ModR\M has quit [Remote host closed the connection]
ModR\M has joined #asahi-dev
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
ModR\M has quit [Remote host closed the connection]
ModR\M has joined #asahi-dev
ModR\M has quit [Remote host closed the connection]
<chadmed>
marcan: i think those regs count up in microjoules
<chadmed>
if i take the difference before and after running bench and divide by the elapsed microseconds, i get values in microwatts that are very very similar to the values i got from the SMC for the pstates where that worked
<chadmed>
seems true for the firestorm cores at least, im not too sure on the cluster counters or icestorm since i couldnt verify with the SMC but they behave roughly how i'd expect them to (i.e. the values arent totally insane)
<chadmed>
surely they wouldnt count in non-reasonable units (tens/hundreds of microjoules, etc)
<chadmed>
yeah im only really unsure about the p cluster value
bisko has joined #asahi-dev
<marcan>
it's possible the init is still wrong
<chadmed>
yeah
<chadmed>
im only unsure because i refuse to believe the entire cluster is only using 200uW on top of the actual core
<chadmed>
even though the numbers line up with what i had from the SMC...
bisko has quit []
<chadmed>
the second p cluster on the m1 max gives the exact same values too
<marcan>
I assume you duplicated the init for the p cluster onto the second one?
<marcan>
(including all the hardcoded stuff that wasn't properly broken out)
<chadmed>
yeah so im not surprised it would give the same results, just wanted to check
<marcan>
let me see if I can de-uglify the init and make sure I didn't miss anything
<chadmed>
ack
<chadmed>
i know at least that final set64 is unnecessary, because i didnt copy it and the second cluster still gave me the same values
ModR\M has joined #asahi-dev
<chadmed>
setting it didnt affect the numbers either
<marcan>
I'll probably make m1n1 init this eventually since it probably makes sense for it to deal with this and let Linux just read the data
<chadmed>
yeah of course
<chadmed>
having sane data at this stage at least lets us bring EAS online without having to anything dodgy in cpufreq
<chadmed>
just update the opp tables and let register_em_with_opp() deal with it (which currently silently fails since we dont have enough data for it in the dt)
<marcan>
sure :)
bisko has joined #asahi-dev
fetsorn has joined #asahi-dev
fetsorn has quit [Remote host closed the connection]
bisko has quit [Ping timeout: 480 seconds]
nuh^ has joined #asahi-dev
nsklaus has joined #asahi-dev
nuh^ has quit [Ping timeout: 480 seconds]
ModR\M has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
jeffmiw has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
bps has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
jeffmiw has joined #asahi-dev
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
<jannau>
dcp is strange, on the internal display (mbp 14") a modeset (changing just the refresh rate) causes freeing and reallocating of buffers. That doesn't happen on mac mini or mac studio on mode changes
nuh^ has joined #asahi-dev
<Dcow[m]>
what about m1 air or mbp13 ?
<jannau>
ENODEV
<jannau>
the annoying part is that dcp crashes after what I believe is the last re-allocation
pashencija[m] has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
nuh^ has quit [Ping timeout: 480 seconds]
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<jannau>
issue was unrelated to the buffer allocation
ModR\M has joined #asahi-dev
ModR\M has quit [Read error: No route to host]
ModR\M has joined #asahi-dev
bps has joined #asahi-dev
ModR\M has quit [Read error: No route to host]
ModR\M has joined #asahi-dev
kov has joined #asahi-dev
scientist has joined #asahi-dev
ModR\M has quit [Ping timeout: 480 seconds]
unevenrhombus[m] has quit []
unevenrhombus[m] has joined #asahi-dev
unevenrhombus[m] has quit []
unevenrhombus[m] has joined #asahi-dev
bisko has joined #asahi-dev
bisko has quit [Ping timeout: 480 seconds]
<j`ey>
marcan: im assuming you know about pwm?
<j`ey>
does "@period: PWM period (in nanoseconds)" mean the entire off and on period?
<j`ey>
and "@duty_cycle: PWM duty cycle (in nanoseconds)" is the portion of the '@period' where it's on
<marcan>
correct, I would say
<marcan>
duty cycle is more often a fraction but if it says nanoseconds then it's relative to period
<j`ey>
that makes somewhat sense then.. for some reason I thought 'period' was the off period
<j`ey>
(up until now, and was getting confused by the code)