4.1 repo

[Robert Nelson]

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 anything from what we were doing with
4.1.x, it's just that it'll have more patches from ti for
am335x/am57xx parts. ;) )

Regards,

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

[William Hermans]

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 ?

--
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.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Wed, Jul 8, 2015 at 2:02 PM, William Hermans <yyr...@gmail.com> 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 easy
> work around. Also, how is capmgr coming along ?

It really depends on what peripheral you need...

Here's the list of everything working:

https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm

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)

If you need something specific that worked only in 3.8.x, just ask and
we will hack it up and try to fix..

[Shadi Abdu-Rahman]

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, and I'm wondering if it's the same Transmit Buffer Underflow problems you're seeing.

Kind Regards,
Shadi

[Robert Nelson]

Most of the issues are now fixed:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts

https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts

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

[Shadi Abdu-Rahman]

 

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

[Shadi Abdu-Rahman]

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 

[timandem...@gmail.com]

Is there any word on the audio cape rev B working with 4.1 in Ubuntu? I've gotten it working in Debian, but would like to get it working in Ubuntu. I've run into an error where the codec is unable to sync registers 0x1-0x1, -121 (whatever that means).

[timandem...@gmail.com]

When I say I got it working in Debian, I meant to say I got it working on 3.8 in Debian. My mistake.

On Wednesday, July 8, 2015 at 11:16:10 AM UTC-4, RobertCNelson wrote:

[hussain...@gmail.com]

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,

[Shadi Abdu-Rahman]

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 working on 4.1 and later. You can read about it here:
https://www.mail-archive.com/beagl...@googlegroups.com/msg31247.html

I've been meaning to try newer kernels to see if it is fixed, but haven't found the time yet. Will report here if I get around to it.

Best Regards,
Shadi

[Rick Mann]

> On Sep 30, 2015, at 01:42 , Shadi Abdu-Rahman <trans...@gmail.com> 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/beagl...@googlegroups.com/msg31247.html

A better subject line would've been very helpful. I almost deleted this message without seeing it.

Yes, I'm seeing this. I had assumed it was a problem with my board. I finally got ahold of a production Audio Cape, but now I'm expecting to see the same problem.

For me, even though the DTB specifies a 12 MHz MCLK, I'm seeing 24 MHz when I measure with an oscilloscope. It's probable that's causing the buffer underflow issue.

> I've been meaning to try newer kernels to see if it is fixed, but haven't found the time yet. Will report here if I get around to it.

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

[hussain ali]

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 this codec to kernel 3.8?

 It is ideal for me to use kernel 3.8, because of stability of this version.But if i can drive codec in kernel 4.1

it is not a too bad solution!

Regards

[Robert Nelson]

On Tue, Oct 13, 2015 at 2:23 AM, hussain ali <hussain...@gmail.com> 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 codec to kernel 3.8.
> What is your idea? Is there any way to add this codec to kernel 3.8?
> It is ideal for me to use kernel 3.8, because of stability of this
> version.But if i can drive codec in kernel 4.1
> it is not a too bad solution!

3.8 isn't actually that stable, both mmc and usb are ticking time
bomb's just waiting to opps..

[Rick Mann]

I'd love to move to 4.x, if I could get the audio to work correctly. Still struggling with it (I have verified that both the audio cape and my own cape work great in 3.8.x).

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

[hussain...@gmail.com]

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 it's schematic is almost 1:1 copy of BBB.
I have trouble with it. Audio comes out but is noisy.
I've also tested board with the same kernel and RFS as BBB ( after some minor change in capemgr diver) but the result has not changed.
If you had any experience with this board, I'll be glad if share your comment here.

Best regards.

[bglaz...@gmail.com]

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 on the output then freezes. Does the audio output bug persist?

Thank you,

Bruce

[Robert Nelson]

On Tue, Dec 8, 2015 at 7:59 AM, <bglaz...@gmail.com> 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 but it chokes on speaker-test; it makes
> one blip on the output then freezes. Does the audio output bug persist?

No, i haven't gotten the audio cape to work yet. I've cleaned up the
boot errors enough where we don't really have any more hints of where
it's messed up, and i don't know enough of the asoc layer to fix it at
this point.

I've had reports that hdmi-audio works fine, so audio does work..
(just not this cape/overlay)

