From: Tomi Valkeinen <tomi.valkeinen@ti.com> To: Nishanth Menon <nm@ti.com>, linux-omap@vger.kernel.org, Tony Lindgren <tony@atomide.com> Cc: linux-arm-kernel@lists.infradead.org, Archit Taneja <archit@ti.com> Subject: Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common Date: Fri, 25 Oct 2013 14:33:26 +0300 [thread overview] Message-ID: <526A5706.5010803@ti.com> (raw) In-Reply-To: <526A542D.8060801@ti.com> [-- Attachment #1: Type: text/plain, Size: 1901 bytes --] 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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common Date: Fri, 25 Oct 2013 14:33:26 +0300 [thread overview] Message-ID: <526A5706.5010803@ti.com> (raw) In-Reply-To: <526A542D.8060801@ti.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/319ae9e2/attachment.sig>
next prev parent reply other threads:[~2013-10-25 11:33 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-10-25 10:07 [PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing Tomi Valkeinen 2013-10-25 10:07 ` Tomi Valkeinen 2013-10-25 10:07 ` [PATCH 2/3] ARM: dts: omap4-sdp: add LCD pinmuxing Tomi Valkeinen 2013-10-25 10:07 ` Tomi Valkeinen 2013-10-25 10:07 ` [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common Tomi Valkeinen 2013-10-25 10:07 ` Tomi Valkeinen 2013-10-25 10:18 ` Nishanth Menon 2013-10-25 10:18 ` Nishanth Menon 2013-10-25 10:25 ` Tomi Valkeinen 2013-10-25 10:25 ` Tomi Valkeinen 2013-10-25 10:54 ` Nishanth Menon 2013-10-25 10:54 ` Nishanth Menon 2013-10-25 11:13 ` Tomi Valkeinen 2013-10-25 11:13 ` Tomi Valkeinen 2013-10-25 11:21 ` Nishanth Menon 2013-10-25 11:21 ` Nishanth Menon 2013-10-25 11:33 ` Tomi Valkeinen [this message] 2013-10-25 11:33 ` Tomi Valkeinen 2013-10-25 11:14 ` Nishanth Menon 2013-10-25 11:14 ` Nishanth Menon 2013-10-25 11:17 ` Tomi Valkeinen 2013-10-25 11:17 ` Tomi Valkeinen 2013-10-25 11:46 ` Tomi Valkeinen 2013-10-25 11:46 ` Tomi Valkeinen 2013-10-25 15:24 ` Nishanth Menon 2013-10-25 15:24 ` Nishanth Menon 2013-10-29 10:15 ` [PATCH 1/3] ARM: dts: omap4-panda: add DPI pinmuxing Tomi Valkeinen 2013-10-29 10:15 ` Tomi Valkeinen 2013-10-29 21:25 ` Tony Lindgren 2013-10-29 21:25 ` Tony Lindgren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=526A5706.5010803@ti.com \ --to=tomi.valkeinen@ti.com \ --cc=archit@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=nm@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.