mach-davinci: fix cache flush build error

Commit Message

Linus Walleij Aug. 2, 2011, 3:48 p.m. UTC

From: Linus Walleij <[e-mail]>

The TNET variant of DaVinci compiles some code that it shares
with other DaVinci variants, however it has a V6 CPU rather than
an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all()
in sleep.S will obviously fail, and we need to build with the
v6_flush_kern_cache_all() call instead. This was triggered by
manually altering the DaVinci config to build the TNET version.

Cc: Dave Martin <[e-mail]>
Cc: Arnd Bergmann <[e-mail]>
Signed-off-by: Linus Walleij <[e-mail]>
---
This is just an ifdef to get the DaVinci TNET variant to compile,
if there is a way to call out to some abstract flush function in a
MULTI CPU/cache configuration from _assembler_ code, please tell me,

I'm not all that happy about this since it blocks proper multiboard
support for DaVinci, would be nice to find a better solution.
---
 arch/arm/mach-davinci/sleep.S |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

Comments

Russell King - ARM Linux Aug. 2, 2011, 4:02 p.m. UTC | #1

On Tue, Aug 02, 2011 at 05:48:38PM +0200, Linus Walleij wrote:
> From: Linus Walleij <[e-mail]>
> 
> The TNET variant of DaVinci compiles some code that it shares
> with other DaVinci variants, however it has a V6 CPU rather than
> an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all()
> in sleep.S will obviously fail, and we need to build with the
> v6_flush_kern_cache_all() call instead. This was triggered by
> manually altering the DaVinci config to build the TNET version.
> 
> Cc: Dave Martin <[e-mail]>
> Cc: Arnd Bergmann <[e-mail]>
> Signed-off-by: Linus Walleij <[e-mail]>
> ---
> This is just an ifdef to get the DaVinci TNET variant to compile,
> if there is a way to call out to some abstract flush function in a
> MULTI CPU/cache configuration from _assembler_ code, please tell me,
> 
> I'm not all that happy about this since it blocks proper multiboard
> support for DaVinci, would be nice to find a better solution.

Davinci seems to be a special case where it somehow preserves all state
even in deep sleep, which makes the generic cpu_suspend() not ideal for
it.

Or maybe that's just an oversight in the existing code - I don't know
so I haven't touched it.  I've been hoping that Davinci people can sort
it out...

Linus Walleij Aug. 3, 2011, 1:23 p.m. UTC | #2

On Tue, Aug 2, 2011 at 5:48 PM, Linus Walleij
<[e-mail]> wrote:

> The TNET variant of DaVinci compiles some code that it shares
> with other DaVinci variants, however it has a V6 CPU rather than
> an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all()
> in sleep.S will obviously fail, and we need to build with the
> v6_flush_kern_cache_all() call instead. This was triggered by
> manually altering the DaVinci config to build the TNET version.
>
> Cc: Dave Martin <[e-mail]>
> Cc: Arnd Bergmann <[e-mail]>
> Signed-off-by: Linus Walleij <[e-mail]>

Arnd can you pick this patch to some suitable arm-soc branch like fixes?
Atleast it makes the DaVinci variants compile one by one.

Thanks,
Linus Walleij

Sekhar Nori Aug. 3, 2011, 5:19 p.m. UTC | #3

On Tue, Aug 02, 2011 at 21:32:34, Russell King - ARM Linux wrote:
> On Tue, Aug 02, 2011 at 05:48:38PM +0200, Linus Walleij wrote:
> > From: Linus Walleij <[e-mail]>
> > 
> > The TNET variant of DaVinci compiles some code that it shares
> > with other DaVinci variants, however it has a V6 CPU rather than
> > an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all()
> > in sleep.S will obviously fail, and we need to build with the
> > v6_flush_kern_cache_all() call instead. This was triggered by
> > manually altering the DaVinci config to build the TNET version.
> > 
> > Cc: Dave Martin <[e-mail]>
> > Cc: Arnd Bergmann <[e-mail]>
> > Signed-off-by: Linus Walleij <[e-mail]>
> > ---
> > This is just an ifdef to get the DaVinci TNET variant to compile,
> > if there is a way to call out to some abstract flush function in a
> > MULTI CPU/cache configuration from _assembler_ code, please tell me,
> > 
> > I'm not all that happy about this since it blocks proper multiboard
> > support for DaVinci, would be nice to find a better solution.

