yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi-re
PhilippvK has joined #asahi-re
phiologe has quit [Ping timeout: 480 seconds]
akemin_dayo has quit [Ping timeout: 480 seconds]
riker77 has quit [Quit: Quitting IRC - gone for good...]
riker77 has joined #asahi-re
akemin_dayo has joined #asahi-re
abilash1994[m] has joined #asahi-re
Tom__ has joined #asahi-re
StupidYui has quit [Ping timeout: 480 seconds]
<
alyssa>
looks like we can get to i2c via dcp over one of the other endpoints (dpdev, mdcp29xx, ..)
nsklaus_ has joined #asahi-re
<
sven>
hrm, so we may need that rtkit node after all?
<
alyssa>
sven: what makes you say that?
<
alyssa>
if everything we need is accessible over dcp, we don't /need/ i2c from the ap
<
alyssa>
it's unclear to me if the other endpoints expose raw "send i2c, recv i2c" calls
<
sven>
so this is not a separate i2c bus we need to expose to other drivers
<
alyssa>
no, I don't think so
<
alyssa>
usually there's an i2c bus for the display and that does get routed into userspace but AFAIK there's no good reason to fake it in our case
<
alyssa>
well, "fake" .... there still an i2c bus that the DCP is using internally to get at display properties
<
alyssa>
just a question of whether the AP can bypass the DCP (directly or indirectly), and whether that's ever useful
<
sven>
uhh... wtf.. the interrupt mask on the USB PD chips seems to be 8 bytes but the interrupt event register 11 bytes of which macos only reads 9?!
<
roxfan>
72 bits ought to be enough for everyone
method_ has joined #asahi-re
Method has quit [Ping timeout: 480 seconds]
<
sven>
urgh.. and it looks like the interrupt bits are different from those defined in the TI manual i think :/
<
roxfan>
it would be too boring otherwise
boardwalk has joined #asahi-re
nsklaus_ has quit [Quit: WeeChat 3.2]
bpye has joined #asahi-re
nsklaus has joined #asahi-re
yrlf has joined #asahi-re
akemin_dayo has quit [Ping timeout: 480 seconds]
ella-0[m] has quit [Ping timeout: 480 seconds]
ella-0[m] has joined #asahi-re