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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux