All of lore.kernel.org
 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 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.