linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
	Kever Yang <kever.yang@rock-chips.com>
Cc: "Jon Lin" <jon.lin@rock-chips.com>,
	linux-spi <linux-spi@vger.kernel.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Johan Jonker" <jbx6244@gmail.com>, 黄家钗 <hjc@rock-chips.com>,
	"Yifeng Zhao" <yifeng.zhao@rock-chips.com>,
	"Sugar Zhang" <sugar.zhang@rock-chips.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	"Pratyush Yadav" <p.yadav@ti.com>,
	"Chris Morgan" <macroalpha82@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	"Chris Morgan" <macromorgan@hotmail.com>
Subject: Re: [PATCH v7 1/9] dt-bindings: rockchip-sfc: Bindings for Rockchip serial flash controller
Date: Wed, 16 Jun 2021 09:38:05 -0600	[thread overview]
Message-ID: <CAL_JsqL1Sb_TCw6TG7XGBDtmhMVD+_n7d-ii7N9N7w1+A627=w@mail.gmail.com> (raw)
In-Reply-To: <CAAEAJfCyXWvcqswXfmgXBX-et0mq3vxoUacUmHGso9t+XoNqOg@mail.gmail.com>

On Fri, Jun 11, 2021 at 10:33 AM Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
>
> Hi all,
>
> On Thu, 10 Jun 2021 at 00:04, Kever Yang <kever.yang@rock-chips.com> wrote:
> >
> > Hi Rob,
> >
> > On 2021/6/10 上午10:43, Rob Herring wrote:
> > > On Wed, Jun 09, 2021 at 10:04:04PM +0800, Jon Lin wrote:
> > >> From: Chris Morgan <macromorgan@hotmail.com>
> > >>
> > >> Add bindings for the Rockchip serial flash controller. New device
> > >> specific parameter of rockchip,sfc-no-dma included in documentation.
> > >>
> > >> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > >> Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
> > >> ---
> > >>
> > >> Changes in v7:
> > >> - Fix up the sclk_sfc parent error in rk3036
> > >> - Unify to "rockchip,sfc" compatible id because all the feature update
> > >>    will have a new IP version, so the driver is used for the SFC IP in
> > >>    all SoCs
> > >> - Change to use node "sfc" to name the SFC pinctrl group
> > >> - Add subnode reg property check
> > >> - Add rockchip_sfc_adjust_op_size to workaround in CMD + DUMMY case
> > >> - Limit max_iosize to 32KB
> > >>
> > >> Changes in v6:
> > >> - Add support in device trees for rv1126(Declared in series 5 but not
> > >>    submitted)
> > >> - Change to use "clk_sfc" "hclk_sfc" as clock lable, since it does not
> > >>    affect interpretation and has been widely used
> > >> - Support sfc tx_dual, tx_quad(Declared in series 5 but not submitted)
> > >> - Simplify the code, such as remove "rockchip_sfc_register_all"(Declared
> > >>    in series 5 but not submitted)
> > >> - Support SFC ver4 ver5(Declared in series 5 but not submitted)
> > >> - Add author Chris Morgan and Jon Lin to spi-rockchip-sfc.c
> > >> - Change to use devm_spi_alloc_master and spi_unregister_master
> > >>
> > >> Changes in v5:
> > >> - Add support in device trees for rv1126
> > >> - Support sfc tx_dual, tx_quad
> > >> - Simplify the code, such as remove "rockchip_sfc_register_all"
> > >> - Support SFC ver4 ver5
> > >>
> > >> Changes in v4:
> > >> - Changing patch back to an "RFC". An engineer from Rockchip
> > >>    reached out to me to let me know they are working on this patch for
> > >>    upstream, I am submitting this v4 for the community to see however
> > >>    I expect Jon Lin (jon.lin@rock-chips.com) will submit new patches
> > >>    soon and these are the ones we should pursue for mainlining. Jon's
> > >>    patch series should include support for more hardware than this
> > >>    series.
> > >> - Clean up documentation more and ensure it is correct per
> > >>    make dt_binding_check.
> > >> - Add support in device trees for rk3036, rk3308, and rv1108.
> > >> - Add ahb clock (hclk_sfc) support for rk3036.
> > >> - Change rockchip_sfc_wait_fifo_ready() to use a switch statement.
> > >> - Change IRQ code to only mark IRQ as handled if it handles the
> > >>    specific IRQ (DMA transfer finish) it is supposed to handle.
> > >>
> > >> Changes in v3:
> > >> - Changed the name of the clocks to sfc/ahb (from clk-sfc/clk-hsfc).
> > >> - Changed the compatible string from rockchip,sfc to
> > >>    rockchip,rk3036-sfc. A quick glance at the datasheets suggests this
> > >>    driver should work for the PX30, RK180x, RK3036, RK312x, RK3308 and
> > >>    RV1108 SoCs, and possibly more. However, I am currently only able
> > >>    to test this on a PX30 (an RK3326). The technical reference manuals
> > >>    appear to list the same registers for each device.
> > >> - Corrected devicetree documentation for formatting and to note these
> > >>    changes.
> > >> - Replaced the maintainer with Heiko Stuebner and myself, as we will
> > >>    take ownership of this going forward.
> > >> - Noted that the device (per the reference manual) supports 4 CS, but
> > >>    I am only able to test a single CS (CS 0).
> > >> - Reordered patches to comply with upstream rules.
> > >>
> > >> Changes in v2:
> > >> - Reimplemented driver using spi-mem subsystem.
> > >> - Removed power management code as I couldn't get it working properly.
> > >> - Added device tree bindings for Odroid Go Advance.
> > >>
> > >> Changes in v1:
> > >> hanges made in this new series versus the v8 of the old series:
> > >> - Added function to read spi-rx-bus-width from device tree, in the
> > >>    event that the SPI chip supports 4x mode but only has 2 pins
> > >>    wired (such as the Odroid Go Advance).
> > >> - Changed device tree documentation from txt to yaml format.
> > >> - Made "reset" message a dev_dbg from a dev_info.
> > >> - Changed read and write fifo functions to remove redundant checks.
> > >> - Changed the write and read from relaxed to non-relaxed when
> > >>    starting the DMA transfer or reading the DMA IRQ.
> > >> - Changed from dma_coerce_mask_and_coherent to just
> > >>    dma_set_mask_and_coherent.
> > >> - Changed name of get_if_type to rockchip_sfc_get_if_type.
> > >>
> > >>   .../devicetree/bindings/spi/rockchip-sfc.yaml | 88 +++++++++++++++++++
> > >>   1 file changed, 88 insertions(+)
> > >>   create mode 100644 Documentation/devicetree/bindings/spi/rockchip-sfc.yaml
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml b/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml
> > >> new file mode 100644
> > >> index 000000000000..42e4198e92af
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml
> > >> @@ -0,0 +1,88 @@
> > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > >> +%YAML 1.2
> > >> +---
> > >> +$id: http://devicetree.org/schemas/spi/rockchip-sfc.yaml#
> > >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > >> +
> > >> +title: Rockchip Serial Flash Controller (SFC)
> > >> +
> > >> +maintainers:
> > >> +  - Heiko Stuebner <heiko@sntech.de>
> > >> +  - Chris Morgan <macromorgan@hotmail.com>
> > >> +
> > >> +allOf:
> > >> +  - $ref: spi-controller.yaml#
> > >> +
> > >> +properties:
> > >> +  compatible:
> > >> +    oneOf:
> > >> +      - const: rockchip,sfc
> > > Use 'enum' instead of oneOf+const.
> > >
> > > You need an SoC specific compatible.
> >
> >
> > The rockchip sfc controller is a standalone IP with version register,
> > and the driver can
> >
> > handle all the feature difference inside the IP, so we would like to use
> > a more generic

