[PATCH 8/11] Compiling dsp-common if DSP is enabled.

[PATCH 8/11] Compiling dsp-common if DSP is enabled.

[Syed Mohammed, Khasim]

Compile dsp_common only if DSP is enabled.

Signed-off-by: Syed Mohammed Khasim  <x0khasim@ti.com>

Files Changed:
 Makefile |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

=======================================================================
diff -purN linux-omap/arch/arm/plat-omap/dsp/Makefile val_3430_GIT/arch/arm/plat-omap/dsp/Makefile
--- linux-omap/arch/arm/plat-omap/dsp/Makefile	2006-11-20 21:54:05.000000000 -0600
+++ val_3430_GIT/arch/arm/plat-omap/dsp/Makefile	2007-05-28 13:30:09.000000000 -0500
@@ -4,7 +4,7 @@
 
 # The target object and module list name.
 
-obj-y := dsp_common.o
+obj-$(CONFIG_OMAP_DSP) := dsp_common.o
 
 obj-$(CONFIG_OMAP_DSP) += dsp.o
 

Re: [PATCH 8/11] Compiling dsp-common if DSP is enabled.

[Tony Lindgren]

* Syed Mohammed, Khasim <x0khasim@ti.com> [070528 23:22]:
> 
> Compile dsp_common only if DSP is enabled.
> 
> Signed-off-by: Syed Mohammed Khasim  <x0khasim@ti.com>
> 
> Files Changed:
>  Makefile |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> =======================================================================
> diff -purN linux-omap/arch/arm/plat-omap/dsp/Makefile val_3430_GIT/arch/arm/plat-omap/dsp/Makefile
> --- linux-omap/arch/arm/plat-omap/dsp/Makefile	2006-11-20 21:54:05.000000000 -0600
> +++ val_3430_GIT/arch/arm/plat-omap/dsp/Makefile	2007-05-28 13:30:09.000000000 -0500
> @@ -4,7 +4,7 @@
>  
>  # The target object and module list name.
>  
> -obj-y := dsp_common.o
> +obj-$(CONFIG_OMAP_DSP) := dsp_common.o
>  
>  obj-$(CONFIG_OMAP_DSP) += dsp.o

We should compile DSP for omap1 (and aybe 24xx?) to keep
audio McBSP clock functioning. And eventually we should have common
dsp init that works for all of them.

What if you just add an early return to dsp init code for now with
a revisit comment?

Regards,

Tony

RE: [PATCH 8/11] Compiling dsp-common if DSP is enabled.

[Woodruff, Richard]

> We should compile DSP for omap1 (and aybe 24xx?) to keep
> audio McBSP clock functioning. And eventually we should have common
> dsp init that works for all of them.
> 
> What if you just add an early return to dsp init code for now with
> a revisit comment?

The McBSP clocks in OMAP2 have no coupling to the DSP as they did in OMAP1.  In 1510's systems there was some ownership which required you to mess in the DSP address space.  This is not there in OMAP2/3.

Depending on the overall system architecture you might very well have the DSP driving a McBSP directly but that is another issue.

... How does DSP gateway share or allocate resources, like a McBSP away from the ARM?  Is this static?  Does it even make sense to declare it as some sort of platform resource?

Regards,
Richard W.

Re: [PATCH 8/11] Compiling dsp-common if DSP is enabled.

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [070529 10:02]:
> > We should compile DSP for omap1 (and aybe 24xx?) to keep
> > audio McBSP clock functioning. And eventually we should have common
> > dsp init that works for all of them.
> > 
> > What if you just add an early return to dsp init code for now with
> > a revisit comment?
> 
> The McBSP clocks in OMAP2 have no coupling to the DSP as they did in OMAP1.  In 1510's systems there was some ownership which required you to mess in the DSP address space.  This is not there in OMAP2/3.
> 
> Depending on the overall system architecture you might very well have the DSP driving a McBSP directly but that is another issue.
> 
> ... How does DSP gateway share or allocate resources, like a McBSP away from the ARM?  Is this static?  Does it even make sense to declare it as some sort of platform resource?

The basic DSP resources should be shared across dspgateway and
TI's bridge. Then the rest can go to drivers/dsp/omap/dspgateway and
drivers/dsp/omap/dspbridge or someting.

Regards,

Tony