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: www.textualapp.com]
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
<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 ane_tm.py, 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
<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 https://www.jannau.net/asahi/30-modeset.conf 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