Skip to contentSkip to conversation

lib_ppc: make the flush_cache stronger

RFC PATCH New Dave Liu 3 participants 6 messages Apr 15, 2008 – Apr 25, 2008

lore
Share & tools
lore

Dave Liu

author
#0 lore raw

RFC PATCH 1/1 lib_ppc: make the flush_cache stronger

Current flush_cache code does

1. clean the dcache with dcbst, but not invalidate dcache
2. invalidate icache

This patch use the dcbf instead of dcbst to have stronger semantic, clean the dcache and invalidate dcache.

Signed-off-by Dave Liu <[email protected]>

---

To meet DMA safe operation on cache enabled system, such as DMA_TO_DEVICE/DMA_FROM_DEVICE/DMA_BIDIRECTIONAL

We have two options:

1. Separate functions for them like linux kernel. A. clean dcache (dcbst) for DMA_TO_DEVICE B. invalidate dcache (dcbi) for DMA_FROM_DEVICE C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
2. Make current flush_cache stronger semanctic. use the dcbf instead of dcbst.

Which one is better? or you have better option?
Please suggest.

Thanks,
Dave

 lib_ppc/cache.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
lib_ppc/cache.c +2 -2
index 27e1a82..f4039ba 100644
@@ -34,9 +34,9 @@ void flush_cache (ulong start_addr, ulong size)
 		for (addr = start_addr;
 		     addr < end_addr;
 		     addr += CFG_CACHELINE_SIZE) {
-			asm ("dcbst 0,%0": :"r" (addr));
+			asm ("dcbf 0,%0": :"r" (addr));
 		}
-		asm ("sync");	/* Wait for all dcbst to complete on bus */
+		asm ("sync");	/* Wait for all dcbf to complete on bus */
 
 		for (addr = start_addr;
 		     addr < end_addr;
Signature · 1 line
1.5.4.rc4
#1 lore raw

RFC PATCH 1/1 lib_ppc: make the flush_cache stronger

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

Current flush_cache code does

1. clean the dcache with dcbst, but not invalidate dcache
2. invalidate icache

This patch use the dcbf instead of dcbst to have stronger semantic, clean the dcache and invalidate dcache.

On which processors did you test the changes? I have some unclear memories of dcbf having problems on for example MPC8xx ?

Quoted 11 lines

We have two options:

1. Separate functions for them like linux kernel. A. clean dcache (dcbst) for DMA_TO_DEVICE B. invalidate dcache (dcbi) for DMA_FROM_DEVICE C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
2. Make current flush_cache stronger semanctic. use the dcbf instead of dcbst.

Which one is better? or you have better option?
Please suggest.

We discussed this a bit on IRC; Kumar suggested to go for 1., and I agree.

Best regards,

Wolfgang Denk

Signature · 7 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 believe the use of noise to make  music  will  increase  until  we
reach  a  music  produced  through  the aid of electrical instruments
which will make available for musical purposes  any  and  all  sounds
that can be heard."                        - composer John Cage, 1937
author
#2 lore raw

RFC PATCH 1/1 lib_ppc: make the flush_cache stronger

Quoted 10 lines
Quoted 7 lines

Current flush_cache code does

1. clean the dcache with dcbst, but not invalidate dcache
2. invalidate icache

This patch use the dcbf instead of dcbst to have stronger semantic, clean the dcache and invalidate dcache.

On which processors did you test the changes? I have some unclear memories of dcbf having problems on for example MPC8xx ?

on 83xx parts.
I remember the 601 processor not support the dcbf.

Quoted 9 lines
Quoted 9 lines

We have two options:

1. Separate functions for them like linux kernel. A. clean dcache (dcbst) for DMA_TO_DEVICE B. invalidate dcache (dcbi) for DMA_FROM_DEVICE C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
2. Make current flush_cache stronger semanctic. use the dcbf instead of dcbst.

Quoted 5 lines
Quoted 2 lines

Which one is better? or you have better option?
Please suggest.

We discussed this a bit on IRC; Kumar suggested to go for 1., and I agree.

Where is the IRC? Could you point it to me?

Thanks,
Dave

#3 lore raw

RFC PATCH 1/1 lib_ppc: make the flush_cache stronger

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

On which processors did you test the changes? I have some unclear memories of dcbf having problems on for example MPC8xx ?

on 83xx parts.
I remember the 601 processor not support the dcbf.

OK, so cannot use the patch you suggested.

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines

We have two options:

1. Separate functions for them like linux kernel. A. clean dcache (dcbst) for DMA_TO_DEVICE B. invalidate dcache (dcbi) for DMA_FROM_DEVICE C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
2. Make current flush_cache stronger semanctic. use the dcbf instead of dcbst.

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Which one is better? or you have better option?
Please suggest.

We discussed this a bit on IRC; Kumar suggested to go for 1., and I agree.

Where is the IRC? Could you point it to me?

That's #u-boot at irc.freenode.org

Best regards,

Wolfgang Denk

Signature · 5 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
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt
#4 lore raw

RFC PATCH 1/1 lib_ppc: make the flush_cache stronger

Quoted 9 lines · Wolfgang Denk
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines

On which processors did you test the changes? I have some unclear memories of dcbf having problems on for example MPC8xx ?

on 83xx parts.
I remember the 601 processor not support the dcbf.

OK, so cannot use the patch you suggested.

u-boot doesn't support any 601 systems and we should keep it that way.

- k

#5 lore raw

RFC PATCH 1/1 lib_ppc: make the flush_cache stronger

In reply to Dave Liu
Quoted 4 lines
Quoted 2 lines

We discussed this a bit on IRC; Kumar suggested to go for 1., and I agree.

Where is the IRC? Could you point it to me?

same server (irc.freenode.net) as #mklinux, but the channel is #u-boot

- k