marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
tylo1 has quit [Ping timeout: 480 seconds]
tylo1 has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
<marcan>
08:22:02 < alyssa> displayport over usb type-c
<marcan>
08:22:11 < alyssa> displayport over usb4/thunderbolt over usb type-c
<marcan>
of course those are distinct
<marcan>
displayport != thunderbolt
<marcan>
so you're saying you're signing up to write the atc driver? :D
<marcan>
kdrag0n[m]: works for me, is it a timing thing? it has some timeout stuff that might fire due to the latency introduced depending on how you're doing it
<marcan>
kdrag0n[m]: re performance, yeah, I think you're right that dhrystone seems to be an outlier
<marcan>
I get 754 using gzip as a benchmark
<marcan>
662 with a simple dd copy
<marcan>
funny enough zcat is almost ~identical perf on both cores
<marcan>
(modulo frequency)
<marcan>
876 with a better gzip benchmark (binary data, not urandom)
<marcan>
690 by doing repeated `find /` calls (syscall-heavy)
<marcan>
I don't have a proper rootfs set up yet, but I wonder about things like compiling
<krbtgt>
modern CPUs have a dhrystone instruction nowadays
darkapex has joined #asahi
<sven>
alyssa: yup, welcome to the hell that is usb!
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi
<maz>
alyssa: that can be squashed into it, or live as a separate patch, doesn't really matter.
aleasto has joined #asahi
myon98 has joined #asahi
<mini>
alyssa: if you get to the point of needing to test things with a TBT monitor, I have a mac mini and a LG Ultrafine 5K here. I'll need to do the required linux setup, but that's not an issue
<marcan>
I'll be picking up some test hardware for this :)
<mini>
you'll get a very nice monitor out of it, I'm sure ;)
<marcan>
if only I had a good place to use it! :D
<marcan>
nah but actually, I'm thinking a dock first
<marcan>
TB3 dock with DP out should be ~equivalent
<sven>
i'm already happy once usb 3 works :D
<sven>
tbt will be even more "fun"
<j_ey>
I wonder if my usb-c monitor not working with my m1 is a macOS software issue, that will be interesting to see if linux works
<sven>
does that monitor only use display port or does it also have more features it needs usb-c for?
<j_ey>
sven: uh, it has a few USB A ports, maybe those go over the USBC?
<sven>
probably :D
<marcan>
j_ey: if it's TBT then USB A ports would be behind a host controller; if it's just USB3 then it'd be a hub
<kettenis>
looks like the pcie driver has been picked up by the pci subsystem maintainer
<marcan>
yeah, just saw that!
<sven>
oh, nice!
<sven>
and ofc there's two ways to implement usb a ports over usb-c :>
<marcan>
going to finish the progress report today (I get myself into too many loops...)
<sven>
or, well, a usb hub over usb-c
<marcan>
I'm putting together a list of all the in-flux kernel drivers, I'll post it here so you all can double check if you don't mind
<j_ey>
kettenis: oh cool, another arm employee
<nskl>
can't wait to read the new progress report :)
nskl is now known as nsklaus
<sven>
i guess i worked on i2c, tipd, usb2 reset quirk, rtkit, smc, sart, nvme and some very early atc phy stuff. oh, and the "make dart work on 4k kernels" i should pick up again at some point
<nsklaus>
are we still using a custom kernel with 16k page size ? or we're using 4k like everyone else now ?
<j_ey>
nsklaus: 4K works now
<nsklaus>
j_ey: nice :)
<j_ey>
ish
<nsklaus>
i missed that info when it became available
<sven>
there's, uh, a patch series that makes it work for trusted devices
<sven>
it's not upstream yet though
<j_ey>
ive been using 16K locally, for fun
<sven>
i think i'm the only one who almost always runs 4k kernels :D
<marcan>
I don't even remember what I have now, I think it used to be 4K and I changed it?
<marcan>
looks like 16K right now :)
<marcan>
IIRC I switched when testing the hv PAC mask stuff
<nsklaus>
i'm a bit over my league with those kind of questions (so forgive me if i happen to say something stupid) but, wouldn't the kernel memory page size being 16k instead of expected 4k will trash some software relying on that ? i was thinking about things like wine for example, being a bit picky with memory issues
<marcan>
yes, it will
<marcan>
it can be worked around but not perfectly
<nsklaus>
darn ;)
<marcan>
that is why sven is putting so much effort on 4K kernels
<marcan>
otherwise we'd just pester distros into shipping 16K
<maz>
note that the PCIE DT updates are *not* in yet.
<marcan>
just the bindings and the driver, right?
<maz>
yup
<marcan>
though tbh that detail about the DT updates can be omitted from the progress report
<JTL>
IOMMU work properly with 4K page size?
<nsklaus>
marcan: when you'll arrive to the point of fiddling with fex-emu, i hope you can help it make wine work well on asahi (m1, arm arch and all)
<j_ey>
JTL: the IOMMU still uses 16k pages
<marcan>
nsklaus: I expect it to work normally
<kettenis>
DT updates not being in is not a disaster as the DT will be provided by m1n1 anyway
<marcan>
the IOMMU only supports 16K, but with the right kernel voodoo can be coaxed to work when the rest of the system is 4K
<marcan>
(with some limitations)
<marcan>
yeah
<maz>
kettenis: sure. but just so people understand what to pick from where...
<JTL>
marcan: I'd be curious to hear about that when the time comes
<JTL>
(re IOMMU and limitations)
<marcan>
mostly you just can't assume you can map an arbitrary userspace mapping to hardware, but you can't assume that anyway for other reasons
<marcan>
there are very few drivers that rely on that kind of hack
<JTL>
ah
<marcan>
as long as you allocate DMA memory with the right layers it works
<kettenis>
fairly simple; if your kernel uses 4k pages but the IOMMU has a granularity of 16k, you end up exposing pages to the hardware that you don't intend to expose
<marcan>
kettenis: not just that, you can't do contiguous maps of 4K granularity blocks at all any more
<kettenis>
that's a limitation of the Linux kernel code though
<kettenis>
anyway, this probably means that using an eGPU is going to be problematic
<marcan>
depends on how gpu memory is allocated tbh
<kettenis>
well, the standard graphics stack expects to be able to map arbitrary allocations made from userland
<chadmed>
nsklaus: fex shouldnt need any special help running on these macs, once all the low level hardware drivers are sorted, all fex sees is an AArch64 linux machine.
<chadmed>
(because at the end of the day, they are in fact just AArch64 machines)
<kettenis>
it also assumes that you can map VRAM as NormalNC
<nsklaus>
chadmed: last time i tried fex (around last may) it wasn't able to run wine at all beside 'wine --version' iirc
<nsklaus>
i could ran sdl based apps, like that metroid vania 'dead cells' (x86_64 app) that worked fine
<j_ey>
i hope that markan doesnt look at wine under fex, by the time m1 is fully in linux.. m1x or m2 will be here, so i hope thats what he focuses on :P
<kettenis>
but is seems that the M1 only allows mapping PCIe as Device-nGnRE
<chadmed>
nsklaus: on these macs?
<nsklaus>
chadmed: i tried fex on my macbook pro m1 yes
<nsklaus>
running on virtualized linux on paralells on macos. i tried with an ubuntu 20 something
<chadmed>
yeah probably just a problem with hardware or how you set up your amd64 root then
<chadmed>
oh well yeah thats definitely going to be a problem. it should work absolutely fine natively once support for the hardware is there. in fact, it should run pretty well natively at the state we're in now. you just dont have any fancy stuff like graphics acceleration
<marcan>
kettenis: good point on the nGnRE thing, I didn't think of that one...
<marcan>
j_ey: one of my major personal blockers is wine under FEX
<marcan>
if I want to dogfood one of these machines (probably m1x or m2) as my main workstation, I need that
<j_ey>
marcan: oh :(
<j_ey>
marcan: well fine, just fix it quickly :P
<marcan>
(to run windows VST plugins under yabridge)
<nsklaus>
chadmed: no graphic acceleration ? you mean because the driver are WIP on asahi itself, or that's a fex-emu limitation ? if that's a fex-emu limitation that will be sad
<chadmed>
didnt maz have a patch that that unlocked nGnRnE?
<marcan>
why would you need nGnRnE?
<chadmed>
dunno, just reading over maz's rfc from earlier this year
<marcan>
one *very* interesting thing for me is that if I move to M1... that means switching architectures on my main machine, which I haven't done since, er, 2004 or so
<marcan>
at the time I mostly reinstalled
<marcan>
(and I haven't reinstalled since)
<j_ey>
marcan: I mean, that's the same for most of us :P
<marcan>
j_ey: yeah but do you still run your first amd64 install from 2004?
<marcan>
I do :)
<marcan>
$ head /var/log/emerge.log
<marcan>
1095199274: *** terminating.
<marcan>
1095202174: Started emerge on: Sep 14, 2004 22:49:34
<j_ey>
oh, in that sense
<j_ey>
marcan: which machine is this? not the imac you stream from?
<marcan>
but I wonder if I could get something I could call a "conversion" done by just replicating my Gentoo package configs except on arm64, then just reinstalling everything onto a new root and merging it in respecting CONFIG_PROTECT...
<JTL>
marcan: how big is your accept_keywords? :P
<marcan>
j_ey: it is the iMac
<marcan>
JTL: I've cleaned it up a bit over time!
<marcan>
... it's still pretty bad
<chadmed>
the same gentoo root for almost 20 years is quite impressive. i can barely go a year without being compelled to nuke my root partition and start fresh :P
<marcan>
actually I think you mean USE
<marcan>
ACCEPT_KEYWORDS is just ~amd64 :p
<marcan>
but yeah, I've just migrated this root (and forked it thrice!) over the years
<maz>
chadmed: I think you have the wrong guy. I don't remember "unlocking" anything.
<marcan>
each time keeping the hostname of the main branch
<marcan>
so the question is can I legitimately keep that hostname or is it time for a new naming scheme for ARMs :)
<kettenis>
I admit I didn't actually check that the M1 doesn't allow NormalNC on the PCIe address space
<marcan>
then again I already *have* a new naming scheme for M1s... for the macOS installs...
<marcan>
maybe I should just roll with that...
<chadmed>
maz: yeah i was about to say this actually isnt your patch at all lmao, idk why your name was in the header. wasnt even your reply to it
<kettenis>
(personally I think it was a mistake for ARM to allow unaligned access to normal memory)
<maz>
kettenis: x86 contagion. like most of what enters the architecture these days.
<chadmed>
same thing happening to the linux userspace too wrt making it more windows-y to entice windows users over. i think making your replacement/alternative look more like the thing its trying to replace is usually not a good idea. why should your replacement exist if it just needs to dress itself up as the "old" thing?
<kettenis>
anyway, the built-in graphics should be fine as it just uses normal memory
<kettenis>
let's hope Apple didn't screw things up and has coherency issues like Intel had for many generations of their integrated graphics
<maz>
kettenis: I guess that if they have that kind of issues, it is likely to affect a lot more than just graphics.
<kettenis>
I think the "make graphics fast by bypassing the coherency protocol" paradigm from the AGP days is finally dead now
<maz>
kettenis: can I quote you on that next time I talk to GPU people? :D
<sven>
everything that uses the dma-iommu api via the the dma api as intended will work on 4k kernels. there's some broken code that expects to be able to give the DMA api two 4k pages at A and A+8k and get back a single contiguous mapping for those at A' and A'+4k but well.... nothing we can do there
<kettenis>
maz: be my guest; I have no formal CS education whatsoever ;)
<sven>
formal CS education is overrated ;)
<maz>
kettenis: saying "be my guest" to a hypervisor person is... turning things upside down! :D
<maz>
as for formal CS education, it really doesn't matter.
<kettenis>
LOL
<sven>
:D
<chadmed>
i contemplated doing CS but both the good unis that offer it in Brisbane have utterly atrocious CS courses. one is basically just a glorified helpdesk certificate of competency and the other is just Bachelor of Python and Java. very depressing
<chadmed>
it shouldnt matter anyway, there are plenty of fantastic resources online and millions of lines of code to study in various git repos
<Glanzmann>
marcan: I have multiple system that I have not installed for over twenty years and cross graded from i386 to amd64 (Debian ...). Of course the hardware change a lot of times.
<marcan>
Glanzmann: I'm going to be using Arch Linux ARM ;)
<MagMell[m]>
NVME support on the mainline should be good at the moment (this is on the Mac mini M1)? Just switched over from corellium
<MagMell[m]>
s/moment/next/
<alyssa>
maz: congrats on the merge
<sven>
there's no mainline nvme support for m1 yet
<alyssa>
maz: DCP can probably go as "functional" tbh
<alyssa>
marcan: i mean
<alyssa>
like NVMe
<marcan>
yeah, will do
<alyssa>
dcpext is an atcphy problem, not a dcp one at this point
<marcan>
yeah, I expected that
<MagMell[m]>
ok thx
<marcan>
and unless you want to sign up for the entire USB3/TB3/USB4/dpxbar/atc/etc mess, I would recommend you leave that side for now
<alyssa>
there are lots of bells and whistles that could be added to the dcp driver but in terms of "set native modes, double buffering, hotplug, ..." i mean it does what it needs
<alyssa>
Yeah, I don't want to
<marcan>
*aside
<alyssa>
I just wanted hv traces of it so I could make sure the DCP side could cope with it later
<alyssa>
and not have to refactor the whole DCP driver after it goes upstream
<marcan>
it doesn't do double buffering? isn't that just presenting different surfaces?
<alyssa>
* allows a compositor to do double buffering
<sven>
marcan: ah, btw., i tested the usb isolation thing and that did absolutely nothing. i still have to try what happens if i only set one of the two reset bits in the usb2phy control register though
<alyssa>
(Wayland takes advantage of that. Xorg is too dumb to.)
<Glanzmann>
MagMell[m]: I noticed that when I do 80 threads 4k random write I only get around 1000 iops. Other than that it looks 'good'. Linear access I get several GB/s.
<sven>
maybe that's enough to unbreak it without breaking xhci/dwc3
<Glanzmann>
alyssa: No issue, I'll check the backlogs.
<sven>
"fun". bringing up usb3 using hacks shouldn't be too hard
<sven>
let's see what happens then
<alyssa>
drop the m1n1 patch (for ANS), the hack is not needed with marcan's drivers in 20211003
<alyssa>
also consider not running cpu_pstates.py before boot, 20211003 has marcan's cpufreq drivers which should get similar perf without melting your desk
<marcan>
I'm going to make m1n1 do the DVMR thing and switch the pcores to 2GHz anyway
<marcan>
I think that makes sense for a bootloader state
<marcan>
and then we can drop the init from the driver
<marcan>
and besides, there's a good chance more nonsense changes here for newer chips, but the basic pstate control probably won't
<Glanzmann>
alyssa: I see, my mini did not get hot or make any noise (fan is off entire time).
<marcan>
if this means we can make basic pstates work on newer chips without kernel changes, that's a big win
<marcan>
Glanzmann: she's kidding
<marcan>
the cores go to sleep anyway
<Glanzmann>
alyssa: Will do the same.
<Glanzmann>
156.234.58.11: Thank you for your public key, now send me the private key.
<alyssa>
marcan: Tell that to my desk 🙃
<chadmed>
the M1X mac mini is apparently going to be even thinner so i have no clue how theyre going to effectively cool the chip
<chadmed>
faster fan i guess?
<Glanzmann>
chadmed: Does the m1x has a nm shrink?
<chadmed>
doubt it, M1 is already on TSMC N5 and theyd have to port the firestorm/icestorm IP to whatever TSMC's next node is. i dont even think their next node has entered risk production yet anyway
<mini>
doubtful, the m1 is already 5nm
<chadmed>
its not an easy task to shink an existing design, you cant just take the same photomask and make it smaller. the actual physical layout must change to conform to the new node's electrical and physical properites
<mini>
I can't say I've noticed any heat or noise issues even with very extended loads on my m1 mac mini so far
<mini>
and I've had it doing things like hours of video & audio processing at 100% CPU
<Glanzmann>
mini: Two things heat up my mac: Running qemu or streaming my screen using 'screego' using a html5 browser.
<Glanzmann>
However I'm talking about m1 macbook air.
<marcan>
chadmed: the M1 Mac Mini is half empty space
<marcan>
they just reused the Intel case
<marcan>
these chips are so power-efficient you barely need a small fan to keep them cool
<marcan>
no reason why they can't cool the M1X efficiently on an even smaller case
<Glanzmann>
marcan: Interesting.
<Glanzmann>
marcan: Btw. did you hardware debug the usb3 chip? Any new findings?
<marcan>
usb3 chip?
<Glanzmann>
marcan: I read in the irc backlog, that when you plug/unplug usb3 macos resets the entire chip, you bought an additional m1 to look at it for a hardware bug, I wonder if you did??
<chadmed>
i think he means the CD3217?
<sven>
the eusb2 repeater actually
jbowen has joined #asahi
povik has joined #asahi
<marcan>
Glanzmann: I haven't yet, I bought it *before* I realized what that whole mess was about, once I did I was pretty sure there was no hope of avoiding the reset
<marcan>
but the question still remains, as I mentioned above, whether we really need to do a full XHCI teardown or we can get away with something lighter
<marcan>
so I will still do the teardown and poke around for that later
<alyssa>
" I mean the Asahi Mesa driver has been in Mesa's upstream CI for 6 months now :-p
marvin24 has quit [Ping timeout: 480 seconds]
<sven>
marcan: there are many svens. please call me "sven peter" the first time or link to my twitter or something like that :)
<alyssa>
"the bobsledding Sven worked on RTKit.."
<alyssa>
that should disambig
<sven>
haha :D
<jvoisin>
firefox317: it's mentioned in the beginning of the draft
<FireFox317>
jvoisin, well kinda. It is mentioned in the PCIe bindings section indeed, but that is a different patch than the one that I just linked
<alyssa>
there are also many Alyssa's, though admittedly I am a mononym at this point :-p
<sven>
marcan: the mailbox driver also supports what apple calls "m3wrap" fwiw. probably doesn't matter for the progress report though
<sven>
alyssa: he also linked your twitter :P
<alyssa>
sven: fair :-p
<sven>
the rest looks good to me otherwise
<alyssa>
I'm not really sure what the order of the drivers is
<alyssa>
I guess closeness to merge?
<alyssa>
tipd+i2c are surely closer than pinctrl right now?
<povik>
marcan: draft looks good to me :)
<alyssa>
and i don't see the iommu 4k stuff getting merged any time soon
<sven>
tipd just needs to be picked up by gregkh whenever he has his next scheduled git session
<sven>
i2c needs a v2 with a few small changes but should be ready then as well
tylo1 has quit [Ping timeout: 480 seconds]
<sven>
i just need to find some time to get back to the 4k iommu stuff
<sven>
it's probably less "in review" and more "stuck somewhere on sven's todo blackhole^W list"
<kettenis>
marcan: maybe mentioning upstreaming U-Boot support (USB type-C only) is worked on
<kettenis>
as in, v2 of the patch series has been posted
<alyssa>
marcan: "ready for review" I would highly encourage you to do the send-email and then switch to in review even if it's only technically true ;)
marvin24 has joined #asahi
<alyssa>
"as well as patchsets too problematic to bundle as-is at this time (WiFi, which needs significant rewrites)"
tylo1 has joined #asahi
<alyssa>
the patches I have in my tree are not ready for upstream but aren't really problematic
<alyssa>
Just left with the firmware issue but if that's left as a DIY/bring-your-own like it is on the T2 Macs, 🤷
<kettenis>
there are always too many Mar[ck]s
marvin24_ has quit [Ping timeout: 480 seconds]
<kettenis>
alyssa: do your wifi patches actually work?
<alyssa>
kettenis: yes?
<alyssa>
it's Corellium code minus the firmware selection stuff that needs a rewrite (and also minus some debug hacks etc)
<kettenis>
but with the pcie driver from maz?
<alyssa>
(and split up into separate commits)
<alyssa>
yes.
<kettenis>
interesting...
<alyssa>
at least an older version of the pcie driver from maz
<alyssa>
need to rebase on the merged one still
<alyssa>
but that ought to be "trivial"
<sven>
famous last words :P
<alyssa>
sven: I'm a bit confused about this "merged but into an apple specific branch"?
<maz>
alyssa: I'm sure there will be an issue when the link comes up late and that we need to rescan the bus.
<alyssa>
maz: yes, that still needs to be solved
<sven>
alyssa: uh, that's just the feature branch
<sven>
alyssa: DART also lives in apple/dart in iommu.git
<maz>
alyssa: when you're done with the rebase, let me know and I'll have a look.
<alyssa>
maz: right now i'm bringing up the radios in m1n1, because that and also because no SMC driver in my tree yet
<alyssa>
which I mean. ok that's a huge hack.
<alyssa>
if you write the rescan the bus patch I guess I'll do the SMC + rfkill stuff :-p
<alyssa>
kettenis: on that note, I don't think the pwren-gpios thing makes sense for the pcie driver
<sven>
SMC will be annoying though. that thing has so many random features
<alyssa>
the only special thing in the pcie driver should be rescanning the bus on link up/down (which we need anyway for thunderbolt hotplug)
<kettenis>
how are you going to trigger the gpio?
<alyssa>
I think the "turn on the radios" SMC property should be managed by an rfkill driver
<alyssa>
(either in the rfkill subsystem using an in-kernel SMC API, or just adding rfkill to one of the many hats the soc/apple/smc.c driver wears.)
<alyssa>
this is important for two reasons:
<alyssa>
1. so rfkill actually works in userspace the way apple intended
<alyssa>
2. so the radios never come online if the machine is booted in airplane mode
<alyssa>
having pwren-gpios unconditionally in the pcie driver means you can't take your macbook on Air Canada anymore :-p
<alyssa>
("I thought there's in flight wifi now" "Shhh")
<kettenis>
well, the gpio isn't really a "turn radios on"
<kettenis>
it actually powers the entire pcie device on and off
<marcan>
alyssa> marcan: "ready for review" I would highly encourage you to do the send-email and then switch to in review even if it's only technically true ;) fair :)
tylo1 has quit [Ping timeout: 480 seconds]
<alyssa>
kettenis: even more reason to do it with rfkill then?
<kettenis>
so it isn't clear to me whether rfkill should be implemented using thise gpio, or if there is some other way
<marcan>
< alyssa> Just left with the firmware issue but if that's left as a DIY/bring-your-own like it is on the T2 Macs, 🤷 <- I just don't really want to ship that hack, I'd much rather do a proper firmware bundler in the installer and ship *something* that at least is a reasonably upstreamable approach
<alyssa>
marcan: yeah that's fair
<marcan>
but also, tbh, I want to rewrite that entire patch
<alyssa>
also fair
<sven>
i think we need to understand both SMC and the pwren-gpio/rfkill thing better anyway.
<sven>
and then figure out what's the best way to implement both
<alyssa>
the register map thing you already committed to rewriting, the MAC address stuff I already rewrote half of to match what m1n1 does, all that's left is just the #define's which are trivial and you can use as-is :)
<marcan>
kettenis/firefox317: good call on explicitly pointing out u-boot
<sven>
at least SMC is mostly guesswork right now
<kettenis>
yeah, it might help to see what macos does when you put the machine in airplane mode
<alyssa>
nod
<alyssa>
I suspect something with that smc gpio
<sven>
i'd hate if we e.g. upstream SMC right now and then later realize that we need an entire different approach because it also does $whatever
<alyssa>
(otherwise why do it with smc at all instead of just a pinctrl pin)
<marcan>
I guess time to start tracing SMC...
<sven>
you can just set a xnu bootarg and it'll trace itself for you
<marcan>
lol
<marcan>
yay
<alyssa>
fully automated luxury gay space tracing
<sven>
smcdebug=0xff i think
<marcan>
and that doesn't need global debug like pmgr did?
<sven>
that one needs "AppleT8103USBXHCI-debug=0xff AppleUSBXDCIARM-debug=0xff" and like 10 similar flags because this mess is spilled across many kexts
tylo1 has joined #asahi
<alyssa>
nice
<sven>
it'll even print the tunables for you
<sven>
(see -re)
<nsklaus>
nice read, the preview blog entry
<nsklaus>
november is still a month away, you folks have already linux running up to the desktop, with most of the peripherals supported, or with support underway, with a bit of luck soon there may be a first publicly usable version getting out, in 1year time, linux support for M1 arch.. very nice
<nsklaus>
i remember marcan posted on phoronix, picking up the challenge that in this timeframe it could be done, and you're about to deliver just that..
<robinp>
marcan: draft reads well, only two suggestions I have: 1. Name Sven and Alyssa in full like the others first use (if they are ok with that), 2. s/backwards-compatible/forwards-compatible/ ?
<marcan>
nsklaus: the challenge was GPU before the end of the year... and we still have some time to get there ;)
<nsklaus>
marcan: was it ? i remember it wrongly then i thought it was a discussion of general linux support for M1
<nsklaus>
either way, it's all good news :)
<marcan>
(as in not like 100% passing all the tests, but good enough for a composited desktop)
tylo1 has quit [Ping timeout: 480 seconds]
<marcan>
alyssa: only issue with pmgr is the reset bit has no consumers and hasn't been tested at all :')
<marcan>
but I guess that doesn't *technically* block the send-email
tylo1 has joined #asahi
<sven>
there'll probably be a v2 for some minor changes anyway. you can always sneak in a fix for the reset bit as well :D
<marcan>
yeah :p
<marcan>
but also you could pipe in the reset into ans :D
<sven>
ah, right. i remember i wanted to do that :D
<sven>
that shouldn't be too hard. let's see.
<kettenis>
marcan: you're still missing the yaml file for the pmgr binding
<kettenis>
at least I don't see it on the branch ;)
tomtastic_ has joined #asahi
<marcan>
kettenis: good point, that was git add fail :)
<marcan>
I'll post it tomorrow, along with the pmgr patchset (because if I start doing that now I know I'm not sleeping at a reasonable time *again* ;))
<alyssa>
marcan: any idea if the reset stuff works with DCP?
<marcan>
it does not, unfortunately
<alyssa>
alright
<marcan>
or rather, it doesn't come back up
<marcan>
it's possible it needs some special kick
<marcan>
since it probably expects iBoot to boot it first
* alyssa
nods
<sorear>
read the draft, nothing jumped out at me
The_DarkFire_[m] has quit [Ping timeout: 480 seconds]
<kettenis>
marcan: I think you need to add an entry to MAINTAINERS for the binding
<marcan>
kettenis: yeah, and for the driver
<marcan>
I'm counting that in the whole checkpatch/etc dance
<marcan>
that's why it's not actually sent out yet ;)
<kettenis>
otherwise this looks good
<kettenis>
already aligned the u-boot driver with this (although that isn't part of my first upstreaming diff)
<marcan>
cool!
facez[m] has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: u-boot mention is okay in the installer section?
<marcan>
(thought it'd flow well since that's where it fits in the whole picture)
<kettenis>
yeah, that sounds fine to me
shaman_br[m] has quit [Ping timeout: 480 seconds]
TellowKrinkle[m] has quit [Ping timeout: 480 seconds]
AlessandroFerrari[m] has quit [Ping timeout: 480 seconds]
<marcan>
cool
jryans has quit [Ping timeout: 480 seconds]
ryanhrob[m] has quit [Ping timeout: 480 seconds]
The_DarkFire_[m] has joined #asahi
spot[m] has quit [Ping timeout: 480 seconds]
jammie[m] has quit [Ping timeout: 480 seconds]
ovf[m] has quit [Ping timeout: 480 seconds]
<kettenis>
need to take another look at the u-boot pinctrl driver to bring it in line with what we now know about the hardware
<marcan>
kettenis: did you get the register bit defs?