From: Davide Ciminaghi <ciminaghi@gnudd.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: sameo@linux.intel.com, rubini@gnudd.com,
giancarlo.asnaghi@st.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code
Date: Thu, 27 Sep 2012 15:41:10 +0200 [thread overview]
Message-ID: <20120927134110.GD6799@mail.gnudd.com> (raw)
In-Reply-To: <20120926164932.GS4428@opensource.wolfsonmicro.com>
On Wed, Sep 26, 2012 at 05:49:33PM +0100, Mark Brown wrote:
> On Wed, Sep 26, 2012 at 06:31:45PM +0200, Davide Ciminaghi wrote:
>
> > Oh, and there's another problem (I'm looking at the code right now, I had
> > forgotten about this): the clock framework also asks for a spinlock_t *.
> > Regmap has its own spinlock (or mutex), and I don't think it would be a
> > good idea trying to export it.
>
> Why is this a problem? Nested spinlocks are perfectly fine.
after some cups of coffee, I tried thinking about this subject again, and
here's what I found:
as far as I know, nested locks are fine provided that you always take them in
the same order and release them in the opposite order (lock A, lock B,
unlock B, unlock A). So my conclusion is that nested spinlocks require
potential regmap users of sta2x11 registers to take the sta2x11-mfd spinlock
first. The pattern would be (sctl registers for instance):
spinlock_t *mfd_lock;
void *addr;
/*
Read sta2x11-mfd spinlock address for sctl registers and put it into
mfd_lock
*/
sta2x11_mfd_get_regs_data(pdev, sta2x11_sctl, &addr, &mfd_lock);
......
/* Take the outer lock */
spin_lock(mfd_lock);
/*
Take the inner lock, do whatever you need to do and release the inner lock
*/
regmap_...();
/* Release the outer lock */
spin_unlock(mfd_lock);
The other way around (taking the regmap spinlock as the "outer" one)
would imply at least exporting the regmap spinlock/mutex address or making the
regmap.lock/unlock function pointers public somehow, not
to mention the fact that, for instance, the clock framework helpers should be
modified to deal with nested locking.
If the above is correct, I'm not sure we'd gain a lot from regmap,
because we'd still need some sta2x11 extra code around regmap calls.
Maybe there's another solution: what about adding a couple of function
pointers (lock, unlock) to struct regmap_config ? If they're set to NULL,
everything works as usual. If they're not NULL, regmap uses such functions
to do locking and unlocking instead of the usual ones (and regmap_bus.fast_io
is ignored). I think this wouldn't hurt existing regmap users and allow
sta2x11-mfd to have just one spinlock for everything, no need for nested
locking this way.
Thanks and regards
Davide
next prev parent reply other threads:[~2012-09-27 13:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 10:22 [PATCH 0/8 RESEND] sta2x11-mfd patches ciminaghi
2012-09-12 10:22 ` [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code ciminaghi
2012-09-25 19:20 ` Mark Brown
2012-09-26 14:56 ` Davide Ciminaghi
2012-09-26 15:04 ` Mark Brown
2012-09-26 16:31 ` Davide Ciminaghi
2012-09-26 16:49 ` Mark Brown
2012-09-27 8:39 ` Davide Ciminaghi
2012-09-27 8:56 ` Davide Ciminaghi
2012-09-27 13:41 ` Davide Ciminaghi [this message]
2012-09-27 13:49 ` Mark Brown
2012-09-28 8:43 ` Davide Ciminaghi
2012-09-28 10:52 ` Mark Brown
2012-09-27 14:13 ` Alan Cox
2012-09-28 15:29 ` Davide Ciminaghi
2012-09-12 10:22 ` [PATCH 2/8] sta2x11-mfd : add sta2x11_mfd_get_regs_data() function ciminaghi
2012-09-12 10:22 ` [PATCH 3/8] sta2x11-mfd : use defines for platform devices' names ciminaghi
2012-09-12 10:22 ` [PATCH 4/8] sta2x11-mfd : only add sta2x11_mfd if it hasn't already been added ciminaghi
2012-09-12 10:22 ` [PATCH 5/8] sta2x11-mfd : platform probe: don't mind about gpio platform data ciminaghi
2012-09-12 10:22 ` [PATCH 6/8] sta2x11-mfd : use one lock per device instead of one lock per mfd ciminaghi
2012-09-12 10:22 ` [PATCH 7/8] sta2x11-mfd : add defines for some sta2x11 sctl registers ciminaghi
2012-09-12 10:22 ` [PATCH 8/8] sta2x11-mfd : add myself to copyright ciminaghi
2012-09-16 21:25 ` [PATCH 0/8 RESEND] sta2x11-mfd patches Alessandro Rubini
-- strict thread matches above, loose matches on Subject: below --
2012-09-12 10:11 ciminaghi
2012-09-12 10:11 ` [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code ciminaghi
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=20120927134110.GD6799@mail.gnudd.com \
--to=ciminaghi@gnudd.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=giancarlo.asnaghi@st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rubini@gnudd.com \
--cc=sameo@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.