Re: omap_hsmmc RX DMA errors

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

 



On Thu, Jan 5, 2023 at 1:08 PM Adam Ford <aford173@xxxxxxxxx> wrote:
>
> On Thu, Jan 5, 2023 at 12:17 PM H. Nikolaus Schaller <hns@xxxxxxxxxxx> wrote:
> >
> > Hi Adam,
> > happy new year!

Happy new year to you too!

> >
> > Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@xxxxxxxxx>:
> >
> > I am trying to test the 6.0 kernel on an AM3517-EVM, but I am seeing
> > some DMA RX errors:
> >
> > [    1.730682] omap_hsmmc 4809c000.mmc: RX DMA channel request failed
> > [    1.738403] omap_hsmmc 480b4000.mmc: RX DMA channel request failed
> >
> >
> > I think I remember there was an issue that more an more devices were switched active by default
> > to use DMA until the 32 channels of an OMAP are filled up. Which subsystem is hit by this
> > limitation may vary and depends if they are properly disabled on the specific board DTS.
> >
> > See: https://git.goldelico.com/?p=letux-kernel.git;a=commit;h=048b9bc86b9a080258460c4ab2989660233c4c8c
> >
> > (I must admit that it is not yet upstreamed).
> >
> > I tried changing the omap3.dtsi file to use the newer sdhci-omap
> > controller instead of the older hsmmc driver since it has support for
> > the omap3.
> >
> >
> > This would then only be a workaround but not a solution.
> >
> >  That seemed to fix the issue:
> >
> > [    2.141967] omap-dma-engine 48056000.dma-controller: OMAP DMA engine driver
> > [    2.183074] mmc1: SDHCI controller on 480b4000.mmc [480b4000.mmc]
> > using External DMA
> > [    2.184631] mmc0: SDHCI controller on 4809c000.mmc [4809c000.mmc]
> > using External DMA
> >
> > Would there be an objection if I migrate the OMAP3.dtsi file to the
> > newer driver?  I wasn't sure if there was a reason this family was
> > being held back from the newer driver.
> >
> >
> > AFAIR Tony wanted to retire the older driver anyways.
>
> That was my impression and it appears that the AM35x has already

correction AM335x (not AM35x)

> migrated to it.  I wasn't sure what was holding us back.  In theory,
> we could add the compatible flags to the new driver and mark them as
> deprecated so the new driver would work with older device trees if
> there was push-back on changing the device trees.  I know sometimes
> there are concerns about using older device trees and the interaction
> with the compatible flags make it a bit more complex.
>
> adam
>
> >
> > Best regards,
> > Nikolaus
> >



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux