public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Bottorff <janb@os.amperecomputing.com>
To: Yann Sionneau <ysionneau@kalrayinc.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jan Dabros <jsd@semihalf.com>, Andi Shyti <andi.shyti@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i2c: designware: Fix corrupted memory seen in the ISR
Date: Wed, 13 Sep 2023 13:16:20 -0700	[thread overview]
Message-ID: <f86b6eae-15c8-4f3b-affc-f24265f3da23@os.amperecomputing.com> (raw)
In-Reply-To: <2657e064-c537-c898-668f-b5e82228ec5a@kalrayinc.com>

On 9/13/2023 4:54 AM, Yann Sionneau wrote:
> 
> On 13/09/2023 13:32, Yann Sionneau wrote:
>>
>> On 13/09/2023 13:22, Andy Shevchenko wrote:
...
>> To my knowledge the READ_ONCE()/WRITE_ONCE() only imply the use of 
>> volatile to access memory thus preventing the compiler to do weird 
>> optimizations like merging store/loads, moving store/loads, removing 
>> them etc
>>
>> They don't imply a memory barrier.
>>
>> Some systems need a memory barrier, to emit a "fence" like 
>> instruction, so that the pipeline stalls waiting for the store to 
>> "finish", for systems where the writes are posted.
>>
>> Regards,
>>
> Well, for the READ_ONCE() actually I'm wrong, it's overloaded for Alpha 
> and arm64 https://elixir.bootlin.com/linux/latest/C/ident/__READ_ONCE
>

Hi Yann,

I'll make a new submission with an improved commit message.

I looked at that ARM definition for READ_ONCE/WRITE_ONCE, and those 
didn't really look like they they addressed this kind of cross-core 
write visibility, it looked more like it was about avoiding read/write 
tearing. Read acquire and write release can sometimes replace explicit 
barrier instructions, but felt adding an explicit barrier was a simpler 
solution. If this were highly performance critical code, then the 
benefits of avoiding explicit barriers would be worth a lot more effort.

I know the ARM Barrier docs at 
https://developer.arm.com/documentation/genc007826/latest/ have an 
example under "Sending Interrupts and Barriers", page 19, that is very 
specific that a DSB barrier is required in cases where you write to 
normal memory on one core and then trigger an interrupt, and the normal 
memory is read on another core. It explicitly says that even if a memory 
write to strongly ordered memory (device memory) triggers the interrupt, 
you would need a DSB barrier. That example seemed like a very good match 
with what the DW i2c driver was doing.

I also found the video at https://www.youtube.com/watch?v=2I8OHacills 
had some useful explanations of when barriers are needed. It was a 
little puzzling in the video, it seemed to say a DMB barrier would be 
sufficient for this case, even though the ARM barrier docs say a DSB is 
needed. The DMB only stalls execution of memory accesses, the DSB stalls 
execution of all instructions. The Linux wmb macro is a DSB barrier on ARM.

Jan


      reply	other threads:[~2023-09-13 20:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13  1:03 [PATCH] i2c: designware: Fix corrupted memory seen in the ISR Jan Bottorff
2023-09-13  9:04 ` Yann Sionneau
2023-09-13 11:22   ` Andy Shevchenko
2023-09-13 11:32     ` Yann Sionneau
2023-09-13 11:54       ` Yann Sionneau
2023-09-13 20:16         ` Jan Bottorff [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=f86b6eae-15c8-4f3b-affc-f24265f3da23@os.amperecomputing.com \
    --to=janb@os.amperecomputing.com \
    --cc=andi.shyti@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jsd@semihalf.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=p.zabel@pengutronix.de \
    --cc=ysionneau@kalrayinc.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