Musings on PCI busses

[Benjamin Herrenschmidt]

> I mean that all OF devices have fully resolved MMIO resources.  So
> very early serial devices that sit in I/O space on sparc64 end
> up being OF device drivers.  See for example, drivers/net/sunsu.c
> which is simply a 8250 chip that sits behind Sun's I/O space bus
> that sits on PCI and provides things normally found via ISA on
> x86 machines.  Another example is drivers/serial/sunsab.c

Right. On Cell, we use the "normal" 8250 driver, via of_serial which
basically initializes it from the of device and associated resources.

It gets a bit messy because we -also- create a platform driver that can
be matched by 8250, in fact, we have a bit of generic powerpc code that
does that early at boot, initializes our low level very early udbg
thingy with it and creates the platform devices.

And then the serial port can -also- be detected by 8250_pci.c when it's
on a PCI based UART :-)

Now, generally thinks work fine even if you use all 3 drivers because
they have the same resources and 8250 has some smarts to figure that out
and not re-create ports. It somewhat fails in the case where we end up
with IO looking like MMIO on one side and looking like PCI IO on another
tho.

We -could- try to standardize on a single of those 3 methods of course.
The of_serial one has some appeal but I quite like the platform driver
approach at this stage because we have code to handle all sort of weirdo
special cases in there (more or less insane device-tree's, weird SoC's,
etc...) and still pump out something 8250_platform can grok, and that
code can run -very- early and provide a udbg backend for early debug and
xmon usage.

> I would make these device drivers OF device drivers.
> 
> Another option is to make use of the "address" property if present.
> You can bypass all of the hassle of figuring out what the 'reg'
> property resolves to by using that and if the device is the
> console it is pretty reliable to expect OF to provide that "address"
> property.
> 
> Of course this doesn't work well for non-console devices.

Also we have various broken firmwares with non usable "address"
properties to deal with.

Ben.