On Mon, Feb 26, 2024 at 02:44:21AM +0000, Xu Yang wrote: > [...] > > > > > But there is no change. Your log has: > > > > CC1: 0 -> 0, CC2: 2 -> 2 [state SRC_TRYWAIT, polarity 0, connected] > > > > How to interpret this? This is with fusb302 driver. The driver has bunch of > > When try sink fails (note: cc:=2 in this period), the tcpm will change to SRC_TRYWAIT > state and it will pull up CC to Rp-default (cc:=3). Since the partner is a sink-only port, > I think the type-c chip will sense a connection is established. Therefore, a CC change > event is reported by type-c chip. I'm not sure the behaviors of fusb302 chip when set > cc:=3. If it does not generate interrupt for this change, then tcpm may think the partner > has been disconnected and move the state to SRC_TRYWAIT_UNATTACHED. Maybe it's a > real hw issue or the event is masked by sw. > > Is this dock also failed to connect other sink-only devices? The hub is sink-only. It is connected to a DRP phone Type-C port (which is using fusb302), which is where my log is from. I also have a board with husb311 Type-C chip and DRP port, which I can use for comparison (with/without your patch), I guess. It's TCPCI based (husb311), so that should eliminate bug in fusb302 driver as a possibility, I think. Kind regards, o. > > gates to not report cc status when it doesn't change: > > > > https://elixir.bootlin.com/linux/latest/source/ > > drivers%2Fusb%2Ftypec%2Ftcpm%2Ffusb302.c%23L1215&data=05%7C02%7Cxu.yang_2%40nxp.com%7C836aa20d8f9549e9 > > 636008dc34ea9e0f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638443429472475922%7CUnknown%7CTWFpbGZ > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bCXr5obX2B > > hKh5ZZt7CZHQ6OLhJ7JFgSPkW7f49NKfs%3D&reserved=0 > > > > in several places where tcpm_cc_change is called. Not sure what is the > > expectation of TCPM state machine, whether it always expects tcpm_cc_change() > > call after it calls set_cc callback, or what exactly. > > I think the tcpm_cc_change() will be called only when a real CC change happens > on the CC line. It's irrelevant to whether tcpm_set_cc() is called or not. > > Thanks, > Xu Yang > > > > > kind regards, > > o. > > > > > Please refer to USB Type-C Specification > > > Figure 4-17 Connection State Diagram: DRP with Accessory and Try.SNK Support > > > > > > Thanks, > > > Xu Yang > > > > > > > [ 13.378347] state change SRC_TRYWAIT -> SRC_TRYWAIT_UNATTACHED [delayed 100 ms] > > > > [ 13.378364] state change SRC_TRYWAIT_UNATTACHED -> SNK_UNATTACHED [rev1 NONE_AMS] > > > > [ 13.378373] Start toggling > > > > [ 13.387019] state change SNK_UNATTACHED -> TOGGLING [rev1 NONE_AMS] > > > > [ 13.462597] CC1: 0 -> 0, CC2: 2 -> 2 [state TOGGLING, polarity 0, connected] > > > > [ 13.462606] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] > > > > [ 13.462613] pending state change SRC_ATTACH_WAIT -> SNK_TRY @ 200 ms [rev1 NONE_AMS] > > > > [ 13.662808] state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms] > > > > [ 13.662827] cc:=2 > > >
