lkml.org 
[lkml]   [2011]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
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@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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-10-11 00:21    [W:0.064 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site