Stat_headcrabed has quit [Ping timeout: 240 seconds]
wiagn is now known as Stat_headcrabed
Stat_headcrabed has quit [Ping timeout: 255 seconds]
shreyasminocha has quit [Write error: Broken pipe]
sm2n has quit [Write error: Broken pipe]
jleightcap has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
yyp has quit [Remote host closed the connection]
keegans has quit [Remote host closed the connection]
pld has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
keegans has joined #riscv
yyp has joined #riscv
pld has joined #riscv
sumoon has joined #riscv
jleightcap has joined #riscv
sm2n has joined #riscv
shreyasminocha has joined #riscv
vagrantc has joined #riscv
prabhakarlad has joined #riscv
billchenchina- has joined #riscv
billchenchina has quit [Ping timeout: 240 seconds]
* bjdooks
wonders if it would be useful to have cmo/cboz tracing in riscv
* bjdooks
wonders if it would be useful to have cmo/cboz tracing in riscv qemu
* muurkha
wonders if it would be useful to have cmo/cboz tracing in riscv mainline qemu
enoq has quit [Quit: enoq]
catcream has joined #riscv
Dyskos has joined #riscv
<conchuod>
Esmil: So, went looking at (what I think is) the sound clocks. I think it's actually "worse" than them potentially being optional if someone doesn't care about audio - I think all of the clocks from from i2stx_bclk_ext on down are entirely optional even if you do want audio based on the muxes in the driver.
jmdaemon has quit [Ping timeout: 264 seconds]
<conchuod>
I might not reply today because I would like to try to have a suggestion for how to fix the binding before I reply, but looks like there are options for internal v external for each of those clocks and populating the external ones is not mandatory.
<Esmil>
conchuod: Cool, thanks. That's exactly what I was worried about
<conchuod>
Esmil: yah, kinda annoying I suppose that it is that way, but I'm not super keen on how the binding looks at the minute anyway so not the end of the world...
<conchuod>
I'm already replying to the series, I'll have a gander at the docs and can tack that that one on too
<conchuod>
thanks
<jrtc27>
very aware of this side of things as starfive's own uboot completely screws this up
<jrtc27>
(their s7 is marked as a u74 with sv39 and status okay, which means OSes try to start it..)
<jrtc27>
(which would be okish... except doing so crashes their opensbi, because it doesn't know it shouldn't allow that request)
<conchuod>
Yeah, I saw some GH issue you filed about that last week I think.
<jrtc27>
ah ok
pedja has quit [Remote host closed the connection]
<conchuod>
jrtc27: Didn't bother digging up the old versions of the u74-mc docs but yah - latest version says S7 only has machine and user mode
<conchuod>
jrtc27: I replied to the u-boot one too, can't retroactively prevent the boards shipping that way, but that'll prob help you out for BSD more than the linux dts..
<jrtc27>
I mean the bindings will be junk too so eh
<jrtc27>
in general
prabhakarlad has quit [Quit: Client closed]
<jrtc27>
step 0 is going to always be to update firmware from the pile of crap they ship with
<conchuod>
I made the same sort of mistakes with polarfire stuff, unless you send the stuff upstream before you ship, it's inevitable :/