[U-Boot] [PATCH v2 3/4] usb: dwc3: add support for 16 bit UTMI+ interface

[Kever Yang <kever.yang@rock-chips.com>]

Hi Marek,

On 08/29/2016 09:01 AM, Marek Vasut wrote:
> On 08/29/2016 02:55 AM, Kever Yang wrote:
>> Hi Marek,
>>
>> On 08/26/2016 05:09 PM, Marek Vasut wrote:
>>> On 08/25/2016 03:17 AM, Kever Yang wrote:
>>>> Hi Marek,
>>>>
>>>> On 08/24/2016 07:38 PM, Marek Vasut wrote:
>>>>> On 08/24/2016 05:46 AM, Kever Yang wrote:
>>>>>> The dwc3 controller is using 8 bit UTMI+ interface for USB2.0 PHY,
>>>>>> add one variable in dwc3/dwc3_device struct to support 16 bit
>>>>>> UTMI+ interface on some SoCs like Rockchip rk3399.
>>>>>>
>>>>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - use a variable to identify utmi+ bus width instead of CONFIG MACRO
>>>>>>
>>>>>>     drivers/usb/dwc3/core.c |  6 ++++++
>>>>>>     drivers/usb/dwc3/core.h | 12 ++++++++++++
>>>>>>     include/dwc3-uboot.h    |  1 +
>>>>>>     3 files changed, 19 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>>>> index 85cc96a..0613508 100644
>>>>>> --- a/drivers/usb/dwc3/core.c
>>>>>> +++ b/drivers/usb/dwc3/core.c
>>>>>> @@ -388,6 +388,11 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
>>>>>>         if (dwc->dis_u2_susphy_quirk)
>>>>>>             reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
>>>>>>     +    if (dwc->usb2_phyif_utmi_width == 16) {
>>>>>> +        reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
>>>>>> +        reg |= DWC3_GUSB2PHYCFG_USBTRDTIM_16BIT;
>>>>>> +        reg |= DWC3_GUSB2PHYCFG_PHYIF_16BIT;
>>>>>> +    }
>>>>> Didn't we agree to pull this info from OF ?
>>>> Yes, the dwc->usb2_phyif_utmi_width is from OF,  but I make the DT parse
>>>> in board file instead of in the dwc3 driver,  see my patch:
>>>> [PATCH v2 2/4] board: evb-rk3399: add api to support dwc3 gadget
>>> So this is basically a passing of platform data ?
>> Yes, this is what other platform do, I just extend one more setting.
> Platform data should go away in favor of the DT probing.
>
>>>> I think implement in this way won't affect other soc also using dwc3
>>>> controller,
>>>> the DT parse would cost some time which may not necessary for other soc.
>>> The time needed to run the DT parsing is completely insignificant.
>>> This sounds like a premature optimization.
>> Which way of implement this DT parse do you prefer and more reasonable,
>> in dwc3 driver or in board init and dwc3 driver use it as platform data?
> Driver should parse the DT.

I'm going to parse the DT for this new 16bit UTMI+ interface, and keep 
other part "as is"
because the dwc3 device node for different SoC are different now.

Does this make sense to you?

Thanks,
- Kever
>
>> Thanks,
>> - Kever
> [...]
>