All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Fabien DESSENNE <fabien.dessenne@st.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-stm32@st-md-mailman.stormreply.com"
	<linux-stm32@st-md-mailman.stormreply.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	Loic PALLARDY <loic.pallardy@st.com>,
	Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
	Ludovic BARRE <ludovic.barre@st.com>,
	Benjamin GAIGNARD <benjamin.gaignard@st.com>
Subject: Re: [PATCH v2 2/8] dt-bindings: remoteproc: add bindings for stm32 remote processor driver
Date: Tue, 30 Apr 2019 15:37:25 -0500	[thread overview]
Message-ID: <CAL_JsqJjMy43Juhse_PwRqjwjG2swkiJsQgagZWAb53an9B-6Q@mail.gmail.com> (raw)
In-Reply-To: <ff424530-6e7b-cec9-910f-1897d60de2a1@st.com>

On Tue, Apr 30, 2019 at 9:15 AM Fabien DESSENNE <fabien.dessenne@st.com> wrote:
>
> Hi Rob,
>
>
> On 30/04/2019 2:40 AM, Rob Herring wrote:
> > On Tue, Apr 16, 2019 at 04:58:13PM +0200, Fabien Dessenne wrote:
> >> Add the device tree bindings document for the stm32 remoteproc devices.
> >>
> >> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
> >> ---
> >>   .../devicetree/bindings/remoteproc/stm32-rproc.txt | 64 ++++++++++++++++++++++
> >>   1 file changed, 64 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt b/Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt
> >> new file mode 100644
> >> index 0000000..430132c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt
> >> @@ -0,0 +1,64 @@
> >> +STMicroelectronics STM32 Remoteproc
> >> +-----------------------------------
> >> +This document defines the binding for the remoteproc component that loads and
> >> +boots firmwares on the ST32MP family chipset.
> >> +
> >> +Required properties:
> >> +- compatible:       Must be "st,stm32mp1-m4"
> >> +- reg:              Address ranges of the remote processor dedicated memories.
> >> +            The parent node should provide an appropriate ranges property
> >> +            for properly translating these into bus addresses.
> > dma-ranges, but that's independent of 'reg'.
> >
> > It needs to list how many reg regions and what they are.
>
> The "reg" property needs to be removed since it is not used by the
> driver : the "memory-region" property (defined below) provides with all
> the needed memory information.

I'm not sure that's the right direction. reserved-memory nodes
generally should be in the range of system memory (i.e. what /memory
nodes define).

> Unfortunately, when I remove this "reg" property from the DeviceTree, I
> have this warning when building (W=123) the DTB:
>
>   "Warning (avoid_unnecessary_addr_size): /mlahb: unnecessary
> #address-cells/#size-cells without "ranges" or child "reg" property"
>
> IMHO, there is something wrong in the dtc script which seems to ignore
> the "dma-ranges" property that needs to have #address-cells/#size-cells
> defined. Just like "ranges".

Perhaps.

