From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752570AbdLLPNX (ORCPT ); Tue, 12 Dec 2017 10:13:23 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:2672 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752464AbdLLPNV (ORCPT ); Tue, 12 Dec 2017 10:13:21 -0500 Date: Tue, 12 Dec 2017 15:12:32 +0000 From: Jonathan Cameron To: Quentin Schulz CC: Jonathan Cameron , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 2/8] iio: adc: axp20x_adc: add support for AXP813 ADC Message-ID: <20171212151232.00006fd0@huawei.com> In-Reply-To: References: <20171210163655.43fbd3c0@archlinux> Organization: Huawei X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.206.48.115] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 11 Dec 2017 09:18:55 +0100 Quentin Schulz wrote: > Hi Jonathan, > > On 10/12/2017 17:36, Jonathan Cameron wrote: > > On Mon, 4 Dec 2017 15:12:48 +0100 > > Quentin Schulz wrote: > > > >> The X-Powers AXP813 PMIC is really close to what is already done for > >> AXP20X/AXP22X. > >> > >> There are two pairs of bits to set the rate (one for Voltage and Current > >> measurements and one for TS/GPIO0 voltage measurements) instead of one. > > > > This would normally imply we need to split the device into two logical > > IIO devices. However, that only becomes relevant if we are using > > buffered output which this driver doesn't support. > > > It'll be nasty to deal with this if we add that support down the line > > though. Up to you though as it's more likely to be your problem than > > anyone else's :) > > > > I have no plans for supporting buffered output for the AXPs at the > moment. But that's an interesting (and important) limitation to raise. > Wouldn't be more of a hack to have two IIO devices representing the > actual same IP? We have thought about allowing multiple buffers from a single IIO device but that makes for some horrible changes to the ABI - so as things stand the only option is two devices for one IP. Ultimately they aren't really two devices - in the same way we have triggers separating registered on the IIO bus (often many of them). Just two different elements of the same IP. > > > For now you could elect to support the different sampling frequencies > > if you wanted to but just providing controls for each channel. > > > > I guess that you're offering to use IIO_CHAN_INFO_SAMP_FREQ in > info_mask_separate for each channel? Yes > > > Given the driver doesn't currently expose these at all (I think) > > this is all rather immaterial ;) > > I'm not giving the user the option to chose the sampling frequency for > now. I have no plans to do it either, but I think it would be rather > simple to later add support for setting frequency sampling since we only > need to add a sysfs entry (with IIO_CHAN_INFO_SAMP_FREQ) that does not > exist yet. Don't you think? Am I missing something? No should be straight forward as long as we keep clear of the buffered interfaces with their limitations. > > Thanks, > Quentin