[PATCH 0/3] extcon: Add Type-C Virtual PD

Jagan Teki jagan at amarulasolutions.com
Wed Sep 9 09:56:47 EDT 2020


Hi Heiko,

On Sat, Sep 5, 2020 at 2:53 AM Heiko Stübner <heiko at 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.



More information about the linux-arm-kernel mailing list