From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Date: Tue, 28 Apr 2020 11:53:07 +0200 Subject: [PATCH 4/8] usb: dwc3: add make compatible for rockchip platform In-Reply-To: <68e3390d-8780-aae3-ae9c-6ea6b0a02222@denx.de> References: <20200428062747.8349-1-frank.wang@rock-chips.com> <7e92d2f5-7521-9272-80a4-93fbd8a35c24@rock-chips.com> <68e3390d-8780-aae3-ae9c-6ea6b0a02222@denx.de> Message-ID: <2014662.uXBneCcEaO@diego> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > >>> --- > >>> 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