On Fri, Feb 28, 2020 at 3:51 PM Michael Walle <michael@xxxxxxxx> wrote: > > 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@xxxxxxx> wrote: > >>> > >>> On Thu, Feb 27, 2020 at 4:35 PM Rob Herring <robh+dt@xxxxxxxxxx> > >>> wrote: > >>> > > >>> > On Fri, Feb 21, 2020 at 11:48 AM Michael Walle <michael@xxxxxxxx> 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 Ya. Same one. I have added CONFIG_FSL_EDMA into the arm64/defconfig as a workaround. Regards, Leo
