Re: uart_match_port() question

[Benjamin Herrenschmidt]

> ia64 has basically the same situation.  I decided it was a mistake to
> have the arch code register serial ports early, because we only learn
> about a few of the ports early, and the firmware console configuration
> determines which ones we learn about.
> 
> The consequence is that changing the firmware configuration changes the
> serial device names, which I thought was a bad thing.
> 
> I finally settled on this scheme:
> 	- discover default firmware port (pcdp.c)
> 	- set it up as an "early uart" which has no ttyS name
> 	  and runs in polled mode (early_serial_console_init())
> 	- register it as a console
> 	- let 8250_{pci,pnp,etc} discover all the ports and
> 	  figure out minor numbers (i.e., ttyS names)
> 	- locate the port that matches the default firmware port,
> 	  switch console to it, and unregister the "early uart"
> 	  (early_uart_console_switch())

Yup, I've been thinking about a similar approach yah. My main issue is
your last step: "locate the port that matches the default firmware
port". Right now, thins works because the early registration allow me to
know in advance what the ttyS number will be. If I go your way,  which I
'm tempted to do, I need to figure out precisely how to properly match
the ports. Part of the problem here is for example PIO. There is no such
thing as PIO on a PowerPC, it's purely a PCI abstraction, thus inX/outX
will only work once the PCI host briges have been discovered and their
IO space mapped (setup_arch() time, but I definitely want my early
console earlier). Thus, for early ports, we use the open firmware tree
to translate all (including PIO) addresses to MMIO in CPU space.

Thus, later on, when the serial driver kicks in, it can't match the PCI
IO resources it's getting from the PCI code to the MMIO physical
addresses or ioremaped addresses that were used at early boot time.

That sort of thing ...

Anyway, things work now with the fix for properly matching MMIO ports
with their physical address and my current mecanism, even if it's not
the nicest solution. I'll still look into reworking it a better way but
I don't have the time right now.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/