Rockchip RK3188 I2C driver
broonie at kernel.org
Thu Apr 17 11:38:35 PDT 2014
On Thu, Apr 17, 2014 at 02:04:20AM +0200, Max Schwarz wrote:
> On Tuesday 15 April 2014 at 19:50:25, Mark Brown wrote:
> > Perhaps I'm missing something about why this is helpful but it does seem
> > like the hardware designers have good drugs here.
> I assume that the point is to avoid read/write cycles for bit-level set/clear.
> You can do a "change bit X, leave everything else intact" in a single write
> without reading the previous value, be it from the register itself or from
> some cache.
> 1) Ideally, regmap_update_bits(map, reg, mask, val) & co would directly boil
> down to a single register write of (mask << 16) | val, even for volatile
> registers. That's a rather big change to regmap though, isn't it?
Fairly, yes, and it's a very specialised case which would still need to
take care of the cache.
> 2) A smaller change would be to always use 0xFFFF as the write enable mask
> while writing. That would mean that write accesses to volatile registers
> would always need a read access before to determine the previous value,
That's no different to any other device, though.
> 3) Make the GRF/syscon device give direct register access to the drivers (i.e.
> passing a pointer to the mapped registers) and bypass regmap entirely.
> That would make sense to me because we are AFAIK not using any of regmap's
> features here:
> * Caching is not that useful because a) we are only doing a few init-time
> accesses and b) the write-mask provides similar functionality.
> * The bus for register access is always going to be MMIO.
> * All the drivers using the GRF are rockchip-specific and can know about
> the write-mask thing.
> From the outcome, I would prefer (1). From the complexity, (3). Thoughts?
If you're only doing a few accesses then surely there's no meaningful
overhead from just writing what you want? So long as you don't cache
these registers regmap won't really get in the way.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the linux-arm-kernel