From: Jonathan Cameron <jic23@kernel.org>
To: Matt Ranostay <mranostay@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH] iio: chemical: atlas-ph-sensor: switch regmap cache
Date: Fri, 19 Feb 2016 18:59:18 +0000 [thread overview]
Message-ID: <56C76606.2020408@kernel.org> (raw)
In-Reply-To: <CAKzfze8VfMrv4rKXthZAT_JgcOazDpXTLvvsuJpQA8q553y-xA@mail.gmail.com>
On 17/02/16 21:44, Matt Ranostay wrote:
> On Wed, Feb 17, 2016 at 1:19 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 15/02/16 15:02, Mark Brown wrote:
>>> On Sun, Feb 14, 2016 at 06:40:15PM +0100, Lars-Peter Clausen wrote:
>>>> On 02/14/2016 04:02 PM, Jonathan Cameron wrote:
>>>
>>>>> I'm lost here. Why should changing the storage of the register cache result
>>>>> in different behaviour other than in efficiency of access to cached values?
>>>
>>>> And if there is really a difference this should probably be addressed at the
>>>> regmap level.
>>>
>>> You'd need to make regcache-flat keep track of which cache values are
>>> valid either during init (in which case it'd have to read every other
>>> register at that time) or at runtime (which would mean extra operations
>>> in a fast path). Flat really is special here, there's no reason to use
>>> it over a rbtree other than being very sensitive about performance.
>>>
>>> Please also be aware that if you CC me on an iio patch series there's a
>>> good chance I'll just delete it without reading it, for some reason I
>>> keep on getting copied on lots of them which have no relevance to me
>>> that I'm able to identify.
>>>
>> Hmm. Not the best documented 'non intuitive case' ever, but fair enough.
>> Glad you did pick this one up Mark!
>>
>> So Matt, the reason those two elements are dropped from being volatile
>> is that they never were, but because we were using a flat cache it wasn't
>> getting the original values?
>>
>> If so fair enough I suppose, but please confirm that I've understood this
>> correctly + I'll probably expand the patch description somewhat to make it
>> clearer why the original was wrong.
>
> That is correct. Flat cache wasn't getting the on device value without
> it being set as volatile.
Applied to the togreg branch iio.git - initially pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
>
>
>>
>> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
prev parent reply other threads:[~2016-02-19 18:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-14 1:20 [PATCH] iio: chemical: atlas-ph-sensor: switch regmap cache Matt Ranostay
2016-02-14 15:02 ` Jonathan Cameron
2016-02-14 17:40 ` Lars-Peter Clausen
2016-02-14 19:52 ` Matt Ranostay
2016-02-15 15:02 ` Mark Brown
2016-02-17 21:19 ` Jonathan Cameron
2016-02-17 21:44 ` Matt Ranostay
2016-02-19 18:59 ` Jonathan Cameron [this message]
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=56C76606.2020408@kernel.org \
--to=jic23@kernel.org \
--cc=broonie@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=mranostay@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).