Subject: [PATCH] pinctrl-zynq: Initialize early

From: [email-masked] (Sören Brinkmann)
Date: Thu, 22 Oct 2015 22:44:55 -0700

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 <[email-masked]>
> >
> >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 <[email-masked]>
> >
> 
> 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