Re: [PATCH] Added support for OMAP35x processor series

Re: [PATCH] Added support for OMAP35x processor series

[Kridner, Jason]

No, ROM CRC is useful for detecting between some device revisions, but not OMAp3430 vs OMAP3530.

----- Original Message -----
From: Koen Kooi <k.kooi@student.utwente.nl>
To: linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>
Cc: Kridner, Jason
Sent: Tue Aug 05 05:10:40 2008
Subject: Re: [PATCH] Added support for OMAP35x processor series


Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:

> On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
>> This patch is needed to ensure that we can make decisions based on
>> the processor capabilities.
>> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
>> disable/ manage the clocks for
>> DSP on this processor. Same for SGX.
>
> Why can't the detection happen at runtime?

AIUI the ID bits are the same (linux misdetect the 3530 on my beagle
for a 3430). I heard that the only definitive way to do it at runtime
is to CRC check the ROM code.

Jason, is that correct?

regards,

Koen

>> Enabling NEON is support iby default is just based on the number of
>> requests I have been getting
>> from various users.
>
> Huh?
>
>
> --
>
> Cheers, Igor
>
> ---
>
> Igor Stoppa
> Maemo Software - Nokia Devices R&D - Helsinki
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] Added support for OMAP35x processor series

[Tony Lindgren]

* Kridner, Jason <jdk@ti.com> [080805 17:12]:
> No, ROM CRC is useful for detecting between some device revisions, but not OMAp3430 vs OMAP3530.
>
> ----- Original Message -----
> From: Koen Kooi <k.kooi@student.utwente.nl>
> To: linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>
> Cc: Kridner, Jason
> Sent: Tue Aug 05 05:10:40 2008
> Subject: Re: [PATCH] Added support for OMAP35x processor series
> 
> 
> Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:
> 
> > On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
> >> This patch is needed to ensure that we can make decisions based on
> >> the processor capabilities.
> >> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
> >> disable/ manage the clocks for
> >> DSP on this processor. Same for SGX.
> >
> > Why can't the detection happen at runtime?
> 
> AIUI the ID bits are the same (linux misdetect the 3530 on my beagle
> for a 3430). I heard that the only definitive way to do it at runtime
> is to CRC check the ROM code.
> 
> Jason, is that correct?

Well if there's no way to detect certain omaps during runtime, please
patch arch/arm/plat-omap/common.c to have something like struct
omap_globals omap3503_globals.

BTW, why can't the dsp code detect if the DSP is there or not?

Tony



