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.wang@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 holdpipe
* power state in P2 before initializing TypeC PHY on RK3399platform.
*/- 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