linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: Andy Gross <agross@kernel.org>, Ohad Ben-Cohen <ohad@wizery.com>,
	Baolin Wang <baolin.wang7@gmail.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM" 
	<linux-remoteproc@vger.kernel.org>,
	devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Vinod Koul <vkoul@kernel.org>
Subject: Re: [PATCH v2 1/4] dt-bindings: hwlock: qcom: Migrate binding to YAML
Date: Tue, 21 Jul 2020 21:46:15 -0700	[thread overview]
Message-ID: <20200722044615.GR388985@builder.lan> (raw)
In-Reply-To: <CAL_JsqKW+R=rygii7N69o28h5780qx645RhPXGQZ4jw3kHadhw@mail.gmail.com>

On Tue 21 Jul 08:13 PDT 2020, Rob Herring wrote:

> On Mon, Jun 22, 2020 at 1:59 AM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > Migrate the Qualcomm TCSR mutex binding to YAML to allow validation.
> >
> > Reviewed-by: Vinod Koul <vkoul@kernel.org>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Changes since v1:
> > - Actually remove the old binding doc
> >
> >  .../bindings/hwlock/qcom-hwspinlock.txt       | 39 --------------
> >  .../bindings/hwlock/qcom-hwspinlock.yaml      | 51 +++++++++++++++++++
> >  2 files changed, 51 insertions(+), 39 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
> >  create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> 
> [...]
> 
> > diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> > new file mode 100644
> > index 000000000000..71e63b52edd5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm Hardware Mutex Block
> > +
> > +maintainers:
> > +  - Bjorn Andersson <bjorn.andersson@linaro.org>
> > +
> > +description:
> > +  The hardware block provides mutexes utilized between different processors on
> > +  the SoC as part of the communication protocol used by these processors.
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - qcom,sfpb-mutex
> > +      - qcom,tcsr-mutex
> > +
> > +  '#hwlock-cells':
> > +    const: 1
> > +
> > +  syscon:
> > +    $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +    description:
> > +      Should be a triple of phandle referencing the TCSR mutex syscon, offset
> > +      of first mutex within the syscon and stride between each mutex.
> > +
> > +required:
> > +  - compatible
> > +  - '#hwlock-cells'
> > +  - syscon
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +        tcsr_mutex_block: syscon@fd484000 {
> > +                compatible = "syscon";
> 
> 'syscon' alone now generates warnings. Can you drop this node or add a
> specific compatible.
> 

In the binding examples or in the dts files as well?

The hardware block here is named "TCSR_MUTEX", so the natural compatible
to add here would be "qcom,tcsr-mutex", but that already has a meaning -
and the syscon node here doesn't carry all required properties...


Should we perhaps just remove the split model (syscon and
qcom,tcsr-mutex as different nodes) from the example and dts files?
(While maintaining backwards compatibility in the binding and driver)

For the platforms where we have other drivers that needs to poke in this
syscon it seems to work fine to say:
	compatible = "qcom,tcsr-mutex", "syscon";

Regards,
Bjorn

> > +                reg = <0xfd484000 0x2000>;
> > +        };
> > +
> > +        hwlock {
> > +                compatible = "qcom,tcsr-mutex";
> > +                syscon = <&tcsr_mutex_block 0 0x80>;
> > +
> > +                #hwlock-cells = <1>;
> > +        };
> > +...
> > --
> > 2.26.2
> >

  reply	other threads:[~2020-07-22  4:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22  7:59 [PATCH v2 0/4] hwspinlock: qcom: Allow dropping the intermediate TCSR mutex syscon Bjorn Andersson
2020-06-22  7:59 ` [PATCH v2 1/4] dt-bindings: hwlock: qcom: Migrate binding to YAML Bjorn Andersson
2020-07-14  2:09   ` Rob Herring
2020-07-21 15:13   ` Rob Herring
2020-07-22  4:46     ` Bjorn Andersson [this message]
2020-07-22 14:42       ` Rob Herring
2020-06-22  7:59 ` [PATCH v2 2/4] dt-bindings: hwlock: qcom: Allow device on mmio bus Bjorn Andersson
2020-07-14  2:10   ` Rob Herring
2020-06-22  7:59 ` [PATCH v2 3/4] hwspinlock: qcom: Allow mmio usage in addition to syscon Bjorn Andersson
2020-07-14 16:04   ` Stephan Gerhold
2020-07-14 16:33     ` Bjorn Andersson
2020-06-22  7:59 ` [PATCH v2 4/4] arm64: dts: qcom: sm8250: Drop tcsr_mutex syscon Bjorn Andersson
2020-07-15 19:36   ` Dmitry Baryshkov
2020-07-16  2:59   ` Manivannan Sadhasivam

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=20200722044615.GR388985@builder.lan \
    --to=bjorn.andersson@linaro.org \
    --cc=agross@kernel.org \
    --cc=baolin.wang7@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=robh+dt@kernel.org \
    --cc=vkoul@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).