Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp714924pxj; Fri, 11 Jun 2021 09:37:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4/WJNB4PXmgkbjzMzm22d+GvZOSD+e14/mOAjI1PzWluuNXutBf8J+EvbziU5N7aszPqM X-Received: by 2002:a05:6402:685:: with SMTP id f5mr4624569edy.178.1623429474527; Fri, 11 Jun 2021 09:37:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623429474; cv=none; d=google.com; s=arc-20160816; b=ZmHwtEouVjHg8QHnTRq5JcrpWX7//0X0ERMarWkktWM1IrWHpIAOItSucE6o1zM+8l ZsYB9L+Pv7QeCXkyv6Wwx4koniZRxA33D+MeA+wC6zc5xjyINjg0umMoaeXmzNllElq8 hTaOgo6xTZg0fkhGrflY2xa6sMUywZhPIb/8e5Vc8uuGG1Ksc35nS4b9CKU6vDnQ9/52 zHQztiQsrk0o6463Mp9QQGGMYNPckNsCu9M1JB3wMzNxx8kA0806Zt2TlKp8Zowrm5+e V39BbB7xO17CmwYrIT2uMbJADyr4MGooOgRhKXTUCCvXFdXEbQaae2zR1ELVx9ldUE2z 1hDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=WgSbcHoAYOInbkclLd+KPDy6aZgT3YURgKmL3Czt4iE=; b=JnQLvBSnM5wKj5vdEz8WixhZKThGY+slSacqm8Se9dhUOGuqdyaxn7zobMvl1AyXQX kBfnNhhPM7hO2zhkR8O1e6N1Y0+2FcbBC5PwJaG4GPzNNyOnwQ5nFJAUeEQ0tQuhHV30 UYSp9mgQ7q7X//GUOBJXQHG1dZWqN7s/GazUuvstwVflEBaTC/JgzkRsqsgzvKQ57dIx RHBLA6q9XcUUW5wTSoCCfnLFaMWCWLW86Az44paCO706z2LLq6qU9gg3P5JDjYaaTGJa vknP0zY+DcI2BhmHr5laaaKOqsjNT0CwSg9vXMxsoeIE5ZhLdpVAZeFwhL9/7JC9u1TF L+9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@vanguardiasur-com-ar.20150623.gappssmtp.com header.s=20150623 header.b=fVnqtDPn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ar13si5183741ejc.73.2021.06.11.09.37.29; Fri, 11 Jun 2021 09:37:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@vanguardiasur-com-ar.20150623.gappssmtp.com header.s=20150623 header.b=fVnqtDPn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230280AbhFKQgD (ORCPT + 99 others); Fri, 11 Jun 2021 12:36:03 -0400 Received: from mail-ed1-f43.google.com ([209.85.208.43]:43841 "EHLO mail-ed1-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229548AbhFKQgC (ORCPT ); Fri, 11 Jun 2021 12:36:02 -0400 Received: by mail-ed1-f43.google.com with SMTP id s6so37796827edu.10 for ; Fri, 11 Jun 2021 09:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vanguardiasur-com-ar.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WgSbcHoAYOInbkclLd+KPDy6aZgT3YURgKmL3Czt4iE=; b=fVnqtDPnHyDeEDwW7lCfLTc6YqgBoQINeauUCk+FzpQk1NQM8ZKrzokTuRsjKcQD0a 7uc5EUmJLdvqhKwS9HPRkPSp6kOwxPiZMmdzeEkp9RQunoQXJnxMjul2NImsgdIPe9FH H5bkyFkjRXTcKrbkpcnYuEg/P7rgWCklLX09bdAy0NSXUvXMFtzPCR86g/c3NEgLmf9P xZUMnqKZx6cGgiOepfrBdCuYoE8ESNN39bl8zYn2H+kx/hJSuQ9kHXSWo+fofieg6ap/ 98gd/jWrtGd7QZOXQsU/ZbLq6r3vJ4+hsXWc9FwzGL95S2JoxKhidNJJPzoZEHWH2dBl NzBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WgSbcHoAYOInbkclLd+KPDy6aZgT3YURgKmL3Czt4iE=; b=hQ/JsAJSGr5kfsw7BykeCRkNd2DbMd2TfA5tDOXzSLzlQcZTbEa43qaRYzrbY+yYZJ /ehancftRIe3VU+udG/pKTvKKfQKw5Xo2op5gU+Udvrj3HQ7om4M/b/JW3xIYLAvFDCp g2qsH6oA11kMKqJEuzcdPOe0+JLYljntwTn1Zk1YJoCyHl/WTBskwMcixCqY7Fjcwcx2 F2hd23BUxC60wTkNW4QbYC6M0YR/XlzN2vj9QlFEAeFT7J8xgyCAGYp8XIICstO/hhvK 9k6jGtoPBvRJEUoye3XoEuB4rD5VlqNcs4RpT8ZocqKPAXqCU2NrTZ00FpgvRlKQkGMW Z8Rg== X-Gm-Message-State: AOAM531Cq94XZUt4iFJOdsULltqAVFRUcAG3kT4jiHG1ANP97lQSoUan 0ZJELQnPvj18WoTxFM+Lhdf2E2a5jeVYWZK/cMLWUA== X-Received: by 2002:aa7:db16:: with SMTP id t22mr4619739eds.49.1623429183914; Fri, 11 Jun 2021 09:33:03 -0700 (PDT) MIME-Version: 1.0 References: <20210609140412.16058-1-jon.lin@rock-chips.com> <20210609140412.16058-2-jon.lin@rock-chips.com> <20210610024350.GA697147@robh.at.kernel.org> In-Reply-To: From: Ezequiel Garcia Date: Fri, 11 Jun 2021 13:32:52 -0300 Message-ID: Subject: Re: [PATCH v7 1/9] dt-bindings: rockchip-sfc: Bindings for Rockchip serial flash controller To: Kever Yang Cc: Rob Herring , Jon Lin , linux-spi@vger.kernel.org, Mark Brown , Heiko Stuebner , Johan Jonker , hjc@rock-chips.com, yifeng.zhao@rock-chips.com, sugar.zhang@rock-chips.com, "open list:ARM/Rockchip SoC..." , linux-mtd , p.yadav@ti.com, macroalpha82@gmail.com, devicetree , linux-arm-kernel , Linux Kernel Mailing List , Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org, Chris Morgan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On Thu, 10 Jun 2021 at 00:04, Kever Yang wrote: > > Hi Rob, > > On 2021/6/10 =E4=B8=8A=E5=8D=8810:43, Rob Herring wrote: > > On Wed, Jun 09, 2021 at 10:04:04PM +0800, Jon Lin wrote: > >> From: Chris Morgan > >> > >> 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 > >> Signed-off-by: Jon Lin > >> --- > >> > >> 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"(Declar= ed > >> 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-sf= c.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 > >> + - Chris Morgan > >> + > >> +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 > > 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? > 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 =3D "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. [1] https://lkml.org/lkml/2021/6/8/2030 Thanks! Ezequiel