<dsimic>
now we also know who makes those RPi cards, Foresee
stikonas has quit [Quit: Konversation terminated!]
<dsimic>
all in all, we've learned something new, and I'll hopefully get those patches upstreamed :)
<dsimic>
I'd say that it was a good decision to dig a bit deeper
<diederik>
dsimic: I VERY much believe you won't find upstreaming efforts by RPi people; that's one of the things that made me abandon RPi's
<dsimic>
diederik: this is an obvious example of such a bad practice :(
<diederik>
The interesting thing about this A2 card stuff ... is that the SDcards that RPi used to provide were REALLY bad ... so bad that the 2 most common causes for problems were PSU and (their!) SDcard
<dsimic>
I'm no longer surprised by anything coming out of the RPi Foundation
<dsimic>
also, the PDF about the RPi microSD cards that I linked above doesn't mention high endurance at all
<Dex2x>
once they changed the licensing it was a major turning point
<dsimic>
which is really disappointing... maybe they actually want people to buy replacement cards? :?
<dsimic>
which is really disappointing... maybe they actually want people to buy replacement cards? :/ *
<dsimic>
Dex2x: I just learned that Apacer also makes A1-rated high-endurance microSD cards
<Dex2x>
oh neat
<diederik>
adding M$ gpg key to Debian APT's keystore without telling anyone about it nor prompting users about it ... in a postinst script. And then they were surprised that anyone could have a problem with it ...
<diederik>
I've found a number of mind blowing things (and not the good kind) in what they did, so that was another reason why I abandoned RPi's
<dsimic>
it seems they simply don't give a damn :/
<diederik>
indeed
<dsimic>
just checked and there are no Rockchip boards that have command queuing enabled on their microSD slots, which means we'll see no benefits from all this, but that's been pretty much already exoected
<dsimic>
s/exoected/expected/
<dsimic>
Dex2x: ^^^
<dsimic>
actually, s/enabled/possible/, meaning that they all use eMMC 4.51 interfaces for the microSD slots
<diederik>
didn't mmind00 submit a patch to enable command queuing? Possibly for some other device, but I do have a (vague) recollection of such a patch
<dsimic>
s/for the/for their/
<dsimic>
any chances to find that patch, please?
<diederik>
I don't know how to find that quickly. Maybe it was ~6 months ago?
<dsimic>
perhaps that patch would've been merged already
<diederik>
very likely, yes
<Dex2x>
dsimic, aaawh that is sad :(.
<Dex2x>
so they only seem to do dw_mshc , Designware
<Dex2x>
But they have eMMC so I guess tradeoff?
<dsimic>
Dex2x: ah, it is what it is... it's simply about the way the boards are designed for different SoCs
<dsimic>
the reference designs from Rockchip always use sdhci interfaces for eMMC chips, and sdmmc interfaces for microSD cards
<Dex2x>
yeah. and rpi don't really have emmc slots from what I recall. It's sdcard or nvme
<dsimic>
the former supports eMMC 5.1, while the latter doesn't, and that's it
<dsimic>
some RPi SoM do have soldered eMMC chips, which I mentioned already
<diederik>
is that perhaps sth that the system/controller adjusts dynamically?
<qschulz>
diederik: yeah I had the same on my Thinkpad x280, was wondering what's what
<diederik>
My laptop is also a Thinkpad, but then a X1 Carbon (5th edition I think)
<diederik>
I just booted into my 6.17-rc7 kernel on Rock 5B and dmesg on level 0,1,2,4 report NO issues and 'only' 984 !! times this error: "ASoC error (-19): at snd_soc_dai_prepare() on i2s-hifi"
<qschulz>
diederik: missing kernel driver?
<qschulz>
-19 is ENODEV
<diederik>
oh, could that be it?
<diederik>
I see ASoC errors appear and disappear without me having any clue as to why ... which is why I tend to ignore them, but that's surely worth investigating. Thanks!
<diederik>
it was more that there were no other errors and no warnings ... and I think I haven't seen that before
<diederik>
(but OTOH, apart from a RTC battery and a network cable (and power), nothing is connected atm)
<diederik>
qschulz: my guess is that it's about snd_soc_hdmi_codec and I have ``CONFIG_SND_SOC_HDMI_CODEC=m`` in my kernel config ... so maybe it isn't loaded yet when snd_soc_dai_prepare() is run?
<chewitt>
the driver CONFIG options renamed between 6.16 and 6.17
<chewitt>
this caught me out when trying to create a common aarch64 defconfig for newer/older LE supported RK chipsets
<chewitt>
the defconfig was for 6.17 but when compiling a 6.16 kernel it dropped the audio devices on older boards as the defconfig was using the newer module name
<chewitt>
so the automagic config adjuster that runs when you compile just dropped the module
<diederik>
That config option was enabled on 2022-10-24 here
<diederik>
chewitt: thanks for that :) I have the 2 I2S variants =m, but I also have ``CONFIG_SND_SOC_ROCKCHIP_SAI=m`` ... and no modules with 'sai' in their name are currently loaded
<qschulz>
this one is only for RK3576, don't need it
<qschulz>
diederik: can you paste the .config somewhere?
<qschulz>
do you have CONFIG_SND_SIMPLE_CARD=m/y somewhere?
<qschulz>
diederik: for starters, are we actually hunting a bug/misconfiguration?
<qschulz>
or does audio over HDMI actually work
<diederik>
that is a good question ... as I actually used Analog audio in my testing thus far
<qschulz>
because it could be you have a driver built-in which depends on other drivers which are built as modules and then once you actually mount your rootfs, the thing works, albeit your log is full of error messages that aren't particularly relevant
<walter>
sr.ht has a paste service. good to know. thanks!
<diederik>
qschulz: Connected the Rock 5B to my AVR which is connected to my (4k) TV and booted into my 6.17-rc6 kernel (with the rkvdec2 patches) and I still get the ASoC errors in dmesg, but I do have working audio
<qschulz>
diederik: there are two HDMI ports on the Rock 5B, does it work on both? (I would assume so since all IPs involved are the same for HDMI0 and 1?)
<diederik>
Will try that in a bit. Right now using HDMI0
<qschulz>
can you tell us what's the actual error message?
<qschulz>
because you gave us twice an error message that can only happen on RK3399 but keep talking about Rock 5B :)
<diederik>
``hdmi-audio-codec hdmi-audio-codec.7.auto: ASoC error (-19): at snd_soc_dai_prepare() on i2s-hifi``
<qschulz>
ok, so this i2s-hifi is actually the hdmi_i2s_dai form hdmi-codec, I thought it was something to be defined in the DT
<qschulz>
and got confused by the log on 6.12.21 because that is run on an RK3399 (rockpro64)
<diederik>
That looks indeed to be the case ... while I don't use my RP64 much ... and on the RP64 Analog audio doesn't work and I don't know yet why
<diederik>
I seem to recall that I get ASoC errors on all or pretty much all my Rochchip based devices, but I'll verify that
<diederik>
the very low CPU usage while playing (with HW decoding) is awesome :-D
<diederik>
Playing BBB 1080p in x264 on my 4k TV and I get 930 dropped frames (which I think was almost 0 on my monitor) ...
<diederik>
similar frame drop with x265 (8-bit)
<diederik>
Also tried the Jellyfin AVC test videos and both the 10M and the 20M variant resulted in 907 dropped frames. I didn't see any visual artifact though (also not in BBB video)
<diederik>
qschulz: I have to check further if I need to change sth, but I have no audio on HDMI1 now
<qschulz>
diederik: that could be the reason why you're seeing the issues then
<qschulz>
s/issues/messages/
<qschulz>
try disabling hdmi1_sound to see if they are then removed
<qschulz>
then you can check the rest of dmesg, maybe the hdmi1 node is somewhat broken (or doesn't register the second hdmi audio output for example) or the other i2s6 controller doesn't get probed/registered properly
<diederik>
indeed. Now rebooting with HDMI1 plugged in to see if that makes a difference (1st test was a 'hot-plug')
<diederik>
interesting. Now wpctl status says "Dummy Output" on Audio Sinks
<diederik>
And I still have a very similar ASoC error message, but now with '...6.auto' instead of '...7.auto'
psydroid2 has quit [Ping timeout: 245 seconds]
psydroid2 has joined #linux-rockchip
<diederik>
hmm still seeing "sync_state() pending" msgs on 6.17-rc7 on Rock 5B (no ``fw_devlink=off`` kernel param though)
<dsimic>
diederik: (re: b81e4cc84bfc) ah, thanks, now I also remember that commit, which is about enabling the RK35xx controller-side of the command queueing
<dsimic>
diederik: (re: NVMe power setting) AFAIK, there's no automatic setting of the power profile, as performed by the kernel, and all NVMe SSDs I've seen so far configured themselves to use the highest available power profile by default; perhaps some SSDs take the opposite side of the spectrum by default
<dsimic>
diederik: qschulz: I'm wondering what are the exact NVMe SSD models you're observing that on?
<qschulz>
dsimic: don't have access to my PC right now, but some Intel one IIRC
<diederik>
I though it was curious that both have that. Both are Samsung SSD though. "Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961/SM963" on my laptop and "Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO" on my Rock 5B
<diederik>
s/I though/I thought/
<dsimic>
I'm very happy see some progress on debugging the audio issues :)
<dsimic>
qschulz: hmm, it could be that some Intel QLC SSDs put themselves into the lowest available power state by default because they aren't the fastest ones
<diederik>
I rebooted again with HDMI cable still plugged into HDMI1 and now it is '...7.auto' again. I now do see other errors and several warnings ... as I normally see (so the no warnings and only ASoC errors really was an outlier)
<dsimic>
diederik: yes, it's rather intriguing, but maybe it could be explained by both SSDs being Samsung OEM variants... actually, is it 980 PRO in your ROCK 5B, or some OEM variant? IIRC, it isn't in a case, so checking it visually should be rather easy :)
<diederik>
it is the 980 PRO
<dsimic>
oh, so it isn't up to it being an OEM variant
<dsimic>
it's really interesting why both SSDs (actually, all three) put themselves into the lowest available power state
<dsimic>
I'll research that further
<dsimic>
diederik: qschulz: thanks for pointing it out!
<qschulz>
diederik: the numbering isn't probably stable so I wouldn't put too much trust in that
<qschulz>
is probably not stable*
<diederik>
qschulz: indeed. the 'auto' already hinted towards that
<qschulz>
what happens if you disable the HDMI0 node in DT?
<diederik>
qschulz: I'll try that later
<diederik>
I'm currently 'fascinated' by the Video Devices reported by wpctl: "rockchip,rk3568-vpu-dec", "rockchip,rga", "rockchip,rk3588-vepu121-enc", "rkvdec", "rockchip,rk3588-av1-vpu-dec" and "snps_hdmirx"
<diederik>
so that is indeed quite similar to PBP which also has 5 :-P
<dsimic>
it actually depends on the SSD
<dsimic>
so it just happens that the PBP example, i.e. the SSD that happened to be installed, has five profiles/states :)
<dsimic>
diederik: qschulz: oh, wait, I know what's going on :D
<dsimic>
you're watching the power state with no I/O load, which causes the SSD to go automatically into teh lowest available state
<dsimic>
please generate some I/O load and you'll see the drive ramping the power profile up
<dsimic>
s/teh lowest/the lowset/
<dsimic>
s/teh lowest/the lowest/ *
<dsimic>
IOW, when there's no I/O load, drives go into the lowest available power profile automatically, which is also (one of) the idle profile(s)
<dsimic>
with some I/O load present, drives go automatically into (one of) the highest possible active power profile(s)
<dsimic>
to sum it up, the distinction between the idle and the active power profiles is very important
<dsimic>
I was under false impression that your SSDs go automatically into the lowest _active_ power profile :)
<qschulz>
I don't understand how this would work TBH
<qschulz>
it's the same feature for idle and under load settings as far as I'm understanding
<dsimic>
this has also reminded me about the need to finish my old patches that put the SSDs in PBP into the power profile that matches the available power
ldevulder has quit [Ping timeout: 255 seconds]
<dsimic>
let me try to use some ASCII art...
<qschulz>
either there's only one feature for both idle and under load
<dsimic>
A1 <-x-> A2 <---> A3 <---> I1 <---> I2
<qschulz>
in which case, you probably want to leave the disk doing what it wants since it's already at the minimum power profile
<qschulz>
in idle
<qschulz>
if there's actually a different setting (feature) for idle/under-load, then the CLI tool is very confusing
paulk has quit [Ping timeout: 260 seconds]
<dsimic>
drives go automatically between the Ax (active) and Ix (idle) states, and when you set the power profile manually, it actually limits only up to which Ax profile the drive can scale automatically, which is the "broken link" between A1 and A2 in the example above
<dsimic>
when idle, drive goes down to the lowest available state/profile
<dsimic>
when loaded, drive goes up to the highest available state/profile
paulk has joined #linux-rockchip
<qschulz>
dsimic: so get_feature doesn't operate on the same "variable" than set_feature
<dsimic>
and the userspace utility limits to how high it can go
<qschulz>
mmm or maybe they do operate on the same "variable", just that to configure the feature under load, you need to be under load
<dsimic>
actually, you're leaving the drive to do what it does anyway, but you just limit the upper power cap, so to speak
<qschulz>
which... makes very little sense
<dsimic>
no, you don't have to be under load
<qschulz>
so the cli tool is misleading
<dsimic>
just test it and you'll surely get the grasp of it
<dsimic>
what man page are you looking at?
<qschulz>
pine64's
<qschulz>
my PC returns 0x4 for nvme get-feature /dev/nvme0 -f 2
<dsimic>
that's the current state
<dsimic>
which canges all the time
<dsimic>
which changes all the time, depending on the I/O load *
<dsimic>
set-feature sets the cap
<qschulz>
how do I see the cap then
<dsimic>
well, you don't see it :/
<qschulz>
that's what I'm complaining about :)
<dsimic>
just write it and "keep knowing it" :/
<dsimic>
ah, yes, it's a bit confusing, but that's how it works
<dsimic>
you can hit the SSD hard with load, use get-feature and check the cap that way, though :)
<dsimic>
it won't go over the currently configured cap :)
<qschulz>
which you cannot know unless you've set it yourself :D
<dsimic>
indeed, or you can measure it under load :)
<dsimic>
qschulz: just checking, have you confirmed that behavior?
<qschulz>
dsimic: no, still no access to my PC :)
<qschulz>
trying to figure out how mkimage actually generates the data-offset and data-size properties for each image node in a FIT
<dsimic>
ah, I see... just take your time
<qschulz>
I'll let you know tomorrow if I haven't forgotten to check tonight :)
<dsimic>
nice, thanks
<qschulz>
this mkimage thing is crazy
<qschulz>
if I call it twice, it generates the same image, but with data-offset and data-size properties' order swapped
<dsimic>
let's also ask diederik to check the behavior described above :)
<qschulz>
I know where the second call writes the properties, but I cannot find where the first call adds them
<dsimic>
hmm, that sounds like some bug?
<qschulz>
it does sound like it to me, so I would like to know how those are added so I know which call I need to fix, the first one or the second :)
<dsimic>
I see, but I'm afraid I can't help much there :/
<dsimic>
FWIW, it sounds to me that the first execution should get it all done
<qschulz>
it's necessariy a different code path because the first call will remove the data property to generate the data-size , data-offset properties and then move the content to the end of the fitimage (it's an external fit)
<qschulz>
can be reproduced with vanilla master with a rockchip device (I tested ringneck-px30)
<qschulz>
compile once with the normal make
<dsimic>
I haven't worked much with it, so I'm afraid I don't know much about it
<qschulz>
run dtc -I dtb -O dts simple-bin.foo.fit in between and you'll see the order change
<qschulz>
dsimic: it's a general "you", not expecting you to debug this :)
<dsimic>
:)
<diederik>
dsimic: [14:33:40] <diederik> is that perhaps sth that the system/controller adjusts dynamically?
<diederik>
^^ that was me wondering whether the profile got adjusted based on 'something' (like I/O load)
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
<dsimic>
diederik: ah, I see what you meant now
<dsimic>
I misread it as "does the system configure the lowest _active_ power profile", which caused the confusion on my side
<dsimic>
I'm hoping we've made it clear now :)
<diederik>
qschulz: disable hdmi0 or hdmi0_sound node? Or both? (and I assume test with hdmi cable in hdmi1?)
<diederik>
I'll first try disabling hdmi1_sound (as the cable is now in hdmi0) ... like you said at 16:57:33
<diederik>
hdmi1_sound disable, hdmi cable in hdmi0 ... and no ASoC errors :-)
<diederik>
booted into 6.17-rc7 (so without rkvdec2 patches) and playing BBB 1080p x264 with software based decoding ... and ~920 dropped frames in 30 secs ... (pretty much) the same as with HW based decoding
<diederik>
hdmi0_sound disabled, hdmi cable in hdmi1 ... and no ASoC errors. But wpctl still reports 'Dummy Output' as Sink ... and indeed no sound
<diederik>
So it seems that ASoC errors occur for the enabled sound node which has no hdmi cable in its port. And hdmi sound on hdmi1 doesn't work at all
<dsimic>
would it be possible to test with both ports enabled and with their cables/sinks attached?
kilobyte_ch has quit [Ping timeout: 260 seconds]
kilobyte_ch has joined #linux-rockchip
ldevulder has joined #linux-rockchip
stikonas has joined #linux-rockchip
eballetbo has quit [Quit: Connection closed for inactivity]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
<dsimic>
diederik: qschulz: dang, it just came to me that there's a possibility to save some battery power with systems equipped with NVMe SSDs
<dsimic>
the NVMe subsystem in the kernel selects the NVMe SSD power profiles, and makes them available to the drive, based on the latency for entering each state
System_Error has joined #linux-rockchip
<dsimic>
thus, there's a possibility to lose the lowest active power state from the final list of profiles, which makes it impossible to have that profile selected, either manually by setting the cap, or automatically by the drive
<dsimic>
which means that some battery power might be saved by making sure that the lowest power profile is always in the final list