On Wed, Feb 17, 2016 at 1:19 PM, Jonathan Cameron <jic23@xxxxxxxxxx> 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. > > Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
