Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200904191830.387296-1-jagan@amarulasolutions.com> <6955091.ERBjKZ0CLf@diego>
In-Reply-To: <6955091.ERBjKZ0CLf@diego>
From:   Jagan Teki <jagan@amarulasolutions.com>
Date:   Wed, 9 Sep 2020 19:26:47 +0530
Message-ID: <CAMty3ZDNVZyYHAuBpCcn_=BhLvcRRHcOXKEWQqxUOdOs2+fp-Q@mail.gmail.com>
Subject: Re: [PATCH 0/3] extcon: Add Type-C Virtual PD
To:     =?UTF-8?Q?Heiko_St=C3=BCbner?= <heiko@sntech.de>
Cc:     MyungJoo Ham <myungjoo.ham@samsung.com>,
        Chanwoo Choi <cw00.choi@samsung.com>,
        Rob Herring <robh+dt@kernel.org>, Tom Cubie <tom@radxa.com>,
        devicetree <devicetree@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-amarula <linux-amarula@amarulasolutions.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Heiko,

On Sat, Sep 5, 2020 at 2:53 AM Heiko St=C3=BCbner <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.