Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752425AbdLLUPi convert rfc822-to-8bit (ORCPT ); Tue, 12 Dec 2017 15:15:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:47280 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752247AbdLLUPe (ORCPT ); Tue, 12 Dec 2017 15:15:34 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A968420671 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jic23@kernel.org Date: Tue, 12 Dec 2017 20:15:30 +0000 From: Jonathan Cameron To: Stefan =?UTF-8?B?QnLDvG5z?= Cc: , Peter Meerwald-Stadler , Maciej Purski , , "Andrew F . Davis" , Lars-Peter Clausen , Hartmut Knaack , Javier Martinez Canillas Subject: Re: [PATCH v1 3/7] iio: adc: ina2xx: Remove unneeded dummy read to clear CNVR flag Message-ID: <20171212201530.3c64d47e@archlinux> In-Reply-To: <1575331.Q2WhDFQurN@pebbles> References: <20171208174152.30341-1-stefan.bruens@rwth-aachen.de> <20171210172733.4adaae77@archlinux> <1575331.Q2WhDFQurN@pebbles> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2049 Lines: 55 On Sun, 10 Dec 2017 21:53:42 +0100 Stefan Brüns wrote: > On Sunday, December 10, 2017 6:27:33 PM CET Jonathan Cameron wrote: > > On Fri, 8 Dec 2017 18:41:48 +0100 > > > > Stefan Brüns wrote: > > > Although the datasheet states the CNVR flag is cleared by reading the > > > BUS_VOLTAGE register, it is actually cleared by reading any of the > > > voltage/current/power registers. > > > > > > The behaviour has been confirmed by TI support: > > > http://e2e.ti.com/support/amplifiers/current-shunt-monitors/f/931/p/647053 > > > /2378282 > > > > > > Signed-off-by: Stefan Brüns > > > > I haven't checked the code thoroughly so there may well be something > > stopping it but have you checked the case where the only channel enabled is > > the timestamp? > > > > Obviously it makes little sense, but IIRC there is nothing in the core > > preventing that happening. > > The timestamp is completely unrelated to the status register, so I fail to > understand your question. Can you please clarify? If you only have a timestamp, the trigger will still fire (I think) but you'll do no reading at all from the device. If configured in this, admittedly odd, way you should just get a stream of timestamps with no data. > > This only removes a redundant read. The question is whether it is redundant if we have no non timestamp registers enabled. I'll be honest, whilst I can't immediately spot any protection against this in the core (and it definitely used to be possible), I'm not totally sure it now is and don't have a system to hand to test against. We had some debate a long time back on whether it made sense to have only timestamps and I think we concluded it did as you might in theory only care about the timing and not the data in some obscure cases. Jonathan > > All channel combinations (w/ and w/o timestamp) work, but combinations not > including the power register use less bus time now. > > Kind regards, > > Stefan >