From: Jonathan Cameron <jic23@kernel.org>
To: "Hennerich, Michael" <Michael.Hennerich@analog.com>
Cc: "zzzzArdelean, zzzzAlexandru" <alexandru.Ardelean@analog.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"lars@metafoo.de" <lars@metafoo.de>,
"Sa, Nuno" <Nuno.Sa@analog.com>,
"Bogdan, Dragos" <Dragos.Bogdan@analog.com>
Subject: Re: [PATCH v3 0/6] iio: Add output buffer support
Date: Sat, 6 Mar 2021 17:34:49 +0000 [thread overview]
Message-ID: <20210306173449.06f2f32b@archlinux> (raw)
In-Reply-To: <BN8PR03MB497724AAAFA43E6555554DC98E969@BN8PR03MB4977.namprd03.prod.outlook.com>
On Fri, 5 Mar 2021 08:57:08 +0000
"Hennerich, Michael" <Michael.Hennerich@analog.com> wrote:
> Hi Jonathan and others,
>
> With output/dac buffer support the semantics of the scan_element type may change.
>
> Today the Format is [be|le]:[s|u]bits/storagebitsXrepeat[>>shift].
>
> While shift (if specified) is the shift that needs to be applied prior to masking out unused bits.
>
> So far so good and it sounds universal.
>
> However, we use the right shift (operator) for that, which makes sense for capture devices.
> For output devices the more logical operator would be the left shift.
>
> I'm not proposing a new Format here. I just want to get some agreement that for an output device
>
> le:s12/16>>4
>
> is understood as a left shift of 4, since the unused bits are then on the LSB.
Good question. Guess I wasn't thinking ahead when I came up with that :)
I'm not sure I'd mind if we did decide to define a new format for output
buffers. Feels like it should be easy to do.
What do others think?
Jonathan
>
> Thoughts?
>
> Best Regards,
> Michael
>
> Analog Devices GmbH
> Michael Hennerich
> Otl-Aicher Strasse 60-64
> D-80807 Muenchen; Germany
>
> Sitz der Gesellschaft München, Registergericht München HRB 40368,
> Geschäftsführer: Stefan Steyerl, Michael Paul Sondel, Yoon Ah Oh
>
>
next prev parent reply other threads:[~2021-03-06 17:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 12:40 [PATCH v3 0/6] iio: Add output buffer support Alexandru Ardelean
2021-02-19 12:40 ` [PATCH v3 1/6] " Alexandru Ardelean
2021-02-19 12:40 ` [PATCH v3 2/6] iio: kfifo-buffer: " Alexandru Ardelean
2021-02-19 12:40 ` [PATCH v3 3/6] iio: triggered-buffer: extend support to configure output buffers Alexandru Ardelean
2021-02-19 12:40 ` [PATCH v3 4/6] iio: buffer-dma: Allow to provide custom buffer ops Alexandru Ardelean
2021-02-19 12:40 ` [PATCH v3 5/6] iio: buffer-dma: Add output buffer support Alexandru Ardelean
2021-02-19 12:40 ` [PATCH v3 6/6] iio: buffer-dma: add support for cyclic DMA transfers Alexandru Ardelean
2021-02-21 12:09 ` Jonathan Cameron
2021-02-23 6:34 ` Alexandru Ardelean
2021-02-21 12:01 ` [PATCH v3 0/6] iio: Add output buffer support Jonathan Cameron
2021-03-05 8:57 ` Hennerich, Michael
2021-03-06 17:34 ` Jonathan Cameron [this message]
2021-03-08 10:07 ` Sa, Nuno
2021-03-08 11:52 ` Jonathan Cameron
2021-03-08 13:00 ` Sa, Nuno
2021-03-08 13:17 ` Sa, Nuno
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=20210306173449.06f2f32b@archlinux \
--to=jic23@kernel.org \
--cc=Dragos.Bogdan@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=Nuno.Sa@analog.com \
--cc=alexandru.Ardelean@analog.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.