Re: [PATCH 0/3] Implement role-switch notifications from dwc3-drd to dwc3-qcom

From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Felipe Balbi <balbi@kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Peter Chen <peter.chen@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	agross@kernel.org, gregkh@linuxfoundation.org,
	jackp@codeaurora.org, wcheng@codeaurora.org,
	linux-usb@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Subject: Re: [PATCH 0/3] Implement role-switch notifications from dwc3-drd to dwc3-qcom
Date: Wed, 25 Aug 2021 13:06:36 -0700	[thread overview]
Message-ID: <YSaizDpqNRZcBGIc@ripper> (raw)
In-Reply-To: <90d17c95-1cf3-89aa-94ad-920e4781f866@linaro.org>

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