ChanServ changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | WARNING: this channel (only) may contain binary reverse engineering discussion | RE policy: https://alx.sh/re (MANDATORY READ) | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-re
quarkyalice has joined #asahi-re
riker77_ has joined #asahi-re
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
phiologe has joined #asahi-re
PhilippvK has quit [Ping timeout: 480 seconds]
quarkyalice has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi-re
<marcan>
sven: even if it were a separate i2c bus to expose to other drivers, that could just be provided by the dcp node
<marcan>
the rtkit node is about us having multiple *drivers* (potentially different modules) bind to rtkit directly
<marcan>
I don't think we have a good reason to do that; all the endpoints can be bundled together in dcp.ko
<marcan>
it can still expose whatever zillion interfaces we feel like to userspace or other drivers
<marcan>
nothing terribly wrong with a monolithic driver like that, and considering how many hacks Apple has in their model, if we tried to modularize it we'd probably have a bunch of abstraction breaks anyway...
<marcan>
I do expect us to expose i2c to userspace; people want that for monitor control
<marcan>
re 2 i2c buses, I saw two exposed externally via those debug PD modes and now I wonder if they're those two
quarkyalice has quit [Ping timeout: 480 seconds]
<sven>
sure
<sven>
and yeah, i guess it would make sense if they exposed the two busses that way
<sven>
i'm fairly sure at this point the secondary bus of those usb pd chips is connected to the smc directly
akemin_dayo has joined #asahi-re
<marcan>
that would make a lot of sense, yeah
<marcan>
and then we just need to make sure we don't mask the wrong IRQs
<sven>
yeah. i'll have to fix the linux driver a bit anyway because right now it also treats IntMask1 and IntMask2 the same.
<sven>
and change the irq numbers to what apple uses. they don't seem to line up with the TI ones :/
<sven>
and then ofc see if there's a sane way to forward usb connected interrupts to the phy driver (possibly just a virtual irq chip) so that usb hotplug finally works
<marcan>
could be a gpio thing too, perhaps
<marcan>
I assume this hasn't been done before for other USB PHYs?
<marcan>
I imagine some systems have a separate VBUS GPIO and the like
<sven>
there's also this whole extcon thing that seems to be somehow related to usb which also seems to have some kind of notification system
<marcan>
heh
<sven>
dunno, just need to read more code and see what the right thing to use is
<marcan>
various PHYs support using this API to get the state
<sven>
just requires to spend some time to read more code :)
<marcan>
including some dwc3 wrappers
<sven>
yeah, that's how i found it
<marcan>
sven: have you seen Documentation/devicetree/bindings/connector/usb-connector.yaml ?
<marcan>
the one existing dt user of the TI chips uses that to link to dwc3
<sven>
yes, just need to read that all in detail
<sven>
this is not a hard problem, it just requires some reading :D
<marcan>
well, I'm just wondering if this is one of "there are two competing ways to do this in linux" cases
<marcan>
:p
<marcan>
it sure sounds like the typec stuff and extcon overlap
<marcan>
some typec drivers do extcon, but not this one
<sven>
possibly
<marcan>
I'm getting the feeling very few drivers actually *use* those connector relationships
<sven>
yup
<marcan>
see also include/linux/usb/role.
<sven>
yeah, i know
<sven>
i already have a reading list
<marcan>
ok ok :)
<j_ey>
sven: reading list: **/*
<sven>
marcan: i mean, feel free to take over if you want to :D
<marcan>
j_ey: zsh user \o/
<marcan>
sven: I already took over the power management stuff, I should probably stay here for a while :>
<marcan>
sven: I found a thing though
<sven>
a thing?
<marcan>
that role switch stuff, dwc3 uses it, see CONFIG_USB_ROLE_SWITCH and dwc3_usb_role_switch_set
<marcan>
however, it just does some lame default mode thing on disconnect
<marcan>
if the typec controller correctly sets the role to none on disconnect, and dwc3 correctly uses that trigger to reset itself, I bet that'd work
<sven>
in gadget mode we don't even get disconnect events fwiw
<marcan>
well, we should
<marcan>
vbus presence should be somewhere
<marcan>
but the mode should be automatic anyway
<marcan>
that's what this role switch stuff is for
<sven>
no, i mean, dwc3 doesn't trigger an interrupt for disconnects. not even in m1n1
<marcan>
and that should be enough to get hotplug to work
<sven>
(in gadget mode. i think in host mode it does)
<marcan>
sure, but I mean
<marcan>
the call path is ti -> dwc3
<sven>
oh
<marcan>
dwc3 is a role switch provider (see dwc3_setup_role_switch)
<sven>
ok, now i get what you mean
<marcan>
and tipd calls it (see tps6598x_set_data_role)
<marcan>
so if all the right configs and DT links are set up, that should all already work
<marcan>
and it should just be a matter of making sure it actually works as intended, and that dwc3 can use the HOST -> NONE -> HOST transition to reset itself
<sven>
yeah, that could work once the interrupt stuff in the TI code is adapted
<marcan>
yeah
<marcan>
this is probably the least friction way, since it's an existing subsystem
<marcan>
I don't know if anyone else actually relies on the roleswitch for hotplugs within a mode, but well
<marcan>
why not
<marcan>
it's there
<marcan>
might as well use it with a smallish patch and move on :p
<sven>
eventually we may or may not need to do more thanks to thunderbolt (ugh) but this might work for now
<marcan>
yeah
<marcan>
and displayport
<sven>
true
<marcan>
I'm guessing there are no devicetrees with thunderbolt, seeing as, well, intel monopolized that and it's ACPI-mediated...
<marcan>
but displayport alt mode should already be a thing
<marcan>
description: Sideband Use (SBU), present in USB-C. This describes the
<marcan>
alternate mode connection of which SBU is a part.
<marcan>
what
<marcan>
no
<marcan>
there can be multiple of these
<marcan>
who made this binding
<marcan>
sigh
<marcan>
sven: current conclusion: this is all made of fail for altmodes and we need to fix core code :p
<sven>
so you'll upstream power/clocks first and then fix the core code? :>
<marcan>
sure :p
<marcan>
no promises on how long power/clocks will take though... that could be a rabbit hole
<sven>
so i guess a week or so for you then? :P
<marcan>
lol
<marcan>
sven: fwiw, rk3399 is a good model for this
<marcan>
the dp/usb/phy/tcpm model is the same as what we have
<marcan>
we're just going to have another one for TB
<sven>
ah, nice
<marcan>
right now we don't do USB3 at all, right?
<sven>
not really
<marcan>
right
<sven>
that requires a real phy driver
<marcan>
yeah
<sven>
(aka bunch of magic pokes and possibly tunables)
<marcan>
and the acio stuff presumably, or at least the atc switching
<marcan>
so that's when we'll have to look at that
<sven>
i think acio is only for thunderbolt
<marcan>
for now, if you can get USB2 to work with the hs port0, that's good enough
<sven>
not sure though
<marcan>
I think acio handles tb, yeah
<marcan>
not sure if it has a hand in dp mode switching though
<sven>
yeah, no idea. all i know how is how to boot that thing so far
<marcan>
lol
<marcan>
anyway, this all looks reasonable
<marcan>
see if you can get hotplug to work by using that roleswap stuff
<marcan>
and just define the port0 (hs) link
<marcan>
and we can expand from there
<sven>
(and then reset the whole machine 2 minutes later because i probably skipped all the phy init and some internal state dies but those are details :-P)
<marcan>
lol
<sven>
but yeah, that's my plan. first get usb2 hot plug working and then take it from there
<marcan>
yeah
<alyssa>
08:09 <@marcan> sven: fwiw, rk3399 is a good model for this
<alyssa>
08:09 <@marcan> the dp/usb/phy/tcpm model is the same as what we have
<alyssa>
tbf type-c on rk3399 is only mostly broken 🤷
<sven>
i think marcan volunteered to fix that as well!
<alyssa>
sven: ADT suggests acio is a prerequisite for HDMI audio
<sven>
uhhhh... that sounds weird. but then again, this is apple
<alyssa>
er might be mixing up with sio
<alyssa>
the funny DMA thing
<sven>
yeah, that's sio
<alyssa>
sorry
<alyssa>
too many acronyms
<sven>
i *think* cio only needs to be booted when you want to tunnel pcie over thunderbolt
<sven>
because the moment i disconnect my thunderbolt dock macos shuts cio down again
<alyssa>
what do you even use thunderbolt for lol
<sven>
uh, i have a thunderbolt dock to connect all my peripherals to my macbook air
<alyssa>
fun
<alyssa>
(I have a type-C to type-A + HDMI cable that's tunnelling displayport internally .. I don't think that's tbolt though right?)
<sven>
don't think so
<alyssa>
was going to say i didn't think rk3399 could do tbolt
<sven>
my dock does usb-c to uhh... displayport,ethernet,like 10 or so usb3 ports, sound and a sd card slot for some reason
<j_ey>
swiss army dock
<alyssa>
Damn
<sven>
marcan: have you ever dumped the firmware running on those PD chips btw?
X-Scale has joined #asahi-re
<marcan>
sven: not on the M1 ones
<marcan>
it's one of those ROM + patch things
<marcan>
I have the patch set for some x86 macs with the same ones
<marcan>
but for the ROM I think you need to start poking at SWD
<marcan>
alyssa: I have an offer from a dock company to send me over some free ones to bring this up :>
<marcan>
I'll probably take them up on that soonish
jbowen has quit [Quit: leaving]
jbowen has joined #asahi-re
yuyichao has quit [Ping timeout: 480 seconds]
riker77 has quit [Quit: Quitting IRC - gone for good...]
riker77 has joined #asahi-re
austriancoder has quit []
austriancoder has joined #asahi-re
yuyichao has joined #asahi-re
mindfreeze has quit []
mindfreeze has joined #asahi-re
quarkyalice has joined #asahi-re
quarkyalice has quit [Remote host closed the connection]