On 07/18/2013 02:02 PM, Otavio Salvador wrote: > On Thu, Jul 18, 2013 at 2:50 AM, Lars-Peter Clausen <lars@xxxxxxxxxx> 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 <marex@xxxxxxx> wrote: >>>>> Dear Otavio Salvador, >>>>> >>>>>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: >>>>>>> Otavio Salvador <otavio@xxxxxxxxxxxxxxxx> 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 -- 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
