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().
>
> 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?
Regards,
Jean
--
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
