01:14 <marcan> jannau: the t6000 support was added later and not everywhere yet

01:16 <marcan> sorry about that :(

03:50 <marcan> sven: if you have a chance, can you send out the watchdog patch with the MAINTAINERS split? I think it's ready for Guenter to merge otherwise

03:54 <marcan> actually, I'll go ahead and merge in the binding already

06:32 <jannau> marcan: no problem. I should have checked earlier. I saw it was handled in from_adt() and assumed it was ok

06:56 <jannau> marcan: did you forget to include Ben in TO/CC in https://lore.kernel.org/all/20211207064019.61444-1-marcan@marcan.st/

07:15 <marcan> ... I'm an idiot. sigh.

07:15 <marcan> jannau: thanks

08:45 <sven> marcan: sure, i'll do it this evening

08:46 <sven> i can also include the commit that adds the watchdog node while i'm at it

08:54 <marcan> sure :)

11:58 <marcan> just pushed aic2 with a cleaned up take on the AICv2 support. There's one thing missing: I'm not sure how to get the true supported die count from the hardware :/ (to compute all the register offsets properly)

11:58 <marcan> I have a guess but I'm not sure if it's right...

12:03 <maz> worse case, make it explicit in DT.

12:06 <j_ey> marcan: 'start_off' looks unused fca0a653bb4b9a161781b0dd01e0eadd83ecf904

12:12 <marcan> ah yeah, that gets used in the next commit

12:12 <marcan> maz: yeah, heh

12:12 <marcan> what apple do instead is... specify the event register offset in the DT

12:12 <marcan> which I think I like even less

12:13 <marcan> (that's the only register which would have to be computed based on max dies; its location seems to be after all the IRQ control registers, rounded to page size)

13:29 <maz> marcan: we need to find a way to expose the E/P affinities in DT one way or another.

13:29 <maz> so that the PMU interrupts can be discriminated.

14:05 <marcan> maz: I was going to ask about that; isn't it the same IRQ anyway? why does the PMU driver need separate IRQs for E/P if they're percpu anyway?

14:41 <marcan> also, looks like the PERST changes haven't been merged yet? is anything holding that up?

14:46 <_jannau_> a discussion about how the dts change is handled was but it looks on track now https://lore.kernel.org/linux-arm-kernel/20211207101621.GA466@lpieralisi/

14:50 <marcan> good to hear that

16:07 <maz> marcan: that's the standard big-little horror. the core PMU code uses the interrupt affinity to find out about the PMUs that are compatible. E/P PMUs are obviously incompatible (they count different things), so you have to segregate them.

16:08 <marcan> ugh.

16:09 <maz> otherwise, you can't tell. they all have the same programming model, and count events similarly numbered. but the semantics of the events are can be radically different (they are on ARM cores, less so on Apple).

16:09 <marcan> aside: just pushed a bunch of DT schema changes to asahi, enough to keep the checker happy about all the t6k stuff except NVMe/SART. cc kettenis in case you want to take a look; I'll probably fire off all the easy ones (everything but AIC2) as a series tomorrow

16:10 <marcan> maz: using IRQ affinity just seems like such a hack for this...

16:11 <marcan> but anyway, I think Apple are probably going to stick with that Aff2 thing for quite a while, they use it all over the place (and so does m1n1)

16:11 <marcan> so I'm okay with going with that

16:12 <maz> marcan: big-little is a terrible hack overall. shame it has spread...

16:12 <marcan> heh :)

16:15 <kettenis> maz: now that it has spread to x86, you can share te pain with lots more people ;)

16:15 <marcan> ha

16:16 <roxfan> where in x86?

16:16 <ar> roxfan: new intel stuff

16:16 <j_ey> alder lake

16:16 <ar> but at least one x86 cpu vendor still claims they won't do big.little ;)

16:17 <roxfan> TIL

16:17 <marcan> it's so amazing it broke some game DRM because it thought you were randomly swapping out your CPU

16:17 <marcan> ... and apparently Intel's official workaround is a BIOS hack to use the scroll lock key to disable half the cores. yes, really.

16:18 <maz> the positive thing is that someone found a use for this key!

16:18 <marcan> hey, I use it to trigger my screen lock!

16:18 <maz> ah!

16:18 <ar> you can also do the windows equivalent of taskset

16:18 <marcan> scroll lock, screen lock, close enough right?

16:18 <marcan> ;)

16:19 <ar> to pin the game in question to p-cores

16:20 <maz> my laptop has a dedicated 'print screen' key. I use it to locate the mouse pointer...

16:20 <marcan> heh :)

16:20 <marcan> I use Pause to trigger krunner (i.e. quick run app/command)

16:20 <marcan> Print screen does trigger screen capture

16:21 <marcan> though... I have to shamefully admit I've gotten too used to the macOS command-shift-{3,4} thing, and I've started to replicate it on my Linux installs...

16:22 <marcan> will be convenient once I actually move to these laptops though, since those definitely don't have a Print Screen key

16:22 <roxfan> will they have diffrent cacheline sizes?

16:23 <marcan> ok, off to sleep. Finally managed to catch up on a bunch of kernel stuff today... I believe tomorrow I have a SPI reversing stream to do, and a couple more kernel mails to read/send out.