On Fri, Jul 1, 2011 at 21:30, Rajendra Nayak <rnayak@xxxxxx> wrote:
[...]
> +static void __init omap4_check_features(void)
> +{
> + u32 si_type;
> +
> + if (cpu_is_omap443x())
> + omap_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 */
> + omap_features |= OMAP4_HAS_MPU_1_5GHZ;
> + break;
I have seen http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg51988.html
and I disagree with this.
We are setting up a standard for all future silicon that omap_features
if it contains a higher frequency will always support all lower
frequencies in omap_feature. This may be convinent for the moment,
BUT, I disagree with the approach as we cannot guarantee that this
will be the approach for all silica in the future and approach taken
here could be considered short-sighted. if 1.2GHz will be supported
then a check for omap_has_1_2GHz should be true as well - which this
patch will fail to support. E.g. on 4460 has_1GHz should'nt return
true as it is 920MHz, but the check for 1_2GHz should be true - which
it wont as return omap_features & OMAP3_HAS_ ##flag; will not have
BIT(9) set.
Regards,
Nishanth Menon
> + case 1:
> + default:
> + /* Standard device */
> + omap_features |= OMAP4_HAS_MPU_1_2GHZ;
> + break;
> + }
> + }
> +}
[...]
--
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
