From: Ned Forrester <nforrester-/d+BM93fTQY@public.gmane.org>
To: Amit Uttamchandani <amit.uttam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: spi-devel
<spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: Spinlock vs mutexes for spi network driver
Date: Wed, 17 Mar 2010 17:28:16 -0400 [thread overview]
Message-ID: <4BA14970.3050603@whoi.edu> (raw)
In-Reply-To: <20100317204915.GB6358-QCuvCd35e3/QT0dZR+AlfA@public.gmane.org>
On 03/17/2010 04:49 PM, Amit Uttamchandani wrote:
>
> I have modified 'drivers/net/ethoc.c' for spi communication and it is
> able to transmit/receive packets. However, I am confused about using
> spinlocks vs mutexes for locking access to the spi device.
>
> e.g. For the transmit function I use a work_queue to schedule the
> transmits. In the handler function, I use a mutex to lock the device.
> Could I be using a spinlock here instead? Should I use a spinlock to
> disable the irq while I'm in the middle of transmitting data?
>
> The ethoc device sends out an interrupt everytime a packet is
> successfully transmitted and received. So it has to be acked otherwise
> the interrupt line stays high and no transmit or receive can happen
> (which why I'm not use if I should use the spin_lock_irq variant in this
> case).
>
> Some other spi net drivers such as ks8851.c have mutexes around all spi
> device accesses, which I guess is to prevent simultaneous uses of the
> device. Is this a good idea? Doesn't the spi_transfer calls schedule
> device accesses already?
Mutexes allow the process to sleep if the locked resource is held by
another process. For that reason, they are not permitted in interrupt
context. You can read all about both types of locking in "Linux Device
Drivers":
http://lwn.net/Kernel/LDD3/
That link is to the third edition. I see the fourth edition may be out.
I expect that the fundamentals have not changed.
If I recall correctly, the work queue does NOT run in interrupt context
(are allowed to sleep), and therefore mutexs are permitted (for locking
with other non-interrupt activity). The interrupt handler definitely
runs in interrupt context. If the locking protects data that is shared
between interrupt context and non-interrupt context, then it will have
to be done with a spinlock. pxa2xx_spi.c (the driver I am familiar
with) does not use any mutexes, because the protected data structure is
used in the interrupt handlers.
It has been a while since I have dealt with this stuff, so I have said
something wrong, above, I'm sure I will be quickly corrected.
--
Ned Forrester nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab 508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA
http://www.whoi.edu/
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
next prev parent reply other threads:[~2010-03-17 21:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-17 20:49 Spinlock vs mutexes for spi network driver Amit Uttamchandani
[not found] ` <20100317204915.GB6358-QCuvCd35e3/QT0dZR+AlfA@public.gmane.org>
2010-03-17 21:28 ` Ned Forrester [this message]
[not found] ` <4BA14970.3050603-/d+BM93fTQY@public.gmane.org>
2010-03-18 16:46 ` Amit Uttamchandani
[not found] ` <20100318164641.GA22298-QCuvCd35e3/QT0dZR+AlfA@public.gmane.org>
2010-03-18 17:28 ` Ned Forrester
[not found] ` <4BA262B1.5050001-/d+BM93fTQY@public.gmane.org>
2010-03-18 20:09 ` Amit Uttamchandani
[not found] ` <20100318200940.GC16834-QCuvCd35e3/QT0dZR+AlfA@public.gmane.org>
2010-03-18 22:11 ` Ned Forrester
[not found] ` <4BA2A4F4.60207-/d+BM93fTQY@public.gmane.org>
2010-03-18 23:14 ` Ned Forrester
2010-03-19 9:35 ` Amit Uttamchandani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA14970.3050603@whoi.edu \
--to=nforrester-/d+bm93ftqy@public.gmane.org \
--cc=amit.uttam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).