On Wed, Sep 26, 2012 at 04:04:29PM +0100, Mark Brown wrote: > On Wed, Sep 26, 2012 at 04:56:15PM +0200, Davide Ciminaghi wrote: > > On Tue, Sep 25, 2012 at 08:20:48PM +0100, Mark Brown wrote: > > > > Glancing at the diff here this looks a lot like regmap-mmio... not sure > > > if it is or not, though. > > > that would be ideal, but I also need to deal with the common clock > > framework, > > which doesn't support regmap: clk_register_divider(), clk_register_mux(), > > clk_register_gate(), all take a void __iomem * to access clock control > > registers, so as far as I can understand we can't use regmap, unless of > > course we convert the common clock framework to regmap. > > The two should be able to coexist happily, regmap-mmio requires the > caller to do the actual mapping and so long as you don't cache the > relevant registers the two shouldn't interfere with each other. > Well, it just sounded not so clean to me having two ways for accessing the same registers. The caller would be sta2x11-mfd in our case, while clock registers are used by the common clock framework, so sta2x11-mfd should still need to export some void __iomem * to make the clock framework happy, while other potential users could go via regmap. 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. So, as far as I can understand at present, the best thing to do would be adding regmap support to the clock framework, which wouldn't be trivial because I guess we should keep compatibility with the present clk_register_... api
Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
