ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log | Community GH | Rockchip GH | ML
vstehle has quit [Ping timeout: 244 seconds]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #linux-rockchip
vstehle has joined #linux-rockchip
pingcrash__ is now known as pingcrash
matthias_bgg has joined #linux-rockchip
<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?
<eballetbo> s/changs/changes
<Ke> yes
<Ke> also the one that has signed off by
vicencb has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
<adema> :(
vicencb has joined #linux-rockchip
<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> but it has the same missmatch?
<Ke> doesn't that struct have one byte type header
<Ke> obviously it fixes the problem, yes
<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 :)
alyssa has left #linux-rockchip [#linux-rockchip]
paulk-leonov has quit [Ping timeout: 252 seconds]
paulk-leonov has joined #linux-rockchip