> 
> regards,
> 
> Koen
> 
> >> Enabling NEON is support iby default is just based on the number of
> >> requests I have been getting
> >> from various users.
> >
> > Huh?
> >
> >
> > --
> >
> > Cheers, Igor
> >
> > ---
> >
> > Igor Stoppa
> > Maemo Software - Nokia Devices R&D - Helsinki
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> N?????r??y????b?X??ǧv?^?)޺{.n?+????{??f??{ay?\x1dʇڙ?,j\a??f???h???z?\x1e?w???\f???j:+v???w?j?m????\a????zZ+?????ݢj"??!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Added support for OMAP35x processor series

[Premi, Sanjeev]

>> Well if there's no way to detect certain omaps during runtime, please patch
>> arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.

There was no need to re-define these structures for the current series of the OMAP35x processors.
Hence, it was left as it.

>> BTW, why can't the dsp code detect if the DSP is there or not?

(Assuming you mean the code running on ARM that looks for the DSP/SGX/...)
The detection was based on the chip ID. This happens to be same for OMAP34XX and OMAP35X.

~sanjeev


-----Original Message-----
From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Wednesday, August 06, 2008 2:37 PM
To: Kridner, Jason
Cc: 'k.kooi@student.utwente.nl'; 'linux-omap@vger.kernel.org'
Subject: Re: [PATCH] Added support for OMAP35x processor series

* Kridner, Jason <jdk@ti.com> [080805 17:12]:
> No, ROM CRC is useful for detecting between some device revisions, but not OMAp3430 vs OMAP3530.
>
> ----- Original Message -----
> From: Koen Kooi <k.kooi@student.utwente.nl>
> To: linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>
> Cc: Kridner, Jason
> Sent: Tue Aug 05 05:10:40 2008
> Subject: Re: [PATCH] Added support for OMAP35x processor series
>
>
> Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:
>
> > On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
> >> This patch is needed to ensure that we can make decisions based on
> >> the processor capabilities.
> >> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
> >> disable/ manage the clocks for DSP on this processor. Same for SGX.
> >
> > Why can't the detection happen at runtime?
>
> AIUI the ID bits are the same (linux misdetect the 3530 on my beagle
> for a 3430). I heard that the only definitive way to do it at runtime
> is to CRC check the ROM code.
>
> Jason, is that correct?

Well if there's no way to detect certain omaps during runtime, please patch arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.

BTW, why can't the dsp code detect if the DSP is there or not?

Tony


To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Added support for OMAP35x processor series

[Tony Lindgren]

* Premi, Sanjeev <premi@ti.com> [080806 12:55]:
> >> Well if there's no way to detect certain omaps during runtime, please patch
> >> arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.
> 
> There was no need to re-define these structures for the current series of the OMAP35x processors.
> Hence, it was left as it.

What exactly do you need to define then for various 35xx processors
that's different from 34xx?

> >> BTW, why can't the dsp code detect if the DSP is there or not?
> 
> (Assuming you mean the code running on ARM that looks for the DSP/SGX/...)
> The detection was based on the chip ID. This happens to be same for OMAP34XX and OMAP35X.

How about trying to read the DSP revision register or something similar?

Tony

> 
> ~sanjeev
> 
> 
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Wednesday, August 06, 2008 2:37 PM
> To: Kridner, Jason
> Cc: 'k.kooi@student.utwente.nl'; 'linux-omap@vger.kernel.org'
> Subject: Re: [PATCH] Added support for OMAP35x processor series
> 
> * Kridner, Jason <jdk@ti.com> [080805 17:12]:
> > No, ROM CRC is useful for detecting between some device revisions, but not OMAp3430 vs OMAP3530.
> >
> > ----- Original Message -----
> > From: Koen Kooi <k.kooi@student.utwente.nl>
> > To: linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>
> > Cc: Kridner, Jason
> > Sent: Tue Aug 05 05:10:40 2008
> > Subject: Re: [PATCH] Added support for OMAP35x processor series
> >
> >
> > Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:
> >
> > > On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
> > >> This patch is needed to ensure that we can make decisions based on
> > >> the processor capabilities.
> > >> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
> > >> disable/ manage the clocks for DSP on this processor. Same for SGX.
> > >
> > > Why can't the detection happen at runtime?
> >
> > AIUI the ID bits are the same (linux misdetect the 3530 on my beagle
> > for a 3430). I heard that the only definitive way to do it at runtime
> > is to CRC check the ROM code.
> >
> > Jason, is that correct?
> 
> Well if there's no way to detect certain omaps during runtime, please patch arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.
> 
> BTW, why can't the dsp code detect if the DSP is there or not?
> 
> Tony
> 
> 
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Added support for OMAP35x processor series

[Premi, Sanjeev]

For 35x processors we need to make compile time decisions to exlude the code that may not be applicable for the specifc processor e.g. excluding the code applicable for DSP/ SGX or both depending upon the exact part number.

~sanjeev

-----Original Message-----
From: Tony Lindgren [mailto:tony@atomide.com]
Sent: Wednesday, August 06, 2008 3:41 PM
To: Premi, Sanjeev
Cc: Kridner, Jason; 'k.kooi@student.utwente.nl'; 'linux-omap@vger.kernel.org'
Subject: Re: [PATCH] Added support for OMAP35x processor series

* Premi, Sanjeev <premi@ti.com> [080806 12:55]:
> >> Well if there's no way to detect certain omaps during runtime,
> >> please patch arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.
>
> There was no need to re-define these structures for the current series of the OMAP35x processors.
> Hence, it was left as it.

What exactly do you need to define then for various 35xx processors that's different from 34xx?

> >> BTW, why can't the dsp code detect if the DSP is there or not?
>
> (Assuming you mean the code running on ARM that looks for the
> DSP/SGX/...) The detection was based on the chip ID. This happens to be same for OMAP34XX and OMAP35X.

How about trying to read the DSP revision register or something similar?

Tony

>
> ~sanjeev
>
>
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Wednesday, August 06, 2008 2:37 PM
> To: Kridner, Jason
> Cc: 'k.kooi@student.utwente.nl'; 'linux-omap@vger.kernel.org'
> Subject: Re: [PATCH] Added support for OMAP35x processor series
>
> * Kridner, Jason <jdk@ti.com> [080805 17:12]:
> > No, ROM CRC is useful for detecting between some device revisions, but not OMAp3430 vs OMAP3530.
> >
> > ----- Original Message -----
> > From: Koen Kooi <k.kooi@student.utwente.nl>
> > To: linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>
> > Cc: Kridner, Jason
> > Sent: Tue Aug 05 05:10:40 2008
> > Subject: Re: [PATCH] Added support for OMAP35x processor series
> >
> >
> > Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:
> >
> > > On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
> > >> This patch is needed to ensure that we can make decisions based
> > >> on the processor capabilities.
> > >> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
> > >> disable/ manage the clocks for DSP on this processor. Same for SGX.
> > >
> > > Why can't the detection happen at runtime?
> >
> > AIUI the ID bits are the same (linux misdetect the 3530 on my beagle
> > for a 3430). I heard that the only definitive way to do it at
> > runtime is to CRC check the ROM code.
> >
> > Jason, is that correct?
>
> Well if there's no way to detect certain omaps during runtime, please patch arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.
>
> BTW, why can't the dsp code detect if the DSP is there or not?
>
> Tony
>
>
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Added support for OMAP35x processor series

[Tony Lindgren]

* Premi, Sanjeev <premi@ti.com> [080806 15:03]:
> For 35x processors we need to make compile time decisions to exlude the code that may not be applicable for the specifc processor e.g. excluding the code applicable for DSP/ SGX or both depending upon the exact part number.

This continuous top posting makes threads impossible to read, please
everybody: do not top post on mailing lists.

Compile time detection of 34xx is not enough. We need to also be able to
detect it during runtime. And if you can't do it based on any registers,
then we need to add omap2_set_globals_3505() et al and force the type
that way.

Regards,

Tony


> 
> ~sanjeev
> 
> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Wednesday, August 06, 2008 3:41 PM
> To: Premi, Sanjeev
> Cc: Kridner, Jason; 'k.kooi@student.utwente.nl'; 'linux-omap@vger.kernel.org'
> Subject: Re: [PATCH] Added support for OMAP35x processor series
> 
> * Premi, Sanjeev <premi@ti.com> [080806 12:55]:
> > >> Well if there's no way to detect certain omaps during runtime,
> > >> please patch arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.
> >
> > There was no need to re-define these structures for the current series of the OMAP35x processors.
> > Hence, it was left as it.
> 
> What exactly do you need to define then for various 35xx processors that's different from 34xx?
> 
> > >> BTW, why can't the dsp code detect if the DSP is there or not?
> >
> > (Assuming you mean the code running on ARM that looks for the
> > DSP/SGX/...) The detection was based on the chip ID. This happens to be same for OMAP34XX and OMAP35X.
> 
> How about trying to read the DSP revision register or something similar?
> 
> Tony
> 
> >
> > ~sanjeev
> >
> >
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org
> > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Wednesday, August 06, 2008 2:37 PM
> > To: Kridner, Jason
> > Cc: 'k.kooi@student.utwente.nl'; 'linux-omap@vger.kernel.org'
> > Subject: Re: [PATCH] Added support for OMAP35x processor series
> >
> > * Kridner, Jason <jdk@ti.com> [080805 17:12]:
> > > No, ROM CRC is useful for detecting between some device revisions, but not OMAp3430 vs OMAP3530.
> > >
> > > ----- Original Message -----
> > > From: Koen Kooi <k.kooi@student.utwente.nl>
> > > To: linux-omap@vger.kernel.org <linux-omap@vger.kernel.org>
> > > Cc: Kridner, Jason
> > > Sent: Tue Aug 05 05:10:40 2008
> > > Subject: Re: [PATCH] Added support for OMAP35x processor series
> > >
> > >
> > > Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:
> > >
> > > > On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
> > > >> This patch is needed to ensure that we can make decisions based
> > > >> on the processor capabilities.
> > > >> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
> > > >> disable/ manage the clocks for DSP on this processor. Same for SGX.
> > > >
> > > > Why can't the detection happen at runtime?
> > >
> > > AIUI the ID bits are the same (linux misdetect the 3530 on my beagle
> > > for a 3430). I heard that the only definitive way to do it at
> > > runtime is to CRC check the ROM code.
> > >
> > > Jason, is that correct?
> >
> > Well if there's no way to detect certain omaps during runtime, please patch arch/arm/plat-omap/common.c to have something like struct omap_globals omap3503_globals.
> >
> > BTW, why can't the dsp code detect if the DSP is there or not?
> >
> > Tony
> >
> >
> > To unsubscribe from this list: send the line "unsubscribe linux-omap"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html

[PATCH0/3] Add support for OMAP35x processors

[Premi, Sanjeev]

Hi,

These patches provide support for the OMAP35x processors.

This is essentially a re-submit after series of discusions
earliers in the list. Based on the comments received, this
patch includes following:
  1) Updates to Kconfig
  2) Runtime check for OMAP35x
  3) Updates to omap3_evm_defconfig

