On 11/02/2017 09:03 AM, David Daney wrote:
> On 11/02/2017 05:23 AM, Andrew Lunn wrote:
>>> +static void res_mgr_lock(void)
>>> +{
>>> + unsigned int tmp;
>>> + u64 lock = (u64)&res_mgr_info->rlock;
>>> +
>>> + __asm__ __volatile__(
>>> + ".set noreorder\n"
>>> + "1: ll %[tmp], 0(%[addr])\n"
>>> + " bnez %[tmp], 1b\n"
>>> + " li %[tmp], 1\n"
>>> + " sc %[tmp], 0(%[addr])\n"
>>> + " beqz %[tmp], 1b\n"
>>> + " nop\n"
>>> + ".set reorder\n" :
>>> + [tmp] "=&r"(tmp) :
>>> + [addr] "r"(lock) :
>>> + "memory");
>>> +}
>>> +
>>> +static void res_mgr_unlock(void)
>>> +{
>>> + u64 lock = (u64)&res_mgr_info->rlock;
>>> +
>>> + /* Wait until all resource operations finish before unlocking. */
>>> + mb();
>>> + __asm__ __volatile__(
>>> + "sw $0, 0(%[addr])\n" : :
>>> + [addr] "r"(lock) :
>>> + "memory");
>>> +
>>> + /* Force a write buffer flush. */
>>> + mb();
>>> +}
>>
>> It would be good to add some justification for using your own locks,
>> rather than standard linux locks.
>
> Yes, I will add that.
>
>
>>
>> Is there anything specific to your hardware in this resource manager?
>> I'm just wondering if this should be generic, put somewhere in lib. Or
>> maybe there is already something generic, and you should be using it,
>> not re-inventing the wheel again.
>
> The systems built around this hardware may have other software running
> on CPUs that are not running the Linux kernel. The data structures used
> to arbitrate usage of shared system hardware resources use exactly these
> locking primitives, so they cannot be changed to use the Linux locking
> implementation de jour.
Would hwspinlock be a possible option so this is abstracted on the Linux
side using these locking primitives through the hwspinlock layer which
in turn does exactly what is above?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
