ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

PATCH Superseded Dirk Behme 4 participants 16 messages Aug 8, 2009 – Aug 20, 2009

Share & tools

Dirk Behme

author

2009-08-08 10:46 UTC #0 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.

Signed-off-by Tom Rix <[email protected]>

Signed-off-by Dirk Behme <[email protected]>

---

Changes in v2: Rebase against recent git head 3b9043a7c03290c9bdbef03848307263f5f3472c "omap3: bug fix for NOR boot support"

This patch updates

http://lists.denx.de/pipermail/u-boot/2009-July/055543.html

Second patch of this series

http://lists.denx.de/pipermail/u-boot/2009-July/055544.html

seems to be fixed already, so doesn't seem to be necessary any more.

Compile tested with ./MAKEALL ARM_CORTEX_A8, boot tested on BeagleBoard.

 cpu/arm_cortexa8/cpu.c                 |    2 
 cpu/arm_cortexa8/omap3/Makefile        |    1 
 cpu/arm_cortexa8/omap3/board.c         |    2 
 cpu/arm_cortexa8/omap3/cache_flush.S   |  118 +++++++++++++++++++++++++++++++++
 cpu/arm_cortexa8/start.S               |   86 ------------------------
 include/asm-arm/arch-omap3/sys_proto.h |    2 
 6 files changed, 122 insertions(+), 89 deletions(-)
 create mode 100644 cpu/arm_cortexa8/omap3/cache_flush.S

cpu/arm_cortexa8/cpu.c +1 -1

Index: u-boot-main/cpu/arm_cortexa8/cpu.c
===================================================================
@@ -64,7 +64,7 @@ int cleanup_before_linux(void)
 	/* turn off L2 cache */
 	l2_cache_disable();
 	/* invalidate L2 cache also */
-	v7_flush_dcache_all(get_device_type());
+	flush_dcache(get_device_type());
 #endif
 	i = 0;
 	/* mem barrier to sync up things */

cpu/arm_cortexa8/omap3/board.c +1 -1

Index: u-boot-main/cpu/arm_cortexa8/omap3/board.c
===================================================================
@@ -201,7 +201,7 @@ void s_init(void)
 	 * Right now flushing at low MPU speed.
 	 * Need to move after clock init
 	 */
-	v7_flush_dcache_all(get_device_type());
+	flush_dcache(get_device_type());
 #ifndef CONFIG_ICACHE_OFF
 	icache_enable();
 #endif

cpu/arm_cortexa8/omap3/cache_flush.S new file +118 -0

118 lines not on this page · raw message

cpu/arm_cortexa8/start.S +0 ~~-86~~

89 lines not on this page · raw message

cpu/arm_cortexa8/omap3/Makefile +1 -0

Index: u-boot-main/cpu/arm_cortexa8/omap3/Makefile
===================================================================
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
 LIB	=  $(obj)lib$(SOC).a
 
 SOBJS	:= lowlevel_init.o
+SOBJS	+= cache_flush.o
 SOBJS	+= reset.o
 
 COBJS	+= board.o

include/asm-arm/arch-omap3/sys_proto.h +1 -1

Index: u-boot-main/include/asm-arm/arch-omap3/sys_proto.h
===================================================================
@@ -55,7 +55,7 @@ void secureworld_exit(void);
 void setup_auxcr(void);
 void try_unlock_memory(void);
 u32 get_boot_type(void);
-void v7_flush_dcache_all(u32);
+void flush_dcache(u32);
 void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);

Dirk Behme

author

2009-08-08 10:46 UTC #1 lore raw

PATCH 1/1 OMAP3: Fix missing GPMC_CONFIG_CS0_BASE

Applying two indepenent OMAP3 patches resulted in missing GPMC_CONFIG_CS0_BASE. Patch "omap3: embedd gpmc_cs into gpmc config struct" removes GPMC_CONFIG_CS0_BASE, independent patch "omap3: bug fix for NOR boot support" introduces it's usage. Re-introduce GPMC_CONFIG_CS0_BASE.

Signed-off-by Dirk Behme <[email protected]>

---
 include/asm-arm/arch-omap3/cpu.h |    1 +
 1 file changed, 1 insertion(+)

include/asm-arm/arch-omap3/cpu.h +1 -0

