Rockchip RK3188 I2C driver
max.schwarz at online.de
Wed Apr 16 17:04:20 PDT 2014
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
> For non-volatile registers this should work fine if the write enable
> bits are just latched on at probe time, we'll never actually look at the
> what the hardware reads back once things are in cache. For ones that
> are volatile we'll need to teach the framework about it... a write
> enable mask setting that we splat into the value perhaps?
The regmap is not volatile at the moment, but it should probably be. We don't
have documentation on the registers (or do you know more, Heiko?), so we can't
be sure how the bits we don't know about behave.
I see three possible solutions to our problem:
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?
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,
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
* 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?
More information about the linux-arm-kernel