From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org,
Duc Nguyen <duc.nguyen.ub@renesas.com>,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [RFC PATCH] memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode
Date: Tue, 28 Sep 2021 11:46:41 +0200 [thread overview]
Message-ID: <beb6c373-e9d8-b0f1-78c5-cf21d01a5a9b@canonical.com> (raw)
In-Reply-To: <20210922091007.5516-1-wsa+renesas@sang-engineering.com>
On 22/09/2021 11:10, Wolfram Sang wrote:
> This patch fixes 2 problems:
> [1] The output warning logs and data loss when performing
> mount/umount then remount the device with jffs2 format.
> [2] The access width of SMWDR[0:1]/SMRDR[0:1] register is wrong.
>
> This is the sample warning logs when performing mount/umount then
> remount the device with jffs2 format:
> jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x031c51d4:
> Read 0x00034e00, calculated 0xadb272a7
>
> The reason for issue [1] is that the writing data seems to
> get messed up.
> Data is only completed when the number of bytes is divisible by 4.
> If you only have 3 bytes of data left to write, 1 garbage byte
> is inserted after the end of the write stream.
> If you only have 2 bytes of data left to write, 2 bytes of '00'
> are added into the write stream.
> If you only have 1 byte of data left to write, 2 bytes of '00'
> are added into the write stream. 1 garbage byte is inserted after
> the end of the write stream.
>
> To solve problem [1], data must be written continuously in serial
> and the write stream ends when data is out.
>
> Following HW manual 62.2.15, access to SMWDR0 register should be
> in the same size as the transfer size specified in the SPIDE[3:0]
> bits in the manual mode enable setting register (SMENR).
> Be sure to access from address 0.
>
> So, in 16-bit transfer (SPIDE[3:0]=b'1100), SMWDR0 should be
> accessed by 16-bit width.
> Similar to SMWDR1, SMDDR0/1 registers.
> In current code, SMWDR0 register is accessed by regmap_write()
> that only set up to do 32-bit width.
>
> To solve problem [2], data must be written 16-bit or 8-bit when
> transferring 1-byte or 2-byte.
>
> Signed-off-by: Duc Nguyen <duc.nguyen.ub@renesas.com>
> [wsa: refactored to use regmap only via reg_read/reg_write]
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Hi,
>
> I could reproduce the issue by a simple:
>
> $ echo "Hello" > /dev/mtd10
>
> The original BSP patch fixed the issue but mixed regmap-acces with
> ioread/iowrite accesses. So, I refactored it to use custom regmap
> accessors. This keeps the code more readable IMO. With this patch, my
> custom test cases work as well as the JFFS2 remount mentioned in the
> commit message. Tested on a Renesas Condor board (R-Car V3M) and a
> Falcon board (R-Car V3U). I send this as RFC because this is my first
> patch for the RPC code and hope for feedback. The BSP team has been
> contacted as well for comments and testing. Nonetheless, this addresses
> a serious issue which has caused broken boards because of writing to
> unintended locations. So, I'd like to see this discussed and applied
> soon if possible.
>
> Thanks everyone,
>
> Wolfram
>
Thanks for testing and comments. Any Fixes tag for it?
Best regards,
Krzysztof
next prev parent reply other threads:[~2021-09-28 9:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 9:10 [RFC PATCH] memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode Wolfram Sang
2021-09-24 11:09 ` Krzysztof Kozlowski
2021-09-24 12:35 ` Wolfram Sang
2021-09-27 8:51 ` Lad, Prabhakar
2021-09-27 9:45 ` Geert Uytterhoeven
2021-09-27 19:50 ` Lad, Prabhakar
2021-09-27 20:10 ` Wolfram Sang
2021-09-28 9:46 ` Krzysztof Kozlowski [this message]
2021-09-28 10:31 ` Wolfram Sang
2021-09-28 10:35 ` Krzysztof Kozlowski
2022-03-07 16:44 ` Geert Uytterhoeven
2022-03-07 17:47 ` Krzysztof Kozlowski
2022-03-07 18:11 ` Geert Uytterhoeven
2022-03-08 8:21 ` Wolfram Sang
2022-03-08 8:29 ` Geert Uytterhoeven
2022-03-08 8:46 ` Wolfram Sang
2022-03-08 9:01 ` Geert Uytterhoeven
2022-03-11 16:55 ` Geert Uytterhoeven
2022-04-27 10:22 ` Geert Uytterhoeven
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=beb6c373-e9d8-b0f1-78c5-cf21d01a5a9b@canonical.com \
--to=krzysztof.kozlowski@canonical.com \
--cc=duc.nguyen.ub@renesas.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=prabhakar.csengg@gmail.com \
--cc=wsa+renesas@sang-engineering.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;
as well as URLs for NNTP newsgroup(s).