It's working for me also, do you know how to change the volume ?
Micka,
Le mar. 12 janv. 2016 à 15:13, Bruce Glazier <bglazie...@gmail.com> a
écrit :
> You are a genius, it really worked! I could NOT get past this roadblock.
> Thank you!
>
> 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.
>
--
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.
