10:22 <peter17> we're considering rockchip SoC for a new projects but we're having mixed feelings regarding the linux support, is there any good overview of supported features for the various SoCs?

10:25 <qschulz> peter17: which SoC and which other SoC vendor/SoC from that other SoC vendor are you considering?

10:26 <qschulz> mmind00: may have some idea about that a page listing supported features maybe?

10:26 <qschulz> peter17: for RK3588, https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

10:26 <qschulz> for RK3576: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3576/-/blob/main/mainline-status.md?ref_type=heads

10:30 <peter17> thank you, any idea about e.g. the RV1109?

10:31 <peter17> Usually we're mostly using NXP because of their good Linux support, looking at rockchip as an alternative for a more cost sensitive project.

10:38 <qschulz> peter17: there's at least **some** support for the RV1109, c.f. https://elixir.bootlin.com/linux/v6.13.7/source/arch/arm/boot/dts/rockchip/rv1109.dtsi

10:39 <qschulz> peter17: I'm not too familiar with the RV family, but I'm not too sure there's a lot of people contributing to it, or many products based on it?

10:39 <qschulz> at least products being upstreamed I mean

10:41 <rah> is HDMI audio passthrough being worked on?

10:42 <rah> I understand that the same driver is used for HDMI on a lot of Rockchip SoCs

10:42 <qschulz> peter17: I worked on NXP, Rockchip, Allwinner, Amlogic and Mediatek SoCs. NXP are VERY much ahead in terms of support and documentation. Rockchip is "okay", Mediatek and Amlogic were far far behind 5 years ago but Mediatek seems to be pushing a bit for upstream now (Rockchip starting to follow I believe(

10:42 <qschulz> so expects a LOT more headaches compared to NXP

10:43 <qschulz> also, only talking about upstream support there

10:43 <qschulz> wrt vendor forks of the kernel... Rockchip's.... is interesting to say the least, but at least there is some documentation (TRMs), compared to Mediatek/Amlogic

10:45 <qschulz> rah: I don't know what HDMI passthrough is? Can you tell me more about it? There's HDMI audio output slated for 6.15 I believe

10:45 <qschulz> on RK3588

10:46 <qschulz> peter17: though to be honest, the upstream Rockchip community is one of the most active I've seen among the Arm Asian SoC vendors.

10:46 <peter17> @qschulz, thank you for your opinion guess we'll either go with the more common RK35XX chips or stick with NXP

10:47 <rah> qschulz: passing encoded DTS/Dolby Digital bitstreams rather than decoded PCM streams

10:47 <rah> https://github.com/LibreELEC/LibreELEC.tv/issues/5858

10:48 <rah> I know there's support for PCM output in the works, I'm wondering if anyone is working towards passthrough support

10:48 <qschulz> peter17: rk356x is pretty popular among cheap Rockchip boards, rk3588s is a cost down version of rk3588. They both now are receiving attention upstream. rk3576 is cheaper than rk3588 (maybe rk3588s) I assume? but newer, so upstream support is still at its inception (but building upon rk3588/rk356x upstream support since a lot is assumed shared)

10:49 <qschulz> s/They both/They all/

10:49 <qschulz> rk3588 is expensive :)

10:50 <diederik> (for good reasons IMO)

11:04 <qschulz> don't know, but Intel having low-cost CPUs now also doesn't really help. Good for competition though :)

11:04 <CounterPillow> peter17: I recommend against the RV ones if you're trying to use upstream Linux. RK3566 and RK3568 should be in a fairly good state with upstream Linux. RK3576 may be in a good state by the time 6.16 rolls around but no guarantees on that front. It also really depends on what you need; e.g. Image Signal Processing for camera input isn't happening for any of the RK35xx for a while longer. Feel free to contact any of the consultancies

11:04 <CounterPillow> that work in this area (hint hint: Collabora) with your specific requirements.

11:05 <CounterPillow> (that is, if hiring a consultancy is within your budget, which it might not be if this is supposed to be low-cost)

11:13 <diederik> true, but the rk3588 has f.e. 'better' ARM cores vs rk3576

11:14 <qschulz> diederik: if RV1109 was an option, I'm not sure it matters :)

11:17 <rah> qschulz: I take it you're not aware of any efforts to support passthrough streams?

11:18 <qschulz> rah: no but I am not too involved with upstream Linux kernel efforts anymore sadly

11:18 <qschulz> Kwiboo: may know, especially if there are downstream patches in the pipes too

11:18 <diederik> qschulz: yeah, very valid point ;)

