Hallo Pavel,
On 25/06/16 17:06, Pavel Pisa wrote:
There are architectures (for example some/many ARM Cortex-A) which have
different cache line sizes for data and instruction caches.
CPU kit and even BSP can be build for group of CPUs which differs
in cache line sizes as well and there are situations when maximum
alignment is not reported by rtems_cache_get_data_line_size.
Ensure, that allocated memory is aligned at least to CPU_CACHE_LINE_BYTES
which is in pair with compile time data structures allocation.
Signed-off-by: Pavel Pisa <p...@cmp.felk.cvut.cz>
---
cpukit/libcsupport/src/cachealignedalloc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/cpukit/libcsupport/src/cachealignedalloc.c
b/cpukit/libcsupport/src/cachealignedalloc.c
index a704859..bb93937 100644
--- a/cpukit/libcsupport/src/cachealignedalloc.c
+++ b/cpukit/libcsupport/src/cachealignedalloc.c
@@ -18,6 +18,9 @@ void *rtems_cache_aligned_malloc( size_t nbytes )
size_t line_size = rtems_cache_get_data_line_size();
if ( line_size > 0 ) {
+ if ( line_size < CPU_CACHE_LINE_BYTES )
+ line_size = CPU_CACHE_LINE_BYTES;
+
/* Assume that the cache line size is a power of two */
size_t m = line_size - 1;
so, in case rtems_cache_get_data_line_size() returns a non-zero value,
then you assume that it lies to the user and fix it here in this place only?
The purpose of CPU_CACHE_LINE_BYTES is to provide a worst-case cache
line size at cpukit compile-time.
We have
/**
* @brief Returns the data cache line size in bytes.
*
* For multi-level caches this is the maximum of the cache line sizes
of all
* levels.
*
* @retval 0 No data cache is present.
* @retval positive The data cache line size in bytes.
*/
size_t rtems_cache_get_data_line_size( void );
/**
* @brief Returns the instruction cache line size in bytes.
*
* For multi-level caches this is the maximum of the cache line sizes
of all
* levels.
*
* @retval 0 No instruction cache is present.
* @retval positive The instruction cache line size in bytes.
*/
size_t rtems_cache_get_instruction_line_size( void );
I think the documentation is pretty clear. In case a BSP implements
these functions wrongly, then we should fix this BSP.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