Index: u-boot-main/include/asm-arm/arch-omap3/cpu.h
===================================================================
@@ -91,6 +91,7 @@ struct ctrl_id {
 
 #define GPMC_BASE		(OMAP34XX_GPMC_BASE)
 #define GPMC_CONFIG_CS0		0x60
+#define GPMC_CONFIG_CS0_BASE	(GPMC_BASE + GPMC_CONFIG_CS0)
 
 #ifndef __KERNEL_STRICT_NAMES
 #ifndef __ASSEMBLY__

Wolfgang Denk

Applied

2009-08-09 22:13 UTC #2 lore raw

PATCH 1/1 OMAP3: Fix missing GPMC_CONFIG_CS0_BASE

Dear Dirk Behme,

Quoted 11 lines · In message <[email protected]> you…

Applying two indepenent OMAP3 patches resulted in missing GPMC_CONFIG_CS0_BASE. Patch "omap3: embedd gpmc_cs into gpmc config struct" removes GPMC_CONFIG_CS0_BASE, independent patch "omap3: bug fix for NOR boot support" introduces it's usage. Re-introduce GPMC_CONFIG_CS0_BASE.
Signed-off-by Dirk Behme <[email protected]>
---
 include/asm-arm/arch-omap3/cpu.h |    1 +
 1 file changed, 1 insertion(+)

Applied, thanks.

Best regards,

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Wish not to seem, but to be, the best."                  - Aeschylus

Jean-Christophe PLAGNIOL-VILLARD

2009-08-08 11:26 UTC #3 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

In reply to Dirk Behme

Quoted 9 lines · Dirk Behme

Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.
Signed-off-by Tom Rix <[email protected]>
Signed-off-by Dirk Behme <[email protected]>
---

NACK keep the arm arch version in the name

and as request to Tom remove the non need device_type
and we can safely use the v7 cache flush for omap3 and other cortex a8

Best Regards,
J.

Dirk Behme

author

2009-08-08 13:47 UTC #4 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 11 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 9 lines · Dirk Behme
Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.
Signed-off-by Tom Rix <[email protected]>
Signed-off-by Dirk Behme <[email protected]>
---
NACK keep the arm arch version in the name

NACK the NACK, see below.

Quoted 2 lines

and as request to Tom remove the non need device_type
and we can safely use the v7 cache flush for omap3 and other cortex a8

This can be done easily (later?) by an additional patch (when people have time for it?).

Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.

Best regards

Dirk

Jean-Christophe PLAGNIOL-VILLARD

2009-08-08 14:10 UTC #5 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 15 lines · Dirk Behme

Quoted 11 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 9 lines · Dirk Behme
Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.
Signed-off-by Tom Rix <[email protected]>
Signed-off-by Dirk Behme <[email protected]>
---
NACK keep the arm arch version in the name
NACK the NACK, see below.

Quoted 8 lines

Quoted 2 lines
and as request to Tom remove the non need device_type
and we can safely use the v7 cache flush for omap3 and other cortex a8
This can be done easily (later?) by an additional patch (when people have time for it?).
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.

no this code is omap3 specific and there is no need ot this rename or move the function make no sense

so NACK

Best Regards,
J.

Dirk Behme

author

2009-08-08 14:35 UTC #6 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 17 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 16 lines · Dirk Behme
Quoted 11 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 9 lines · Dirk Behme
Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.
Signed-off-by Tom Rix <[email protected]>
Signed-off-by Dirk Behme <[email protected]>
---
NACK keep the arm arch version in the name
NACK the NACK, see below.
Quoted 2 lines
and as request to Tom remove the non need device_type
and we can safely use the v7 cache flush for omap3 and other cortex a8

Quoted 7 lines

Quoted 5 lines
This can be done easily (later?) by an additional patch (when people have time for it?).
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.
no this code is omap3 specific and there is no need ot this rename or move the function make no sense

Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.

Quoted 1 line

so NACK

NACK your NACK, see above.

Best regards

Dirk

Jean-Christophe PLAGNIOL-VILLARD

2009-08-08 15:00 UTC #7 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 23 lines · Dirk Behme

Quoted 22 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 21 lines · Dirk Behme
Quoted 11 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 9 lines · Dirk Behme
Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.
Signed-off-by Tom Rix <[email protected]>
Signed-off-by Dirk Behme <[email protected]>
---
NACK keep the arm arch version in the name
NACK the NACK, see below.
Quoted 2 lines
and as request to Tom remove the non need device_type
and we can safely use the v7 cache flush for omap3 and other cortex a8
This can be done easily (later?) by an additional patch (when people have time for it?).
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.

Quoted 7 lines

Quoted 2 lines
no this code is omap3 specific and there is no need ot this rename or move the function make no sense
Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.

the flush MUST NOT be soc specific as there is NO need to do this at all

so NACK

Best Regards,
J.

Dirk Behme

author

2009-08-08 15:18 UTC #8 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 26 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 25 lines · Dirk Behme
Quoted 24 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 14 lines · Dirk Behme
Quoted 11 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 9 lines · Dirk Behme
Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.
Signed-off-by Tom Rix <[email protected]>
Signed-off-by Dirk Behme <[email protected]>
---
NACK keep the arm arch version in the name
NACK the NACK, see below.
Quoted 7 lines
Quoted 2 lines
and as request to Tom remove the non need device_type
and we can safely use the v7 cache flush for omap3 and other cortex a8
This can be done easily (later?) by an additional patch (when people have time for it?).
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.
no this code is omap3 specific and there is no need ot this rename or move the function make no sense

Quoted 8 lines

Quoted 4 lines
Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
the flush MUST NOT be soc specific as there is NO need to do this at all
so NACK

Let's summarize:

- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"

Sorry, but this sounds somehow confusing, better let us stop here.

As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more. Then everybody (including you) can send additional patches for further improvements.

Best regards

Dirk

Jean-Christophe PLAGNIOL-VILLARD

2009-08-08 15:26 UTC #9 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 8 lines

Quoted 8 lines
Quoted 5 lines
Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
the flush MUST NOT be soc specific as there is NO need to do this at all

Quoted 8 lines

Quoted 1 line
so NACK
Let's summarize:
- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"

the current implementation is wrong

there is NO NEED to have a omap3 specific full cache code as the generic armv7 full cache work fine on omap3

that's why rename it or move it make no sense as we can use the same full cache code on cortex a8

the only part that could be soc specific will the l2 flush code

that's why I NACK this as it does not fix anything and just will end with duplicated code

and yes I do want to have armv7 name in the armv cache function

I known you will tell but the other does not
I agree the other arm flush code need to be clean and it's plan anyway as I need it to add the mmu and d-cache support
which will be done later

Quoted 4 lines

As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more. Then everybody (including you) can send additional patches for further improvements.

It's plan as I'm working currentlty on the mmu and d-cache support for arm and the current arm implementation will be udpated really soon to allow this and after I'll take a look in the relocation scheme on arm

Best Regards,
J.

Wolfgang Denk

2009-08-08 18:03 UTC #10 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Dear Jean-Christophe PLAGNIOL-VILLARD,

Quoted 10 lines · In message <[email protected]> you wrote:

Quoted 9 lines
Quoted 2 lines
so NACK
Let's summarize:
- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"
the current implementation is wrong

I try to stay out of this flame war, but Jean-Christophenm I cannot prevent myself from stating that indeed with each noew message from you in this thread you come up with new arguments. This is not exactly a convincing method, and it makes me (and probably others) wonder if you are just argumenting because you want to have some fight or if ther eis really some technical argument.

If there is one, it should remain contant, so we can try to understand what you mean.

Quoted 1 line

and yes I do want to have armv7 name in the armv cache function

And this is something which does not make any sense to me. If we have a function flush_dcache() it should be indeed a genric one, so it can be used everywhere in the code where we need to flush the data cache. What would be the sense to stick the architecture name in it? If we - for example - decide we need to flush the data cache somewhere in the generic code, then I want to be able to write

	flush_dcache();

Your proposal sounds as if we would end up with

#if defined(_ARMV7_)
	armv7_flush_dcache();
#elif defined(_OMAP3_)
	omap3__flush_dcache();
...
#elif defined(_MIPS32_)
	mips32_flush_dcache();
#elif defined(_MIPS64_)
	mips64_flush_dcache();

...

This cannot be your intention?

A _generig_ name is a must, I think.

Quoted 4 lines

I known you will tell but the other does not
I agree the other arm flush code need to be clean and it's plan anyway as I need it to add the mmu and d-cache support
which will be done later

Again this argument of some clenup that might be performed some time in the future. If this should happen one day, then changing one funcktion name more or less probably makes only marginal difference.

Quoted 6 lines

Quoted 3 lines
As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more. Then everybody (including you) can send additional patches for further improvements.
It's plan as I'm working currentlty on the mmu and d-cache support for arm and the current arm implementation will be udpated really soon to allow this and after I'll take a look in the relocation scheme on arm

So this is all plans for some future release. Fine.

But what we're discussing here is a patch for the current release. And we've been told that other development depends on getting this into a working state, so I even tend to consider this a bug fix.

I think specific needs for the current release must have higher priority than some unspecific and unconfirmed plans for some later release.

Best regards,

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I've seen it. It's rubbish."          - Marvin the Paranoid Android

Jean-Christophe PLAGNIOL-VILLARD

2009-08-08 18:59 UTC #11 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 33 lines · Wolfgang Denk

Dear Jean-Christophe PLAGNIOL-VILLARD,
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 9 lines
Quoted 2 lines
so NACK
Let's summarize:
- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"
the current implementation is wrong
I try to stay out of this flame war, but Jean-Christophenm I cannot prevent myself from stating that indeed with each noew message from you in this thread you come up with new arguments. This is not exactly a convincing method, and it makes me (and probably others) wonder if you are just argumenting because you want to have some fight or if ther eis really some technical argument.
If there is one, it should remain contant, so we can try to understand what you mean.
Quoted 1 line
and yes I do want to have armv7 name in the armv cache function
And this is something which does not make any sense to me. If we have a function flush_dcache() it should be indeed a genric one, so it can be used everywhere in the code where we need to flush the data cache. What would be the sense to stick the architecture name in it? If we - for example - decide we need to flush the data cache somewhere in the generic code, then I want to be able to write

Quoted 8 lines

	flush_dcache();
Your proposal sounds as if we would end up with
#if defined(_ARMV7_)
	armv7_flush_dcache();
#elif defined(_OMAP3_)
	omap3__flush_dcache();

again no need of omap3 flush code
so just armv7_flush_cache

Quoted 8 lines

...
#elif defined(_MIPS32_)
	mips32_flush_dcache();
#elif defined(_MIPS64_)
	mips64_flush_dcache();
...
This cannot be your intention?

no on more and more soc as cortex from armltd
the difference between two soc for U-Boot point of view will be the cache version which we detect via the cp15 and have only one U-Boot for both

Quoted 11 lines

A _generig_ name is a must, I think.
Quoted 4 lines
I known you will tell but the other does not
I agree the other arm flush code need to be clean and it's plan anyway as I need it to add the mmu and d-cache support
which will be done later
Again this argument of some clenup that might be performed some time in the future. If this should happen one day, then changing one funcktion name more or less probably makes only marginal difference.

no the patch cleanup nothing it just move code in omap3 that is mostly armv7 specific and not omap3 specific. The only part that is omap3 specfic is non need anyway so move it make no sense

Quoted 8 lines

Quoted 7 lines
Quoted 4 lines
As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more. Then everybody (including you) can send additional patches for further improvements.
It's plan as I'm working currentlty on the mmu and d-cache support for arm and the current arm implementation will be udpated really soon to allow this and after I'll take a look in the relocation scheme on arm

Quoted 5 lines

So this is all plans for some future release. Fine.
But what we're discussing here is a patch for the current release. And we've been told that other development depends on getting this into a working state, so I even tend to consider this a bug fix.

as the current code fix nothing and on contrary introduce a bug as the code in most armv7 specifc not omap3

the true fix will to remove the omap3 code as it's not needed

Best Regards,
J.

Dirk Behme

author

2009-08-10 16:20 UTC #12 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

In reply to Dirk Behme

Quoted 39 lines · Dirk Behme

Quoted 27 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 26 lines · Dirk Behme
Quoted 25 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 14 lines · Dirk Behme
Quoted 11 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 9 lines · Dirk Behme
Since there is only one version of flushing the dcache for arm_cortex8, rename v7_flush_dcache_all to the the generic name flush_dcache. Because the function is intended for only omap3 boards, move the function to the new file cache_flush.S.
Signed-off-by Tom Rix <[email protected]>
Signed-off-by Dirk Behme <[email protected]>
---
NACK keep the arm arch version in the name
NACK the NACK, see below.
Quoted 8 lines
Quoted 3 lines
and as request to Tom remove the non need device_type and we can safely use the v7 cache flush for omap3 and other cortex a8
This can be done easily (later?) by an additional patch (when people have time for it?).
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.
no this code is omap3 specific and there is no need ot this rename or move the function make no sense
Quoted 8 lines
Quoted 4 lines
Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
the flush MUST NOT be soc specific as there is NO need to do this at all
so NACK
Let's summarize:

Quoted 8 lines

- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"
Sorry, but this sounds somehow confusing, better let us stop here.
As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more.

At the weekend, I missed the point why this code is OMAP3 specific and why it has to be moved to omap3 directory, so short update:

It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g. Samsung. That is, it must be moved to not stall others any more.

(Thanks to Tom for remembering this!)

Best regards

Dirk

Jean-Christophe PLAGNIOL-VILLARD

2009-08-19 23:49 UTC #13 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 22 lines

Quoted 22 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.
no this code is omap3 specific and there is no need ot this rename or move the function make no sense
Quoted 8 lines
Quoted 4 lines
Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
the flush MUST NOT be soc specific as there is NO need to do this at all
so NACK
Let's summarize:
- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"
Sorry, but this sounds somehow confusing, better let us stop here.

Quoted 8 lines

Quoted 2 lines
As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more.
At the weekend, I missed the point why this code is OMAP3 specific and why it has to be moved to omap3 directory, so short update:
It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g. Samsung. That is, it must be moved to not stall others any more.

so I'll repeat this only once there no need to call the rom code as the generic armv7 cache full work fine

so no-need to use omap3 specific code

Best Regards,
J.

Tom

2009-08-20 11:48 UTC #14 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 30 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 30 lines
Quoted 18 lines
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.
no this code is omap3 specific and there is no need ot this rename or move the function make no sense
Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
Quoted 5 lines
the flush MUST NOT be soc specific as there is NO need to do this at all
so NACK
Let's summarize:
Quoted 9 lines
- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"
Sorry, but this sounds somehow confusing, better let us stop here.
As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more.
At the weekend, I missed the point why this code is OMAP3 specific and why it has to be moved to omap3 directory, so short update:

Quoted 9 lines

Quoted 3 lines
It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g. Samsung. That is, it must be moved to not stall others any more.
so I'll repeat this only once there no need to call the rom code as the generic armv7 cache full work fine
so no-need to use omap3 specific code

I am not sure if the generic code can replace the omap3 code. I do not have access to the ROM code.
From what I have seen on the l2_cache code, it seems that in
some cases that the ROM code handles earlier revs of the hardware. I would be in favor of phasing in the new generic code so that if older hardware needed to use the ROM code it could.
Not know knowing full effect of the change we should go slowly and provide options for legacy support up front.
Tom

Quoted 3 lines

Best Regards,
J.

Dirk Behme

author

2009-08-20 13:52 UTC #15 lore raw

PATCH v2 1/1 ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

Quoted 40 lines · Tom

Quoted 30 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 30 lines
Quoted 18 lines
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches.
no this code is omap3 specific and there is no need ot this rename or move the function make no sense
Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
Quoted 5 lines
the flush MUST NOT be soc specific as there is NO need to do this at all
so NACK
Let's summarize:
Quoted 9 lines
- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"
Sorry, but this sounds somehow confusing, better let us stop here.
As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more.
At the weekend, I missed the point why this code is OMAP3 specific and why it has to be moved to omap3 directory, so short update:
Quoted 9 lines
Quoted 3 lines
It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g. Samsung. That is, it must be moved to not stall others any more.
so I'll repeat this only once there no need to call the rom code as the generic armv7 cache full work fine
so no-need to use omap3 specific code

Quoted 8 lines

I am not sure if the generic code can replace the omap3 code. I do not have access to the ROM code.
From what I have seen on the l2_cache code, it seems that in
some cases that the ROM code handles earlier revs of the hardware. I would be in favor of phasing in the new generic code so that if older hardware needed to use the ROM code it could.
Not know knowing full effect of the change we should go slowly and provide options for legacy support up front.

Yes. Agreed.

Best regards

Dirk