Best practice to lock a read/write to a HW register

Luca Ellero lroluk at gmail.com
Fri Nov 15 03:53:07 EST 2013


Il 15/11/2013 02:30, manty kuma ha wrote:
> Ideally, it depends on the platform you are working. You need to 
> discuss with them for the correct approach. For Qualcomm they have 
> some hardware caled as RPU(Register protection unit). They have 
> systems calls exposed for using them. You can associtate it to the 
> register you want protection. I dont know if there is any way you 
> could do it in Linux itself?
>
> Regards,
> Sandeep
>
>
> On Thu, Nov 14, 2013 at 9:14 PM, Bernd Petrovitsch 
> <bernd at petrovitsch.priv.at <mailto:bernd at petrovitsch.priv.at>> wrote:
>
>     Hi!
>
>     On Don, 2013-11-14 at 11:32 +0100, Luca Ellero wrote:
>     [...]
>     > can someone please show me which is the best practice to lock a
>     > read/write to a hardware register.
>     > In other words if, in a driver, I want to modify a bit in a HW
>     register,
>     > I have to read the register, set/reset the relevant bit and
>     write back
>     > the reg.
>     > But what can I do to be sure that no other code modifies the
>     register
>     > between my read and write?
>     > Is spin_lock() suitable for this purpose?
>
>     If the read-modify-write (read: the critical section) run-time is
>     short,
>     a spin-lock is the usual means. If it is needed from IRQ-context - see
>     also other mails - you must use the *_irq() variant.
>
>             Bernd
>     --
>     Bernd Petrovitsch                  Email :
>     bernd at petrovitsch.priv.at <mailto:bernd at petrovitsch.priv.at>
>                          LUGA : http://www.luga.at
>
>
>     _______________________________________________
>     Kernelnewbies mailing list
>     Kernelnewbies at kernelnewbies.org
>     <mailto:Kernelnewbies at kernelnewbies.org>
>     http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


Thanks to all,
your suggestions are very appreciated
Best regards
Luca





More information about the Kernelnewbies mailing list