[PATCH 1/2] ARM: Add inituart macro to initialize DEBUG_LL serial port based on the machine ID

[tony@atomide.com (Tony Lindgren)]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110204 04:31]:
> On Fri, Feb 04, 2011 at 08:39:34AM +0000, Russell King - ARM Linux wrote:
> > Can't we just hard-configure the virtual/physical address at build
> > time and be done with it?
> > 
> > I've given up with the current state of affairs which tries to use the
> > platform ID to select the UART to use as it never seems to work, and I
> > have a couple of patches which hard-code the address at compile time -
> > one for the SDP4430 board and one for the LDP3430 board.
> > 
> > If it's complicated, then it probably won't work.  Keep it simple.
> > That's especially true for debugging code, otherwise you need extra
> > debugging code to debug why the debugging code doesn't work.
> 
> There's another good reason to hard-configure the UART port rather
> than select it by ID.
> 
> The common usage scenario: you're bringing up a new board.  You know
> you're going to have your console connected to UART2.  So, no matter
> what you want your debug messages to come out of UART2 even if the
> machine ID is wrong.

Yes that's an important debugging case too. Another common use
case is "this kernel boots on machines a and b, but fails to boot
on c and d".
 
> By detecting the UART port from the machine number, you immediately
> lose that ability, and therefore the confidence, that "if I build the
> kernel for X with LL debug enabled, and monitor port Y, I will get
> messages out of port Y, and not some other random port Z which I'd to
> solder wires to to monitor."

True, but that easily also leads to confusion on why some kernel only
boots on one machine. So maybe we can do something that can easily be
selected in Kconfig for forcing certain port?
 
> In other words, no messages on the monitored port changes from "we didn't
> get into the kernel, or something early in the kernel boot before the C
> code went wrong" to "... or maybe the debugging code failed to get the
> right port too."
> 
> It is invaluable to know that the debugging code will always talk to
> the same UART which you're monitoring.

I'll take a look how we can allow forcing the uart easily.

Regards,

Tony