All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>,
	linux-omap@vger.kernel.org, Tony Lindgren <tony@atomide.com>
Cc: Archit Taneja <archit@ti.com>, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/3] ARM: OMAP2: omap4-sdp: remove unneeded gpios from dss-common
Date: Fri, 25 Oct 2013 10:24:50 -0500	[thread overview]
Message-ID: <526A8D42.5090209@ti.com> (raw)
In-Reply-To: <526A59F9.3010104@ti.com>

On 10/25/2013 06:46 AM, Tomi Valkeinen wrote:
> On 25/10/13 14:14, Nishanth Menon wrote:
> 
>> lcd2_pins: pinmux_lcd2_pins {
>> +		pinctrl-single,pins = <
>> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
>> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
>> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
>> +		>;
>>
>> 3 pins are driven around 300uA at boot, even with display OFF -> which
>> means wasted current that could have been optimized by hooking the pin
>> to the dts node corresponding to the device and used by the driver
>> appropriately.
> 
> One more clarification question.
> 
> The gpio 40 is used to enable powers for the picodlp. Shouldn't that one
> have a pinctrl pull-down in any case? If it's left floating, and the
> driver is not compiled in or doesn't start, the powers could get enabled
> depending on sunspot, right?
> 
> And I guess the same goes for all gpios used to enable something.
> 
Fair question. The selection of pull up, gpio control needs to be
balanced.
if the peripheral in question has a regulator controlled supply, none
of the pins would matter - driver can adequately sequence this to
ensure there are no weird side-effects. in such a scenario, i'd have a
default MODE3 with no pulls, sequence as follows:
a) control gpio to required default level (disabled)
b) control regulator
c) set GPIO to enable.

if the peripheral in question is always on and controlled with just a
enable pin, it is safer to keep the pin muxed with weak pull.

If the enable has no real functional impact without setting another
pin (say power_on), or if any transient glitches on the line has no
functional impact, I might go with no pull configuration.


It all depends on the schematics and peripherals involved w.r.t how
you'd optimally select the configuration.

-- 
Regards,
Nishanth Menon

WARNING: multiple messages have this Message-ID (diff)
From: nm@ti.com (Nishanth Menon)
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 10:24:50 -0500	[thread overview]
Message-ID: <526A8D42.5090209@ti.com> (raw)
In-Reply-To: <526A59F9.3010104@ti.com>

On 10/25/2013 06:46 AM, Tomi Valkeinen wrote:
> On 25/10/13 14:14, Nishanth Menon wrote:
> 
>> lcd2_pins: pinmux_lcd2_pins {
>> +		pinctrl-single,pins = <
>> +			0x20 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_40 */
>> +			0x46 (PIN_OUTPUT_PULLUP | MUX_MODE3)	/* gpio_59 */
>> +			0x56 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* gpio_104 */
>> +		>;
>>
>> 3 pins are driven around 300uA at boot, even with display OFF -> which
>> means wasted current that could have been optimized by hooking the pin
>> to the dts node corresponding to the device and used by the driver
>> appropriately.
> 
> One more clarification question.
> 
> The gpio 40 is used to enable powers for the picodlp. Shouldn't that one
> have a pinctrl pull-down in any case? If it's left floating, and the
> driver is not compiled in or doesn't start, the powers could get enabled
> depending on sunspot, right?
> 
> And I guess the same goes for all gpios used to enable something.
> 
Fair question. The selection of pull up, gpio control needs to be
balanced.
if the peripheral in question has a regulator controlled supply, none
of the pins would matter - driver can adequately sequence this to
ensure there are no weird side-effects. in such a scenario, i'd have a
default MODE3 with no pulls, sequence as follows:
a) control gpio to required default level (disabled)
b) control regulator
c) set GPIO to enable.

if the peripheral in question is always on and controlled with just a
enable pin, it is safer to keep the pin muxed with weak pull.

If the enable has no real functional impact without setting another
pin (say power_on), or if any transient glitches on the line has no
functional impact, I might go with no pull configuration.


It all depends on the schematics and peripherals involved w.r.t how
you'd optimally select the configuration.

-- 
Regards,
Nishanth Menon

  reply	other threads:[~2013-10-25 15: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
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 [this message]
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=526A8D42.5090209@ti.com \
    --to=nm@ti.com \
    --cc=archit@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tomi.valkeinen@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: link
Be 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.