<kevans91>
it turns out I had a stale config that was disabling the xhci driver for dwc3, I was inspecting the wrong device entirely
nela has quit [Quit: leaving.]
nela has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
kov has quit [Quit: Coyote finally caught me]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
robinp has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<povik>
marcan: sure, will wait for Vinod's reply
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<sven>
jannau: I need to figure out how usb4 tunneling works first to figure out more details, but I think it already makes sense to change two things inside dcp:
<sven>
1) the top level node shouldn't be called disp0 and also shouldn't attach to the disp0 iommu. instead it probably needs to take pairs of dcp(extN), dispN
<sven>
2) split dcp.c into dcp.c and iofm.c (i think that's how apple calls the main dcp endpoint) so that struct apple_dcp can be used for other endpoint
<sven>
I'll add dptx.c and dcpav.c and povik can then later add audio.c :-P
<povik>
:p
<sven>
*iomfb.c actually
<sven>
povik: you know you want to :D
<sven>
it actually doesn't look too complicated fwiw
<jannau>
not sure what to do about the disp* darts. It would be convenient to share the page tables over all of them for multiple displays/overlays shared between two displays
<sven>
maybe just add all of them to the main node then :D
<sven>
or adjust dart.c to allow more than 2 darts/domain and just attach them all to the same one
<povik>
(ideally someone extracts signatures of the relevant IPCs; seems to me you have some process figured out for it)
* povik
've surveyed the audio-display interaction in kernel, to see what we will need to do
<sven>
looks like atc-dpin0/1 both have an interrupt. maybe that's how they know when a stream needs to be tunneled
<sven>
povik: I'll need to prepare one more PR for the DCP EPIC pretty printer. then the extraction literally is "add bt() to the unknown command handler after loading kext symbols"
<povik>
ah, so they have some presumably-automatically generated stubs for all the IPCs? then it's simple
<sven>
the dcp->ap side is still missing though
<jannau>
let's start with one dcpext and assing both stream 0 of the disp dart to the same domain and see if that is what we want
<sven>
i'll prepare a PR to handle that as well this weekend
<sven>
but then you can just stare at trace_dcp.py and probably figure out audio in a day or so. I took a very brief look and it seemed rather simple
MajorBiscuit has joined #asahi-dev
goldsoultheory has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
gonzogonzales[m] has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
I'm surprised they're pushing audio through the EPIC interface
<marcan>
I honestly expected some extra hardware involved, some DMA engine
<marcan>
but also, povik: HDMI/DP audio is its own pile of cursedness with things like dolby/DTS/multichannel PCM modes, so this might be more DRM subsystem stuff than ASoC subsystem stuff (I think DRM has helpers for some of this, infoframes/etc?)
<marcan>
not sure what level the DCP interface is at of course
<marcan>
but worth noting
<sven>
at least the setup seems to happen via that epic Interface, dunno how they actually push the data then
<_jannau_>
dp-audio* has dma-parent/dma-channels
<_jannau_>
I'd assume that is used to push ausio data
<povik>
yeah, pretty sure they push the audio through SIO
fossdd has quit [Ping timeout: 480 seconds]
<povik>
from my looking into this earlier, this is what i expect we need to implement on the DRM side around the EPIC interface
chipxxx has quit [Read error: Connection reset by peer]
<sven>
nice, thanks.
<_jannau_>
I think for dcpext/dispext only dcp text and heap are pre-mapped, so that should be easy to add in m1n1
<sven>
i've also thought a bit about how to hook this all up
<sven>
the atc-crossbar will probably be a separate node in the FDT. either we just stuff the driver into drm/apple as well or maybe it actually fits into drivers/mux (or possibly even somewhere else)
<sven>
then tps6598x will be connected via those graph bindings to at least atcphy and the top-level dispay-subsystem node
<sven>
the atcphy connection to configure the electrical side, the display-subsytem one to trigger the dcpext<->atcphy connection
<sven>
then we'll probably need a connection from the thunderbolt NHI to the display-subsystem as well to trigger dcpext<->dpin0/1 connections
<_jannau_>
I think the connectors should link against the dcps/crtcs in the dt
<sven>
that's the top-level node, isn't it?
<sven>
for now i'll just a constant connection to atcphy1/dpphy anyway and just configure atcphy from python before I start linux ;)
<sven>
*i'll just hardcode
<_jannau_>
I haven't looked how it is supposed to look in the dt but crtc should map to dcp/dcpext* so not the top level display system node
<sven>
huh, does that node already exists?
<_jannau_>
the disp0 node
<sven>
so when I said "top level display subsytem node" above I meant that one
<sven>
the thing that also has apple,coprocessors or however it's called with the list of DCPs
<_jannau_>
yes. I mean that too. not sure how he connectors are supposed to work
<sven>
what do you mean with connectors?
<_jannau_>
I assume the "typec1: connector" nodes from tps6598x should somehow link to the display
<sven>
yes
<sven>
similar to how they're connected to e.g. dwc3 or atcphy right now
Soroush has joined #asahi-dev
<sven>
iirc the bindings for that already exist. port@0 is usb2, port@1 is usb3/SS lanes with their default use and port@2 is "anything else"
<_jannau_>
I guess for dispext it makes more sense if there are connected to the top level node
<sven>
and you can have multiple connections per port
<sven>
yeah, i think so
<sven>
because we can mux any dispext to any atcphy afaict
<_jannau_>
but dcp will have drm level connector which might make more sense to bind to dcp
<_jannau_>
mostly so that we do not call the internal display HDMI-A
jakebot6022 has joined #asahi-dev
<sven>
what is a drm level connector?
* sven
has no clue about drm so far
jakebot602 has quit [Ping timeout: 480 seconds]
jakebot6022 is now known as jakebot602
<sven>
but anyway, just the thoughts I had in the last days. there's still plenty of time to change it. as i said, i'll first hardcode everything for dcpext0->atcphy0-dpphy
<_jannau_>
drm documentaion is not bad, only problem is that all the legacy stuff is documented as well. It would be nice if there was a stripped down version
<sven>
okay, so essentially we'll have one "internal screen" (macbooks) or "HDMI" (mac mini) connector and then "USB-C #n DP altmode", "USB-C #n USB4 Tunnel #0" and "USB-C #n USB4 Tunnel #1" for each atcphy
<sven>
oh, and that special HDMI port on uhhh.. the macbook pro
<_jannau_>
that looks right
<sven>
and I guess each of those can fire a hotplug event which we get from tps6598x for dp-altmode and thunderbolt-nhi for the others
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<sven>
hrm, I guess we actually only fire that hotplug event after we've already configured the crossbar and everything I think
<_jannau_>
but how do we then know when/how to configure the crossbar?
<sven>
then when is the easy part: when tps6598x or thunderbolt-nhi wants a stream
<sven>
the how is going to be annoying
<sven>
especially if I can actually hack dual external screens for the M1
<sven>
but essentially we need to find a free dcpext and match that one to the atcphy input
<sven>
the typec subsystem will needs some adjustments to forward the required stuff to atcphy anyway
<sven>
and I think I saw some patch series that introduced a OOB notification specifically for drm
<_jannau_>
with hotplug you meant the actual display hotplug. I assumed it meant the electril port hotplug as hint that a dcpext needs to be connected to that port
<sven>
now i'm confused :D
<sven>
there's the electrical hotplug that comes from tps6598x/thunderbolt-nhi. once we get that we know that there's something that wants a DP stream and we need to select a dcpext and configure the crossbar
<_jannau_>
me too. starting from "I guess we actually only fire that hotplug event after we've already configured the crossbar"
<_jannau_>
yes
<sven>
and then i think there's the drm hotplug which we only fire after the crossbar is configured and dcpext has done its link training
tobhe_ has joined #asahi-dev
<_jannau_>
agreed. did't come the hotplug event before the link training? i.e. you saw it even before the link training was working
<sven>
true
<sven>
it maybe comes at the start of link training
<sven>
not sure though
<sven>
but it definitely only comes after atcphy is configured and the required methods on that dcpdptx-port-epic are called
<_jannau_>
yes, I was confused because I thought you were speaking about the exlectric hotplug
tobhe has quit [Ping timeout: 480 seconds]
<sven>
I think I confused myself somewhere along the way and switched the meaning of hotplug :)
<sven>
I also don't think we can hardcode the dcpext<->atcphy relationship because there are situations where a single atcphy wants streams from two separate dcpexts for usb4 tunneling
<_jannau_>
hardcoding doesn't work at all when we have fewer dcpext than ports
<sven>
true
<_jannau_>
i.e. it would only somewhat work on m1 max and ultra
<sven>
something greedy should work at first though :D
<sven>
whenever there's a new electrical hotplug just steal a dcpext or complain if none are available ;)
<_jannau_>
hardcode it in the beginning. I think it's reasonable to say during development external displays work only on port b
<sven>
oh, yeah, for now it'll only be atcphy1/dispext0
<sven>
dottedmag: you had that tiled thunderbolt display that worked on m1, didn't you? do you have time to generate another trace for me sometime?
<dottedmag>
sven: sure
<sven>
nice! i'll prepare something tomorrow or so
<sven>
essentially I hope that I can make dcp think that two separate displays connected to atcphy0 and atcphy1 are a single tiled display
<_jannau_>
does macos offers a display selection if you have more screens connected than dcpexts?
<dottedmag>
_jannau_: I can check what happens if I plug two monitors into M1 Air
<_jannau_>
I can check myself, not really a question which urgently needs an answer. thanks
<sven>
note that there sometimes seems to be a bug where it complains about not being able to read from some DART page and then falls back into a python shell
<sven>
just reboot in those cases and try again
<sven>
oh, and you can stop the trace the moment something appears on your screen
goldsoultheory has joined #asahi-dev
<dottedmag>
sven: something appears or monitor says it has got the signal?
<sven>
something appears to be safe
<dottedmag>
sven: okay, I tried three times and it failed during boot every time, before anything was displayed on the external screen.
<dottedmag>
does it matter if the lid is closed (so that I can force progress bar on the external screen)?
<sven>
failed?
<sven>
closing the lid should be fine
<dottedmag>
stopped with unmapped page
<sven>
oh
<sven>
hrm, that's quite frequent. it very rarely happens here
<sven>
you can also try to just type "cont" and hope that nothing important is missing in the trace then
MajorBiscuit has quit [Quit: WeeChat 3.5]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<sven>
i guess CORE is actually ATCPHY_INPUT or something like that
<brentr123[m]>
My phone is blowing up right now
<brentr123[m]>
With notifications from here Jesus
tobhe has joined #asahi-dev
<sven>
iomfb looks pretty normal
<sven>
so maybe it's literally just bring up both dptx and hope for the best
tobhe_ has quit [Ping timeout: 480 seconds]
<sven>
it does start a DCPAVSplitDisplayVideoInterface though
tobhe_ has joined #asahi-dev
<sven>
oh well. guess i'll have to add support to the linux driver and see what happens if I do that with two sreens
<sven>
unfortunately this m1 only has two usb-c ports which makes it impossible to test this from python :(
tobhe has quit [Ping timeout: 480 seconds]
yuyichao_ has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Gaspare has joined #asahi-dev
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
Gaspare has quit [Quit: Gaspare]
yamii has quit [Quit: WeeChat 3.6]
yamii has joined #asahi-dev
konradybcio has joined #asahi-dev
<konradybcio>
sven: so basically I'm debating about the "default fallback" aic compatible and it would be nice if somebody could test whether or not m1 works with apple,s5l8960x-aic from the patchset
<konradybcio>
if it doesn't, it would make sense to keep the current apple,aic where it is and introduce a legacy fallback, I think
cobcobs[m] has left #asahi-dev [#asahi-dev]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
yuyichao_ has joined #asahi-dev
ljs has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goldsoultheory has joined #asahi-dev
nullroute has quit [Read error: Connection reset by peer]
nullroute has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bluetail has joined #asahi-dev
ljs has quit [Remote host closed the connection]
jlco has quit [Ping timeout: 480 seconds]
goldsoultheory has joined #asahi-dev
SSJGZ has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chipxxx has joined #asahi-dev
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
teddys has joined #asahi-dev
gff_ has joined #asahi-dev
gff has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
snowcra5h has joined #asahi-dev
CME has quit [Read error: No route to host]
snowcra5h has quit [Quit: B1tch eX]
snowcra5h has joined #asahi-dev
CME has joined #asahi-dev
rqou_ has joined #asahi-dev
<rqou_>
rcombs: (reading logs) i would like to poke you wrt ProRes
<snowcra5h>
?
<rqou_>
rcombs: i've done enough reverse engineering of the hardware that it should be possible to start developing a linux-side driver, but i don't know anything about what would be needed on the kernel-userspace interface or above