* [PATCH v7 01/20] dt-bindings: mtd: Document nand-ecc-placement
From: Miquel Raynal @ 2020-05-29 0:24 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Boris Brezillon, Thomas Petazzoni, Paul Cercueil, Chuanhong Guo,
Weijie Gao, linux-arm-kernel, Mason Yang, Julien Su,
Miquel Raynal
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
This optional property defines where the ECC bytes are expected to be
stored. No value defaults to an unknown location, while these
locations can be explicitly set to OOB or interleaved depending if
the ECC bytes are entirely stored in the OOB area or mixed with
regular data in the main area (also sometimes referred as
"syndrome").
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
.../devicetree/bindings/mtd/nand-controller.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index d261b7096c69..4a0798247d2d 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -56,6 +56,16 @@ patternProperties:
(Linux will handle the calculations). soft_bch is deprecated
and should be replaced by soft and nand-ecc-algo.
+ nand-ecc-placement:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ oob, interleaved ]
+ description:
+ Location of the ECC bytes. This location is unknown by default
+ but can be explicitly set to "oob", if all ECC bytes are
+ known to be stored in the OOB area, or "interleaved" if ECC
+ bytes will be interleaved with regular data in the main area.
+
nand-ecc-algo:
allOf:
- $ref: /schemas/types.yaml#/definitions/string
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Suman Anna @ 2020-05-29 0:23 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <594b649d-eca6-1cd4-3621-c8297a6a9492@ti.com>
Hi Rob,
On 5/28/20 5:47 PM, Suman Anna wrote:
> Hi Rob,
>
> On 5/28/20 5:32 PM, Rob Herring wrote:
>> On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
>>> Some Texas Instruments K3 family of SoCs have one of more Digital Signal
>>> Processor (DSP) subsystems that are comprised of either a TMS320C66x
>>> CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
>>> Add the device tree bindings document for the C66x DSP devices on these
>>> SoCs. The added example illustrates the DT nodes for the first C66x DSP
>>> device present on the K3 J721E family of SoCs.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>> v2:
>>> - Updated the example to include the root-node to fix the bot
>>> errors from v1
>>
>> Pretty sure that was not why you had errors.
>
> It is because of the default values used for #address-cells and
> #size-cells in the example_template and example_start variables used in
> the dt-extract-example script. They are 1 by default, so the generated
> template ended up with the root-node using 1, and the actual example
> using 2 resulting in the mismatch.
>
> When I updated the script to use 2 for both #address-cells and
> #size-cells, then the warnings go away. This is the reason, dtbs_check
> on my actual dts files goes through fine.
Just to clarify, the warnings were only because of the mismatched
'ranges'. If I limit the example to just the dsp node, eliminating all
ranges usage, then it passes fine.
So, you would see this with any example that uses ranges with
#address-cells and #size-cells as 2 without explicitly using the
appropriate top-level #address-cells and #size-cells.
>
>>
>>> - Added maxItems to resets, mboxes, memory-region, sram properties
>>> - Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
>>> - Addressed the minor review comments from Mathieu
>>> v1: https://patchwork.kernel.org/patch/11458571/
>>>
>>> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 ++++++++++++++++++
>>> 1 file changed, 190 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>> b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>> new file mode 100644
>>> index 000000000000..cdf649655838
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>> @@ -0,0 +1,190 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: TI K3 DSP devices
>>> +
>>> +maintainers:
>>> + - Suman Anna <s-anna@ti.com>
>>> +
>>> +description: |
>>> + The TI K3 family of SoCs usually have one or more TI DSP Core
>>> sub-systems
>>> + that are used to offload some of the processor-intensive tasks or
>>> algorithms,
>>> + for achieving various system level goals.
>>> +
>>> + These processor sub-systems usually contain additional sub-modules
>>> like
>>> + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external
>>> memory
>>> + controller, a dedicated local power/sleep controller etc. The DSP
>>> processor
>>> + cores in the K3 SoCs are usually either a TMS320C66x CorePac
>>> processor or a
>>> + TMS320C71x CorePac processor.
>>> +
>>> + Each DSP Core sub-system is represented as a single DT node. Each
>>> node has a
>>> + number of required or optional properties that enable the OS
>>> running on the
>>> + host processor (Arm CorePac) to perform the device management of
>>> the remote
>>> + processor and to communicate with the remote processor.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: ti,j721e-c66-dsp
>>> + description:
>>> + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
>>
>> What else are you going to use? There's only one compatible string. Drop
>> description.
>
> Is updated in a subsequent binding update where I added the C71 support.
See https://patchwork.kernel.org/patch/11563231/.
Let me know if you prefer that I combine both of them. Any changes to
this patch will also affect the other.
>
>>
>>> +
>>> + reg:
>>> + description: |
>>> + Should contain an entry for each value in 'reg-names'.
>>> + Each entry should have the memory region's start address
>>> + and the size of the region, the representation matching
>>> + the parent node's '#address-cells' and '#size-cells' values.
>>
>> Don't need generic descriptions. That's every 'reg'.
>>
>> What you can do is an 'items' list describing what each region is.
>
> OK, I am bit confused here. I have listed the items under the reg-names,
> while using just the minItems or maxItems here. What is the convention,
> aren't reg and reg-names associative.
>
>>
>>> + minItems: 3
>>> + maxItems: 3
>>> +
>>> + reg-names:
>>> + description: |
>>> + Should contain strings with the names of the specific internal
>>> + memory regions, and should be defined in this order
>>
>> Again, drop.
>
> OK
>
>>
>>> + maxItems: 3
>>> + items:
>>> + - const: l2sram
>>> + - const: l1pram
>>> + - const: l1dram
>>> +
>>> + ti,sci:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description:
>>> + Should be a phandle to the TI-SCI System Controller node
>>> +
>>> + ti,sci-dev-id:
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + description: |
>>> + Should contain the TI-SCI device id corresponding to the DSP
>>> core.
>>> + Please refer to the corresponding System Controller documentation
>>> + for valid values for the DSP cores.
>>> +
>>> + ti,sci-proc-ids:
>>> + description: Should contain a single tuple of <proc_id host_id>.
>>> + allOf:
>>> + - $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + - maxItems: 1
>>> + items:
>>> + items:
>>> + - description: TI-SCI processor id for the DSP core device
>>> + - description: TI-SCI host id to which processor control
>>> + ownership should be transferred to
>>
>> I assume these properties appear in multiple TI nodes? We don't need
>> them defined multiple times. Create a schema for them that you can
>> include here.
>
> Only the remoteprocs, so they are limited to this binding and one more
> R5F remoteproc binding.
Can you confirm if these are the properties you want moved - ti,sci,
ti,sci-dev-id and ti,sci-proc-ids? Any recommended path I should be
using, is remoteproc folder still fine for this?
regards
Suman
>
>>
>>> +
>>> + resets:
>>> + description: |
>>> + Should contain the phandle to the reset controller node
>>> + managing the local resets for this device, and a reset
>>> + specifier. Please refer to the following reset bindings
>>> + for the reset argument specifier,
>>> + Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>>
>> Drop.
>
> Entire description or just the reference to the reset bindings file?
>
>>
>>> + maxItems: 1
>>> +
>>> + firmware-name:
>>> + description: |
>>> + Should contain the name of the default firmware image
>>> + file located on the firmware search path
>>> +
>>> + mboxes:
>>> + description: |
>>> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
>>> + communication with the remote processor. This property should
>>> match
>>> + with the sub-mailbox node used in the firmware image. The
>>> specifier
>>> + format is as per the bindings,
>>> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>>
>> Drop. What mailbox provider is used is outside the scope of this
>> binding.
>
> OK.
>
>>
>>> + maxItems: 1
>>> +
>>> + memory-region:
>>> + minItems: 2
>>> + maxItems: 8
>>> + description: |
>>> + phandle to the reserved memory nodes to be associated with the
>>> remoteproc
>>> + device. There should be at least two reserved memory nodes
>>> defined - the
>>> + first one would be used for dynamic DMA allocations like
>>> vrings and vring
>>> + buffers, and the remaining ones used for the firmware image
>>> sections. The
>>> + reserved memory nodes should be carveout nodes, and should be
>>> defined as
>>> + per the bindings in
>>> +
>>> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>>
>> items:
>> - description: dynamic DMA allocations like vrings and vring buffers
>> - description: firmware image section ???
>> - description: firmware image section ???
>
> Yeah, this is scalable if we will have multiple separate DDR regions. I
> had to choose a decent maxItems value, so I chose 8. Wouldn't listing
> the individual items override the number of minItems/maxItems?
>
>>
>>> +
>>> +# Optional properties:
>>> +# --------------------
>>> +
>>> + sram:
>>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>>> + minItems: 1
>>> + maxItems: 4
>>> + description: |
>>> + phandles to one or more reserved on-chip SRAM regions. The
>>> regions
>>> + should be defined as child nodes of the respective SRAM node, and
>>> + should be defined as per the generic bindings in,
>>> + Documentation/devicetree/bindings/sram/sram.yaml
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - reg-names
>>> + - ti,sci
>>> + - ti,sci-dev-id
>>> + - ti,sci-proc-ids
>>> + - resets
>>> + - firmware-name
>>> + - mboxes
>>> + - memory-region
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + / {
>>> + model = "Texas Instruments K3 J721E SoC";
>>> + compatible = "ti,j721e";
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + /* DSP Carveout reserved memory nodes */
>>> + reserved-memory {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + c66_0_dma_memory_region: c66-dma-memory@a6000000 {
>>> + compatible = "shared-dma-pool";
>>> + reg = <0x00 0xa6000000 0x00 0x100000>;
>>> + no-map;
>>> + };
>>> +
>>> + c66_0_memory_region: c66-memory@a6100000 {
>>> + compatible = "shared-dma-pool";
>>> + reg = <0x00 0xa6100000 0x00 0xf00000>;
>>> + no-map;
>>> + };
>>> + };
>>
>> Drop all of this. Outside the scope of this binding. And will likely
>> start failing validation as schemas become more complete.
>
> This is a complete example because of the memory-region references below.
>
>>
>>> +
>>> + cbass_main: bus@100000 {
>>
>> Drop unused labels.
>
> OK.
>
> regards
> Suman
>
>>
>>> + compatible = "simple-bus";
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges = <0x00 0x00100000 0x00 0x00100000 0x00
>>> 0x00020000>, /* ctrl mmr */
>>> + <0x4d 0x80800000 0x4d 0x80800000 0x00
>>> 0x00800000>, /* C66_0 */
>>> + <0x4d 0x81800000 0x4d 0x81800000 0x00
>>> 0x00800000>; /* C66_1 */
>>> +
>>> + /* J721E C66_0 DSP node */
>>> + c66_0: dsp@4d80800000 {
>>> + compatible = "ti,j721e-c66-dsp";
>>> + reg = <0x4d 0x80800000 0x00 0x00048000>,
>>> + <0x4d 0x80e00000 0x00 0x00008000>,
>>> + <0x4d 0x80f00000 0x00 0x00008000>;
>>> + reg-names = "l2sram", "l1pram", "l1dram";
>>> + ti,sci = <&dmsc>;
>>> + ti,sci-dev-id = <142>;
>>> + ti,sci-proc-ids = <0x03 0xFF>;
>>> + resets = <&k3_reset 142 1>;
>>> + firmware-name = "j7-c66_0-fw";
>>> + memory-region = <&c66_0_dma_memory_region>,
>>> + <&c66_0_memory_region>;
>>> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
>>> + };
>>> + };
>>> + };
>>> --
>>> 2.26.0
>>>
>
^ permalink raw reply
* Re: [PATCH v4 16/16] dt-bindings: spi: Convert DW SPI binding to DT schema
From: Rob Herring @ 2020-05-28 23:28 UTC (permalink / raw)
To: Serge Semin
Cc: Alexey Malahov, Ralf Baechle, Georgy Vlasov, linux-kernel,
Mark Brown, Paul Burton, Arnd Bergmann, linux-spi,
Wan Ahmad Zainie, linux-mips, devicetree, Thomas Bogendoerfer,
Serge Semin, Rob Herring, Gareth Williams, Andy Shevchenko,
Ramil Zaripov
In-Reply-To: <20200522000806.7381-17-Sergey.Semin@baikalelectronics.ru>
On Fri, 22 May 2020 03:08:05 +0300, Serge Semin wrote:
> Modern device tree bindings are supposed to be created as YAML-files
> in accordance with dt-schema. This commit replaces two DW SPI legacy
> bare text bindings with YAML file. As before the bindings file states
> that the corresponding dts node is supposed to be compatible either
> with generic DW APB SSI controller or with Microsemi/Amazon/Renesas/Intel
> vendors-specific controllers, to have registers, interrupts and clocks
> properties. Though in case of Microsemi version of the controller
> there must be two registers resources specified. Properties like
> clock-names, reg-io-width, cs-gpio, num-cs, DMA and slave device
> sub-nodes are optional.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
> ---
> .../bindings/spi/snps,dw-apb-ssi.txt | 44 ------
> .../bindings/spi/snps,dw-apb-ssi.yaml | 127 ++++++++++++++++++
> .../devicetree/bindings/spi/spi-dw.txt | 24 ----
> 3 files changed, 127 insertions(+), 68 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> create mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> delete mode 100644 Documentation/devicetree/bindings/spi/spi-dw.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 18/18] mtd: rawnand: Move generic bits to the ECC framework
From: Miquel Raynal @ 2020-05-28 23:55 UTC (permalink / raw)
To: Boris Brezillon
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
In-Reply-To: <20200528175656.0a32dd7c@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 17:56:56 +0200:
> On Thu, 28 May 2020 13:31:13 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > +/**
> > + * nanddev_get_flash_node() - Get the device node attached to a NAND device
> > + * @nand: NAND device
> > + *
> > + * Return: the device node linked to @nand.
> > + */
> > +static inline struct device_node *nanddev_get_flash_node(struct nand_device *nand)
> > +{
> > + return mtd_get_of_node(nanddev_to_mtd(nand));
> > +}
> > +
>
> Can we name that one nanddev_get_of_node(). We'll probably want to
> expose fwnode at some point, and get_flash_node() is a bit too generic
> IMO.
I just spot that there is a nanddev_get_of_node() function already,
which does exactly the same as nanddev_get_flash_node(), so I just
dropped it.
^ permalink raw reply
* Re: [PATCH] clk: qcom: Add missing msm8998 ufs_unipro_core_clk_src
From: Stephen Boyd @ 2020-05-28 23:54 UTC (permalink / raw)
To: Jeffrey Hugo, mturquette, robh+dt
Cc: agross, bjorn.andersson, linux-arm-msm, linux-clk, linux-kernel,
devicetree, Jeffrey Hugo
In-Reply-To: <20200528142205.44003-1-jeffrey.l.hugo@gmail.com>
Quoting Jeffrey Hugo (2020-05-28 07:22:05)
> ufs_unipro_core_clk_src is required to allow UFS to clock scale for power
> savings.
>
> Fixes: b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) driver")
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v1 1/2] Add YAML schema for a new PWM driver
From: Rob Herring @ 2020-05-28 23:31 UTC (permalink / raw)
To: Rahul Tanwar
Cc: thierry.reding, u.kleine-koenig, p.zabel, linux-pwm, linux-kernel,
devicetree, andriy.shevchenko, songjun.Wu, cheol.yong.kim,
qi-ming.wu
In-Reply-To: <53333e2a30f123065a68a3a24042ead982393164.1590132733.git.rahul.tanwar@linux.intel.com>
On Fri, May 22, 2020 at 03:41:58PM +0800, Rahul Tanwar wrote:
> Add DT bindings YAML schema for PWM controller driver of
> Lightning Mountain(LGM) SoC.
You need a better subject such as what h/w this is for. Bindings are for
h/w blocks, not drivers.
>
> Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
> ---
> .../devicetree/bindings/pwm/pwm-intel-lgm.yaml | 43 ++++++++++++++++++++++
Use the compatible string for filename.
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-intel-lgm.yaml
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-intel-lgm.yaml b/Documentation/devicetree/bindings/pwm/pwm-intel-lgm.yaml
> new file mode 100644
> index 000000000000..adb33265aa5e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-intel-lgm.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-intel-lgm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LGM SoC PWM controller
> +
> +maintainers:
> + - Rahul Tanwar <rahul.tanwar@intel.com>
> +
> +properties:
> + compatible:
> + const: intel,lgm-pwm
> +
> + reg:
> + maxItems: 1
> +
> + "#pwm-cells":
> + const: 2
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - "#pwm-cells"
> + - clocks
> + - resets
additionalProperties: false
> +
> +examples:
> + - |
> + pwm: pwm@e0d00000 {
> + compatible = "intel,lgm-pwm";
> + reg = <0xe0d00000 0x30>;
> + #pwm-cells = <2>;
> + clocks = <&cgu0 126>;
> + resets = <&rcu0 0x30 21>;
> + };
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: thermal: tsens: Add cold interrupt support in yaml
From: Rob Herring @ 2020-05-28 23:32 UTC (permalink / raw)
To: Manaf Meethalavalappu Pallikunhi
Cc: Rob Herring, devicetree, Amit Kucheria, linux-kernel, Zhang Rui,
linux-arm-msm, Andy Gross, Bjorn Andersson, Daniel Lezcano,
linux-pm
In-Reply-To: <20200522114626.28834-3-manafm@codeaurora.org>
On Fri, 22 May 2020 17:16:26 +0530, Manaf Meethalavalappu Pallikunhi wrote:
> Add cold interrupt support for tsens in yaml.
>
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
> ---
> .../bindings/thermal/qcom-tsens.yaml | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: irq: Add a compatible for the H3 R_INTC
From: Rob Herring @ 2020-05-28 23:50 UTC (permalink / raw)
To: Samuel Holland
Cc: Maxime Ripard, Chen-Yu Tsai, Jason Cooper, linux-arm-kernel,
Russell King, Marc Zyngier, Rob Herring, Thomas Gleixner,
devicetree, Will Deacon, Catalin Marinas, linux-sunxi,
linux-kernel
In-Reply-To: <20200525041302.51213-4-samuel@sholland.org>
On Sun, 24 May 2020 23:12:56 -0500, Samuel Holland wrote:
> The Allwinner H3 SoC contains an R_INTC that is, as far as we know,
> compatible with the R_INTC present in other sun8i/sun50i SoCs starting
> with the A31. Since the R_INTC hardware is undocumented, introduce a new
> compatible for the R_INTC variant in this SoC, in case there turns out
> to be some difference.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> .../allwinner,sun7i-a20-sc-nmi.yaml | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 16/18] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Miquel Raynal @ 2020-05-28 23:48 UTC (permalink / raw)
To: Boris Brezillon
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
In-Reply-To: <20200528180003.0f682e6f@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 18:00:03 +0200:
> On Thu, 28 May 2020 13:31:11 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Embed a generic NAND ECC high-level object in the nand_device
> > structure to carry all the ECC engine configuration/data. Adapt the
> > raw NAND and SPI-NAND cores to fit the change.
>
> I would also split that one:
>
> 1/ s/nand_ecc_props/nand_ecc/ in the core + change the spi nand
> framework accordingly
>
> 2/ update rawnand to use the generic layer
This one I honestly don't understand how to split it. As long as I
change the NAND device object content, I have to update all
raw/spi-NAND devices in the same patch, or I would break the build. As
it there are already many many changes, I did not split this patch.
^ permalink raw reply
* Re: [PATCH v6 15/18] mtd: nand: Introduce the ECC engine abstraction
From: Miquel Raynal @ 2020-05-28 23:46 UTC (permalink / raw)
To: Boris Brezillon
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Julien Su, Weijie Gao,
Paul Cercueil, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528205251.5e8abdd1@collabora.com>
Hi Boris,
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 20:52:51 +0200:
> On Thu, 28 May 2020 13:31:10 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Create a generic ECC engine object.
> >
> > Later the ecc.c file will receive more generic code coming from
> > the raw NAND specific part. This is a base to instantiate ECC engine
> > objects.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > drivers/mtd/nand/Kconfig | 7 ++
> > drivers/mtd/nand/Makefile | 2 +
> > drivers/mtd/nand/ecc.c | 138 ++++++++++++++++++++++++++++++++++++++
> > include/linux/mtd/nand.h | 67 ++++++++++++++++++
> > 4 files changed, 214 insertions(+)
> > create mode 100644 drivers/mtd/nand/ecc.c
> >
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index c1a45b071165..a4478ffa279d 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -9,4 +9,11 @@ source "drivers/mtd/nand/onenand/Kconfig"
> > source "drivers/mtd/nand/raw/Kconfig"
> > source "drivers/mtd/nand/spi/Kconfig"
> >
> > +menu "ECC engine support"
> > +
> > +config MTD_NAND_ECC
> > + bool
> > +
> > +endmenu
> > +
> > endmenu
> > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> > index 7ecd80c0a66e..981372953b56 100644
> > --- a/drivers/mtd/nand/Makefile
> > +++ b/drivers/mtd/nand/Makefile
> > @@ -6,3 +6,5 @@ obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> > obj-y += onenand/
> > obj-y += raw/
> > obj-y += spi/
> > +
> > +nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
> > diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
> > new file mode 100644
> > index 000000000000..e4f2b6fcbb12
> > --- /dev/null
> > +++ b/drivers/mtd/nand/ecc.c
> > @@ -0,0 +1,138 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Generic Error-Correcting Code (ECC) engine
> > + *
> > + * Copyright (C) 2019 Macronix
> > + * Author:
> > + * Miquèl RAYNAL <miquel.raynal@bootlin.com>
> > + *
> > + *
> > + * This file describes the abstraction of any NAND ECC engine. It has been
> > + * designed to fit most cases, including parallel NANDs and SPI-NANDs.
> > + *
> > + * There are three main situations where instantiating this ECC engine makes
> > + * sense:
> > + * - "external": The ECC engine is outside the NAND pipeline, typically this
>
> I'm not sure why you put quotes around those names.
>
> > + * is a software ECC engine. One can also imagine a generic
>
> ^ or an hardware
> engine that's outside the NAND controller pipeline.
>
> You can the drop the "One can also imagine ..." since it's more than a
> theoretical use case, we already have a few engines that fall in this
> category.
>
> > + * hardware ECC engine which would be an IP itself. Interacting
> > + * with a SPI-NAND device without on-die ECC could be achieved
>
> ^can
>
> > + * thanks to the use of such external engine.
>
> But I think I would simply drop this last sentence.
>
> > + * - "pipelined": The ECC engine is inside the NAND pipeline, ie. on the
> > + * controller's side. This is the case of most of the raw NAND
> > + * controllers. These controllers usually embed an hardware ECC
> > + * engine which is managed thanks to the same register set as
> > + * the controller's.
>
> Again, I would drop the last sentence here. I think saying the ECC
> bytes are generated/data corrected on the fly when a page is
> written/read would be more useful.
>
> > + * - "ondie": The ECC engine is inside the NAND pipeline, on the chip's side.
> > + * Some NAND chips can correct themselves the data. The on-die
> > + * correction can be enabled, disabled and the status of the
> > + * correction after a read may be retrieved with a NAND command
> > + * (may be vendor specific).
>
> "The on-die correction can be enabled, disabled" -> this is true for
> any kind of ECC engine :P.
>
> > + *
> > + * Besides the initial setup and final cleanups, the interfaces are rather
> > + * simple:
> > + * - "prepare": Prepare an I/O request, check the ECC engine is enabled or
>
> ^if/whether
>
> > + * disabled as requested before the I/O. In case of software
>
> How about "Enable/disable the ECC engine based on the I/O request type."
>
> > + * correction, this step may involve to derive the ECC bytes and
> > + * place them in the OOB area before a write.
>
> This is also true for external hardware ECC engines.
>
> > + * - "finish": Finish an I/O request, check the status of the operation ie.
> > + * the data validity in case of a read (report to the upper layer
> > + * any bitflip/errors).
>
> It's all about correcting/reporting errors, right. Let's try to put
> that into simple words: "Correct the data in case of a read request and
> report the number of corrected bits/uncorrectable errors. Most likely
> empty for write operations, unless you have hardware specific stuff to
> do, like shutting down the engine to save some power"
>
> > + *
> > + * Both prepare/finish callbacks are supposed to enclose I/O request and will
>
> "The I/O request should be enclosed in a prepare()/finish() pair of
> calls" or "The prepare/finish call should surround the I/O request".
>
> > + * behave differently depending on the desired correction:
>
> ^requested I/O type
>
> > + * - "raw": Correction disabled
> > + * - "ecc": Correction enabled
> > + *
> > + * The request direction is impacting the logic as well:
> > + * - "read": Load data from the NAND chip
> > + * - "write": Store data in the NAND chip
> > + *
> > + * Mixing all this combinations together gives the following behavior.
>
> Mention that those are just examples, and drivers are free to add
> custom steps in their prepare/finish hooks.
>
> > + *
> > + * ["external" ECC engine]
> > + * - external + prepare + raw + read: do nothing
> > + * - external + finish + raw + read: do nothing
> > + * - external + prepare + raw + write: do nothing
> > + * - external + finish + raw + write: do nothing
> > + * - external + prepare + ecc + read: do nothing
> > + * - external + finish + ecc + read: calculate expected ECC bytes, extract
> > + * ECC bytes from OOB buffer, correct
> > + * and report any bitflip/error
> > + * - external + prepare + ecc + write: calculate ECC bytes and store them at
> > + * the right place in the OOB buffer based
> > + * on the OOB layout
> > + * - external + finish + ecc + write: do nothing
> > + *
> > + * ["pipelined" ECC engine]
> > + * - pipelined + prepare + raw + read: disable the controller's ECC engine if
> > + * activated
> > + * - pipelined + finish + raw + read: do nothing
> > + * - pipelined + prepare + raw + write: disable the controller's ECC engine if
> > + * activated
> > + * - pipelined + finish + raw + write: do nothing
> > + * - pipelined + prepare + ecc + read: enable the controller's ECC engine if
> > + * deactivated
> > + * - pipelined + finish + ecc + read: check the status, report any
> > + * error/bitflip
> > + * - pipelined + prepare + ecc + write: enable the controller's ECC engine if
> > + * deactivated
> > + * - pipelined + finish + ecc + write: do nothing
> > + *
> > + * ["ondie" ECC engine]
> > + * - ondie + prepare + raw + read: send commands to disable the on-chip ECC
> > + * engine if activated
> > + * - ondie + finish + raw + read: do nothing
> > + * - ondie + prepare + raw + write: send commands to disable the on-chip ECC
> > + * engine if activated
> > + * - ondie + finish + raw + write: do nothing
> > + * - ondie + prepare + ecc + read: send commands to enable the on-chip ECC
> > + * engine if deactivated
> > + * - ondie + finish + ecc + read: send commands to check the status, report
> > + * any error/bitflip
> > + * - ondie + prepare + ecc + write: send commands to enable the on-chip ECC
> > + * engine if deactivated
> > + * - ondie + finish + ecc + write: do nothing
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/mtd/nand.h>
> > +
>
> Shouldn't we have kernel-docs for those functions?
>
> > +int nand_ecc_init_ctx(struct nand_device *nand)
> > +{
> > + if (!nand->ecc.engine->ops->init_ctx)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->init_ctx(nand);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_init_ctx);
> > +
> > +void nand_ecc_cleanup_ctx(struct nand_device *nand)
> > +{
> > + if (nand->ecc.engine->ops->cleanup_ctx)
> > + nand->ecc.engine->ops->cleanup_ctx(nand);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_cleanup_ctx);
> > +
> > +int nand_ecc_prepare_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req)
> > +{
> > + if (!nand->ecc.engine->ops->prepare_io_req)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->prepare_io_req(nand, req);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_prepare_io_req);
> > +
> > +int nand_ecc_finish_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req)
> > +{
> > + if (!nand->ecc.engine->ops->finish_io_req)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->finish_io_req(nand, req);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_finish_io_req);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
> > +MODULE_DESCRIPTION("Generic ECC engine");
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index 2e9af24936cd..0be260fd2f86 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -221,6 +221,73 @@ struct nand_ops {
> > bool (*isbad)(struct nand_device *nand, const struct nand_pos *pos);
> > };
> >
> > +/**
> > + * struct nand_ecc_context - Context for the ECC engine
> > + * @conf: basic ECC engine parameters
> > + * @total: Total number of bytes used for storing ECC codes, this is used by
>
> Sometimes you start your description with an uppercase, sometimes not.
>
> > + * generic OOB layouts
> > + * @priv: ECC engine driver private data
> > + */
> > +struct nand_ecc_context {
> > + struct nand_ecc_props conf;
> > + unsigned int total;
> > + void *priv;
> > +};
> > +
> > +/**
> > + * struct nand_ecc_engine_ops - Generic ECC engine operations
>
> ^s/Generic//
>
> > + * @init_ctx: given a desired user configuration for the pointed NAND device,
> > + * requests the ECC engine driver to setup a configuration with
> > + * values it supports.
> > + * @cleanup_ctx: clean the context initialized by @init_ctx.
> > + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> > + * request to be performed with ECC correction.
> > + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> > + * request and ensure proper ECC correction.
> > + */
> > +struct nand_ecc_engine_ops {
> > + int (*init_ctx)(struct nand_device *nand);
> > + void (*cleanup_ctx)(struct nand_device *nand);
> > + int (*prepare_io_req)(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > + int (*finish_io_req)(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > +};
> > +
> > +/**
> > + * struct nand_ecc_engine - Generic ECC engine abstraction for NAND devices
>
> ^s/Generic//
>
> > + * @ops: ECC engine operations
> > + */
> > +struct nand_ecc_engine {
> > + struct nand_ecc_engine_ops *ops;
> > +};
> > +
> > +int nand_ecc_init_ctx(struct nand_device *nand);
> > +void nand_ecc_cleanup_ctx(struct nand_device *nand);
> > +int nand_ecc_prepare_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > +int nand_ecc_finish_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > +
> > +/**
> > + * struct nand_ecc - High-level ECC object
>
> I think you can drop the "High-level" and just say "Information
> relative to the ECC"
>
> > + * @defaults: Default values, depend on the underlying subsystem
> > + * @requirements: ECC requirements from the NAND chip perspective
> > + * @user_conf: User desires in terms of ECC parameters
> > + * @ctx: ECC context for the ECC engine, derived from the device @requirements
> > + * the @user_conf and the @defaults
> > + * @ondie_engine: On-die ECC engine reference, if any
> > + * @engine: ECC engine actually bound
> > + */
> > +struct nand_ecc {
> > + struct nand_ecc_props defaults;
> > + struct nand_ecc_props requirements;
> > + struct nand_ecc_props user_conf;
> > + struct nand_ecc_context ctx;
> > + struct nand_ecc_engine *ondie_engine;
> > + struct nand_ecc_engine *engine;
> > +};
> > +
> > /**
> > * struct nand_device - NAND device
> > * @mtd: MTD instance attached to the NAND device
>
All comments applied.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH 5/8] dt-bindings: usb: usb-xhci: Document r8a7742 support
From: Rob Herring @ 2020-05-28 23:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Kishon Vijay Abraham I, Geert Uytterhoeven, linux-renesas-soc,
Prabhakar, Greg Kroah-Hartman, linux-kernel, devicetree,
linux-pci, linux-usb, dmaengine, Bjorn Helgaas, Magnus Damm,
Rob Herring, Vinod Koul
In-Reply-To: <1590356277-19993-6-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:54 +0100, Lad Prabhakar wrote:
> Document r8a7742 xhci support. The driver will use the fallback
> compatible string "renesas,rcar-gen2-xhci", therefore no driver
> change is needed.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 4/8] dt-bindings: dmaengine: renesas,usb-dmac: Add binding for r8a7742
From: Rob Herring @ 2020-05-28 23:45 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, devicetree, Rob Herring, dmaengine,
Vinod Koul, linux-renesas-soc, Kishon Vijay Abraham I,
Magnus Damm, linux-kernel, Prabhakar, Greg Kroah-Hartman,
linux-pci, linux-usb, Bjorn Helgaas
In-Reply-To: <1590356277-19993-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:53 +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Doesn't apply to my tree, so
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: usb: renesas,usbhs: Add support for r8a7742
From: Rob Herring @ 2020-05-28 23:44 UTC (permalink / raw)
To: Lad Prabhakar
Cc: devicetree, Rob Herring, Geert Uytterhoeven, linux-pci,
Kishon Vijay Abraham I, dmaengine, Bjorn Helgaas, linux-kernel,
Greg Kroah-Hartman, Prabhakar, linux-renesas-soc, Magnus Damm,
Vinod Koul, linux-usb
In-Reply-To: <1590356277-19993-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:52 +0100, Lad Prabhakar wrote:
> Document support for RZ/G1H (R8A7742) SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/8] dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742
From: Rob Herring @ 2020-05-28 23:43 UTC (permalink / raw)
To: Lad Prabhakar
Cc: devicetree, linux-pci, linux-usb, Rob Herring, Magnus Damm,
linux-renesas-soc, Geert Uytterhoeven, Bjorn Helgaas, Prabhakar,
Vinod Koul, Kishon Vijay Abraham I, dmaengine, linux-kernel,
Greg Kroah-Hartman
In-Reply-To: <1590356277-19993-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:51 +0100, Lad Prabhakar wrote:
> Add internal PCI bridge support for r8a7742 SoC. The Renesas RZ/G1H
> (R8A7742) internal PCI bridge is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: phy: rcar-gen2: Add r8a7742 support
From: Rob Herring @ 2020-05-28 23:43 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Rob Herring, linux-usb, linux-pci, Prabhakar, Vinod Koul,
Bjorn Helgaas, Kishon Vijay Abraham I, Greg Kroah-Hartman,
devicetree, linux-renesas-soc, linux-kernel, Magnus Damm,
dmaengine, Geert Uytterhoeven
In-Reply-To: <1590356277-19993-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:50 +0100, Lad Prabhakar wrote:
> Add USB PHY support for r8a7742 SoC. Renesas RZ/G1H (R8A7742)
> USB PHY is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 05/10] dt-bindings: clock: Introduce SM8150 QCOM Graphics clock bindings
From: Rob Herring @ 2020-05-28 23:41 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, open list,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20200524210615.17035-6-jonathan@marek.ca>
On Sun, May 24, 2020 at 05:06:06PM -0400, Jonathan Marek wrote:
> Add device tree bindings for graphics clock controller for
> Qualcomm Technology Inc's SM8150 SoCs.
Where's the schema?
>
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
> include/dt-bindings/clock/qcom,gpucc-sm8150.h | 40 +++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 include/dt-bindings/clock/qcom,gpucc-sm8150.h
^ permalink raw reply
* Re: [PATCH v12 1/4] power_supply: Add additional health properties to the header
From: Andrew F. Davis @ 2020-05-28 23:34 UTC (permalink / raw)
To: Ricardo Rivera-Matos, sre, pali, robh
Cc: dmurphy, linux-pm, linux-kernel, devicetree, sspatil,
Guru Das Srinagesh
In-Reply-To: <20200528225350.661-2-r-rivera-matos@ti.com>
On 5/28/20 6:53 PM, Ricardo Rivera-Matos wrote:
> From: Dan Murphy <dmurphy@ti.com>
>
> Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.
>
> HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken
> from JEITA specification JISC8712:2015
>
> Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
You should collect the acks and such you have received in previous
versions here, like mine from v11:
Acked-by: Andrew F. Davis <afd@ti.com>
> ---
> Documentation/ABI/testing/sysfs-class-power | 2 +-
> drivers/power/supply/power_supply_sysfs.c | 2 +-
> include/linux/power_supply.h | 3 +++
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
> index bf3b48f022dc..9f3fd01a9373 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -190,7 +190,7 @@ Description:
> Valid values: "Unknown", "Good", "Overheat", "Dead",
> "Over voltage", "Unspecified failure", "Cold",
> "Watchdog timer expire", "Safety timer expire",
> - "Over current"
> + "Over current", "Warm", "Cool", "Hot"
>
> What: /sys/class/power_supply/<supply_name>/precharge_current
> Date: June 2017
> diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
> index f37ad4eae60b..d0d549611794 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -61,7 +61,7 @@ static const char * const power_supply_charge_type_text[] = {
> static const char * const power_supply_health_text[] = {
> "Unknown", "Good", "Overheat", "Dead", "Over voltage",
> "Unspecified failure", "Cold", "Watchdog timer expire",
> - "Safety timer expire", "Over current"
> + "Safety timer expire", "Over current", "Warm", "Cool", "Hot"
> };
>
> static const char * const power_supply_technology_text[] = {
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index dcd5a71e6c67..8670e90c1d51 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -61,6 +61,9 @@ enum {
> POWER_SUPPLY_HEALTH_WATCHDOG_TIMER_EXPIRE,
> POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE,
> POWER_SUPPLY_HEALTH_OVERCURRENT,
> + POWER_SUPPLY_HEALTH_WARM,
> + POWER_SUPPLY_HEALTH_COOL,
> + POWER_SUPPLY_HEALTH_HOT,
> };
>
> enum {
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: uart: mtk: fix example
From: Rob Herring @ 2020-05-28 23:40 UTC (permalink / raw)
To: matthias.bgg
Cc: matthias.bgg, Matthias Brugger, dmaengine, linux-arm-kernel,
sean.wang, robh+dt, devicetree, linux-kernel, linux-mediatek,
vkoul
In-Reply-To: <20200523201530.18225-1-matthias.bgg@kernel.org>
On Sat, 23 May 2020 22:15:30 +0200, matthias.bgg@kernel.org wrote:
> From: Matthias Brugger <mbrugger@suse.com>
>
> The binding example is missing the fallback compatible.
> This is needed as the driver only matches against mt6577.
>
> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> ---
> Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [Patch 1/2] dt-binbings: media: ti-vpe: Document the VIP driver
From: Rob Herring @ 2020-05-28 23:39 UTC (permalink / raw)
To: Benoit Parrot; +Cc: Hans Verkuil, linux-media, devicetree, linux-kernel
In-Reply-To: <20200522225412.29440-2-bparrot@ti.com>
On Fri, May 22, 2020 at 05:54:11PM -0500, Benoit Parrot wrote:
> Device Tree bindings for the Video Input Port (VIP) driver.
Bindings document h/w, not drivers.
>
> Signed-off-by: Benoit Parrot <bparrot@ti.com>
> ---
> .../devicetree/bindings/media/ti,vip.yaml | 394 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 395 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/ti,vip.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/ti,vip.yaml b/Documentation/devicetree/bindings/media/ti,vip.yaml
> new file mode 100644
> index 000000000000..8a9084e42329
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/ti,vip.yaml
> @@ -0,0 +1,394 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/ti,vip.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments DRA7x VIDEO INPUT PORT (VIP) Device Tree Bindings
> +
> +maintainers:
> + - Benoit Parrot <bparrot@ti.com>
> +
> +description: |-
> + The Video Input Port (VIP) is a key component for image capture
> + applications. The capture module provides the system interface and the
> + processing capability to connect parallel image-sensor as well as
> + BT.656/1120 capable encoder chip to DRA7x device.
> +
> + Each VIP instance supports 2 independently configurable external video
> + input capture slices (Slice 0 and Slice 1) each providing up to two video
> + input ports (Port A and Port B) where Port A can be configured as
> + 24/16/8-bit port and Port B is fixed as 8-bit port.
> + Here these ports a represented as follows
> + port@0 -> Slice 0 Port A
> + port@1 -> Slice 0 Port B
> + port@2 -> Slice 1 Port A
> + port@3 -> Slice 1 Port B
> +
> + Each camera port nodes should contain a 'port' child node with child
> + 'endpoint' node. Please refer to the bindings defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +properties:
> + compatible:
> + const: ti,dra7-vip
> +
> + label:
> + description: Instance name
Kind of odd for this type of binding. Are there a define set or pattern
of values.
> +
> + reg:
> + items:
> + - description: The VIP main register region
> + - description: Video Data Parser (PARSER) register region for Slice0
> + - description: Color Space Conversion (CSC) register region for Slice0
> + - description: Scaler (SC) register region for Slice0
> + - description: Video Data Parser (PARSER) register region for Slice1
> + - description: Color Space Conversion (CSC) register region for Slice1
> + - description: Scaler (SC) register region for Slice1
> + - description: Video Port Direct Memory Access (VPDMA) register region
> +
> + reg-names:
> + items:
> + - const: vip
> + - const: parser0
> + - const: csc0
> + - const: sc0
> + - const: parser1
> + - const: csc1
> + - const: sc1
> + - const: vpdma
> +
> + interrupts:
> + minItems: 2
> + description:
> + IRQ index 0 is used for Slice0 interrupts
> + IRQ index 1 is used for Slice1 interrupts
> +
> + ti,vip-clk-polarity:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description:
> + phandle to the device control module. The 1st argument should
> + contain the register offset to the CTRL_CORE_SMA_SW_1 register.
> + 2nd argument contains the bit field to slice 0 port A,
> + 3rd argument contains the bit field to slice 0 port B,
> + 4th argument contains the bit field to slice 1 port A,
> + 5th argument contains the bit field to slice 1 port B.
> +
> + # See ./video-interfaces.txt for details
> + ports:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + port@0:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 0
> + description: Slice 0 Port A
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
Not an array. Just:
hsync-active: true
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
Not an array. What subset of values are allowed?
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description: |-
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
> +
> + required:
> + - reg
> + - label
> +
> + port@1:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 1
> + description: Slice 0 Port B
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description:
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
> +
> + required:
> + - reg
> + - label
> +
> + port@2:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 2
> + description: Slice 1 Port A
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description:
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
> +
> + required:
> + - reg
> + - label
> +
> + port@3:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 3
> + description: Slice 1 Port B
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description:
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
If all the properties are the same across ports, then do a
patternProperties with '^port@' and define them there. You'll still need
'port@0', etc. to define what each port is.
> +
> + required:
> + - reg
> + - label
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> + - port@0
> +
> +required:
> + - compatible
> + - label
> + - reg
> + - reg-names
> + - interrupts
> + - ti,vip-clk-polarity
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + vip1: vip@48970000 {
> + compatible = "ti,dra7-vip";
> + label = "vip1";
> + reg = <0x48970000 0x114>,
> + <0x48975500 0xD8>,
> + <0x48975700 0x18>,
> + <0x48975800 0x80>,
> + <0x48975a00 0xD8>,
> + <0x48975c00 0x18>,
> + <0x48975d00 0x80>,
> + <0x4897d000 0x400>;
> + reg-names = "vip",
> + "parser0",
> + "csc0",
> + "sc0",
> + "parser1",
> + "csc1",
> + "sc1",
> + "vpdma";
> + interrupts = <GIC_SPI 351 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 392 IRQ_TYPE_LEVEL_HIGH>;
> + ti,vip-clk-polarity = <&scm_conf 0x534 0x1 0x4 0x2 0x8>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1a: port@0 {
> + reg = <0>;
> + label = "vin1a";
> +
> + vin1a_ep: endpoint {
> + remote-endpoint = <&camera1>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <0>;
> + bus-width = <8>;
> + };
> + };
> + vin1b: port@1 {
> + reg = <1>;
> + label = "vin1b";
> + };
> + vin2a: port@2 {
> + reg = <2>;
> + label = "vin2a";
> + };
> + vin2b: port@3 {
> + reg = <3>;
> + label = "vin2b";
> + };
> + };
> + };
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@37 {
> + compatible = "ovti,ov10633";
> + reg = <0x37>;
> +
> + clocks = <&fixed_clock>;
> + clocks-names = "xvclk";
> +
> + port {
> + camera1: endpoint {
> + remote-endpoint = <&vin1a_ep>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2e9a5f6e4ff7..06856d05b53b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16947,6 +16947,7 @@ S: Maintained
> W: http://linuxtv.org/
> Q: http://patchwork.linuxtv.org/project/linux-media/list/
> F: Documentation/devicetree/bindings/media/ti,cal.yaml
> +F: Documentation/devicetree/bindings/media/ti,vip.yaml
> F: Documentation/devicetree/bindings/media/ti,vpe.yaml
> F: drivers/media/platform/ti-vpe/
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 5/6] gnss: motmdm: Add support for Motorola Mapphone MDM6600 modem
From: Tony Lindgren @ 2020-05-28 23:38 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg Kroah-Hartman, Rob Herring, Lee Jones, Jiri Slaby,
Merlijn Wajer, Pavel Machek, Peter Hurley, Sebastian Reichel,
linux-serial, devicetree, linux-kernel, linux-omap
In-Reply-To: <20200528130653.GG10358@localhost>
Hi,
* Johan Hovold <johan@kernel.org> [200528 13:07]:
> On Tue, May 12, 2020 at 02:47:12PM -0700, Tony Lindgren wrote:
> > +/*
> > + * Motorola MDM GNSS device communicates over a dedicated TS 27.010 channel
> > + * using custom data packets. The packets look like AT commands embedded into
> > + * a Motorola invented packet using format like "U1234AT+MPDSTART=0,1,100,0".
> > + * But it's not an AT compatible serial interface, it's a packet interface
> > + * using AT like commands.
> > + */
>
> So this shouldn't depend on TS 27.010 and instead be a generic gnss
> serial driver.
Hmm not sure if it makes sense to try to represent packet data as
a virtual serial port :) But sure let's at least investigate it.
> What does the interface look like over the corresponding USB port?
> AT-commands without the U1234 prefix?
I don't know if it's using the same commands as the ttyUSB* GNSS device
seems disabled. From what I understand, gobi2000 has just $gps_start and
$gps_stop commands for the ttyUSB* GNSS device. Those don't exist
here. Also the command style seems to follow the modem firmware for
various other devices on the modem.
> No module parameters please. Either pick a good default or we need to
> come up with a generic (sysfs) interface for polled drivers like this
> one.
OK yeah this could be a generic sysfs option.
> How does your "aggressive pm" gsmmux implementation work with the gps if
> there are no other clients keeping the modem awake? It seems the modem
> would be suspended after 600 milliseconds after being woken up every 10
> seconds or so by the polling gnss driver?
Well we still have /dev/gnss open, so GNSS stays active and won't get
disabled until the device is closed. The shared GPIOs with the USB PHY
are used to signal port traffic.
> What happens to the satellite lock in between? Does the request block
> until the gps has an updated position?
It seems to regain the lock in about one or two seconds, so it's some
kind of modem PM state for allowing the SoC to idle it seems.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH V2 1/3] dt-bindings: mmc: Supply max load for mmc supplies
From: Rob Herring @ 2020-05-28 23:23 UTC (permalink / raw)
To: Veerabhadrarao Badiganti
Cc: adrian.hunter, ulf.hansson, bjorn.andersson, linux-mmc,
linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <1590074615-10787-2-git-send-email-vbadigan@codeaurora.org>
On Thu, May 21, 2020 at 08:53:33PM +0530, Veerabhadrarao Badiganti wrote:
> Supply the max load needed for driving the mmc supplies.
>
> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
> ---
> .../devicetree/bindings/mmc/mmc-controller.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> index acc9f10..9058b82 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> @@ -290,6 +290,22 @@ properties:
> description:
> Supply for the bus IO line power
>
> + vmmc-max-load-microamp:
Seems like this should be a common regulator property (it would have to
be a suffix to match up with *-supply).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
Properties with unit suffix already have a type.
> + - minimum: 0
> + - maximum: 1000000
> + description:
> + Maximum load for the card power.
> +
> + vqmmc-max-load-microamp:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 0
> + - maximum: 1000000
> + description:
> + Maximum load for the bus IO line power.
> +
> mmc-pwrseq:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: timer: Add CLINT bindings
From: Rob Herring @ 2020-05-28 23:18 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: seanga2, anup, Anup Patel, Paul Walmsley, aou, daniel.lezcano,
tglx, devicetree, Damien Le Moal, linux-kernel, Atish Patra,
Alistair Francis, linux-riscv
In-Reply-To: <mhng-0995a264-b39c-4790-9aa5-b8c598b43ffd@palmerdabbelt-glaptop1>
On Tue, May 26, 2020 at 05:32:30PM -0700, Palmer Dabbelt wrote:
> On Thu, 21 May 2020 23:29:36 PDT (-0700), seanga2@gmail.com wrote:
> > On 5/22/20 1:54 AM, Anup Patel wrote:
> > > On Fri, May 22, 2020 at 1:35 AM Sean Anderson <seanga2@gmail.com> wrote:
> > > >
> > > > On 5/21/20 9:45 AM, Anup Patel wrote:
> > > > > +Required properties:
> > > > > +- compatible : "sifive,clint-1.0.0" and a string identifying the actual
> > > > > + detailed implementation in case that specific bugs need to be worked around.
> > > >
> > > > Should the "riscv,clint0" compatible string be documented here? This
> > >
> > > Yes, I forgot to add this compatible string. I will add in v2.
> > >
> > > > peripheral is not really specific to sifive, as it is present in most
> > > > rocket-chip cores.
> > >
> > > I agree that CLINT is present in a lot of non-SiFive RISC-V SOCs and
> > > FPGAs but this IP is only documented as part of SiFive FU540 SOC.
> > > (Refer, https://static.dev.sifive.com/FU540-C000-v1.0.pdf)
> > >
> > > The RISC-V foundation should host the CLINT spec independently
> > > under https://github.com/riscv and make CLINT spec totally open.
> > >
> > > For now, I have documented it just like PLIC DT bindings found at:
> > > Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
> >
> > The PLIC seems to have its own RISC-V-sponsored documentation [1] which
> > was split off from the older privileged specs. By your logic above,
> > should it be renamed to riscv,plic0.txt (with a corresponding change in
> > the documented compatible strings)?
> >
> > [1] https://github.com/riscv/riscv-plic-spec
>
> Let's propose tagging that PLIC spec as v1.0.0 in the platform spec group, but
> I don't see a reason why that wouldn't be viable. Assuming that's all OK, we
> can start calling this a RISC-V PLIC (in addition to a SiFive PLIC, as they'll
> be compatible).
>
> > >
> > > If RISC-V maintainers agree then I will document it as "RISC-V CLINT".
> > >
> > > @Palmer ?? @Paul ??
>
> The CLINT is a SiFive spec. It has open source RTL so it's been implemented in
> other designs, but it's not a RISC-V spec. The CLIC, which is a superset of
> the CLINT, is a RISC-V spec. IIRC it's not finished yet (it's the fast
> interrupts task group), but presumably we should have a "riscv,clic-2.0.0" (or
> whatever it ends up being called) compat string to go along with the
> specification.
Whatever you all decide on, note that "sifive,<block><num>" is a SiFive
thing (as it is documented) and <num> corresponds to tag of the IP
implmentation (at least it is supposed to). So you can't just copy that
with 'riscv,<block><num>' unless you have the same IP versioning
and update the documentation.
Using a spec version is fine, but not standalone. You need
implementation specific compatible too because no one perfectly
implements any spec and/or there details a spec may not cover.
Rob
^ permalink raw reply
* Re: [PATCH v2 9/9] dt-bindings: usb: Convert ehci-mv to json-schema
From: Rob Herring @ 2020-05-28 23:05 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Linus Walleij, Marc Zyngier, Thomas Gleixner, Daniel Lezcano,
Rob Herring, Alessandro Zummo, devicetree, Bartosz Golaszewski,
Alexandre Belloni, linux-kernel, Ulf Hansson, Jason Cooper
In-Reply-To: <20200521091356.2211020-10-lkundrak@v3.sk>
On Thu, 21 May 2020 11:13:56 +0200, Lubomir Rintel wrote:
> A straightforward conversion of the ehci-mv binding to DT schema format
> using json-schema.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - s/GPL-2.0-or-later/GPL-2.0-only/
>
> .../devicetree/bindings/usb/ehci-mv.txt | 23 -------
> .../bindings/usb/marvell,pxau2o-ehci.yaml | 60 +++++++++++++++++++
> 2 files changed, 60 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/ehci-mv.txt
> create mode 100644 Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas,du: Convert binding to YAML
From: Laurent Pinchart @ 2020-05-28 23:04 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, dri-devel, devicetree, linux-renesas-soc,
Kieran Bingham
In-Reply-To: <20200528185244.GA400585@bogus>
Hi Rob,
On Thu, May 28, 2020 at 12:52:44PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:33:40AM +0300, Laurent Pinchart wrote:
> > Convert the Renesas R-Car DU text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > .../bindings/display/renesas,du.txt | 139 ---
> > .../bindings/display/renesas,du.yaml | 915 ++++++++++++++++++
>
> A 'normal' conversion is about double the lines. I guess this is a sign
> that the original was not well specified.
The original was specified in a much more compressed form (for instance
there was a table with one line per SoC to describe the port node, the
YAML equivalent has to be longer).
> Maybe this can be split to reduce some of the if/then? One way is define
> a common 'include' file that each specific instance can reference
With your recommendation of using pattern instead of enum for the dclkin
clock names, we're down to 848 lines, it's already a bit better :-)
I could indeed split the file, but I'll then run into naming issues. If
you look at the compatible strings for each of the if...then...else,
they don't have easy patterns that could be used to name files. I could
name the files based on one arbitrarily chosen compat string among the
multiple values that are supported, but I think that would become
confusing. I could also have one file per SoC, but we'll then end up
with lots of files, several of them being totally identical except for
the compatible string. Would you mind keeping it as-is, or do you think
it really needs to be split ?
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > new file mode 100644
> > index 000000000000..ca48065afe1f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > @@ -0,0 +1,915 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/renesas,du.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas R-Car Display Unit (DU)
> > +
> > +maintainers:
> > + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > +
> > +description: |
> > + These DT bindings describe the Display Unit embedded in the Renesas R-Car
> > + Gen1, R-Car Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - renesas,du-r8a7743 # for RZ/G1M compatible DU
> > + - renesas,du-r8a7744 # for RZ/G1N compatible DU
> > + - renesas,du-r8a7745 # for RZ/G1E compatible DU
> > + - renesas,du-r8a77470 # for RZ/G1C compatible DU
> > + - renesas,du-r8a774a1 # for RZ/G2M compatible DU
> > + - renesas,du-r8a774b1 # for RZ/G2N compatible DU
> > + - renesas,du-r8a774c0 # for RZ/G2E compatible DU
> > + - renesas,du-r8a7779 # for R-Car H1 compatible DU
> > + - renesas,du-r8a7790 # for R-Car H2 compatible DU
> > + - renesas,du-r8a7791 # for R-Car M2-W compatible DU
> > + - renesas,du-r8a7792 # for R-Car V2H compatible DU
> > + - renesas,du-r8a7793 # for R-Car M2-N compatible DU
> > + - renesas,du-r8a7794 # for R-Car E2 compatible DU
> > + - renesas,du-r8a7795 # for R-Car H3 compatible DU
> > + - renesas,du-r8a7796 # for R-Car M3-W compatible DU
> > + - renesas,du-r8a77965 # for R-Car M3-N compatible DU
> > + - renesas,du-r8a77970 # for R-Car V3M compatible DU
> > + - renesas,du-r8a77980 # for R-Car V3H compatible DU
> > + - renesas,du-r8a77990 # for R-Car E3 compatible DU
> > + - renesas,du-r8a77995 # for R-Car D3 compatible DU
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + # See compatible-specific constraints below.
> > + clocks: true
> > + clock-names: true
> > + interrupts: true
> > + resets: true
> > + reset-names: true
> > +
> > + ports:
> > + type: object
> > + description: |
> > + The connections to the DU output video ports are modeled using the OF
> > + graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > + The number of ports and their assignment are model-dependent. Each port
> > + shall have a single endpoint.
> > +
> > + properties:
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > + patternProperties:
> > + "^port@[0-3]$":
> > + type: object
> > +
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + endpoint:
> > + type: object
> > +
> > + properties:
> > + remote-endpoint:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + required:
> > + - remote-endpoint
> > +
> > + additionalProperties: false
> > +
> > + additionalProperties: false
>
> You can drop this and assume there's a generic check for this. Though I
> guess this does ensure only 'remote-endpoint' is present which a generic
> schema couldn't do.
When you say I can drop "this", which part do you mean exactly ? I
indeed wanted to specify that no other property than remote-endpoint can
be present. What's your recommendation ?
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + additionalProperties: false
> > +
> > + renesas,cmms:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > + description:
> > + A list of phandles to the CMM instances present in the SoC, one for each
> > + available DU channel.
> > +
> > + renesas,vsps:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > + description:
> > + A list of phandle and channel index tuples to the VSPs that handle the
> > + memory interfaces for the DU channels. The phandle identifies the VSP
> > + instance that serves the DU channel, and the channel index identifies
> > + the LIF instance in that VSP.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - interrupts
> > + - resets
> > + - ports
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: renesas,du-r8a7779
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 1
> > + maxItems: 3
> > + items:
> > + - description: Functional clock
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 1
> > + maxItems: 3
> > + items:
> > + - const: du.0
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
>
> Here and elsewhere:
>
> - pattern: "^dclkin\.[01]$"
I assume you meant
- pattern: "^dclkin\\.[01]$"
Will fix.
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + # port@2 is TCON, not supported yet
>
> Does that matter?
It's a nice reminder that we should add support for it. And I don't
meant in the driver, even if that part is also required, but in the DT
bindings. I don't want to blindly state
port@2:
description: TCON
without working on TCON support on the driver side to validate that the
DT binding is fine and that I haven't overlooked something. Do you mind
keeping the comment for now ?
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - interrupts
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7743
> > + - renesas,du-r8a7744
> > + - renesas,du-r8a7791
> > + - renesas,du-r8a7793
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + # port@2 is TCON, not supported yet
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7745
> > + - renesas,du-r8a7792
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7794
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + # port@2 is TCON, not supported yet
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a77470
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + port@2:
> > + description: LVDS 0
> > + # port@3 is DVENC, not supported yet
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7790
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU2
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN2 input clock
> > +
> > + clock-names:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > +
> > + interrupts:
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + port@2:
> > + description: LVDS 1
> > + # port@3 is TCON, not supported yet
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7795
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 4
> > + maxItems: 8
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU2
> > + - description: Functional clock for DU4
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN2 input clock
> > + - description: DU_DOTCLKIN3 input clock
> > +
> > + clock-names:
> > + minItems: 4
> > + maxItems: 8
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.2
> > + - const: du.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > +
> > + interrupts:
> > + maxItems: 4
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > + - const: du.2
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: HDMI 0
> > + port@2:
> > + description: HDMI 1
> > + port@3:
> > + description: LVDS 0
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > + - port@3
> > +
> > + renesas,cmms:
> > + minItems: 4
> > +
> > + renesas,vsps:
> > + minItems: 4
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a774a1
> > + - renesas,du-r8a7796
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU2
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN2 input clock
> > +
> > + clock-names:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > +
> > + interrupts:
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > + - const: du.2
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: HDMI 0
> > + port@2:
> > + description: LVDS 0
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + renesas,cmms:
> > + minItems: 3
> > +
> > + renesas,vsps:
> > + minItems: 3
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a774b1
> > + - renesas,du-r8a77965
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU3
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN3 input clock
> > +
> > + clock-names:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.3
> > +
> > + interrupts:
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > + - const: du.3
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: HDMI 0
> > + port@2:
> > + description: LVDS 0
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + renesas,cmms:
> > + minItems: 3
> > +
> > + renesas,vsps:
> > + minItems: 3
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a77970
> > + - renesas,du-r8a77980
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - description: Functional clock for DU0
> > + - description: DU_DOTCLKIN0 input clock
> > +
> > + clock-names:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - const: du.0
> > + - const: dclkin.0
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + renesas,vsps:
> > + minItems: 1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a774c0
> > + - renesas,du-r8a77990
> > + - renesas,du-r8a77995
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + port@2:
> > + description: LVDS 1
> > + # port@3 is TCON, not supported yet
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + renesas,cmms:
> > + minItems: 2
> > +
> > + renesas,vsps:
> > + minItems: 2
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + # R-Car H3 ES2.0 DU
> > + - |
> > + #include <dt-bindings/clock/renesas-cpg-mssr.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > + display@feb00000 {
> > + compatible = "renesas,du-r8a7795";
> > + reg = <0xfeb00000 0x80000>;
> > + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 724>,
> > + <&cpg CPG_MOD 723>,
> > + <&cpg CPG_MOD 722>,
> > + <&cpg CPG_MOD 721>;
> > + clock-names = "du.0", "du.1", "du.2", "du.3";
> > + resets = <&cpg 724>, <&cpg 722>;
> > + reset-names = "du.0", "du.2";
> > +
> > + renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
> > + renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + endpoint {
> > + remote-endpoint = <&adv7123_in>;
> > + };
> > + };
> > + port@1 {
> > + reg = <1>;
> > + endpoint {
> > + remote-endpoint = <&dw_hdmi0_in>;
> > + };
> > + };
> > + port@2 {
> > + reg = <2>;
> > + endpoint {
> > + remote-endpoint = <&dw_hdmi1_in>;
> > + };
> > + };
> > + port@3 {
> > + reg = <3>;
> > + endpoint {
> > + remote-endpoint = <&lvds0_in>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 7/9] dt-bindings: spi: Convert spi-pxa2xx to json-schema
From: Rob Herring @ 2020-05-28 23:03 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Thomas Gleixner, Alessandro Zummo, Jason Cooper, Ulf Hansson,
Marc Zyngier, devicetree, Bartosz Golaszewski, Alexandre Belloni,
Daniel Lezcano, Rob Herring, linux-kernel, Linus Walleij
In-Reply-To: <20200521091356.2211020-8-lkundrak@v3.sk>
On Thu, 21 May 2020 11:13:54 +0200, Lubomir Rintel wrote:
> A straightforward conversion of the the spi-pxa2xx binding to DT schema
> format using json-schema.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Drop #address-cells and #size-cells
> - s/GPL-2.0-or-later/GPL-2.0-only/
>
> .../bindings/spi/marvell,mmp2-ssp.yaml | 56 +++++++++++++++++++
> .../devicetree/bindings/spi/spi-pxa2xx.txt | 27 ---------
> 2 files changed, 56 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml
> delete mode 100644 Documentation/devicetree/bindings/spi/spi-pxa2xx.txt
>
Applied, thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox