From: "Arnd Bergmann" <arnd@arndb.de>
To: "Valentin Korenblit" <vkorenblit@sequans.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>
Cc: "kernel test robot" <lkp@intel.com>,
llvm@lists.linux.dev, kbuild-all@lists.01.org,
linux-kernel@vger.kernel.org
Subject: Re: [mtd:nand/next 11/31] drivers/mtd/nand/raw/cadence-nand-controller.c:1893:4: error: implicit declaration of function 'ioread64_rep' is invalid in C99
Date: Tue, 27 Sep 2022 22:02:39 +0200 [thread overview]
Message-ID: <e0a3bc54-a1be-4e10-afcb-bee1888c4066@www.fastmail.com> (raw)
In-Reply-To: <da19f271-6ad6-7158-2ebe-e54fa5c91f6b@sequans.com>
On Tue, Sep 27, 2022, at 4:56 PM, Valentin Korenblit wrote:
>>>
>>> But in the mean time I am only half satisfied, because we plan to do
>>> twice more accesses than needed _just_ because of a the COMPILE_TEST
>>> constraint.
>> In my example, I had an #ifdef so it would only fall back
>> to 32-bit accesses on the 64-bit register when running an
>> actual 32-bit kernel, but leaving the 64-bit case efficient. Sorry for my late reply. I've just tested this and unfortunately
> the two sequential 32-bit accesses (with OFF0==0 and OFF1==4 seem
> to trigger sdma_err. I need to check some waveforms to verify if it
> happens right after the first access.
What happens if you do pairs of read from offset 0, effectively
doing a readsl() instead of readql(), obviously with twice the number
of accesses.
It's also possible you have to read from the second word first,
like
u32 *buf;
do {
buf[1] = __raw_readl(reg + 4);
buf[0] = __raw_readl(reg);
buf += 2;
} while (buf < end);
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: kbuild-all@lists.01.org
Subject: Re: [mtd:nand/next 11/31] drivers/mtd/nand/raw/cadence-nand-controller.c:1893:4: error: implicit declaration of function 'ioread64_rep' is invalid in C99
Date: Tue, 27 Sep 2022 22:02:39 +0200 [thread overview]
Message-ID: <e0a3bc54-a1be-4e10-afcb-bee1888c4066@www.fastmail.com> (raw)
In-Reply-To: <da19f271-6ad6-7158-2ebe-e54fa5c91f6b@sequans.com>
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
On Tue, Sep 27, 2022, at 4:56 PM, Valentin Korenblit wrote:
>>>
>>> But in the mean time I am only half satisfied, because we plan to do
>>> twice more accesses than needed _just_ because of a the COMPILE_TEST
>>> constraint.
>> In my example, I had an #ifdef so it would only fall back
>> to 32-bit accesses on the 64-bit register when running an
>> actual 32-bit kernel, but leaving the 64-bit case efficient. Sorry for my late reply. I've just tested this and unfortunately
> the two sequential 32-bit accesses (with OFF0==0 and OFF1==4 seem
> to trigger sdma_err. I need to check some waveforms to verify if it
> happens right after the first access.
What happens if you do pairs of read from offset 0, effectively
doing a readsl() instead of readql(), obviously with twice the number
of accesses.
It's also possible you have to read from the second word first,
like
u32 *buf;
do {
buf[1] = __raw_readl(reg + 4);
buf[0] = __raw_readl(reg);
buf += 2;
} while (buf < end);
Arnd
next prev parent reply other threads:[~2022-09-27 20:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 22:31 [mtd:nand/next 11/31] drivers/mtd/nand/raw/cadence-nand-controller.c:1893:4: error: implicit declaration of function 'ioread64_rep' is invalid in C99 kernel test robot
2022-09-21 8:40 ` Miquel Raynal
2022-09-21 8:40 ` Miquel Raynal
2022-09-21 8:45 ` Valentin Korenblit
2022-09-21 8:45 ` Valentin Korenblit
2022-09-21 12:27 ` Valentin Korenblit
2022-09-21 14:47 ` Miquel Raynal
2022-09-21 14:47 ` Miquel Raynal
2022-09-21 15:49 ` Arnd Bergmann
2022-09-21 15:49 ` Arnd Bergmann
2022-09-21 16:38 ` Miquel Raynal
2022-09-21 16:38 ` Miquel Raynal
2022-09-21 20:01 ` Arnd Bergmann
2022-09-21 20:01 ` Arnd Bergmann
2022-09-22 8:18 ` Valentin Korenblit
2022-09-22 9:36 ` Miquel Raynal
2022-09-22 9:36 ` Miquel Raynal
2022-09-22 10:52 ` Arnd Bergmann
2022-09-22 10:52 ` Arnd Bergmann
2022-09-22 11:00 ` Miquel Raynal
2022-09-22 11:00 ` Miquel Raynal
2022-09-27 14:56 ` Valentin Korenblit
2022-09-27 20:02 ` Arnd Bergmann [this message]
2022-09-27 20:02 ` Arnd Bergmann
2022-09-28 8:41 ` Valentin Korenblit
2022-09-28 8:41 ` Valentin Korenblit
2022-09-28 8:56 ` Arnd Bergmann
2022-09-28 8:56 ` Arnd Bergmann
2022-09-28 10:04 ` Valentin Korenblit
2022-09-28 10:04 ` Valentin Korenblit
2022-09-22 9:38 ` Miquel Raynal
2022-09-22 9:38 ` Miquel Raynal
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=e0a3bc54-a1be-4e10-afcb-bee1888c4066@www.fastmail.com \
--to=arnd@arndb.de \
--cc=kbuild-all@lists.01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=miquel.raynal@bootlin.com \
--cc=vkorenblit@sequans.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 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.