ARM: Generic cache ops skeleton
PATCH 1/1 ARM: Generic cache ops skeleton
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
--- arch/arm/include/asm/cache.h | 22 ++++++++ arch/arm/include/asm/global_data.h | 1 + arch/arm/lib/cache.c | 99 ++++++++++++++++++++++++++--------- 3 files changed, 96 insertions(+), 26 deletions(-)
arch/arm/include/asm/cache.h +22 -0
@@ -53,4 +53,26 @@ void l2_cache_disable(void);#define ARCH_DMA_MINALIGN 64#endif +enum cache_data_op { +CACHE_FLUSH , +CACHE_INVAL +}; + +enum cache_mgmt_op { +CACHE_ENABLE , +CACHE_DISABLE +}; + +struct cache_ops { +uint32_t cache_line_size; +void (*dcache_range_op)(enum cache_data_op op,u32 start,u32 end); +void (*dcache_whole_op)(enum cache_data_op op); +void (*icache_range_op)(enum cache_data_op op,u32 start,u32 end); +void (*icache_whole_op)(enum cache_data_op op); +void (*icache_ops)(enum cache_mgmt_op op); +void (*dcache_ops)(enum cache_mgmt_op op); +}; + +void cpu_register_cache_ops (struct cache_ops *ops); +#endif /* _ASM_CACHE_H */
arch/arm/include/asm/global_data.h +1 -0
@@ -38,6 +38,7 @@ typedef struct global_data {unsigned long flags;unsigned long baudrate;unsigned long have_console;/* serial_init() was called */ +struct cache_ops *cache_ops;/* cache operations */ #ifdef CONFIG_PRE_CONSOLE_BUFFER unsigned long precon_buf_idx;/* Pre-Console buffer index */ #endif
arch/arm/lib/cache.c +73 -26
116 lines not on this page · raw message
Signature · 1 line
1.7.6.3
PATCH 1/1 ARM: Generic cache ops skeleton
Quoted 2 lines · On Saturday 05 November 2011 21:16:23 Marek Vasut wrote:
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
sorry, what's the point ? this would make sense if you wanted to build one u- boot image to run on multiple SoCs, but since that doesn't make sense, i don't see what this patch gets you.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111106/b14d0825/attachment.pgp
PATCH 1/1 ARM: Generic cache ops skeleton
Quoted 8 lines · On Saturday 05 November 2011 21:16:23 Marek Vasut wrote:
Quoted 2 lines
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
sorry, what's the point ? this would make sense if you wanted to build one u- boot image to run on multiple SoCs, but since that doesn't make sense, i don't see what this patch gets you.
-mike
Well that's the ultimate goal, isn't it ...
PATCH 1/1 ARM: Generic cache ops skeleton
Quoted 10 lines · On Sunday 06 November 2011 07:39:56 Marek Vasut wrote:
Quoted 8 lines · On Saturday 05 November 2011 21:16:23 Marek Vasut wrote:
Quoted 3 lines
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
sorry, what's the point ? this would make sense if you wanted to build one u- boot image to run on multiple SoCs, but since that doesn't make sense, i don't see what this patch gets you.
Well that's the ultimate goal, isn't it ...
is it actually ? i must have missed the memo.
support for multiple-SoC-support-in-a-single-image shouldn't bloat the single SoC case. this code seems to do just that. so it sounds like you should find a CONFIG name for this setup and start putting everything behind that.
maybe something like CONFIG_SYS_MULTI_SOC.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111106/1a4519f3/attachment.pgp
PATCH 1/1 ARM: Generic cache ops skeleton
Quoted 10 lines · On Sunday 06 November 2011 07:39:56 Marek Vasut wrote:
Quoted 9 lines
Quoted 8 lines · On Saturday 05 November 2011 21:16:23 Marek Vasut wrote:
Quoted 3 lines
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
sorry, what's the point ? this would make sense if you wanted to build one u- boot image to run on multiple SoCs, but since that doesn't make sense, i don't see what this patch gets you.
Quoted 8 lines
Quoted 1 line
Well that's the ultimate goal, isn't it ...
is it actually ? i must have missed the memo.
support for multiple-SoC-support-in-a-single-image shouldn't bloat the single SoC case. this code seems to do just that. so it sounds like you should find a CONFIG name for this setup and start putting everything behind that.
That's a good point indeed. The other question is, if gcc4.6's LTO won't fix that for us. Surely enough though, we can't rely on that.
Quoted 2 lines
maybe something like
CONFIG_SYS_MULTI_SOC.
Yea
Quoted 1 line
-mike
M
PATCH 1/1 ARM: Generic cache ops skeleton
Hi,
Quoted 6 lines · Marek Vasut
Quoted 6 lines · On Sunday 06 November 2011 07:39:56 Marek Vasut wrote:
Quoted 5 lines
Quoted 5 lines · On Saturday 05 November 2011 21:16:23 Marek Vasut wrote:
Quoted 3 lines
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
sorry, what's the point ? ?this would make sense if you wanted to build one u- boot image to run on multiple SoCs, but since that doesn't make sense, i don't see what this patch gets you.
Well that's the ultimate goal, isn't it ...
is it actually ? ?i must have missed the memo.
It's actually a lot more than cache ops. SOCs have there own clock stuff, pinmux things, power mgmt, timers and the like. While it might be desirable to provide this feature it is a fair bit of work and we need to be careful not to make things more complex.
I would settle for an initial step of getting some sort of unified but simple clock/pinmux support in across all ARM. Anyone interested in that? I mean an API that covers the lot, not an implementation. Also it would be nice to avoid the heavy-weight data structures and strings that Linux has. If we got that far then we could make the interface virtual as Marek has done for caches.
On this particular patch, I feel it should be more explicit about L1 cache, which is what I think it deals with. We may want to support L2 also through a similar API. And a CONFIG option is a good idea.
Finally, even the CP15/cache/MMU code is duplicated in different arch/arm/cpu subdirs. Can we unify this a bit?
Regards,
Simon
Quoted 21 lines
Quoted 5 lines
support for multiple-SoC-support-in-a-single-image shouldn't bloat the single SoC case. ?this code seems to do just that. ?so it sounds like you should find a CONFIG name for this setup and start putting everything behind that.
That's a good point indeed. The other question is, if gcc4.6's LTO won't fix that for us. Surely enough though, we can't rely on that.
Quoted 2 lines
maybe something like
CONFIG_SYS_MULTI_SOC.Yea
Quoted 1 line
-mike
M
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH 1/1 ARM: Generic cache ops skeleton
Quoted 3 lines · On Sunday 06 November 2011 14:29:47 Simon Glass wrote:
On this particular patch, I feel it should be more explicit about L1 cache, which is what I think it deals with. We may want to support L2 also through a similar API. And a CONFIG option is a good idea.
the point of flushing caches is to make the memory coherent to other devices (like peripherals). we don't differentiate between the cache levels.
Quoted 2 lines
Finally, even the CP15/cache/MMU code is duplicated in different
arch/arm/cpusubdirs. Can we unify this a bit?
things should be separated based on core and system levels. the fact that a particular SoC is say armv4 doesn't mean it should have armv4 specific cache/mmu handling in its SoC subdir. i think the Linux arm tree is properly separating things.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111106/5626c6b9/attachment.pgp
PATCH 1/1 ARM: Generic cache ops skeleton
Hi Mike,
Quoted 7 lines · Mike Frysinger
Quoted 3 lines · On Sunday 06 November 2011 14:29:47 Simon Glass wrote:
On this particular patch, I feel it should be more explicit about L1 cache, which is what I think it deals with. We may want to support L2 also through a similar API. And a CONFIG option is a good idea.
the point of flushing caches is to make the memory coherent to other devices (like peripherals). ?we don't differentiate between the cache levels.
Do we not have a situation where the L2 is coherent wrt on-chip peripherals? I haven't looked into it.
Quoted 10 lines
Quoted 3 lines
Finally, even the CP15/cache/MMU code is duplicated in different
arch/arm/cpusubdirs. Can we unify this a bit?things should be separated based on core and system levels. ?the fact that a particular SoC is say armv4 doesn't mean it should have armv4 specific cache/mmu handling in its SoC subdir. ?i think the Linux arm tree is properly separating things.
-mike
Actually I have this wrong - it was the CP15 stuff I was thinking of (in start.S). For cache it is just weak functions that are overridden in the ARMv7 case, and for MMU we only use ARMv4 features.
Going back to this patch, where will cpu_register_cache_ops() be called?
Regards,
Simon
PATCH 1/1 ARM: Generic cache ops skeleton
In reply to Simon GlassLe 06/11/2011 20:29, Simon Glass a ?crit :
Quoted 4 lines
It's actually a lot more than cache ops. SOCs have there own clock stuff, pinmux things, power mgmt, timers and the like. While it might be desirable to provide this feature it is a fair bit of work and we need to be careful not to make things more complex.
Agreed.
Quoted 6 lines
I would settle for an initial step of getting some sort of unified but simple clock/pinmux support in across all ARM. Anyone interested in that? I mean an API that covers the lot, not an implementation. Also it would be nice to avoid the heavy-weight data structures and strings that Linux has. If we got that far then we could make the interface virtual as Marek has done for caches.
On a general note, if we set our goal is to have in U-Boot what Linux has, U-Boot will end up being... Linux, which I don't think is a good thing unless we consider that U-Boot is redundant.
Besides, I don't think 'virtual' interfaces are necessarily the way to go either, not for the sole sake of it anyway. We might well get there with a driver model, and then we might want to see how things are done in Linux, but certainly not import the Linux model without thinking of what makes sense rather than what would be nice. U-Boot's basic principles are fundamentally different from those of an OS like Linux.
We can start, within the "single-SoC binary" model for now, by simply adding relevant SoC-specific or board-specific mechanisms, and using those already in place.
Quoted 6 lines
On this particular patch, I feel it should be more explicit about L1 cache, which is what I think it deals with. We may want to support L2 also through a similar API. And a CONFIG option is a good idea.
Finally, even the CP15/cache/MMU code is duplicated in different
arch/arm/cpusubdirs. Can we unify this a bit?
I think our recent discussion opens the way for this unification in that cp15 code should be able to go away from start.S and into the (fewer) cache lib(s).
Quoted 2 lines
Regards,
Simon
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 ARM: Generic cache ops skeleton
In reply to Marek VasutQuoted 14 lines · On Sunday 06 November 2011 13:07:29 Marek Vasut wrote:
Quoted 14 lines · On Sunday 06 November 2011 07:39:56 Marek Vasut wrote:
Quoted 10 lines
Quoted 8 lines · On Saturday 05 November 2011 21:16:23 Marek Vasut wrote:
Quoted 3 lines
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
sorry, what's the point ? this would make sense if you wanted to build one u- boot image to run on multiple SoCs, but since that doesn't make sense, i don't see what this patch gets you.
Well that's the ultimate goal, isn't it ...
is it actually ? i must have missed the memo.
Quoted 7 lines
Quoted 4 lines
support for multiple-SoC-support-in-a-single-image shouldn't bloat the single SoC case. this code seems to do just that. so it sounds like you should find a CONFIG name for this setup and start putting everything behind that.
That's a good point indeed. The other question is, if gcc4.6's LTO won't fix that for us. Surely enough though, we can't rely on that.
i don't think LTO would help here
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111106/0681fbed/attachment.pgp
PATCH 1/1 ARM: Generic cache ops skeleton
In reply to Marek VasutLe 06/11/2011 02:16, Marek Vasut a ?crit :
Quoted 2 lines
This patch should allow a CPU to register it's own cache ops. This shall allow multiple CPUs with different cache handlings to be supported.
I don't really like the idea of a system of dynamic cache ops right now, because as discussed by Mike, we're far from a one-size-fits-all multiple-SoC binary, and in the current context of a single-SoC binary, this patch is overkill for cache management IMO.
OTOH, I am not against rationalizing the cache code, along the lines already discussed, i.e. factorizing cache code as much as possible (just as we should factorize start.S code for instance).
Amicalement,
Signature · 1 line
Albert.