mbox series

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

Message ID 20200904191830.387296-1-jagan@amarulasolutions.com
Headers show
Series extcon: Add Type-C Virtual PD | expand

Message

Jagan Teki Sept. 4, 2020, 7:18 p.m. UTC
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?
Jagan.

Jagan Teki (3):
  dt-bindings: extcon: Document Type-C Virtual PD driver
  extcon: Add Type-C Virtual PD driver
  arm64: dts: rk3399-rock-pi-4c: Enable Display Port

 .../extcon/extcon-usbc-virtual-pd.yaml        |  66 ++++
 MAINTAINERS                                   |   6 +
 .../boot/dts/rockchip/rk3399-rock-pi-4c.dts   |  16 +
 drivers/extcon/Kconfig                        |  10 +
 drivers/extcon/Makefile                       |   1 +
 drivers/extcon/extcon-usbc-virtual-pd.c       | 285 ++++++++++++++++++
 6 files changed, 384 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usbc-virtual-pd.yaml
 create mode 100644 drivers/extcon/extcon-usbc-virtual-pd.c

Comments

Heiko Stübner Sept. 4, 2020, 9:23 p.m. UTC | #1
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.

That the Rockchip rk3399 currently carries that extcon thingy is unfortunate
and only works for ChromeOS devices based on the rk3399.

The kernel now has a real type-c framework so we should not extend this
extcon hack any further, because that will make it even harder to roll back
later. Also simply because other Rockchip boards currently can't really make
use of type-c due to this, as they use the fsusb302 phys directly connected.

ChromeOS actually spend some time to make the cros-ec pd part of the type-c
framework if I remember correctly, so a viable battle plan would be to:

(1) move the Rockchip type-c phy driver to actually be part of the type-c
    framework, with the extcon being a deprecated fallback for old DTs.
(2) implement your gpio-altmode as part of the type-c framework
    (which may even already exist)


In short, please don't extend the rk3399 type-c extcon hack.

Thanks
Heiko
Jagan Teki Sept. 9, 2020, 1:56 p.m. UTC | #2
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.
Rob Herring Sept. 14, 2020, 11:15 p.m. UTC | #3
On Fri, Sep 04, 2020 at 11:23:21PM +0200, Heiko Stübner 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.

I don't accept new extcon bindings or users of it either. It's a 
poorly thought out collection of Linux driver properties. Use the usb 
connector binding.

> 
> That the Rockchip rk3399 currently carries that extcon thingy is unfortunate
> and only works for ChromeOS devices based on the rk3399.
> 
> The kernel now has a real type-c framework so we should not extend this
> extcon hack any further, because that will make it even harder to roll back
> later. Also simply because other Rockchip boards currently can't really make
> use of type-c due to this, as they use the fsusb302 phys directly connected.
> 
> ChromeOS actually spend some time to make the cros-ec pd part of the type-c
> framework if I remember correctly, so a viable battle plan would be to:
> 
> (1) move the Rockchip type-c phy driver to actually be part of the type-c
>     framework, with the extcon being a deprecated fallback for old DTs.
> (2) implement your gpio-altmode as part of the type-c framework
>     (which may even already exist)
> 
> 
> In short, please don't extend the rk3399 type-c extcon hack.
> 
> Thanks
> Heiko
> 
> 
> 
>
Chanwoo Choi Sept. 15, 2020, 1:17 a.m. UTC | #4
Hi Rob,

On 9/15/20 8:15 AM, Rob Herring wrote:
> On Fri, Sep 04, 2020 at 11:23:21PM +0200, Heiko Stübner 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.
> 
> I don't accept new extcon bindings or users of it either. It's a 
> poorly thought out collection of Linux driver properties. Use the usb 
> connector binding.

I agree the prior binding format of extcon with 'extcon' property name
is not proper. So, I'll try to bind new style. But, I have a question.
Do you have the objection of the use of extcon like 'users of it either' 
of your comment?

> 
>>
>> That the Rockchip rk3399 currently carries that extcon thingy is unfortunate
>> and only works for ChromeOS devices based on the rk3399.
>>
>> The kernel now has a real type-c framework so we should not extend this
>> extcon hack any further, because that will make it even harder to roll back
>> later. Also simply because other Rockchip boards currently can't really make
>> use of type-c due to this, as they use the fsusb302 phys directly connected.
>>
>> ChromeOS actually spend some time to make the cros-ec pd part of the type-c
>> framework if I remember correctly, so a viable battle plan would be to:
>>
>> (1) move the Rockchip type-c phy driver to actually be part of the type-c
>>     framework, with the extcon being a deprecated fallback for old DTs.
>> (2) implement your gpio-altmode as part of the type-c framework
>>     (which may even already exist)
>>
>>
>> In short, please don't extend the rk3399 type-c extcon hack.
>>
>> Thanks
>> Heiko
>>
>>
>>
>>
> 
>