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

[Stephen Warren]

On 02/01/2016 05:28 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 1 February 2016 at 17:17, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> 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?
>
> I don't want to use 'lcd' for 'vidconsole' since 'vidconsole' is
> supposed to work for both LCD and video devices. The idea is to merge
> them. The only way I could think of to make it work was hack in
> stdio.c to automatically change 'lcd' to vidconsole. I was not brave
> enough to attempt that, but it might work. What do you think?

That sounds like it should work. Isn't that simply:

#if SOMETHING
if (!strcmp(foo, "lcd"))
     foo = "vidconsole";
#endif

>> 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.
>
> Is that the shield thing? I'd really like to attempt that solder if
> there are instructions somewhere.

It's the Toshiba AC100 laptop. There's some information at 
https://ac100.grandou.net/doku.php (and numerous other places if you 
search Google for the model number.)