Hi Sjeord,
On 25 March 2018 at 15:28, Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
On Sat, 2016-12-03 at 11:40 -0700, Simon Glass wrote:
Hi Mugunthan,
On 17 November 2016 at 02:08, Mugunthan V N mugunthanvnm@ti.com wrote:
Add a TI MUSB peripheral driver with driver model support and the driver will be bound by the MUSB wrapper driver based on the dr_mode device tree entry.
Seems like this never landed. Seems to works fine with some trivial fixups though.
Signed-off-by: Mugunthan V N mugunthanvnm@ti.com Reviewed-by: Simon Glass sjg@chromium.org
drivers/usb/musb-new/musb_uboot.c | 2 + drivers/usb/musb-new/ti-musb.c | 109 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 111 insertions(+)
diff --git a/drivers/usb/musb-new/musb_uboot.c b/drivers/usb/musb- new/musb_uboot.c index ea71f75947..46e3faeeaa 100644 --- a/drivers/usb/musb-new/musb_uboot.c +++ b/drivers/usb/musb-new/musb_uboot.c @@ -373,6 +373,7 @@ struct dm_usb_ops musb_usb_ops = { #endif /* CONFIG_DM_USB */ #endif /* CONFIG_USB_MUSB_HOST */
+#ifndef CONFIG_DM_USB #ifdef CONFIG_USB_MUSB_GADGET static struct musb *gadget;
@@ -453,3 +454,4 @@ int musb_register(struct musb_hdrc_platform_data *plat, void *bdata,
return 0;} +#endif /* CONFIG_DM_USB */ diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb- new/ti-musb.c index 1c15aa2a42..b8abc1dc58 100644 --- a/drivers/usb/musb-new/ti-musb.c +++ b/drivers/usb/musb-new/ti-musb.c @@ -14,6 +14,7 @@ #include <dm/device-internal.h> #include <dm/lists.h>
+#include <watchdog.h> #include <asm/io.h> #include <asm/omap_musb.h> #include "musb_uboot.h" @@ -142,6 +143,106 @@ static int ti_musb_ofdata_to_platdata(struct udevice *dev) return 0; }
+static struct musb *gadget;
Can you please drop this static struct? We should not use this sort of thing with driver model.
Let me know if you want ideas on how.
From what i can tell; dropping that needs quite a bit refactoring of the gadget framework such that it passes through a udevice with e.g. usb_gadget_register_driver and usb_gadget_handle_interrupts.
Was that what you were pondering, or other suggestions ;)
Well if it is just this static var, then it should be possible to move it to use device-private data, or perhaps uclass-private data if there is a uclass for the gadget (but presumably in principle we need to support multiple gadgets?).
Regards, Simon