On Fri, Jul 01, 2011 at 07:37:56AM +0530, Rajendra Nayak wrote:
> From: Aneesh V <ane...@ti.com>
>
> Macros for identifying the max frequency supported by various
> OMAP4 variants - Expanding along the lines of OMAP3's feature
> handling.
>
> [n...@ti.com: minor fixes for checks that should only for 443x|446x]
> Signed-off-by: Nishanth Menon <n...@ti.com>
> Signed-off-by: Aneesh V <ane...@ti.com>
> ---
> arch/arm/mach-omap2/id.c | 29 +++++++++++++++++++++++++++++
> arch/arm/plat-omap/include/plat/cpu.h | 19 +++++++++++++++++++
> 2 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 3d43d64..a86d0f9 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -32,6 +32,7 @@ static struct omap_chip_id omap_chip;
> static unsigned int omap_revision;
>
> u32 omap3_features;
> +u32 omap4_features;
Since the features are enabled by cpu_is*, need to have separate masks
for OMAP3 vs. OMAP4 in same kernel?
>
> unsigned int omap_rev(void)
> {
> @@ -212,6 +213,33 @@ static void __init omap3_check_features(void)
> */
> }
>
> +static void __init omap4_check_features(void)
> +{
> + u32 si_type;
> +
> + omap4_features = 0;
Already guaranteed to be zero, could skip this.
> +
> + if (cpu_is_omap443x())
> + omap4_features |= OMAP4_HAS_MPU_1GHZ;
> +
> +
> + if (cpu_is_omap446x()) {
> + si_type =
> + read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
> + switch ((si_type & (3 << 16)) >> 16) {
> + case 2:
> + /* High performance device */
> + omap4_features |= OMAP4_HAS_MPU_1_5GHZ;
> + break;
Should this fall through to also add OMAP4_HAS_MPU_1_2GHZ? (Or are
they mutually exclusive, or 1.5 implies 1.2 also present by
convention)?
Todd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
