usb: musb: add driver for control module

Documentation/devicetree/bindings/usb/omap-usb.txt Board specific device node entry · line 44

Quoted 10 lines · Kishon Vijay Abraham I

Documentation/devicetree/bindings/usb/omap-usb.txt +10 -0

+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be "ti,omap-control-usb"
+ - reg : Address and length of the register set for the device. It contains
+   the address of "control_dev_conf" and "otghs_control".
+ - reg-names: The names of the register addresses corresponding to the registers
+   filled in "reg".
+ - ti,has_mailbox: This is used to specify if the platform uses mailbox in
+   control module.

I wonder whether we need to have a phandle here to connect the control device to the actual usb device. What happens if you have multiple instances of each?

Good point :-). Currently, none of the OMAP platforms have multiple control modules and it doesn't seem to be in the future (AFAIK). While it might be simpler to support multiple control devices with phandle, it might face the same complications as faced by the USB PHY framework for non-dt boot.

A seperate driver has been added to handle the usb part of control module. A device for the above driver is created here, using the register address information to be used by the driver for powering on the PHY and for writing to the mailbox.

Signed-off-by Kishon Vijay Abraham I <[email protected]>

---
  arch/arm/mach-omap2/devices.c |   50 +++++++++++++++++++++++++++++++++++++++++
  1 file changed, 50 insertions(+)

arch/arm/mach-omap2/devices.c +0 -0

index 5e304d0..a761faf4 100644

Hello.

Quoted 16 lines · Kishon Vijay Abraham I

A seperate driver has been added to handle the usb part of control module. A device for the above driver is created here, using the register address information to be used by the driver for powering on the PHY and for writing to the mailbox.

Signed-off-by Kishon Vijay Abraham I <[email protected]>

---
  arch/arm/mach-omap2/devices.c |   50
+++++++++++++++++++++++++++++++++++++++++
  1 file changed, 50 insertions(+)

arch/arm/mach-omap2/devices.c +0 -0

index 5e304d0..a761faf4 100644

[...]

arch/arm/mach-omap2/devices.c static inline void omap_init_camera(void) · line 259

Quoted 6 lines

arch/arm/mach-omap2/devices.c +2 -0

@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
  #endif
  }
 
+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+                defined(CONFIG_OMAP_CONTROL_USB_MODULE))

    () around || not needed, and you're indenting the second line too much.

arch/arm/mach-omap2/devices.c static inline void omap_init_camera(void) · line 292

Quoted 3 lines

arch/arm/mach-omap2/devices.c +3 -0

+static inline void __init omap_init_control_usb(void)
+{
+    int ret = 0;

Initializer not needed.

arch/arm/mach-omap2/devices.c static inline void omap_init_camera(void) · line 298

Quoted 6 lines

arch/arm/mach-omap2/devices.c +6 -0

+
+    if (cpu_is_omap44xx()) {
+        ret = platform_device_register(&omap4_control_usb);
+        if (ret)
+            pr_err("Error registering omap_control_usb device: %d\n"
+                , ret);

Please leave the comma on the previous line.

Quoted 40 lines · Kishon Vijay Abraham I

Quoted 17 lines

A seperate driver has been added to handle the usb part of control module. A device for the above driver is created here, using the register address information to be used by the driver for powering on the PHY and for writing to the mailbox.

Signed-off-by Kishon Vijay Abraham I <[email protected]>

---
  arch/arm/mach-omap2/devices.c |   50
+++++++++++++++++++++++++++++++++++++++++
  1 file changed, 50 insertions(+)

arch/arm/mach-omap2/devices.c +0 -0

index 5e304d0..a761faf4 100644

[...]

arch/arm/mach-omap2/devices.c static inline void omap_init_camera(void) · line 259

Quoted 6 lines

arch/arm/mach-omap2/devices.c +2 -0

@@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
  #endif
  }
 
+#if (defined(CONFIG_OMAP_CONTROL_USB) || \
+                defined(CONFIG_OMAP_CONTROL_USB_MODULE))

    () around || not needed, and you're indenting the second line too much.

arch/arm/mach-omap2/devices.c static inline void omap_init_camera(void) · line 292

Quoted 3 lines

arch/arm/mach-omap2/devices.c +3 -0

