Kernel 4.14 for sun8i h3 wanted

[hanni76]

Hello, guys,

 

when can we expect mainline Kernel 4.14 for sun8i h3 ?   Now we have only 2 options : 4.11 or 4.13.

 

Thank you

[Igor]

It is planned but after it will be out. There is sunxi-dev branch which contains upstream 4.14.y but is not maintained - it is without necessary patches. You don't want to waste time with it. 

[hanni76]

Igor,

I spent some time looking at patches in sun8i-dev folder that are currently applied to 4.11 and I think some of them can be applied to 4.14-rc7 kernel which is currently available for other boards.

This way sun8i h3 can be supported well enough. And some build files should be changed, i.e. config/sources/sunxi_common.inc to allow sun8i linuxfamily to be changed to "sunxi" as it is done for  others.

That is of course IMHO. I may miss something important.

 

 

 

 

[hanni76]

Well, I think I got your point. 

Current 4.14  which is available for other boards is completely missing h3 stuff in the device tree. There is no even ethernet. 

[hanni76]

On 11/5/2017 at 8:09 PM, Igor said:

It is planned but after it will be out. There is sunxi-dev branch which contains upstream 4.14.y but is not maintained - it is without necessary patches. You don't want to waste time with it. 

Hey Igor, seems like it is out.

[Igor]

25 minutes ago, ssuloev said:

Hey Igor, seems like it is out.

This is the only way if you want things moving faster:

https://docs.armbian.com/Process_Contribute/#collaborate-on-the-project

 

New kernel, new bugs. At least module packaging is broken on 4.14.y and this needs to be fixed first. Then for H3&H5&A64 we have 100+ patches which might need fine-tuning ...

[Pavel Löbl]

Maybe I could also try to do something. I have a orangepi pc board and I would like to get i2s working which should be supported in 4.14. So if I get it right I get upstream mainline kernel then apply patches from "build/patch/kernel/sun8i-dev/". If everything goes fine I will add device trees from sunxi-DT-overlays repository and test the kernel?

[jernej]

33 minutes ago, Pavel Löbl said:

I have a orangepi pc board and I would like to get i2s working

H3 I2S patches were backported in Armbiam due to HDMI Audio. It should already work if you add right DT node for your codec.

[hanni76]

18 hours ago, Igor said:

This is the only way if you want things moving faster:

https://docs.armbian.com/Process_Contribute/#collaborate-on-the-project

 

New kernel, new bugs. At least module packaging is broken on 4.14.y and this needs to be fixed first. Then for H3&H5&A64 we have 100+ patches which might need fine-tuning ...

Igor,

do you have a list of planned tasks that can be split over people?

Or you just said  that someone can do whatever he wants to contribute ?

 

Thanks

[hanni76]

10 hours ago, Pavel Löbl said:

Maybe I could also try to do something. I have a orangepi pc board and I would like to get i2s working which should be supported in 4.14. So if I get it right I get upstream mainline kernel then apply patches from "build/patch/kernel/sun8i-dev/". If everything goes fine I will add device trees from sunxi-DT-overlays repository and test the kernel?

I2S support should be already there, in 4.14. This should be included into the same file sun4i-i2s.c. See http://elixir.free-electrons.com/linux/v4.14/source/sound/soc/sunxi/sun4i-i2s.c. I am afraid I2S support is still not complete...  but it really depends on what you need and what hardware (codec) you are trying to run. Saying"not complete" I mean, for example, method set_bclk_ratio which is not implemented. Same time if you just need to run a simple codec as a slave then things may work for you...

[Igor]

53 minutes ago, ssuloev said:

Or you just said  that someone can do whatever he wants to contribute ?

2

It's more this way. The organizational structure of Linux, which is the main part of or similar to our project, is pretty much anarchistic, highly organized and egalitarian, but voluntary and decentralized. I would say - following your pain or joy and sharing results are the ways to go.

Whatever help we get in what do we do is appreciated - we are already working at the full capacity and putting more pressure on regulars is, on my opinion, contra productive. We can easily burn out and then what?

 

There is also a small award from my side - I do arrange free hardware samples redistribution and there is some budget allocated which is shared with regulars.

[zador.blood.stained]

2 hours ago, ssuloev said:

do you have a list of planned tasks that can be split over people?

We tried this in the past, didn't really work apart from some rare exceptions

 

2 hours ago, ssuloev said:

Or you just said  that someone can do whatever he wants to contribute ?

Not exactly, better to discuss things first.

sunxi-next branch (together with sunxi64-next) will stay at 4.13 for a while. There are no new sunxi related changes in 4,13 (i.e. I2S patches are present already) and we still need to make a stable release based on kernel 4.13 + u-boot 2017.09 (since 2017.11 may break eMMC boot on all boards according to some not yet tested upstream changes)

After the stable release we may start to move it to 4.14

[Christos]

On 14/11/2017 at 11:08 PM, jernej said:

H3 I2S patches were backported in Armbiam due to HDMI Audio. It should already work if you add right DT node for your codec.

 

Is there any chance to have a 'working' overlay for I2S0?

Up to now we were not able to have a playback and capture overlay for the new I2S driver (we also found the timing issues @ssuloev mentions as really frustrating since 192KHz and 24/32bit do not work either)

 

[hanni76]

1 hour ago, Christos said:

 

Is there any chance to have a 'working' overlay for I2S0?

Up to now we were not able to have a playback and capture overlay for the new I2S driver (we also found the timing issues @ssuloev mentions as really frustrating since 192KHz and 24/32bit do not work either)

 

