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. Heiko