[U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

[Stephen Warren]

On 02/01/2016 05:05 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 1 February 2016 at 17:00, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 01/30/2016 04:37 PM, Simon Glass wrote:
>>>
>>> This series moves these two drivers over to use driver model for video.
>>>
>>> This involves the following steps:
>>> - Sync up some device tree files with Linux
>>> - Implement a proper PWM driver
>>> - Clean up and unify the driver code
>>> - Modify the existing drivers to work with driver model
>>>
>>> The tegra20 display driver uses device tree bindings invented in 2011
>>> before
>>> Linux had this or anyone was able to agree a standard. It seems possible
>>> to
>>> move it to the new bindings (like tegra124) except for the issue of time
>>> delays between stages. It isn't clear how this should work, and Linux
>>> implements this by including all LCD definitions in the kernel source
>>> code,
>>> and not using any delays. This causes strange display artifacts on the
>>> display when starting up, but perhaps is harmless to the display. Future
>>> work will sync up the device tree more for seaboard, and thus tidy this up
>>> for nvidia boards.
>>>
>>> A bug in the keyboard driver is also fixed by this series. The series is
>>> tested on seaboard and nyan-big, the two boards I have which support a
>>> display.
>>>
>>> This series is available at u-boot-dm/tegra-working.
>>
>>
>> This changes the name of the output device from "lcd" to "vidconsole".
>> Anyone who doesn't reset their environment to default when switching to this
>> new U-Boot will lose their display output because of this. Is there any way
>> to maintain compatibility?
>
> I could not think of one other than an egregious hack. It will
> certainly bite someone. Perhaps a hack that detects 'lcd' in the
> stdout env variable and prints a warning would be useful?

Can't the two drivers just respond to the same device name. Presumably a 
build would only have one or the other compiled in?

Or perhaps we can add a hook in the board-specific initialization code 
which re-writes the environment after loading it?

Printing a message would be useful if the user has a serial console 
plugged in, which will not always be the case. It is not possible on 
Paz00 (likely the most widely used T20 device) for example without 
taking the case apart and soldering to a very tiny connector; I expect 
almost nobody has done that.