From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Chris Brandt <Chris.Brandt@renesas.com>,
Rob Herring <robh+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Mason Yang <masonccyang@mxic.com.tw>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>
Subject: Re: [PATCH RFC 0/2] Add Renesas RPC-IF support
Date: Wed, 11 Dec 2019 19:08:51 +0300 [thread overview]
Message-ID: <03a630e2-280f-98b7-a9c8-6533716720e5@cogentembedded.com> (raw)
In-Reply-To: <TY1PR01MB156234F5B44BB43D3DCA98128A5A0@TY1PR01MB1562.jpnprd01.prod.outlook.com>
HEllo
On 12/11/2019 05:33 PM, Chris Brandt 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.
Between the hardware and SPI, and between the hardware and HyperFlash
infrastructure. There's a lot of the common hardware code common between
these 2 driver areas.
> 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.
We're already been thru that with Mason's patch -- I don't want the code
duplicated between 2 drivers.
> 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
Sure. But the code controlling RPC hardware is largely the same b/w 2 cases.
> 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.
That's what I do (the current realization makes too many assumptions about
the HF hardware (both direct read and write).
> Why do you think you need another layer in between the HW driver and the
> MTD layer?
Because we don't want any duplicated code. Also, think about DT -- it
describes the hardware, not the driver configuration.
> 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.
My goal is to prevent the code duplication (and keep DT sane too).
> Chris
MBR, Sergei
next prev parent reply other threads:[~2019-12-11 16:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 19:34 [PATCH RFC 0/2] Add Renesas RPC-IF support Sergei Shtylyov
2019-12-10 19:37 ` [PATCH RFC 1/2] dt-bindings: memory: document Renesas RPC-IF bindings Sergei Shtylyov
2019-12-19 20:38 ` Rob Herring
2019-12-10 19:39 ` [PATCH RFC 2/2] memory: add Renesas RPC-IF driver Sergei Shtylyov
2019-12-11 9:58 ` Philipp Zabel
2020-02-10 10:21 ` Behme Dirk (CM/ESO2)
[not found] ` <5760bcdb-e44b-6f18-7262-9526684e5780-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
2020-02-22 20:42 ` Sergei Shtylyov
[not found] ` <5603f393-554d-e2a8-c2d8-6bafc20f4169-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2020-02-24 5:46 ` Behme Dirk (CM/ESO2)
[not found] ` <cba1e2ec-4896-23ef-ef7b-0f80d4310127-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
2020-02-24 17:28 ` Chris Brandt
2020-02-24 18:59 ` Sergei Shtylyov
2020-02-25 9:33 ` Behme Dirk (CM/ESO2)
[not found] ` <3a182ac7-8d41-cdc7-2b87-7c503f68a426-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
2020-02-25 20:41 ` Sergei Shtylyov
[not found] ` <f21a9444-9541-6558-f5f5-ca0b733768ff-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2020-02-26 9:54 ` Behme Dirk (CM/ESO2)
2020-02-27 20:32 ` Sergei Shtylyov
2019-12-11 14:33 ` [PATCH RFC 0/2] Add Renesas RPC-IF support Chris Brandt
2019-12-11 16:08 ` Sergei Shtylyov [this message]
2019-12-11 16:20 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03a630e2-280f-98b7-a9c8-6533716720e5@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=Chris.Brandt@renesas.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=masonccyang@mxic.com.tw \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).