- 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 w
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)& mask(start, end))>>
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,
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
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_CPP
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
>>
>> - A
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.
>> +
>> +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 s
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,
Dear Wolfgang,
On Monday 10 January 2011 04:11 AM, Wolfgang Denk wrote:
> 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 su
On Saturday 08 January 2011 07:36 PM, Albert ARIBAUD wrote:
> Le 08/01/2011 14:17, Aneesh V a écrit :
>
+/* some utility macros */
+#define mask(start, end) \
+ (((1<< ((end) - (start) + 1)) - 1)<< (start))
+
+#define mask_n_get(reg, start, end) \
+ (((reg)& mask(sta
(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
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 :
>>
>
>
> +/* some utility macros */
> +#define mask(start, end) \
> + (((1<< ((end) - (start) + 1)) - 1)<< (start))
> +
> +#define ma
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 con
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 :
>>>
>>
>>
>> +/* some utility macros */
>> +#define mask(start, end) \
>> + (
On Thursday 13 January 2011 12:48 AM, Albert ARIBAUD wrote:
+ 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 opti
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
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) = ((
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:
>
>
> + 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'' i
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
21 matches
Mail list logo
