All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	alsa-devel@alsa-project.org, Liam Girdwood <lrg@ti.com>
Subject: Re: [PATCH] ASoC: core: Configure pin muxing via pinctrl when registering a DAI
Date: Mon, 24 Sep 2012 09:41:22 -0600	[thread overview]
Message-ID: <50607F22.4070903@wwwdotorg.org> (raw)
In-Reply-To: <20120924101757.GC21375@opensource.wolfsonmicro.com>

On 09/24/2012 04:17 AM, Mark Brown wrote:
> On Mon, Sep 24, 2012 at 11:20:16AM +0200, Linus Walleij wrote:
>> On Sun, Sep 23, 2012 at 5:23 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> 
>>> I think the errors shouldn't be ignored at all; it's an error for a
>>> driver to explicitly go out and request a pinctrl state if that state is
>>> not defined. In turn, this means that no generic code should be going
>>> out and requesting a pinctrl state on behalf of the driver; it has no
>>> idea if the driver has defined that it needs pinctrl set up for it.
> 
>> This makes perfect sense to me, right now atleast.
> 
>> So the problem with the patch we're discussing is that it's
>> "too far up" in the framework, and handling pinctrl should be done
>> somewhere below.
> 
> Well, the problem here is that people keep wanting to add one shot
> pinctrl calls in drivers which clearly suggests that it ought to be
> factored out.
> 
>>> For any pinctrl configuration that is static, that configuration should
>>> be applied one time as the system boots using the "hog" feature of the
>>> pin controller itself,
> 
>> Agreed. Even in the docs luckily :-)
> 
> Which is one way of factoring out, though it doesn't seem to be
> universally applied (and I don't immediately see how it scales when the
> device is used in multiple SoCs some of which need runtime configuration
> and some of which don't).

Anywhere that particular device is used needs to have a pinctrl state
defined. On SoCs that need the pinctrl changed, the pinctrl state would
be populated with meaningful data. On SoCs that don't need pinctrl
changed, the pinctrl state would be empty; essentially a dummy just to
represent the fact that someone thought about the issue and decided
nothing was needed.

But I still find it unlikely that this situation will occur; surely
there's some specific reason directly related to the device itself, or
the protocol it implements, that defines whether it needs dynamic
pinctrl, and hence no matter what SoC that device is inserted into, it
will either need or not-need dynamic pinctrl. Are there any extant
examples to refute this?

  parent reply	other threads:[~2012-09-24 15:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-21  7:54 [PATCH] ASoC: core: Configure pin muxing via pinctrl when registering a DAI Peter Ujfalusi
2012-09-21 11:13 ` Mark Brown
2012-09-21 13:16   ` Peter Ujfalusi
2012-09-21 14:55     ` Peter Ujfalusi
2012-09-22 15:23       ` Mark Brown
2012-09-21 16:23     ` Stephen Warren
2012-09-22 15:28       ` Mark Brown
2012-09-23  3:23         ` Stephen Warren
2012-09-24  9:20           ` Linus Walleij
2012-09-24 10:17             ` Mark Brown
2012-09-24 14:37               ` Linus Walleij
2012-09-25 11:11                 ` Mark Brown
2012-09-25 11:24                   ` Peter Ujfalusi
2012-09-25 11:43                     ` Linus Walleij
2012-09-25 11:43                     ` Mark Brown
2012-09-25 11:56                       ` Linus Walleij
2012-09-25 12:24                         ` Mark Brown
2012-09-25 17:00                     ` Stephen Warren
2012-09-24 15:41               ` Stephen Warren [this message]
2012-09-25 11:22                 ` Mark Brown
2012-09-24  8:34       ` Linus Walleij
2012-09-24 10:23         ` Mark Brown
2012-09-24 15:38         ` Stephen Warren
2012-09-22 15:18     ` Mark Brown

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=50607F22.4070903@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linus.walleij@linaro.org \
    --cc=lrg@ti.com \
    --cc=peter.ujfalusi@ti.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.