Best regards,
Sanjeev

[PATCH] Added support for OMAP35x processor series

[Sanjeev Premi]

This patch adds basic support for the OMAP35x Applications Processors.
(See: http://focus.ti.com/general/docs/gencontent.tsp?contentId=46725)

As you will notice, NEON SIMD coprocessor is enabled by default for
these processors.

Signed-off-by: Sanjeev Premi <premi@ti.com>
---
 arch/arm/mach-omap2/Kconfig |   50 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 49 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index bb6d695..63d7cdd 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -25,6 +25,54 @@ config ARCH_OMAP3430
 	depends on ARCH_OMAP3 && ARCH_OMAP34XX
 	select ARCH_OMAP_OTG
 
+config ARCH_OMAP35XX
+	bool "OMAP35x Family"
+	select ARCH_OMAP3
+	select ARCH_OMAP34XX
+	select ARCH_OMAP3430
+	select OMAP3430_ES2
+	select NEON
+	help
+	  OMAP35x family of processors based on ARM Cortex-A8
+	  in combination with IVA2.2 core and OpenGL ES2.0
+	  compatible graphics engine.
+
+	  ARM Cortex-A8 contains NEON SIMD coprocessor.
+
+choice
+	prompt "Current choice"
+	default ARCH_OMAP3503
+
+config ARCH_OMAP3503
+	bool "OMAP3503"
+	depends on ARCH_OMAP35XX
+	help
+	  Contains ARM Cortex-A8 processor.
+
+config ARCH_OMAP3515
+	bool "OMAP3515"
+	depends on ARCH_OMAP35XX
+	help
+	   Contains ARM Cortex-A8 processor and SGX530 subsystem
+	   for 2D and 3D graphics acceleration.
+
+config ARCH_OMAP3525
+	bool "OMAP3525"
+	depends on ARCH_OMAP35XX
+	help
+	  Contains ARM Cortex-A8 processor and IVA2.2 subsystem
+	  with a C64x+ DSP core.
+
+config ARCH_OMAP3530
+	bool "OMAP3530"
+	depends on ARCH_OMAP35XX
+	help
+	   Contains ARM Cortex-A8 processor, IVA2.2 subsystem
+	   with a C64x+ DSP Core and SGX530 subsystem for 2D
+	   and 3D graphics acceleration.
+
+endchoice
+
 comment "OMAP Board Type"
 	depends on ARCH_OMAP2 || ARCH_OMAP3
 
@@ -117,7 +165,7 @@ config MACH_OMAP_3430SDP
 
 config MACH_OMAP3EVM
 	bool "OMAP 3530 EVM board"
-	depends on ARCH_OMAP3 && ARCH_OMAP34XX
+	depends on ARCH_OMAP35XX
 
 config MACH_OMAP3_BEAGLE
 	bool "OMAP3 BEAGLE board"
-- 
1.5.6

Re: [PATCH] Added support for OMAP35x processor series

[Tony Lindgren]

* Sanjeev Premi <premi@ti.com> [080801 14:50]:
> This patch adds basic support for the OMAP35x Applications Processors.
> (See: http://focus.ti.com/general/docs/gencontent.tsp?contentId=46725)
> 
> As you will notice, NEON SIMD coprocessor is enabled by default for
> these processors.

Do we really need this? To me it seems like our CPU detection should
figure out the processor is 34xx and specifically 35xx something.

Are there Cortex A8 processors with no Neon hardware?

Tony


> Signed-off-by: Sanjeev Premi <premi@ti.com>
> ---
>  arch/arm/mach-omap2/Kconfig |   50 ++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 49 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index bb6d695..63d7cdd 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -25,6 +25,54 @@ config ARCH_OMAP3430
>  	depends on ARCH_OMAP3 && ARCH_OMAP34XX
>  	select ARCH_OMAP_OTG
>  
> +config ARCH_OMAP35XX
> +	bool "OMAP35x Family"
> +	select ARCH_OMAP3
> +	select ARCH_OMAP34XX
> +	select ARCH_OMAP3430
> +	select OMAP3430_ES2
> +	select NEON
> +	help
> +	  OMAP35x family of processors based on ARM Cortex-A8
> +	  in combination with IVA2.2 core and OpenGL ES2.0
> +	  compatible graphics engine.
> +
> +	  ARM Cortex-A8 contains NEON SIMD coprocessor.
> +
> +choice
> +	prompt "Current choice"
> +	default ARCH_OMAP3503
> +
> +config ARCH_OMAP3503
> +	bool "OMAP3503"
> +	depends on ARCH_OMAP35XX
> +	help
> +	  Contains ARM Cortex-A8 processor.
> +
> +config ARCH_OMAP3515
> +	bool "OMAP3515"
> +	depends on ARCH_OMAP35XX
> +	help
> +	   Contains ARM Cortex-A8 processor and SGX530 subsystem
> +	   for 2D and 3D graphics acceleration.
> +
> +config ARCH_OMAP3525
> +	bool "OMAP3525"
> +	depends on ARCH_OMAP35XX
> +	help
> +	  Contains ARM Cortex-A8 processor and IVA2.2 subsystem
> +	  with a C64x+ DSP core.
> +
> +config ARCH_OMAP3530
> +	bool "OMAP3530"
> +	depends on ARCH_OMAP35XX
> +	help
> +	   Contains ARM Cortex-A8 processor, IVA2.2 subsystem
> +	   with a C64x+ DSP Core and SGX530 subsystem for 2D
> +	   and 3D graphics acceleration.
> +
> +endchoice
> +
>  comment "OMAP Board Type"
>  	depends on ARCH_OMAP2 || ARCH_OMAP3
>  
> @@ -117,7 +165,7 @@ config MACH_OMAP_3430SDP
>  
>  config MACH_OMAP3EVM
>  	bool "OMAP 3530 EVM board"
> -	depends on ARCH_OMAP3 && ARCH_OMAP34XX
> +	depends on ARCH_OMAP35XX
>  
>  config MACH_OMAP3_BEAGLE
>  	bool "OMAP3 BEAGLE board"
> -- 
> 1.5.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Added support for OMAP35x processor series

[Premi, Sanjeev]

This patch is needed to ensure that we can make decisions based on the processor capabilities.
E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to disable/ manage the clocks for
DSP on this processor. Same for SGX.

Enabling NEON is support iby default is just based on the number of requests I have been getting
from various users.

Best regards,
Sanjeev

-----Original Message-----
From: Tony Lindgren [mailto:tony@atomide.com]
Sent: Tuesday, August 05, 2008 2:55 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] Added support for OMAP35x processor series

* Sanjeev Premi <premi@ti.com> [080801 14:50]:
> This patch adds basic support for the OMAP35x Applications Processors.
> (See: http://focus.ti.com/general/docs/gencontent.tsp?contentId=46725)
>
> As you will notice, NEON SIMD coprocessor is enabled by default for
> these processors.

Do we really need this? To me it seems like our CPU detection should figure out the processor is 34xx and specifically 35xx something.

Are there Cortex A8 processors with no Neon hardware?

Tony


> Signed-off-by: Sanjeev Premi <premi@ti.com>
> ---
>  arch/arm/mach-omap2/Kconfig |   50 ++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 49 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index bb6d695..63d7cdd 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -25,6 +25,54 @@ config ARCH_OMAP3430
>       depends on ARCH_OMAP3 && ARCH_OMAP34XX
>       select ARCH_OMAP_OTG
>
> +config ARCH_OMAP35XX
> +     bool "OMAP35x Family"
> +     select ARCH_OMAP3
> +     select ARCH_OMAP34XX
> +     select ARCH_OMAP3430
> +     select OMAP3430_ES2
> +     select NEON
> +     help
> +       OMAP35x family of processors based on ARM Cortex-A8
> +       in combination with IVA2.2 core and OpenGL ES2.0
> +       compatible graphics engine.
> +
> +       ARM Cortex-A8 contains NEON SIMD coprocessor.
> +
> +choice
> +     prompt "Current choice"
> +     default ARCH_OMAP3503
> +
> +config ARCH_OMAP3503
> +     bool "OMAP3503"
> +     depends on ARCH_OMAP35XX
> +     help
> +       Contains ARM Cortex-A8 processor.
> +
> +config ARCH_OMAP3515
> +     bool "OMAP3515"
> +     depends on ARCH_OMAP35XX
> +     help
> +        Contains ARM Cortex-A8 processor and SGX530 subsystem
> +        for 2D and 3D graphics acceleration.
> +
> +config ARCH_OMAP3525
> +     bool "OMAP3525"
> +     depends on ARCH_OMAP35XX
> +     help
> +       Contains ARM Cortex-A8 processor and IVA2.2 subsystem
> +       with a C64x+ DSP core.
> +
> +config ARCH_OMAP3530
> +     bool "OMAP3530"
> +     depends on ARCH_OMAP35XX
> +     help
> +        Contains ARM Cortex-A8 processor, IVA2.2 subsystem
> +        with a C64x+ DSP Core and SGX530 subsystem for 2D
> +        and 3D graphics acceleration.
> +
> +endchoice
> +
>  comment "OMAP Board Type"
>       depends on ARCH_OMAP2 || ARCH_OMAP3
>
> @@ -117,7 +165,7 @@ config MACH_OMAP_3430SDP
>
>  config MACH_OMAP3EVM
>       bool "OMAP 3530 EVM board"
> -     depends on ARCH_OMAP3 && ARCH_OMAP34XX
> +     depends on ARCH_OMAP35XX
>
>  config MACH_OMAP3_BEAGLE
>       bool "OMAP3 BEAGLE board"
> --
> 1.5.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Added support for OMAP35x processor series

[Igor Stoppa]

On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
> This patch is needed to ensure that we can make decisions based on the processor capabilities.
> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to disable/ manage the clocks for
> DSP on this processor. Same for SGX.

Why can't the detection happen at runtime?

> Enabling NEON is support iby default is just based on the number of requests I have been getting
> from various users.

Huh?


-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

RE: [PATCH] Added support for OMAP35x processor series

[Premi, Sanjeev]

> Why can't the detection happen at runtime?
No mechanism as of now.

~sanjeev

-----Original Message-----
From: Igor Stoppa [mailto:igor.stoppa@nokia.com]
Sent: Tuesday, August 05, 2008 3:21 PM
To: Premi, Sanjeev
Cc: Tony Lindgren; linux-omap@vger.kernel.org
Subject: RE: [PATCH] Added support for OMAP35x processor series

On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
> This patch is needed to ensure that we can make decisions based on the processor capabilities.
> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
> disable/ manage the clocks for DSP on this processor. Same for SGX.

Why can't the detection happen at runtime?

> Enabling NEON is support iby default is just based on the number of
> requests I have been getting from various users.

Huh?

[sp] Linux releases on OMAP35x based on 2.6.22 are available for download since MAR '08.

--

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

Re: [PATCH] Added support for OMAP35x processor series

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]


Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:

> On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
>> This patch is needed to ensure that we can make decisions based on  
>> the processor capabilities.
>> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to  
>> disable/ manage the clocks for
>> DSP on this processor. Same for SGX.
>
> Why can't the detection happen at runtime?

AIUI the ID bits are the same (linux misdetect the 3530 on my beagle  
for a 3430). I heard that the only definitive way to do it at runtime  
is to CRC check the ROM code.

Jason, is that correct?

regards,

Koen

>> Enabling NEON is support iby default is just based on the number of  
>> requests I have been getting
>> from various users.
>
> Huh?
>
>
> -- 
>
> Cheers, Igor
>
> ---
>
> Igor Stoppa
> Maemo Software - Nokia Devices R&D - Helsinki
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

RE: [PATCH] Added support for OMAP35x processor series

[Premi, Sanjeev]

A configure time selection will be definitive.

Best regards,
Sanjeev

-----Original Message-----
From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Koen Kooi
Sent: Tuesday, August 05, 2008 3:41 PM
To: linux-omap@vger.kernel.org
Cc: Kridner, Jason
Subject: Re: [PATCH] Added support for OMAP35x processor series


Op 5 aug 2008, om 11:50 heeft Igor Stoppa het volgende geschreven:

> On Tue, 2008-08-05 at 15:09 +0530, ext Premi, Sanjeev wrote:
>> This patch is needed to ensure that we can make decisions based on
>> the processor capabilities.
>> E.g. OMAP3503 does not contain a DSP. We shouldn't be trying to
>> disable/ manage the clocks for DSP on this processor. Same for SGX.
>
> Why can't the detection happen at runtime?

AIUI the ID bits are the same (linux misdetect the 3530 on my beagle for a 3430). I heard that the only definitive way to do it at runtime is to CRC check the ROM code.

Jason, is that correct?

regards,

Koen

>> Enabling NEON is support iby default is just based on the number of
>> requests I have been getting from various users.
>
> Huh?
>
>
> --
>
> Cheers, Igor
>
> ---
>
> Igor Stoppa
> Maemo Software - Nokia Devices R&D - Helsinki
> --
> To unsubscribe from this list: send the line "unsubscribe linux- omap"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html
>