H3 I2S0 DT overlay
5 5

44 posts in this topic

Recommended Posts

It would make more sense to work with the mainline driver and fix issues with it over than working with this sun8i-i2s driver. So from what I read you have an external G-Dis DAC and some highly accurate clock board which you wish to clock both the dac and SoC with. What other connections do you have from the nanopi?, are the gpio's mentioned in the overlay used?

 

Overlays should be fairly straight forward, can you try this?.

// Definitions for G-Dis DAC
/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun8i-h3";

	fragment@0 {
		target = <&i2s0>;
		__overlay__ {
			pinctrl-0 = <&i2s0_pins>;
			pinctrl-names = "default";
			status = "okay";
		};
	};

	fragment@1 {
		target-path = "/";
		__overlay__ {
			i2s0_out: i2s0-out {
				#sound-dai-cells = <0>;
				compatible = "linux,spdif-dit";
			};

			sound_i2s {
				simple-audio-card,name = "G-Dis DAC";
				compatible = "simple-audio-card";
				simple-audio-card,format = "i2s";
				simple-audio-card,bitclock-master = <&codec_dai>; 
				simple-audio-card,frame-master = <&codec_dai>; 
				simple-audio-card,mclk-fs = <256>;
				status = "okay";

				simple-audio-card,cpu {
					sound-dai = <&i2s0>;
				};

				codec_dai: simple-audio-card,codec {
					sound-dai = <&i2s0_out>;
				};
			};
		};
	};
};

What did you use to get it working with the Raspberry pi?,

CK

Edited by codekipper
code update

Share this post


Link to post
Share on other sites

I must start saying thank you for trying helping me.

I am back in Stockholm now and I will try your suggestion  tomorrow.

I am loading this overlay to RPi

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    fragment@0 {
        target = <&i2s>;
        __overlay__ {
            status = "okay";
            };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            pcm1794a_codec: pcm1794a_codec {
                #sound-dai-cells = <0>;
                compatible = "ti,pcm1794a";
                status = "okay";
            };
        };
    };

    fragment@2 {
        target = <&sound>;
        __overlay__ {
            compatible = "simple-audio-card";
            simple-audio-card,name = "G-Dis-DAC";
            simple-audio-card,format = "right_j";
            simple-audio-card,bitclock-master = <&codec_dai>;
            simple-audio-card,frame-master = <&codec_dai>;
            status="okay";

            cpu_dai: simple-audio-card,cpu {
                sound-dai = <&i2s>;
                dai-tdm-slot-num = <2>;
                dai-tdm-slot-width = <32>;
            };

            codec_dai: simple-audio-card,codec {
                sound-dai = <&pcm1794a_codec>;
            };
        };
    };
};

I agree with you about using the mainline driver but according to some answers earlier in the thread I thought it didnt supported slave mode.

I can post some pictures of my dac/reclocking board ao you can see how it looks like.

 

Share this post


Link to post
Share on other sites

OK, we can reuse most of the working overlay and adapt it for the h3. Slave mode should be supported by the mainline driver but I've not tested it, however I do have a master codec in the post which should get to me sometime this week. Do you have access to a logic analyser?,

BR,
CK

Share this post


Link to post
Share on other sites
6 minutes ago, codekipper said:

OK, we can reuse most of the working overlay and adapt it for the h3. Slave mode should be supported by the mainline driver but I've not tested it, however I do have a master codec in the post which should get to me sometime this week. Do you have access to a logic analyser?,

BR,
CK

 

Slave mode assume that externals source of the bit- and lr-clocks controls by driver,  but I can't saw where is it. And as I see mainline driver support only 16 bit sample.
I worked with friendlyarm's variant because it was most complete. Now I want modify mainline driver for support 16/24 bit master/slave and test it on nanopi neo (2, air) and cubietruck.

Share this post


Link to post
Share on other sites

mainline should support slave mode

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sunxi/sun4i-i2s.c?h=v4.15-rc2#n502

there is also a few patches which I haven't delivered yet here

https://github.com/codekipper/linux-sunxi/commits/sunxi-wip

however I still need to test these properly before pushing for mainline. I'm also trying to come up with a cleaner solution for when the codec expects 32bits frame width.

 

MitchD likes this

Share this post


Link to post
Share on other sites
3 minutes ago, codekipper said:

mainline should support slave mode

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sunxi/sun4i-i2s.c?h=v4.15-rc2#n502

there is also a few patches which I haven't delivered yet here

https://github.com/codekipper/linux-sunxi/commits/sunxi-wip

however I still need to test these properly before pushing for mainline. I'm also trying to come up with a cleaner solution for when the codec expects 32bits frame width.

 

Thank you for information. I only now began to understand mainline driver. I have some hardware (cubietruck, nanopi neo and nanopi neo 2), clocks board (schematic attached) and simple logic analyzer. I can try testing your modification.

neoclock - Project.pdf

Share this post


Link to post
Share on other sites

please do....I've currently got a logic analyser on my pcm5102a boards and I'm seeing issues with the clock division which I will address. It would be good to have someone testing on an older board as my A20 EVB is no longer booting.

Share this post


Link to post
Share on other sites
1 hour ago, codekipper said:

please do....I've currently got a logic analyser on my pcm5102a boards and I'm seeing issues with the clock division which I will address. It would be good to have someone testing on an older board as my A20 EVB is no longer booting.

OK, I'll built fresh armbian image for nanopi neo and can check your code. One question: why oversample rates started with 128 but not 64 (32 bit frame) or 32 (16 bit frame)?

Share this post


Link to post
Share on other sites

I guess we've just never had all the possible information, the oversample rates were documented in the A20 user manual (128 was the lowest)but not in the later iterations.

Share this post


Link to post
Share on other sites

Quick info about testing.
- nanopi neo
- armbian image builded from github sources
- i2s module by codekipper
- overlay from codekipper's post (but simple-audio-card,mclk-fs = <128>).

 

Because my clock board without pins control works on 176400 all test with this sample rate:

aplay -c 2 -f S16_LE -r 176400 /dev/urandom - working and I see some data on dout pin
aplay -c 2 -f S24_LE -r 176400 /dev/urandom - aplay: pcm_write:2011: write error: Input/output error
aplay -c 2 -f S32_LE -r 176400 /dev/urandom - no error and zero data on dout pin

Share this post


Link to post
Share on other sites

Congratulations, this is the first time slave clock has been utilised on the mainline driver. Do you have my debug enabled?, it would be nice to see register settings during playback. I'll follow the same test procedures when I get my new codec.

 

Share this post


Link to post
Share on other sites

I did some testing today and I can tell that the overlay you suggested works just fine both  as slave and right justified format.

I only played 16/44 tracks (feeding nanopi neo with a 2.8224 MHz bitclock and a 44.1 KHz LRclock from my clockcard).

My setup is almost identical as nikkov  except for the external clock card 

I will do some more testing and report back. I have some small issues with pops and clicks when the nanopi is in pause state but I dont think it has something to do with the software.

 

Share this post


Link to post
Share on other sites
10 hours ago, codekipper said:

Congratulations, this is the first time slave clock has been utilised on the mainline driver. Do you have my debug enabled?, it would be nice to see register settings during playback. I'll follow the same test procedures when I get my new codec.

 

Yes, your debug output I see in kernel.log

 

For full-fledged testing, I need to add a codec driver to specify the hardware modes for my clocks board:
i2s mode;
32 bit frame size independents from sample size;
divider for BCLK/LRCLK driven by GPIO.

 

I'll try made this in near time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

5 5

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.