Okay, if the version register can be relied on, then this is fine.
Just add a comment that further differentiation is done using a
version register.

> >
> > compatible name instead of bind to any of SoC name. So can we use
> > "rockchip,sfc"
> >
> > like "snps,designware-spi", which is a generic one, instead of an SoC
> > specific compatible?

That's a licensed IP which is a bit different. Though generic names on
those are useless too. There's different versions and different
integration quirks.

> >
>
> IIUC, the way this works is along these lines:
>
> * The SFC driver can only care for the rockchip,sfc compatible string
> and, if suitable, use the IP version register mentioned by Kever [1].
>
> * The bindings doc specifies both the SoC-specific and the generic one
> with:
>
>       - items:
>           - enum:
>               - rockchip,px30-sfc
>           - const: rockchip,sfc
>
> * The device tree lists both as well:
>
> compatible = "rockchip,px30-sfc", "rockchip,sfc";
>
> This can apply to all IP cores really; and will allow some
> compatibility between the downstream/vendor device tree
> and upstream.
>
> This scheme is indeed more convoluted than just
> picking any SoC name for the compatible string, and
> use that compatible string for all the SoCs (given they
> are all compatible, again as per [1]).
>
> IOW, you only have "rockchip,px30-sfc" in the bindings,
> in the devicetree files and in the driver.

