All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dong Aisheng <aisheng.dong@freescale.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Dong Aisheng-B29396 <B29396@freescale.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linus.walleij@stericsson.com" <linus.walleij@stericsson.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
Subject: Re: [PATCH v2 1/2] pinctrl: add pinctrl_provide_dummies interface for platforms to use
Date: Thu, 26 Apr 2012 15:48:54 +0800	[thread overview]
Message-ID: <20120426074853.GA26070@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <4F9816A3.5090907@wwwdotorg.org>

On Wed, Apr 25, 2012 at 11:22:11PM +0800, Stephen Warren wrote:
> On 04/25/2012 05:49 AM, Dong Aisheng wrote:
> > On Wed, Apr 25, 2012 at 07:19:43PM +0800, Linus Walleij wrote:
> >> On Wed, Apr 25, 2012 at 11:49 AM, Dong Aisheng
> >> <aisheng.dong@freescale.com> wrote:
> >>> On Wed, Apr 25, 2012 at 03:00:23AM +0800, Stephen Warren wrote:
> >>
> >>>> The only thing that should be calling pinctrl_request_gpio() is a GPIO
> >>>> driver. It should only be calling it for the GPIOs it manages. I'd
> >>>> expect that if a platform's pinctrl driver was not yet written to
> >>>> support the GPIO functionality, then the GPIO driver would not be
> >>>> calling this function.
> >>>>
> >>> Hmm, pinctrl gpio is in the same situation as pinctrl state that gpio
> >>> driver may be shared between several platforms, with pinctrl support
> >>> or not.
> >>
> >> I think it's mostly safe to assume that either:
> >>
> > I just saw your reply after i sent out the revised patch...
> > 
> >> - pinctrl calls from GPIO drivers gets stubbed out totally due to
> >>   CONFIG_PINCTRL not being selected
> >>
> > Yes, we already have that in include/linux/pinctrl/consumer.h
> > 
> >> or:
> >>
> >> - You need to pass a token through platform data to the
> >>   GPIO driver telling it whether it needs to request pins for
> >>   it's GPIOs or not. Just a bool should work fine?
> >>
> > Yes, this is an alternative way.
> > I'm using a similar way, but pass the data to pinctrl core
> > rather than gpio driver. Then it is be handled together with
> > dummy state in platform code.
> > 
> > Do you think if the current way i used is ok?
> > Or i need to change to your proposed way?
> 
> I think Linus was suggesting a flag in platform data for each GPIO
> driver rather than a global flag for the entire pinctrl subsystem.
> 
> That way, if one of the pinctrl drivers did fully support all the GPIO
> functionality and the other didn't, you'd be able to have just one of
> the GPIO drivers not call into pinctrl (or ignore certain errors) yet
> the other GPIO driver could still fully interact with pinctrl as desired.
> 
Yes, it's true.
I will drop the dummy gpio support in pinctrl subsystem and let gpio
driver to decide whether it wants to use pinctrl gpio mux function.

Regards
Dong Aisheng


WARNING: multiple messages have this Message-ID (diff)
From: aisheng.dong@freescale.com (Dong Aisheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] pinctrl: add pinctrl_provide_dummies interface for platforms to use
Date: Thu, 26 Apr 2012 15:48:54 +0800	[thread overview]
Message-ID: <20120426074853.GA26070@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <4F9816A3.5090907@wwwdotorg.org>

On Wed, Apr 25, 2012 at 11:22:11PM +0800, Stephen Warren wrote:
> On 04/25/2012 05:49 AM, Dong Aisheng wrote:
> > On Wed, Apr 25, 2012 at 07:19:43PM +0800, Linus Walleij wrote:
> >> On Wed, Apr 25, 2012 at 11:49 AM, Dong Aisheng
> >> <aisheng.dong@freescale.com> wrote:
> >>> On Wed, Apr 25, 2012 at 03:00:23AM +0800, Stephen Warren wrote:
> >>
> >>>> The only thing that should be calling pinctrl_request_gpio() is a GPIO
> >>>> driver. It should only be calling it for the GPIOs it manages. I'd
> >>>> expect that if a platform's pinctrl driver was not yet written to
> >>>> support the GPIO functionality, then the GPIO driver would not be
> >>>> calling this function.
> >>>>
> >>> Hmm, pinctrl gpio is in the same situation as pinctrl state that gpio
> >>> driver may be shared between several platforms, with pinctrl support
> >>> or not.
> >>
> >> I think it's mostly safe to assume that either:
> >>
> > I just saw your reply after i sent out the revised patch...
> > 
> >> - pinctrl calls from GPIO drivers gets stubbed out totally due to
> >>   CONFIG_PINCTRL not being selected
> >>
> > Yes, we already have that in include/linux/pinctrl/consumer.h
> > 
> >> or:
> >>
> >> - You need to pass a token through platform data to the
> >>   GPIO driver telling it whether it needs to request pins for
> >>   it's GPIOs or not. Just a bool should work fine?
> >>
> > Yes, this is an alternative way.
> > I'm using a similar way, but pass the data to pinctrl core
> > rather than gpio driver. Then it is be handled together with
> > dummy state in platform code.
> > 
> > Do you think if the current way i used is ok?
> > Or i need to change to your proposed way?
> 
> I think Linus was suggesting a flag in platform data for each GPIO
> driver rather than a global flag for the entire pinctrl subsystem.
> 
> That way, if one of the pinctrl drivers did fully support all the GPIO
> functionality and the other didn't, you'd be able to have just one of
> the GPIO drivers not call into pinctrl (or ignore certain errors) yet
> the other GPIO driver could still fully interact with pinctrl as desired.
> 
Yes, it's true.
I will drop the dummy gpio support in pinctrl subsystem and let gpio
driver to decide whether it wants to use pinctrl gpio mux function.

Regards
Dong Aisheng

  reply	other threads:[~2012-04-26  7:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24  9:33 [PATCH v2 1/2] pinctrl: add pinctrl_provide_dummies interface for platforms to use Dong Aisheng
2012-04-24  9:33 ` Dong Aisheng
2012-04-24  9:33 ` [PATCH v2 2/2] pinctrl: remove the old pinctrl dt dummy state interfaces Dong Aisheng
2012-04-24  9:33   ` Dong Aisheng
2012-04-24 19:04   ` Stephen Warren
2012-04-24 19:04     ` Stephen Warren
2012-04-25 12:05     ` Dong Aisheng
2012-04-25 12:05       ` Dong Aisheng
2012-04-24 19:00 ` [PATCH v2 1/2] pinctrl: add pinctrl_provide_dummies interface for platforms to use Stephen Warren
2012-04-24 19:00   ` Stephen Warren
2012-04-25  9:49   ` Dong Aisheng
2012-04-25  9:49     ` Dong Aisheng
2012-04-25 11:19     ` Linus Walleij
2012-04-25 11:19       ` Linus Walleij
2012-04-25 11:49       ` Dong Aisheng
2012-04-25 11:49         ` Dong Aisheng
2012-04-25 15:22         ` Stephen Warren
2012-04-25 15:22           ` Stephen Warren
2012-04-26  7:48           ` Dong Aisheng [this message]
2012-04-26  7:48             ` Dong Aisheng

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=20120426074853.GA26070@shlinux2.ap.freescale.net \
    --to=aisheng.dong@freescale.com \
    --cc=B29396@freescale.com \
    --cc=linus.walleij@linaro.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=swarren@wwwdotorg.org \
    /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.