From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751071AbdAQK2m (ORCPT ); Tue, 17 Jan 2017 05:28:42 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:49411 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbdAQK2k (ORCPT ); Tue, 17 Jan 2017 05:28:40 -0500 Date: Tue, 17 Jan 2017 11:28:01 +0100 From: Andreas Klinger To: Jonathan Cameron Cc: knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, ktsai@capellamicro.com, wsa@the-dreams.de, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, trivial@kernel.org, mranostay@gmail.com, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger Message-ID: <20170117102801.GB7823@andreas> References: <20170110184815.GA15532@andreas> <4099feac-959c-2b5b-a21a-3b111098af39@kernel.org> <20170114174856.GA2351@andreas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:EExv0DwD5VWwSG8yqlMCXc8LtIvAVjNK9kmGTMtxtjkIM/mxpMs o3h8mjkCm5/HUZHrynSMKnKGAf+BPoLaDVgw9n9p/ttUfVuVHplN1oEctVledbldPlgJznM TeDhH3H/LQ9e/uFvGZQcpnNJxBJFF3ocSVDpyw7x/AMTtdCMY+5tn+7OEUuBbHl8iIlH+h+ sE3UF8EGYKW2kNgCWNA1g== X-UI-Out-Filterresults: notjunk:1;V01:K0:vFluBJ4yjBI=:gqyWHSsMQqTpWwaLdHCxbT ARPTGfJLYXWOwXZm8bWGDrB+1KbsyHwIAZe3M6PYpJVDciHnmiPhl40pEOEZGJLdfqWliplH+ wmbqvIPXhbyiRFqrsCOOEv1yaWYY8vPSGx5YQEPiLjaonZDPIhUOAj9k08Pg45elv9gGzyDRl hf8x7/VHQ9pkC8ljXZ3ZI6L1BlwxZUJ0rvmm7u59UoXcCAY+gA8H9UYxkYUFDRrcK3puL2akc Z28Xg+uVi9mZCkYzdV2fVLvdpxBWMW8hJxj6SySetGhTvGfoYWBt0PS9D55rMFor12y/ZypZr ygd64QZq5dMeXid4RDG7T49GKt14+86ELAYQa4kBWVUe1PSAr1iXzk6cSqma7g/M3YwMjWnjk iDC2zsNAy+qAIcFHVoqBpogdl/7kYq92sjXiKqKLDL8u45dU980uGBoIAxl3ojbcSfcbCRzaJ evz1yAaxUTXA52gArNVH4x7ihPsrewODVxa+pldbWVSs1+jz8+Tie239jzW3DjXSW6GSUrG1d vKfN7qAjgjmIxJ9bZ6VPyFFM6s6vP22Wir+ZZxngGkz82mj9TmYL2+2wiiTBF9Q+o296WMrXV Lq2M5O3emEe2i4XZdbqsSFlaMAhbweG4t24o8fhh1Q/j7TyFYgu9P+FuighdnsyXLkROXdkAd lDr7e91VDa1US0M0hROCqSvT5EV2VkIKoNrI4+5TPAjFxf7SB+J7BjzVgiP65pGka4c0= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jonathan, [...] > >> For the range, it's an interesting one. Again the term range could > >> mean too many things within the wider ABI. We need to make it more > >> specific. > >> > >> Actually reading the datasheet, I think this is fundamentally about the > >> maximum sampling frequency rather than directly about the range. > >> The only reason you'd reduce the range is to speed that up. It doesn't > >> improve the resolution, the device simply answers quicker. > >> > >> So I'd support this as sampling_frequency. You could then use > >> the the iio_info_mask_*_available and relevant callback to provide > >> info on what it then restricts the possible output values to > >> (rather than controlling it directly). > >> > > > > By changing the range one cannot influence the sampling frequency directly. I > > have seen on the oszilloscope that the telegrams arrive almost at the same time > > with different settings of range and the same gain. > > > > Only if the gain is also adjusted the sensor works faster and a higher frequency > > can be used. But the gain is also used to adjust the sensitivity of the sensor. > That's rather weird and not what the datasheet suggests. Ah well. > > > > What about calling it "sensor_domain" or "sensor_max_range"? > hmm. Not sure - propose that with appropriate Docs and we can think more on it. > > > > I made a mistake in the earlier mentioned measurement which i have to correct: The telegrams arrive faster with a smaller range and the same gain. But we cannot use the sensor at a higher frequency if we are not adjusting the gain of the sensor as well. This is because of echos of the former cycle which are still around. And this setting of the gain depends on the surrounding where the sensor is used. So in the driver we cannot estimate it. Therefore i'll send out the next version with the attribute name "sensor_max_range" together with documentation as proposal. Andreas --