Hi, On Wed, 25 Aug 2021 at 20:57, Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx> wrote: > > On 25/08/2021 16:53, Bjorn Andersson wrote: > > 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
