Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes:
> Hi Kevin,
>
> On Thu, Jan 5, 2012 at 2:16 AM, Kevin Hilman <khilman@xxxxxx> wrote:
>> 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.
> Since the only remaining check is for omap3517 and from this comment
> it should be better to use a generic check, e.g. cpu_is_omap35xx().
Yes, or probably AM35xx.
>> 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.
>>
>> Signed-off-by: Kevin Hilman <khilman@xxxxxx>
>> ---
>> arch/arm/mach-omap2/clock3xxx_data.c | 14 +-------------
>> 1 files changed, 1 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
>> index e09e506..26fb4d9 100644
>> --- a/arch/arm/mach-omap2/clock3xxx_data.c
>> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
>> @@ -3505,21 +3505,9 @@ int __init omap3xxx_clk_init(void)
>> struct omap_clk *c;
>> u32 cpu_clkflg = 0;
>>
>> - /*
>> - * 3505 must be tested before 3517, since 3517 returns true
>> - * for both AM3517 chips and AM3517 family chips, which
>> - * includes 3505. Unfortunately there's no obvious family
>> - * test for 3517/3505 :-(
>> - */
>> - if (cpu_is_omap3505()) {
>> - cpu_mask = RATE_IN_34XX;
>> - cpu_clkflg = CK_3505;
>> - } else if (cpu_is_omap3517()) {
>> + if (cpu_is_omap3517()) {
> This is rather confusing if it applies to other omap35xx variants.
> cpu_is_omap35xx() is better.
>
> What do you think?
Agreed, and am working on a patch that changes this to cpu_is_am35xx(),
but didn't have time to get it out yet.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
