04:02 <aka_[m]> konradybcio: minecrell[m]: said it doesn't change anything so I went for it in apss, gfx one has no such

04:03 <aka_[m]> Haven't noticed any special crashing or anything

04:31 <travmurav[m]> lumag: quick look at the acpi suggests there are read/write functions for it and I guess it's not tooo hard to hook it up into my ec driver

04:32 <travmurav[m]> lumag: afaiu this is for dual-role and PD tho and I think both are kinda useless on aspire1 - the type-c is on a hub so no periph mode and there is no PD support, otherwise stuff like lane flipping and dp alt is done with a mux chip controlled by the type-c controller, so it "just works"...

04:33 <travmurav[m]> I guess talking PD might be fun still, so I may look into it

04:33 <travmurav[m]> lumag: do you think I miss out on something without UCSI or maybe have some usecase for it?

09:42 <aka_[m]> konradybcio: is that something to your likings?

09:42 <aka_[m]> https://patchwork.kernel.org/project/linux-arm-msm/list/?series=844935

13:07 <lumag> travmurav[m], My end-goal is to be able to correlate the DP connector and the typec port like it's done on x86. I've posted my current attempt at https://lore.kernel.org/linux-arm-msm/20240416-ucsi-glink-altmode-v1-0-890db00877ac@linaro.org/ . Once it is merged (hopefully) I plan to actually add the symlinks between DP connector and corresponding typec port. So, I'd say, having UCSI in place might improve end-user experience.

13:08 <travmurav[m]> lumag: oh I see

13:08 <lumag> travmurav[m], but I can't say that it becomes an absolute requirement.

13:08 <lumag> Also the 'merged altmode' isn't yet accepted

13:09 <travmurav[m]> lumag: I tried to play with it a bit right now and it seems like i can talk to it, even if very annoyingly

13:09 <lumag> You've mentioned c630, that's also currently pending on the 'merged' altmode approach.

13:09 <lumag> travmurav[m], what do you mean by 'annoyingly'?

13:10 <travmurav[m]> there is either some weird imlementation quirk or I don't understand how acpi implements it

13:10 <travmurav[m]> lumag: hm "merged altmode" as in?

13:11 <lumag> the altmode driver being merged into the UCSI glue code

13:11 <travmurav[m]> ah

13:11 <lumag> like in the referenced patchset

13:12 <lumag> ok, I got the point that it's not trivial on your platform.

13:12 <travmurav[m]> well in my case for dp alt right now I just have a bridge/connector that notifies the hpd based on what ec says, and all the muxing/lane switching/rotating is done transparently by the ec and the chips it controls

13:13 <travmurav[m]> but maybe I miss the idea on what ucsi does in this case

13:13 <lumag> Yeah, it's nice. In case of pmic-glink we have to manually control all the switches and muxes

13:13 <travmurav[m]> lumag: I think it's possible to implement and I just didn't reverse-engineer it far enough

13:13 <lumag> In your case I think it only brings /sys/class/typec/portN and portN-partner

13:14 <travmurav[m]> lumag: and I guess with glink you need to read rotation from ucsi and apply it with the kernel?

13:14 <lumag> rotation = orientation (CC1 / CC2)?

