omap_hsmmc RX DMA errors

omap_hsmmc RX DMA errors

[Adam Ford]

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 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.  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.

thanks

adam

Re: omap_hsmmc RX DMA errors

[H. Nikolaus Schaller]

Hi Adam,
happy new year!

> Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@gmail.com>:
> 
> 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.

Best regards,
Nikolaus

Re: omap_hsmmc RX DMA errors

[Adam Ford]

On Thu, Jan 5, 2023 at 12:17 PM H. Nikolaus Schaller <hns@messlink.de> wrote:
>
> Hi Adam,
> happy new year!
>
> Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@gmail.com>:
>
> 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
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
>

Re: omap_hsmmc RX DMA errors

[Adam Ford]

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

Happy new year to you too!

> >
> > Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@gmail.com>:
> >
> > 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
> >

Re: omap_hsmmc RX DMA errors

[Tony Lindgren]

Hi,

* Adam Ford <aford173@gmail.com> [230105 19:20]:
> On Thu, Jan 5, 2023 at 1:08 PM Adam Ford <aford173@gmail.com> wrote:
> > On Thu, Jan 5, 2023 at 12:17 PM H. Nikolaus Schaller <hns@messlink.de> wrote:
> > > Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@gmail.com>:
> > >
> > > 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.

Things should be ready to flip the remaining SoCs to use sdhci so we
should do that.

The only thing I'm aware of is that sdhci will try to keep probing
also mmc instances that are not wired. So some board specific dts files
may need to set some mmc instances with status = "disabled". Or maybe
the sdhci driver can be configured to stop trying after some timeout.

Regards,

Tony

Re: omap_hsmmc RX DMA errors

[Adam Ford]

On Sun, Jan 8, 2023 at 11:58 PM Tony Lindgren <tony@atomide.com> wrote:
>
> Hi,
>
> * Adam Ford <aford173@gmail.com> [230105 19:20]:
> > On Thu, Jan 5, 2023 at 1:08 PM Adam Ford <aford173@gmail.com> wrote:
> > > On Thu, Jan 5, 2023 at 12:17 PM H. Nikolaus Schaller <hns@messlink.de> wrote:
> > > > Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@gmail.com>:
> > > >
> > > > 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.
>
> Things should be ready to flip the remaining SoCs to use sdhci so we
> should do that.
>
> The only thing I'm aware of is that sdhci will try to keep probing
> also mmc instances that are not wired. So some board specific dts files
> may need to set some mmc instances with status = "disabled". Or maybe
> the sdhci driver can be configured to stop trying after some timeout.
>
> Regards,
>
> Tony

Re: omap_hsmmc RX DMA errors

[Adam Ford]

On Sun, Jan 8, 2023 at 11:58 PM Tony Lindgren <tony@atomide.com> wrote:
>
> Hi,
>
> * Adam Ford <aford173@gmail.com> [230105 19:20]:
> > On Thu, Jan 5, 2023 at 1:08 PM Adam Ford <aford173@gmail.com> wrote:
> > > On Thu, Jan 5, 2023 at 12:17 PM H. Nikolaus Schaller <hns@messlink.de> wrote:
> > > > Am 05.01.2023 um 18:54 schrieb Adam Ford <aford173@gmail.com>:
> > > >
> > > > 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.
>
> Things should be ready to flip the remaining SoCs to use sdhci so we
> should do that.

Do you want me to push a patch?  It might bring more clout if it comes
from you, but I don't mind. If so, how do we handle the backwards
compatibility stuff with older device trees?
>
> The only thing I'm aware of is that sdhci will try to keep probing
> also mmc instances that are not wired. So some board specific dts files
> may need to set some mmc instances with status = "disabled". Or maybe
> the sdhci driver can be configured to stop trying after some timeout.

I have not seen this as being an issue on the AM35 I have.

adam
>
> Regards,
>
> Tony

Re: omap_hsmmc RX DMA errors

[Tony Lindgren]

* Adam Ford <aford173@gmail.com> [230115 18:55]:
> On Sun, Jan 8, 2023 at 11:58 PM Tony Lindgren <tony@atomide.com> wrote:
> > Things should be ready to flip the remaining SoCs to use sdhci so we
> > should do that.
> 
> Do you want me to push a patch?  It might bring more clout if it comes
> from you, but I don't mind. If so, how do we handle the backwards
> compatibility stuff with older device trees?

Sure please go ahead and post a patch for omap3.dtsi. It's best to do it
one SoC type at a time. Older dtb files will work as long as there is
the old mmc driver in place. But considering we don't even have complete
data in the dts files in general, I would not worry about supporting older
dtb files. In most cases we can add boot timer warnings if needed.

Regards,

Tony