[PATCH 3/5] usb: dwc3-generic: Add dependency on SIMPLE_BUS

Marek Vasut marex at denx.de
Wed Jan 25 02:38:17 CET 2023


On 1/24/23 03:53, Kunihiko Hayashi wrote:
> Hi Marek,

Hello Hayashi-san,

> On 2023/01/24 0:49, Marek Vasut wrote:
>> On 1/23/23 06:01, Kunihiko Hayashi wrote:
>>> Hi Marek,
>>
>> Hello Hayashi-san,
>>
>> [...]
>>
>>>> On the other hand, the PXS2 controller for example is not a bus:
>>>>
>>>> arch/arm/dts/uniphier-pxs2.dtsi:
>>>> 596 _usb0: usb at 65a00000 {
>>>> 597     compatible = "socionext,uniphier-dwc3", "snps,dwc3";
>>>> 598     status = "disabled";
>>>> 599     reg = <0x65a00000 0xcd00>;
>>>> ...
>>>> 610 };
>>>
>>> I understand. However, this node isn't used in u-boot.
>>> (see below for details)
>>>
>>>>>> Is this needed for socionext dwc3 variant to handle the simple-mfd in
>>>>>> e.g. arch/arm/dts/uniphier-pxs3.dtsi :
>>>>>>
>>>>>> 614 usb-glue at 65b00000 {
>>>>>> 615     compatible = "socionext,uniphier-pxs3-dwc3-glue",
>>>>>> 616              "simple-mfd";
>>>>>>
>>>>>> ?
>>>>>
>>>>> In case of U-Boot, the glue driver is probed by:
>>>>>
>>>>>        /* FIXME: U-Boot own node */
>>>>>        usb at 65b00000 {
>>>>>                compatible = "socionext,uniphier-pxs3-dwc3";
>>>>>
>>>>> And dwc3-uniphier is also declared as UCLASS_SIMPLE_BUS.
>>>>> Even if using "simple-mfd", this is included in
>>>>> drivers/core/simple-bus.c
>>>>> which is declared as UCLASS_SIMPLE_BUS.
>>>>
>>>> If I understand this correctly, node compatible with
>>>> "socionext,uniphier-pxs3-dwc3-glue" is not used at all , right ?
>>>
>>> Yes.
>>> Original uniphier devicetree has the following usb nodes.
>>>
>>>       usb at 65a00000 {
>>>           compatible = "snps,dwc3";
>>>       };
>>>       usb-glue at 65b00000 {
>>>           compatible = "socionext,uniphier-pxs3-dwc3-glue", 
>>> "simple-mfd";
>>>       };
>>>
>>> However, U-Boot dwc3-generic needs to put dwc3 node under the glue node.
>>
>> Have a look at arch/arm/dts/imx8mq.dtsi which does not use any glue
>> node, the snps,dwc3 compatible node is directly placed on the soc at 0 bus:
>>
>> 1417
>> 1418         usb_dwc3_0: usb at 38100000 {
>> 1419             compatible = "fsl,imx8mq-dwc3", "snps,dwc3";
>> 1420             reg = <0x38100000 0x10000>;
>> 1421             clocks = <&clk IMX8MQ_CLK_USB1_CTRL_ROOT>,
>>
>>> Due to this restriction, there is another usb node dedicated to u-boot.
>>>
>>>       /* FIXME: U-Boot own node */
>>>       usb at 65b00000 { /* glue */
>>>           compatible = "socionext,uniphier-pxs3-dwc3";
>>>
>>>           dwc3 at 65a00000 {
>>>               compatible = "snps,dwc3";
>>>           };
>>>       };
>>>
>>> So instead of "socionext,uniphier-pxs3-dwc3-glue", the glue driver
>>> uses "socionext,uniphier-pxs3-dwc3" in U-Boot.
>>
>> Can we use the same method as imx8mq.dtsi uses, to avoid this special
>> node workaround ?
> 
> Umm, it's curious. It seems imx8mq doesn't have any glue registers and 
> defines
> dwc3 core registers directly.
> 
> On the other hand, "fsl,imx8mq-dwc3" is included in dwc3-generic.c, though,
> dwc3_glue_bind() calls the driver that the child node shows.
> 
>      ofnode_for_each_subnode(node, dev_ofnode(parent)) {
>          ...
>          device_bind_driver_to_node(parent, driver, name,
>                                     node, &dev);
>          ...
>      }
> 
> Maybe the child node expects the driver that "snps,dwc3" indicates.
> 
> If we use the same method as imx8mq.dtsi, I think there is no way to probe
> the driver for "snps,dwc3" in dwc3-generic.c.
> 
> BTW, xchi-dwc3.c can handle "snps,dwc3", but it seems this doesn't use
> usb/dwc3/ functions (so I'm confusing it).

Let's try the following, please have a look at this change:

https://source.denx.de/u-boot/custodians/u-boot-usb/-/commit/028ad9536e501986f4e19d27f462f81a9ea70bad

The change is difficult to read, use 'git show -w' to ignore space 
changes, that might help.

The idea is that the dwc3-generic.c (or dwc3-uniphier.c , placement does 
not really matter) binds to "socionext,uniphier-pxs3-dwc3-glue" 
compatible first.

Then, the dwc3_glue_ops is extended with a new callback 
glue_get_ctrl_dev, which returns the pointer to controller DT node (the 
node compatible with "socionext,uniphier-dwc3"). This is used in 
dwc3_glue_bind(), which either uses the current implementation with a 
loop over all subnodes and tries to find the controller subnode, OR, 
calls the glue_get_ctrl_dev callback, obtains controller device node 
pointer that way, and runs the inner loop of dwc3_glue_bind() (now 
dwc3_glue_bind_common()) only on that pointer.

In either case, the dwc3-generic driver is bound to the controller. You 
might need to re-use this trick in dwc3_glue_probe() too.

This should allow you to get rid of the custom DT node too.

Does this work ?


More information about the U-Boot mailing list