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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
