thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
selene751[m] has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
aleasto- is now known as aleasto
eloy_ has quit [Ping timeout: 480 seconds]
eloy_ has joined #asahi-dev
nico_32_ has quit [Ping timeout: 480 seconds]
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
nico_32 has joined #asahi-dev
<chadmed>
povik: jack works a treat on t6000, slight nitpick though the wind filter control is inverted so that 0 is the strongest and 100 is off
<chadmed>
admac still ends up crashing after a while and knocking out both the jack and internal speakers
<chadmed>
and the internal speakers only output garbage digital noise instead of sound, so maybe a bad i2s clock or something idk
<chadmed>
ridiculous fix for all the other stuff was turning off llvm m1 optimisations...
<chadmed>
which i was not using on the kernel... and not on any kernel-adjacent packages either...
eloy_ has quit [Ping timeout: 480 seconds]
<povik>
16:20 < chadmed> ridiculous fix for all the other stuff was turning off llvm m1 optimisations...
<povik>
hm?
<povik>
what does it fix? and you weren't using it?
<chadmed>
yeah idk i dont really have an explanation for it, but all the issues with module probing and initramfs etc went away when i took -mcpu=apple-m1 out of my make.conf and rebuilt the rootfs
<chadmed>
so some important package was exploding on those optimisations
<dottedmag>
sven: Please tell me how to collect data, I've never used m1n1 before
eloy_ has joined #asahi-dev
<chadmed>
just append -l [path to log file] to run_guest.py then put the log in a gist or something (assuming youre already running a tracer sven sent you or something)
<arnd>
j`ey: yes, I saw the submission, I'm just waiting for marcan to pick them up and send me a pull request to forward to torvalds
<j`ey>
ah ok
jeffmiw has joined #asahi-dev
<marcan>
arnd: Ah, just saw your message here. I replied to rmk saying I'd do it, but you can pick that one up directly if you want. It's trivial and there are no other code changes.
<marcan>
t6k DTs will have to go through me, but if nothing else I need to shove the IOMMU binding patch in front, otherwise we'll end up with non-validating DTs
<Eighth_Doctor>
It'd be great to have those in for 6.1 😁
<marcan>
other than the first patch not having a review by rob I think everything else in there is okay?
<marcan>
but yeah, I'm tired of waiting for the IOMMU series and the binding change is reviewed, so I'll pick that up.
<marcan>
would be nice to get a robher review on #1 in the t6k series :)
<marcan>
Eighth_Doctor: unfortunately until the IOMMU code changes go in, t6k won't actually work to any usable extent with 6.1...
<marcan>
but yeah, let's get the DTs in at least
<Eighth_Doctor>
I'm just ask for less patches to carry 😉
<marcan>
fair :)
<Eighth_Doctor>
s/ask/all/
<Eighth_Doctor>
Though Davide Cavalca is seeing something odd with our attempt to boot our remix image in #asahi:fedora.im
<marcan>
ping me later if I forget, I really should sleep :)
<Eighth_Doctor>
USB boot doesn't seem to work 😦
<Eighth_Doctor>
Will do... I forgot you're in Japan...
<marcan>
Eighth_Doctor: is that a 16K page size or 4K page size kernel?
<Eighth_Doctor>
4k
<marcan>
4K support patches aren't in yet, no surprise that'd be broken
<Eighth_Doctor>
This is 5.19 with your patch tree on top
<Eighth_Doctor>
5.19.9
<marcan>
yeah, which doesn't have those patches :)
<j`ey>
the 4k patch was never in the asahi tree
<marcan>
those patches aren't quite reviewed yet, but I also don't want people using 4K kernels as an excuse not to fix software to run on 16K
<Eighth_Doctor>
That's fair
<marcan>
please just do 16K builds for now, 4K needs polish and it's likely other things are broken there
<Eighth_Doctor>
That's why RHEL did 64k for years
<marcan>
(plus there is a nontrivial performance gain from 16K)
<marcan>
"deferred probe timeout" though, that kind of looks like you're missing a driver
<marcan>
possibly the DART driver itself?
<arnd>
the deferred probe bug should be fixed in -rc4
<marcan>
oh, that's a bug?
<jannau>
in 5.19?
<dcavalca>
I did notice the apple-dart kmod seemed to be missing (meaning, I couldn't modprobe it)
<arnd>
well, not sure if you hit the same thing, but multiple people were affected by a change in the driver core that resulted in deferred probe issues and got reverted in -rc4
<arnd>
6.0-rc1 through rc3 were broken, 5.19 should be fine
<marcan>
no DART driver explains the USB issues
<marcan>
the USB DARTs are supposed to be bypassable (so will work in 4K kernels, just with no security), but without the driver you only get one of the two DARTs bypassed as left behind by u-boot
<marcan>
(I think?)
<marcan>
which means once the USB controller tries to use the other one, it'll fail
<marcan>
but 4K kernels won't work with PCIe so you really want 16K
<arnd>
marcan, rmk: applied the apple_rtkit_poll() patch directly from the list now, no need to resend
<marcan>
arnd: thank you!
<dcavalca>
thanks marcan
<dcavalca>
yeah, we'll do a 16K build and take it from there
<jannau>
I still hope the t6k dart series will make it for 6.1. Joerg was awol this week
<marcan>
if you build the DART as a module, make sure you don't have anything that depends on it built in
<marcan>
(if unsure, I'd build it in, it's a very core driver)
<marcan>
on our kernels we build it in since it's in the dependency chain for backlight-gpio which is a dep for simpledrm in the DT, but that's a temporary hack
<jannau>
no, it's a module in the asahilinux kernel
<marcan>
if you use the same DTs with that though, you want all that chain built in, which includes macsmc and macsmc-gpio...
<dcavalca>
what's the kconfig knob for DART?
<marcan>
is it? did I miss that?
<jannau>
APPLE_DART
<marcan>
looks like I did, lol
<marcan>
dcavalca: okay then I didn't intend it to be :)
<marcan>
it always ends up in the initramfs but yeah, I want people to get framebuffer without waiting for modules
thelounge7571340 has quit [Remote host closed the connection]
<dcavalca>
yup it's =m in our Fedora kernel build for now
<marcan>
if you have CONFIG_GPIO_MACSMC=y like we do, you should also build in DART, otherwise there's no point
<marcan>
if you don't, then you need to be aware that you'll get no simpledrm framebuffer without modules being available
<marcan>
yeah, then it's okay, an DART as a module is too
<marcan>
my mind just went off thinking SMC depended on it because it's an ASC
compassion has quit [Ping timeout: 480 seconds]
* Eighth_Doctor
is running through configs check for 16K pages
<marcan>
alright, I'm off to sleep, hope that helps get you up and running :)
<j`ey>
Eighth_Doctor: this one CONFIG_ARM64_16K_PAGES=y
<Eighth_Doctor>
yup
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
<blazra[m]>
j`ey: Regarding the keyboard backlight PWM: I have found out some more details.
<blazra[m]>
Also, the difference between bit(0) and bit(14) is that bit(14) is just output enable - bit(0) is probably a global enable.
<blazra[m]>
The control register bit(2) that I previously thought enabled "single-shot" mode is more like a "single-pulse" mode where bit(10) selects if you want positive or negative pulse.
<blazra[m]>
Then, bit(0) in the status register gets set at the end of the OFF period and bit(1) at the end of the ON period.
<blazra[m]>
You can clear the status bits by writing ones to them.
<jeffmiw>
one of the next steps is to decide how to manage the different models as they will likely have a different set of sensors(I do not have other machines to check)
<jeffmiw>
and how much we want to use the DT for that and in which form.
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
jeffmiw has quit [Quit: Konversation terminated!]
thelounge7571340 has quit [Remote host closed the connection]