> -----Original Message-----
> From: Hilman, Kevin
> Sent: Saturday, December 10, 2011 6:51 AM
> To: Tony Lindgren
> Cc: Ilya Yanok; [email protected]; [email protected]; [email protected];
> [email protected]; Hiremath, Vaibhav
> Subject: Re: [PATCH] AM35xx: disable checking for reserved feature bits
>
> Tony Lindgren <[email protected]> writes:
>
> [...]
>
> >> This "feature" selection mechanism is clearly not scaling to newer SoCs.
> >> While this patch works around the problem, IMO, we need a more scalable
> >> solution.
> >
> > Agreed.
> >
<snip>
> >
> > This should be coordinated with the splitting of feature detection
> > as posted by Vaibhave in thread "[RFC PATCH] arm:omap: cleanup & split
> > omap2/3/4_check_revision function" thread.
>
> Vaibhav,
>
> Feel free to take my proposed patch and develop it further and include
> it in your rework of the SoC/feature detection.
>
Kevin,
I spend some time on this, and I think it is not possible to use HWMOD
Entries for feature check. Reason being,
- The whole revision story is built upon howkeye and silicon rev.
And both remains same for different devices in same family,
For example,
omap3430, omap3503 and omap3515 (for that matter all AM37x) all
will have same howkeye and silicon revision no.
Also, in the kernel we have something like.
# define cpu_is_omap3515() (cpu_is_omap3430() && \
(!omap3_has_iva()) && \
(omap3_has_sgx()))
# define cpu_is_omap3525() (cpu_is_omap3430() && \
(!omap3_has_sgx()) && \
(omap3_has_iva()))
Which means, you can not do IP detection before check_feature
function.
- The current omap_hwmod_xxxx_data.c uses silicon version alone
and only differentiate between silicon versions. We do not
differentiate between different family of devices while registering
hwmod data.
So the conclusion is, we have to stick to check_feature function.
Thanks,
Vaibhav
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html