thelounge7571340 has quit [Remote host closed the connection]
Etrien__ has joined #asahi-dev
Dcow has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
VinDuv has quit [Ping timeout: 480 seconds]
Dcow has quit [Ping timeout: 480 seconds]
SSJ_GZ has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
Core9066 has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
duban6 has quit []
duban6 has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
nicolas17 has quit [Quit: Konversation terminated!]
<chadmed>
took the time to grab a freq-response curve from macos on j314: https://chadmed.github.io/res/macos.png, made the right decision to not copy this imo
<chadmed>
if that phase/delay data is accurate thats... very fun
<chadmed>
i should note that i bumped the codec gain limits to 15 instead of 9 since i have no intention of ever using this machine without pipewire. the curve is pretty much identical at the normal limit though, just quieter by a few dB
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
millenia_ has joined #asahi-dev
millenia_ has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
Dcow has joined #asahi-dev
chadmed has joined #asahi-dev
chadmed has quit []
Dcow has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
<marcan>
so I think the only major issue with the new kernels is the tipd i2c thing?
<marcan>
do we have any good repros for that? I still haven't seen it myself...
<marcan>
I *think* I can get tipd i2c physically out the Type C ports with my glasgow/arduino rig, so I can use that to debug if needed, but first I need a repro...
<marcan>
tpw_rules: the kernel gained /lib/firmware/vendor as a load path
<marcan>
other than that no
<sven>
I haven’t been able to reproduce it here but I think jannau can reproduce it reliably
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
rmk: if you have a tree with review comments addressed I can try to merge it into mine to make sure we don't diverge into a mess
<marcan>
then if I end up having to rearchitect that thing we won't lose review state
<marcan>
(thanks for trying to upstream this, and sorry that it's become such a mess)
<jannau>
I can reproduce the tipd issue easily on the m2 macbook with asahi-dev without HV
<jannau>
I think the issue might be acessing tipd too quickly after an interrupt
<jannau>
current minimal workaround are udelay(200) before read/write in tps6598x_block_read and tps6598x_block_write
<jannau>
reproduction is disconnecting and reconnected usb-c devices/charger a couple of times
<jannau>
fails usually at 1-3 try
<jannau>
there is also issue with dart/iommu device probing. most likely affecting devices with multiple darts like usb, audio on t600x, pcie
<jannau>
works fine if all darts are probed first, i.e. workaround is to build dart not as module
millenia_ has joined #asahi-dev
millenia_ has quit [Ping timeout: 480 seconds]
<jannau>
ChaosPrincess: kbd pwm driver works on m2
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<millenialhacker>
isinyaaa
<millenialhacker>
is pwd driver in another branch? I'd like to try it out
<marcan>
dammit. recoveryOS doesn't have libffi, which is needed for ctypes to work.... argh!
<marcan>
now how do I work around this...
<millenialhacker>
I saw the kernel patch raised yesterday, thought it was already in one AsahiLinux/linux branches
<rmk>
marcan: I've been talking to robh in private about improving the dt schema checks, and it sounds like some of my suggestions are being acted on... quite different from Krzysztof's attitude.
<marcan>
rmk: Krzysztof has... a certain attitude, that's for sure
<marcan>
hm, now how do I fix this... is there some way to invoke lzfse decompression in RecoveryOS? or just... bundle img4tool?
<marcan>
or maybe I can just include libffi
<millenialhacker>
marcan what are you doing? I arrived late to party so miss context
<marcan>
installer releng
<marcan>
I'm tempted to just vendor the .dylib into our installer repo and call it a day
<millenialhacker>
is there any plans to have a GUI installer (is it even possible?)
<millenialhacker>
?
chadmed has joined #asahi-dev
<marcan>
it's possible, but no solid plans here
<marcan>
maybe one day once I run out of other things to do
<marcan>
looks like the homebrew dylib might work, let's go with that
<chadmed>
millenialhacker: someone was working on implementing one in qt but thats vapourware now
<millenialhacker>
I could try to help there, I mean I tried RE ISP and I couldn't progress too much so I could try to do something more according to my skills lol
gladiac has joined #asahi-dev
<marcan>
it would be nice to have a wizard-style installer
<marcan>
not sure how much of the code could be shared. I guess probably the most reasonable thing would be to rewrite most of main.py and then change the other modules to report progress/errors via some kind of callback or abstraction, instead of just printing messages to stdout.
<marcan>
some of the main.py logic could probably be moved to shared code (like some of the decisions around what operations to offer and enumerating partitions)
<millenialhacker>
wizard style with distro choose, that would be my ideal scenario
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Etrien has joined #asahi-dev
<chadmed>
if you use pyqt5 you probably wouldnt need to change much in the current installer since you could probably just import its methods and call into them
<chadmed>
id suggest tkinter so you could run it in 1tr but i wouldnt wish tkinter on my worst enemy
VinDuv has joined #asahi-dev
Etrien__ has quit [Ping timeout: 480 seconds]
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi-dev
<millenialhacker>
why not a fully native ObjectiveC app xD
<millenialhacker>
?
<millenialhacker>
I assume apple native apps should be able to run in 1TR
<chadmed>
yeah id assume youd at least have swiftui
Etrien__ has joined #asahi-dev
<chadmed>
but then youd need to figure out how to call in to the installer, or modify it so that you can just run it externally with some parameters fed to it
Etrien has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
___nick___ has joined #asahi-dev
___nick___ has quit []
chadmed has joined #asahi-dev
chadmed has quit []
___nick___ has joined #asahi-dev
chadmed has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
chadmed_ has joined #asahi-dev
chadmed_ is now known as chadmed
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
millenialhacker has quit [Remote host closed the connection]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Read error: No route to host]
millenialhacker has joined #asahi-dev
millenialhacker_ has joined #asahi-dev
millenialhacker has quit [Read error: Connection reset by peer]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Remote host closed the connection]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Remote host closed the connection]
millenialhacker_ is now known as millenialhacker
millenia_ has joined #asahi-dev
millenia_ has quit [Remote host closed the connection]
millenia_ has joined #asahi-dev
millenia_ has quit [Remote host closed the connection]
millenia_ has joined #asahi-dev
millenia_ has quit [Remote host closed the connection]
millenia_ has joined #asahi-dev
millenia_ has quit [Remote host closed the connection]
millenia_ has joined #asahi-dev
<chadmed>
i think the best solution to the energy model thing long term is going to be to specify the voltages in the DT
<marcan>
pyqt5 should work in recovery mode as long as we bundle it
<marcan>
we already established it's not too big to bundle
<marcan>
millenialhacker: I'd rather the installer be maintainable by other people, most of us aren't familiar with swiftui
<marcan>
pyqt5 makes more sense IMO
<marcan>
chadmed: why do we need the voltages?
<chadmed>
the code that registers the energy model via the opp table does so by assuming there are VRMs associated with the core linked to the opp table in question. VRMs are enumerated by looking for the number of opp-microvolt props in the DT. if no VRMs are found, the energy model is not registered
<chadmed>
ive been looking at changing that behaviour so if there are no VRMs associated && opp-microwatt is present, it still works. however, the core OPP code uses arch-native unsigned longs in all the relevant structs and functions, so using of_property_read_{u32,u64} makes the compiler very sad
millenialhacker_ has joined #asahi-dev
<chadmed>
fwiw we dont actually need to describe the VRMs in their entirety for this to work, i confirmed that just having opp-microvolt in the pstates is fine last night (see logs)
<marcan>
so here's the fun thing: Lina discovered yesterday that that's not constant
millenialhacker_ has quit []
<marcan>
there's minor variation in microvolt values between pcore tables from machine to machine
<marcan>
apparently my M1 Studio and jannau's disagree
<chadmed>
oh its the same on the cpu cores too?
<marcan>
yeah, I thought they were always the same (in my cursory looks in the past) but apparently not, or not any more
<chadmed>
argh
<chadmed>
idk what assumptions other arches make about the size of these dt properties, i dont really want to start going through changing shared code willy-nilly :(
<marcan>
I'm not opposed to making m1n1 forward that, same as Lina did for the GPU, but only if those values are actually meaningful
<marcan>
the DT properties should have constant sizes regardless of arch
<marcan>
what's the problem exactly?
millenialhacker has quit [Ping timeout: 480 seconds]
<marcan>
chadmed: the bindings don't say anything about types for these fields, which is arguably a bug, but I think the intent is clearly that opp-microwatt is u32
<marcan>
see drivers/opp/of.c for how to parse it
<marcan>
u32 array, more specifically
<marcan>
(in case of multiple regulators)
<marcan>
OTOH, that entire binding is arguably silly
<marcan>
the binding implies this is to configure regulators
<marcan>
as in some kind of cap
<marcan>
which is different from a power level you'd use for EAS
<chadmed>
yeah i dont really know why opp-microwatt got tied to all of this
<marcan>
so maybe that binding should be changed, and just have that field dropped to a single u32 representing total power for this entry
<marcan>
how does EAS work exactly anyway?
<chadmed>
no clue how the actual scheduler makes decisions, but the cpufreq driver registers the device with the energy model system, and then schedutil can use that power information along with capacity-dmips-mhz to optimise for J/inst or something like that
<marcan>
that makes sense
<chadmed>
the opp-microwatt property was specifically added so that DT platforms could just provide opp-microwatt in the opp table and have the kernel do everything else without intervention by using that register_em_with_opp function as the callback for .register_em
<chadmed>
so i have no idea why it got tangled up with all this VRM crap, it was specifically added to NOT do that...
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<chadmed>
oh i see whats happened
<marcan>
chadmed: Look at dev_pm_opp_of_register_em. It looks for microwatt, if it finds it, it elides the calculations.
<marcan>
if that doesn't work, that's a bug
<chadmed>
yeah i see whats wrong, they have a function that looks for the property BUT it only finds the property if it finds opp-microvolt first, the check is nested inside an if statement that is false if theres no opp-microvolt
<marcan>
yeah, opp_parse_supplies
<marcan>
that needs fixing
<chadmed>
yeah i might make the _of_has_opp_microwatt_property thing actually check for the property instead of what happens now
<marcan>
that won't work
<marcan>
_get_dt_power still does the same thing with the OPP
<marcan>
using the OPP is correct
<marcan>
opp_parse_supplies just needs to be fixed so it doesn't assume everything needs a voltage
<marcan>
which might need some rework, but that's kernel dev for you :)
<marcan>
looks like the way it works is it looks for regulators to find the count, if it doesn't find them, it assumes 1 for the purposes of parsing the table, which is what you'd want
<chadmed>
do you mind having a look at this? it works, the EM is registered but as you could probably tell with my bumbling around macaudio im not very good at this :P
<chadmed>
oh hang on i left a debug print in there
thelounge7571340 has quit [Remote host closed the connection]
___nick___ has quit []
uur has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<thasti>
(looking at macsmc_power.c): is it actually correct that POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW is returned in seconds, as opposed to minutes? i'm seeing in asahi that i3status tries to interpret this uevent property as minutes...
wyes has joined #asahi-dev
<thasti>
two random kernel drivers I just checked (bq27xxx and cw2015) return it in minutes
<thasti>
oh no, it's only the cw2015, the bq27xxx also does it in seconds. great
<jannau>
thasti: it's interpreted correctly by kde
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
jluthra_ has quit [Remote host closed the connection]
jluthra_ has joined #asahi-dev
<tpw_rules>
so is a scenario known or anticipated where some firmware will actually need to be loaded by the initrd or is this just to make management easier?
<tpw_rules>
(and avoid "first boot" sorts of problems)
<tpw_rules>
i guess there is the usb controller firmware on some machines
<tpw_rules>
so if you are booting off USB you would need that in the initrd. barf
<tpw_rules>
(though u-boot couldn't find that drive _anyway_ so)
<nicolas17>
fun edge cases
<nicolas17>
apparently Apple contemplated the edge case where you're booting macOS off a USB drive connected to the USB hub on the Studio Display, in which case it won't let you install software updates on the display
<jannau>
you can have the esp/kernel/initrd on the nvme and the root partition on usb
<jannau>
but the main advantage is that it is much simpler and you don't have to fight with udev to avoid races
<tpw_rules>
arch runs udev in the initrd, right
kazuki has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
c10l5 has joined #asahi-dev
c10l has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
pthariensflame has joined #asahi-dev
pthariensflame has quit []
jluthra_ has quit [Read error: Connection reset by peer]
jluthra has joined #asahi-dev
<ChaosPrincess>
would someone with a M2 machine mind running this kernel https://github.com/AsahiLinux/linux/pull/62 and then running sudo hexdump -C /dev/mtd0 | grep nvram ?
<ChaosPrincess>
also, this one has a very small but non-zero chance of making you have to restore os via dfu restore
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
SSJ_GZ has quit [Read error: No route to host]
Etrien has joined #asahi-dev
<nicolas17>
ChaosPrincess: I have M2 MBP but I'd need some handholding through the process...
<nicolas17>
ah hm if there's a risk of needing DFU restore I may need to backup some stuff too :D
Etrien__ has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Etrien has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
Etrien__ has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
<nicolas17>
such as, how do I build a kernel with the appropriate config for a mac?
<ChaosPrincess>
do you already have asahi installed
<nicolas17>
yes
<ChaosPrincess>
zcat /proc/config.gz
<nicolas17>
once I compile it how do I install it? the kernel readme says "if you have lilo you can just run 'make install'" and that sounds outdated as hell (lilo?!)
<ChaosPrincess>
you run make install, then make modules_install, and then reconfigure your bootloader to see the new kernel
<ChaosPrincess>
i am assuming it is grub, so you will have to run grub-mkconfig
<nicolas17>
damn, I *was* using all 8 cores for something else earlier but that didn't bring up the fans at full speed like this kernel build is doing :D
<nicolas17>
ugh
<nicolas17>
ChaosPrincess: I think 'make install' actually overwrote my existing kernel
<ChaosPrincess>
look in /boot, if it did, it moved it to the same name but with .old at the end
<ChaosPrincess>
but it is weird and it really shouldnt have done that
<nicolas17>
ah no
<nicolas17>
the one I installed is vmlinux and the repo one is vmlinuz
<nicolas17>
ok, I built the kernel from git asahi branch (so it doesn't even have your pull request), and it just hangs on startup showing a text cursor and 10 seconds later it reboots
<ChaosPrincess>
you are probably missing an initrd or somethng
<ChaosPrincess>
anyway, im off to sleep for today, its getting super late
<nicolas17>
o/
<nicolas17>
yeah pretty sure it's the initrd
<nicolas17>
booted self-built kernel \o/
<nicolas17>
now to try your PR
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]