Re: [beagleboard] 4.1 repo

It's working for me also, do you know how to change the volume ? Micka, Le mar. 12 janv. 2016 à 15:13, Bruce Glazier 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, wrote: > >> I don't have a problem with en

Re: [beagleboard] 4.1 repo

Robert, The Kernel side *dts change is : clk_mcasp0_fixed: clk_mcasp0_fixed { #clock-cells = <0>; compatible = "fixed-clock"; clock-frequency = <24576000>; }; clk_mcasp0: clk_mcasp0 { #clock-cells = <0>;

Re: [beagleboard] 4.1 repo

On Tue, Mar 8, 2016 at 12:21 AM, wrote: > Everyone, > > I'm a noob and trying to get the BBB Audio Cape Rev B working. Is there an > update at all coming from BB on this? https://github.com/beagleboard/bb.org-overlays/commit/419c160cb30f40230edea0460a9776eed1f7779f I have a kernel side *dts ch

Re: [beagleboard] 4.1 repo

Everyone, I'm a noob and trying to get the BBB Audio Cape Rev B working. Is there an update at all coming from BB on this? On Tuesday, January 12, 2016 at 7:53:27 PM UTC-6, RobertCNelson wrote: > > > > On Tue, Jan 12, 2016 at 5:57 PM, Bruce Glazier > wrote: > >> Thanks Robert, glad it could ge

Re: [beagleboard] 4.1 repo

On Tue, Jan 12, 2016 at 5:57 PM, Bruce Glazier wrote: > Thanks Robert, glad it could get resolved. > It's still a hack, we need to find a way to call edma subsystem and re-enable those channels for the overlay situation.. Right now it'll burn a little more power.. So users looking to save ever

Re: [beagleboard] 4.1 repo

Thanks Robert, glad it could get resolved. On Tue, Jan 12, 2016 at 11:40 AM, Robert Nelson wrote: > > > On Tue, Jan 12, 2016 at 7:35 AM, Bruce Glazier > wrote: > >> 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

Re: [beagleboard] 4.1 repo

On Tue, Jan 12, 2016 at 7:35 AM, Bruce Glazier wrote: > 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

Re: [beagleboard] 4.1 repo

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

Re: [beagleboard] 4.1 repo

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, wrote: > I don't have a problem with enabling the dma's in the > -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

Re: [beagleboard] 4.1 repo

On Mon, Jan 11, 2016 at 1:18 PM, wrote: > I don't have a problem with enabling the dma's in the > -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. > Just pushed this as default: https://githu

Re: [beagleboard] 4.1 repo

I don't have a problem with enabling the dma's in the -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 1

Re: [beagleboard] 4.1 repo

On Mon, Jan 11, 2016 at 12:45 PM, Robert Nelson wrote: > > > On Mon, Jan 11, 2016 at 9:54 AM, 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 determin

Re: [beagleboard] 4.1 repo

On Mon, Jan 11, 2016 at 9:54 AM, 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_un

Re: [beagleboard] 4.1 repo

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

Re: [beagleboard] 4.1 repo

I'm getting an overrun error at this point and not an underflow. I am also measuring 24MHz on MCLK regardless of what I specify. These clocks are defined within the default am335x-boneblack.dtb. I pay special attention to the clk_mcasp0 as it specified the gpio-gate-clock which uses external osc

Re: [beagleboard] 4.1 repo

On Tue, Dec 8, 2015 at 7:59 AM, wrote: > Robert, > Any updates on this? I just moved from r21 to r35 and created the DTC for my > TLV320AIC3104 as specified here: > https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts > I can see and configure the device

Re: [beagleboard] 4.1 repo

Robert, Any updates on this? I just moved from r21 to r35 and created the DTC for my TLV320AIC3104 as specified here: https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts I can see and configure the device but it chokes on speaker-test; it makes one blip

Re: [beagleboard] 4.1 repo

Thanks Robert and Rick, I'll be appreciate if you inform about the result of your work on audio in 4.x. I did not have any problem with audio in 3.8. and now I'm trying to get the audio to work on uSomiQ Board. uSomIQ AM335x is a BeagleBone Black clone with added more robust SLC NAND flash and

Re: [beagleboard] 4.1 repo

> On Oct 13, 2015, at 05:56 , Robert Nelson wrote: > > On Tue, Oct 13, 2015 at 2:23 AM, hussain ali wrote: >> Thanks for your attention and quick reply. >> I have another problem. >> I want to drive TLV320AIC23 codec to play and record audio. >> I Migrated from kernel 3.8 to 4.1, because kernel

Re: [beagleboard] 4.1 repo

On Tue, Oct 13, 2015 at 2:23 AM, hussain ali wrote: > Thanks for your attention and quick reply. > I have another problem. > I want to drive TLV320AIC23 codec to play and record audio. > I Migrated from kernel 3.8 to 4.1, because kernel 3.8 dose not support this > codec, and > i couldn't add this

Re: [beagleboard] 4.1 repo

Thanks for your attention and quick reply. I have another problem. I want to drive TLV320AIC23 codec to play and record audio. I Migrated from kernel 3.8 to 4.1, because kernel 3.8 dose not support this codec, and i couldn't add this codec to kernel 3.8. What is your idea? Is there any way to add t

Re: [beagleboard] 4.1 repo

> On Sep 30, 2015, at 01:42 , Shadi Abdu-Rahman wrote: > > Also, Rick Mann seems to be having similar problems getting an audio board > working on 4.1 and later. You can read about it here: > https://www.mail-archive.com/beagleboard@googlegroups.com/msg31247.html A better subject line would've

Re: [beagleboard] 4.1 repo

Hi Hussain, I have not been able to solve it. I've reported it to the ALSA developer list as well, but haven't received an answer (yet): http://mailman.alsa-project.org/pipermail/alsa-devel/2015-September/097147.html Also, Rick Mann seems to be having similar problems getting an audio board w

Re: [beagleboard] 4.1 repo

Hi Shadi, I have same problem .( Transmit Buffer Underflow problem) . I'm using kernel 4.1.1 and audio cape rev B ( that uses aic3104 codec) for playing audio. I will be glad if you tell me that you solve the problem or not. Regards, On Wednesday, August 12, 2015 at 7:56:08 PM UTC+3:30, Shad

Re: [beagleboard] 4.1 repo

> But i think audio (output) was still not working.. > > > Hi Robert, Did you get a chance to look at the audio out and whether it's working? Kind Regards, Shadi -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Goog

Re: [beagleboard] 4.1 repo

> > But i think audio (output) was still not working.. > > Now that the reset bug has a workaround, i'll try and look at audio > again today.. > > Ok. I'll wait for your reply then. Thanks for taking the time. Much appreciated. Best, Shadi -- For more options, visit http://beagleboard.o

Re: [beagleboard] 4.1 repo

On Mon, Aug 10, 2015 at 9:05 AM, Shadi Abdu-Rahman wrote: > >> >> there are some issues with the audio rev b, but i can't find that >> board for sale anywhere anymore. (i have the rev a) >> > > Hi Robert, > > Could you elaborate on the issues you're seeing with the Audio Cape? I'm > having trouble

Re: [beagleboard] 4.1 repo

> > there are some issues with the audio rev b, but i can't find that > board for sale anywhere anymore. (i have the rev a) > > Hi Robert, Could you elaborate on the issues you're seeing with the Audio Cape? I'm having trouble using the audio system as described here

Re: [beagleboard] 4.1 repo

On Wed, Jul 8, 2015 at 2:02 PM, William Hermans wrote: > Hey Robert, > > Is there a list of things somewhere that do not work currently ? Personally, > I want to make the leap, but I would not enjoy spending a lot of time > messing with 4.1.x only to find there is / are problem(s) without any eas

Re: [beagleboard] 4.1 repo

Hey Robert, Is there a list of things somewhere that do not work currently ? Personally, I want to make the leap, but I would not enjoy spending a lot of time messing with 4.1.x only to find there is / are problem(s) without any easy work around. Also, how is capmgr coming along ? On Wed, Jul 8,

[beagleboard] 4.1 repo

Hey Guys, Just a heads up, the 4.1 branch: https://github.com/beagleboard/linux/tree/4.1 Is now based on ti's 4.1.x-ti release. (same thing we did with 3.14.x) http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y (this really doesn't change any