Re: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi, On Tue, Jan 15, 2013 at 02:12:51PM +0530, Kishon Vijay Abraham I wrote: 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. can you resend without RFC tag so I can apply ? Thank you -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: 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. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: 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. 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? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: 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. 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? 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 signature.asc Description: Digital signature
RE: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: 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. 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? 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. In this case whether the single instance of control module driver is good enough to cater of all cpu types of same SoC series ? Whether cpu_is_xxx() can be used to differentiate b/w different cpu types in CM driver? 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 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
Hi Ravi, On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote: Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: 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. 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? 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. 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 ;-) Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
On Wed, Jan 16, 2013 at 11:31:32AM +0530, kishon wrote: Hi Ravi, On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote: Hi, On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote: Hi Arnd, On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: 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. 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? 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. 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 ;-) right, it was to look at removing mach/* inclusion from all davinci-link glue layers (they should be combined, btw). -- balbi signature.asc Description: Digital signature
