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

Simon Glass
2016-02-02T00:28:26Z

Hi Stephen,

On 1 February 2016 at 17:17, Stephen Warren <swarren@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@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?

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

Regards,
Simon