From: soren.brinkmann@xilinx.com (Sören Brinkmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl-zynq: Initialize early
Date: Thu, 22 Oct 2015 22:44:55 -0700 [thread overview]
Message-ID: <20151023054455.GU5257@xsjsorenbubuntu> (raw)
In-Reply-To: <5629C62D.8030804@topic.nl>
On Fri, 2015-10-23 at 07:31AM +0200, Mike Looijmans wrote:
> On 22-10-15 18:07, S?ren Brinkmann wrote:
> >Hi Mike,
> >
> >On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote:
> >>Supplying pinmux configuration for e.g. gpio pins leads to deferred
> >>probes because the pinctrl device is probed much later than gpio.
> >>Move the init call to a much earlier stage so it probes before the
> >>devices that may need it.
> >>
> >>Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
> >
> >in general, the change should be OK, but neither on zc702 nor zc706 do I
> >see a difference in respect to deferred probes. With and without the
> >patch I see:
> > root at zynq:~# dmesg | grep -i defer
> > [ 0.097021] zynq-gpio e000a000.gpio: could not find pctldev for node /amba/slcr at f8000000/pinctrl at 700/gpio0-default, deferring probe
> > root at zynq:~#
> >
> >If you have a case this patch improves things though, feel free to add my
> >Tested-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> >
>
> On the Florida boards there are i2c controlled clocks, power supplies and
> reset signals. Replacing the Cadence I2C controller with a GPIO-bitbang
> controller solved the I2C problems but caused a storm of dozens of deferred
> probes because of the pinmux driver arriving even after the first probe
> attempt of the i2c bus driver. Moving the pinmux driver to an earlier stage
> solved that problem neatly, now the "zynq-pinctrl 700.pinctrl: zynq pinctrl
> initialized" message appears after the OCM driver.
OK, makes sense. Thanks for the background.
> Judging from your comment the GPIO driver still probes earlier (I don't have
> any GPIO-only pinmuxes yet), so maybe we should amend the patch to probe
> even earlier. The pinmux driver doesn't depend on anything, so it can
> potentially probe very early. What do you think?
I'm pretty neutral on this one :) Hasn't the probe deferral mechanism
been introduced to avoid having to create ordering through the initcall
stages? But I agree, having the probe deferral notices is not particularly
pretty. So, I'd definitely not oppose changing this.
Though, there is one dependency on the SLCR regmap, but that is initialized
fairly early.
S?ren
next prev parent reply other threads:[~2015-10-23 5:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-22 11:30 [PATCH] pinctrl-zynq: Initialize early Mike Looijmans
2015-10-22 16:07 ` Sören Brinkmann
2015-10-23 5:31 ` Mike Looijmans
2015-10-23 5:43 ` Mike Looijmans
2015-10-23 5:48 ` Sören Brinkmann
2015-10-23 5:44 ` Sören Brinkmann [this message]
2015-10-29 9:00 ` Michal Simek
2015-10-30 9:42 ` Linus Walleij
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=20151023054455.GU5257@xsjsorenbubuntu \
--to=soren.brinkmann@xilinx.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).