13:14 <travmurav[m]> yeah the port0 appear indeed (but so far I did some mistake and I don't get the events to update it)

13:15 <travmurav[m]> yes, type c orientation

13:15 <lumag> If so, then it's even worse. UCSI doesn't have orientation information (it's old 1.x). altmode reports orientation, but it does so only for DP connections. So we ended up always reading the GPIO from PMIC

13:16 <travmurav[m]> mhm

13:16 <lumag> (in the patchset I've brought up the code to use orientation from altmode, but I absolutely hate it)

13:16 <lumag> But we need it for backwards compat

13:16 <travmurav[m]> so for glink you need to read ucsi to detect it's dp-> read pmic gpio for orientation -> mux dp and pick the lanes?

13:17 <lumag> No, that would be too good. pmic-glink also has a separate 'altmode' interface / events

13:18 <travmurav[m]> mhm

13:18 <travmurav[m]> but I guess I see what UCSI does more or less

13:19 <lumag> So UCSI tells us about USB-related events (like switching between safe / not-connected and USB / whatever). While altmode events bring up DP altmode information, lanes count and orientation (which we already know from GPIO).

13:19 <lumag> The story started for me as a way to express that this DP-1 connector is really wrapped in the USB-C connector.

13:20 <lumag> you are not getting events to update it -> do you mean that you are not getting the USB events from EC?

13:21 <lumag> Or that UCSI itself can not process them?

13:22 <travmurav[m]> I get first event but it doesn't seem to get processed/stuck with no subsequent events

13:22 <travmurav[m]> well the problem for me is that apparently I'm not allowed to re-read the values (get all 0)

13:22 <lumag> I see.

13:22 <travmurav[m]> and the ucsi "core" likes to call read() multiple times...

13:22 <travmurav[m]> so I'm trying to workaround it by selectively not updating the "cache"

13:23 <lumag> So probably you have to copy them to the internal buffer and update them only when the notify event happens.

13:23 <lumag> I think ACPI does it in this way

13:23 <travmurav[m]> and the reason I'm confused is because it seems like acpi code doesn't care and just read/updates it every read call

13:23 <lumag> DSTD handles that internally

13:23 <lumag> DSDT

13:23 <travmurav[m]> and with "only update by notify" there is the reset call that is polled and doesn't fire event...

13:24 <lumag> Hmm, this sounds pretty close to what Christian was trying to do in one of his patchsets.

13:24 <lumag> Ok, I see.

13:28 <lumag> https://lore.kernel.org/linux-usb/20240218222039.822040-5-lk@c--e.de/

13:28 <lumag> Here he proposed exactly the kind of API that you might need.

13:29 <travmurav[m]> yeah this sounds like what I have a problem with then

13:30 <lumag> Or something like ucsi_zenbook_read() might solve your issue

13:30 <lumag> until we have poll_cci

13:30 <travmurav[m]> yeah that makes sense since dsdt code for the event handler does the read into the ram buffer so I guess the user is not supposed to call the read() again

13:31 <travmurav[m]> that is, dsdt read function

13:31 <lumag> ucsi_zenbook_read() caches the command and ignores reads unless the command was PPM_RESET

13:32 <lumag> Ok, I think I troubled you enough for a 'would be nice' piece of code. Excuse me :-)

13:33 <travmurav[m]> well it still doesn't look too complicated

13:34 <travmurav[m]> tbh the main problems for me with this are the header is local but my driver is in drivers/platform/arm64 and that I don't have access to many type-c devices/cables to try to make it talk to them xD

13:34 <travmurav[m]> that is, with the first not sure if we need to expose usci.h then

13:58 <lumag> no. CrOS people tried to do that. I'd suggest keeping the UCSI glue in drivers/usb/typec/ucsi and having the API interface between driver parts.

13:59 <travmurav[m]> mhm

13:59 <lumag> I'm thinking about using generic notification chains.

14:01 <travmurav[m]> lumag: well, seems like after making sure I don't read from hw too much, it talks and does quite a lot of messages even (which look a bit slow, ~13s to update), though still not sure how to interpret the sysfs values I get

14:01 <lumag> We have driver-specific callbacks in pmic-glink. Now if I were to write ucsi-c630, I also have to add new callbacks call. CrOS also have their own notifications / callbacks

14:03 <lumag> travmurav[m], at the very least you should be able to see /sys/class/usb_power_delivery/ and your power-supply caps if you have a USB-C charger

14:03 <lumag> 13 seconds is strange indeed

14:04 <lumag> in /sys/class/typec/ there should be data_role and power_role attributes.

14:05 <lumag> also once DP dongle is plugged there should be /sys/class/typec/portN-partner with PD atributes

14:05 <lumag> (or none if none are supported)

14:05 <travmurav[m]> yeah the partner seems to appear when I plug dp capable dongles

14:05 <travmurav[m]> there are some fun svid/vdo values I guess they encode capabilities?

14:06 <lumag> svid 0xff01 = DP

14:06 <travmurav[m]> yeah definitely see it

14:06 <lumag> hmm, do you have /sys/class/typec/port0/port0.N dirs?

14:06 <travmurav[m]> yes I think

14:07 <lumag> Interesting. These correspond to UCSI-managed altmodes

14:07 <lumag> I wonder if UCSI on its own can manage DP altmode on your platform

14:07 <travmurav[m]> as in the mux?

14:08 <travmurav[m]> for me it "just works" yes, the type-c mcu controls an external usb/dp mux redriver and I just need to read the hpd bit

14:10 <lumag> No, I had something different in mind: UCSI has its own handler for altmodes, especially for the displayport mode. But it doesn't seem to handle HPD.

14:13 <travmurav[m]> lumag: well in any case, what I have so far is this: https://github.com/TravMurav/linux/commit/2ba83979a78ff3d99b92d293095ab16b1820dde5

14:13 <travmurav[m]> definitely needs cleanup and I guess as you say, also would need to be hooked into ucsi differently

14:15 <lumag> I'd say this is pretty nice.

14:16 <lumag> Yes, I think this should be moved to usb/typec/ucsi. And I'll keep this platform in mind if we were to refactor UCSI platform ops

14:17 <lumag> if you can paste somewhere `ls -lR /sys/class/typec/port0/` with your DP dongle plugged, that would also be very nice.

14:21 <travmurav[m]> lumag: https://paste.debian.net/hidden/8235a248/ <- the trace of communication + the ls

14:21 <lumag> thanks!

14:21 <travmurav[m]> this is after plugging a type-c->DP (not hdmi) dongle without a dp cable in it

14:22 <lumag> Wow. /sys/class/typec/port0/port0-partner/port0-partner.0/mode1 -- I don't have this even on x86 (lenovo). This means that EC reports properly altmodes supported by the dongle.

14:24 <travmurav[m]> is "description" supposed to be filled in btw? it seems always empty

14:29 <travmurav[m]> I've also borrowed a phone that can do dual role and pd, asked it to switch the roles with the laptop but there was no activity whatsoever on ucsi, though not sure if it's because the phone/laptop already knows it can't switch and never reports the attempt

14:30 <lumag> Good question. I see that Aspire1 can not charge through the USB-C port, maybe that plays a role there.

14:30 <travmurav[m]> yes, there is no pd charging hardware sadly

14:31 <lumag> Description is set by the altmode driver, but I'm not sure if it is supported to be used in your case. See TYPEC_DP_ALTMODE

14:32 <lumag> The trace is strange. It almost looks like there is 0.5 second sleep somewhere

14:32 <travmurav[m]> I think I could actually even hack everything up to do periph mode in usb2 sicne there is a nice "edl mode" switch that bypasses the internal hub, I guess I could assert the edl pin of the soc to switch those xD

14:32 <travmurav[m]> yeah, feels like ec takes .5s to respond

14:32 <travmurav[m]> hm

14:33 <travmurav[m]> I think polling for the reset is also .5s

14:34 <travmurav[m]> ah no, just close write reset at 0.241748 -> success at 0.614046

14:35 <lumag> 1587.306205 -> 1587.715549 also less than 0.5

14:35 <lumag> It's as if at some point it switched to 0.4s

14:35 <travmurav[m]> hm right, perhaps it;s really how long it takes for the ec to talk to the other mcu

14:36 <lumag> [ 1589.778641] aspire-ec 2-0076: unknown error 0

14:36 <lumag> [ 1589.778657] aspire-ec 2-0076: UCSI_GET_PDOS failed (-5)

14:36 <lumag> We should add support for something like no-pd

14:36 <travmurav[m]> I think this doesn't always appear actually

14:38 <lumag> Maybe it's something like UCSI_DELAY_DEVICE_PDOS

14:38 <travmurav[m]> I have 3 dongles: dp+usb+pd-passthrough hub (no error); dp (the log with error); hdmi (no error too)

14:38 <lumag> Hmm, I must read it more carefully

14:38 <travmurav[m]> so I think it's specific to the dongle...

14:40 <lumag> Most likely it's reporting the 'partner doesn't do PD' in a weird way

14:40 <lumag> The error means that UCSI returned an error, but then when questioned regarding the error, it returns 0

14:40 <lumag> I'd say we can ignore that