Re: [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code

[Davide Ciminaghi]

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






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/