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
quarkyalice_ has joined #asahi
quarkyalice has quit [Ping timeout: 480 seconds]
<alyssa>
...My M1 tree is now +10k insertions to mainline
<alyssa>
I sure hope { PCI, i2c, tipd, mailbox, pinctrl } land soon.
<ar>
it's too late for 5.15, but there's some hope for 5.16
<alyssa>
ar: i still don't understand the kernel merge window stuff
<ar>
alyssa: i only remember that there's a, i think, 2 week window after a release of a given version where subsystem maintainers and other people can send pull requests to linus and hope that their stuff lands in the -rc1, or that the problems are small enough to get fixed before rc2
<alyssa>
right... but why can't we push stuff to linux-next continuously?
<ar>
but i only ever look at it from the outside, to see if there are interesting changes to drivers that affect me
<alyssa>
(we being maintainers I guess)
<ar>
i have no idea
hspak has quit [Quit: bye]
hspak has joined #asahi
yuyichao has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
linearcannon_ is now known as linearcannon
<sven>
alyssa: three or so patches for tipd should be in linux-next starting today. they are the boring ones though and only ~5 lines
<sven>
and linux-next isn't meant for continuous pushing afaict
<sven>
it's meant for maintainers who send pull requests directly to linus to make sure everything works and iron out conflicts as soon as possible
<marcan>
sven: so AFAICT the downstream/upstream idle (no device) states are the same as the reset state for the eUSB2 phy
<marcan>
that's why hotplug doesn't work
<marcan>
however, hotplugging just the CC line does work for me
<marcan>
I'm guessing that works because if you reset the eUSB2 repeater while gadget mode is connected, it detects that as a disconnect, and as part of that sequence issues an eUSB2 reset/reconfigure
<marcan>
so it works again
<marcan>
(and that's why it works sometimes, depends on who detects the reset first, tipd or the phy, and how fast you unplug the connector...)
<sven>
so essentially the eUSB2 repeater is reset and then it goes into idle/no device?
<marcan>
idle is like "dead" mode, yeah
<marcan>
the M1 has to put it into either host or device mode
<marcan>
in idle mode it does nothing
<sven>
:/
<marcan>
but if the M1 doesn't know that happened, well. fail.
<sven>
okay.. and the SoC PHY is still in host or device mode and doesn't do anything
<sven>
great.
<marcan>
so the question is, can we poke some phy regs to force an eUSB2 reset without using a big hammer on the controller
<marcan>
yeah
<marcan>
both "idle, no device" and "eUSB2 reset default state" are just low on both pins
<marcan>
so neither side notices anything
<marcan>
both are expecting the other side to talk first
<sven>
hrm
<marcan>
I saw something in strings on the phy driver
<marcan>
-> -re
<sven>
that kinda also explains why the partial SoC PHY reset I did kinda works
<sven>
(but then sometimes makes dwc3 fail because I didn't do a complete reset I guess and broke some internal state machine :D)
<sven>
sure
aleasto has joined #asahi
nbnm has joined #asahi
coolshaurya[m] has joined #asahi
X-Scale has joined #asahi
X-Scale` has quit [Ping timeout: 480 seconds]
nbnm has quit [Ping timeout: 480 seconds]
FireFox317 has joined #asahi
<FireFox317>
Finally decided to buy my first apple hardware with the M1 chip, the MacBook Air. Cannot wait to put m1n1 on this thing and try to boot Linux xd
robinp_ is now known as robinp
chadmed has joined #asahi
FireFox317 has quit [Remote host closed the connection]
<marcan>
:D
<tophevich[m]>
marcan: what do you reckon, next progress report ~ v5.15 or v5.16?
<j_ey>
5.16
<marcan>
tophevich[m]: you mean when?
<marcan>
as in october?
<j_ey>
hm, actually DART when in in 5.15
<marcan>
september will come out this weekend if I can make it, early next week worst case
<marcan>
I cover things whatever their progress is, which version they land in doesn't really matter
<tophevich[m]>
ah, cool, earlyier than expected, thought releases of stable kernel versions would give you the best "kick" in the buttocks to cover the progress, as you mentioned that it's hard to get the motiviation to write those.
<j_ey>
hopefully 5.16 might get pinctrl, i2c, and tipd
<j_ey>
pcie too
<marcan>
and pmgr pstates/cpufreq
<marcan>
pstates I'll throw over the wall soon, hopefully it won't be too controversial
<marcan>
and cpufreq should be done in the next few days too
<marcan>
tophevich[m]: I said I'd do less crazy updates monthly from now on, I hope I can keep to that :)
<marcan>
besides, with everything going on it makes a lot of sense to just summarize
<tophevich[m]>
aye, also if you do it more frequently it is easier to digest. I guess summarizing also helps you yourself to get a better overview on the current state, and gives ideas on how to best proceed.
<marcan>
yeah
<marcan>
main problem last time is I told myself I'd do a mega hypervisor special
<marcan>
... and then that never happened and blocked everything else
<marcan>
I have a bit of an issue with mental blocks like that sometimes
<sven>
j_ey: yeah, i can kinda hope we can make at least usb 2 work for 5.16
<arahael>
It strikes me that this channel is the name of the beer I've been drinking. :)
<chadmed>
its a great beer but must be consumed quickly. asahi is not pleasant to drink warm
<arahael>
It does need to be chilled, yeah. I've been drinking their black variety.
<arahael>
In my country, beer is _always_ served chilled.
<arahael>
(Most western countries)
<chadmed>
likewise yeah but i find asahi to be remarkably undrinkable warm, moreso than other beers
<arahael>
Yeah, it gets really bitter when warm.
<jn>
Asahi (旭) is also the japanese name of the McIntosh apple variety :)
<arahael>
Fascinating.
nbnm has joined #asahi
<marcan>
that's where the project name came from
<nsklaus_>
i wonder why they've choosen such kanji keys for the macintosh apple. 旭 features two keys: 九and 日 (nine and day). maybe something related to mcintosh apples takes 9 days to happen ?
<nsklaus_>
the most common way of writing asahi is usualy 朝日 (asa hi / morning sun )
<alyssa>
arahael: In my country, beer is _always_ served
<alyssa>
😋
<marcan>
nsklaus_: the kanji means morning sun too, it's an alternate spelling of 朝日
<marcan>
it's not just the apple
<alyssa>
ANS is crashing my rebase on the p-state driver. Oh bot.
<alyssa>
*boy
<marcan>
the "morning sun" meaning is from the original chinese, phonetic-semantic composition (九 is the phonetic component, 日 is the semantic component)
<j_ey>
alyssa: there's one commit I didn't pickup from the pmgr series cos of that
<j_ey>
2bed6110b919fae8760d120e953b4ff86c615970
<marcan>
the japanese name for the apple was apparently coined in 1892
<alyssa>
j_ey: nod
<alyssa>
j_ey: it would be nice to get my "enable ANS" hack out of linux.py though
<alyssa>
one thing at a time
<nsklaus_>
marcan: if i follow you correctly, then 旭 is a more traditional/closer to primitive japanese derived from chinese, way of saying 朝日 ?
<alyssa>
j_ey: right, if I drop that commit everything works
<marcan>
nsklaus_: as I understand it
<nsklaus_>
i never saw it spelled 旭 before, but i know only current japanese, and i may have overlooked that spelling too
<j_ey>
alyssa: cool!
<marcan>
nsklaus_: it's in dictionaries :)
<marcan>
but it's largely used in names
<marcan>
you're right that 朝日 is much more common
<alyssa>
and now I can drop the "clk_ignore_unused" hack in my cmdline which was pretty awful, so that's nice 👍
<nsklaus_>
the closest i knew about was: 日の丸 or 丸の日
<marcan>
alyssa: 2bed6110 won't work as is "on purpose" because I hadn't decide if m1n1 should fix that borkage or we should just re-define it
<marcan>
I did mention this before :p
<alyssa>
yeah sorry
<alyssa>
imo redefine but yes
<marcan>
you want to remove ps_ans2 from ps_apcie_st and instead have the ans device node depend on both ps_ans2 and ps_apcie_st
<j_ey>
marcan: yeah but it's not a useful commit if youre trying to merge that branch into yours :P
<alyssa>
ack
<marcan>
j_ey: fair :p
<alyssa>
j_ey: My own fault really :-p
<alyssa>
guess I should uprev pinctrl next
<j_ey>
v2 coming soon(tm)
<alyssa>
git repo?
<marcan>
6012693c4203 pushed to fix that
<j_ey>
alyssa: I havent pushed it yet
<marcan>
anyway, I'll rebase and add a bunch of register defines just for documentation's sake, maaybe implement auto-pm just to see how that goes, and throw it upstream soon
<marcan>
I do wonder if I should rename the driver though
<marcan>
I call it pstate but that could mean power or performance state
<marcan>
there are separate performance state registers apparently (?)
<marcan>
so maybe pwrstate is a better name
<alyssa>
delightful
<marcan>
I really don't know what the perfstate regs do; xnu just initializes them all from ADT data and then ~never touches them afaict
<marcan>
I think I'll just make m1n1 do that
<alyssa>
treat it like tunables?
<marcan>
yes, all the info is in the adt
<marcan>
if linux has to manage some we can take care of that later, but at least that way it doesn't have to init everything
<alyssa>
my current excuse : can't do my homework because i'm debugging the kernel
<TheLink>
my excuses at that time of my life were much more lame :P
* alyssa
still having "fun" with the nvme pwr gates
<alyssa>
*ans
<j_ey>
alyssa: you can also try adding 'always-on';
<j_ey>
like ps_imx has
<alyssa>
no dice and I should really uh stop procrastinating on my homework now
<alyssa>
i figure i'm doing something stupid on account of not having eaten breakfast yet
<sven>
ah yes. i love how rebasing on the latest linux-next essentially triggers a full kernel rebuild. and ccache doesn't seem to help :(
nbnm has quit [Read error: Connection reset by peer]
nsr has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
<nsr>
Hoy! Started around playing with asahi/m1n1, great&impressive stuff! One question though: I'm trying to access the ARMv8 PMU registers, but getting a SYNC exception upon trying. Couldn't find any solution yet, any insights? Is apple silicon locking those away?
<maz>
M1 doesn't have the architectural ARMv8 PMU.
<alyssa>
sven: yep.
<nsr>
thx maz
<nsr>
are you aware of any substitute to get high-precision timers/clock-cycle count?
<maz>
nsr: there's an IMPDEF PMU, but there is absolutely no documentation (or at least none I'm aware of) for the programming model or the characterisation of the events. that'd certainly be an interesting project for someone to RE! ;-)
<alyssa>
maz: nice nerdsnipe!
<maz>
alyssa: I learned from the best! ;-)
<alyssa>
❤️
<alyssa>
"How is Asahi so far along? Are you guys just that talented?"
<alyssa>
"Recursive nerdsniping and focused procrastination."
<nsr>
indeed :D any pointers where to start with (e.g., at least some known mrs combinations?)
<nsr>
ouh great, thx j_ey
<_jannau_>
nsr: at least parts of apple's pmu code is the in open source part of xnu. Apple also made more performance counters available in mac os recently
yuyichao has joined #asahi
jbowen has quit [Quit: leaving]
<maz>
_jannau_: do you happen to know if they have described the nature of the events in any sort of detail?
<sven>
huh... looks like i also just somehow managed to get one of the usb-c port into a broken state on my macbook air running macOS
<sven>
(rebooting will probably fix it, but this whole thing seems to be rather unstable :D)
<alyssa>
sven: how'd you do that?
<sven>
i don't really know tbh
<sven>
i had both of them connected to my mac mini
<sven>
then i disconnected it
<alyssa>
i will not nerdsnipe myself into writing a jpeg driver i will not nerdsnipe myself into writing a jpeg driver i will not nerdsnipe myself into writing a jpeg driver i will not nerdsnipe myself into writing a jpeg driver i will not nerdsnipe myself into writing a jpeg driver
<sven>
and it looks like that got *both* m1 machines into a state where that port just refuses to work :D
<sven>
like, i expect this with my horrible linux hacks
<sven>
but the machine running macOS shows the same behaviour now :/
<alyssa>
lowers the standards for linux :-p
<sven>
alyssa: so i hear you're writing a jpeg driver now? :>
<sven>
also makes me more inclined to just do the full xhci reset every time a cable is unplugged
<alyssa>
sven: i am TRYING to do my homework :-p
<alyssa>
and conveniently noticing the ADT for the JPEG block makes it seem especially simple to the extent it might be possible to just ... guess my way through
<sven>
if even doing _that_ makes it unstable i feel like trying to be clever and getting away with partial resets or PHY only resets might just make it worse
<marcan>
fwiw, I finally set up my M1 iMac
<marcan>
and I can confirm idevicerestore fails with in, for multiple reasons only one of which I've fixed so far :)
<sven>
okay. rebooting the macbook air fixed the port again *sigh*
roxfan has joined #asahi
<sven>
yup. and this works semi-reliably: connect both usb ports (maybe one is also enough), wait until the linux tells you that the serial gadget is attached and then unplug the cable.
<sven>
sometimes the macbook air (running macOS) usb port is dead until i reboot