[PATCH 0/7] memory: renesas-rpc-if: Rebind and s2ram fixes

From: Geert Uytterhoeven
Date: Mon Jun 27 2022 - 11:31:35 EST


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(-)

--
2.25.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds