On Wed, Sep 19, 2018 at 02:36:17PM +0300, Heikki Krogerus wrote: > > I noticed that bits [21:20] are set as 0b11. The datasheet describes > > these bits as software configuration of the OTG_ID signal functionality. > > With these bits set, does that mean that the OS is expected to be > > configuring the internal mux as you've described? > > No, it does not mean that. Software can here mean firmware as well. > > Normally there are ACPI methods that program the mux. Your ACPI tables > have methods named CDRH (for host mode) and CDRD (for device mode). > Those methods should normally be called as a result of a GPE (General- > purpose Event) that the embedded controller firmware generates after > it has determined the desired USB role. > > > If the "software ID" configuration requires the OS to control the mux, > > then would the opposite of this involve the hardware OTG_ID signal > > controlling the mux instead? > > > > > - How do you interact with the PD controller from the operating > > > system? Is the PD controller connected to the embedded controller or > > > to the SoC (or both) via some serial bus like I2C? > > > > > > - Which PD controller is it? What's the manufacturer and the model? > > > > The two PD controllers are both a Cypress CCG3. We also have an STM32 MCU > > that interacts over I2C with the CCG3s, among other components. The data > > signals and SuperSpeed signals are connected directly to the SoC. > > That means you have the EC (embedded controller) firmware on top of > things. It should be generating those GPEs. Okay, this all makes sense now. Thank you for the explanation. > The EC may also expose UCSI interface to the OS that allows you to see > the status of the Type-C ports, and also for example swap the roles > when possible. You can check if you have UCSI like this: > > % cat /sys/bus/acpi/devices/USBC000\:00/status > 15 > > If the value is 0 instead of 15, UCSI is not supported. > > > > My guess is that the role mux is again the culprit (it so often is). > > > If you can test a newer kernel, preferable v4.18, you should be able > > > to test manually via sysfs if configuring the mux helps. The kernel > > > option for the mux driver is CONFIG_USB_ROLES_INTEL_XHCI. You can set > > > it to device role like this: > > > > > > % echo device > /sys/class/usb_role/intel_xhci_usb_sw-role-switch/role > > > > Thanks for the suggestion, I'll start preparing an OS image with a 4.18 > > kernel and let you know what happens. > > OK. Thank you for your help, Heikki. Migrating to kernel 4.18 has solved the problem because we were missing the intel-xhci-usb-role-switch driver as you suspected. We're able to switch USB modes successfuly from userspace as well. Sorry for the delayed response. Board bring-up has been quite hectic, but my team and I really appreciated the help. Cheers, Rob Weber
