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

89 views
Skip to first unread message

Rick Mann

unread,
Apr 19, 2016, 5:42:06 AM4/19/16
to Beagle Board
The following .dtsi file:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi

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!

--
Rick Mann
rm...@latencyzero.com


John Syne

unread,
Apr 19, 2016, 6:21:21 AM4/19/16
to beagl...@googlegroups.com
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
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/77DEEFDD-F2AC-494B-A8AC-6BC54F19EEC3%40latencyzero.com.
> For more options, visit https://groups.google.com/d/optout.

John Syne

unread,
Apr 19, 2016, 6:29:13 AM4/19/16
to beagl...@googlegroups.com
It was part of this discussion in which you participated.

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


Regards,
John




> On Apr 19, 2016, at 2:41 AM, Rick Mann <rm...@latencyzero.com> wrote:
>

Rick Mann

unread,
Apr 19, 2016, 6:44:27 AM4/19/16
to beagl...@googlegroups.com

> On Apr 19, 2016, at 03:29 , John Syne <john...@gmail.com> wrote:
>
> It was part of this discussion in which you participated.
>
> https://groups.google.com/forum/#!msg/beagleboard/TMGEWjBLsok/ALk4h_jrCwAJ

Ooof, months ago. I can barely remember what I did last week. ;-)

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
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/55916E28-05ED-4C01-89A5-5C6D30741FA9%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.


--
Rick Mann
rm...@latencyzero.com


John Syne

unread,
Apr 19, 2016, 7:16:22 AM4/19/16
to beagl...@googlegroups.com

> On Apr 19, 2016, at 3:44 AM, Rick Mann <rm...@latencyzero.com> wrote:
>
>>
>> On Apr 19, 2016, at 03:29 , John Syne <john...@gmail.com> wrote:
>>
>> It was part of this discussion in which you participated.
>>
>> https://groups.google.com/forum/#!msg/beagleboard/TMGEWjBLsok/ALk4h_jrCwAJ
>
> Ooof, months ago. I can barely remember what I did last week. ;-)
>
> 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
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/FB865EB5-76E4-434E-8217-BC9FB39E0E35%40latencyzero.com.

Robert Nelson

unread,
Apr 19, 2016, 8:04:21 AM4/19/16
to Beagle Board
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...



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

Regards,

--
Robert Nelson
https://rcn-ee.com/

William Hermans

unread,
Apr 19, 2016, 2:29:09 PM4/19/16
to beagl...@googlegroups.com
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...



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

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYipqhzvXgY_o7rmsN8tXAT%3Db7rjvzWn5JsQxCxBxFBX5w%40mail.gmail.com.

Robert Nelson

unread,
Apr 19, 2016, 2:33:50 PM4/19/16
to Beagle Board
On Tue, Apr 19, 2016 at 1:29 PM, William Hermans <yyr...@gmail.com> wrote:
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...



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

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


When you are using the audio cape:

These nodes break it:


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,

William Hermans

unread,
Apr 19, 2016, 2:37:38 PM4/19/16
to beagl...@googlegroups.com
When you are using the audio cape:

These nodes break it:


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 ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjU_Z9gSQUUh8gMxrJAown38ecjUxOU__Oj9zPFVADFow%40mail.gmail.com.

William Hermans

unread,
Apr 19, 2016, 2:45:32 PM4/19/16
to beagl...@googlegroups.com
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 :)

Robert Nelson

unread,
Apr 19, 2016, 2:52:08 PM4/19/16
to Beagle Board
On Tue, Apr 19, 2016 at 1:45 PM, William Hermans <yyr...@gmail.com> wrote:
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 :)

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

Regards,

William Hermans

unread,
Apr 19, 2016, 3:01:15 PM4/19/16
to beagl...@googlegroups.com
Correct, the issue occurs on spi, if you enable spi in only the overlay object.

Regards,
Awesome, easy fix then. Thanks again Robert :)


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiY_2zY6EJFkN-uY00stgkqX5GZjsQ9zKYm7_nFd8Rx8g%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages