Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Stat_headcrabbed has joined #linux-rockchip
eballetbo has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
hipboi has quit [Quit: hipboi]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
naoki has joined #linux-rockchip
warpme has joined #linux-rockchip
naoki has quit [Quit: naoki]
a1batross has quit [Ping timeout: 248 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
psydroid has joined #linux-rockchip
dsimic has quit [Ping timeout: 265 seconds]
dsimic has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
vagrantc has joined #linux-rockchip
<qschulz>
if someone sees naoki on the chan, U-Boot next branch has now DT synced with 6.11 which is something they wanted to do themselves
<tlwoerner>
i'm curious to know if anyone is working on hdmi output support for the radxa zero 3? (i'm using the 3e specifically)
<tlwoerner>
the most recent kernel i've tried is 6.11-rc6 and nothing shows up on the hdmi while booting (no signal)
<tlwoerner>
i can help with testing
<Kwiboo>
tlwoerner: hdmi worked for linux when I sent the DTs, booting using mainline u-boot and latest rc and/or next kernel back in april, not sure if I have tested hdmi using newer kernel version on my zero 3w/3e boards since then
<macromorgan>
tlwoerner: mainline A-TF or binary A-TF?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tlwoerner>
macromorgan: currently binary
<tlwoerner>
Kwiboo: okay, thanks
<macromorgan>
interesting... no idea then. There was a minor change in upstream A-TF, but I haven't observed it causing any problems in Linux (only in U-Boot under very rare circumstances that seem to be unique to one of my boards)
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
<tlwoerner>
macromorgan: do you have hdmi working on your radxa zero 3e?
<macromorgan>
I don't have one of those, I have a series of handheld devices with HDMI... I'll test it in a minute to confirm it's still working.
<diederik>
mmind00: what's your opinion on 2 interrupts on rk3328.dtsi's hdmi node?
<mmind00>
diederik: that I see two in the dtsi :-P
<mmind00>
diederik: the 2nd one seems to be some sort of wakeup thing?
<diederik>
you added those two ... but the binding only wants to see 1
<mmind00>
I guess we should just drop it for the time being
* mmind00
needs to talk to "git blame" to not reveal such delicate things ;-)
<mmind00>
I guess that came somewhat verbatim from the vendor kernel
<diederik>
Ok, where (in which documents) can I find info on what IRQs are to be used? (yeah, this is a n00b question)
<mmind00>
diederik: per soc, TRM part one, chapter 2 system overview, System interrupt connection
<diederik>
thanks, going to read that :)
<mmind00>
from checking rk3288, rk3328 and rk3399 both of them have the regular hdmi_irq and the hdmi_wakeup thing, but only rk3328 managed to wrongly have this in its dts
<diederik>
At some point I hope to understand what that means ;-P
<mmind00>
you mean the numbering?
<diederik>
"dts-irq+32 = trm-irq-nr"
<diederik>
no need to explain it (now); if things go well I'll figure it out
<mmind00>
diederik: :-) ... when you look into the rk3399 TRM you see hdmi_irq with number 55 and hdmi_wakeup_irq at 56
<mmind00>
that's just the whole PPI vs SPI gic interrupts ... dts starts both a 0, TRM just continues incrementing
<diederik>
then I better get the rk3399 TRM (I do have one for rk3328)
<mmind00>
diederik: I think rk3399 should've leaked at lot over the years ;-)
<diederik>
ah ok, base numbering difference :)
<diederik>
It's just that I don't have a rk3399 based device, so I saw no need to get it (earlier)
<mmind00>
diederik: for the rk3328, it really is just dropping the 2nd one
<diederik>
I'll check that with the TRM ;-P
<diederik>
ok, tracked down the rk3399 value ...
<diederik>
\o/
raster has quit [Quit: Gettin' stinky!]
sukrutb has joined #linux-rockchip
raster has joined #linux-rockchip
<diederik>
I don't feel comfortable making that change. rk3328, rk3399 and rk3568 all have an interrupt for hdmi and hdmi_wakeup ...
<diederik>
And I don't know if those are just not used or that the binding is incorrect and it should have maxItems: 2 (or sth like that)
raster has quit [Quit: Gettin' stinky!]
raster has joined #linux-rockchip
<diederik>
wakeup ... aka hpd?
<Kwiboo>
tlwoerner: I did a quick test of starting linux v6.11 (with my dw-hdmi + 4k@60hz series) on my zero 3e and I get the linux console on my 1440p screen, and I do not think the additional dw-hdmi + 4k@60hz patches affect anything
naoki has joined #linux-rockchip
<Kwiboo>
did however get a Synchronous Abort after Starting kernel ... using latest u-boot next branch, something to look a little bit closer at, using latest u-boot master works
f476_ has joined #linux-rockchip
f476 has quit [Read error: Connection reset by peer]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<naoki>
qschulz: thanks! currently I'm using master branch with dts v6.11 :)
f476_ has quit [Ping timeout: 265 seconds]
<tlwoerner>
Kwiboo: thanks, i'll take a look at the latest u-boot master. i'm currently using the latest (2024.07)
<tlwoerner>
release
f476 has joined #linux-rockchip
<naoki>
is there any better way to supply power to usb hub without abusing fixed-regulator?
<naoki>
is there any rk35xx which can play sound with es8316?