[RFC PATCH 0/7] usb: musb: add driver for control module

[kishon]

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