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
Attachment:
signature.asc
Description: Digital signature
