Linux-IIO Archive on lore.kernel.org
 help / color / Atom feed
From: Andrea Merello <andrea.merello@gmail.com>
To: Couret Charles-Antoine <charles-antoine.couret@essensium.com>
Cc: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"jic23@kernel.org" <jic23@kernel.org>,
	"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
	"knaack.h@gmx.de" <knaack.h@gmx.de>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 0/4] Fixes for ad7949
Date: Mon, 16 Sep 2019 09:34:38 +0200
Message-ID: <CAN8YU5PtmC9QQCmSb1uDXMK+WVQ6Lfihijs1c0zRkr568GrdXg@mail.gmail.com> (raw)
In-Reply-To: <2b7ab6c3-6ff6-69b5-bbd4-f8a1966b6b57@essensium.com>

Il giorno ven 13 set 2019 alle ore 16:00 Couret Charles-Antoine
<charles-antoine.couret@essensium.com> ha scritto:

>
> For patch 3, I didn't use delay_usecs fiels due to the timings
> definition in the datasheet in "READ/WRITE SPANNING CONVERSION WITHOUT A
> BUSY INDICATOR" mode. During the delay, the chip select line must be
> released which is not the case when we use delay_usecs field. So I add
> the delay instruction after the write step to be compliant with these
> timings.

Ok, you are right, thank you for pointing this out..

It looks like that, for my original intent of being strict about
acquisition time and conversion time (as per my original
interpretation), both delays (before and after) CS change would be
needed.. But since Alexandru pointed out that the single 2uS delay, as
per current implementation, should be OK for the A/D chip, then I'd
drop patch 3/4.

> For patch 4, I explained a bit in the other thread. Maybe we have a
> difference of behaviour due to the choice of the timings "modes"?

I don't know.. is it "RAC" the intended working mode? If you want I
can take some snapshot of scope images and share them..

>
> BTW, from my point of view the datasheet is not totally clear about the
> timings and what is mandatory or not in the expected behaviour.

I agree with you that datasheet is not so clear about timings..
However I think it makes it pretty clear that we need the extra
transfer in order to make sure that the read data is correct (except
if the CFG doesn't change).

IMO that's could be evinced by both diagrams (all modes I think) and
by the following sentence in "READING/WRITING AFTER CONVERSION, ANY
SPEED HOSTS" paragraph: "When reading/writing after conversion, or
during acquisition(n), conversion results are for the previous (n − 1)
conversion, and writing is for the (n + 1) acquisition".

I interpret this as follows:
- You write a new CFG in cycle n, you get (and discard) data for cycle
n-1, and the new CFG will be used for next _acquisition_.
- Once you release the CS (you finished to write) the conversion for
the _currently_ acquired data (old cfg) starts. Once the A/D finishes
the conversion, the acquisition starts with the new CFG
- You read data, and the A/D returns results from the last
_conversion_ that has been done, which is still related to the old
configuration. Once you release the CS (finish to read) the conversion
for the currently acquired data - which is now the one with the new
CFG - is started.
- Finally you read the result of the above conversion

So IMO we really need three cycles to read from a random channel


> Regards,
>
> Charles-Antoine Couret
>

      parent reply index

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 14:43 Andrea Merello
2019-09-12 14:43 ` [PATCH 1/4] iio: ad7949: kill pointless "readback"-handling code Andrea Merello
2019-09-13  6:37   ` Ardelean, Alexandru
2019-09-15 10:26     ` Jonathan Cameron
2019-09-12 14:43 ` [PATCH 2/4] iio: ad7949: fix incorrect SPI xfer len Andrea Merello
2019-09-13  6:46   ` Ardelean, Alexandru
2019-09-13  7:56     ` Andrea Merello
2019-09-13  8:28       ` Ardelean, Alexandru
2019-09-15 10:36       ` Jonathan Cameron
2019-09-16  7:51         ` Ardelean, Alexandru
2019-09-21 17:16           ` Jonathan Cameron
2019-09-12 14:43 ` [PATCH 3/4] iio: ad7949: fix SPI xfer delays Andrea Merello
2019-09-13  6:59   ` Ardelean, Alexandru
2019-09-13  8:23     ` Andrea Merello
2019-09-13  8:43       ` Ardelean, Alexandru
2019-09-12 14:43 ` [PATCH 4/4] iio: ad7949: fix channels mixups Andrea Merello
2019-09-13  7:19   ` Ardelean, Alexandru
2019-09-13  8:30     ` Andrea Merello
2019-09-13 11:30       ` Couret Charles-Antoine
2019-09-13 11:40         ` Andrea Merello
2019-09-20  7:45         ` Andrea Merello
2019-09-21 17:12           ` Jonathan Cameron
2019-09-23  8:21             ` Andrea Merello
2019-10-05  9:55               ` Jonathan Cameron
     [not found]                 ` <CAN8YU5PRO5Y5EeEj2SZGm5XfuKSB1rtS7nKdu6wWxXYDOfexqw@mail.gmail.com>
2019-10-22  8:56                   ` Jonathan Cameron
2019-11-04 14:12                     ` Andrea Merello
2019-11-09 11:58                       ` Jonathan Cameron
2019-11-12 15:09                       ` Couret Charles-Antoine
2019-12-02 14:13                         ` [v2] " Andrea Merello
2019-12-02 15:36                           ` Couret Charles-Antoine
2019-12-04 11:06                             ` Jonathan Cameron
2019-12-04 11:13                               ` Couret Charles-Antoine
2019-12-06 16:45                                 ` Jonathan Cameron
2019-09-13  7:24 ` [PATCH 0/4] Fixes for ad7949 Ardelean, Alexandru
2019-09-13 14:00   ` Couret Charles-Antoine
2019-09-15 10:49     ` Jonathan Cameron
2019-09-16  7:39       ` Andrea Merello
2019-09-16  7:48         ` Ardelean, Alexandru
2019-09-16  7:50           ` Ardelean, Alexandru
2019-09-16  7:34     ` Andrea Merello [this message]

Reply instructions:

You may reply publically 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=CAN8YU5PtmC9QQCmSb1uDXMK+WVQ6Lfihijs1c0zRkr568GrdXg@mail.gmail.com \
    --to=andrea.merello@gmail.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=alexandru.Ardelean@analog.com \
    --cc=charles-antoine.couret@essensium.com \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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

Linux-IIO Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-iio/0 linux-iio/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iio linux-iio/ https://lore.kernel.org/linux-iio \
		linux-iio@vger.kernel.org
	public-inbox-index linux-iio

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-iio


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git