From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 494A7C4332F for ; Fri, 24 Sep 2021 11:10:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2D82D61214 for ; Fri, 24 Sep 2021 11:10:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245718AbhIXLLb (ORCPT ); Fri, 24 Sep 2021 07:11:31 -0400 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]:54474 "EHLO smtp-relay-internal-1.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245727AbhIXLL3 (ORCPT ); Fri, 24 Sep 2021 07:11:29 -0400 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 5B74240828 for ; Fri, 24 Sep 2021 11:09:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1632481795; bh=dYSZ/Mc6JsUAkvA/NUn4+dUkHgFKndSqh5nGDhv9ymw=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=Gnmn874BqvMiKu2P8p0k/ouIWPFZm9WeT+Vo5YuJyG9zDA8TV+Lcxc/1DnVUgIjP9 TOuuaqvddW6yK3BkYP2ZT3Ui8WUFLJ41tN/5AwkZtDXXnnP5/8RRLsL+n+X0/MaL7+ HNEYR4R25mmgzRc7SZQN0YMCQW6waKvAsJ/bqTFn3/hS4lFAOlnkgNjv88BOomgja0 Z7fhDrW02YGJ1KceLZuBwMkiCGNwAWCG7s/vmdx/xRQMgrjU5oX9EJ1tKXb4ZaJSbL PBl62jVOez0S4KiPmEnhQOBJmz6R0bh4BLvbxvL4XlpejK3iSOzTb6Mj+Dqz6TqmJh u0tHHXpiE/Vkw== Received: by mail-wr1-f70.google.com with SMTP id u10-20020adfae4a000000b0016022cb0d2bso7714692wrd.19 for ; Fri, 24 Sep 2021 04:09:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dYSZ/Mc6JsUAkvA/NUn4+dUkHgFKndSqh5nGDhv9ymw=; b=oDVa3jALm+k+BuVhWw+485RhOB95ZHw6ZeP3yzqKU3f4hwGMGkk+mJey5nYVQa4c9E KTrKQ2OLuTWZfAlfC1pil5nfG2O1R8SA3vrm2RXSLQwJIeTj4Une4s1iRdhxyGkeN77f xRY0QqYoFm0FRwM2UuVKtryHNnWFWyj7K+0lcb0naSM6dSVGbPrYdHX1IbQfM0/BbJ+C CnHEvuN7jXX0j2YkzQnN/7Zm4stA6IOEUWJJ8flkFNgI3FgBGbj3McXGV3JUrMzXI5te tPFp79XalnI4NHoz1yBVb0BoICD//5W9xqK9vqQXWfbosgODSkp8x80G5dJ76k9VQkik d2Tw== X-Gm-Message-State: AOAM532yOU5suNgsCWG0H0/1OhGMeMZGSXcSZfMcb2Jgf2mHXQ5c7yla bXeiQvnv/s1uJSb4W4XKLSXkJKdzRPQajW8G+hWRIWseN91dsVNzguKNjKVVE1bMy0HhIY+BBUT 8WRSj63kV+rWvJnD5Qi+7Yx3bCGfCxgfEjGDMyFZSVw== X-Received: by 2002:a05:6000:1379:: with SMTP id q25mr11017821wrz.429.1632481794765; Fri, 24 Sep 2021 04:09:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtYqCpyghjXrGKwJE8YBUcU+u19xLlZicvnkMF15QUFlmjgr4OTvw42lVtXntG4qGYLi11vQ== X-Received: by 2002:a05:6000:1379:: with SMTP id q25mr11017805wrz.429.1632481794530; Fri, 24 Sep 2021 04:09:54 -0700 (PDT) Received: from [192.168.0.134] (lk.84.20.244.219.dc.cable.static.lj-kabel.net. [84.20.244.219]) by smtp.gmail.com with ESMTPSA id c77sm8061949wme.46.2021.09.24.04.09.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Sep 2021 04:09:54 -0700 (PDT) Subject: Re: [RFC PATCH] memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode To: Wolfram Sang , linux-kernel@vger.kernel.org Cc: linux-renesas-soc@vger.kernel.org, Duc Nguyen , Andrew Gabbasov , Geert Uytterhoeven , Lad Prabhakar References: <20210922091007.5516-1-wsa+renesas@sang-engineering.com> From: Krzysztof Kozlowski Message-ID: <11355367-8d20-5a17-70da-618d87301407@canonical.com> Date: Fri, 24 Sep 2021 13:09:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210922091007.5516-1-wsa+renesas@sang-engineering.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > [wsa: refactored to use regmap only via reg_read/reg_write] > Signed-off-by: Wolfram Sang > --- > > 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