[PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Cousson, Benoit]

On 10/10/2011 10:42 PM, Paul Walmsley wrote:
> Hi Benoît
>
> On Mon, 10 Oct 2011, Cousson, Benoit wrote:
>
>> On 10/10/2011 9:24 PM, Paul Walmsley wrote:
>>> On Fri, 23 Sep 2011, Tero Kristo wrote:
>>>
>>>> This patch is temporary until Paul can provide a final version.
>>>>
>>>> Signed-off-by: Tero Kristo<t-kristo at ti.com>
>>>
>>> Here's an updated version of this one.  The one change is that the hwmod's
>>> name is now "prm3xxx" to reflect that the register layout of this IP block
>>> is quite different from its OMAP2 predecessors and OMAP4 successors.
>>> This should avoid some of the special-purpose driver probing code.
>>
>> This is not really aligned with the naming convention we've been using so far.
>> In both cases, the hwmod should just be named "prm". If a version information
>> is needed, then it should be added in the revision class field.
>>
>> It will make the device creation even simpler and not dependent of the SoC
>> version.
>
> The problem in this case is that we should be using a completely different
> device driver for the PRM that's in the OMAP3 chips, from the driver used
> for OMAP2 or OMAP4 PRM blocks, due to the completely different register
> layout.  As far as I know, we haven't yet used the hwmod IP version to
> probe a different device driver when the version number changes.  There's
> no support for that in the current Linux platform* code, so we'd need
> special-purpose code for that.
>
> In an ideal world, we'd have an omap_bus, etc., which would include an
> additional interface version number as part of its driver matching
> criteria.  Device drivers would then specify which interface version
> numbers they supported.  The device data would specify that interface
> version number should be matched.
>
> But as it is right now in the current platform_device/platform_driver
> based system, we have only the name to match.  We could implement
> something where we concatenate the existing IP version number onto the
> hwmod name, and modify the device drivers to use that name.  But that
> seems like a lot of potential churn in light of a future DT and/or
> omap_bus migration.
>
> So I'm proposing to use the IP version number field that's in the hwmod
> data to indicate evolutionary revisions of an IP block -- rather than
> revolutionary revisions that would require a new driver.  Then, since we
> use the hwmod name for driver matching, we'd use a different name for
> radically different IPs.
>
> If it's the "3xxx" that you're objecting to in the name, we could call it
> "prm2" or "prmxyz" - the '3xxx' just seemed like the most logical
> approach.  The name of the hwmod class in the patch is still "prm", of
> course.

Yes, but that's different, the number is supposed to represent the 
instance number in the IP naming convention. So prm2 != prmv2.

> Thoughts?

In fact the device name does not have to match the hwmod name. So we can 
just create an "omap2_prm" omap_device for OMAP2, "omap3_prm" 
omap_device for OMAP3...
That will allow the relevant PRM  driver to be bound to the proper device.

> N.B., it's true that by waiting, this problem will presumably go away,
> with DT, in which the driver matching data would go into the
> "compatible" string in the DT.

Yes, this will become indeed straightforward with DT.

We will just have something like:
prm {
	compatible = "prm-omap2";
	ti,hwmods = "prm";
}

> But I guess it would be good to figure out a clean approach in the
> meantime.

I guess the different device names should make that work in the meantime.

Regards,
Benoit