Messages in this thread | | | From | Jagan Teki <> | Date | Wed, 9 Sep 2020 19:26:47 +0530 | Subject | Re: [PATCH 0/3] extcon: Add Type-C Virtual PD |
| |
Hi Heiko,
On Sat, Sep 5, 2020 at 2:53 AM Heiko Stübner <heiko@sntech.de> 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.
| |