Re: mc13xxx: add I2C support

[Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>]

On Fri, Jan 20, 2012 at 06:55:35PM +1100, Marc Reilly wrote:
> On Thursday, January 19, 2012 10:29:41 PM Mark Brown wrote:
> > On Thu, Jan 19, 2012 at 12:12:31PM +0100, Arnaud Patard wrote:

> > > I've never looked at regmap deeply but can't it be done with regmap or is
> > > it just a bad idea ?

> > Glancing quickly at the existing code it should map on reasonably well,
> > though a new format definition may be required for the 25 bit shift that
> > would be trivial.

> I'm sadly unfamiliar with regmap, is it a far superior solution? does it need 
> to used now? (ie. I'm relucant to totally rework this now. Please convince me 
> I need to if required.)

It shouldn't be a total rework - the conversion is usually just a case
of replacing the body of the current read/write functions (and ideally
also update_bits() if you've got a one of those) with the equivalent
regmap calls and adding the calls to initialise and free to the probe
functions.  This should be pretty quick and easy.

The benefit of doing the simple conversion is mostly just code sharing,
though you do also get some trace infrastructure for logging register
writes for free.  With a tiny bit more work (saying what the highest
register number is) you'd also get debugfs support for dumping the
register map which is handy for development.  With another small bit of
work (turning on a flag when registering the device and adding a
function which says which registers the chip can change itself) you can
get a register cache which gives a nice performance improvement on
read/modify/write updates as it cuts out the read.  This is useful for
things like DVFS where the regulator voltage change should be as quick
as possible.  None of this is earth shattering but it's very easy to
deploy once the infrastructure is shared.

I doubt Samuel would insist on doing this immediately, though given that
you're adding new bus support it'd be nice.