From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-165.synserver.de ([212.40.185.165]:1033 "EHLO smtp-out-165.synserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394Ab3GRNxV (ORCPT ); Thu, 18 Jul 2013 09:53:21 -0400 Message-ID: <51E7F37B.4050803@metafoo.de> Date: Thu, 18 Jul 2013 15:54:03 +0200 From: Lars-Peter Clausen MIME-Version: 1.0 To: Otavio Salvador CC: Marek Vasut , Jonathan Cameron , linux-iio@vger.kernel.org, Mario Goulart Subject: Re: ADC setting for differential and single-ended channels References: <201307180531.02207.marex@denx.de> <201307180608.09345.marex@denx.de> <51E78230.8070602@metafoo.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org On 07/18/2013 02:02 PM, Otavio Salvador wrote: > On Thu, Jul 18, 2013 at 2:50 AM, Lars-Peter Clausen wrote: >> On 07/18/2013 06:08 AM, Marek Vasut wrote: >>> Dear Otavio Salvador, >>> >>>> On Thu, Jul 18, 2013 at 12:31 AM, Marek Vasut wrote: >>>>> Dear Otavio Salvador, >>>>> >>>>>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron wrote: >>>>>>> Otavio Salvador wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Mario and I are working at TI ADS124x driver and this chip can be used >>>>>>>> in two ways: >>>>>>>> >>>>>>>> In case of ADS1247: >>>>>>>> - 2 differential channels >>>>>>>> - 3 single-ended channels >>>>>>>> >>>>>>>> In the first case it take two inputs and the chip returns the >>>>>>>> difference between them; in the second case it does the same but you >>>>>>>> must choose one channel to be the negative reference for all the other >>>>>>>> inputs. This is how we understood the datasheet however the >>>>>>>> single-ended use is quite confusing on it so we might be wrong. >>>>>>>> >>>>>>>> So we'd like to know the best way to handle those cases in the driver. >>>>>>>> >>>>>>>> One alternative we discussed is to use two attributes in the dts as: >>>>>>>> ... >>>>>>>> #channels = <2>; >>>>>>>> channels = <0 3 >>>>>>>> >>>>>>>> 1 2>; >>>>>>>> >>>>>>>> So it'd take two channels. One composed by input 0 and input 3 and >>>>>>>> another composed by input 1 and input 2. >>>>>>>> >>>>>>>> On the another case, we'd use: >>>>>>>> ... >>>>>>>> #channels = <3> >>>>>>>> channels = <0 3 >>>>>>>> >>>>>>>> 1 3 >>>>>>>> 2 3>; >>>>>>>> >>>>>>>> So it'd take three channels and all them comparing to input 3. >>>>>>>> >>>>>>>> Are we in the right route? Any hints how to better solve this? >>>>>>>> >>>>>>> Another option is to leave it entirely up to user space. See max1363 >>>>>>> driver where both single ended and differential channels are supported >>>>>>> at the same time with care taken in buffered mode. >>>>>>> >>>>>>> Not sure if that works for your case? >>>>>> >>>>>> I think it is nicer to have it set in the dt; we need the dt anyway so >>>>>> it seems logical to get it setting the right channel. >>>>> >>>>> Can you please elaborate why is it logical? >>>>> >>>>> I took a brief look over the datasheet [1], here are the facts I see >>>>> (correct me if I'm wrong). I first looked at Figure 51. : >>>>> >>>>> - ADS1246 has two input channels >>>>> - ADS1247 has four input channels >>>>> - ADS1428 has eight input channels >>>>> >>>>> - Each one of the 2/4/8 input channels can be connected to either P(+) or >>>>> N(-) of the amplifier (figure 53) for the ADC. >>>>> >>>>> - Apparently, according to Figure 51. , it is possible to have only one P >>>>> and one N channel enabled at time (and therefore sample only one pair of >>>>> channels with the ADC) since the P and N rails are shared by all the >>>>> inputs and there's only one ADC block. >>>>> >>>>> Therefore, the userland would have to export sysfs file for each of the >>>>> channels where one would write if the channel is possitive(+) / >>>>> negative(-) / not_connected(NC) and then trigger the start of sampling. >>>>> >>>>> What do you think? >>>> >>>> This does not make them act as differential against each other. >>>> >>>> We can have several combinations as: >>>> >>>> 0 - P / 1 - N (differential) >>>> 0 - P / 1 - P / 2 - P / 3 - N (all differential to 3) >>>> and so on. >>>> >>>> So how userland would tell which would be the differential to use? >>>> >>>> Our board has: >>>> >>>> 0 against 1 >>>> 2 against 3 >>>> >>>> but it is a design choice. >>>> >>>> Am I missing something? >>> >>> echo 'P' > /sys/.../chan_mux_0 >>> echo 'P' > /sys/.../chan_mux_2 >>> echo 'N' > /sys/.../chan_mux_1 >>> echo 'N' > /sys/.../chan_mux_3 >>> >>> Like this for example ;-) And this could be nicely implemented via IIO, but I >>> believe there might even already be an IIO API for this stuff. >> >> Well the standard API as Jonathan said is to expose all possible pin >> combinations. In this case that might be up to 8x8=64 channels. In my >> opinion that's fine, but on a specific board maybe not all combinations are >> valid. So you might want to specify in your platform data or devicetree that >> only a subset of these 64 channels is valid and should be exposed to >> userspace. In my opinion it makes the most sense to handle this in the IIO >> core since this is a generic requirement, nothing specific to this chip. >> E.g. even for 'simple' converters you'll find situations where some pins >> might not be connected. > > Right and how should we do this? > > Because it would not be 8x8 but it has also the single-ended > combinations (using different N inputs). Does the device really support single ended, it looks to me as if it only supports pseudo-differential configurations. > > So in the end, it'd have a huge number of channels in sysfs where only > few would be used. This seems confusing for user from my POV. > > You said about handle this pins to be exposed in IIO core, does IIO > already provide support for it? No unfortunately not, but as I said, this is not a device specific requirement and thus we should find a way to handle this generically in the IIO core. - Lars