[PATCH 4/8] usb: dwc3: add make compatible for rockchip platform

[Marek Vasut]

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.wang at 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.