mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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