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

[Geert Uytterhoeven <geert+renesas@glider.be>]

	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@linux-m68k.org

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/