dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

Hi Stephen,

Quoted 52 lines · Stephen Warren

Quoted 49 lines · Simon Glass

Hi Stephen,

Quoted 34 lines · Stephen Warren

Quoted 24 lines · Simon Glass

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.

Quoted 5 lines

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.

Quoted 6 lines

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?

Quoted 2 lines

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?

Quoted 8 lines

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.