linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Fri, 28 Sep 2012 10:43:03 +0200	[thread overview]
Message-ID: <20120928084303.GB22500@mail.gnudd.com> (raw)
In-Reply-To: <20120927134919.GW4428@opensource.wolfsonmicro.com>

On Thu, Sep 27, 2012 at 02:49:19PM +0100, Mark Brown wrote:
> On Thu, Sep 27, 2012 at 03:41:10PM +0200, Davide Ciminaghi wrote:
> 
> > 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.
> 
> That might work, yes, and would be generally useful I think.  Or we
> could add regmap based versions of the clock utilities (which would also
> be useful anyway).  Or both.

I have a (first, incomplete but working) clock framework implementation for
the sta2x11 ready, but can't submit it until these sta2x11-mfd patches have
been accepted.
And then of course many of the drivers we need on sta2x11 depend on the
clock framework (they're amba drivers). So, since sta2x11-mfd is blocking much
of our work, I would proceed like this:

1. Regmap patch for overriding lock/unlock functions
2. Regmap based reimplementation of sta2x11-mfd (using sta2x11 special
   lock/unlock functions).
3. Submission of sta2x11 common clock framework as is (using the current
   version of the clock framework helpers, no regmap).
4. Patches for some amba drivers to get them to work on sta2x11.
5. Regmap related patches for the common clock framework.

Does this sound reasonable ?

Thanks and regards
Davide







  reply	other threads:[~2012-09-28  8:43 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
2012-09-27 13:49               ` Mark Brown
2012-09-28  8:43                 ` Davide Ciminaghi [this message]
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=20120928084303.GB22500@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 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).