Re: [PATCH v2 3/9] tty: serial: fsl_lpuart: handle EPROBE_DEFER for DMA

From: Michael Walle <michael@walle.cc>
To: Rob Herring <robh+dt@kernel.org>
Cc: Li Yang <leoyang.li@nxp.com>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Shawn Guo <shawnguo@kernel.org>, Jiri Slaby <jslaby@suse.com>,
	Peng Fan <peng.fan@nxp.com>,
	Vabhav Sharma <vabhav.sharma@nxp.com>
Subject: Re: [PATCH v2 3/9] tty: serial: fsl_lpuart: handle EPROBE_DEFER for DMA
Date: Fri, 28 Feb 2020 22:50:51 +0100	[thread overview]
Message-ID: <24b9a657a65f75a4f4f10baa17561451@walle.cc> (raw)
In-Reply-To: <639a1df72fbeda77436b282a99f17995@walle.cc>

Am 2020-02-28 12:46, schrieb Michael Walle:
> Hi Rob, Hi Leo,
> 
> Am 2020-02-28 00:03, schrieb Rob Herring:
>> On Thu, Feb 27, 2020 at 4:49 PM Li Yang <leoyang.li@nxp.com> wrote:
>>> 
>>> On Thu, Feb 27, 2020 at 4:35 PM Rob Herring <robh+dt@kernel.org> 
>>> wrote:
>>> >
>>> > On Fri, Feb 21, 2020 at 11:48 AM Michael Walle <michael@walle.cc> wrote:
>>> > >
>>> > > The DMA channel might not be available at the first probe time. This is
>>> > > esp. the case if the DMA controller has an IOMMU mapping.
>>> > >
>>> > > Use the new dma_request_chan() API and handle EPROBE_DEFER errors. Also
>>> > > reorder the code a bit, so that we don't prepare the whole UART just to
>>> > > determine that the DMA channel is not ready yet and we have to undo all
>>> > > the stuff. Try to map the DMA channels earlier.
>>> >
>>> > Changing this means you never probe successfully if you boot a kernel
>>> > with the DMA driver disabled (or it's IOMMU disabled). Some other
>>> > drivers request DMA in open() and can work either way.
> 
> Oh, I see.
> 
>>> We got this exact issue previously with another driver.  When the
> 
> What driver is it? I've been working on the i2c-mxs.c driver which has

whoops, i2c-imx.c, not i2c-mxs.c

-michael

> the same problem. Ie. its not working with DMA when the IOMMU is 
> enabled.
> Now that I've learned that dma_request_chan() will return EPROBE_DEFER
> if the actual DMA driver is not available, I don't think there is any
> trick like this there. There is no function which would be called late
> except you'd do something like on the first master_xfer() try to 
> request
> the DMA channels. But I don't think that would be the way to go.
> 
> -michael
> 
>>> required DMA driver is disabled, the DMA framework cannot figure out
>>> this situation and keeps returning EPROBE_DEFER.  I'm wondering if we
>>> should update the DMA framework to use your deferred probe timeout
>>> mechanism.  Is it still only used for debug purpose?
>> 
>> It's undergoing some rework ATM to not just be for debug. However,
>> it's not really going to help you if you care about the console
>> because waiting for the timeout will be too late to register the
>> console.