All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	Andrew Gabbasov <andrew_gabbasov@mentor.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [RFC PATCH] memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode
Date: Fri, 24 Sep 2021 13:09:53 +0200	[thread overview]
Message-ID: <11355367-8d20-5a17-70da-618d87301407@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.

Is this part something worth splitting to its own patch?

> 
> 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
> 
> 
>  drivers/memory/renesas-rpc-if.c | 113 ++++++++++++++++++++++----------
>  include/memory/renesas-rpc-if.h |   1 +
>  2 files changed, 79 insertions(+), 35 deletions(-)

You sent the patch just slightly after this one:
https://lore.kernel.org/lkml/20210922184830.29147-1-andrew_gabbasov@mentor.com/

Are you solving similar problem?


Best regards,
Krzysztof

  reply	other threads:[~2021-09-24 11:10 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 [this message]
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
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=11355367-8d20-5a17-70da-618d87301407@canonical.com \
    --to=krzysztof.kozlowski@canonical.com \
    --cc=andrew_gabbasov@mentor.com \
    --cc=duc.nguyen.ub@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.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 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.