Re: [RFC/PATCH 3/7] ARM: OMAP3: clock data: treat all AM35x devices the same

[Kevin Hilman <khilman@ti.com>]

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

>> -----Original Message-----
>> From: Hilman, Kevin
>> Sent: Thursday, January 05, 2012 6:47 AM
>> To: linux-omap@vger.kernel.org
>> Cc: Paul Walmsley; Hiremath, Vaibhav
>> Subject: [RFC/PATCH 3/7] ARM: OMAP3: clock data: treat all AM35x devices
>> the same
>> 
>> The init for 3505/3517 specific clocks depends on the ordering of
>> cpu_is checks, is error prone and confusing (there are 2 separate
>> checks for cpu_is_omap3505()).
>> 
>> Remove the 3505-specific checking since CK_3505 flag is not used, and
>> treat all AM35x clocks the same.
>> 
>> This means that the SGX clock (the only AM35x clkdev not currently
>> flagged for 3505) will now be registered on 3505, but that is
>> harmless.  That can be cleaned up when the clkdev nodes are removed in
>> favor of them being registered by hwmod.
>> 
> [Hiremath, Vaibhav] How do you think we can use hwmod here?

I haven't thought in detail about the exact fix for this, but it
shouldn't be difficult. For example, it could be as simple as creating
some more per-family hwmod lists of optional hwmods.  Then, during init,
register them based on the feature flag.

Longer term, it may be that we handle this using DT, but I'm not sure we
will use DT to describe that level of SoC detail.

> Currently hwmod is also dependent on cpu_is_xxxx to register respective modules.

In mainline it is only done by CPU family (revision), not using cpu_is*

> I completely understand and agree to the fact that there may not be any harm
> due to this, but this means, iva will be always registered for 3505 devices.

Correct for today, but not difficult to remedy by fixing up the hwmod init.

Kevin