[U-Boot] [PATCH] ns16550: allow UART address to be set dynamically

[Stephen Warren <swarren@wwwdotorg.org>]

On 12/17/2012 02:09 PM, Tom Rini wrote:
> On 12/14/12 17:45, Stephen Warren wrote:
>> On 12/14/2012 03:22 PM, Simon Glass wrote:
>>> Hi Stephen,
>> ...
>>> Perhaps I can make the point another way. Assuming that the SOC
>>> in question is ARM-based and has Linux support it either supports
>>> FDT now or presumably will fairly soon.
> 
>> Sure, but I'm *explicitly* avoiding relying on DT for this,
>> because there are plenty of things that happen before DT can or
>> should be touched that might warrant serial port output.
> 
> Also totally true and valid.  But what I'd like to see is:
> parse_odmdata(void *ptr) {
>   if (ptr->console)
>     device_tree_register_uart(... fake it ...);
> }

Sorry, I'm having a hard time parsing:

> In other words, if we add the register a port call now, there's a

By "register a port call", do you mean the device_tree_register_uart()
you're proposing above, or the NS16550_set_dynamic_address() I'd
implemented in my patch?

Below, you appear to be pointing out problems with adding the "register
a port call now" which seems like you're arguing against your own example?

> history of adding just one more thing, by someone else (say am335x and
> our EVMs that differ on where primary UART is, and only need a little
> different logic to say 'oh! this one.') and making a mess of things.

> Once we deal with device trees in some manner, then we can just fake
> their existence at this point and pass in the console information from
> ODMDATA.

There are many ways besides device tree to enumerate hardware. For
example, consider PCI or USB (albeit USB isn't memory mapped). I don't
think we should tie any new U-Boot dynamic device registration API to
device tree, since that would seem to prevent (or imply against) usage
of that API with PCI for example.

Perhaps this is just bike-shedding over naming?

So, perhaps:

int device_register_uart(enum uart_type, u32 base_address)

So that all of the following cases could call that:

* DT parsing.
* PCI device enumeration.
* ODMDATA parsing.

(and where enum uart_type is some internal U-Boot identifier for the
UART drivers it supports)

Presumably the implementation would validate if the (uart_type,
base_address) combination had been seen already, and then do nothing.
that would allow for ODMDATA parsing to set up the UART, and then DT
parsing to avoid any special cases to skip handling DT nodes for serial
devices that were already registered.