On 4/28/20 11:53 AM, Heiko Stübner wrote: > Am Dienstag, 28. April 2020, 11:21:07 CEST schrieb Marek Vasut: >> On 4/28/20 11:05 AM, Frank Wang wrote: >>> Hi Marek, >>> >>> On 2020/4/28 16:27, Marek Vasut wrote: >>>> On 4/28/20 8:27 AM, Frank Wang wrote: >>>>> RK3399 Type-C PHY is required that must hold whole USB3.0 OTG controller >>>>> in resetting to hold pipe power state in P2 before initializing the PHY. >>>>> This commit fixed it and added device compatible for rockchip platform. >>>>> >>>>> Signed-off-by: Frank Wang <frank.w...@rock-chips.com> >>>>> --- >>>>> drivers/usb/dwc3/dwc3-generic.c | 33 +++++++++++++++++++++++++++------ >>>>> 1 file changed, 27 insertions(+), 6 deletions(-) >>>>> >>>>> [...] >>>>> + /* >>>>> + * It must hold whole USB3.0 OTG controller in resetting to hold >>>>> pipe >>>>> + * power state in P2 before initializing TypeC PHY on RK3399 >>>>> platform. >>>>> + */ >>>>> + if (device_is_compatible(dev->parent, "rockchip,rk3399-dwc3")) { >>>>> + reset_assert_bulk(&glue->resets); >>>>> + udelay(1); >>>> Reset delay should be handled by the reset controller, no ? >>> This is dwc3's reset phandle linked to CRU on Rockchip platform, >>> however, the reset driver just update the register value, and the timing >>> need to be guaranteed by invoker itself. >> >> If the reset controller needs a delay after toggling the bit, then it >> should add such delay, no ? > > But normally the time a reset line should be pulled low/high whatever > is specified in the datasheet of the relevant controller (type-c phy here). > > My most recent experience is with dsi panels, where the panel-controller's > datasheet specifies how long its reset line needs to be pulled to achieve > a full reset of the controller - and I guess it will be similar with other > controllers. > > So to me this doesn't look like a property of the reset controller, but the > controller connected to the reset line - especially as different > "reset-clients" will have different timing constraints.
That's up to Frank to find out then.