Hi Stephen, On 1 February 2016 at 17:36, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 02/01/2016 05:28 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 1 February 2016 at 17:17, Stephen Warren <swar...@wwwdotorg.org> wrote: >>> >>> On 02/01/2016 05:05 PM, Simon Glass wrote: >>>> >>>> >>>> Hi Stephen, >>>> >>>> On 1 February 2016 at 17:00, Stephen Warren <swar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot