ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
chadmed_ has quit [Remote host closed the connection]
chadmed_ has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eiln has joined #asahi-dev
faruk has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
faruk has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
seeeath has joined #asahi-dev
eiln has quit [Remote host closed the connection]
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
swaggie has joined #asahi-dev
eiln has joined #asahi-dev
<eiln>
got chaining to work
<eiln>
meaning most* apple coreml models can be asahified now
<chadmed>
i borrowed jeffmiw's float translation function because the one in smc-core kept giving a null pointer dereference, which i will look at fixing at some point
<chadmed>
its based mostly on jeffmiw's work but generalised so that it will be a bit nicer to maintain and work with multiple machines
<chadmed>
the scaling on translated floats is incorrect for power readings but that can be easily rectified
mkurz has quit [Remote host closed the connection]
mkurz has joined #asahi-dev
<marcan>
a... null deref? for a *float conversion*?
<chadmed>
yeah idk whats going on there, the kernel oopses inside that function though
<chadmed>
im probably passing it something it doesnt like
<marcan>
are you actually giving it a pointer to the int to write to? :p
<chadmed>
yeah i was
<marcan>
I don't get it, that function doesn't do any pointer math at all...
<chadmed>
yeah idk like i said its something im doing wrong that ill figure out
<chadmed>
but for now macsmc_f32_to_u32 works as a poc
cylm has quit [Ping timeout: 480 seconds]
<marcan>
so I was thinking we want all those key/name mappings in the DT
<marcan>
since it is fundamentally not tied to the SoC at all
<marcan>
it is tied to the platform and SMC firmware
<marcan>
and could even gain new entries with firmware upgrades
<marcan>
plus there are going to be combinatronics involved, e.g. you have certain SoC-tied things (like CLVR voltage rails on Pro/Max) and some machine-tied things (e.g. j314 vs j316 differences)
<marcan>
so we probably want to have it in the DT as separate includes much like the platforms themselves are handled
<chadmed>
yeah my thought on that was to end up with a per-machine smc binding for the match table, but that makes a bit more sense
<chadmed>
only thing is i dont _think_ you can build the hwmon_channel_info struct on the fly
<chadmed>
the hwmon docs say something about the way applesmc-intel does it being non-preferred these days, and none of the recent hwmon drivers do anything like that
<sven>
oh well, here comes the usb curse: if I first use my apple tbt 3->2 adapter and then switch to this startech adapter acio hangs 🙃
zzywysm has joined #asahi-dev
zzywysm_ has quit [Ping timeout: 480 seconds]
swaggie has quit [Remote host closed the connection]
swaggie has joined #asahi-dev
<jeffmiw>
chamed: I'm working on an hwmon driver version that will have configurable labels when we know them and do that from the DT like previously discussed with marcan.
chadmed_ has joined #asahi-dev
<chadmed_>
jeffmiw: yeah i was just playing around with how that would look
<chadmed_>
building the hwmon_channel_info array based on dt info is possible just annoying
<jeffmiw>
by the way, if anyone has idea suggestion for the DT data/structure format or something that will be similar, I'm very interested :)
swaggie has quit [Ping timeout: 480 seconds]
<chadmed_>
i was thinking something like the opp table
<chadmed_>
have an element for each key with smc-key and smc-label props
<chadmed_>
or something like that
<chadmed_>
then you could just walk the table and build the required structures in the driver
<chadmed_>
idek if thats possible though, i need to read up on how dts are compiled
<jeffmiw>
thanks. I'll see how I could do something similar or along those lines
swaggie has joined #asahi-dev
swaggie has quit [Remote host closed the connection]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-dev
kensan has joined #asahi-dev
kensan has quit []
swaggie has quit [Ping timeout: 480 seconds]
kh has joined #asahi-dev
<marcan>
chadmed_: yeah the "don't build the hwmon_channel_info on the fly" thing falls under "lol subsystem maintainers think they can dictate how hardware works"
<marcan>
we push back against those silly rules/guidelines :p
swaggie has joined #asahi-dev
<kettenis_>
in the openbsd aplsmc(4) driver I simply have a list of keys we might be interested in and check which of them exist when the driver attaches
<kettenis_>
seems to work fine so far, although I only support a limited set of keys for now
<kettenis_>
of course if Apple starts using the same key for wildly different purposes this won't work
<marcan>
kettenis_: some keys have a different meaning on different systems because they are abstractly attached to power rails
<marcan>
e.g. MPMU buck #1 might be two totally different things on different machines, and naming it "MPMU buck #1" erases all information useful for end users
<marcan>
I'd rather name those after the power rail they drive or what that power rail is for
<marcan>
which varies from board to board
<marcan>
(of course we don't have that data for everything, but we do for some machines, and that's nice)
<sven>
jannau: fwiw, I think at this point we might as well try to just writer our own small dwc3 driver that calls into the dwc3 core but is more aware of the annoying atcphy dance by hooking into the typec_mux stuff as well
<ChaosPrincess>
if we intend to unify smc drivers with intel machines, then how to define that data for intel systems where there is no DT
<sven>
jannau: especially with thunderbolt this seems to be very annoying to get right and end in even more ugly hacks
<marcan>
ChaosPrincess: I don't think intel machines have anywhere near as many sensors as these; we could just have some defaults hardcoded in the driver and probe for existing keys like kettenis_ does for those
<marcan>
it'd cause some divergence but that's fine
<ChaosPrincess>
so, just assume apple will not make new intel machines and have hardcoded tables in the driver?
<sven>
jannau: it looks like we e.g. don't need a dwc3 reset if we just switch from usb3-only to usb3/dp
<marcan>
sven: works for me, we already have apple,dwc3 for this. might need a denylist in the generic dwc3 driver to make sure it doesn't probe on snps,dwc3 first.
<sven>
yeah, there's some annoying details to figure out but at least I want to give this a try
<kettenis_>
having a consistent set of descriptions for those keys may be a challenge ("name of the power rail" vs. "what they're for")
<marcan>
please do
<sven>
hacking around dwc3 is getting more and more painful these days
<sven>
which is probably a sign that we're doing something wrong ;)
<marcan>
kettenis_: I'd just include both, flood users with info. repair people will love it, and it's cool. for stuff we don't have the info for, just roll with what we can guess.
<marcan>
it doesn't have to be consistent other than a few very well defined and stable keys, it has to be useful.
kh has quit [Quit: Quit]
<kettenis_>
I suppose I can always ignore the stuff in the DT if it conflicts with my OCD ;)
<chadmed_>
ChaosPrincess: 90% of that applesmc-intel driver can be factored out into an x86 backend for smc core
<ChaosPrincess>
and the other 90% is parsing of the keys
<ChaosPrincess>
since they dont match
robinp has joined #asahi-dev
<chadmed_>
yeah the way they do it is odd too
swaggie has quit [Ping timeout: 480 seconds]
<marcan>
the fan control keys match, that's the #1 thing that will share nicely
<chadmed_>
does the existing intel driver work for t2 macs?
<marcan>
no
<marcan>
that's another reason to deprecate it
<chadmed_>
ah... yeah...
<marcan>
and I expect T2 Macs to share a lot more with M1s
<marcan>
like, quite likely, the battery stuff
<ChaosPrincess>
marcan: dont they use a different data format
<marcan>
?
<ChaosPrincess>
int vs float and such
<ChaosPrincess>
and intel macs used some weird fixpoint format for some keys
<chadmed_>
would it be worth just not unifying them, but factoring out the backend stuff we can and still have an independent driver for the intel machines
<marcan>
ChaosPrincess: oh, good point, they do, but... key type is discoverable
<marcan>
so that means the driver can just find out and support both
<chadmed_>
or can we just say "if dmi table use this codepath if of use this other codepath"
<marcan>
that's just a minor divergence
<marcan>
you can query key type and data format
<marcan>
chadmed_: not worth it IMO
<marcan>
once we have fan/temp unified, the rest of what the intel driver is what... keyboard backlight and some ambient light sensor thing?
<marcan>
those are easy enough to throw in for completeness and call the existing driver superseded
<marcan>
and in the meantime we can just have both drivers mutually exclusive in kconfig and let people pick
<marcan>
so apple silicon already has mixed key formats: most templeratures are 'flt ' (float32), but some are 'ioft' (16.16 fixed point). intel macs seem to use (at least) 'sp78' which is 8.8 fixed point (7.8 plus sign bit, but hopefully the sign bit is standard two's complement?)
<marcan>
the driver needs to just enumerate all T??? keys, and grab the formats, and export everything it supports
<marcan>
then pull descriptions from the DT or (on intel) hardcoded tables for known keys
<marcan>
and leave the others as raw keys
<marcan>
(better export unknown keys than leave them out)
bcrumb has joined #asahi-dev
amarioguy has joined #asahi-dev
eiln has quit [Remote host closed the connection]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
<sven>
hrm, there's a strange apciec1-piodma node in the ADT which seems to use the pciec dart for some reason
<sven>
its MMIO starts where usually the second root port would be
<sven>
and apparently at some point the .kexts disappeared from /System/Library/Extensions :/
<sven>
like, all of them. I guess they only exist in that kernelcache now?
<jannau>
marcan: do you still want to "stabilize" asahi-wip soon? I would like to get the component based probing and runtime PM merged before 13.2 support
<marcan>
jannau: I think at this point we might just release everything together, so I'm happy to merge those in first
bcrumb has quit [Quit: WeeChat 3.8]
<ChaosPrincess>
if you have time, mind looking at the touchbar prs?
<sven>
apciec[%s]::%s no PIODMA engine associated with this port <-- oh dear god, I'm not sure I want to know what that's about
<marcan>
sven: looks like a generic DMA copy engine?
<sven>
yeah, somehow associated with the thunderbolt pcie controller
<marcan>
and DCP too, and other things :p
<sven>
i'm just a bit confused because it uses stream 15 of that pcie dart
chadmed_ has quit [Ping timeout: 480 seconds]
<jannau>
marcan: ok, I'll prepare it. not sure if I want to something about the PCIe dart runtime PM hack
<marcan>
I'll look at it
<sven>
and DCP at least uses that piodma thing somehow internally. it's just weird that the thunderbolt pcie controller has that thing as wel
m42uko_ has joined #asahi-dev
m42uko has quit [Ping timeout: 480 seconds]
kensan has joined #asahi-dev
<jannau>
marcan: https://github.com/jannau/linux/tree/dcp_runtime_pm based on asahi-6.2-rc3-5 I hope you don't mind sorting the patches into their bits/* branches. creating PRs for all of them is a little tedious
<marcan>
[ 20.424813] apple-dcp 38bc00000.dcp: failed to suspend DCP
<marcan>
that clearly shouldn't happen
<marcan>
(it does work nonetheless though)
<marcan>
after a couple sleep cycles it stopped saying that
bisko has joined #asahi-dev
bisko has quit []
<jannau>
I see neither on t8103-j274 without always-on for ps_disp0_cpu0. testing now with always-on
bisko has joined #asahi-dev
<marcan>
I suspect I know what this is
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
yeah, it's a race
<jannau>
marcan: reproduced with "soc: apple: apple-pmgr-pwrstate: Switch to IRQ-safe mode" reverted
<marcan>
no it's just a race
<jannau>
I see it here with a timeout for setDCPPower() and there's a syslog message after that
<marcan>
jannau: pushed a fixup with a comment
<marcan>
wait I messed up
seeeath has joined #asahi-dev
<marcan>
jannau: fixed now
<marcan>
honestly the mechanism I used there is kind of flaky and should probably be rethought
<marcan>
but at least this works now
antonio2 has joined #asahi-dev
<jannau>
looks ok. nice though that the reset recovered from this. I still consider the module reload and reset handling as unsupported
<marcan>
oh this one wasn't causing any badness, the rpm code just re-incremented the count so it was just cosmetic
<marcan>
the previous one though, yeah (when I was missing the IRQ-safe patch)
<marcan>
jannau: what are your plans for 13.2?
<jannau>
the deferred probe / gdm startup race should be fixed now
<marcan>
ooh nice
<jannau>
I'm currently working on updating trace_dcp.py for 13.2
<marcan>
jannau: how is the race solved in the end?
<jannau>
driver changes will be a little annoying. firmware specific call/callback tables and structures
antonio2 has quit [Quit: Leaving]
<marcan>
ah, I guess you just start all DCPs in the callback when the components are ready?
<marcan>
dcp_wait_ready() right
<marcan>
makes sense
<jannau>
marcan: component (linux/component.h) based probing starts when the last missing component is probed
<marcan>
yeah, got it
<jannau>
I think the wait_ready change is not that important. it prevents a "drm: crtc missing modes" during fbdev initailization
<marcan>
ok, I'll do a -dev release with this and m1n1
<jannau>
+1
<marcan>
I'm thinking I might merge lina's new UAPI/rebase stuff plus rebase on the latest rc, and then after some smoke testing of that do a release to stable to see if we regress anything (which really should only affect -edge at that point)
<marcan>
and then when the M2 Pro/Max stuff is ready, release it together with promoting -edge stuff to stable
<marcan>
i.e. to non-edge
<marcan>
whether something else makes it in there (audio? DP?) depends on timing at that point, TBD
<marcan>
but anyway, doing a build with what we have now before going to sleep
<marcan>
so I think systemd is probably triggering that immediately when the backlight device appears
<jannau>
ok, missing swap or modeset sounds reasonable and it appears it's called then the backlight devices reappears
<jannau>
not really happy with the backlight handling. I wish the drm backlight integration would progress faster
faruk has joined #asahi-dev
faruk has quit []
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
faruk has joined #asahi-dev
jeffmiw_ has joined #asahi-dev
jeffmiw_ has quit [Remote host closed the connection]
bcrumb has joined #asahi-dev
hightower4 has quit [Ping timeout: 480 seconds]
bcrumb has quit []
gladiac has joined #asahi-dev
jeffmiw_ has joined #asahi-dev
jeffmiw_ has quit [Remote host closed the connection]
swaggie has joined #asahi-dev
<thasti>
having an interesting issue here (m2 air, on -edge): I'm trying to use an USB-C ethernet dongle. I can only get it to enumerate reliably by placing a finger on top of the USB traces on its PCB. Without doing that, it never enumerates (and I get repeated 'Cannot enable. Maybe the USB cable is bad?' or 'config error' messages in dmesg)
<thasti>
could that be caused by some USB-PHY setting, making the link not come up properly due to marginal signal integrity without my finger on the PCB?
<jannau>
does the dongle work reliably when connected to other devices
<thasti>
I only have one other machine to test, but it seemed to work fine there. I should be able to test another machine or two at work tomorrow
<thasti>
i at least two have two such devices (same model, both new out of box), and both of them behave exactly the same
<thasti>
but if their design was bad, that would of course to be expected :)
<sven>
does it work on the same machine when running macos?
<thasti>
this I haven't tried yet (haven't booted back into macos since I installed asahi on here)
<thasti>
.. turns out macOS actually doesn't boot any longer (telling me it needs to be reinstalled)
bisko has joined #asahi-dev
<thasti>
okay, got it to boot. turns out the dongles don't really work under macOS either
<thasti>
i can get them to appear sometimes with the same kind of trick, but without that they don't show up
<sven>
thanks for checking, sounds like some kind of signal integrity issue then
<sven>
can’t really do anything about that though :(
seeeath has joined #asahi-dev
<thasti>
yep, best guess it's just a marginal design (they were free, I probably know the reason why now...)
bcrumb has joined #asahi-dev
bcrumb_ has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
bcrumb__ has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bcrumb has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
bcrumb_ has quit [Ping timeout: 480 seconds]
bisko has quit []
bcrumb__ has quit [Quit: WeeChat 3.8]
bisko has joined #asahi-dev
faruk has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gladiac has quit [Quit: k thx bye]
nicolas17 has joined #asahi-dev
<nicolas17>
ChaosPrincess: your touchbar pr only supports M1 atm right?
mkurz has quit [Quit: Leaving]
bisko has joined #asahi-dev
<ChaosPrincess>
yes
<ChaosPrincess>
in theory should work on m2, but i do not have one
<nicolas17>
I have M2, but maybe you want some review/testing on M1 first, before messing with the M2 devicetree :P
bisko has quit [Ping timeout: 480 seconds]
faruk has joined #asahi-dev
nicolas17 has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
* thasti
fixed the USB ethernet dongles by shortening the wires between the USB-C cable pigtail and the PCB... now works reliably
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
faruk has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
c10l1 has quit []
c10l has joined #asahi-dev
faruk has joined #asahi-dev
faruk has quit [Ping timeout: 480 seconds]
<sven>
hrm, looks like apple's pciec driver has some quirks for certain devices that don't play nice with the rid2sid map
<sven>
"PI7C9X442SL USB OHCI" is always forced to sid 0
<sven>
and then there's a marvel-wa-viddids field in the ADT to select some devices that also get a special treatment
<sven>
ohh... the PI7C9X442SL workaround makes sense I think. it's the controller in the old apple thunderbolt displays (like mine) and that one exposes three different pci functions
<sven>
and that worked here. so I bet all functions just need to go to the same stream
<kettenis_>
might not include the function number in the RID
<kettenis_>
linux may already have a quirk table
<sven>
yeah, that’s what I assume happens. but if we just go with mapping each bus to a separate sid it’ll just work without quirks
<kettenis_>
one of the reasons I suggested that approach ;)
<sven>
:)
seeeath_ has joined #asahi-dev
hightower2 has joined #asahi-dev
seeeath has quit [Ping timeout: 480 seconds]
sawyer has joined #asahi-dev
<sawyer>
hi all, saw this in the tethered boot setup guide and wasn't sure if it was a placeholder or a reference that I'm just out-of-the-loop on: `A somewhat sane .config can be found at [[DesktopKernel]].`