Le 01/03/2011 12:54, Aneesh V a écrit :
Hi Albert,
On Saturday 08 January 2011 12:06 PM, Albert ARIBAUD wrote:
Hi Aneesh,
[snip ..]
+/* some utility macros */
+#define mask(start, end) \
+ (((1 ((end) - (start) + 1)) - 1) (start))
+
+#define mask_n_get(reg, start, end) \
+ (((reg)
Dear Aneesh V,
In message 4d2a9164.5020...@ti.com you wrote:
Unless we see a specific example which uses this feature, we should
not add provisions that make the code more complicated than needed.
Agree. But do you think the pointer based approach makes it overly
complex?
Not overly
On Thursday 13 January 2011 12:48 AM, Albert ARIBAUD wrote:
(I realize I did not answer the other ones)
Le 08/01/2011 11:06, Aneesh V a écrit :
Out of curiosity, can you elaborate on why the compiler would optimize
better in these cases?
While counting down the termination condition check
On Thursday 13 January 2011 12:53 AM, Albert ARIBAUD wrote:
Le 12/01/2011 10:08, Aneesh V a écrit :
On Saturday 08 January 2011 07:36 PM, Albert ARIBAUD wrote:
Le 08/01/2011 14:17, Aneesh V a écrit :
snip..
+/* some utility macros */
+#define mask(start, end) \
+ (((1 ((end) - (start) +
On Thursday 13 January 2011 12:48 AM, Albert ARIBAUD wrote:
snip ..
+ for (way = num_ways - 1; way= 0 ; way--)
+ for (set = num_sets - 1; set= 0; set--) {
Please fix whitespacing around operators. The best way to ''catch'em
all'' is to run Linux' checkpatch.pl (I do this with option
Le 13/01/2011 13:05, Aneesh V a écrit :
What I need is something like below:
#define get_bit_field(nr, start, mask)\
(((nr) (mask)) (start))
#define set_bit_field(nr, start, mask, val)\
(nr) = ((nr) ~(mask)) | (((val) (start)) (mask))
Can these go in a generic header? If so, can I
On Thursday 13 January 2011 06:44 PM, Albert ARIBAUD wrote:
Le 13/01/2011 13:05, Aneesh V a écrit :
What I need is something like below:
#define get_bit_field(nr, start, mask)\
(((nr) (mask)) (start))
#define set_bit_field(nr, start, mask, val)\
(nr) = ((nr) ~(mask)) | (((val)
Le 13/01/2011 15:30, Aneesh V a écrit :
Perhaps my requirement is different. If this scheme is not used by
many, I shall put these macros in OMAP specific headers.
Yes, I'd prefer that, finally.
best regards,
Aneesh
Amicalement,
--
Albert.
___
Le 13/01/2011 13:14, Aneesh V a écrit :
On Thursday 13 January 2011 12:48 AM, Albert ARIBAUD wrote:
snip ..
+ for (way = num_ways - 1; way= 0 ; way--)
+ for (set = num_sets - 1; set= 0; set--) {
Please fix whitespacing around operators. The best way to ''catch'em
all'' is to run Linux'
On Saturday 08 January 2011 07:36 PM, Albert ARIBAUD wrote:
Le 08/01/2011 14:17, Aneesh V a écrit :
snip..
+/* some utility macros */
+#define mask(start, end) \
+ (((1 ((end) - (start) + 1)) - 1) (start))
+
+#define mask_n_get(reg, start, end) \
+ (((reg) mask(start, end)) (start))
(I realize I did not answer the other ones)
Le 08/01/2011 11:06, Aneesh V a écrit :
Out of curiosity, can you elaborate on why the compiler would optimize
better in these cases?
While counting down the termination condition check is against 0. So
you can just decrement the loop count using
Le 12/01/2011 10:08, Aneesh V a écrit :
On Saturday 08 January 2011 07:36 PM, Albert ARIBAUD wrote:
Le 08/01/2011 14:17, Aneesh V a écrit :
snip..
+/* some utility macros */
+#define mask(start, end) \
+ (((1 ((end) - (start) + 1)) - 1) (start))
+
+#define mask_n_get(reg, start, end) \
Dear Albert ARIBAUD,
In message 4d286f58.9010...@free.fr you wrote:
I know we consider multi-board u-boot binaries when boards are variant
of a given SoC, that's one reason why we wanted relocation. I'm not sure
about multi-SoC when SoC is a variant of a given cpu, though. Wolfgang,
your
Dear Wolfgang,
On Monday 10 January 2011 04:11 AM, Wolfgang Denk wrote:
Dear Albert ARIBAUD,
In message4d286f58.9010...@free.fr you wrote:
I know we consider multi-board u-boot binaries when boards are variant
of a given SoC, that's one reason why we wanted relocation. I'm not sure
about
Le 08/01/2011 07:36, Albert ARIBAUD a écrit :
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -23,7 +23,7 @@
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
# Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS +=
Hi Albert,
On Saturday 08 January 2011 12:06 PM, Albert ARIBAUD wrote:
Hi Aneesh,
Le 22/12/2010 12:54, Aneesh V a écrit :
- Add a framework for layered cache maintenance
- separate out SOC specific outer cache maintenance from
maintenance of caches known to CPU
- Add generic
On Saturday 08 January 2011 12:06 PM, Albert ARIBAUD wrote:
Hi Aneesh,
Pressed the Send button too fast last time. Missed answering the last
few questions.
snip..
+
+void invalidate_dcache_all(void)
+{
+v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
+if (v7_outer_cache.inval_all)
+
Le 08/01/2011 14:17, Aneesh V a écrit :
Why use pointers here rather than weak functions?
In fact, I hadn't thought about it. Maybe I was biased by the Linux
implementation.The only reason I can think of is that pointer gives the
flexibility of doing this assignment at run-time. Let's say we
Hi Aneesh,
Le 22/12/2010 12:54, Aneesh V a écrit :
- Add a framework for layered cache maintenance
- separate out SOC specific outer cache maintenance from
maintenance of caches known to CPU
- Add generic ARMv7 cache maintenance operations that affect all
caches known to
- Add a framework for layered cache maintenance
- separate out SOC specific outer cache maintenance from
maintenance of caches known to CPU
- Add generic ARMv7 cache maintenance operations that affect all
caches known to ARMv7 CPUs. For instance in Cortex-A8 these
opertions
20 matches
Mail list logo
