> -----Original Message-----
> From: Shawn Guo <shawn...@kernel.org>
> Sent: Wednesday, June 12, 2019 7:45 PM
> To: Leo Li <leoyang...@nxp.com>
> Cc: Madalin-cristian Bucur <madalin.bu...@nxp.com>; Rob Herring
> <robh...@kernel.org>; Aisheng Dong <aisheng.d...@nxp.com>; Vinod Koul
> <vk...@kernel.org>; Grant Likely <grant.lik...@arm.com>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-arm-
> ker...@lists.infradead.org>; lkml <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH] arm64: defconfig: Enable FSL_EDMA driver
>
> On Wed, Jun 12, 2019 at 03:01:29PM -0500, Li Yang wrote:
> > On Thu, May 9, 2019 at 10:15 PM Shawn Guo <shawn...@kernel.org>
> wrote:
> > >
> > > On Mon, Apr 22, 2019 at 01:30:56PM -0500, Li Yang wrote:
> > > > Enables the FSL EDMA driver by default. This also works around an
> > > > issue that imx-i2c driver keeps deferring the probe because of the
> > > > DMA is not ready. And currently the DMA engine framework can not
> > > > correctly tell if the DMA channels will truly become available
> > > > later (it will never be available if the DMA driver is not enabled).
> > > >
> > > > This will cause indefinite messages like below:
> > > > [ 3.335829] imx-i2c 2180000.i2c: can't get pinctrl, bus recovery not
> supported
> > > > [ 3.344455] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000
> uOhm)
> > > > [ 3.350917] lm90 0-004c: 0-004c supply vcc not found, using dummy
> regulator
> > > > [ 3.362089] imx-i2c 2180000.i2c: can't get pinctrl, bus recovery not
> supported
> > > > [ 3.370741] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000
> uOhm)
> > > > [ 3.377205] lm90 0-004c: 0-004c supply vcc not found, using dummy
> regulator
> > > > [ 3.388455] imx-i2c 2180000.i2c: can't get pinctrl, bus recovery not
> supported
> > > > .....
> > > >
> > > > Signed-off-by: Li Yang <leoyang...@nxp.com>
> > >
> > > Applied, thanks.
> >
> > Hi Shawn,
> >
> > Is it possible to move this patch to the -fix series so that it can
> > reach the mainline earlier? It is having a boot failure in mainline
> > for platforms using this device without this workaround.
>
> Why would I2C device deferring cause boot failure on a platform? I'm just
> trying to understand severity of the problem.
Currently the probe of imx-i2c will be retried immediately after it is deferred
when the optional dependency on DMA driver is not met. This will cause an
indefinite loop of probe-defer-probe and keep printing the message as shown in
the commit message.
On a further look into the imx-i2c driver, it looks like the driver need some
fix too. The requesting of dma channel is done at the very late stage of the
imx-i2c probe after registering the i2c adapter. Adding the i2c adapter
triggers the probe of the i2c bus which probably immediately triggers the retry
of deferred probe. This was fine previously as requesting dma channel didn't
trigger a defer. But now it triggers defer after commit
e1ab9a468e3b1636d60cebd0a778461270dde208. We probably should move the
i2c_imx_dma_request() to the beginning of the probe as it is considered as a
dependency now.
Regards,
Leo
