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

[Simon Glass]

Hi Stephen,

On 1 February 2016 at 17:36, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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

I've sent a patch for this. Hopefully it will not offend too many people.

>
>>> 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.)

Ah OK I had forgotten about that, thanks.

Regards,
Smion