All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hartmut Knaack <knaack.h@gmx.de>
To: "Stefan Wahren" <stefan.wahren@i2se.com>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Marek Vašut" <marex@denx.de>
Cc: "Kristina Martšenko" <kristina.martsenko@gmail.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	linux-iio@vger.kernel.org, jbe@pengutronix.de
Subject: Re: [PATCH] iio: mxs-lradc: check ranges of ts properties
Date: Sat, 29 Nov 2014 19:47:06 +0100	[thread overview]
Message-ID: <547A14AA.6020405@gmx.de> (raw)
In-Reply-To: <10217382.467571.1417260127187.JavaMail.open-xchange@oxbaltgw07.schlund.de>

Stefan Wahren schrieb am 29.11.2014 um 12:22:
> Hi Hartmut,
> 
>> Hartmut Knaack <knaack.h@gmx.de> hat am 29. November 2014 um 00:28
>> geschrieben:
>>
>>
>> Fabio Estevam schrieb am 19.11.2014 um 23:42:
>>> [Adding Marek]
>> Taking a closer look on how these values are used, I wondered what the real
>> value range of the registers actually are. So, anyone with access to the data
>> sheets, please confirm.
> 
> the reference manual is public:
> 
> http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
Thanks.
> 
>> Starting with over_sample_cnt, which according to the DT bindings has a range
>> of 1...31. In mxs_lradc_setup_ts_channel(), currently line 429, the value
>> decreased by one (0...30) gets written to register 0x50 (+ 0x10 for each
>> channel) to bits 24-29. Question: What is the right value range there, 0...30
>> or 0...31?
> 
> Yes, looks like an off-by-one issue. The register range is 0..31 so i would
> assume the DT property range should be logically 1..32. But i don't have checked
> the reference manual about that.
It's NUM_SAMPLES with the description: "This bit field contains the number of conversion cycles to sum together before reporting operation
complete interrupt status. Set this field to zero for a single conversion per interrupt."
So, a range of 0...31 can be assumed.
> 
>> In the same function, line 440, the value decreased by one (0...30) is written
>> to register 0x100 into bits 11-15. Same question here: What is the right value
>> range?
It's LOOP_COUNT with the description: "This bit field specifies the number of times this delay counter will count down and then trigger its
designated targets. This is particularly useful for scheduling multiple samples of an LRADC channel set. If
this field is set to 0x0, then exactly one delay loop will be generated with exactly one event triggering the
target LRADC and/or delay channels."
So, the range is also 0...31.
>> The same behavior can be found in mxs_lradc_setup_ts_pressure() in lines 485
>> and 498.
>> For over_sample_delay, the DT bindings state a range of 1...2047. In
>> mxs_lradc_setup_ts_channel(), line 440, the value decreased by one (0...2046)
>> is written to register 0x100, bits 0-10. Question: which value range is valid
>> there? The same happens in line 498.
It's DELAY with the description: "This 11-bit field counts down to zero. At zero it triggers either a set of LRADC channel conversions or
another delay channel, or both. It can trigger up to all eight LRADCs and all four delay channels in a single
event. This counter operates on a 2KHz clock derived from crystal clock."
So, the range is 0...2047.
>> For settling_delay, the DT bindings state a range of 1...2047. In
>> mxs_lradc_setup_ts_channel(), line 458, that value is written to register
>> 0xf0, bits 0-10. Question: what value range is valid here, 1...2047 or
>> 0...2047? The same happens in line 517.
This is the same as register 0x100, so 0...2047 is the valid range.
Stefan, would you mind to change the DT documentation while you are on it?
>> Thanks,
>>
>> Hartmut
>>>
> 
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2014-11-29 18:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-19 22:19 [PATCH] iio: mxs-lradc: check ranges of ts properties Stefan Wahren
2014-11-19 22:42 ` Fabio Estevam
2014-11-22 12:02   ` Jonathan Cameron
2014-11-28 23:28   ` Hartmut Knaack
2014-11-29 11:22     ` Stefan Wahren
2014-11-29 18:47       ` Hartmut Knaack [this message]
2014-11-30 12:10         ` Kristina Martšenko
2014-11-30 13:29           ` Stefan Wahren
2014-12-08 19:40             ` Stefan Wahren
2014-12-12 11:38               ` Jonathan Cameron
2014-11-28 22:47 ` Hartmut Knaack
2014-11-29 11:06   ` Stefan Wahren
2014-11-29 18:14     ` Hartmut Knaack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547A14AA.6020405@gmx.de \
    --to=knaack.h@gmx.de \
    --cc=festevam@gmail.com \
    --cc=jbe@pengutronix.de \
    --cc=jic23@kernel.org \
    --cc=kristina.martsenko@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=stefan.wahren@i2se.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.