>
> The quick patch below (add check for "dma-ranges" ) in
> scripts/dtc/checks.c solves this issue.
>
> static void check_avoid_unnecessary_addr_size(struct check *c, struct
> dt_info *dti,
>                            struct node *node)
> {
> ...
>      if (get_property(node, "ranges") || get_property(node,
> "dma-ranges") || !node->children)
>          return;
> ...
>
> Can you confirm that I can remove the "reg" property and ignore the warning?

That should cause another warning because the 'simple-bus' checks
expect to have nodes with addresses as 'simple-bus' means MMIO bus.
That may have been the check which was broken for a while and I just
fixed not too long ago.

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Fabien DESSENNE <fabien.dessenne@st.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Loic PALLARDY <loic.pallardy@st.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ludovic BARRE <ludovic.barre@st.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	"linux-stm32@st-md-mailman.stormreply.com"
	<linux-stm32@st-md-mailman.stormreply.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Benjamin GAIGNARD <benjamin.gaignard@st.com>
Subject: Re: [PATCH v2 2/8] dt-bindings: remoteproc: add bindings for stm32 remote processor driver
Date: Tue, 30 Apr 2019 15:37:25 -0500	[thread overview]
Message-ID: <CAL_JsqJjMy43Juhse_PwRqjwjG2swkiJsQgagZWAb53an9B-6Q@mail.gmail.com> (raw)
In-Reply-To: <ff424530-6e7b-cec9-910f-1897d60de2a1@st.com>

On Tue, Apr 30, 2019 at 9:15 AM Fabien DESSENNE <fabien.dessenne@st.com> wrote:
>
> Hi Rob,
>
>
> On 30/04/2019 2:40 AM, Rob Herring wrote:
> > On Tue, Apr 16, 2019 at 04:58:13PM +0200, Fabien Dessenne wrote:
> >> Add the device tree bindings document for the stm32 remoteproc devices.
> >>
> >> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
> >> ---
> >>   .../devicetree/bindings/remoteproc/stm32-rproc.txt | 64 ++++++++++++++++++++++
> >>   1 file changed, 64 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt b/Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt
> >> new file mode 100644
> >> index 0000000..430132c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt
> >> @@ -0,0 +1,64 @@
> >> +STMicroelectronics STM32 Remoteproc
> >> +-----------------------------------
> >> +This document defines the binding for the remoteproc component that loads and
> >> +boots firmwares on the ST32MP family chipset.
> >> +
> >> +Required properties:
> >> +- compatible:       Must be "st,stm32mp1-m4"
> >> +- reg:              Address ranges of the remote processor dedicated memories.
> >> +            The parent node should provide an appropriate ranges property
> >> +            for properly translating these into bus addresses.
> > dma-ranges, but that's independent of 'reg'.
> >
> > It needs to list how many reg regions and what they are.
>
> The "reg" property needs to be removed since it is not used by the
> driver : the "memory-region" property (defined below) provides with all
> the needed memory information.

I'm not sure that's the right direction. reserved-memory nodes
generally should be in the range of system memory (i.e. what /memory
nodes define).

> Unfortunately, when I remove this "reg" property from the DeviceTree, I
> have this warning when building (W=123) the DTB:
>
>   "Warning (avoid_unnecessary_addr_size): /mlahb: unnecessary
> #address-cells/#size-cells without "ranges" or child "reg" property"
>
> IMHO, there is something wrong in the dtc script which seems to ignore
> the "dma-ranges" property that needs to have #address-cells/#size-cells
> defined. Just like "ranges".

Perhaps.

>
> The quick patch below (add check for "dma-ranges" ) in
> scripts/dtc/checks.c solves this issue.
>
> static void check_avoid_unnecessary_addr_size(struct check *c, struct
> dt_info *dti,
>                            struct node *node)
> {
> ...
>      if (get_property(node, "ranges") || get_property(node,
> "dma-ranges") || !node->children)
>          return;
> ...
>
> Can you confirm that I can remove the "reg" property and ignore the warning?

That should cause another warning because the 'simple-bus' checks
expect to have nodes with addresses as 'simple-bus' means MMIO bus.
That may have been the check which was broken for a while and I just
fixed not too long ago.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-04-30 20:37 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16 14:58 [PATCH v2 0/8] stm32 m4 remoteproc on STM32MP157c Fabien Dessenne
2019-04-16 14:58 ` Fabien Dessenne
2019-04-16 14:58 ` Fabien Dessenne
2019-04-16 14:58 ` Fabien Dessenne
2019-04-16 14:58 ` [PATCH v2 1/8] dt-bindings: stm32: add bindings for ML-AHB interconnect Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-29 23:13   ` Rob Herring
2019-04-29 23:13     ` Rob Herring
2019-04-29 23:13     ` Rob Herring
2019-04-16 14:58 ` [PATCH v2 2/8] dt-bindings: remoteproc: add bindings for stm32 remote processor driver Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-30  0:40   ` Rob Herring
2019-04-30  0:40     ` Rob Herring
2019-04-30 14:14     ` Fabien DESSENNE
2019-04-30 14:14       ` Fabien DESSENNE
2019-04-30 14:14       ` Fabien DESSENNE
2019-04-30 20:37       ` Rob Herring [this message]
2019-04-30 20:37         ` Rob Herring
2019-04-30 20:37         ` Rob Herring
2019-04-16 14:58 ` [PATCH v2 3/8] remoteproc: stm32: add an ST stm32_rproc driver Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58 ` [PATCH v2 4/8] ARM: dts: stm32: add m4 remoteproc support on STM32MP157c Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58 ` [PATCH v2 5/8] ARM: dts: stm32: declare copro reserved memories on STM32MP157c-ed1 Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58 ` [PATCH v2 6/8] ARM: dts: stm32: enable m4 coprocessor support " Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58 ` [PATCH v2 7/8] ARM: dts: stm32: declare copro reserved memories on STM32MP157a-dk1 Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58 ` [PATCH v2 8/8] ARM: dts: stm32: enable m4 coprocessor support " Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne
2019-04-16 14:58   ` Fabien Dessenne

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_JsqJjMy43Juhse_PwRqjwjG2swkiJsQgagZWAb53an9B-6Q@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=alexandre.torgue@st.com \
    --cc=arnaud.pouliquen@st.com \
    --cc=benjamin.gaignard@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabien.dessenne@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=loic.pallardy@st.com \
    --cc=ludovic.barre@st.com \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=ohad@wizery.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.