On Fri, Sep 14, 2018 at 02:59:49PM -0700, Rob Weber wrote:
> On Fri, Sep 14, 2018 at 11:09:15AM +0300, Heikki Krogerus wrote:
> > Adding Hans. Hans has become something of a Cherry Trail expert.
>
> Hello Hans. Yesterday I was reading through your blog posts that describe
> your work with the GPDWin CHT platform and I definitely learned a lot from
> them. Thank you for sharing!
>
> > > Our system includes two USB 3.0-capable ports with Type-C connectors.
> > > One port is designed to be a host-only port (downstream-facing),
> > > while the other port is designed to be a dual-role port. The USB 2.0
> > > data lines and the SuperSpeed lines are connected to the SoC. Our
> > > system uses two USB Power Delivery controllers to help with PD
> > > negotiations. We have an OTG_ID signal connected to the SoC.
> > > Depending on the data role negotiation (which we detect from the PD
> > > controller), we either tie that signal to GND or let it float.
> > > I'm running a 4.9.115 kernel built using Yocto with a few patches applied
> > > to enable HDMI audio.
> > >
> > > I've been working very closely with our BIOS vendor to initialize the
> > > CherryTrail SoC's embedded host and device controllers properly. I've been
> > > able to validate that both of our USB-C ports work at both 2.0 and 3.0 speeds
> > > from the BIOS, but Linux only has access to our host port. The dual-role
> > > port is not operational from Linux.
> >
> > Your kernel is indeed a bit old, and it is missing a lot of code that
> > adds USB Type-C and PD support. It also does not have for example a
> > driver for the internal Intel USB role mux. That driver may not always
> > be needed (the firmware may be configuring the mux), but I don't know
> > what is the situation on your platform.
> >
> > Can you find out the following things for us:
> >
> > - Does the BIOS program the internal USB role mux, or is the
> > operating system expected to take care of it?
>
> I'm waiting for confirmation from the BIOS vendor on this configuration,
> but I believe the firmware is configured to not control the mux and
> leave it up to the OS. Here are the values of the DUAL_ROLE_CFG_REG0 and
> DUAL_ROLE_CFG_REG1 registers as seen from the BIOS UEFI shell:
>
> Shell> mm 91B080D8 -w 4 -MMIO
> MMIO 0x0000000091B080D8 : 0x00800000 >
> MMIO 0x0000000091B080DC : 0x20000000 >
>
> And here are the same registers as seen from Linux:
>
> $ devmem2 0x91b080D8
> /dev/mem opened.
> Memory mapped at address 0x7fc24cdc3000.
> Read at address 0x91B080D8 (0x7fc24cdc30d8): 0x0000000000B00800
>
> 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.
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.
Cheers,
--
heikki