11:19 <CounterPillow> is there any point to doing passthrough on HDMI? It has enough bandwidth for raw PCM surround.

11:19 <diederik> you may want your AVR to handle it

11:19 <rah> Kwiboo: are you aware of any efforts to support HDMI audio passthrough?

11:19 <rah> e.g. 2021-11-07 12:10:05.417 T:957 INFO : m_streamTypes : STREAM_TYPE_AC3,STREAM_TYPE_DTSHD,STREAM_TYPE_DTSHD_MA,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_2048,STREAM_TYPE_DTS_512,STREAM_TYPE_EAC3,STREAM_TYPE_TRUEHD

11:19 <CounterPillow> But why would you want your AVR to handle it? Like, what's the benefit? I only know of downsides.

11:21 <rah> for a start, the set of audio bitstreams that can be decoded by open source software is a proper subset of the set of audio bitstreams that can be decoded by AVRs

11:22 <diederik> CounterPillow: can you list (some of) those downsides? (as you know way more about this then I do)

11:23 <CounterPillow> diederik: you can't do any audio mixing/resampling/etc. on the host. So something like mpv's video-sync=display-resample will simply not work because it can't retime the audio.

11:26 <diederik> ok, true. Thanks.

11:29 <diederik> What I'm hoping for is to use one HDMI port for the audio to my AVR while the other HDMI port only deals with the video stream and that goes directly to my TV

11:30 <diederik> (My TV supports HDR, but my AVR does not, so routing everything through the AVR does not work)

14:05 <mmind00> peter17: didn't follow the whole conversation from earlier, but at least for the rv1109 support should be quite good

14:06 <mmind00> peter17: as it's "just" a rv1126 with less cpu cores, you can essentially take a look at https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rockchip/rv1126.dtsi for what is supported peripheral wise

14:08 <mmind00> peter17: there even seems to be graphics support for that soc (via rgb and dsi outputs)

14:09 <peter17> mmind00, thank you, will check the rv1126

14:10 <mmind00> peter17: in general most Rockchip SoCs use a similar set of peripherals, so depending on what might be missing, support is likely also easy to add

14:11 <mmind00> peter17: also you get mainline u-boot support for the rv1109/rv1126 as well it seems

14:17 <mmind00> peter17: caution, don't get numbers mixed up (speaking from own experience) ... rv1109 is a variant of the rv1126 ... but rv1108 is a different soc (though also supported)

14:34 <sigmaris> peter17: HDMI audio passthrough on RK3399 and other SoCs using dw-hdmi would probably need some changes similar to what's done for Allwinner on https://forum.libreelec.tv/thread/22309-audio-passthrough-testing/

14:34 <mmind00> sigmaris: wrong nick? ... I think it was rah asking about hdmi?

14:35 <sigmaris> oh, sorry my bad :) didn't read enough

14:40 <sigmaris> AIUI the awkward part is the dw-hdmi controller wants an input format different to the standard IEC958_SUBFRAME_LE over I2S, the LibreELEC patches change the ALSA userspace so it writes the special format but still claims it is IEC958_SUBFRAME_LE, but that's not really correct

16:52 <Kwiboo> rah: not aware of any efforts, I gave up on hbr audio long time ago, it took around 4-5 years until there was enough interest in my fix "ASoC: hdmi-codec: reorder channel allocation list" for multi-channel mapping to land, thanks to chewitt for re-sending it

16:55 <Kwiboo> since it took that long time until people started noticing the same issue for regular lpcm multi-channel hdmi audio, I am not expecting there too be much intereset in proper passthrough hbr audio

17:01 <rah> Kwiboo: I see

17:03 <Kwiboo> all I can remember related to i2s and hbr was that the hbr data needed to be mapped to sampleI2S[20:0] = {B,P,C,U,V, dataHBR[15:0]} somewhere, and I created https://gist.github.com/Kwiboo/ccfc99c8c926105b33fa63c6b3c38fc0 around 8 years ago to document the algo

17:03 <rah> Kwiboo: although this isn't limited to high bit-rate audio, which I presume is what you mean by "hbr"?

17:03 <Kwiboo> do not remember if it was specific for dw-hdmi, amlogic or rockchip :-)

17:08 <Kwiboo> rah: yes, hbr=high-bitrate, it was so long time ago I played with passthrough audio, and I cannot remember the exact state, from what I recall there at least was issues with hbr audio, and there was also always out-of-sync issues with passthrough so I settled at multi-channel lpcm support

17:09 <rah> :-/