<diederik>
Turns out this card is made by Samsung (KLMCG2UCTB)
<diederik>
(but I do also have Foresee eMMC cards)
<diederik>
chewitt: That page only tells which cards they tested with, which says ~ nothing about what you actually have
raster has quit [Remote host closed the connection]
<chewitt>
true .. I'm trying to read the chip via phone camera (as my eyeballs aren't the best)
<diederik>
IOW look at your actual eMMC module to find out what you have
<diederik>
that's exactly what I did too ;-P
<robmur01>
chewitt: sure, just saying it's not wrong for the board to have SDIO enabled, since it's still wired to the socket even if you do happen to be using a non-SDIO module
raster has joined #linux-rockchip
<chewitt>
emmc issue resolved :)
<chewitt>
"user error, please replace user"
<chewitt>
turns out I connected the ufs module for Rock 4D? instead of the emmc module
<chewitt>
too many little packages and boards combined with enthusiasm and bad eyesight
<diederik>
This was bound to happen: same size and same connectors
<diederik>
I do have a 'special' eMMC adapter and I wonder if I'd need another one if I will use an UFS module ...
<detlevc>
diederik: The ASoC messages is kinda my fault, I don't have a solution for that yet. The QP bridge won't let some audio related registers be written when no HDMI cable is connected (it will just hang). So if there is nothing connected, I just return -ENODEV. But ASoC doesn't like that. I think my solution will be to just return 0 but do nothing.
<detlevc>
diederik: Another idea was to use a cached regmap and write the registers one a cable is plugged in, but that doesn't work as most values are calculated based on the TMDS char rate
<detlevc>
which is unavailable if no screen is plugged in
<diederik>
detlevc: I may indeed not have plugged in the HDMI cable that time; I booted it up to check if 6.16-rc5 would have a problem with eMMC (see earlier discussion)
<detlevc>
Also, there seem to be no way to mark the sound device as disconnected (so that it doesn't show in alsa or pipewire)
<diederik>
I dunno where it came from, but all (?) my devices have various ASoC errors now, although they're not all the same. Given that I also got it on a 6.12.21 kernel, my guess is that it's some userspace thing that messes things up?
<diederik>
I did a (quick) downgrade of pipewire, but that didn't make a change.
<diederik>
Usually I have no idea where ASoC errors come from ... and after some time they seem to disappear ... once again without me knowing/understanding why
* diederik
starts up Rock5B again, this time with HDMI connected ...
<detlevc>
These won't disappear unless I fix them in the driver. Also on rock 5b, we now have 2 hdmi outputs so you need to plug 2 screens to not see any error
<diederik>
Ah, that explains why I'm still seeing the same ASoC error with 1 HDMI connected, but now 'preseeded' by "HDMI: Unknown ELD version 0" error ... and less spammy as dmesg now still had the first boot messages
<mmind00>
detlevc: might be a dumb question, but did you compare clock-state between cable plugged and not? Controller hanging for some register write sounds like some clock thingy
warpme_ has joined #linux-rockchip
<detlevc>
mmind00: Yes, that's also a solution, but it feels wrong to enable clocks on hdmi to configure something that won't work (there will also still be no TMDS char rate, so configured values will still be wrong)
<diederik>
detlevc: AFAIC there's no need to prioritize this (for me). For the foreseeable future I'll likely only use my 5B to build (kernel) packages (ie headless)
<diederik>
I do want to try to daily drive it during the Forky cycle though to see how that fares :)
<mmind00>
detlevc: was more thinking about, asoc wants some registers written -> enable pclk -> do the write -> disable pclk
<detlevc>
mmind00: I can try. That might remove the "HDMI: Unknown ELD version 0" though, I'll give it a go
<chewitt>
detlevc I'm experimenting with Kodi support on 3588 for LibreELEC