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

[Stephen Warren]

On 12/13/2012 01:53 PM, Tom Rini wrote:
> On 12/13/12 15:45, Stephen Warren wrote:
>> On 12/13/2012 01:36 PM, Wolfgang Denk wrote:
>>> Dear Stephen Warren,
>>> 
>>> In message <50CA1BB8.4000704 at wwwdotorg.org> you wrote:
>>>> 
>>>>> Arghh... Do we really, really have to invent yet another
>>>>> way to pass hardware configuration information?  Especially
>>>>> one totally incompatible to any other system?
>>>> 
>>>> This is a special case for the console UART. The idea is to
>>>> get that up and running well before device tree is parsed in
>>>> any way. For example, Tegra's SPL doesn't touch the device
>>>> tree in any way (or even know one exists) but does want to
>>>> print (possibly error) messages in a generic fashion.
>>>> Similarly, many problems could occur before the device tree
>>>> is parsed (e.g. the user forgets to provide one...), and
>>>> having specifically the console UART set up before that
>>>> allows those errors to be reported, rather than requiring a
>>>> JTAG or similar debugger.
>>>> 
>>>> My intent is that ODMDATA will definitely only be used for
>>>> the console UART, and will NOT be used for anything else like
>>>> LCD, RTC, ... Those other devices will certainly be
>>>> configured via device tree.
>>> 
>>> We've been there before, you know.
> 
>> I'm not quite sure what the implication is here.
> 
>>> OK - what is the scope of visibility of such code?  Will it be
>>>  strictly board specific only?  Or SoC specific? Arch? Global?
> 
>> It's partially SoC-specific, partially global.
> 
> Right.  I see what Wolfgang was saying before, and I get it now.
> This is not how we want to open the can of worms for "lets do
> dynamic locations of stuff".  We should start with being able to
> parse (some form of the normal) device tree, and be able to say "I
> now know I have a UART $HERE and $THERE".

So if Tegra were to statically define the location of all 5 on-SoC
UARTs, by defining CONFIG_SYS_NS16550_COM*, and then use the ODMDATA
to select which UART to use for the console, rather than using the
ODMDATA to dynamically change the value that CONFIG_SYS_NS16550_COM1
sets up, would that remove the objection? I haven't look into coding
that up, but I imagine it could be made to work...

> And yes, that's too late for initial console being in the right
> spot, at first, probably.  But now we've moved in the direction of
> being able to dynamically assign things.

I'm not sure about "at first"; on Tegra, I don't imagine the SPL would
ever use device tree. The only HW- (board-) specific thing that's
relevant to it is the UART and UART-pinmux, since the SPL only exists
to boot the main A9 cores, and doesn't ever access any kind of storage
device.

> And from there we can move on and say "On ${SoC} we get a device
> tree (that we can't quite parse as we don't have enough resources)
> AND $some-data (OMDATA or an abbreviated device tree or $whatever),
> lets translate that into something we can make use of very early
> rather than a hard-coded initial console location"

It seems like you're saying that once we have dynamic serial port
assignment working based on DT, you'll be fine using ODMDATA to
initialize the early console, but not before then? If so, I'm having a
hard time understanding why enabling the DT-based support blocks using
ODMDATA, since the code would be pretty orthogonal.