Hi,

On Wed, 25 Aug 2021 at 20:57, Bryan O'Donoghue
[off-list ref] wrote:

On 25/08/2021 16:53, Bjorn Andersson wrote:

quoted

But in the case of Type-C altmode several of our boards have either an
external gpio-based SBU-pin-swapper or some redriver on I2C with this
functionality, so we need a way to tell both the PHY and this external
contraption about the orientation.

Its a very similar problem to orientation switch

As an example

- redriver may need to fix up signal integrity for
   lane switching

- PHY needs to toggle lanes from one IP block to another

I don't think off the top of my head a USB controller or DPU cares much
about the orientation switch but for argument sake you could add one to
that list.

I _think_ the type-c mux layer handles this though, as in what we did on
RB5 has PHY and redriver receiving and reacting to a type-c orientation
switch both with the existing type-c port driver and the new tcpm.

+ Dmitry - he did the mux work on the PHY and the redriver

For the RB5 case I ended up with the redriver acting as a client for
the type-c port orientation events, and then it would act as a source
for the event being sent to the DP PHY. This chained approach is far
from being ideal, but it allowed me to use the current framework
without applying significant changes. I've had some ideas on how to
improve the type-c framework, but I never had enough time to
materialize them.

Seems to me that the type-c mux way of diseminating to more than one
place might fight role-switching well too.

-- 
With best wishes
Dmitry