linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 


      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).