Hi All,
The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
There are 3 foundation component for PRUSS subsystem: the PRUSS platform driver,
the PRUSS INTC driver and the PRUSS remoteproc driver. Two first were already
merged and can be found under:
1) drivers/soc/ti/pruss.c
Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
2) drivers/irqchip/irq-pruss-intc.c
Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
The third one [1] was accepted and applied to andersson/remoteproc.git
(refs/heads/for-next): [2] but is not merged yet.
The programmable nature of the PRUs provide flexibility to implement custom
peripheral interfaces, fast real-time responses, or specialized data handling.
Example of a PRU consumer drivers will be:
- Software UART over PRUSS
- PRU-ICSS Ethernet EMAC
In order to make usage of common PRU resources and allow the consumer drivers to
configure the PRU hardware for specific usage the PRU API is introduced.
This patch set depends on not merged (but applied to remoteproc/for-next) PRUSS
remoteproc driver [1][2] and two remoteproc related patches [3] and [4].
[1] https://patchwork.kernel.org/project/linux-arm-kernel/cover/[email protected]/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git/commit/?h=for-next&id=b44786c9bdc46eac8388843f0a6116369cb18bca
[3] https://patchwork.kernel.org/project/linux-remoteproc/patch/[email protected]/
[4] https://patchwork.kernel.org/project/linux-remoteproc/patch/[email protected]/
Best regards,
Grzegorz
Roger Quadros (1):
remoteproc: pru: Add pru_rproc_set_ctable() function
Suman Anna (2):
dt-bindings: remoteproc: Add PRU consumer bindings
remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
Tero Kristo (2):
remoteproc: pru: Add APIs to get and put the PRU cores
remoteproc: pru: Configure firmware based on client setup
.../bindings/remoteproc/ti,pru-consumer.yaml | 64 +++++
drivers/remoteproc/pru_rproc.c | 221 +++++++++++++++++-
include/linux/pruss.h | 78 +++++++
3 files changed, 360 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
create mode 100644 include/linux/pruss.h
--
2.29.0
From: Suman Anna <[email protected]>
Add a YAML binding document for PRU consumers. The binding includes
all the common properties that can be used by different PRU consumer
or application nodes and supported by the PRU remoteproc driver.
These are used to configure the PRU hardware for specific user
applications.
The application nodes themselves should define their own bindings.
Co-developed-by: Tero Kristo <[email protected]>
Signed-off-by: Tero Kristo <[email protected]>
Signed-off-by: Suman Anna <[email protected]>
Co-developed-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Grzegorz Jaszczyk <[email protected]>
---
.../bindings/remoteproc/ti,pru-consumer.yaml | 64 +++++++++++++++++++
1 file changed, 64 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
new file mode 100644
index 000000000000..2c5c5e2b6159
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common TI PRU Consumer Binding
+
+maintainers:
+ - Suman Anna <[email protected]>
+
+description: |
+ A PRU application/consumer/user node typically uses one or more PRU device
+ nodes to implement a PRU application/functionality. Each application/client
+ node would need a reference to at least a PRU node, and optionally define
+ some properties needed for hardware/firmware configuration. The below
+ properties are a list of common properties supported by the PRU remoteproc
+ infrastructure.
+
+ The application nodes shall define their own bindings like regular platform
+ devices, so below are in addition to each node's bindings.
+
+properties:
+ prus:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: phandles to the PRU, RTU or Tx_PRU nodes used
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description: |
+ firmwares for the PRU cores, the default firmware for the core from
+ the PRU node will be used if not provided. The firmware names should
+ correspond to the PRU cores listed in the 'prus' property
+
+ ti,pruss-gp-mux-sel:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ enum: [0, 1, 2, 3, 4]
+ description: |
+ array of values for the GP_MUX_SEL under PRUSS_GPCFG register for a PRU.
+ This selects the internal muxing scheme for the PRU instance. Values
+ should correspond to the PRU cores listed in the 'prus' property. The
+ GP_MUX_SEL setting is a per-slice setting (one setting for PRU0, RTU0,
+ and Tx_PRU0 on K3 SoCs). Use the same value for all cores within the
+ same slice in the associative array. If the array size is smaller than
+ the size of 'prus' property, the default out-of-reset value (0) for the
+ PRU core is used.
+
+required:
+ - prus
+
+dependencies:
+ firmware-name: [ prus ]
+ ti,pruss-gp-mux-sel: [ prus ]
+
+additionalProperties: true
+
+examples:
+ - |
+ /* PRU application node example */
+ pru-app {
+ prus = <&pru0>, <&pru1>;
+ firmware-name = "pruss-app-fw0", "pruss-app-fw1";
+ ti,pruss-gp-mux-sel = <2>, <1>;
+ };
--
2.29.0
From: Tero Kristo <[email protected]>
Client device node property firmware-name is now used to configure
firmware for the PRU instances. The default firmware is also
restored once releasing the PRU resource.
Co-developed-by: Suman Anna <[email protected]>
Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Tero Kristo <[email protected]>
Co-developed-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Grzegorz Jaszczyk <[email protected]>
---
drivers/remoteproc/pru_rproc.c | 35 ++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index ac13e4452a57..fed7a2051ebf 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -170,6 +170,23 @@ void pru_control_set_reg(struct pru_rproc *pru, unsigned int reg,
spin_unlock_irqrestore(&pru->rmw_lock, flags);
}
+/**
+ * pru_rproc_set_firmware() - set firmware for a pru core
+ * @rproc: the rproc instance of the PRU
+ * @fw_name: the new firmware name, or NULL if default is desired
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int pru_rproc_set_firmware(struct rproc *rproc, const char *fw_name)
+{
+ struct pru_rproc *pru = rproc->priv;
+
+ if (!fw_name)
+ fw_name = pru->fw_name;
+
+ return rproc_set_firmware(rproc, fw_name);
+}
+
static struct rproc *__pru_rproc_get(struct device_node *np, int index)
{
struct device_node *rproc_np = NULL;
@@ -230,6 +247,8 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
struct rproc *rproc;
struct pru_rproc *pru;
struct device *dev;
+ const char *fw_name;
+ int ret;
rproc = __pru_rproc_get(np, index);
if (IS_ERR(rproc))
@@ -254,7 +273,21 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
if (pru_id)
*pru_id = pru->id;
+ ret = of_property_read_string_index(np, "firmware-name", index,
+ &fw_name);
+ if (!ret) {
+ ret = pru_rproc_set_firmware(rproc, fw_name);
+ if (ret) {
+ dev_err(dev, "failed to set firmware: %d\n", ret);
+ goto err;
+ }
+ }
+
return rproc;
+
+err:
+ pru_rproc_put(rproc);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(pru_rproc_get);
@@ -276,6 +309,8 @@ void pru_rproc_put(struct rproc *rproc)
if (!pru->client_np)
return;
+ pru_rproc_set_firmware(rproc, NULL);
+
mutex_lock(&pru->lock);
pru->client_np = NULL;
rproc->deny_sysfs_ops = false;
--
2.29.0
From: Suman Anna <[email protected]>
The PRU remoteproc driver is not configured for 'auto-boot' by default,
and allows to be booted either by in-kernel PRU client drivers or by
userspace using the generic remoteproc sysfs interfaces. The sysfs
interfaces should not be permitted to change the remoteproc firmwares
or states when a PRU is being managed by an in-kernel client driver.
Use the newly introduced remoteproc generic 'deny_sysfs_ops' flag to
provide these restrictions by setting and clearing it appropriately
during the PRU acquire and release steps.
Signed-off-by: Suman Anna <[email protected]>
Co-developed-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Grzegorz Jaszczyk <[email protected]>
---
drivers/remoteproc/pru_rproc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index cc2e585778b1..bfb53967edda 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -228,6 +228,7 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
}
pru->client_np = np;
+ rproc->deny_sysfs_ops = true;
mutex_unlock(&pru->lock);
@@ -258,6 +259,7 @@ void pru_rproc_put(struct rproc *rproc)
mutex_lock(&pru->lock);
pru->client_np = NULL;
+ rproc->deny_sysfs_ops = false;
mutex_unlock(&pru->lock);
put_device(&rproc->dev);
--
2.29.0
On Wed, Dec 16, 2020 at 9:55 AM Grzegorz Jaszczyk
<[email protected]> wrote:
>
> Hi Rob,
>
> On Mon, 14 Dec 2020 at 23:58, Rob Herring <[email protected]> wrote:
> >
> > On Fri, Dec 11, 2020 at 03:29:29PM +0100, Grzegorz Jaszczyk wrote:
> > > From: Suman Anna <[email protected]>
> > >
> > > Add a YAML binding document for PRU consumers. The binding includes
> > > all the common properties that can be used by different PRU consumer
> > > or application nodes and supported by the PRU remoteproc driver.
> > > These are used to configure the PRU hardware for specific user
> > > applications.
> > >
> > > The application nodes themselves should define their own bindings.
> > >
> > > Co-developed-by: Tero Kristo <[email protected]>
> > > Signed-off-by: Tero Kristo <[email protected]>
> > > Signed-off-by: Suman Anna <[email protected]>
> > > Co-developed-by: Grzegorz Jaszczyk <[email protected]>
> > > Signed-off-by: Grzegorz Jaszczyk <[email protected]>
> > > ---
> > > .../bindings/remoteproc/ti,pru-consumer.yaml | 64 +++++++++++++++++++
> > > 1 file changed, 64 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > new file mode 100644
> > > index 000000000000..2c5c5e2b6159
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > @@ -0,0 +1,64 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Common TI PRU Consumer Binding
> > > +
> > > +maintainers:
> > > + - Suman Anna <[email protected]>
> > > +
> > > +description: |
> > > + A PRU application/consumer/user node typically uses one or more PRU device
> > > + nodes to implement a PRU application/functionality. Each application/client
> > > + node would need a reference to at least a PRU node, and optionally define
> > > + some properties needed for hardware/firmware configuration. The below
> > > + properties are a list of common properties supported by the PRU remoteproc
> > > + infrastructure.
> > > +
> > > + The application nodes shall define their own bindings like regular platform
> > > + devices, so below are in addition to each node's bindings.
> > > +
> > > +properties:
> > > + prus:
> >
> > ti,prus
>
> Thank you - I will change and post v2 but with this I will run into
> issues when this binding will be referenced by some consumer YAML
> binding. Running dtbs_check in such case throws:
> ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' does not
> match any of the regexes: 'pinctrl-[0-9]+'
> In the same time if I will remove this property from that node I am getting:
> ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' is a required property
> as expected.
Sounds like you didn't update 'ti,prus' in whatever schema you include
this one from.
>
> Getting rid of the comma from this property name workarounds mentioned
> problem (which is not proper but allows me to correctly test this
> binding): e.g. s/ti,prus/ti-pruss/ or using the previous name without
> a comma.
> It seems to be an issue with dtbs_check itself which we will encounter
> in the future.
If not, can you point me to a branch having this problem.
Rob
Hi Rob,
On Fri, 18 Dec 2020 at 23:51, Rob Herring <[email protected]> wrote:
>
> On Wed, Dec 16, 2020 at 9:55 AM Grzegorz Jaszczyk
> <[email protected]> wrote:
> >
> > Hi Rob,
> >
> > On Mon, 14 Dec 2020 at 23:58, Rob Herring <[email protected]> wrote:
> > >
> > > On Fri, Dec 11, 2020 at 03:29:29PM +0100, Grzegorz Jaszczyk wrote:
> > > > From: Suman Anna <[email protected]>
> > > >
> > > > Add a YAML binding document for PRU consumers. The binding includes
> > > > all the common properties that can be used by different PRU consumer
> > > > or application nodes and supported by the PRU remoteproc driver.
> > > > These are used to configure the PRU hardware for specific user
> > > > applications.
> > > >
> > > > The application nodes themselves should define their own bindings.
> > > >
> > > > Co-developed-by: Tero Kristo <[email protected]>
> > > > Signed-off-by: Tero Kristo <[email protected]>
> > > > Signed-off-by: Suman Anna <[email protected]>
> > > > Co-developed-by: Grzegorz Jaszczyk <[email protected]>
> > > > Signed-off-by: Grzegorz Jaszczyk <[email protected]>
> > > > ---
> > > > .../bindings/remoteproc/ti,pru-consumer.yaml | 64 +++++++++++++++++++
> > > > 1 file changed, 64 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > new file mode 100644
> > > > index 000000000000..2c5c5e2b6159
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > @@ -0,0 +1,64 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Common TI PRU Consumer Binding
> > > > +
> > > > +maintainers:
> > > > + - Suman Anna <[email protected]>
> > > > +
> > > > +description: |
> > > > + A PRU application/consumer/user node typically uses one or more PRU device
> > > > + nodes to implement a PRU application/functionality. Each application/client
> > > > + node would need a reference to at least a PRU node, and optionally define
> > > > + some properties needed for hardware/firmware configuration. The below
> > > > + properties are a list of common properties supported by the PRU remoteproc
> > > > + infrastructure.
> > > > +
> > > > + The application nodes shall define their own bindings like regular platform
> > > > + devices, so below are in addition to each node's bindings.
> > > > +
> > > > +properties:
> > > > + prus:
> > >
> > > ti,prus
> >
> > Thank you - I will change and post v2 but with this I will run into
> > issues when this binding will be referenced by some consumer YAML
> > binding. Running dtbs_check in such case throws:
> > ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' does not
> > match any of the regexes: 'pinctrl-[0-9]+'
> > In the same time if I will remove this property from that node I am getting:
> > ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' is a required property
> > as expected.
>
> Sounds like you didn't update 'ti,prus' in whatever schema you include
> this one from.
>
> >
> > Getting rid of the comma from this property name workarounds mentioned
> > problem (which is not proper but allows me to correctly test this
> > binding): e.g. s/ti,prus/ti-pruss/ or using the previous name without
> > a comma.
> > It seems to be an issue with dtbs_check itself which we will encounter
> > in the future.
>
> If not, can you point me to a branch having this problem.
Sure, here is temporary branch with 4 last commits demonstrating
mentioned issues (when property name contains comma):
https://git.linaro.org/people/grzegorz.jaszczyk/linux.git/log/?h=ti-pruss-binding-issue
The last commit gets rid of the comma from properties names which
successfully w/a the problem.
Please note that those are only TEMP commits which demonstrates the
mentioned issue. I've put error logs with some notes in commit log to
ease understanding what issues are seen when.
Thank you in advance,
Grzegorz
On Tue, Dec 22, 2020 at 8:57 AM Grzegorz Jaszczyk
<[email protected]> wrote:
>
> Hi Rob,
>
> On Fri, 18 Dec 2020 at 23:51, Rob Herring <[email protected]> wrote:
> >
> > On Wed, Dec 16, 2020 at 9:55 AM Grzegorz Jaszczyk
> > <[email protected]> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Mon, 14 Dec 2020 at 23:58, Rob Herring <[email protected]> wrote:
> > > >
> > > > On Fri, Dec 11, 2020 at 03:29:29PM +0100, Grzegorz Jaszczyk wrote:
> > > > > From: Suman Anna <[email protected]>
> > > > >
> > > > > Add a YAML binding document for PRU consumers. The binding includes
> > > > > all the common properties that can be used by different PRU consumer
> > > > > or application nodes and supported by the PRU remoteproc driver.
> > > > > These are used to configure the PRU hardware for specific user
> > > > > applications.
> > > > >
> > > > > The application nodes themselves should define their own bindings.
> > > > >
> > > > > Co-developed-by: Tero Kristo <[email protected]>
> > > > > Signed-off-by: Tero Kristo <[email protected]>
> > > > > Signed-off-by: Suman Anna <[email protected]>
> > > > > Co-developed-by: Grzegorz Jaszczyk <[email protected]>
> > > > > Signed-off-by: Grzegorz Jaszczyk <[email protected]>
> > > > > ---
> > > > > .../bindings/remoteproc/ti,pru-consumer.yaml | 64 +++++++++++++++++++
> > > > > 1 file changed, 64 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..2c5c5e2b6159
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > > @@ -0,0 +1,64 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Common TI PRU Consumer Binding
> > > > > +
> > > > > +maintainers:
> > > > > + - Suman Anna <[email protected]>
> > > > > +
> > > > > +description: |
> > > > > + A PRU application/consumer/user node typically uses one or more PRU device
> > > > > + nodes to implement a PRU application/functionality. Each application/client
> > > > > + node would need a reference to at least a PRU node, and optionally define
> > > > > + some properties needed for hardware/firmware configuration. The below
> > > > > + properties are a list of common properties supported by the PRU remoteproc
> > > > > + infrastructure.
> > > > > +
> > > > > + The application nodes shall define their own bindings like regular platform
> > > > > + devices, so below are in addition to each node's bindings.
> > > > > +
> > > > > +properties:
> > > > > + prus:
> > > >
> > > > ti,prus
> > >
> > > Thank you - I will change and post v2 but with this I will run into
> > > issues when this binding will be referenced by some consumer YAML
> > > binding. Running dtbs_check in such case throws:
> > > ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' does not
> > > match any of the regexes: 'pinctrl-[0-9]+'
> > > In the same time if I will remove this property from that node I am getting:
> > > ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' is a required property
> > > as expected.
> >
> > Sounds like you didn't update 'ti,prus' in whatever schema you include
> > this one from.
> >
> > >
> > > Getting rid of the comma from this property name workarounds mentioned
> > > problem (which is not proper but allows me to correctly test this
> > > binding): e.g. s/ti,prus/ti-pruss/ or using the previous name without
> > > a comma.
> > > It seems to be an issue with dtbs_check itself which we will encounter
> > > in the future.
> >
> > If not, can you point me to a branch having this problem.
>
> Sure, here is temporary branch with 4 last commits demonstrating
> mentioned issues (when property name contains comma):
> https://git.linaro.org/people/grzegorz.jaszczyk/linux.git/log/?h=ti-pruss-binding-issue
>
> The last commit gets rid of the comma from properties names which
> successfully w/a the problem.
>
> Please note that those are only TEMP commits which demonstrates the
> mentioned issue. I've put error logs with some notes in commit log to
> ease understanding what issues are seen when.
The problem is any property with a vendor prefix has to define a type.
There's not a way to define a 'common vendor property' and distinguish
both cases in the meta-schemas. I'd like to come up with a more robust
mechanism where we just detect if a property has a defined type or
not. It should be possible to extract that. (Related, I also want to
check for conflicting types.)
How many cases of 'ti,prus' do you expect to have and what's the range
of number of phandles? Either you should just not have the common
schema and just define the properties in each consumer or don't put
additional constraints into the consumer schemas (i.e omit the
properties in 'properties' and use 'unevaluatedProperties').
Also, I think you can get rid of 'ti,pruss-gp-mux-sel'. Can't it just
be an arg cell in 'ti,prus' entries?
Rob
> Also, I think you can get rid of 'ti,pruss-gp-mux-sel'. Can't it just
> be an arg cell in 'ti,prus' entries?
>
> Rob
+1 for using cells instead of a separate property.
FYI, we will have a similar issue with the PRUSSEVTSEL signal for the
interrupt controller on the AM18XX. I am still of the opinion (described
in more detail at [1]) that using a cell for this makes for both better
device tree bindings and easier driver implementation. So I am interested
to see what the resolution is here.
[1]: https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/