PPC arch and spinlocks

PPC arch and spinlocks

[Garcia Jérémie]

Hi everybody, I need your help one more time.
I'm new to kernel device driver (linux newbie) and I'd like to control =
concurrent access
to our hardware resources. (I'm working on a ppc405EP platform =
uniprocessor)
Reading the Allessandro Rubini book (Linux device drivers) and many =
lists and guides on the web,
I concluded that spinlocks were very adapted to my expectations.
So, I decided to declare a spinlock in my module and offer, via ioctl, =
the possibilty to user
space programs to handle it with spin_trylock(), spin_lock() and =
spin_unlock().
Unfortunately I saw that was not working properly and so, I wanted to =
debug the "spinlock-process"
printing the value of it after calling one of the above routine:=20

spinlock_t my_spinlock =3D SPIN_UNLOCKED;
[...]
spin_try_lock(&my_spinlock);
printk("value: %d\n",my_spinlock.lock);
[...]

At compile time, I had an error that told me no "lock" member for this =
type of structure.
And it was write, cause I investigated and noticed that the definition =
used for "spinlock_t"=20
structure was the following in <linux/spinlock.h>:

#if (__GNUC__ > 2 || __GNUC_MINOR__ > 95) =20
  typedef struct { } spinlock_t;
  #define SPIN_LOCK_UNLOCKED (spinlock_t) { }   //  empty structure...
[...]

I don't understand cause I thought that spinlocks were recommended for =
SMP platforms but could be
safely used in uni-processor platforms too.=20
So did I miss something to be able to use them (in config?? is it =
specific to PPC arch??)?
If not, is there a way to get a similar behavior with others technics =
(mutex??). I saw Posix mutex? Are they
usable in kernel mode?
I really need to have an equivalent of the spin_trylock() routine in =
order not to have the processus waiting till
the semaphore is available when tryin to get it. (ask and take if =
available, but not sleep).

Please give me some tips.
Tks a lot for your precious help!!
Jeremie

Re: PPC arch and spinlocks

[Jeff Angielski]

On Wed, 2005-06-08 at 16:29 +0200, Garcia Jérémie wrote:
> Hi everybody, I need your help one more time.
> I'm new to kernel device driver (linux newbie) and I'd like to control concurrent access
> to our hardware resources. (I'm working on a ppc405EP platform uniprocessor)

You might find this guide useful:

http://www.kernelnewbies.org/documents/kdoc/kernel-locking/lklockingguide.html



Jeff Angielski
The PTR Group

Re: PPC arch and spinlocks

[Hollis Blanchard]

On Jun 8, 2005, at 9:29 AM, Garcia J=E9r=E9mie wrote:
> I'm new to kernel device driver (linux newbie) and I'd like to control=20=

> concurrent access
> to our hardware resources. (I'm working on a ppc405EP platform=20
> uniprocessor)
> ...
> So, I decided to declare a spinlock in my module and offer, via ioctl,=20=

> the possibilty to user
> space programs to handle it with spin_trylock(), spin_lock() and=20
> spin_unlock().

I don't think this makes any sense. Kernel spinlocks are to protect=20
critical sections of kernel code from race conditions.

> I really need to have an equivalent of the spin_trylock() routine in=20=

> order not to have the processus waiting till the semaphore is=20
> available when tryin to get it. (ask and take if available, but not=20
> sleep).

It sounds like what you want is to enforce only a single user of your=20
device driver. If that's the case, you will need an atomic operation,=20
but if that fails then simply return an appropriate error code from=20
your open() routine.

You could use a spinlock like drivers/char/nvram.c:
static int
nvram_open(struct inode *inode, struct file *file)
{
     spin_lock(&nvram_state_lock);
     if ((nvram_open_cnt && (file->f_flags & O_EXCL)) || ...)
         spin_unlock(&nvram_state_lock);
         return -EBUSY;
     }

     ...
     nvram_open_cnt++;
     spin_unlock(&nvram_state_lock);
     return 0;
}

In this example, "nvram_open_cnt++" is one of the operations being=20
protected from race conditions, such as two processes on an SMP system=20=

both entering open() at literally the same time. Of course, since you=20
aren't building SMP, you know that there will not be two processes in=20
open() simultaneously, so the spinlocks will be compiled out, and you=20
will be left with a plain counter returning -EBUSY if the device is=20
already in use.

-Hollis=