On 10/2/23 15:42, Miquel Raynal wrote:
Hi Marek,
marex@denx.de wrote on Sat, 30 Sep 2023 23:11:17 +0200:
On 9/27/23 15:59, Miquel Raynal wrote:
Hi Marek,
Hi,
miquel.raynal@bootlin.com wrote on Fri, 22 Sep 2023 12:00:12 +0200:
Hi Marek,
I'm answering here as there is no cover letter. Just to let you know I'm still concerned by the series and want to test it but did not had the time to do so recently. Hopefully next week.
The series looks good to me and works as well on a Beagle Bone Black with no visible functional changes regarding the use of the UDC. The whole series is:
Tested-by: Miquel Raynal miquel.raynal@bootlin.com
By the way, following your initial series there have been three followup patches trying to improve a little bit the doc, one got merged and two others were delegated to you: https://patchwork.ozlabs.org/project/uboot/list/?series=367635
They are almost 2 months old now, would you mind acking or merging them so both your initial USB gadget rework and the additional (related) doc can be in the same release please?
Can you resend those and CC this mail address ?
Of course!
That said, 1/2 should be in some sort of README instead, and the 'dm tree' command depends on CMD_DM=y .
Well, the README is more something which targets the developer IMO, whereas here I want to target the users. Many people only see U-Boot through Yocto now (that's a different topic) and the purpose of this additional text is to help them in finding their way into U-Boot device model *alone*. It's really short, but I bet it can really help, given how I felt when I actually understood why you advised to type a couple of semi-random bind/unbind commands which eventually worked. Anybody not involved in any DM conversion is likely just not aware of all of that. Having people finding their own way through the DM means less complaints/needs for help on the mailing list.
Thinking about it back and forth, I think you've got a point, yes.
The usb_gadget_probe_driver() is code synchronized from kernel, you likely want to add any such clarification to usb_gadget_register_driver() .
Actually the kernel functions do have some kind of alternate error message as well now :-) Clearly different given that this code has been adapted to U-Boot's DM, but the idea is close. However usb_gadget_register_driver() is kind of blind regarding the number of UDCs in the system and if they are already bound or not, so I don't really see the point in moving the error message there along with all the logic duplication involved.
That said, the usb_gadget_register_driver() should be reworked into some new functions, which takes UDC controller *udevice pointer to avoid this binding heuristics.
Yes, I don't know many boards with two UDCs but it's a clear limitation.
i.MX8M Plus is one such example, Quad I think is another, and pretty much anything with more than one DWC3 controller is. The CI HDRC is also often present in OTG capable configuration, so a lot of i.MXes are multi UDC systems.