From: Dan Murphy <dmurphy@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>,
"Benoît Cousson" <b-cousson@ti.com>,
"Tony Lindgren" <tony@atomide.com>,
devicetree-discuss@lists.ozlabs.org,
lkml <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
Date: Thu, 16 May 2013 15:22:51 -0500 [thread overview]
Message-ID: <5195401B.5070209@ti.com> (raw)
In-Reply-To: <CAGo_u6pX+DdVNWqdPXDChzMr27YAXL_Zvt7DxWBijOCW0rXpkA@mail.gmail.com>
On 05/16/2013 01:18 PM, Nishanth Menon wrote:
> On Thu, May 16, 2013 at 10:35 AM, Dan Murphy <dmurphy@ti.com> wrote:
>> I am not sure you really want to do this.
>> If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when
>> the CONFIG_LEDS_GPIO flag is set.
>>
>> Do you really want that dependency? You did say it was a key fix
>> At least this way the pins are configured regardless of that flag.
> That is better as the system will be left in the pinmux configuration
> handed over from bootloader.
So you want to depend on a boot loader to configure pins correctly for the kernel?
Hmmm seems risky to me.
> The point being, muxing up pins even when not needed(config switched
> off) has no real benefit - in this case albeit, the default mux was
> causing a bug.
> pinctrl IMHO should be considered as any other resource, if it is not
> mandatory for boot, and needed only for a device functionality when
> probed, it should done there only.
>
> just my 2 cents.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
------------------
Dan Murphy
WARNING: multiple messages have this Message-ID (diff)
From: dmurphy@ti.com (Dan Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
Date: Thu, 16 May 2013 15:22:51 -0500 [thread overview]
Message-ID: <5195401B.5070209@ti.com> (raw)
In-Reply-To: <CAGo_u6pX+DdVNWqdPXDChzMr27YAXL_Zvt7DxWBijOCW0rXpkA@mail.gmail.com>
On 05/16/2013 01:18 PM, Nishanth Menon wrote:
> On Thu, May 16, 2013 at 10:35 AM, Dan Murphy <dmurphy@ti.com> wrote:
>> I am not sure you really want to do this.
>> If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when
>> the CONFIG_LEDS_GPIO flag is set.
>>
>> Do you really want that dependency? You did say it was a key fix
>> At least this way the pins are configured regardless of that flag.
> That is better as the system will be left in the pinmux configuration
> handed over from bootloader.
So you want to depend on a boot loader to configure pins correctly for the kernel?
Hmmm seems risky to me.
> The point being, muxing up pins even when not needed(config switched
> off) has no real benefit - in this case albeit, the default mux was
> causing a bug.
> pinctrl IMHO should be considered as any other resource, if it is not
> mandatory for boot, and needed only for a device functionality when
> probed, it should done there only.
>
> just my 2 cents.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
------------------
Dan Murphy
WARNING: multiple messages have this Message-ID (diff)
From: Dan Murphy <dmurphy@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>,
"Tony Lindgren" <tony@atomide.com>,
"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
linux-omap <linux-omap@vger.kernel.org>,
devicetree-discuss@lists.ozlabs.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
Date: Thu, 16 May 2013 15:22:51 -0500 [thread overview]
Message-ID: <5195401B.5070209@ti.com> (raw)
In-Reply-To: <CAGo_u6pX+DdVNWqdPXDChzMr27YAXL_Zvt7DxWBijOCW0rXpkA@mail.gmail.com>
On 05/16/2013 01:18 PM, Nishanth Menon wrote:
> On Thu, May 16, 2013 at 10:35 AM, Dan Murphy <dmurphy@ti.com> wrote:
>> I am not sure you really want to do this.
>> If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when
>> the CONFIG_LEDS_GPIO flag is set.
>>
>> Do you really want that dependency? You did say it was a key fix
>> At least this way the pins are configured regardless of that flag.
> That is better as the system will be left in the pinmux configuration
> handed over from bootloader.
So you want to depend on a boot loader to configure pins correctly for the kernel?
Hmmm seems risky to me.
> The point being, muxing up pins even when not needed(config switched
> off) has no real benefit - in this case albeit, the default mux was
> causing a bug.
> pinctrl IMHO should be considered as any other resource, if it is not
> mandatory for boot, and needed only for a device functionality when
> probed, it should done there only.
>
> just my 2 cents.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
------------------
Dan Murphy
next prev parent reply other threads:[~2013-05-16 20:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-15 16:46 [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS Dan Murphy
2013-05-15 16:46 ` Dan Murphy
2013-05-15 16:46 ` Dan Murphy
2013-05-15 17:05 ` Nishanth Menon
2013-05-15 17:05 ` Nishanth Menon
2013-05-15 17:05 ` Nishanth Menon
2013-05-16 15:35 ` Dan Murphy
2013-05-16 15:35 ` Dan Murphy
2013-05-16 15:35 ` Dan Murphy
2013-05-16 18:18 ` Nishanth Menon
2013-05-16 18:18 ` Nishanth Menon
2013-05-16 20:22 ` Dan Murphy [this message]
2013-05-16 20:22 ` Dan Murphy
2013-05-16 20:22 ` Dan Murphy
[not found] ` <5195401B.5070209-l0cyMroinI0@public.gmane.org>
2013-05-16 20:42 ` Nishanth Menon
2013-05-16 20:42 ` Nishanth Menon
2013-05-16 20:42 ` Nishanth Menon
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=5195401B.5070209@ti.com \
--to=dmurphy@ti.com \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--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: 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.