Re: [PATCH 6/6] omap: move generic omap3 features to generic
On 06/01/2010 08:34 AM, Venkatraman S wrote: If you can post them formally as part of the series, I can test and ack them (with OMAP3, OMAP4) My original comment was even if these were not implemented due to some constraints, they should be mentioned in the code (as TODO / FIXME etc). The caveat description is not going to show up in commit logs or printks okie.. the 3 RFC patches following to the list. Regards, Nishanth Menon -- 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
Re: [PATCH 6/6] omap: move generic omap3 features to generic
Nishanth Menon n...@ti.com wrote:
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.com wrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat; \
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a check
in that sense. if you look at it from features variable, yeah it is updating
it, but the idea of usage of the Macro is: check in status if feature X is
available.. which is what it does ;). btw, the intent of the current patch
was not meant to rename CHECK_FEATURE as it was very OMAP3 specific ;)
It's ok. I don't want to worry too much about the name.
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in common.c,
the check_feature and id.c has not set that bit, the variable will remain 0,
hence omap_has_sgx() will return 0 unless someone enables that for lets say
OMAP4 - feel free to do it, as I mentioned in 0/6, this series was meant
solely to reorganize and provide an infrastructure for further development.
I don't agree. The patch / series is about making them 'generic', where generic
is, to the minimum, making the features exposed for major silicon versions.
If they are not usable beyond OMAP3, it's not generic.
[Apologies for the delayed reply, seem to have a delayed delivery issue]
-Venkat.
--
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
Re: [PATCH 6/6] omap: move generic omap3 features to generic
On 05/31/2010 07:06 PM, Venkatraman S wrote:
Nishanth Menonn...@ti.com wrote:
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.comwrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((statusOMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat;\
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a check
in that sense. if you look at it from features variable, yeah it is updating
it, but the idea of usage of the Macro is: check in status if feature X is
available.. which is what it does ;). btw, the intent of the current patch
was not meant to rename CHECK_FEATURE as it was very OMAP3 specific ;)
It's ok. I don't want to worry too much about the name.
Thanks.
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in common.c,
the check_feature and id.c has not set that bit, the variable will remain 0,
hence omap_has_sgx() will return 0 unless someone enables that for lets say
OMAP4 - feel free to do it, as I mentioned in 0/6, this series was meant
solely to reorganize and provide an infrastructure for further development.
I don't agree. The patch / series is about making them 'generic', where generic
is, to the minimum, making the features exposed for major silicon versions.
If they are not usable beyond OMAP3, it's not generic.
Which part is not generic? I am unable to comprehend your contention
here. Are you contending that ISP, l2cache, neon, isp are *not* generic
OMAP features? or are you contending that since I did not add the
OMAP2,4 logic to detect the same, this patch is not valid?
all silicon revisions CAN use the function omap_has_sgx() now, even
though I have not added detection logic to actually populate the same.
if you do have a patch for detecting actual OMAP4/2 features feel free
to add to the patch list, I am more than happy to ack them, if they look
good - I personally dont have a omap4 platform at the very moment to
write and post a patch - however trivial it may be.
Regards,
Nishanth Menon
--
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
Re: [PATCH 6/6] omap: move generic omap3 features to generic
Nishanth Menon menon.nisha...@gmail.com wrote:
On 05/31/2010 07:06 PM, Venkatraman S wrote:
Nishanth Menonn...@ti.com wrote:
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.com wrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat)
\
if (((status OMAP3_ ##feat## _MASK)
\
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) {
\
- omap3_features |= OMAP3_HAS_ ##feat;
\
+ omap_features |= OMAP_HAS_ ##feat;
\
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a
check
in that sense. if you look at it from features variable, yeah it is
updating
it, but the idea of usage of the Macro is: check in status if feature X
is
available.. which is what it does ;). btw, the intent of the current
patch
was not meant to rename CHECK_FEATURE as it was very OMAP3 specific ;)
It's ok. I don't want to worry too much about the name.
Thanks.
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in
common.c,
the check_feature and id.c has not set that bit, the variable will remain
0,
hence omap_has_sgx() will return 0 unless someone enables that for lets
say
OMAP4 - feel free to do it, as I mentioned in 0/6, this series was
meant
solely to reorganize and provide an infrastructure for further
development.
I don't agree. The patch / series is about making them 'generic', where
generic
is, to the minimum, making the features exposed for major silicon
versions.
If they are not usable beyond OMAP3, it's not generic.
Which part is not generic? I am unable to comprehend your contention here.
Are you contending that ISP, l2cache, neon, isp are *not* generic OMAP
features? or are you contending that since I did not add the OMAP2,4 logic
to detect the same, this patch is not valid?
all silicon revisions CAN use the function omap_has_sgx() now, even though I
have not added detection logic to actually populate the same. if you do have
a patch for detecting actual OMAP4/2 features feel free to add to the patch
list, I am more than happy to ack them, if they look good - I personally
dont have a omap4 platform at the very moment to write and post a patch -
however trivial it may be.
It is this..
or are you contending that since I did not add the OMAP2,4 logic
to detect the same, this patch is not valid?
I understand that you might not have all platforms to test with, but
let's not provide a
'generic feature api' without it being available for the supported platforms.
It's incomplete without it.
Regards,
Venkat.
--
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
Re: [PATCH 6/6] omap: move generic omap3 features to generic
On 05/31/2010 09:46 PM, S, Venkatraman wrote:
I understand that you might not have all platforms to test with, but
let's not provide a
'generic feature api' without it being available for the supported platforms.
It's incomplete without it.
well.. if you did read 0/6
http://marc.info/?l=linux-omapm=127458581708411w=2
Caveat: this series just introduces the framework by reorganizing
the existing data, it does not attempt to define what the features
for OMAP1,2,3,4 would be. As usual, comments are welcome.
:) anyways, these are how the three follow on patches will look like
(sample omap1,2,4 patches are attached), feel free to ack them after
testing - but this patch 6/6 needs to be done prior to the remaining
being added - that is one more reason why i stopped where I did.
Feel free to modify to rectify my patches and post good ones, as you
see, you will need to do 6/6 before doing anything further anyways..
Regards,
Nishanth Menon
From a4f7d23139f8ccfc6b0e910017a759faa0d59578 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 31 May 2010 14:03:28 -0500
Subject: [PATCH 1/3] omap: id: introduce omap4 feature
introduce basic omap4 feature framework
Signed-off-by: Nishanth Menon n...@ti.com
---
CAVEAT: COMPLETELY UNTESTED!!!
arch/arm/mach-omap2/id.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 01555b6..e3f5994 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -267,6 +267,19 @@ static void __init omap3_check_revision(void)
}
}
+static void __init omap4_check_features(void)
+{
+ /*
+ * TODO: add a better check feature once we have
+ * more decent feature check
+ */
+ if (cpu_is_omap4430())
+ omap_features |= OMAP_HAS_L2CACHE |
+ OMAP_HAS_IVA |
+ OMAP_HAS_SGX |
+ OMAP_HAS_NEON;
+}
+
static void __init omap4_check_revision(void)
{
u32 idcode;
@@ -382,6 +395,7 @@ void __init omap2_check_revision(void)
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
+ omap4_check_features();
return;
} else {
pr_err(OMAP revision unknown, please fix!\n);
--
1.6.3.3
From 0e4c9df9870c29da19234a1f4be5227a289b6463 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 31 May 2010 14:10:31 -0500
Subject: [PATCH 2/3] omap: id: introduce omap24xx generic features
introduce generic features for omap2. omap2 uses mbx, not sgx, and
it still has a dsp, though not iva2 as omap3 uses..
Signed-off-by: Nishanth Menon n...@ti.com
---
CAVEAT: COMPLETELY UNTESTED!!!
arch/arm/mach-omap2/id.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f5994..fe634dd 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -102,6 +102,16 @@ static struct omap_id omap_ids[] __initdata = {
static void __iomem *tap_base;
static u16 tap_prod_id;
+static void __init omap24xx_check_features(void)
+{
+ /*
+ * TODO: add a better check feature once we have
+ * more decent feature check
+ */
+ omap_features |= OMAP_HAS_L2CACHE |
+ OMAP_HAS_IVA;
+}
+
static void __init omap24xx_check_revision(void)
{
int i, j;
@@ -388,6 +398,7 @@ void __init omap2_check_revision(void)
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
+ omap24xx_check_features();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
--
1.6.3.3
From c297e29bfd27c373af8d9bdc428f72cad2ef4e7a Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 31 May 2010 14:13:57 -0500
Subject: [PATCH 3/3] omap: id: add feature check for omap1
add a minimalist feature - l2cache for omap1.
Signed-off-by: Nishanth Menon n...@ti.com
---
CAVEAT: COMPLETELY UNTESTED!!!
arch/arm/mach-omap1/id.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c
index 91dbb71..b98a17f 100644
--- a/arch/arm/mach-omap1/id.c
+++ b/arch/arm/mach-omap1/id.c
@@ -200,5 +200,11 @@ void __init omap1_check_revision(void)
printk(KERN_INFO revision %i handled as %02xxx id: %08x%08x\n,
die_rev, omap_revision 0xff, system_serial_low,
system_serial_high);
+
+ /*
+ * TODO: add a better check feature once we have
+ * more decent feature check
+ */
+ omap_features |= OMAP_HAS_L2CACHE;
}
--
1.6.3.3
Re: [PATCH 6/6] omap: move generic omap3 features to generic
On Tue, Jun 1, 2010 at 12:48 AM, Nishanth Menon n...@ti.com wrote: On 05/31/2010 09:46 PM, S, Venkatraman wrote: I understand that you might not have all platforms to test with, but let's not provide a 'generic feature api' without it being available for the supported platforms. It's incomplete without it. well.. if you did read 0/6 http://marc.info/?l=linux-omapm=127458581708411w=2 Caveat: this series just introduces the framework by reorganizing the existing data, it does not attempt to define what the features for OMAP1,2,3,4 would be. As usual, comments are welcome. I did see this. My point was the 6/6 claims to do $foo (where $foo= make it generic) doesn't fit with a caveat description (My patch doesn't do $foo) :) anyways, these are how the three follow on patches will look like (sample omap1,2,4 patches are attached), feel free to ack them after testing - but this patch 6/6 needs to be done prior to the remaining being added - that is one more reason why i stopped where I did. If you can post them formally as part of the series, I can test and ack them (with OMAP3, OMAP4) My original comment was even if these were not implemented due to some constraints, they should be mentioned in the code (as TODO / FIXME etc). The caveat description is not going to show up in commit logs or printks -- 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
Re: [PATCH 6/6] omap: move generic omap3 features to generic
Nishanth Menon n...@ti.com wrote:
sgx, iva, l2cache, sgx, neon, isp are generic features, make
them generic features, current OMAP3 detection mechanism
is still retained. 192Mhz is more specific OMAP3 feature
so it is retained as is
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/id.c | 20
arch/arm/plat-omap/common.c | 3 ++
arch/arm/plat-omap/include/plat/cpu.h | 39 +++-
3 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat; \
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
* AM35xx devices
*/
- if (omap3_has_sgx()) {
+ if (omap_has_sgx()) {
omap_revision = OMAP3517_REV(rev);
strcpy(cpu_name, AM3517);
} else {
/* Already set in omap3_check_revision() */
strcpy(cpu_name, AM3505);
}
- } else if (omap3_has_iva() omap3_has_sgx()) {
+ } else if (omap_has_iva() omap_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, OMAP3430/3530);
- } else if (omap3_has_iva()) {
+ } else if (omap_has_iva()) {
omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, OMAP3525);
- } else if (omap3_has_sgx()) {
+ } else if (omap_has_sgx()) {
omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, OMAP3515);
} else {
@@ -354,11 +354,11 @@ static void __init omap3_cpuinfo(void)
/* Print verbose information */
pr_info(%s ES%s (, cpu_name, cpu_rev);
- OMAP_SHOW_FEATURE(3, l2cache);
- OMAP_SHOW_FEATURE(3, iva);
- OMAP_SHOW_FEATURE(3, sgx);
- OMAP_SHOW_FEATURE(3, neon);
- OMAP_SHOW_FEATURE(3, isp);
+ OMAP_SHOW_FEATURE(, l2cache);
+ OMAP_SHOW_FEATURE(, iva);
+ OMAP_SHOW_FEATURE(, sgx);
+ OMAP_SHOW_FEATURE(, neon);
+ OMAP_SHOW_FEATURE(, isp);
OMAP_SHOW_FEATURE(3, 192mhz_clk);
printk()\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 459a45f..259adc7 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -81,6 +81,9 @@ const void *omap_get_var_config(u16 tag, size_t *len)
}
EXPORT_SYMBOL(omap_get_var_config);
+/* OMAP Generic features */
+u32 omap_features;
+
void __init omap_check_revision()
{
#ifdef CONFIG_ARCH_OMAP1
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index f8ecbc4..3cc4947 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -331,14 +331,14 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap3517
# define cpu_is_omap3430() is_omap3430()
# define cpu_is_omap3503() (cpu_is_omap3430() \
- (!omap3_has_iva()) \
- (!omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (!omap_has_sgx()))
# define cpu_is_omap3515() (cpu_is_omap3430() \
- (!omap3_has_iva()) \
- (omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (omap_has_sgx()))
# define cpu_is_omap3525()
Re: [PATCH 6/6] omap: move generic omap3 features to generic
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.com wrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat;\
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a
check in that sense. if you look at it from features variable, yeah it
is updating it, but the idea of usage of the Macro is: check in status
if feature X is available.. which is what it does ;). btw, the intent of
the current patch was not meant to rename CHECK_FEATURE as it was very
OMAP3 specific ;)
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in
common.c, the check_feature and id.c has not set that bit, the variable
will remain 0, hence omap_has_sgx() will return 0 unless someone enables
that for lets say OMAP4 - feel free to do it, as I mentioned in 0/6,
this series was meant solely to reorganize and provide an infrastructure
for further development.
Regards,
Nishanth Menon
--
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
[PATCH 6/6] omap: move generic omap3 features to generic
sgx, iva, l2cache, sgx, neon, isp are generic features, make
them generic features, current OMAP3 detection mechanism
is still retained. 192Mhz is more specific OMAP3 feature
so it is retained as is
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/id.c | 20
arch/arm/plat-omap/common.c |3 ++
arch/arm/plat-omap/include/plat/cpu.h | 39 +++-
3 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat;\
+ omap_features |= OMAP_HAS_ ##feat; \
}
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
* AM35xx devices
*/
- if (omap3_has_sgx()) {
+ if (omap_has_sgx()) {
omap_revision = OMAP3517_REV(rev);
strcpy(cpu_name, AM3517);
} else {
/* Already set in omap3_check_revision() */
strcpy(cpu_name, AM3505);
}
- } else if (omap3_has_iva() omap3_has_sgx()) {
+ } else if (omap_has_iva() omap_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, OMAP3430/3530);
- } else if (omap3_has_iva()) {
+ } else if (omap_has_iva()) {
omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, OMAP3525);
- } else if (omap3_has_sgx()) {
+ } else if (omap_has_sgx()) {
omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, OMAP3515);
} else {
@@ -354,11 +354,11 @@ static void __init omap3_cpuinfo(void)
/* Print verbose information */
pr_info(%s ES%s (, cpu_name, cpu_rev);
- OMAP_SHOW_FEATURE(3, l2cache);
- OMAP_SHOW_FEATURE(3, iva);
- OMAP_SHOW_FEATURE(3, sgx);
- OMAP_SHOW_FEATURE(3, neon);
- OMAP_SHOW_FEATURE(3, isp);
+ OMAP_SHOW_FEATURE(, l2cache);
+ OMAP_SHOW_FEATURE(, iva);
+ OMAP_SHOW_FEATURE(, sgx);
+ OMAP_SHOW_FEATURE(, neon);
+ OMAP_SHOW_FEATURE(, isp);
OMAP_SHOW_FEATURE(3, 192mhz_clk);
printk()\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 459a45f..259adc7 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -81,6 +81,9 @@ const void *omap_get_var_config(u16 tag, size_t *len)
}
EXPORT_SYMBOL(omap_get_var_config);
+/* OMAP Generic features */
+u32 omap_features;
+
void __init omap_check_revision()
{
#ifdef CONFIG_ARCH_OMAP1
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index f8ecbc4..3cc4947 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -331,14 +331,14 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap3517
# define cpu_is_omap3430() is_omap3430()
# define cpu_is_omap3503() (cpu_is_omap3430()\
- (!omap3_has_iva())\
- (!omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (!omap_has_sgx()))
# define cpu_is_omap3515() (cpu_is_omap3430()\
- (!omap3_has_iva())\
- (omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (omap_has_sgx()))
# define cpu_is_omap3525() (cpu_is_omap3430()\
- (!omap3_has_sgx())\
- (omap3_has_iva()))
+
