[U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7

Aneesh V aneesh at ti.com
Thu Jan 13 13:05:23 CET 2011


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) + 1)) - 1)<< (start))
>>>>>> +
>>>>>> +#define mask_n_get(reg, start, end) \
>>>>>> + (((reg)& mask(start, end))>> (start))
>>>>>
>>>>> Seeing as these functions are only used in the ARMv7 cache C file,
>>>>> they
>>>>> should be moved there.
>>>>
>>>> I plan to use a modified version of mask_n_get() and its set couterpart
>>>> mask_n_set() in my subsequent works in more files.
>>>>
>>>> Can I keep it here itself or should I move it to an OMAP specific
>>>> header file or can I move it to a more generic header file? Please
>>>> suggest.
>>>
>>> They're very generic actually. I think they should go to a gereric bit
>>> manipulation header, and be named a... bit... more explicitly. For
>>> instance, the name 'mask' does not show that the macro creates a range
>>> of 'one' bits from start to end.
>>
>> 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 add them to
>> "include/linux/bitops.h"
>
> After some more thought, I am wondering if a *generic* field setting and
> getting macro is really useful. So far everyone is fine with at most
> defining field-specific macros.

Is it going to be easy if you have many fields to deal with?

However, I agree that the above may be specific to our needs.

What may be of more generic interest may be something like this with
the mask automatically generated:
#define get_bit_field(nr, start, end)
#define set_bit_field(nr, start, end, val)

However, in our case I am already given the mask and start position for
each field (automatically generated from hw database). So, I prefer the
former versions.

If that doesn't look useful for generic use I will put them in
OMAP specific headers.

Best regards,
Aneesh


More information about the U-Boot mailing list