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

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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@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".  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.
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"

In other words, we want to (re)start the conversation around lets get
device tree going.  Then we can deal with other things.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQykBWAAoJENk4IS6UOR1W0q4P/2P2yFc0FgPNfDdPU31DCVwI
mZPEzIY4xkuCAh0F2fGfzHjqYHtivru3py9Q7Os1Quse7BoWYea5HHH0/dbxCGGI
DWuqWUtle7XPFwfdTiMkf60wXcYzTKrg/1KXV259lvy3zxjhgttDMNMhucHEgWG4
E3wdfGqvQ6SuAYOxDAuSZrA6N7hCLCcCDSt2YMKWpIuP0iJiwCYLPloXgMfQd9h0
en+KY2TivavbFRsUoXzdmmDk7k0/7nP0TzOGn7TQVWetQ3x63C8Z8nD25QxiDDEP
onQq7p32UjXpbd1DVgy1F77n8afj6jKYWyRKCC8w2pp/PXx7W00qJRg/7KBGYAgx
VASpUpWb004WPIHLUykOee9cZneo0HlH1EUCIMkFLVLunABMxlMjLvdVQ04Ow4st
GbDRTKkTsG0pheGCTN50CyJMexv0wjDgaqS9PsaRtYNBliwXslg5lqFBm6u96/gR
+6nzkI9vHLGNnFOjqWVQeKt3XjQW+eByivDB778isMYohdEwOMCFz3uFSsK3AcGR
YxdM3CPNYzbMMZQ6SwYp4NZ+6XQd+ovIunuWECapRLRSIaI6pOKo3TBmOJOfbCD0
Pxf60seXUj4jsCO6e9oki5C/vwC1PiQ6uMxL2ucNpJN6sHdH0ivHRCGdjy866m0r
FGFVZlNtxmXhROcdBYTV
=N5NV
-----END PGP SIGNATURE-----