marcan changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: | Wiki: | Logs:
nicolas17 has joined #asahi-dev
djorz has quit [Ping timeout: 480 seconds]
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
kenzie7 has quit []
kenzie7 has joined #asahi-dev
nicolas17 has quit [Ping timeout: 480 seconds]
hjpm has joined #asahi-dev
hjpm is now known as foton
Mary has quit [Quit: The Lounge -]
Mary has joined #asahi-dev
foton has quit [Remote host closed the connection]
capta1nt0ad has quit [Quit: Konversation terminated!]
Znullptr has quit []
Gues__________________________ has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit []
<Gues__________________________> I have no idea that why I am here. How can I start from beginning to support this. Background: I have been doing full-stack for last 5 years, worked with: C++, Go, Qt, Rust (learning), Frontend-Frameworks. I am really hyped for this project. Where can I start from?
Gues__________________________ has quit [Quit: Textual IRC Client:]
Dcow has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
pjakobsson has quit [Remote host closed the connection]
mps_ has joined #asahi-dev
mps has quit [Ping timeout: 480 seconds]
capta1nt0ad has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
capta1nt0ad has quit [Quit: Konversation terminated!]
SSJ_GZ has joined #asahi-dev
bgb has joined #asahi-dev
<sven> jannau: I think it's a race between dwc3_set_mode and __dwc3_set_mode
<sven> locking dwc->mutex instead of dwc->lock in dwc3_set_mode seems to fix it for me
___nick___ has joined #asahi-dev
Gues__________________________ has joined #asahi-dev
Gues__________________________ has quit []
<sven> urgh. but we can't lock a mutex there because that function might be called from an extcon interrupt handler :/
capta1nt0ad has joined #asahi-dev
fugi has joined #asahi-dev
cylm has joined #asahi-dev
capta1nt0ad has quit [Quit: Konversation terminated!]
<sven> the race is also present in vanilla kernels. it’s incredibly tight but you can get dwc3 into a state where ptrcap is set to device but dwc3 sets up xhci
<sven> which doesn’t go very well ;)
capta1nt0ad has joined #asahi-dev
<Dcow> guys, platform_profile is ACPI thing, right?
bgb has quit [Remote host closed the connection]
bgb has joined #asahi-dev
millenialhacker has joined #asahi-dev
<_jannau_> Dcow: in which ontext? but there shouldn't be any ACPI on apple silicon macs
<Dcow> yeah, I know that AS is not ACPI. power-profiles-daemon maintainer asked about if it's possible to implement platform_profile interface fro those chips
<Dcow> but I guess it's not possible. But we might have similar thing for OF devices, no?
<Dcow> _jannau_: ^
<sven> is cpufreq already upstream? might be wise to wait for that before adding support to other software
<sven> and are there even other things we can tweak? fans and all that is done by SMC anyway
<Dcow> hm, I think it's not, but marcan was happy about it and he AFAIK was in touch with maintainers, so I think it's stable enough
<sven> i'd still wait until it's at least in linux-next. i don't expect things to change but you never know
<Dcow> I am confident enough for draft pr :-D
<sven> (for merging into tools it that is, not necessarily for starting to work on)
<sven> yeah, draft pr sounds good
<sven> would just be annoying if it got merged and then the kernel interface unexpectedly changes
<Dcow> but since it's in stable asahi I want use it, because without patch it's uses NOP implementation and UI is confusing
<Dcow> we want everyone to feel like it's finished product (as possible) right? :)
<sven> sure
<sven> my point really only is that the maintainer of that project should be aware that the driver isn't quite upstream yet
<Dcow> I'll made this more clear in next communication batch, but for now it's draft anyway
<sven> sounds good!
<Dcow> so, the question, do we have similar to platfrom_profile interface for OF devices?
<sven> no idea!
<sven> but that interface seems to be used when multiples knobs are to be turned together (cpufreq + fan speed + whatever else) - do we have anything except for cpufreq that can even be tweaked?
<sven> I think most other things are controlled by SMC and I don't think we have control over them
<sven> no idea if I'm missing anything though
<sven> hrm, actually that interface seems to be about changing some "internal" policy so that something like SMC can tweak all these things together
<sven> not sure if anything like that even exists and that also seems to be unrelated to cpufreq i think
<Dcow> well, this is daemon to tune device modes, not exactly cpufreq. If we can do more than cpufreq, why not?
<Dcow> so, not that unrelated
bgb has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Remote host closed the connection]
mstephenson6 has joined #asahi-dev
<sven> jannau: alright, looks like I can't reproduce the WARN anymore if I lock dwc->mutex around dwc->lock in dwc3_set_mode with that atcphy-WIP tree
<sven> not 100% sure because reproducing it has always been flakey for me
<jannau> I'll test later
<sven> thanks. fixing that race correctly is going to be annoying
<jannau> I find it surprising that dwc3_set_mode and __dwc3_set_mode can race each other
mstephenson6 has quit [Quit: Konversation terminated!]
<sven> you need a very quick A->B->A role change event
<sven> it's much easier to hit that race with the role switch reset quirk
<sven> but without it you can have one dwc->desired_dr_role value in dwc3_set_prtcap(dwc, dwc->desired_dr_role); and then three lines or so below a different one in switch (dwc->desired_dr_role)
<sven> but that thing is incredibly right. I only managed to trigger it twice
<sven> but you then end up with PRTCAP = host and dwc3 bringing up gadget or vice versa
maria has quit [Quit: The Lounge -]
maria has joined #asahi-dev
nomnomcookie has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
nicolas17 has joined #asahi-dev
<tpw_rules> hm, which device trees does the come with?
<tpw_rules> the UEFI environment only installer option
roxfan2 has joined #asahi-dev
zzywysm has quit [Remote host closed the connection]
zzywysm has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
<kettenis> looks like it has something very similar to what's in the asahi-wip branch
<kettenis> actually I suppose that's now the asahi branch
<kettenis> of the linux repository
<zzywysm> kettenis: i think marcan gave the asahi branch the same contents as the asahi-wip branch a day or two after asahi-wip finalized?
zzywysm has quit [Quit: Textual IRC Client:]
<kettenis> looks like it
<tpw_rules> is it the same as the regular asahi installer options then
<kettenis> I think so
Major_Biscuit has quit [Ping timeout: 480 seconds]
roxfan2 is now known as roxfan
zzywysm has joined #asahi-dev
<sven> looks like that additional muted also fixed the rare DP-altmode transition bugs I saw
<sven> *mutex
eiln has joined #asahi-dev
<eiln> hello everyone! it's been 5 days and i'm *still* in github jail so i made a mirror on
<eiln> so far i've got a prototype of 1D element-wise ADD/MUL/MIN/MAX, NCHW convolution, and (my fav, also the trickiest) 2D matrix multiplication working :D
<eiln> i haven't had much issues with the work interface (TaskManager in, my main work), so i'm now studying the actual work, i.e. those magic numbers in the configuration registers
<eiln> t8103s should be able to run the scripts in experiments/ane_*.py
<eiln> please let me know if there are issues
<jannau> sven: looking good here as well. m1n1 device is reliably detected and I haven't triggered the warning so far
<sven> so then we just have to find a way to fix it properly even when dwc3_set_mode is called from atomic context
<jannau> dmesg from m1n1 device detection to after powering the device off:
<sven> looks good to me
<sven> I guess we could create a single threaded workqueue and defer it to there with a newly allocated work_struct each time but ugh :(
<kettenis> isn't this the point where you start talking to the maintainer of the dwc3 driver?
<sven> yeah, probably
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
roxfan has quit [Remote host closed the connection]
<povik> not sure how surprising this is but SIO requires the data section of its firmware DART-mapped for it to boot
<povik> segment-ranges= has the right values but maybe there's some other canonical source
roxfan has joined #asahi-dev
<sven> data section inside dart is pretty common
<sven> segment ranges should be the source
<sven> it’s only not used for DCP because that dart is locked and pre filled iirc
<povik> ah ok. AOP had it in the dedicated SRAM of its own
<sven> I think AOP is the exception because it probably has to work even when RAM doesn’t
<povik> yeah
<povik> but how come grep for segment-ranges/segment_ranges has no hits in proxyclient?
<povik> i would think there's other code already doing this
<sven> why would it?
<sven> for DCP the PTEs already exist
<povik> well, what about the other ASC clients? don't they set up the mapping?
<sven> and ANS has the data section mapped via SART
<sven> SMC has everything in its internal RAM as well
<sven> and I think that’s all we support
<povik> fine, i get to parse it myself :)
<sven> :D
nomnomcookie has quit [Remote host closed the connection]
<jannau> I have notes how to parse segment ranges
<povik> i am looking at the right hardcoded indices for now
nomnomcookie has joined #asahi-dev
<jannau> dart-dcp has them as well but it's a little more complicated since some of the ranges have to be mapped to disp0-dart as well
<povik> ok, boots now
<povik> ok, boots now
<povik> uh, bad window
<jannau> povik: "32 byte per segment, 8-byte physical addr, 8 bytes unknown, 8-byte device address, 4-byte size, remeining 4 bytes look like flags"
<povik> 4-byte size limit?
<povik> wait, that's a lot, what am i thinking
<povik> ok, matches my understanding, except i was passing in the flags for top 4 bytes of size
<jannau> are the top 4 bytes all zero? iirc for dcp it had bits set which didn't make sense as size
<povik> all zero for data. flag bit 0 set for text
<jannau> there's a segment-range for text? dcp misses that on t8103/t600x
<povik> seem to be. segment-names of dcp has __TEXT too
<sven> it maps text via dart?
<povik> i assume that matches the segment-ranges order
<povik> no, at least the SIO doesn't get that mapped
<sven> ok, that would’ve been really surprising :)
<sven> otherwise we could’ve just written out own fake-dma firmware :D
<sven> *our
<povik> "SmartIO"
<jannau> sven: dcp text seems to be mapped via dart on m2
<sven> huh, interesting.
<sven> and that dart is still locked?
<sven> povik: maybe it’s tongue-in-cheek :D
<jannau> povik: dcp has text in segment-names but not in segment-ranges
<jannau> yes, dart-dcp* are still locked
<sven> weird.
<sven> if text is mapped via dart I don’t get why they have to lock it anymore
<povik> jannau: ah, seems to be there for SIO
<povik> hm, on t8103 i see 6 entries in both names and ranges of dcp
<jannau> ah, I think my problem in understanding was that there were just 5 5 ranges mapped in the dart as set up by iboot
<povik> flag bit 0 could be "this is TEXT" or "don't map this with DART"
erik3424 has quit [Quit: erik3424]
<povik> matches the dcp segment-ranges too
artemist has quit [Quit: artemist]
<jannau> the last 4 segments for dcp have bit(1) set
<povik> on m2 does text have bit(0)?
<jannau> yes
<jannau> could be a executable flag
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
<jannau> X11 works with in /etc/X11/xorg.conf.d/ - the modesetting driver apparently needs to be told to use /dev/dri/card2 although there are log messages which imply it is probed
Dcow has quit [Ping timeout: 480 seconds]
<jannau> plasma/x11 is broken though since it appears to require vblank events as well
millenialhacker has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
<kettenis> isn't there code to fake vblank events in the Linux drm code somewhere?
pbsds0 has joined #asahi-dev
millenialhacker has quit [Quit: Konversation terminated!]
<jannau> I was under the impression drm was already doing it based on the refresh rate
pbsds has quit [Ping timeout: 480 seconds]
<jannau> emiting fake fblank events is not the problem, we are that already (on framebuffer swaps and in some error paths)
SSJ_GZ has quit [Ping timeout: 480 seconds]
<jannau> the problem is deciding when fake fblank events needs to be emitted with adding to the vblank events from fb swaps
Major_Biscuit has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
<povik> ha! got SIO to speak up
<povik> Message 1: Invalid tunable size: 67108864
<povik> not sure what it means but progress anyway