From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vignesh R Subject: Re: [PATCH 0/2] iio: ti_am335x_adc: Add optional DT properties for tscadc Date: Wed, 13 May 2015 13:11:45 +0530 Message-ID: <55530039.3020601@ti.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Hannes Petermaier Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dmitry Torokhov , fcooper-l0cyMroinI0@public.gmane.org, Kumar Gala , "ijc,_O=+devicetree"@hellion.org.uk, JanKardelljan.kardell-5O2GiQo/Ci2aMPzRcYMCawC/G2K4zDHf@public.gmane.org List-Id: devicetree@vger.kernel.org Hi Hannes, On Wednesday 29 April 2015 10:36 AM, Hannes Petermaier wrote: > Hi Vignesh, > > any comments on this ? > I didn't hear anything last 2 weeks from you. Apologies... For some reason my mail client classified your reply mails as junk, hence I never look into it. I agree that making SEL_INM_SWC_3_0, SEL_RFM_SWC_1_0 and SEL_RFP_SWC_2_0 configurable is good to have. But I don't think I will be able to work on it anytime sooner. Regards Vignesh > > best regards, > Hannes > > ----- Forwarded by Hannes Petermaier/Eggelsberg/AT/B&R on 29.04.2015 07:03 > ----- > >> From: Hannes Petermaier/Eggelsberg/AT/B&R >> To: Vignesh R >> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dmitry Torokhov > , >> fcooper-l0cyMroinI0@public.gmane.org, Kumar Gala , Ian Campbell> +devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>, Jan Kardell , > Johannes >> Pointner , Hartmut Knaack >> , Karol Wrona , Lars-Peter Clausen > >> , linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, > linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, >> Mark Rutland , Pawel Moll , > Peter >> Meerwald , Rob Herring >> Date: 15.04.2015 07:33 >> Subject: Re: [PATCH 0/2] iio: ti_am335x_adc: Add optional DT properties > for tscadc >> >>> Hi Hannes, >> Hi Vignesh, >> thanks for answer. >> >>>>> >>>>> would it be possible to add some more channel-specific settings ? >>>>> >>>>> It would be nice to have allmost full control to the STEPCONFIGx >>>> register. >>>>> >>>>> At least we need to write the bits >>>>> >>>>> SEL_RFM_SWC_1_0 >>>>> SEL_INM_SWC_3_0 >>>>> SEL_RFP_SWC_2_0 >>>>> >>>>> In the current mainline version only (SEL_INP_SWC_3_0) is written. >>>>> So for the other bits "0" is value is used, for my point of view > this is >>>> not correct. >>>>> >>>>> For example if we want to read a value from AIN5 the negative pin > from >>>> adc is >>>>> muxed allways to AIN0. >>> >>> Sorry... I didn't understand what you meant by"AIN5 is muxed always > with >>> AIN0"? >> Have a look to the TRM (spruh73k.pdf) Page 1740 / Figure 12-2. > Functional Block Diagram. >> There you can see that the ADC-cell which has two inputs, one positive > and onenegative. >> Also there are two reference inputs, one positive - one negative. >> >> All this "pins" are muxed, because only one channel per time can be > sampled. >> This muxes are controlled through the STEPCONFIGx registers. >> >> If you want for example take some measurement from AIN5 the driver muxes > the >> positive input from the ADC to AIN5 by setting the bits for SEL_INP<3:0> > - this is ok. >> But the bits for SEL_INM<3:0> are still 'zero'. >> In summary this results in following mux-setting (regarding page 1771 in > TRM): >> >> positive-reference muxed to VDDA >> negative-reference muxed to VSSA >> positive-input muxed to AIN5 >> negative-input muxed to AIN0 >> >> From this setup we run into 2 problems: >> - the negative input terminal is muxed maybe to wrong potential >> In much cases we have a single-ended signal so this setup looks good at > first, >> because the "Diff_CNTRL" bit is also false. >> In fact there is an influence to the reading if the negative > input-terminal >> isn't setup correctly (to VSSA or REFN). >> Maybe i interpret the "Diff_CNTRL" not correctly, there is no detailed >> description within the TRM - maybe some of your workmates can explain > you the >> functionality of this bit. >> >> - reference is allways taken from VDDA/VSSA >> For a precision measurement you dont't use in normal case the > analog-supply. >> This rail brings noise, drift - all things whicht we don't need for > accurate >> measurement. >> >>> >>>>> In fact i can readout heavy jitter even if AIN5 is connected to > ground - >>>> after >>>>> setting up negative adc pin within code (to use REFN) the readout > value >>>> is 0 >>>>> as expected without nameable jitter. >>>>> If i short AIN0 also to ground, jitter is also eliminated. >>> >>> Hmmm... nobody has reported such behavior before. ADC support for >>> am335x-evm/beaglebone has been there for quite long time, but nobody >>> reported any jitter on AIN5 line. I think this may be specific to >>> your setup. Can you provide more info with regard to your setup? >>> Which kernel? Is it am335x-evm or beaglebone or a custom board? >> Maybe nobody does some precision measurement with beaglebone. >> For operating some touchscreen or readout a potentiometer for evaluation > >> purpose it is still good enough. >> >> Kernel is current mainline, 4.0 >> Board is some custom board of my company. >> But all this parameters shouldn't have some influence to the case. >> >>>>> >>>>> Maybe this is also some fault of TI SoC ... in normal case somebody > >>>> could >>>>> expect, that negative adc pin is equal even the Diff_CNTRL bit > isn't set >>>> - but >>>>> in practice it isn't. >>>>> >>>>> Also actually it isn't possible to make some accurate measurement > due to >>>> the >>>>> fact that allways VDDA_ADC is used as positive reference. >>>>> >>>>> So it would be nice to have control around this bits. >>>>> Whats your opinion around that? >>> >>> Sorry, I am not yet clear on your bug/use-case. >>> >>> Please comment inline while replying on mailing list >> okay so ? >> >>> Regards >>> Vignesh >> best regards, >> Hannes >> >> > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html