Re: [PATCH 2/6] regmap: Add a magic bus type to handle quirks ofanalog devices ADIS sensors.

From: Mark Brown
Date: Wed Sep 07 2011 - 14:32:38 EST


On Wed, Sep 07, 2011 at 07:26:10PM +0100, Jonathan Cameron wrote:
> On 09/07/11 18:47, Mark Brown wrote:
> > On Wed, Sep 07, 2011 at 05:19:43PM +0100, Jonathan Cameron wrote:

> > To be honest I'm not terribly happy about
> > pushing this into the regmap core code; if we start needing to do stuff
> > like this we should expose the bus interface.

> That's certainly an option, but I'd really like to use the regmap caching
> stuff in here. These things can have quite a few registers that other than
> their weird read / write quirks look much like any other register based
> device. (particularly ignoring the burst reads but they tend to apply
> to volatile registers only so caching is probably irrelevant).

> At the moment, the only hooks AFAIKS to allow this are at the bus level.
> I'm not sure where else they could go. (I haven't actually looked much
> at the cache code yet though).

Well, if there's not hooks they could be added if it's not too painful.
However I'm not convinced that's sane.

> Actually I may have misunderstood, do you mean expose the bus interface
> within regmap or just not use regmap at all?

Either. Or either expose marshalling or add configuration for the
marshalling depending on what's being done, I'm not convinced you need
to be working at SPI level at all.

> >> +static struct regmap_bus regmap_spi_adi = {
> >> + .write = regmap_spi_write,
> >> + .read = regmap_spi_read,
> >> +};

> > You want to implement the gather write too if you can.

> Doesn't really exist other than by linearising them into a series
> of calls to the write function. (assuming I understand what those
> functions are doing right!)

If you build up a series of SPI transfers you just need to control when
/CS gets bounced appropriately.
--
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/