[U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver

[Jean-Jacques Hiblot]

On 02/09/2019 13:29, Sherry Sun wrote:
> Hi Vignesh,
>
>> Hi Sherry,
>>
>> [...]
>>>> AFAIK, U-Boot does not support runtime switching of USB port to host
>>>> from device and vice versa. This is the case for existing driver like
>> DWC3/MUSB etc.
>>>> Ideally we would need a role switch driver that unbinds and rebinds
>>>> host vs device driver as when required based on U-Boot cmd or via an
>>>> API (if required to be done during SPL stage etc).
>>> I wonder if we can add two subnodes under the wrapper node as below,
>> one bind to usb gadget driver and another bind to usb host driver.
>>> So if we want to use usb device, just call the gadget driver, and if want to
>> use usb host, just call the host driver. The driver will probe correspond node.
>>> I'm not sure if it is feasible, what do you think about it?
>>>
>>>        usbss0: cdns_usb at 4104000 {
>>>            compatible = "ti,j721e-usb";
>>>            [....]
>>>            usb0: usb at 6010000 {		/* xhci reg address*/
>>>                compatible = "cdns,usb3-1.0.1";
>>> 	dr_mode = "host";
>>> 	[....]
>>> 	}
>>>            usb1: usb at 6020000 {		/* dev reg address*/
>>>                compatible = "cdns,usb3-1.0.1";
>>> 	dr_mode = "peripheral";
>>> 	[....]
>>> 	}
>>>      }
>>>
>> But this is not how DT would look in kernel. There will be single DT node
>> representing both Host and Device node. DT repesentation should not be
>> changed based on OS/bootloader, its HW description and must remain same.
>> Unbinding host/gadget driver and rebinding with a different role should not
>> be hard as the U-Boot core infrastructure exists.
>>
>> Moreover if xhci reg and dev reg are separated into different nodes dont we
>> still need access to OTG register block to switch b/w host and device mode?
> I think we may not need to access OTG register if we add two subnodes for gadget and host.
>
> But I see a for loop in dwc3_glue_bind() as follows, if there only one single node representing both Host and Device node under usb wrapper node, why we need this for loop?
>
> 212     for (node = fdt_first_subnode(fdt, dev_of_offset(parent)); node > 0;
> 213          node = fdt_next_subnode(fdt, node)) {

I believe this is a legacy from the code it was inspired from.

Indeed the loop is not required.

Like Vignesh I think we must stick with the dt-bindings used by the kernel.

BTW we are working on the USB3 support right now that is lacking in our 
tree. I choose to keep the PHY drivers as close as possible to their 
linux version. I'll probably start posting preliminary patches this week.

If you have the USB3 working in the kernel, can you point to a tree 
where I can have a look at the drivers and dt-bindings ?

JJ

>
> Best regards
> Sherry sun
>
>> Regards
>> Vignesh
>>
>>> Best regards
>>> Sherry sun
>>>
>>>> Regards
>>>> Vignesh
>>>>
>>>>> Best regards
>>>>> Sherry sun
>>>>>
>>>>>> JJ
>>>>>>
>>>>>>>> Then when binding the wrapper node, it will hard-coded the two
>>>>>> subnodes
>>>>>>>> to different driver(gadge/host driver) according to the dr_mode
>>>>>>>> property
>>>>>> in
>>>>>>>> nodes.
>>>>>>>>
>>>>>>> Do you think I understand it right?
>>>>>>> Best regards
>>>>>>> Sherry sun
>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Sherry sun
>>>>>>>>
>>>>>>>>> JJ
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> +	{ }
>>>>>>>>>>>>>>> +};
>>>>>>>> _______________________________________________
>>>>>>>> U-Boot mailing list
>>>>>>>> U-Boot at lists.denx.de
>>>>>>>> https://l
>>>>>>>>
>> ists.d&data=02%7C01%7Csherry.sun%40nxp.com%7C7d1d76a7124f4c3f
>>>> e9
>> 9d08d72d3ddf82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
>>>> 70276
>> 16080089878&sdata=70BPVQkomokcNpxsHRD3njfZQvuG51VSD1QKBjQ
>>>> o1kA%3
>>>>>>>> D&reserved=0
>>>>>>>> enx.de%2Flistinfo%2Fu-
>>>>>>>>
>> boot&data=02%7C01%7Csherry.sun%40nxp.com%7C35f1d34da1ea4b7
>> 670ba08d72b823e9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
>> C637025710721487079&sdata=Nfk0qWtSViz60wJHAOr2m5tgIwTWjNwI
>>>>>>>> GrNOxDH6HC0%3D&reserved=0
>>>> --
>>>> Regards
>>>> Vignesh