When you build sunxi "next" kernel with Armbian you will get those nodes in the /arch/arm/boot/dts/sunxi-h3-h5.dtsi file after automatic patching. I don't remember exact name of the patch but you can search for it in patch/kernel/sunxi-next folder. By default i2s0_pins node is not connected to i2s0 so you have to do something like this: 

 

/dts-v1/;
/plugin/;

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

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

                        status = "okay";
                };
        };
};

This overlay patch can be added to the add-sun8i-h3-overlays.patch  file or you can create your own patch. Then you can add it to /boot/armbianEnv.txt on your target board:    

 

overlays=<name of your dtbo>

 

 

[Christos]

@ssuloev

Thanks, but it seems there are more underlying problems than simply adding this overlay

-> https://forum.armbian.com/topic/5643-h3-i2s0-dt-overlay/

So far, have seen no working result on having playback and capture and additionaly it looks there are I2S driver problems with 192KHz or at 24 and 32bits.

[jernej]

10 hours ago, Christos said:

24/32bit do not work either

Yes, because it is not implemented yet. Mainline I2S driver supports only 16 bits for now. Shouldn't be hard to add 24/32 bit support. I'm not sure about 192kHz though, maybe it's only not marked as supported or maybe something more is missing.

[Christos]

@jernej

Tried quite a bit to get things to work regarding the I2S0, yet it looks the driver that was included in 4.14 is very limited, most likely because from what I understand it was meant mainly to give some kind of working status to the hdmi.. and thats it, nothing else. IMHO someone has to correct the sunxi mainline effort table at least stating what this I2S driver actualy does and what is pending so we stop banging our heads on the wall wondering why stuff dont work.

[zador.blood.stained]

47 minutes ago, Christos said:

most likely because from what I understand it was meant mainly to give some kind of working status to the hdmi.

No, it was mainlined independently, especially since HDMI DRM driver is still in RFC state.

 

48 minutes ago, Christos said:

IMHO someone has to correct the sunxi mainline effort table at least stating what this I2S driver actualy does and what is pending so we stop banging our heads on the wall wondering why stuff dont work.

Or you could try contacting the driver author/maintainer.

[Christos]

@zador.blood.stained

HDMI's audio is I2S2, thus without an underlying I2S driver HDMI is without audio, so the I2S driver got quickly out with minimal functionality just to accommodate that.

Anyway, IMHO it looks there is plenty of work that needs to be done in that field of I2S.

[jernej]

13 minutes ago, Christos said:

HDMI's audio is I2S2, thus without an underlying I2S driver HDMI is without audio, so the I2S driver got quickly out with minimal functionality just to accommodate that.

That is not really true. Check cover letter of the I2S driver patches: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525407.html

While I ask him to support I2S2 for HDMI audio, he started to develop this driver before with DACs like pcm5102 and uda1380. Actually I2S2 node is not even in upstream DT. You can ask him for 24/32 bit and 192 kHz support and he may help you.

[Christos]

@jernej

The developer is a very nice guy, after all its just free software and he offers his time for free on this.

The sunxi mainline effort page though should have been  detailed on what has been done and what is missing.

Now people got expectations based on it.

 

[zador.blood.stained]

19 minutes ago, Christos said:

The developer is a very nice guy, after all its just free software and he offers his time for free on this.

But linux-sunxi wiki is a community project too and people offer their free time to update it.

 

19 minutes ago, Christos said:

The sunxi mainline effort page though should have been  detailed on what has been done and what is missing.

Now people got expectations based on it.

Regarding the status matrix - "OK" for the audio codec doesn't mean that all audio codec features are implemented (i.e. both playback and capture, all mixer controls, etc.), "OK" for the DRM driver doesn't mean that HW scaling is supported, "OK" for the crypto doesn't mean that all algos and DMA support are implemented, "OK" for the SPDIF doesn't mean that SPDIF transmit is implemented, etc. What I'm trying to say is that first -  it is a developer-oriented status matrix and second - if you start adding that much details regarding partially implemented features it will become more unreadable than it is now on small displays.

 

That is assuming that there are legitimate problems and missing features with I2S driver and not HW limitations or DT misconfiguration.

[hanni76]

On 11/18/2017 at 12:36 AM, zador.blood.stained said:

But linux-sunxi wiki is a community project too and people offer their free time to update it.

 

Regarding the status matrix - "OK" for the audio codec doesn't mean that all audio codec features are implemented (i.e. both playback and capture, all mixer controls, etc.), "OK" for the DRM driver doesn't mean that HW scaling is supported, "OK" for the crypto doesn't mean that all algos and DMA support are implemented, "OK" for the SPDIF doesn't mean that SPDIF transmit is implemented, etc. What I'm trying to say is that first -  it is a developer-oriented status matrix and second - if you start adding that much details regarding partially implemented features it will become more unreadable than it is now on small displays.

 

That is assuming that there are legitimate problems and missing features with I2S driver and not HW limitations or DT misconfiguration.

Like I said before: sun8i I2S may(!!!) work only on limited number of codecs and only in cpu-master mode. That's  what codekipper was promising when I talked to him.

Here is my story: some time ago I strongly needed a stereo ADC in my project and I had Audioinjector sound card at hand http://www.audioinjector.net/rpi-hat. I tried to make it work with OrangePi PC. But it turned to be a huge problem because 1) it uses WM8731 codec + own xtal 12MHz and this dictates it to be a codec-master 2) it required to set BCLK ratio for cpu dai side ("set_bclk_ratio" method in Sound SoC API, which is not implemented in the driver)

Finally it didn't work and I had no expertise to make it. At the same time you can easily use it on Rpi 3 because of full I2S support in Raspbery kernel.