<robmur01>
mmind00: you mean just hang a generic "vd-supply" property directly off power domain nodes as needed rather than adding "vd-gpu-supply" etc. at the top level (like for io-domains) and modelling the real voltage domain hierarchy?
<robmur01>
I guess that would work well enough, and avoid unnecessary complication, since realistically it's probably only VD_GPU on 3399 and 3288 that's ever likely to have the chance of being turned off
jelly-home is now known as jelly
matthias_bgg has quit [Ping timeout: 260 seconds]
alpernebbi has quit [Read error: Connection reset by peer]
alpernebbi has joined #linux-rockchip
field^Mop has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #linux-rockchip
kaspter has quit [Quit: kaspter]
matthias_bgg has quit [Ping timeout: 260 seconds]
<mmind00>
robmur01: yeah, that was sort-of my wine-induced thought yesterday evening ;-)
matthias_bgg has joined #linux-rockchip
<mmind00>
robmur01: though now without wine, I guess doing in a way similar to io-domains also looks interesting
<mps>
I have this in dmesg output 'cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2'
<mps>
anyone know where can be found this firmware which can loaded?
<mps>
or, the problem is maybe something else
<robmur01>
mps: presumably you're loading the driver before /lib/firmware/ is mounted and available?
<stikonas>
or linux-firmware is not installed
<mps>
no, driver and firmare are on the same root FS
<stikonas>
although, you only need that firmware for high resolution displays...
<stikonas>
1080p seem to work fine without firmware
<stikonas>
well, I don't have it on my system, can't compare sizes, but permissions look alright
<stikonas>
yeah, I think 2400x1600 is probably too much
<mps>
stikonas: display works, but is somewhat slow with panfrost driver loaded
<mps>
btw, firmware is from latest linux-firmware
<robmur01>
mmind00: on reflection, my main concern with the full-voltage-domain model (other than being a fair bit of work for virtually no gain) is how to refcount/claim supplies when the relevant power domains aren't managed by the kernel itself
<robmur01>
after a while, "regulator-always-on" starts looking like the most elegant and appropriate option :)
<stikonas>
mps: oh so I think you are fine then
<mmind00>
robmur01: haha yeah
<mps>
stikonas: heh, yes. mostly :)
<mps>
could it be because driver is built in kernel and not as module?
<stikonas>
yes
<stikonas>
if it's loaded early
<stikonas>
and firmware is not in initramfs
<mps>
initramfs doesn't exist, only kernel and all modules and firmware on rootFS
<mps>
looks like have to 'build' firmware 'in-kernel'. thanks all for hint
<robmur01>
OK, builtin drivers are probed before root is mounted, which is what I was getting at 10 minutes ago
ldevulder has quit [Remote host closed the connection]