am33xx-overlay-edma-fix.dtsi causes problems with mcasp

GoogleGroups
1

The following .dtsi file:

  dtb-rebuilder/src/arm/am33xx-overlay-edma-fix.dtsi at 4.4.x · RobertCNelson/dtb-rebuilder · GitHub

causes the mcasp davinci audio driver to load during boot,
and prevents overlays (like BB-BONE-AUDI-02) from setting
audio parameters. The result is hardware configuration errors
when trying to use ALSA commands:

Unable to set hw params for playback: Invalid argument
Setting of hwparams failed: Invalid argument

That .dtsi file enables spi0/1, and mcasp0/1. By removing
the mcasp0/1 entries, the BB-BONE-AUDI-02 overlay is able
to enable mcasp while configuring it properly, and allowing
the driver to work.

It's not clear to me how that file is an eDMA fix, nor why
it enables mcasp.

Here's the thread on the alsa-devel list where we figured it
out:

http://mailman.alsa-project.org/pipermail/alsa-devel/2016-April/107061.html

Is the best way to report this problem here on the list like
this, or to open an issue on github/dtb-rebuilder?

Note that this is all with kernel 4.4.7-bone-rt-r9. Not sure
to how many other versions it applies.

Thanks!

2

Robert spoke about this on Jan 12, 2016:

it's a big workaround hack, the bug seems to be in edma_probe:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/edma.c#n2118

On first load of the board *.dtb, edma_probe is called and all the 'active' nodes get an edma slot, while the in-active nodes get disabled.. (power savings? for am335x, every ip has it's own edma channel, but maybe some parts need sharing?)

So, next when we load an overlay, for uart0, uart1, uart2, spi0, spi1, mcasp0, and mcasp1 the edma channel would be disabled, (they still load, but every transfer fails when it switches from pio-dma spi=160 bytes) as we don't re-call edma_probe to enable them*..

* that seems like the better fix.

Regards,
John

3

It was part of this discussion in which you participated.

https://groups.google.com/forum/#!msg/beagleboard/TMGEWjBLsok/ALk4h_jrCwAJ

Regards,
John

4

It was part of this discussion in which you participated.

Redirecting to Google Groups

Ooof, months ago. I can barely remember what I did last week. :wink:

In any case, I didn't put it together back then. This is the first time I've gotten a 4+ kernel to do everything I need (e.g. pruss, adc, and audio). It's still not all quite there, but I'm much farther along than I was. I may have also missed the follow-on posts on that thread.

In any case, it doesn't seem to allow audio to be overlayed when enabled in the boot DTB.

Robert spoke about this on Jan 12, 2016:

it's a big workaround hack, the bug seems to be in edma_probe:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/edma.c#n2118

On first load of the board *.dtb, edma_probe is called and all the 'active' nodes get an edma slot, while the in-active nodes get disabled.. (power savings? for am335x, every ip has it's own edma channel, but maybe some parts need sharing?)

So, next when we load an overlay, for uart0, uart1, uart2, spi0, spi1, mcasp0, and mcasp1 the edma channel would be disabled, (they still load, but every transfer fails when it switches from pio-dma spi=160 bytes) as we don't re-call edma_probe to enable them*..

* that seems like the better fix.

I think I understand what's going on. However, I'm not seeing the result of failed transfers. Audio actually works for me now.

In any case, for my primary application, I can make a single comprehensive DTB to load at boot, so I should be able to get edma and audio, right? I'll try this after I sleep and wake up.

Also, those discussions were for 4.1.x. Does all that still hold true for 4.4.x?

Thanks,
Rick

5

It was part of this discussion in which you participated.

Redirecting to Google Groups

Ooof, months ago. I can barely remember what I did last week. :wink:

In any case, I didn't put it together back then. This is the first time I've gotten a 4+ kernel to do everything I need (e.g. pruss, adc, and audio). It's still not all quite there, but I'm much farther along than I was. I may have also missed the follow-on posts on that thread.

In any case, it doesn't seem to allow audio to be overlayed when enabled in the boot DTB.

Robert spoke about this on Jan 12, 2016:

it's a big workaround hack, the bug seems to be in edma_probe:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/edma.c#n2118

On first load of the board *.dtb, edma_probe is called and all the 'active' nodes get an edma slot, while the in-active nodes get disabled.. (power savings? for am335x, every ip has it's own edma channel, but maybe some parts need sharing?)

So, next when we load an overlay, for uart0, uart1, uart2, spi0, spi1, mcasp0, and mcasp1 the edma channel would be disabled, (they still load, but every transfer fails when it switches from pio-dma spi=160 bytes) as we don't re-call edma_probe to enable them*..

* that seems like the better fix.

I think I understand what's going on. However, I'm not seeing the result of failed transfers. Audio actually works for me now.

In any case, for my primary application, I can make a single comprehensive DTB to load at boot, so I should be able to get edma and audio, right? I'll try this after I sleep and wake up.

Also, those discussions were for 4.1.x. Does all that still hold true for 4.4.x?

My guess if Robert still has the workarround applied, then it applies to 4.4.x as well. Best to ask Robert about this.

Regards,
John

6

Correct, don't add [#include "am33xx-overlay-edma-fix.dtsi
<https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi>"]
to the base dtb if your going to load the audio cape.

I didn't in the example...

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-audio.dts

But i didn't spell out why, but from your testing, you see why now. :wink:

Regards,

7

Correct, don’t add [#include “am33xx-overlay-edma-fix.dtsi”**] to the base dtb if your going to load the audio cape.

I didn’t in the example…

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-audio.dts

But i didn’t spell out why, but from your testing, you see why now. :wink:

Regards,

Robert,

Does that mean the old bug will reinsert its self if that include file is omitted ?

We’re in a similar boat here using McASP( audio codec ) with UART, SPI, and I2C all at once too . . .

8

When you are using the audio cape:

These nodes break it:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am33xx-overlay-edma-fix.dtsi#L19-L25

You can include the spi nodes, or just put everything in your main dtb...
The bug occurs when edma devices are enabled in the dtbo overlay.

Regards,

9

When you are using the audio cape:

These nodes break it:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am33xx-overlay-edma-fix.dtsi#L19-L25

You can include the spi nodes, or just put everything in your main dtb… The bug occurs when edma devices are enabled in the dtbo overlay.

Regards,

dtbo overlay as in main board file, through an include ?

10

Robert, Ok, I’m still not sure what you mean by dtbo, however simply moving those device enable lines into a device tree file that is loaded manually after boot would fix the problem ? Seriously ?

Thanks :slight_smile:

11

Correct, the issue occurs on spi, if you enable spi in only the overlay
object.

Regards,

12

Correct, the issue occurs on spi, if you enable spi in only the overlay object.

Regards,

Awesome, easy fix then. Thanks again Robert :slight_smile: