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
jelly has quit [Ping timeout: 480 seconds]
<klange> My stock of 64-bit ARM machines is rapidly increasingly...
boardwalk1 has joined #asahi
boardwalk has quit [Ping timeout: 480 seconds]
boardwalk1 is now known as boardwalk
jabashque_ has joined #asahi
guan has quit [Ping timeout: 480 seconds]
enomem has quit [Ping timeout: 480 seconds]
nkaretnikov_ has joined #asahi
eric_engestrom__ has joined #asahi
jabashque is now known as Guest2461
jabashque_ is now known as jabashque
nkaretnikov has quit [Ping timeout: 480 seconds]
nkaretnikov_ is now known as nkaretnikov
cptcobalt has quit [Ping timeout: 480 seconds]
Guest2461 has quit [Ping timeout: 480 seconds]
eric_engestrom_ has quit [Ping timeout: 480 seconds]
Vaughn has quit [Ping timeout: 480 seconds]
steev has quit [Ping timeout: 480 seconds]
steev has joined #asahi
nkaretnikov has quit [Remote host closed the connection]
eric_engestrom__ has quit [Read error: Connection reset by peer]
steev has quit [Remote host closed the connection]
jkkm has quit [Read error: Connection reset by peer]
eichin has quit [Read error: Connection reset by peer]
enomem has joined #asahi
jelly has joined #asahi
guan has joined #asahi
cptcobalt has joined #asahi
jkkm has joined #asahi
nkaretnikov has joined #asahi
eric_engestrom__ has joined #asahi
steev has joined #asahi
eichin has joined #asahi
Vaughn has joined #asahi
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
darkapex2 has quit [Remote host closed the connection]
darkapex has joined #asahi
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
doggkruse has joined #asahi
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bgb has joined #asahi
doggkruse has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
doggkruse has joined #asahi
Glanzmann has quit [Quit: leaving]
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chadmed has quit [Quit: Konversation terminated!]
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
bgb_ has left #asahi [WeeChat 3.0.1]
bgb has joined #asahi
darkapex1 has joined #asahi
<bgb> I tried boot linux according to SW:Linux, but ended with brk exception. the log: http://paste.debian.net/1215023
<j_ey> type 'lower()' it will get a bit further, might print out some stuff
darkapex has quit [Ping timeout: 480 seconds]
<bgb> just stuck and no more output
<bgb> I use main branch of AsahiLinux/linux and recently updated m1n1
<j_ey> main is very old
<j_ey> I would suggest using master from torvalds
<bgb> ok, but what about the config?
<j_ey> I think arm64_defconfig should be enough
povik has joined #asahi
<povik> marcan: that disappearing sound devices seem to related with assigning multiple power-domains to them in DT
<marcan> ah yes, you can't do that
<marcan> multiple PDs require explicit device support
<povik> be it the dma controller, or pcm device, if i assign multiple power domains, it's like they are ignored
<marcan> yes
<marcan> you need to explicitly instantiate them if there is more than one
<marcan> because the genpd framework doesn't know what to do with more than one
<povik> yeah, so i read in the genpd code
<marcan> I would recommend using a single power domain for the audio devices, and instead representing extra dependencies in the power-controller nodes
<marcan> (which do support multiple deps properly)
<povik> but i am surprised that the nodes in DT are then outright ignored, it's not just that the power domains don't get turned on
<marcan> oh, I would not expect them to be ignored
<povik> marcan: is there support for some notion of virtual power domains with multiple parents?
aleasto has quit [Ping timeout: 480 seconds]
<marcan> there isn't, not right now
<marcan> what is your use case?
<marcan> I think for most devices there would be one domain that is the device per se, and any other deps can be chained off of that
aleasto has joined #asahi
<marcan> (note that we don't have to have the same tree as the ADT, we know theirs is BS sometimes anyway)
<povik> yeah if we deviate from the ADT power domain tree, then maybe there's no need for the virtual domains
<povik> i will see how i can represent that
<marcan> yeah, we're already doing that
<marcan> (e.g. for ANS2)
<povik> okay, okay
* j_ey too dumb for dt bindings
<povik> aren't we all
<j_ey> dt bindings check is saying that my vendor property has to be a boolean? but i need it to be a number!
<kettenis> is that the apple,npins property?
<marcan> j_ey: the error messages from the binding check kind of suck
<j_ey> kettenis: yes
<marcan> you need a $ref to the type
<marcan> apple,num-channels:
<marcan> $ref: /schemas/types.yaml#/definitions/uint32
<marcan> maxItems: 1
<marcan> description:
<marcan> (foo)
<marcan> that is how you do it
<j_ey> thanks
<kettenis> don't think the maxItems is appropriate for a scalar type
<j_ey> what's num-channels from?
<marcan> the MCC driver I'm fixing up for submissing right now :)
<marcan> kettenis: scalar types usually use maxItems 1 AIUI, though maybe it's not necessary for things with a type ref already?
<j_ey> i checked, uint32 has maxItems already
<kettenis> yup
<marcan> makes sense
<kettenis> there is a uint32-array type for arrays
linearcannon has quit [Read error: No route to host]
linearcannon has joined #asahi
<marcan> yeah, I used that one
<j_ey> "description: The number of pins", feels like one of those comments: /* set x to 1 */ x = 1;
<povik> :D
<kettenis> j_ey: probably still useful if someone actually implements a tool to pretty-print the bindings for use by humans
<kettenis> in other news, my 30bpp framebuffer support made it to u-boot master
<j_ey> nice!
<kettenis> hopefully the actual M1 support diff is next...
<j_ey> kettenis: I also realised that keyboard support is needed in u-boot, since that's how grub will get keyboard support via EFI protocols
<kettenis> correct; usb keyboards work though
<ar> btw, the keyboards in m1 macs are i2c-hid, or something funnier?
<j_ey> ar: spi
<bgb> j_ey: upstream-bringup-v5-plus-nvhe works fine with arm64 defconfig. thanks :)
<j_ey> yeah, I just thought that the built-in would be a 'nice to have at some point', but it's more necessary than I thought
<j_ey> bgb: I still recommend you use torvalds/linux master
<j_ey> bgb: your branch is from april
<povik> so much trouble. why aren't you all content with using a kexec-based bootloader? :-p
<j_ey> that was pipcet[m]'s approach!
<povik> i stumbled upon their repo the other day, should look into what's there
<j_ey> kettenis: https://paste.gg/p/anonymous/34055aa25f1146cb810142e94b4b2ed1 anything else I should add?
<kettenis> don't think so
<marcan> https://github.com/asahilinux/linux/tree/cpufreq/v1 if anyone wants to poke around before I send out an RFC
<j_ey> kettenis: oh, and add it to the require properties
<j_ey> marcan: apple,memory-perf-config, these are just magic values from the ADT right?
<marcan> the highperf ones are from the ADT; the lowperf ones are the boot values
<marcan> (I asked around and it seems they're the same for everyone)
<marcan> the xnu driver just reads the current values for that, but I don't like that
<marcan> a lot of deep research into memory controller performance might uncover what they mean, but... I don't think we should block on that.
<marcan> in the future, if we have a better understanding, we can improve the binding and then just maintain backwards compat with the old style
<kettenis> j_ey: that would be a good idea
<j_ey> marcan: makes sense
<kettenis> marcan: where did the opp-microvolt values in the CPU OPP tables come from?
<marcan> ADT
<j_ey> marcan: lol 'squelch this error' :D
<marcan> we don't use them, but I figure might as well document them
<marcan> j_ey: yeah I dunno, the whole required-opps thing is kind of dodgy in the context of cpu OPP tables
<marcan> that's why this is an RFC
<marcan> I'm going to grab some dinner, I'll collect any feedback once I'm back and fire off the series :)
<kettenis> marcan: commit message mentioned 714, but you actually use 700
<marcan> ah derp, thanks
<kettenis> might be confusing for someone doing repo archeology
<marcan> j_ey: not intentional, thanks :)
<marcan> okay, heading off, will read later!
<j_ey> dev_info(dev, "MCC performance driver initialized\n");, could say 'Apple MCC..' so minor that I feel like typing this out is silly
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
aleasto has quit []
<j_ey> marcan: also in the same commit message with the 714/700 you have "CoreMark benchmark [1]", I guess the [1] was meant to have a link later at the bottom
aleasto has joined #asahi
<bgb> marcan: cpufreq/v1 compiling ends with error, using arm64 defconfig
<j_ey> bgb: what's the error?
povik has quit [Quit: Page closed]
<j_ey> marcan: needs the _noclk ^
<bgb> j_ey: yeah, just found that
bgb has quit [Remote host closed the connection]
bgb has joined #asahi
gabuscus_ has joined #asahi
Nspace has joined #asahi
gabuscus has quit [Ping timeout: 480 seconds]
Nspace has quit [Quit: Nspace]
Nspace has joined #asahi
<bgb> booted ok after typo fix
<bgb> p-cores run at 600MHz by default, how to mannually speed up them?
<alyssa> sven: congrats on i2c merge
gabuscus has joined #asahi
gabuscus_ has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
arahael1 has joined #asahi
jbowen has joined #asahi
Arahael has quit [Ping timeout: 480 seconds]
povik has joined #asahi
Nspace has quit [Quit: Nspace]
yuyichao_ has joined #asahi
Nspace has joined #asahi
Nspace has quit []
Nspace has joined #asahi
yuyichao has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
<marcan> bgb: that depends on your governor, standard cpufreq stuff
<marcan> but they should be at 600MHz if they aren't doing anything
<sven> remember how i was looking for a smaller hammer to fix this usb hotplugging issues? looks like i ended up with a bigger hammer instead to fix the "usb port breaks completely" problem that even macOS suffers from: there's a bit in the PHY registers which apple calls DRD_SW_VCC_RESET
<sven> i noticed that i can also fix the port in macos when it goes to sleep. and it looks like macos sets that bit just before it disables power to dwc3
<kettenis> what exactly happens when you toggle it?
<sven> i think it resets whatever DWC3_GCTL_CORESOFTRESET resets + some more things
<sven> still trying to figure out the details
Nspace has quit [Quit: Nspace]
<marcan> ha
<marcan> asahi linux with USB more stable than macos when
<marcan> sven: can I tweet that? :)
<sven> i guess
<sven> so if that bit is set all dwc3 registers read as 0
<sven> this seems to be some kind of hard reset i guess
<marcan> that looks like what the pmgr reset does
<marcan> on e.g. uart
<sven> yeah, let me check if it also loses all state. but i'd expect that
<sven> yup
<sven> resets all state
<sven> so i guess if you disconnect the cable at just the wrong time when two M1s are connected and one of them is in device mode the dwc3 controller on one of them just trips over and stops working
<marcan> nice
<sven> until you hard reset the entire thing
Nspace has joined #asahi
<marcan> and this reset fixes it?
<sven> yup
<marcan> hahahaha
<marcan> amazing
<sven> needs a PHY reset afterwards and a complete reinitialization but oh well
<marcan> the side that blows up is the device mode side?
<marcan> and then even host mode doesn't work?
<sven> nope
<sven> that's the warn_on alyssa ran into
<sven> the port broke completely for her afterwards
<sven> it'll still WARN_ON, then i trigger that reset and then the port works again
<sven> and sometimes my macbook air ends up as the device and then the same happens on that side
<marcan> nice
<sven> yuup. this seems to work. now only sometimes the port on my macbook air breaks when it decides to be a device again once linux is up :D
<marcan> :D
<marcan> awesome
<sven> and then i put it to sleep, wait a few seconds, wake it up again and it also works there again :D
<sven> so i guess atc-phy will also be a reset-controller now and dwc3 gets a "fun" quirk to reset_control_assert and then reset_control_deassert whenever a device is disconnected
<marcan> lovely
<sven> usb. not even once.
<marcan> well, more like dwc*, not even once
<marcan> remember dwc2 is what's in raspberry pis and how well that worked
<maz> funny how anything designware ends up being a pile of crap...
Nspace has quit [Quit: Nspace]
<alyssa> maz: rk3288's dwc2 was unusable iirc
<sven> didn't the rasparry pi one even require some horrible hack that had to be run like >9000 times per second?
* j_ey sets .use_relaxed_mmio = true to avoid more rants
<maz> sven: yeah, they had to have a FIQ as some sort of high-priority interrupt. terrible thing.
<marcan> yup
<j_ey> marcan: did you see the other comments about the cpufreq code?
<marcan> yeah
<marcan> applying them now
<j_ey> hmm, cant seem to boot macOS with SMP anymore: panic(cpu 0 caller 0xfffffe00124e04cc): "CPU4 has failed to respond to cross-call after 6000000000 nanos
<j_ey> econds (timeout = 6000000000 ns)"
<marcan> did I break something with the IPI changes?
<marcan> which version of macOS?
<j_ey> 11.4 I think it is, going to try by un-defining TIME_ACCOUNTING
<j_ey> marcan: apparently b9f1eb29e9c84aa3cb0b75ab3ced144f019e4dff broke it
<j_ey> (seems weird, maybe I borked my bisect)
<marcan> j_ey: yeah that doesn't make any sense :)
<marcan> it could just be random
<marcan> firing off the series, hope I didn't bork anything too much :-)
<marcan> (well, it's an RFC...)
<maz> marcan: gahhh. I had just managed to get in Inbox under 500 emails...
<marcan> ahaha
<marcan> I figured you might want to look at it :p
<marcan> oh crap
<marcan> I'm at 497
<marcan> and the emails are still going out
<marcan> oh that's all, 498
<marcan> maz: :D
<marcan> now you need to review it so you can push me over the edge too ;)
<maz> odd, I'm at 498 too. are you reading myh email? ;-)
<marcan> :D
<marcan> inbox synchronicity, is this a thing with like-minded devs? ;)
<maz> spooky action at a distance?
<marcan> :o
_andy_t_ has joined #asahi
<j_ey> marcan: bisected again, now it pointed at a16731e8b33fa492c000ed5d5b43bcfbb4a26a5c "hv_exc: Avoid delivering spurious HV-triggered IPIs to the guest"
<marcan> thought so
<j_ey> ran each commit a few times while bisecting
<marcan> but I'm not sure what's broken there :)
<marcan> maybe some mpidr value is wrong?
<marcan> might want to add a break to those loops when it finds the mpidr, and a check for not found
<marcan> it could be a memory barrier problem too
<marcan> j_ey: try adding a sysop("dsb sy") after those queued flag sets
<marcan> (probably overkill but)
<marcan> though I think the spinlock should guarantee that is not needed if we wrote it properly, but...
<j_ey> will try in a bit
doggkruse has joined #asahi
kenjigashu has joined #asahi
kenjigashu has quit []
kenjigashu has joined #asahi
yuyichao_ has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
rross101 has joined #asahi
rross101 has quit [Remote host closed the connection]
kenjigashu has quit []
joske has joined #asahi
rross101 has joined #asahi
rross101 has quit [Remote host closed the connection]
Nspace has joined #asahi
rross101 has joined #asahi
rross101 has quit [Remote host closed the connection]
Nspace has quit [Quit: Nspace]
Nspace has joined #asahi
joske has quit [Remote host closed the connection]
Nspace has quit [Quit: Nspace]
kenjigashu has joined #asahi
kenjigashu has quit [Remote host closed the connection]
jacoxon has joined #asahi
rross101 has joined #asahi
rross101 has quit [Remote host closed the connection]
yuyichao has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
jbowen has quit [Read error: Connection reset by peer]
jbowen has joined #asahi
Nspace has joined #asahi
<kettenis> that discussion developed into something that may interest folks here
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jacoxon has quit []
<j_ey> kettenis: Im a bit confused by the mention of m1n1 at the end, it sounded like some offline tooling.. but the m1n1 mention made it sound like something else?
jacoxon has joined #asahi
jacoxon has quit []
<kettenis> In the end m1n1 is going to provide the device tree that is actually going to be used
<kettenis> But the device trees (and bindings) are maintained in the Linux kernel tree
<kettenis> So the question is how we're going to make sure these stay in synch
<kettenis> (U-Boot will have a copy too that needs to be kept in synch, but that isn't really that important for us)
eric_engestrom__ has quit []
eric_engestrom has joined #asahi
<j_ey> I was thinking m1n1 was just going to take the one from linux
<kettenis> There may be cases where we want m1n1 to be ahead of Linux for a bit
<kettenis> Say Apple releases a new model that doesn't need new drivers
<kettenis> We create a device tree for it and ship an updated m1n1
<kettenis> Then all OSes will just work
<j_ey> oh yeah, that case makes sense
<j_ey> or at least if most of the drivers work for a usuable enough system
<kettenis> But we don't really want to wait for the next Linux kernel merge window to open to be able to do that
<kettenis> Now if we wrote the DT schemas correctly, it should just be a matter of verifying the device tree using the new schema
<kettenis> I mean verify the new device tree with the existing schema
jacoxon has joined #asahi
jacoxon has quit []
jbowen has quit [Quit: leaving]
jacoxon has joined #asahi
jacoxon has quit []
Nspace has quit [Quit: Nspace]
povik has quit [Quit: Page closed]
yuyichao_ has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
yuyichao has quit [Ping timeout: 480 seconds]
doggkruse has joined #asahi
<alyssa> j_ey: fwiw I've seen hv+smp+macOS panic during boot totally randomly
<alyssa> probability bisection idk
<j_ey> alyssa: yeah but this was failing 3/4 times
yuyichao has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
hspak has quit [Quit: The Lounge - https://thelounge.chat]
<alyssa> j_ey: yeah that matches my experience
<alyssa> but even that is high enough pass to screw up a bisect
hspak has joined #asahi
Nspace has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
Nspace has quit [Quit: Nspace]