[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151023054455.GU5257@xsjsorenbubuntu>
Date: Thu, 22 Oct 2015 22:44:55 -0700
From: Sören Brinkmann <soren.brinkmann@...inx.com>
To: Mike Looijmans <mike.looijmans@...ic.nl>
CC: <git@...inx.com>, <linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pinctrl-zynq: Initialize early
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@...ic.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@...q:~# dmesg | grep -i defer
> > [ 0.097021] zynq-gpio e000a000.gpio: could not find pctldev for node /amba/slcr@...00000/pinctrl@.../gpio0-default, deferring probe
> > root@...q:~#
> >
> >If you have a case this patch improves things though, feel free to add my
> >Tested-by: Sören Brinkmann <soren.brinkmann@...inx.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
--
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