Messages in this thread | | | Date | Fri, 28 Feb 2020 22:50:51 +0100 | From | Michael Walle <> | Subject | Re: [PATCH v2 3/9] tty: serial: fsl_lpuart: handle EPROBE_DEFER for DMA |
| |
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.
| |