pxa: Disable dcache on palmld, palmtc, zipitz2

PATCH New Simon Glass 4 participants 7 messages Oct 30, 2012 – Nov 5, 2012

Share & tools

Simon Glass

author

2012-10-30 23:38 UTC #0 lore raw

PATCH 1/1 pxa: Disable dcache on palmld, palmtc, zipitz2

These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().

Signed-off-by Simon Glass <[email protected]>

---
 include/configs/palmld.h  |    3 +++
 include/configs/palmtc.h  |    3 +++
 include/configs/zipitz2.h |    3 +++
 3 files changed, 9 insertions(+), 0 deletions(-)

include/configs/palmld.h +3 -0

index c5dd494..3f9802c 100644
@@ -28,6 +28,9 @@
 #define	CONFIG_CPU_PXA27X		1	/* Marvell PXA270 CPU */
 #define	CONFIG_PALMLD		1	/* Palm LifeDrive board */
 
+/* we will never enable dcache, because we have to setup MMU first */
+#define CONFIG_SYS_DCACHE_OFF
+
 /*
  * Environment settings
  */

include/configs/palmtc.h +3 -0

index 9c948c5..64771e7 100644
@@ -30,6 +30,9 @@
 #define	CONFIG_CPU_PXA25X			1	/* Intel PXA255 CPU */
 #define	CONFIG_PALMTC			1	/* Palm Tungsten|C board */
 
+/* we will never enable dcache, because we have to setup MMU first */
+#define CONFIG_SYS_DCACHE_OFF
+
 /*
  * Environment settings
  */

include/configs/zipitz2.h +3 -0

index bf6394a..b92f70b 100644
@@ -41,6 +41,9 @@
 #define CONFIG_ENV_ADDR			0x40000
 #define CONFIG_ENV_SIZE			0x20000
 
+/* we will never enable dcache, because we have to setup MMU first */
+#define CONFIG_SYS_DCACHE_OFF
+
 #define	CONFIG_SYS_MALLOC_LEN		(128*1024)
 #define	CONFIG_ARCH_CPU_INIT

Signature · 1 line

1.7.7.3

Tom Rini

2012-10-31 14:44 UTC #2 lore raw

PATCH 1/1 pxa: Disable dcache on palmld, palmtc, zipitz2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 9 lines · Marek Vasut

Dear Simon Glass,
Quoted 5 lines
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by Simon Glass <[email protected]>
Is that needed? Why not fix PXA by defining stub cache routines ?

Adding stubs sounds more like a work-around than disabling support that we won't have to me.

- --
Tom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQkTllAAoJENk4IS6UOR1WLr4P/A+W1cl1MV2aBrLH0VMPCjzn M3oOHvn2TQDbIZawIVf1AXbAv6BVfdLWg4XUQFsfnU/sFS3gGZccK4U4aCVqwoXv ewUD6L7UgT9GeKCSvACDIwx0T3xntSO5B6+fzESyDzE2I04ZjnUyP5cKkXZWNJdH XTB0F5BP6EgPwGtfvl/5gjWajuDLyPnuyd+kLY8LOsBc5g6ELORkjQGMeVzs1Qe9 rFtQfw/g/ie3Qq7O7UDmaliJq7iLiZL7aSam/+20so0JzvTYTspT9lk6Gt2yRJRU iLA3J53BOsU4JnZ28PwfHycQEKxFhYWLUAyhO6G8wMjod7NEcwC138ywvoOFX1xg A/wWiorxt94nioiZmRAVOwQKNiIiPLCJg4T2j5BzhhUvK/xT3F2lhcI8fF9HpVt4 dKzVRpO3TvtYXVLajpRVuoVVUkiInwo68NEHv6cZZDsKFKOWKG6zmEotVR9xAf1y 3NHz+d8j78Ach5k4O7bJXDZKIO+s3ak3Oa6uHUmz0oPwPnb9PsLNd3B/Ds5uMLsB BsHREAk7f+K6cRH4vWZOfJ2vuuLMViR5+lIsPAUKMi9uPVM3qG/MFcrkr0pqAML7 8a6kn/9lAmPquQCm3t7tLgJNhZkMuMokFLGFe6oQDGSNdxeaOSPmxli2W464vhsh T0l9Gi6Mb3yAbJuMYnJM
=AJDZ
-----END PGP SIGNATURE-----

Marek Vasut

2012-10-31 16:41 UTC #3 lore raw

PATCH 1/1 pxa: Disable dcache on palmld, palmtc, zipitz2

Dear Tom Rini,

Quoted 7 lines · Marek Vasut

Quoted 6 lines
Dear Simon Glass,
Quoted 4 lines
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Simon Glass <[email protected]>
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.

