Then I've been talking too much to PC-centric people, who kept on telling me I
should be using readb() and friends to access _all_ memory mapped I/O.
I don't dare to accuse DaveM of being PC-centric (:-), but he told me my
readb() should find out itself whether it's used on an address belonging to the
PCI or the SBUS or the whatever bus... Except for cases that can be optimized
away.
> The fact is, that these days the PCI-like derivatives (and predecessors)
> are just so popular even among non-PC's that I consider PCI to be the
> major interface. That does NOT mean that it should be the only interface,
> and it does NOT mean that all other buses should use "iomem" and "ioport".
Agreed. PCI was never intended to be PC-only. I'm aware of that fact.
> > But now Linus claims all these things are for PCI only?? What should I use
> > for other busses then?? Don't forget there are many drivers that work for
> > the same device connected to different busses.
>
> When that happens, it is only the driver that can know what the
> difference is. If there is a VME and PCI version of the same card, you
> should make that explicit in the driver sources. Because there WILL be
> other differences anyway - how you find the thing, how you initialize it,
> etc etc. So then the driver should be ready and willing to do separate
> initialization.
Initialization indeed differs. Other things may be the same.
In my domain, I'm mainly concerned about the fbcon-* low level drivers. They
just paint characters in memory, which is the same for all cards. Wait a bit...
Memory? This is not always normal memory, it may be mapped through ioremap().
That's why we changed the `pointer dereference style accesses' to `readb() and
friends'.
In 2.3.x, I plan to use `fb_{read,write}*()', which can be re#define'd to
whatever you want if your bus/driver needs it.
I'm just afraid we'll end up with a zillion versions of these fbcon-* low level
drivers now...
> > - Instead of `peanuts', I'd vote for `io' and `memory' :-)
> > Calling it `PCI' is confusing, since there are machines without PCI
> > busses, and machines with PCI and other (SBUS, Zorro) busses in one box.
>
> And EXACTLY because there are machines with PCI and other buses, there
> should be a CLEAR delineation of the two. They should NOT be the same
> resource. If your SBUS subsystem tries to look too much like PCI, that's
> probably a mistake in itself.
>
> And trying to impose any SBUS behaviour on the PCI resource allocation is
> just NOT going to happen. Ever. Either you make it look exactly like PCI
> from a device driver standpoint (at which point you might as well just
> admit to the fact that it IS PCI as far as Linux is concerned, it just has
> slightly different connectors - and you shouldn't complain about PCI-only
If only the connectors differ, it's PCI (or Compact-PCI :-).
> issues), OR you make it a primary bus in its own right, with its own
> resource allocation and with its own access functions and with its own
> identification functions.
In that case I vote for moving the ioport_resource and iomem_resource
definition from kernel/resource.c to a machine/architecture/bus specific file.
Then it makes sense we create zorro_resource and sbus_resource for the Zorro
resp. SBUS bus on Amiga resp. SPARC systems.
Besides, the resource struct contains the start and end addresses of the
resource region, which depend on the machine type. Assuming `PCI mem' is from
0x00000000 to 0xFFFFFFFF is a PCism. E.g. on my CHRP PPC box `PCI mem' is from
0xC0000000-0xF6FFFFFF. And it is `PC style' PCI...
Or do we have to overwrite iomem_resource.{start,end} in setup_arch() with the
correct machine-specific values?
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/