[bglaz...@gmail.com]

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 oscillator, Y4, on the BBB to generate that signal. I've attempted modifying the clock-frequency value but it does not have an effect, I still see 24MHz on the output.

clk_mcasp0_fixed {
        #clock-cells = <0x0>;
        compatible = "fixed-clock";
        clock-frequency = <0x1770000>;
        linux,phandle = <0x51>;
        phandle = <0x51>;
    };

    clk_mcasp0 {
        #clock-cells = <0x0>;
        compatible = "gpio-gate-clock";
        clocks = <0x51>;
        enable-gpios = <0x48 0x1b 0x0>;
        linux,phandle = <0x54>;
        phandle = <0x54>;
    };

Also I've specified the clock within the simple-card binding as follows:

 sound_master:simple-audio-card,codec {
                    sound-dai = <&tlv320aic3104_aq1>;
                    clocks = <0x54>;
                    /* system-clock-frequency = <12000000>; */
                    };

This allows me to use the defined clock, referenced by its phandle, for my codec. In this configuration it is the codec that is doing the clock generation as it is defined as the master. In my case, it is generating a BCLK and a WCLK but at a much higher frequency that what is expected, i.e, I issue an arecord test.wav, I should see BCLK at 8KHz but it is instead at 16KHz. Or is that what I should expect for BCLK considering Nyquist Theorem, etc, need to sample at twice the desired frequency? On second thought, this entire thing is configured for TDM and I am not very familiar with what I should be seeing vs. what I am seeing.

I'd also like to add that I am seeing data on both AIN and AOUT but its coming in much faster than we'd expect hence the:
root@beaglebone:~# arecord test.wav
Recording WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
overrun!!! (at least 0.109 ms long)
overrun!!! (at least 0.064 ms long)
overrun!!! (at least 0.754 ms long)

or the

root@beaglebone:~# speaker-test

speaker-test 1.0.28

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 256 to 32768
Period size range from 128 to 16384
Using max buffer size 32768
Periods = 4
was set period_size = 8192
was set buffer_size = 32768
 0 - Front Left
Write error: -32,Broken pipe
Write error: -32,Broken pipe
Write error: -32,Broken pipe
Time per period = 0.101305
 0 - Front Left
Write error: -32,Broken pipe
Write error: -32,Broken pipe
Time per period = 0.054033

Not sure what to make of the Broken Pipe but there you have it.

[kand...@amtelco.com]

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.

[Robert Nelson]

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

Regards,

[Robert Nelson]

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,

[kand...@amtelco.com]

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.

[Robert Nelson]

On Mon, Jan 11, 2016 at 1:18 PM, <kand...@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.

Just pushed this as default:

https://github.com/RobertCNelson/dtb-rebuilder/commit/d2879cff737d2d4671989de43067336745868ab8

it's nice having dma with spi overlay working again!

Regards,

[Bruce Glazier]

You are a genius, it really worked! I could NOT get past this roadblock. Thank you!

--

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...@googlegroups.com.

[Bruce Glazier]

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, <kand...@amtelco.com> wrote:

--

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...@googlegroups.com.

[Robert Nelson]

On Tue, Jan 12, 2016 at 7:35 AM, Bruce Glazier <bglaz...@gmail.com> 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 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.

Yeap, that should work ^^

BTW, i've pushed this change too all active branches:

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

4.4.0-bone2

4.4.0-bone-rt-r2

4.3.3-bone4

4.1.15-bone18

4.1.15-bone-rt-r18

which are building on the arm farm right now..

and it'll be part of:

4.1.15-ti-r41

4.1.15-ti-rt-r41

pushed out on thursday.

Regards,

[Bruce Glazier]

Thanks Robert, glad it could get resolved.

--

[Robert Nelson]

On Tue, Jan 12, 2016 at 5:57 PM, Bruce Glazier <bglaz...@gmail.com> 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 every little mA, will need to disable the un-used options in that included *.dtsi

Regards,

[bur...@cybrigade.com]

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?

[Robert Nelson]

On Tue, Mar 8, 2016 at 12:21 AM, <bur...@cybrigade.com> 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 change i need todo to..

[Micka]

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>;
	      compatible = "gpio-gate-clock";
	      clocks = <&clk_mcasp0_fixed>;
	      enable-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; /* BeagleBone Black Clk enable on GPIO1_27 */
	};

is it ?

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

[Micka]

It's working for me also, do you know how to change the volume ? 

Micka,

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.