[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <TY1PR01MB156234F5B44BB43D3DCA98128A5A0@TY1PR01MB1562.jpnprd01.prod.outlook.com>
Date: Wed, 11 Dec 2019 14:33:42 +0000
From: Chris Brandt <Chris.Brandt@...esas.com>
To: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
Rob Herring <robh+dt@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
CC: Mark Rutland <mark.rutland@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Mason Yang <masonccyang@...c.com.tw>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
Subject: RE: [PATCH RFC 0/2] Add Renesas RPC-IF support
Hello Sergei,
On Tue, Dec 10, 2019, Sergei Shtylyov wrote:
> Here's a set of 2 patches against Linus' repo. Renesas Reduced Pin Count
> Interface (RPC-IF) allows a SPI flash or HyperFlash connected to the SoC to
> be accessed via the external address space read mode or the manual mode.
Looking at this driver, all it is are APIs. Meaning another driver is
needed to sit in between the MTD layer and this HW driver layer.
In the driver that I did, if the "RPC" HW is going to be used to control
a SPI Flash device, it registered a spi controller and then the MTD
layer could access the device just like any other SPI controller driver. No
additional drivers are needed.
Looking at the hyperbus driver that is in drivers/mtd/hyperbus/, it
seems that if the "RPC" HW is going to be used to control HyperFlash, then
all you would need to do is register a hyperbus controller using
hyperbus_register_device(). Then the MTD layer could read/write the flash using
normal MTD CFI interface.
Why do you think you need another layer in between the HW driver and the
MTD layer?
Is your goal to make a multi-layered system where the HW jumps back and forth
in between operating modes at runtime? I'm not sure of the use case for all of
this.
Chris
Powered by blists - more mailing lists