+static inline void __init omap_init_control_usb(void)
+{
+    int ret = 0;

Initializer not needed.

Quoted 6 lines

arch/arm/mach-omap2/devices.c +6 -0

+
+    if (cpu_is_omap44xx()) {
+        ret = platform_device_register(&omap4_control_usb);
+        if (ret)
+            pr_err("Error registering omap_control_usb device: %d\n"
+                , ret);

Quoted 1 line

Please leave the comma on the previous line.

Sure. I'll fix it.

Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode.

Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it.

Quoted 11 lines · Kishon Vijay Abraham I

Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode.

Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it.

The series looks good to me, I just had a minor comment on one patch.

One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.

Hi Arnd,

Quoted 13 lines · Arnd Bergmann

Quoted 11 lines · Kishon Vijay Abraham I

Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode.

Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it.

Quoted 6 lines

The series looks good to me, I just had a minor comment on one patch.

One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.

We don't have plans as of now. I actually don't expect any changes in the driver other than the Kconfig changes. Anyways the probe of glue's other than the platform it's running won't get called. right Felipe?

Hi,

Quoted 5 lines · kishon

Hi Arnd,

Quoted 2 lines · Arnd Bergmann

Quoted 1 line · Kishon Vijay Abraham I

Added a new driver for the usb part of control module.

This has an

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in

device mode.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Writing to control module registers for doing the above

task which

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH

folders, so If it

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

has to be split I'll do it.

The series looks good to me, I just had a minor comment on

one patch.

Quoted 2 lines

Quoted 2 lines

One a somewhat related topic, I wonder whether there are

any plans on

Quoted 1 line

Quoted 1 line

your side to change this driver to support multiple bus

glues to be

Quoted 1 line

Quoted 1 line

built for one kernel image. With a multiplatform kernel,

we may need

Quoted 3 lines

Quoted 1 line

all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.

We don't have plans as of now. I actually don't expect any

changes in

Quoted 1 line

the driver other than the Kconfig changes. Anyways the

probe of glue's

Quoted 1 line

other than the platform it's running won't get called. right Felipe?

AFAICT there's nothing preventing those from being built together as long as you don't use DMA (yeah, that's a touchy subject still with MUSB).

If there are any build breaks, please report them so bus glue owners can fix. I see that at least the davinci folks need to work a bit

$ git grep -e "mach\/" drivers/usb/musb/ 
drivers/usb/musb/da8xx.c:#include <mach/da8xx.h> 
drivers/usb/musb/davinci.c:#include <mach/cputype.h> 
drivers/usb/musb/davinci.c:#include <mach/hardware.h>

I'm adding Ravi B to the loop here for those.

--
balbi

Quoted 34 lines

Hi,

Quoted 5 lines · kishon

Hi Arnd,

Quoted 2 lines · Arnd Bergmann

Quoted 1 line · Kishon Vijay Abraham I

Added a new driver for the usb part of control module.

This has an

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in

device mode.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Writing to control module registers for doing the above

task which

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH

folders, so If it

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

has to be split I'll do it.

The series looks good to me, I just had a minor comment on

one patch.

Quoted 2 lines

Quoted 2 lines

One a somewhat related topic, I wonder whether there are

any plans on

Quoted 1 line

Quoted 1 line

your side to change this driver to support multiple bus

glues to be

Quoted 1 line

Quoted 1 line

built for one kernel image. With a multiplatform kernel,

we may need

Quoted 2 lines

Quoted 1 line

all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.

Quoted 5 lines

Quoted 1 line

We don't have plans as of now. I actually don't expect any

changes in

Quoted 1 line

the driver other than the Kconfig changes. Anyways the

probe of glue's

Quoted 1 line

other than the platform it's running won't get called. right Felipe?

If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs.

Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver?

Hi Ravi,

Quoted 34 lines · Ravi

Quoted 34 lines

Hi,

Quoted 5 lines · kishon

Hi Arnd,

Quoted 2 lines · Arnd Bergmann

Quoted 1 line · Kishon Vijay Abraham I

Added a new driver for the usb part of control module.

This has an

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in

device mode.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Writing to control module registers for doing the above

task which

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH

folders, so If it

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

has to be split I'll do it.

The series looks good to me, I just had a minor comment on

one patch.

Quoted 2 lines

Quoted 2 lines

One a somewhat related topic, I wonder whether there are

any plans on

Quoted 1 line

Quoted 1 line

your side to change this driver to support multiple bus

glues to be

Quoted 1 line

Quoted 1 line

built for one kernel image. With a multiplatform kernel,

we may need

Quoted 2 lines

Quoted 1 line

all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance.

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

We don't have plans as of now. I actually don't expect any

changes in

Quoted 1 line

the driver other than the Kconfig changes. Anyways the

probe of glue's

Quoted 1 line

other than the platform it's running won't get called. right Felipe?

If understand correctly the control module driver used to configure the respective usb phy of SoC to respective usb modes using the common set of control module APIs.

What if, if control module interface (register defintions) varies b/w different revision or spin of same type of SoCs, if usbphy type is changed.
Well in that case, we can write to the registers based on the IP revision check (I think thats the common practice to do).

In this case whether the single instance of control module driver is good enough to cater of all cpu types of same SoC series ? Of course. I don't see why we can't have the same driver to handle different versions of the same IP.
The only reason where we might need multiple instance is if the SoC have multiple control module which Arnd already pointed out.

Quoted 1 line

Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver?

Not needed at all IMHO. We can use revision register to differentiate.

Btw I think Felipe looped you for a different reason ;-)

Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode.

Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed.

Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it.

This series was developed on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv

Did basic enumeration testing in omap4 beagle, omap4 sdp and omap3 beagle.