This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/TUSB422: TUSB422 driver / doc for Linux incomplete

Part Number: TUSB422
Other Parts Discussed in Thread: AM5748, TPS65982

Tool/software: Linux

Hello 

I got TUSB422_SW software from TI and I tried to compile the Linux driver wit TI Linux SDK 4.3 as suggested in TUSB422 Linux Driver Users Guide.pdf

  • Copied the contents of tusb422_linux_v0.99 to ./drivers/usb/tusb422 (maybe there is a more suitable place. There is no hint in the doc)
  • Added “obj-$(CONFIG_TUSB422)                             += tusb422/” to ./drivers/usb/makefile
  • Added “source drivers/usb/tusb422/Kconfig" in  ./drivers/usb/Kconfig in line 108

Kernel config: 

CONFIG_TUSB422=y
CONFIG_TUSB422_PAL=y

Finding 1: It does not compile because string.h is not included if  CONFIG_TUSB422 is set.

#ifndef CONFIG_TUSB422
       #include <linux/string.h>
#endif

I can correct that, but I wonder if this driver was ever compiled under Linux by TI??

Finding 2: It does not compile due to missing include file in usb_pd_pal.c : #include <huawei_platform/usb/hw_pd_dev.h>

In the TUSB422 Linux Driver Users Guide.pdf there is a hint that "USB PD platform abstraction layer (PAL) must be ported to enable the software for use on specific platforms.". There is no hint how to implement these function in usb_pd_pal.c. Brian Quach from TI commented "A platform abstraction is required and an example for a Huawei platform is included". In fact, there is no such example included.

In addition to the PAL there is also a lot of parameters that can be set in the device tree, see tusb422-pd.txt. There are parent a child nodes but no explanations how to use.

I need help for our simple use case:

- Schematic as below (has been reviewed by TI). TUSB is connected to AM5748 USB port 1 or 2. We use USB type C connector and want to run USB 2.0 and 3.0.

 We would like to test 2 scenarios:

Scenario 1): Ethernet over USB. This is for testing device mode.

 CPU USB port is in device mode, Ethernet gadget active.

Windows PC connected with USB type A to type C cable

 Scenario 2): Access to USB-C memory stick. This is for testing host mode.

 ---

 

Would it be possible to support us for these I guess quite simple scenarios?

We would need help here:

 -         Suggested device tree settings according to tusb422-pd.txt

-          Suggested minimal implementation of platform-specific functions in usb_pd_pal., if required at all for the given scenarios (by setting CONFIG_TUSB422_PAL=n ?)

 Our USB interface can deliver 5V / 3A. 

Regards, Chris

  • Hi Chris,

    I'm afraid this source code is provided as-is because we do not have the resources to provide in-depth support for it. This code has been compiled and tested on the BeagleBone Black platform connected to the TUSB422 EVM. Additionally, customers have successfully used it to go to mass production without support. The documentation is minimal but the code should be easy enough to understand and use for those familiar with USB-PD and Linux driver development. For those wanting a easy plug-n-play solution, I recommend a firmware-based USB-PD part such as TPS65982 which can control power directly. The TUSB422 is a PD PHY only and therefore requires a significant amount of SW effort to integrate into the platform as all logic and power & data control is handled outside of the part.

    The tusb422-pd.txt file explains all the settings and provides a basic example. If you source power, just implement a single source node and no sink nodes. You only need to implement the PAL functions your platform supports or requires. Otherwise, you can leave them empty. Source and disable VBUS function at minimum. The function names describe what their purpose is.

    Alternatively, if you set "CONFIG_TUSB422_PAL=n", then you'll need to modify tusb422_linux.c to port tusb422_set_vbus() and tusb422_clr_vbus() called by tusb422_common.c to your system.

    Regards,
    Brian