[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a2b49fb-8e2c-ff76-4743-08f8d6a8d5e9@axentia.se>
Date: Tue, 3 Apr 2018 10:37:44 +0200
From: Peter Rosin <peda@...ntia.se>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Boris Brezillon <boris.brezillon@...tlin.com>,
Josh Wu <rainyfeeling@...look.com>,
Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
linux-kernel@...r.kernel.org,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Marek Vasut <marek.vasut@...il.com>,
linux-mtd@...ts.infradead.org, Richard Weinberger <richard@....at>,
Brian Norris <computersforpeace@...il.com>,
David Woodhouse <dwmw2@...radead.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using
dma
On 2018-04-03 09:18, Alexandre Belloni wrote:
> On 02/04/2018 at 22:23:17 +0200, Peter Rosin wrote:
>>>> No, but did it again and checked, see transcript below.
>>>
>>> I don't use devmem2. Is 'readback' information accurate or is it
>>> always what's been written? Because when you write 0x33 to 0xFFFFECBC,
>>> 0x33 is read back, but just after that, when you read it again it's 0.
>>
>> Looking at the devmem2 source, it seems very likely that the compiler
>> optimizes out the read and thus outputs what has been written.
>>
>
> At least on x86, it is not optimized out.
Looking at the disassembly, they are gone here (not that I'm fluent).
I then tried to compile devmem2 with -O0 (instead of -Os) and the read
is then fine. So, I guess the devmem2 devs could claim that it's a
buildroot issue, but a volatile would certainly have helped...
Cheers,
Peter
Powered by blists - more mailing lists