<dsimic>
I'm not really sure what's going on there, and how can that apply to A2-rated cards... perhaps someone got the CQE mixed up with the host-side support that's limited to the controller support and eMMC chips only
<dsimic>
there's been work to have it supported for A2-rated cards as well, but I'm unaware of that work progressing to the point where support is actually available in the mainline kernel
<dsimic>
FTR, here's what I see for an eMMC chip, regarding the RPi forum thread linked above:
<Kwiboo>
"workaround for rk356x, fix the hw bug of cabac/cavlc switch only in h264d"
<chewitt>
hmm.. nice :)
<chewitt>
so far I've not noticed any issues with playback, other than it seems limited in the bitrates it supports
<chewitt>
but 3576 is the same
<diederik>
I still see massive frame drops with BBB in 1080p in both x264 and x265 (>2000 in first 60 seconds)
<diederik>
but great that there is a *known* issue ... and a 'fix'
<chewitt>
I've not seen that at all
<chewitt>
all your dodgy samples play :)
<diederik>
My testing was on Debian with sway and a patched ffmpeg+mpv, so that could play a factor. Haven't tried it with LE, but previously I saw problems which were not or no where near as severe on LE
<Kwiboo>
with vendor kernel on rk3568 the mpp driver will use devfreq/opp table to change clock rates from 297mhz to 400mhz, could be something that is needed for higher bitrates?
<diederik>
I'm not as well versed in LE so I only detect things when there are visual artifacts. When playing with mpv on sway, mpv directly reports the frame drops (and possible audio sync issues)
<chewitt>
Kwiboo I tried up-clocking the vdec but that didn't seem to have a noticeable effect
<chewitt>
I've also spotted the two sets of rates
<chewitt>
they don't appear to do that for 3576 though, it only has a single set, and same on 3588 (although no issue there)
<diederik>
OTOH, my testing on rk3588 with amazing results was on the same setup, so that indicates the different 'environment' is not the (big) differentiator
franoosh has joined #linux-rockchip
_walter_32 has joined #linux-rockchip
walter has quit [Ping timeout: 244 seconds]
<dsimic>
Dex2x: I'm not sure where does the support come from? any chances for summing up what you read about it?
<dsimic>
what's written in the RPi forum thread, for example, is pretty much someone mixing the things up
_walter_32 has quit [Quit: Konversation terminated!]
walter has joined #linux-rockchip
franoosh has quit [Remote host closed the connection]
<dsimic>
nah, that's not it, see commit 045d705dc1fb (mmc: core: Enable the MMC host software queue for the SD card, 2020-02-12)
<dsimic>
as I wrote above, people seem to mix up what's what
<dsimic>
and what isn't :)
<chewitt>
turns out adding more files for 346 h264/hevc/regs is more involved than I realised :)
<chewitt>
the old dog needs to learn some new tricks
<Dex2x>
dsimic, ah hmmmm. Would you see "CQHCI version 5.10" with an sdcard? And how do I know which mmc is the emmc or sdcard ? (this is a more general thing I struggle to see if both are inserted)
<dsimic>
you need to have a look at the board DT to see what's what
<dsimic>
for Rockchip DTs, there are nice aliases at the top of board DT files
<Dex2x>
I thought this would be in kernel already
<dsimic>
I've got "mmc2: CQHCI version 5.10" for an eMMC chip
<dsimic>
sorry, WDYM?
<Dex2x>
I thought by now, instead of having to use some overlay, that the kernel might have had support for A2
<dsimic>
it isn't up to overlays, but about the driver support
<dsimic>
let me repeat: there's been work to have it supported for A2-rated cards as well, but I'm unaware of that work progressing to the point where support is actually available in the mainline kernel
<Dex2x>
ah gotcha
<dsimic>
one of the crippling factors to have it supported in the mainline kernel is the lack of hardware support for command queueuing on the MMC interfaces that go to microSD card slots on various SBCs
<dsimic>
thus, even when the support eventually lands into mainline, many SBCs will end up having next to no speed improvements :/
<dsimic>
which is why A1-rated cards are a much safer choicea anyway
<dsimic>
s/choicea/choice/
<dsimic>
to sum it up, there are a few reasons why I recommended A1-rated cards from the beginning :)
<dsimic>
it has also reminded me to go back to fixing some old bugs in the mmc drivers
<Dex2x>
interesting with the emmc removed and just the sdcard I still see mmc0: CQHCI version 5.10
<dsimic>
oh, and when you unmount a microSD card, don't eject it immediately... they may need some time to flush some internal caches, and the MMC specification allows the cards to do that at virtually any time... give it half a minute or so before ejecting
<dsimic>
which board is that?
<Dex2x>
orangepi 5 ultra
<Dex2x>
want to see the dmesg output?
<Dex2x>
dsimic, regarding the flush, does not `sync` not help?
<dsimic>
just a moment, please...
<dsimic>
running sync doesn't help, because cards manage their caches internally and invisibly
<dsimic>
even when told to flush caches and prepare to be ejected, the spec for some strange reason allows them to not do that entirely
<dsimic>
IOW, maybe most cards don't need time to simmer down, but the spec allows them to need some time
<Dex2x>
the dmesg is very different with an edge kernel vs vendor
<dsimic>
those aliases define what are actually mmc0 and mmc1 on the OrangePi 5 Ultra
<dsimic>
mmc0 is the MMC interface that supports command queueuing, i.e. it supports eMMC 5.1
<dsimic>
while mmc1 is the MMC interface intended for microSD cards, and it supports eMMC 4.51 only, so there's no command queueing on it
<dsimic>
which also explains why are you getting "mmc0: CQHCI version 5.10" -- it's the same as for the MMC interface I'm getting it on
<dsimic>
it just shows what the interface is capable of
<dsimic>
the vendor kernel seemingly shows that regardless of the mmc0 interface being populated or not, which is somewhat confusing, but the mainline doesn't display that message when the interface isn't actually in use, so we're fine there
<dsimic>
regarding why some of the official RPi microSD cards are A2-rated, who knows, maybe they're prepping for the future :)
<dsimic>
also, maybe those cards actually satisfy the A1 rating even with no host-side support in place -- the RPi Foundation could have tested it and selected those cards carefully and accordingly
<dsimic>
it would be very interesting to research does the MMC interfaces that the microSD cards are attached to on different RPis models actually support command queueuing, i.e. do they actually support the eMMC 5.1 standard
<dsimic>
perhaps they do, because some RPi SoMs come with soldered eMMC chips, so it's reasonable to expect full support for eMMC 5.1 there; perhaps the same MMC interface is used for microSD cards on the Model-B RPis
<dsimic>
s/RPis models/RPi models/
<dsimic>
s/queueuing/queueing/
<dsimic>
s/research does the/research do the/
<dsimic>
sorry for the typos and fixes... got those messages edited before hitting <Enter>, but not entirely
<dsimic>
actually, I'll probably have to work (yuck! :) with a couple of Raspberry Pi 4 boards soon, together with a couple of Kingston high-endurance A1-rated microSD cards, and I'll pay close attention to how do the cards end up working
<dsimic>
perhaps there's just the "mmcX: CQHCI version 5.10" message printed, so people wrongly take that as A2 being supported
<CounterPillow>
people still believe the RPi """Foundation""" thing? They're a corporation, the foundation is just there for accounting tricks to do tax evasion.
<dsimic>
Dex2x: as I wrote above, that just shows what the controller is capable of, see also the link below
<dsimic>
Dex2x: diederik: believe it or not, :) the RPi kernel does enable A2 cards, and I'm unable to find those patches submitted anywhere for upstreaming
<Dex2x>
o.0
<Dex2x>
that much has then happened end of last year, start of this
<Dex2x>
I wonder what speeds it gets
<dsimic>
thus, this is a great opportunity to have those code additions researched further, possibly reworked a bit and, hopefully, submitted upstream, for everyone's benefit :)
<dsimic>
only a couple of A2-rated cards are whitelisted for having the command queueing enabled, though
<Dex2x>
oh so "vetted" ?
<Dex2x>
Or just rpi , picking their brand?
<dsimic>
I'll be happy to research all that further and work on getting all that upstreamed
<dsimic>
yes, basically just the RPi cards are allowed to have that feature enabled
<Dex2x>
I can test on a couple of orangepi 5's
<dsimic>
I'm afraid we'll need boards that have command queuing available on their microSD slots
<dsimic>
which means... RPis :/
<dsimic>
but we'll see after I dive a bit deeper into all that
<dsimic>
it's really, _really_ strange that those patches haven't been submitted upstream yet, but I guess that's how RPi "Foundtaion" operates
<dsimic>
s/Foundtaion/Foundation/
<Dex2x>
well.. given they only white listed their A2 cards : /
<dsimic>
I'll also have to shell out some bucks to get a few A2-rated cards