This is fine too, but again if a version or capability register is
sufficient, no need to put this into DT. Maybe someday h/w designers
will clue in and always have version and/or capability registers.

Rob

  reply	other threads:[~2021-06-16 15:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 14:04 [PATCH v7 0/9] Add Rockchip SFC(serial flash controller) support Jon Lin
2021-06-09 14:04 ` [PATCH v7 1/9] dt-bindings: rockchip-sfc: Bindings for Rockchip serial flash controller Jon Lin
2021-06-09 16:16   ` Rob Herring
2021-06-10  2:43   ` Rob Herring
2021-06-10  3:02     ` Kever Yang
2021-06-11 16:32       ` Ezequiel Garcia
2021-06-16 15:38         ` Rob Herring [this message]
2021-06-17  1:51           ` Kever Yang
2021-06-09 14:04 ` [PATCH v7 2/9] spi: rockchip-sfc: add rockchip " Jon Lin
2021-06-09 18:45   ` Chris Morgan
2021-06-09 14:04 ` [PATCH v7 3/9] arm64: dts: rockchip: Add SFC to PX30 Jon Lin
2021-06-09 14:04 ` [PATCH v7 4/9] clk: rockchip: rk3036: fix up the sclk_sfc parent error Jon Lin
2021-06-09 14:13 ` [PATCH v7 5/9] clk: rockchip: Add support for hclk_sfc on rk3036 Jon Lin
2021-06-09 14:13   ` [PATCH v7 6/9] arm: dts: rockchip: Add SFC to RK3036 Jon Lin
2021-06-09 14:13   ` [PATCH v7 7/9] arm: dts: rockchip: Add SFC to RV1108 Jon Lin
2021-06-09 14:13   ` [PATCH v7 8/9] arm64: dts: rockchip: Add SFC to RK3308 Jon Lin
2021-06-09 14:13   ` [PATCH v7 9/9] arm64: dts: rockchip: Enable SFC for Odroid Go Advance Jon Lin
2021-06-10 17:36     ` Chris Morgan
2021-06-11  2:26       ` Jon Lin
     [not found]         ` <SN6PR06MB5342327048383CC3D416C93DA5349@SN6PR06MB5342.namprd06.prod.outlook.com>
2021-06-11  3:54           ` Jon Lin

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='CAL_JsqL1Sb_TCw6TG7XGBDtmhMVD+_n7d-ii7N9N7w1+A627=w@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=jbx6244@gmail.com \
    --cc=jon.lin@rock-chips.com \
    --cc=kever.yang@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=macroalpha82@gmail.com \
    --cc=macromorgan@hotmail.com \
    --cc=mturquette@baylibre.com \
    --cc=p.yadav@ti.com \
    --cc=sboyd@kernel.org \
    --cc=sugar.zhang@rock-chips.com \
    --cc=yifeng.zhao@rock-chips.com \
    /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).