<lvrp16>
adema: you need the DDR4 initialization bits
<adema>
Can you point toward commits in firefly ? Or anywhere else with valuable info ?
<adema>
lvrp16, to be clear, the u-boot i built boots, it just can't read the sd card to look for partition where the kernel lives.
<lvrp16>
there's a commit(s) in firefly's tree that control UHS on the MicroSD card. it is different than every other RK3328 in that regards since it supports 50MB/s instead of 25MB/s
<lvrp16>
it is probably that
<adema>
Oh OK, even rock64 is different ?
<adema>
I mean, roc-cc is even different from rock64 ?
<lvrp16>
rock64 doesn't support UHS since it doesn't support the 1.8V mode switch
<lvrp16>
it's stuck at 3.3V
<adema>
Ah ok makes sense
<lvrp16>
since it's missing the voltage switch line
<lvrp16>
it's just another TV box design
<adema>
Ok
<adema>
Thankyou
<adema>
"plat->cfg.host_caps |= MMC_MODE_DDR_52MHz;" could it be related ?
maz has joined #linux-rockchip
<Ke>
eballetbo: you were ccd in my cros-ec patch, do you have any chance of pushing things forward before 4.19.0
<Ke>
or what sort of response time is there normally, I know 3 days over the weekend is not much though
<eballetbo>
Ke: oh, sorry, thanks for pinging me here because I missed your patch, found it now. I will try to take a look this afternoon.
<Ke>
thanks
<Ke>
eballetbo: note the later patch is most probably better
<Ke>
or latter I guess, though it's later in time
<Ke>
I changed the patch name, because the old name would have contained false information...
<eballetbo>
so the correct is the one that changs the memcpy line, right?
<lvrp16>
weird that they would revert the whole thing when one boadd cant handle it
<adema>
Should the frequency by set up in the devicetree ?
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
<eballetbo>
Ke: from a quick look, the patch fixes the issue. But looks weird to me that event_size is ret - 1 but copies ret bytes to event_data, I think we're missing something here
<eballetbo>
IIUC event_size should be exactly the size of event_data
<eballetbo>
Looking at the downstream chromeos kernel they solve the issue in a different way, something like this:
<Ke>
so ret is the len of the whole struct but event_size is the size without the header? event_size
<Ke>
eballetbo: are you going to push the chromeOS fix or what, some fix would be preferred
<eballetbo>
I only did a quick look, give me some more time to look deeper
<Ke>
should probably pull in that kernel to see the commit
<eballetbo>
I'll try to push Benson to include some fix in current version
<eballetbo>
I think that he will be more happy and more easy to convince if the fix is close to what the downstream kernel does
<Ke>
sure
turkerali has joined #linux-rockchip
turkerali has quit [Quit: Page closed]
JohnDoe_71Rus has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 252 seconds]
vagrantc has joined #linux-rockchip
maz has quit [Ping timeout: 244 seconds]
vicencb has quit [Quit: Leaving.]
vicencb has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 245 seconds]
hanetzer has quit [Remote host closed the connection]
hanetzer has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
steev has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
ldevulder has quit [Ping timeout: 252 seconds]
afaerber has quit [Quit: Leaving]
busterbcook has quit [Ping timeout: 260 seconds]
busterbcook has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
alyssa has joined #linux-rockchip
<alyssa>
Is "--hwdec rkmpp" expected to Just Work (TM) on mpv/RK3399/ChromeOS kernel/GNU/Linux?
<alyssa>
Passing it doesn't seem to cause any effect whatsoever, but maybe it's because decoding is not the bottleneck so I don't notice ^_^
matthias_bgg has quit [Ping timeout: 272 seconds]
<ramcq>
chrome OS kernel will use v4l2-slice
<ramcq>
not MPP
<ramcq>
rockchip kernels have two userland APIs for the same thing, all of the rklinux kernels/etc default to MPP and they have userland patches for stuff, gst elements, etc
<ramcq>
chrome OS only supports v2l
<ramcq>
er, v4l
<alyssa>
...ah
<alyssa>
I would think v4l is better supported, no?
<ramcq>
it's not standard v4l, the decoder chip is stateless - you have to maintain the state in the decoding process and pass it back along with each request
<ramcq>
it's conceptually what the kernel now has as v4l requests, aiui
<ramcq>
the CrOS rk implementation predates that standardisation
<ramcq>
maybe it will turn to v4l requests later
<alyssa>
Fair enough
<alyssa>
In that case, out of scope for me to worry about. Thanks for the info :)