Date:	Sun, 11 Nov 2012 13:32:35 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...retlab.ca>
Cc:	Kevin Hilman <khilman@...prootsystems.com>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Felipe Balbi <balbi@...com>, Benoit Cousson <b-cousson@...com>,
	Sourav Poddar <sourav.poddar@...com>, tony@...mide.com,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org, linux-input@...r.kernel.org,
	Stephen Warren <swarren@...dotorg.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Thu, Nov 1, 2012 at 3:01 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
> <broonie@...nsource.wolfsonmicro.com> wrote:
>> On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
>
>> For the pin hogging I'd actually been thinking separately that we should
>> just have the device core do a devm_pinctrl_get_set_default() prior to
>> probing the device and store the result in the struct device.  That
>> would immediately remove almost all of the current pinctrl users, users
>> that do need to do things with the data or check the result can then
>> pick up the pinctrl pointer from the device struct.
>
> I never thought of that. This sounds like it would work.

So I've looked closer at this.

> And the good thing is that this is a clean cut so we
> will centralized code without having to decide right now
> how to handle the pm idle/sleep cases.
>
> Talking here with Kevin Hilman on my left and Grant
> Likely on my right (they're physically here) there is some
> worry about stashing stuff into struct device.
>
> What if I retrieve this in the pinctrl subsystem using
> bus notifiers and then expose the struct pinctrl * to
> the clients by using pinctrl_get() and when you get
> such a handle in your probe() you know that the
> pinctrl subsystem has already fetched the handle and
> set it to "default" at that point?

I have sent out an RFC for this approach. It actually
works quite well on the U300 for example.

However as stated in the patch we run into another
problem: what if the pinctrl provider returns
-EDEFER_PROBE?

(The same will be true for clocks, regulators etc I
guess...)

If I use notifiers like this, I cannot return -EPROBE_DEFER
to the core. :-(

The PM domains seem to be built on the notification
mechanism as well (AFAICT), so it will not allow drivers to
defer their probes, as it is an optional layer after all.

As a matter of fact it seems that there is an implicit
assumption in PM domains that the resources that
are taken there cannot defer any probing, so they are
assumed to always be present. Is this correct?
If so, any resources that may be deferred (such as
pinctrl) can never be handled in PM domains. Only
simple stuff that the SoC controls directly e.g through
some fixed register pokes to voltage domains.

So then the only option that remains to centralize
pinctrl handling is indeed to do that in the device core,
before probe(). I need to know Greg's feelings about that.

At the same time this sort of give me the feeling that
we might be doing something wrong. The distributed
nature of deferred probes will become quite elusive
if the deferral request comes from some place
before probe() is even called on the driver.

Please check my RFC patch and tell me above errors
in the above reasoning....

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists