From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Jan Kiszka <jan.kiszka@siemens.com>
Cc: linux-iio@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sascha Weisenberger <sascha.weisenberger@siemens.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v3] iio: adc: Add support for TI ADC108S102 and ADC128S102
Date: Sun, 7 May 2017 12:17:24 +0100 [thread overview]
Message-ID: <65e819ec-0723-cd10-7546-09ee50434762@kernel.org> (raw)
In-Reply-To: <1494011349.30052.42.camel@linux.intel.com>
On 05/05/17 20:09, Andy Shevchenko wrote:
> On Fri, 2017-05-05 at 19:55 +0100, Jonathan Cameron wrote:
>> On 05/05/17 07:31, Jan Kiszka wrote:
>
>>> +
>>> + /*
>>> + * SPI message buffers:
>>> + * tx_buf: |C0|C1|C2|C3|C4|C5|C6|C7|XX|
>>> + * rx_buf: |XX|R0|R1|R2|R3|R4|R5|R6|R7|tt|tt|tt|tt|
>>> + *
>>> + * tx_buf: 8 channel read commands, plus 1 dummy command
>>> + * rx_buf: 1 dummy response, 8 channel responses, plus 64-
>>> bit timestamp
>>> + */
>>> + __be16 rx_buf[13]
>>> ____cacheline_aligned;
>>> + __be16 tx_buf[9]
>>> ____cacheline_aligned;
>>
>> I would have thought the SPI dma wouldn't take itself out so you
>> should be
>> good with just the one cacheline_aligned? Maybe I'm missing
>> something.
>
> It was my idea for sake of consistency. Just to explicitly show that
> buffers a cache aligned.
>
> If you insist to remove one, it's your call at the end ;-)
>
As far as I know the only reason the 'need' to be cacheline aligned
is to avoid corruption issues if any other elements sharing the
cacheline (ie.earlier elements in our structure) change whilst the
dma is progress. Doesn't matter if the second is also so aligned
as we should only have one dma type transfer going on at a time
(plenty of locking in spi to ensure this).
It's not a big point though so doesn't really matter as it is
safe either way!
Jonathan
prev parent reply other threads:[~2017-05-07 21:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 6:31 Jan Kiszka
2017-05-05 9:40 ` Mika Westerberg
2017-05-05 10:23 ` Jan Kiszka
2017-05-05 10:40 ` Mika Westerberg
2017-05-05 18:50 ` Jonathan Cameron
2017-05-05 9:54 ` Andy Shevchenko
2017-05-05 10:39 ` Jan Kiszka
2017-05-05 18:52 ` Jonathan Cameron
2017-05-05 20:09 ` Jan Kiszka
2017-05-05 20:32 ` Andy Shevchenko
2017-05-07 11:19 ` Jonathan Cameron
2017-05-05 18:55 ` Jonathan Cameron
2017-05-05 19:09 ` Andy Shevchenko
2017-05-07 11:17 ` Jonathan Cameron [this message]
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=65e819ec-0723-cd10-7546-09ee50434762@kernel.org \
--to=jic23@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=jan.kiszka@siemens.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=pmeerw@pmeerw.net \
--cc=robh@kernel.org \
--cc=sascha.weisenberger@siemens.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome