Re: RFC: delete UART current-speed from 4xx DTS?

[Josh Boyer <jwboyer@linux.vnet.ibm.com>]

On Wed, Sep 16, 2009 at 07:44:07AM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2009-09-15 at 11:32 -0400, Josh Boyer wrote:
>> On Tue, Sep 15, 2009 at 10:31:36AM -0400, Paul Gortmaker wrote:
>> >One of the guys here was getting a messed up console on a bamboo board
>> >(on linux boot), which he traced to the fact that the default dts has a
>> >9600 baudrate coded into it (board was running 115k2, not 9600).  Either
>> >deleting the line, or replacing the 9600 with zero fixed the problem.
>> 
>> Once booted, was there a valid current-speed property in /proc/device-tree
>> for the serial node?  I'm curious if U-Boot created it, or if the kernel
>> just used whatever baud was present already.
>> 
>> When I did the bamboo port a while ago, I recall having issues with either
>> a missing clock-frequency or current-speed (or both perhaps) and the bootloader
>> on the board was the original PIBS.  It might have been an issue with PIBS
>> but I'm guessing the rest of the 4xx boards copied from either Ebony or
>> Bamboo in their ports and hence contain that property.
>
>I think I recently added code to legacy_serial probe the speed from the
>HW if the property is absent, which should help.

Ok, so I think that is related to what I originally hit.

I played around with removing the current-speed property on canyonlands today,
and noticed that I would get no console output at all unless I specified a
baudrate with console=ttyS0,115200.  That was sort of contrary to what I found
with bamboo, so I diffed the configs to see why.  Bamboo has udbg enabled and
hence has legacy_serial builtin, whereas canyonlands just has of_serial.

So on boards where of_serial is the only serial driver, we need either an
accurate current-speed property, or a specific baudrate on the command line.
That makes a bit more tenuous to remove the properties entirely, because if
people disable udbg and are relying on that behavior they get no more console
output.  Need to think on that a bit I guess.

Alternatively, we could try patching of_serial.c to do the baudrate probe
as well.

josh