Yes, but then, the stubs will be optimized out.

I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.

We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.

Best regards,
Marek Vasut

Tom Warren

2012-10-31 16:52 UTC #4 lore raw

PATCH 1/1 pxa: Disable dcache on palmld, palmtc, zipitz2

Marek,

Quoted 25 lines

-----Original Message-----
From: Marek Vasut [mailto:marex at denx.de]
Sent: Wednesday, October 31, 2012 9:41 AM
To: Tom Rini
Cc: Simon Glass; U-Boot Mailing List; Tom Warren
Subject: Re: [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
Dear Tom Rini,
Quoted 7 lines · Marek Vasut
Quoted 6 lines
Dear Simon Glass,
Quoted 4 lines
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Simon Glass <[email protected]>
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
Yes, but then, the stubs will be optimized out.

Quoted 8 lines

I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.
We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.

You are the PXA custodian, according to the wiki. Simon's fix is to get the PXA boards that use LCD to compile OK with the Tegra LCD cache flush changes that he implemented. I think it contains the appropriate change to get those builds working, which is all he's obligated to do.

If you want stubs written for those boards, why don't you do it, since it affects the boards you are responsible for? It seems to me that it's more in your bailiwick than Simon's - as you state, every platform should implement cache stubs, and these are your platforms.

Tom

Quoted 3 lines

Best regards,
Marek Vasut

Signature · 1 line

nvpublic

Simon Glass

author

2012-11-05 20:47 UTC #5 lore raw

PATCH 1/1 pxa: Disable dcache on palmld, palmtc, zipitz2

Hi,

Quoted 33 lines · Tom Warren

Marek,
Quoted 31 lines
-----Original Message-----
From: Marek Vasut [mailto:marex at denx.de]
Sent: Wednesday, October 31, 2012 9:41 AM
To: Tom Rini
Cc: Simon Glass; U-Boot Mailing List; Tom Warren
Subject: Re: [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
Dear Tom Rini,
Quoted 7 lines · Marek Vasut
Quoted 6 lines
Dear Simon Glass,
Quoted 4 lines
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Simon Glass <[email protected]>
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
Yes, but then, the stubs will be optimized out.
I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.

Quoted 7 lines

Quoted 2 lines
We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.
You are the PXA custodian, according to the wiki. Simon's fix is to get the PXA boards that use LCD to compile OK with the Tegra LCD cache flush changes that he implemented. I think it contains the appropriate change to get those builds working, which is all he's obligated to do.
If you want stubs written for those boards, why don't you do it, since it affects the boards you are responsible for? It seems to me that it's more in your bailiwick than Simon's - as you state, every platform should implement cache stubs, and these are your platforms.

Is that the final word? If so, Tom Warren should be able to pull this through. If not, Marek are you going to send a patch to replace this patch? If that is coming soon, I suggest we wait a few days. If not, then we can perhaps take this patch and then Marek can clean up later.

Regards,
Simon

Quoted 6 lines

Tom
Quoted 3 lines
Best regards,
Marek Vasut
--
nvpublic

Marek Vasut

2012-11-05 22:59 UTC #6 lore raw

PATCH 1/1 pxa: Disable dcache on palmld, palmtc, zipitz2

Dear Simon Glass,

Quoted 49 lines

Hi,
Quoted 41 lines · Tom Warren
Marek,
Quoted 25 lines
-----Original Message-----
From: Marek Vasut [mailto:marex at denx.de]
Sent: Wednesday, October 31, 2012 9:41 AM
To: Tom Rini
Cc: Simon Glass; U-Boot Mailing List; Tom Warren
Subject: Re: [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
Dear Tom Rini,
Quoted 7 lines · Marek Vasut
Quoted 6 lines
Dear Simon Glass,
Quoted 4 lines
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Simon Glass <[email protected]>
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
Yes, but then, the stubs will be optimized out.
Quoted 8 lines
I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.
We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.
You are the PXA custodian, according to the wiki. Simon's fix is to get the PXA boards that use LCD to compile OK with the Tegra LCD cache flush changes that he implemented. I think it contains the appropriate change to get those builds working, which is all he's obligated to do.
Quoted 4 lines
If you want stubs written for those boards, why don't you do it, since it affects the boards you are responsible for? It seems to me that it's more in your bailiwick than Simon's - as you state, every platform should implement cache stubs, and these are your platforms.

Quoted 4 lines

Is that the final word? If so, Tom Warren should be able to pull this through. If not, Marek are you going to send a patch to replace this patch? If that is coming soon, I suggest we wait a few days. If not, then we can perhaps take this patch and then Marek can clean up later.

Just apply this. PXA is mostly dead anyway.

Best regards,
Marek Vasut