[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqJY8fzQ8=e=RHrtq1huucx6msqXJ+C6EcoaofBqRf9yLQ@mail.gmail.com>
Date: Tue, 7 Jan 2020 09:48:36 -0600
From: Rob Herring <robh@...nel.org>
To: Tero Kristo <t-kristo@...com>
Cc: Bjorn Andersson <bjorn.andersson@...aro.org>,
Ohad Ben-Cohen <ohad@...ery.com>,
"open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM"
<linux-remoteproc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
linux-omap <linux-omap@...r.kernel.org>,
Suman Anna <s-anna@...com>, devicetree@...r.kernel.org
Subject: Re: [RESEND PATCHv4 01/14] dt-bindings: remoteproc: Add OMAP
remoteproc bindings
On Tue, Jan 7, 2020 at 5:01 AM Tero Kristo <t-kristo@...com> wrote:
>
> On 04/01/2020 01:38, Rob Herring wrote:
> > On Thu, Jan 02, 2020 at 03:25:12PM +0200, Tero Kristo wrote:
> >> From: Suman Anna <s-anna@...com>
> >>
> >> Add the device tree bindings document for the IPU and DSP
> >> remote processor devices on OMAP4+ SoCs.
> >>
> >> Cc: Rob Herring <robh@...nel.org>
> >> Cc: devicetree@...r.kernel.org
> >> Signed-off-by: Suman Anna <s-anna@...com>
> >> [t-kristo@...com: converted to schema]
> >> Signed-off-by: Tero Kristo <t-kristo@...com>
> >> ---
> >> v4: added ti,bootreg-shift and ti,autosuspend-delay properties
> >>
> >> .../remoteproc/ti,omap-remoteproc.yaml | 329 ++++++++++++++++++
> >> 1 file changed, 329 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
> >> + reg:
> >> + description: |
> >> + Address space for any remoteproc memories present on
> >> + the SoC. Should contain an entry for each value in
> >> + 'reg-names'. These are mandatory for all DSP and IPU
> >> + processors that have them (OMAP4/OMAP5 DSPs do not have
> >> + any RAMs)
> >> +
> >> + reg-names:
> >> + description: |
> >> + Required names for each of the address spaces defined in
> >> + the 'reg' property. Should contain a string from among
> >> + the following names, each representing the corresponding
> >> + internal RAM memory region.
> >
> > The schema is more constrained than 'a string from among the following
> > names'. 'l2ram' is the only valid 1st entry for example.
>
> Right, I wasn't able to figure out a way to make the schema more
> flexible, so I will just modify the description above.
The goal is somewhat to not be flexible as we want the possible
combinations defined. If it is a manageable number of combinations,
just list them out under a 'oneOf'.
Not encouraged, but it is possible to define any length and order of
values (note 'items' is not a list here):
items:
enum: [ ... ]
Rob
Powered by blists - more mailing lists