This isn't the only thing that prevents building the TNET variant
with the rest of the DaVinci variants.

If you enable DM365 and TNETV107x together, you get errors:

  AS      arch/arm/kernel/entry-armv.o
arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:196: Error: selected processor does not support `strex r1,r2,[sp]'
arch/arm/kernel/entry-armv.S:228: Error: selected processor does not support `strex r1,r2,[sp]'
arch/arm/kernel/entry-armv.S:286: Error: selected processor does not support `strex r1,r2,[sp]'
arch/arm/kernel/entry-armv.S:323: Error: selected processor does not support `strex r1,r2,[sp]'

And from what I read[1], it is futile to try and make v5 and v6 architectures
build together.

> Davinci seems to be a special case where it somehow preserves all state
> even in deep sleep, which makes the generic cpu_suspend() not ideal for
> it.
> 
> Or maybe that's just an oversight in the existing code - I don't know
> so I haven't touched it.  I've been hoping that Davinci people can sort
> it out...

It is true that DaVinci does not lose state even in its lowest power
mode. There are no power domains to switch off in DaVinci. The deep
sleep mode just stops device clocks and on-chip oscillator is shutdown.

Considering this, Linus's patch looks fair to me. If there are no
objections, I will queue for v3.1-rc

Linus, in future can you please CC me and/or Kevin on DaVinci patches?

Thanks,
Sekhar

[1] http://www.mail-archive.com/[e-mail]/msg43834.html

Russell King - ARM Linux Aug. 3, 2011, 6:14 p.m. UTC | #4

On Wed, Aug 03, 2011 at 10:49:21PM +0530, Nori, Sekhar wrote:
> And from what I read[1], it is futile to try and make v5 and v6 architectures
> build together.

Correct.  The differences are just too great.  We're going to hit the
same thing with LPAE too.

Linus Walleij Aug. 3, 2011, 10:48 p.m. UTC | #5

On Wed, Aug 3, 2011 at 7:19 PM, Nori, Sekhar <[e-mail]> wrote:

> This isn't the only thing that prevents building the TNET variant
> with the rest of the DaVinci variants.
>
> If you enable DM365 and TNETV107x together, you get errors:

Looks like it needs some KConfig patch to disallow such combinations
then?

> Considering this, Linus's patch looks fair to me. If there are no
> objections, I will queue for v3.1-rc

Thanks!

> Linus, in future can you please CC me and/or Kevin on DaVinci patches?

Yeah, sorry. Will do better.
Linus Walleij

Sekhar Nori Aug. 4, 2011, 2:30 p.m. UTC | #6

On Thu, Aug 04, 2011 at 04:18:49, Linus Walleij wrote:
> On Wed, Aug 3, 2011 at 7:19 PM, Nori, Sekhar <[e-mail]> wrote:
> 
> > This isn't the only thing that prevents building the TNET variant
> > with the rest of the DaVinci variants.
> >
> > If you enable DM365 and TNETV107x together, you get errors:
> 
> Looks like it needs some KConfig patch to disallow such combinations
> then?

Yes, need to work on this. Build breakage is bad.

Thanks,
Sekhar

Patch

diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
index fb5e72b..5f1e045 100644
--- a/arch/arm/mach-davinci/sleep.S
+++ b/arch/arm/mach-davinci/sleep.S
@@ -217,7 +217,11 @@  ddr2clk_stop_done:
 ENDPROC(davinci_ddr_psc_config)
 
 CACHE_FLUSH:
-	.word	arm926_flush_kern_cache_all
+#ifdef CONFIG_CPU_V6
+	.word	v6_flush_kern_cache_all
+#else
+	.word   arm926_flush_kern_cache_all
+#endif
 
 ENTRY(davinci_cpu_suspend_sz)
 	.word	. - davinci_cpu_suspend