On Fri, 2014-04-18 at 18:43 +0200, Joachim Eastwood wrote: > > If it does not make sense to set up a generic mode-gpios for the > > panels, then panel dpi can parse the first two GPIOs for enable > > and reset. Then we can allow the rest of the array be parsed if > > needed based on the compatible flag. > > Looking through the panels in omap2/display-new the most common gpio > pins are; backlight, reset and enable. > So it makes sense to have enable and reset as properties. > > Gpio is used for mode setting in: nl8048hl11 and ls037v7dw01. > nl8048hl11 has just a qvga gpio, while the other one has no less than > 3 mode pins (qvga and 2 scanning direction pins). All these mode pins > are set once and then never touched again. > > Using gpios property for setting up an arbitrary amount of mode pins > so like a solution to me. Generic reset gpio handling is a bit problematic, as even if we know what the normal state for the gpio is, we don't know how to use it. How long should it be set to reset-state? How long should be it in the normal-state before we can reset again? How to handle the powers when resetting? We could have some big delays there, which would work for more or less all the panels. It just doesn't feel quite right =). If we need reset and panel specific mode pin handling, I think a separate driver is the cleanest option. Do we have any way to set some gpios to a specified value at boot time via DT, in a fixed manner? So more or less what Tony does in ldp_twl_gpio_setup(). If we could just fix the RESET and QVGA gpios, we could use the panel-dpi just fine, and only handle the enable gpio in the panel driver. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
