Hi, On 4/29/2020 6:33 PM, Heikki Krogerus wrote: > Hi again, > >>> Thanks for the details so this will enable the role switch for drd controller. Now for UCSI driver to call the role make functions it needs the reference of the same switch reference, >>> >>> so for that do i have to use device_get_named_child_node(dev,"CON0"), in UCSI Driver? >> No. If you use the ucsi driver, and if your connector child nodes are >> in correct order, then ucsi_find_fwnode() takes care of assigning the >> node for you. >> >> But you do need to use the USB role class API to get a handle to the >> switch (dwc3) in the typec driver. >> >> UCSI is really meant to be a status interface. The specification >> states that the USB Type-C connectors should function autonomously >> without any OS involvement. So by relying on the driver to configure >> the muxes, you are actually corrupting that part of the specification. > I had to recheck that. I seem to be wrong about this. It does not > clearly state that the ports need to function autonomously. Also, in > this case the USB role switch isn't a mux. > > Sorry about that. > >> I would still strongly recommend that you use TI's own host interface. Thanks for the mail, in my view role switch is just software interface here to update the DWC3 controller for role change. I may be wrong here but this is my understanding. So on our platform PD is also connected as Master to USB/DP phy. Hence here is sequence as per my understanding during the role change. 1. PD detects the role change and update the phy register over I2C (as a i2c master) 2. PD also generated the interrupt to UCSI Driver (PD as a i2c slave) regarding the role change. 3. UCSI driver has to update same to DRD ( this is what we are all after that) 4. DRD will program controller register. I can implement /use TI's own host interface but requirement for us to have UCSI based driver. Regards Nehal
