It's working for me also, do you know how to change the volume ? Micka,
Le mar. 12 janv. 2016 à 15:13, Bruce Glazier <[email protected]> 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, <[email protected]> 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 <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Mon, Jan 11, 2016 at 9:54 AM, <[email protected]> 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 >> [email protected]. >> > >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
