mmind00 changed the topic of #linux-rockchip to: Rockchip development discussion | public log at https://libera.irclog.whitequark.org/linux-rockchip
stikonas_ has quit [Quit: Konversation terminated!]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 244 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
Daanct12 has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
vagrantc has joined #linux-rockchip
Daanct12 has quit [Ping timeout: 246 seconds]
Daanct12 has joined #linux-rockchip
hexdump0815 has quit [Ping timeout: 260 seconds]
hexdump0815 has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
gnuiyl has joined #linux-rockchip
<naoki> Kwiboo: is there any checkboard() for rk3399? ;)
Daanct12 has quit [Ping timeout: 248 seconds]
Daanct12 has joined #linux-rockchip
Daanct12 has quit [Ping timeout: 260 seconds]
Daanct12 has joined #linux-rockchip
LordKalma5 has joined #linux-rockchip
qschulz_ has joined #linux-rockchip
micken has quit [Ping timeout: 260 seconds]
qschulz has quit [Ping timeout: 260 seconds]
LordKalma has quit [Ping timeout: 260 seconds]
LordKalma5 is now known as LordKalma
micken has joined #linux-rockchip
<mmind00> naoki: I'd say the platform_set_drvdata is too low (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c#n1128) ... i.e. right now it comes after the devm_pm_runtime_enable
<mmind00> naoki: platform_set_drvdata can move way up shortly after allocating the hdptx struct, to pevent that issue
raster has joined #linux-rockchip
<naoki> mmind00: thanks... I don't understand (yet) what platform_set_drvdata does
<mmind00> naoki: it "just" attaches the struct to the device ... i.e. platform_set_drvdata is just a wrapper around the more generic dev_set_drvdata
<mmind00> naoki: the driver links that hdptx struct to the device instance ... and a later function can than retrieve that struct again, simply by knowing the device instance ... which the runtime-pm functions do (look for the dev_get_drvdata there)
<naoki> devm_pm_runtime_enable should be lower? just before reset_control_deassert
<mmind00> naoki: no ... platform_set_drvdata should be higher
<mmind00> hmm, or both? ... need another look
<naoki> ah, I understand about it
<naoki> I just thought devm_pm_runtime_enable() really can be called if probe is failed
<naoki> there are 2 error return after devm_pm_runtime_enable()
<mmind00> devm_pm_runtime_enable() will do the disable automatically if probe fails
<naoki> oh, I see
<naoki> mmind00: I'll try to move platform_set_drvdata, but it seems it's not 100% reproducible, I need to find out reliable way to make that oops ;)
<mmind00> naoki: the not-reproducible thing is understandable ... i.e. once phy_create and and phy_provider_register have run, another driver _can_ request the phy at any time
<mmind00> naoki: so things then depend on timing, hence you don't see it all the time
<mmind00> naoki: for the same reason that reset handling in there also looks fishy ;-) ... they get deasserted (and never asserted), _after_ phy_provider_register ... so some driver could already request the phy before they actually get deasserted
<naoki> hehe, lately I don't read/write any kernel driver, it's a little difficult to understand them ;)
warpme has joined #linux-rockchip
raster has quit [Read error: Connection reset by peer]
raster has joined #linux-rockchip
ldevulder has joined #linux-rockchip
qschulz_ is now known as qschulz
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
stikonas_ has joined #linux-rockchip
stikonas_ has quit [Client Quit]
<linkmauve> Hi, when I run my game (https://pytouhou.linkmauve.fr) in unlimited framerate more, on Weston, my Rock-5B does a lot more coil while than in idle, is that a known issue?
<linkmauve> I’m running latest mainline as my kernel, outputting to HDMI.
<linkmauve> whine*
<linkmauve> It takes 2:08 to complete the entire game in invincible mode. For reference on my Kaby Lake laptop it takes 1:23.
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linkmauve> It is as usual fully CPU-limited, still being single-core.
<linkmauve> Running at 1000~2000 fps on that board still.
<linkmauve> 2:00 exactly on the second run, 8s of those were spent on loading assets from the microSD probably.
<linkmauve> There is also slightly more coil whine when Weston is running and displaying things to HDMI, than when it isn’t.
eballetbo has joined #linux-rockchip
warpme has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
psydroid has joined #linux-rockchip
dsimic has quit [Ping timeout: 264 seconds]
dsimic has joined #linux-rockchip
<robmur01> linkmauve: So, doing more draws more power than doing less? Yes, I think that is known ;)
<robmur01> also it's probably safe to assume that nearly all SBC power supply designs and optimised for cheapness/board area rather than end user auditory experience
<robmur01> s/and/are/
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stikonas_ has joined #linux-rockchip
warpme has joined #linux-rockchip
stikonas_ has quit [Quit: Konversation terminated!]
Daanct12 has quit [Quit: WeeChat 4.4.3]
<naoki> rfkill-gpio shutdown-gpios really working? it doesn't change gpio state
jakllsch has quit [Ping timeout: 260 seconds]
jakllsch has joined #linux-rockchip
<naoki> ah
<naoki> # CONFIG_RFKILL_GPIO is not set
psydroid has quit [Remote host closed the connection]
xha has quit [Quit: WeeChat 4.4.3]
xha has joined #linux-rockchip
naoki has quit [Quit: naoki]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
raster has quit [Quit: Gettin' stinky!]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 255 seconds]
kevery1 is now known as kevery
<linkmauve> robmur01, I’m used to a slight coil whine, here it’s LOUD. :/
<qschulz> linkmauve: I had this too on our RK3588 devices, don't remember if upstream, downstream or both kernels
<qschulz> yes, it's bothered me as well
<qschulz> does anyone know why we hardcode the size of the SPL to less than the size of the SRAM in U-Boot?
<qschulz> shouldn't it just not matter?
<qschulz> TPL should fit in RAM
<qschulz> SRAM
<qschulz> then we go back to BootROM
<qschulz> SPL should fit in SRAM
<linkmauve> I haven’t tried downstream ever yet, only mainline.
<qschulz> or is the whole thing read at once by the BootROM somehow?
<qschulz> so the whole thing should fit in SRAM
<qschulz> but if that's the case, why caring about TPL or SPL size, we only should care about TPL+SPL?
<qschulz> oooooh, or TF-A? SPL loading TF-A into SRAM, therefore needs some free space for that?
<qschulz> no, an earlier commit for RK3399 says SRAM - whatever's used by BootROM
vagrantc has joined #linux-rockchip
<Kwiboo> qschulz: TPL must fit in SRAM, go back to bootrom that loads SPL to start of DRAM, however SPL typically load TF-A to <start of DRAM> + 256 KB, so SPL must not take up more than 256 KB or SPL may overwrite itself
<Kwiboo> part of sram is also used as stack by bootrom, and the reason why tpl cannot take up full sram
<qschulz> Kwiboo: not sure how this can apply to RK3588 with its 1MiB of SRAM?
<qschulz> does Rockchip document how much the bootrom takes out of the SRAM?
Stat_headcrabbed has joined #linux-rockchip
psydroid has joined #linux-rockchip
<Kwiboo> qschulz: no idea, last time I tried to ajust the sizes I ended up just syncing from vendor u-boot: https://lore.kernel.org/r/c53380e2-1770-9f38-86b2-1671199e4780@rock-chips.com/
<Kwiboo> and for rk3066 there is some bootrom logic that may limit how much is loaded: https://patchwork.ozlabs.org/project/uboot/patch/20230217205247.3402473-5-jonas@kwiboo.se/ so possible rk3588 also has some sort of limit in bootrom
<Kwiboo> vendor u-boot commits sometime contain information about the stack size: https://github.com/rockchip-linux/u-boot/commit/ed2791773ea1539f48aa90110f5d207006db818a
<qschulz> Kwiboo: thanks for the pointer :)
<qschulz> Kwiboo: it's a bit hit and miss commits in Rockchip's vendor trees :)
<qschulz> so you never know what you should really take at face value :/
<Kwiboo> hehe, so true :-)
raster has joined #linux-rockchip
raster has quit [Client Quit]
raster has joined #linux-rockchip
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
stikonas has joined #linux-rockchip
warpme_ has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
System_Error has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
System_Error has joined #linux-rockchip
warpme_ has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
ldevulder has quit [Quit: Leaving]
dliviu has quit [Quit: Going away]
dliviu has joined #linux-rockchip
psydroid has quit [Remote host closed the connection]