From patchwork Mon Jun 27 15:31:07 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Geert Uytterhoeven X-Patchwork-Id: 585420 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C4EEC43334 for ; Mon, 27 Jun 2022 15:31:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238228AbiF0Pba (ORCPT ); Mon, 27 Jun 2022 11:31:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237521AbiF0Pb2 (ORCPT ); Mon, 27 Jun 2022 11:31:28 -0400 Received: from andre.telenet-ops.be (andre.telenet-ops.be [IPv6:2a02:1800:120:4::f00:15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BD0F19C33 for ; Mon, 27 Jun 2022 08:31:24 -0700 (PDT) Received: from ramsan.of.borg ([84.195.186.194]) by andre.telenet-ops.be with bizsmtp id oFXH2700K4C55Sk01FXHYh; Mon, 27 Jun 2022 17:31:21 +0200 Received: from rox.of.borg ([192.168.97.57]) by ramsan.of.borg with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1o5qho-0014yX-Ve; Mon, 27 Jun 2022 17:31:16 +0200 Received: from geert by rox.of.borg with local (Exim 4.93) (envelope-from ) id 1o5qho-004jEG-Dr; Mon, 27 Jun 2022 17:31:16 +0200 From: Geert Uytterhoeven To: Vignesh Raghavendra , Sergey Shtylyov , Krzysztof Kozlowski , Wolfram Sang , Lad Prabhakar , Miquel Raynal , Richard Weinberger Cc: Mark Brown , linux-mtd@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, Geert Uytterhoeven Subject: [PATCH 0/7] memory: renesas-rpc-if: Rebind and s2ram fixes Date: Mon, 27 Jun 2022 17:31:07 +0200 Message-Id: X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org Hi all, The Renesas RPC-IF provides either HyperFlash or SPI host access. To handle this, three drivers are used: 1. The RPC-IF core diver, 2. An HyperFlash child driver, 3. An SPI child driver. Currently this driver collection has the following issues: 1. After manually unbinding the child driver, rebinding the child driver fails with -EBUSY, 2. During PSCI system suspend, the SoC may be powered down, losing RPC-IF register state, and causing data corruption after resume. This patch series aims to fix this: - Patches 1-4 contain preparatory cleanups and improvements, - Patch 5 fixes unbind/rebind, - Patch 6 cleans up the internal API between the RPC-IF core diver, and the HF and SPI child drivers, and thus touches the MTD/HYPERBUS and SPI subsystems, too, - Patch 7 adds system suspend/resume support to the RPC-IF core driver. This has been tested on the Salvator-XS (HyperFlash) and Falcon (QSPI FLASH) development boards. At least with HyperFlash, successful RPC-IF operation after s2ram is still not guaranteed (more details below). I do not have physical access to a board that uses the RPC-IF in SPI mode, so I could not test s2ram with RPC-SPI. I am wondering if it suffers from similar problems, or if these are purely related to HyperFlash? Findings: - Sometimes RPC-HF still works after resume from s2ram - Sometimes RPC-HF read data is corrupted after resume from s2ram: - Data read looks like (for each block of 16 bytes at offset i): - 8 bytes of data stored at offset (i % 262144) * 256, - 8 bytes duplicate of the above. - After that, unbind/rebind fails: # echo rpc-if-hyperflash > /sys/bus/platform/drivers/rpc-if-hyperflash/unbind # echo rpc-if-hyperflash > /sys/bus/platform/drivers/rpc-if-hyperflash/bind rpc-if-hyperflash rpc-if-hyperflash: probing of hyperbus device failed - After doing s2ram again, rebind (usually) succeeds again, and reading from HF returns the expected data again: # echo rpc-if-hyperflash > /sys/bus/platform/drivers/rpc-if-hyperflash/bind rpc-if-hyperflash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x007000 - When doing unbind before s2ram, rebind after resume usually works (better success rate than without unbind), but not always. Things I have tried: - Always resetting the device in rpcif_hw_init(), like is done on RZ/G2L, does not make a difference. - Dumping the full RPC register space before/after s2ram, but there does not seem to be any relation between register contents (which vary) and successful operation. - Adding HF calibration like hbmc-am654 (and never setting the controller's calibrated flag) does not help: either calibration succeeds with 5 passes on 5 tries, or fails with 0 passes on 25 tries. - Browsing the TF/A and U-Boot sources also didn't help. Thanks for your comments! Geert Uytterhoeven (7): memory: renesas-rpc-if: Always use dev in rpcif_sw_init() memory: renesas-rpc-if: Add dev helper to rpcif_probe() memory: renesas-rpc-if: Improve Runtime PM handling memory: renesas-rpc-if: Split-off private data from struct rpcif memory: renesas-rpc-if: Move resource acquisition to .probe() memory: renesas-rpc-if: Pass device instead of rpcif to rpcif_*() memory: renesas-rpc-if: Reinitialize registers during system resume drivers/memory/renesas-rpc-if.c | 167 +++++++++++++++++++++----------- drivers/mtd/hyperbus/rpc-if.c | 18 ++-- drivers/spi/spi-rpc-if.c | 14 +-- include/memory/renesas-rpc-if.h | 32 ++---- 4 files changed, 137 insertions(+), 94 deletions(-)