On Wed 25 Aug 10:59 PDT 2021, Bryan O'Donoghue 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 > Right, conceptually the problem is similar, but IMHO there's a big difference in that the redriver and PHY are two physically separate entities - on different buses. The dwc3 glue and core represent the same piece of hardware. > 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. > Right, downstream the DPU driver is involved in the orientation switching in the PHY, but upstream this moved into the PHY driver. > 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 > > Seems to me that the type-c mux way of diseminating to more than one place > might fight role-switching well too. > Both works by you the controller using the of_graph to acquire the handle to _the_ consumer. I'm not aware of any support that would allow us to signal two separate entities about the mux, orientation or role. But as I said, for the orientation (at least) we do need to signal two separate pieces of hardware (and drivers) about the change. Perhaps the notifier mechanism that Heikki linked to earlier would be sufficient though (I don't see a problem with probe deferring the redriver until the type-c controller is registered). But I don't like the idea of duplicating the rather clumsy of_graph definition on both the glue node and the core node in DT. Similar to how we previously had to do extcon in both nodes, and we kept getting that wrong. Regards, Bjorn
