Hello! On 02/24/2020 08:46 AM, 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 ;) All Linux MLs prefer patches inline. :-) But you seem to paste the patches to the mail edited in some MUA (which does ruin whitespace). Don't do that, it's better to just attach. > Even better, maybe we should put what we have so far publicly anywhere, e.g. github. Cogent has an accout there, I'll try asking the management if it could also be used... >>> 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? No, I have arewto say 'cpld write 30 1' in U-Boot before a boot a kernel. Normally, the V3x Starter Kit boards are wired for the QSPI flash chips. > 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. Yes. Mind dumping the registers and sending to me? > Best regards > > Dirk MBR, Sergei
