Hi Heiko, On Sat, Sep 5, 2020 at 2:53 AM Heiko Stübner <heiko@xxxxxxxxx> wrote: > > Hi Jagan, > > Am Freitag, 4. September 2020, 21:18:27 CEST schrieb Jagan Teki: > > USB Type-C protocol supports various modes of operations > > includes PD, USB3, and Altmode. If the platform design > > supports a Type-C connector then configuring these modes > > can be done via enumeration. > > > > However, there are some platforms that design these modes > > of operations as separate protocol connectors like design > > Display Port from on-chip USB3 controller. So accessing > > Type-C Altmode Display Port via onboard Display Port > > connector instead of a Type-C connector. > > > > These kinds of platforms require an explicit extcon driver > > in order to handle Power Delivery and Port Detection. > > > > This series support this Type-C Virtual PD and enable the > > same in ROCK Pi 4C SBC. > > > > Any inputs? > > I tend to disagree on the design via an extcon. Okay, are you disagree with the extcon extension for fusb chips routing or entire rk3399 designs? I totally agree with this point of bypassing extcon for the designs which has fusb302 chips. My only concern is about designs that don't have fusb chips - for example rock-pi-4. Designs that do have fusb302 chips, has dynamic possibilities to identify data roles, like detecting Altmode DP via Type-C connector whereas designs that don't have fusb302 or any type-c chip need static identification of data role, polarity, and ss for detecting direct DP port ie where virtual-pd is useful. Look like we have two potential issues of handling DP on rk3399 here, let me know if you think these non-type-c chips designs also possible to detect w/o extcon? Jagan.
