I am really eager to try this fix but I have to clarify one thing. Not that
it makes a difference, but I am working with mcasp1 and I have a
&mcasp1 {
status = "okay";
};
in my overlay but you are saying this just needs to be added
to am335x-boneblack.dts instead?! I will have spent too much time for it to
be that easy, not that I'm complaining :D I will try this.
On Mon, Jan 11, 2016 at 2:18 PM, <kander...@amtelco.com> wrote:
> I don't have a problem with enabling the dma's in the
> <device>-overlay.dtb's. I just didn't know if it was appropriate to do so
> or if it was the best approach. For 4.1.x it may very well be the best
> solution.
>
> On Monday, January 11, 2016 at 12:47:03 PM UTC-6, RobertCNelson wrote:
>>
>>
>>
>> On Mon, Jan 11, 2016 at 12:45 PM, Robert Nelson <robert...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 11, 2016 at 9:54 AM, <kand...@amtelco.com> wrote:
>>>
>>>> It looks to me like the problem came about because the function
>>>> prepare_unused_channel_list() in arch/arm/common/edma.c for 4.1 kernels was
>>>> modified to use the device tree for determining which dma channels to
>>>> enable (by clearing appropriate edma_unused bits in the edma struct).
>>>> However, this function is called before processing of the cape device tree
>>>> overlays begins. Since the base dtbo files do not have appropriate
>>>> references to the McASPs, their dmas are not enabled. When the cape is
>>>> loaded, it appears that everything works, but since dma is not enabled, the
>>>> required dma transfers do not occur. Hence the underrun errors for play
>>>> and overrun errors for record.
>>>>
>>>> A simple workaround that worked for me was to add the following to
>>>> arch/arm/boot/dts/am335x-boneblack.dts:
>>>>
>>>> &mcasp0 {
>>>> status = "okay";
>>>> };
>>>>
>>>> This may not be the best solution. It seems to me that a better
>>>> solution would be to modify the kernel so that if a device that uses DMA is
>>>> enabled by a device tree overlay, the kernel would enable the DMA when it
>>>> parses the overlay. However, I have practically no experience or knowledge
>>>> of Linux at the kernel level, so may be completely off base.
>>>>
>>>
>>> Nice find! (this explains why spidev0/spidev1 don't work, without my
>>> dma disable hack)
>>>
>>> For v4.1.x, i wonder if we just enable everything like you did for
>>> mcasp0 by default.. in the <device>-overlay.dtb's..
>>>
>>
>> btw, this should be safe, as all the channels seem to not overlap:
>>
>>
>> http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=blob;f=arch/arm/boot/dts/am33xx.dtsi;h=a0fbe071299c53c9bf1c6627c29326bea0f71fdf;hb=refs/heads/ti-linux-4.1.y
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/TMGEWjBLsok/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
