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 13:25:12 +0300 [thread overview] Message-ID: <526A4708.7010309@ti.com> (raw) In-Reply-To: <526A4585.30403@ti.com> [-- Attachment #1: Type: text/plain, Size: 1371 bytes --] On 25/10/13 13:18, Nishanth Menon wrote: >> void __init omap_4430sdp_display_init_of(void) >> { >> - int r; >> - >> - r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH, >> - "display_sel"); >> - if (r) >> - pr_err("%s: Could not get display_sel GPIO\n", __func__); >> - >> - r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW, >> - "DLP POWER ON"); >> - if (r) >> - pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__); >> - >> omap_display_init(&sdp4430_dss_data); >> >> platform_device_register(&sdp4430_lcd_device); >> > would you not be depending on the weak IO pull done using mux to drive > these GPIO pins since the GPIO is not requested and held? Yes. Is that not enough? > Could we not use Documentation/devicetree/bindings/gpio/gpio.txt > binding to map to the right GPIO and drive it using the GPIO module? Hmm, what do you mean? I do mux the pins to gpios, but there's nothing in the kernel that would use those gpios. That's why we had the hack above, but I'd love to get rid of it. Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts? If things were perfect, we probably would have a driver for the "switch" part. I have no idea what kind of driver that would be, though, so at the moment we've just gone with the use-LCD2-by-default route. 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 13:25:12 +0300 [thread overview] Message-ID: <526A4708.7010309@ti.com> (raw) In-Reply-To: <526A4585.30403@ti.com> On 25/10/13 13:18, Nishanth Menon wrote: >> void __init omap_4430sdp_display_init_of(void) >> { >> - int r; >> - >> - r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH, >> - "display_sel"); >> - if (r) >> - pr_err("%s: Could not get display_sel GPIO\n", __func__); >> - >> - r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW, >> - "DLP POWER ON"); >> - if (r) >> - pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__); >> - >> omap_display_init(&sdp4430_dss_data); >> >> platform_device_register(&sdp4430_lcd_device); >> > would you not be depending on the weak IO pull done using mux to drive > these GPIO pins since the GPIO is not requested and held? Yes. Is that not enough? > Could we not use Documentation/devicetree/bindings/gpio/gpio.txt > binding to map to the right GPIO and drive it using the GPIO module? Hmm, what do you mean? I do mux the pins to gpios, but there's nothing in the kernel that would use those gpios. That's why we had the hack above, but I'd love to get rid of it. Can I set the pins to GPIO mode, and set the GPIO to high/low in the .dts? If things were perfect, we probably would have a driver for the "switch" part. I have no idea what kind of driver that would be, though, so at the moment we've just gone with the use-LCD2-by-default route. 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/b14d1d18/attachment.sig>
next prev parent reply other threads:[~2013-10-25 10:25 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 [this message] 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 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=526A4708.7010309@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.