03:06 <jevinskie[m]> That’s cool!

11:32 <sven> nice!

20:55 <jeffmiw> I have a basic SPMI/PMU/RTC drivers implementation almost ready, what is the best way to proceed ? I create a branch on asahi/linux for reviews and testing (I only have an mba, should work on the other with little or no changes but to be confirmed) before submitting upstream ?

20:55 <jeffmiw> this will be my first submission, so I'm sure asahi team feedback will be valuable before submitting :)

21:01 <kettenis> we don't have a mailing list (yet) so a branch on github is probably te next best thing

21:18 <jeffmiw> ok thanks, I will do that

22:21 <povik> i tuned the mmio power-domain sweep a bit and saved it on wiki: https://github.com/AsahiLinux/docs/wiki/HW:Memory-map#mmio-ranges-that-respond-to-probe-reads-t8103

22:24 <alyssa> povik: Awwh! nice work :-)

22:25 <alyssa> By the way, my speakers have been working reliably now. Idk

22:25 <alyssa> definitely something screwy happening but not sure what

22:31 <povik> thanks :)

22:31 <alyssa> The drivers have passed the "Legally Blonde" test

22:31 <povik> weird with the speakers. could we have been so unlucky on the first try?

22:31 <povik> not that i don't want to fix the issue, even if it scarcely manifests

22:31 <alyssa> maybe.. or some state persisting across boots...

22:32 <alyssa> random theory, can't remember if this applies here but plausible-- Related to whether the boot chime is enabled or not

22:33 <alyssa> If it is, iBoot did config or powered something on or something that Linux forgot

22:33 <alyssa> If it's not that idk what other race it would be

22:33 <alyssa> s/race/issue/

22:36 <tpw_rules> i only ever got sound to work once

22:36 <povik> yeah post that dmesg please

22:37 <alyssa> povik: https://github.com/AsahiLinux/linux/blob/asahi/sound/soc/codecs/cs42l42.c#L2119

22:38 <alyssa> this is what failed for me, for whatever it's worth

22:38 <alyssa> when I commented out the whole device ID block, `regmap_read(cs42l42->regmap, CS42L42_REVID, &reg)` failed instead

22:38 <alyssa> which to me smells like the CS42L42 is just powered off

22:39 <povik> the only idea i had is that the cs42l wasn't in reset when linux booted because of the state of the respective gpio

22:39 <povik> and then the driver pulls the reset for too short

22:39 <povik> which means the part is in a weird state

22:39 <povik> let's see the driver code again if that's possible

22:40 <povik> yeah, i wonder if it's possible that lines 2087 to 2096 generate a narrow reset pulse

22:40 <povik> if the codec isn't in reset to begin with

22:42 <povik> i guess the gpio line is untouched before some driver calls gpiod_get_optional

22:42 <povik> shame we can't reproduce it

22:43 <povik> well but i can try changing the gpio before linux boots :)

22:43 <alyssa> grumble

22:43 <alyssa> Ooh, true

22:46 <povik> no breakage here

22:46 <povik> let me try couple more times

22:49 <povik> nope, didn't reproduce

22:50 <povik> let's try changing that usleep_range to udelay

22:50 <povik> oh i already tried that, that's what i am running

22:50 <povik> :)

22:50 <alyssa> idk :(

22:50 <povik> one day...

23:01 <povik> even if i put the codec in an unresponsive state by messing with its clocking, and leave the gpio in the bad state, that narrow pulse linux does is enough to recover

23:01 <povik> alyssa: how did you do it ?!

23:02 <alyssa> povik: i'm cursed

23:02 <povik> i'm short on other explanations

23:18 <alyssa> witchcraft