On 25/10/13 14:21, Nishanth Menon wrote: >> The problem here is that the gpios don't really belong to anyone in the >> kernel, as we don't have a driver for the switch. >> >> Or did you mean that we'd still have the code in dss-common.c, but just >> get the gpio numbers from the .dts instead? That makes sense, although >> I'd want to get rid of that code altogether. >> >> Should we have support in the gpio-controller to define default values >> for gpios? I don't think we can rely on the boot loader to set things >> correctly. >> > > I am unfortunately, not in a position to know how you plan to > architect dss_common or the various panels associated with it. if you The dss-common.c is just a hack, needed during the transition to DT. It's supposed to go away as soon as we have proper DT support for DSS. In this case it has just been a convenient place to set the gpios at boot time. The gpios are not touched after that. > model these as panels and a generic driver which controls the panel > could request and control pins and gpios as needed I suppose. > > gpio controller cannot drive default pull direction, that is the job > of the driver using the gpio. I agree. But what to do when there is no driver that uses the gpio, but the gpio still affects the drivers? That's more or less the situation here. The SDP board has an LCD and a PicoDLP projector, and the board designers have shared resources between those, meaning only one can be used at a time. Having the GPIO pulled down means that LCD2 won't have backlight (although the gpio doesn't actually enable the backlight, it just handles the routing if I'm not mistaken) , but PicoDLP will have something (parallel video datalines, if I recall right). I can't add that GPIO to either the LCD driver or the PicoDLP driver, as it's not a property of either of them. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
