<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?