Re: [PATCH RFC 2/2] memory: add Renesas RPC-IF driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22.02.2020 21:42, Sergei Shtylyov wrote:
On 02/10/2020 01:21 PM, Behme Dirk (CM/ESO2) wrote:

Add the memory driver for Renesas RPC-IF which registers either SPI or
HyperFLash device depending on the contents of the device tree subnode.
It also provides the absract "back end" device APIs that can be used by
the "front end" SPI/MTD drivers to talk to the real hardware.

Based on the original patch by Mason Yang <masonccyang@xxxxxxxxxxx>.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx>


FYI, please find below [1] the changes I did locally on this driver. It seems to read & write successfully on my custom M3 (R8A7796) device, now.

    Not for me...
    BTW, your patch had whitespace ruined, I had to apply it by hand, you'd better
attach the patches, not paste. :-/


Ok. There are other mailing lists complaining about attachments ;)

Even better, maybe we should put what we have so far publicly anywhere, e.g. github.


Best regards

Dirk

[1]

 From d72b805cc461ab1e9747c973e9be84e7abb8f828 Mon Sep 17 00:00:00 2001
From: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
Date: Tue, 4 Feb 2020 08:39:31 +0100
Subject: [PATCH] memory: renesas-rpc-if: Correct the STRTIM and some other
  clean up

This is required to make the driver work correctly in my M3 environment.

Signed-off-by: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
---
  drivers/memory/renesas-rpc-if.c | 42 ++++++++++++++++++++-------------
  1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c
index 04be92b64bfa..f4356b066384 100644
--- a/drivers/memory/renesas-rpc-if.c
+++ b/drivers/memory/renesas-rpc-if.c
[...]
@@ -513,19 +525,15 @@ ssize_t rpcif_dirmap_read(struct rpcif *rpc, u64 offs, size_t len, void *buf)
      pm_runtime_get_sync(rpc->dev);

      regmap_update_bits(rpc->regmap, RPCIF_CMNCR, RPCIF_CMNCR_MD, 0);
-    regmap_write(rpc->regmap, RPCIF_DRCR,
-             RPCIF_DRCR_RBURST(32) | RPCIF_DRCR_RBE);
-    regmap_write(rpc->regmap, RPCIF_DRCMR, rpc->command);
-    regmap_write(rpc->regmap, RPCIF_DREAR,
-             RPCIF_DREAR_EAV(offs >> 25) | RPCIF_DREAR_EAC(1));
-    regmap_write(rpc->regmap, RPCIF_DROPR, rpc->option);
-    regmap_write(rpc->regmap, RPCIF_DRENR,
-             rpc->enable & ~RPCIF_SMENR_SPIDE(0xF));
-    regmap_write(rpc->regmap, RPCIF_DRDMCR, rpc->dummy);
-    regmap_write(rpc->regmap, RPCIF_DRDRENR, rpc->ddr);

    The driver somehow works only with this left in place (with 2 bytes eaten
as before), otherwise all the flash reads all 0xff (via dirmap).


Do you boot from hyperflash?

The system I'm using for testing boots from hyperflash. So most probably all registers I don't touch in the driver are put into a reasonable state by the boot code, already. If you don't boot from hyperflash, that at least would explain our different behavior.

Best regards

Dirk




[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux