From: Crestez Dan Leonard <leonard.crestez@intel.com>
To: Mark Brown <broonie@kernel.org>, Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Daniel Baluta <daniel.baluta@intel.com>,
Ge Gao <GGao@invensense.com>, Peter Rosin <peda@axentia.se>
Subject: Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings
Date: Tue, 3 May 2016 14:21:40 +0300 [thread overview]
Message-ID: <572889C4.40806@intel.com> (raw)
In-Reply-To: <20160502152328.GG6292@sirena.org.uk>
On 05/02/2016 06:23 PM, Mark Brown wrote:
> On Sun, May 01, 2016 at 06:04:08PM +0100, Jonathan Cameron wrote:
>
>> If you were to break these registers up into regmap fields it might solve
>> this.. Regmap writes always go through whatever - whether they match the
>> existing state of the cache or not. If fields are involved the write will get
>> built up from whatever field you change and whatever the cache has for other
>> elements. I guess it only works if they volatile bits are contiguous though.
>> Maybe hand rolling it is cleaner here.
>
>> Mark, any clever thoughts on this?
>
> I don't have enough context here to be sure what the problem you're
> trying to solve is, sorry.
>
This is worth explaining:
I have a device which has several registers with bits that are a mix of
"cacheable" and "volatile". For example for register SLV4_CTRL:
- Bit 7 (I2C_SLV4_EN) triggers a transaction with slave 4 when a "1" is
written. The bit is cleared when the transaction is done.
- Bits 0-4 (I2C_MST_DLY) configures the reduced access rate of I2C
slaves relative to the device sample rate. This applies to slaves 0-3 as
well.
If I2C_MST_DLY was a separate register it could be easily cached by
regmap. Because it's part of a volatile register I have to add a
private_data field caching the value and always write it when triggering
a SLV4 transfer.
Jonathan was wondering if regmap can still be used somehow instead of
custom caching.
--
Regards,
Leonard
next prev parent reply other threads:[~2016-05-03 11:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 19:02 [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings Crestez Dan Leonard
2016-04-29 19:02 ` [PATCH 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c directly Crestez Dan Leonard
2016-05-01 17:11 ` Jonathan Cameron
2016-05-02 15:24 ` Mark Brown
2016-04-29 19:02 ` [PATCH 2/7] iio: inv_mpu6050: Initial regcache support Crestez Dan Leonard
2016-05-01 17:12 ` Jonathan Cameron
2016-04-29 19:02 ` [PATCH 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo Crestez Dan Leonard
2016-05-01 17:13 ` Jonathan Cameron
2016-04-29 19:02 ` [PATCH 4/7] iio: inv_mpu6050: Cache non-volatile bits of user_ctrl Crestez Dan Leonard
2016-05-01 17:14 ` Jonathan Cameron
2016-04-29 19:02 ` [RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master Crestez Dan Leonard
[not found] ` <4aeaced7c1c8e222996df4c1b4b71e505ab256f7.1461953982.git.leonard.crestez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-05-01 17:27 ` Jonathan Cameron
2016-05-01 17:27 ` Jonathan Cameron
2016-05-05 12:38 ` Crestez Dan Leonard
2016-05-05 13:10 ` Rob Herring
2016-05-02 15:31 ` Peter Rosin
2016-04-29 19:02 ` [PATCH 6/7] iio: inv_mpu6050: Check channel configuration on preenable Crestez Dan Leonard
2016-05-01 17:34 ` Jonathan Cameron
2016-05-03 13:01 ` Crestez Dan Leonard
2016-05-04 9:01 ` Jonathan Cameron
2016-05-04 15:34 ` Crestez Dan Leonard
2016-05-04 18:22 ` Jonathan Cameron
2016-04-29 19:02 ` [RFC 7/7] iio: inv_mpu6050: Add support for external sensors Crestez Dan Leonard
2016-05-01 17:54 ` Jonathan Cameron
2016-05-01 17:54 ` Jonathan Cameron
2016-05-02 12:15 ` Rob Herring
2016-05-01 17:04 ` [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings Jonathan Cameron
2016-05-02 15:23 ` Mark Brown
2016-05-03 11:21 ` Crestez Dan Leonard [this message]
2016-05-03 11:32 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=572889C4.40806@intel.com \
--to=leonard.crestez@intel.com \
--cc=GGao@invensense.com \
--cc=broonie@kernel.org \
--cc=daniel.baluta@intel.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.