Premi, Sanjeev had written, on 07/22/2010 04:49 AM, the following:
-----Original Message-----
From: Menon, Nishanth
Sent: Thursday, July 22, 2010 3:08 PM
To: Gadiyar, Anand
Cc: Premi, Sanjeev; linux-omap@xxxxxxxxxxxxxxx
Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision
On 07/22/2010 01:53 AM, Gadiyar, Anand wrote:
@@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
+/*
+ * Map revision bits to silicon specific revisions
+ */
+#define ES_1_0 OMAP_REVBITS_00
probably need ES_1_1, 1_2 (considering 3630)
This should be okay, since the 3630 is out with
these revisions, but...
+#define ES_2_0 OMAP_REVBITS_10
+#define ES_2_1 OMAP_REVBITS_20
makes sense to go to 2_2
+#define ES_3_0 OMAP_REVBITS_30
+#define ES_3_1 OMAP_REVBITS_40
+#define ES_3_1_2 OMAP_REVBITS_50
3_2?
This may not make sense to add now as there are no
2.2 or 3.2 revisions of any OMAP3/4 silicon?
Agreed for 3 and 4, but considering this is
arch/arm/plat-omap/include/plat/cpu.h, does it make sense in
looking all
OMAPs?
In this case, the best option would be to prefix OMAP34X_/ OMAP36X_
OMAP44X_ etc and define the ES revisions for each context.
doing that is gonna make the code real dirty looking. at the very least
mebbe bracket it in with #ifdef with CONFIG_OMAP2PLUS?
--
Regards,
Nishanth Menon
--
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
