Re: [PATCH 0/3] drm: panfrost: Coherency support

2020-09-16 Thread Rob Herring
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
 wrote:
>
> > So I get a performance regression with the dma-coherent approach, even if 
> > it's
> > clearly the cleaner.
>
> That's bizarre -- this should really be the faster of the two.

Coherency may not be free. CortexA9 had something like 4x slower
memcpy if SMP was enabled as an example. I don't know if there's
anything going on like that specifically here. If there's never any
CPU accesses mixed in with kmscube, then there would be no benefit to
coherency.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for LT9611UXC

2020-09-15 Thread Rob Herring
On Wed, 09 Sep 2020 12:28:22 +0300, Dmitry Baryshkov wrote:
> Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports
> and I2S port as input and one HDMI port as output. The LT9611UXC chip is
> handled by a separate driver, but the bindings used are fully compatible
> with the LT9611 chip, so let's reuse the lt9611.yaml schema.
> 
> Signed-off-by: Dmitry Baryshkov 
> Acked-by: Vinod Koul 
> Acked-by: Sam Ravnborg 
> ---
>  .../devicetree/bindings/display/bridge/lontium,lt9611.yaml   | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 03/10] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support

2020-09-15 Thread Rob Herring
On Tue, 08 Sep 2020 09:34:17 +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> This patch adds R-Car M3-W+ (R8A77961) SoC bindings.
> 
> Signed-off-by: Kuninori Morimoto 
> Reviewed-by: Geert Uytterhoeven 
> ---
>  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt   | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 01/10] dt-bindings: display: renesas: du: Document the r8a77961 bindings

2020-09-15 Thread Rob Herring
On Tue, 08 Sep 2020 09:34:04 +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.
> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/6] dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings

2020-09-15 Thread Rob Herring
On Mon, Sep 07, 2020 at 10:18:21AM +0200, Neil Armstrong wrote:
> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), 
> with a custom
> glue managing the IP resets, clock and data input similar to the DW-HDMI Glue 
> on other
> Amlogic SoCs.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../display/amlogic,meson-dw-mipi-dsi.yaml| 115 ++
>  1 file changed, 115 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml 
> b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
> new file mode 100644
> index ..6177f45ea1a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2020 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-mipi-dsi.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host 
> Controller
> +
> +maintainers:
> +  - Neil Armstrong 
> +
> +description: |
> +  The Amlogic Meson Synopsys Designware Integration is composed of
> +  - A Synopsys DesignWare MIPI DSI Host Controller IP
> +  - A TOP control block controlling the Clocks & Resets of the IP
> +
> +allOf:
> +  - $ref: dsi-controller.yaml#
> +
> +properties:
> +  compatible:
> +enum:
> +  - amlogic,meson-axg-dw-mipi-dsi
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +minItems: 2
> +
> +  clock-names:
> +minItems: 2
> +items:
> +  - const: pclk
> +  - const: px_clk
> +  - const: meas_clk
> +
> +  resets:
> +minItems: 1
> +
> +  reset-names:
> +items:
> +  - const: top
> +
> +  phys:
> +minItems: 1
> +
> +  phy-names:
> +items:
> +  - const: dphy
> +
> +  ports:
> +type: object
> +
> +properties:
> +  port@0:
> +type: object
> +description: Input node to receive pixel data.
> +  port@1:
> +type: object
> +description: DSI output node to panel.
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - resets
> +  - reset-names
> +  - phys
> +  - phy-names
> +  - ports
> +
> +additionalProperties: false

Presumably you may have panel/bridge child nodes, so this needs to be 
'unevaluatedProperties: false'.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/6] dt-bindings: display: amlogic,meson-vpu: add bindings for VPU found in AXG SoCs

2020-09-15 Thread Rob Herring
On Mon, Sep 07, 2020 at 10:18:20AM +0200, Neil Armstrong wrote:
> The Amlogic AXG SoC family has a downgraded VPU supporting only MIPI-DSI 
> output
> after it's ENCL DPI encoder output.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../bindings/display/amlogic,meson-vpu.yaml   | 36 +--
>  1 file changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml 
> b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> index a8d202c9d004..e2e7d99d8ace 100644
> --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> @@ -31,8 +31,10 @@ description: |
>  
>The Video Input Unit is in charge of the pixel scanout from the DDR memory.
>It fetches the frames addresses, stride and parameters from the "Canvas" 
> memory.
> +  On the AXG family, the Video Input Unit direclty reads from DDR memory.
>This part is also in charge of the CSC (Colorspace Conversion).
>It can handle 2 OSD Planes and 2 Video Planes.
> +  On the AXG family, only a single OSD plane without scalins is supported.

s/scalins/scaling/ ?

Otherwise,

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 06/13] dt-bindings: mfd: rohm, bd71837-pmic: Add common properties

2020-09-15 Thread Rob Herring
On Tue, Sep 15, 2020 at 12:34 AM Vaittinen, Matti
 wrote:
>
>
> Hello All,
>
> On Mon, 2020-09-14 at 16:44 -0600, Rob Herring wrote:
> > On Fri, Sep 04, 2020 at 04:53:05PM +0200, Krzysztof Kozlowski wrote:
> > > Add common properties appearing in DTSes (clock-names,
> > > clock-output-names) to fix dtbs_check warnings like:
> > >
> > >   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml:
> > > pmic@4b: 'clock-names', 'clock-output-names', do not match any
> > > of the regexes: 'pinctrl-[0-9]+'
> > >
> > > Signed-off-by: Krzysztof Kozlowski 
> > > ---
> > >  .../devicetree/bindings/mfd/rohm,bd71837-pmic.yaml  | 6
> > > ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> > > pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> > > pmic.yaml
> > > index 65018a019e1d..ecce0d5e3a95 100644
> > > --- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> > > +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> > > @@ -32,9 +32,15 @@ properties:
> > >clocks:
> > >  maxItems: 1
> > >
> > > +  clock-names:
> > > +maxItems: 1
> >
> > Needs to define what the name is.
>
> Someone once told me that "naming is hard".
> Do we have some good common convention for 32K oscillator input naming?

No.

> Or should it just be dropped?

Yes, having a name for a single entry in *-names is kind of pointless IMO.


> > > +
> > >"#clock-cells":
> > >  const: 0
> > >
> > > +  clock-output-names:
> > > +maxItems: 1
> >
> > Ideally this one too, but we've been more flexible on it.
>
> Data-sheet for BD71837 uses pin name "C32k_OUT". So maybe this would be
> good?

What's in all the dts files? I'd go with that if there's any clear
winner. If it's already a random free-for-all, then just leave it
as-is.

>
> BD71838 uses "bd71828-32k-out" . so we could also go with this same
> convention and use "bd71837-32k-out". Or - we could take a risk and
> *assume* typical use case for this clk (as this is typically used with
> i.MX8 I'd guess the 32k is used for RTC) and name it accordingly.

It should be aligned with what the output is called, not what it is
connected to.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Yes Optoelectronics

2020-09-14 Thread Rob Herring
On Fri, 04 Sep 2020 23:38:19 +0530, Jagan Teki wrote:
> Add vendor dt-bindings for Yes Optoelectronics Co.,Ltd.
> 
> Signed-off-by: Jagan Teki 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/3] dt-bindings: display: simple: Add YTC700TLAG-05-201C

2020-09-14 Thread Rob Herring
On Fri, 04 Sep 2020 23:38:20 +0530, Jagan Teki wrote:
> Add dt-bindings for YTC700TLAG-05-201C 7" TFT LCD panel from
> Yes Optoelectronics Co.,Ltd.
> 
> Signed-off-by: Jagan Teki 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 07/13] dt-bindings: mfd: rohm,bd71847-pmic: Add common clock-names

2020-09-14 Thread Rob Herring
On Fri, Sep 04, 2020 at 04:53:06PM +0200, Krzysztof Kozlowski wrote:
> Add common 'clock-names' property which might appear in DTSes.  This
> makes it consistent with rohm,bd71837-pmic dtschema.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml 
> b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
> index 5d531051a153..6328163fc32a 100644
> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
> @@ -35,6 +35,9 @@ properties:
>clocks:
>  maxItems: 1
>  
> +  clock-names:
> +maxItems: 1

Need to define the name.

> +
>"#clock-cells":
>  const: 0
>  
> -- 
> 2.17.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 06/13] dt-bindings: mfd: rohm,bd71837-pmic: Add common properties

2020-09-14 Thread Rob Herring
On Fri, Sep 04, 2020 at 04:53:05PM +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (clock-names,
> clock-output-names) to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml:
> pmic@4b: 'clock-names', 'clock-output-names', do not match any of the 
> regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/mfd/rohm,bd71837-pmic.yaml  | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml 
> b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> index 65018a019e1d..ecce0d5e3a95 100644
> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> @@ -32,9 +32,15 @@ properties:
>clocks:
>  maxItems: 1
>  
> +  clock-names:
> +maxItems: 1

Needs to define what the name is.

> +
>"#clock-cells":
>  const: 0
>  
> +  clock-output-names:
> +maxItems: 1

Ideally this one too, but we've been more flexible on it.

> +
>  # The BD718x7 supports two different HW states as reset target states. States
>  # are called as SNVS and READY. At READY state all the PMIC power outputs go
>  # down and OTP is reload. At the SNVS state all other logic and external
> -- 
> 2.17.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 04/13] dt-bindings: gpu: vivante, gc: Add common properties

2020-09-14 Thread Rob Herring
On Fri, 04 Sep 2020 16:53:03 +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (cooling-cells, assigned-clocks
> and others) to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpu@3800:
> '#cooling-cells', 'assigned-clock-parents', 'assigned-clock-rates', 
> 'assigned-clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/gpu/vivante,gc.yaml | 7 +++
>  1 file changed, 7 insertions(+)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 03/13] dt-bindings: arm: fsl: Fix matching Purism Librem5 phones

2020-09-14 Thread Rob Herring
On Fri, 04 Sep 2020 16:53:02 +0200, Krzysztof Kozlowski wrote:
> All Purism Librem5 phones have three compatibles so they need their own
> entry to fix dbts_check warnings like:
> 
>   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml: /:
> compatible: ['purism,librem5r2', 'purism,librem5', 'fsl,imx8mq'] is not 
> valid under any of the given schemas
> 
>   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml: /:
> compatible: ['purism,librem5r2', 'purism,librem5', 'fsl,imx8mq'] is too 
> long
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

I expect Shawn to pick this one up as this file gets touched a fair 
amount.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 05/13] dt-bindings: gpu: vivante, gc: Remove trailing whitespace

2020-09-14 Thread Rob Herring
On Fri, 04 Sep 2020 16:53:04 +0200, Krzysztof Kozlowski wrote:
> Remove whitespace at the end of line.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/gpu/vivante,gc.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/13] dt-bindings: power: fsl, imx-gpcv2: Document interrupt controller properties

2020-09-14 Thread Rob Herring
On Fri, 04 Sep 2020 16:53:00 +0200, Krzysztof Kozlowski wrote:
> The i.MX General Power Controller v2 is also an interrupt controller so
> document additional properties to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpc@303a:
> '#interrupt-cells', 'interrupt-controller' do not match any of the 
> regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 4 
>  1 file changed, 4 insertions(+)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 02/13] dt-bindings: display: bridge: nwl-dsi: Add common properties

2020-09-14 Thread Rob Herring
On Fri, 04 Sep 2020 16:53:01 +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (assigned-clocks and others) to
> fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: mipi-dsi@30a0:
> 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do 
> not match any of the regexes: '^panel@[0-9]+$', 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 4 
>  1 file changed, 4 insertions(+)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 3/6] dt-bindings: gpu: arm, mali-utgard: Correct Maxime's email

2020-09-14 Thread Rob Herring
On Thu, 03 Sep 2020 21:14:35 +0200, Krzysztof Kozlowski wrote:
> Update the address of Maxime Ripard as one in @free-electrons.com does
> not work.
> 
> Cc: Maxime Ripard 
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Maxime Ripard 
> 
> ---
> 
> Changes since v1:
> 1. Add Ack
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 4/6] dt-bindings: gpu: samsung-rotator: Add missing properties

2020-09-14 Thread Rob Herring
On Thu, Sep 03, 2020 at 09:14:36PM +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (iommus, power-domains) to fix
> dtbs_check warnings like:
> 
>   arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
> 'iommus', 'power-domains' do not match any of the regexes: 
> 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Add properties instead of using unevaluated
> ---
>  Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml 
> b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
> index 665c6e3b31d3..f480174fe0d3 100644
> --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
> +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
> @@ -22,6 +22,9 @@ properties:
>interrupts:
>  maxItems: 1
>  
> +  iommus: true
> +  power-domains: true

These need to define how many. I assume 1, so 'maxItems: 1'.

> +
>clocks:
>  maxItems: 1
>  
> -- 
> 2.17.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/6] dt-bindings: gpu: arm, mali-utgard: Add missing properties

2020-09-14 Thread Rob Herring
On Thu, 03 Sep 2020 21:14:34 +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (opp-table) to fix dtbs_check
> warnings like:
> 
>   arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300:
> 'opp-table' does not match any of the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Add properties instead of using unevaluated
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/6] dt-bindings: gpu: arm, mali-midgard: Add missing properties

2020-09-14 Thread Rob Herring
On Thu, 03 Sep 2020 21:14:33 +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (opp-table) to fix dtbs_check
> warnings like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac:
> 'opp-table' does not match any of the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Add properties instead of using unevaluated
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/4] dt-bindings: display: samsung, amoled-mipi-dsi: Do not require enable-gpios on samsung, s6e63j0x03

2020-09-14 Thread Rob Herring
On Sat, 29 Aug 2020 19:25:29 +0200, Krzysztof Kozlowski wrote:
> The samsung,s6e63j0x03 does not have enable GPIO, so do not require it.
> This fixes dtbs_check warning:
> 
>   arch/arm/boot/dts/exynos3250-rinato.dt.yaml: panel@0: 'enable-gpios' is a 
> required property
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../display/panel/samsung,amoled-mipi-dsi.yaml   | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 05/10] dt-bindings: connector: Convert Samsung 11-pin USB bindings to dtschema

2020-09-14 Thread Rob Herring
On Sat, 29 Aug 2020 16:24:56 +0200, Krzysztof Kozlowski wrote:
> Add Samsung 11-pin USB-C connector into standard dtschema bindings file.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../connector/samsung,usb-connector-11pin.txt | 49 ---
>  .../bindings/connector/usb-connector.yaml | 44 +
>  2 files changed, 44 insertions(+), 49 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 4/5] dt-bindings: display/bridge: nwl-dsi: Document fsl,clock-drop-level property

2020-09-09 Thread Rob Herring
On Fri, Aug 28, 2020 at 02:13:31PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras 
> 
> Add documentation for a new property: 'fsl,clock-drop-level'.
> 
> Signed-off-by: Robert Chiras 
> ---
>  Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml 
> b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> index 8b5741b..b415f4e 100644
> --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -143,6 +143,10 @@ properties:
>  
>  additionalProperties: false
>  
> +  clock-drop-level:

fsl, ?

> +description:
> +  Specifies the level at wich the crtc_clock should be dropped

Needs a type $ref.

> +
>  patternProperties:
>"^panel@[0-9]+$":
>  type: object
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/6] dt-bindings: display: Document NewVision NV3052C DT node

2020-09-08 Thread Rob Herring
On Sat, 22 Aug 2020 18:32:45 +0200, Paul Cercueil wrote:
> Add documentation for the Device Tree node for LCD panels based on the
> NewVision NV3052C controller.
> 
> v2: - Support backlight property
> - Add *-supply properties for the 5 different power supplies.
>   Either they must all be present, or 'power-supply' must be
>   present.
> - Reword description to avoid confusion about 'driver'
> - Use 4-space indent in example
> 
> Signed-off-by: Paul Cercueil 
> ---
>  .../display/panel/newvision,nv3052c.yaml  | 100 ++
>  1 file changed, 100 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property

2020-09-08 Thread Rob Herring
On Tue, Sep 1, 2020 at 4:27 AM Laurent Pinchart
 wrote:
>
> Hi Rob,
>
> On Mon, Aug 24, 2020 at 05:04:58PM -0600, Rob Herring wrote:
> > On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote:
> > > Document optional vcc-supply property that may be used as VCC source.
> > >
> > > Signed-off-by: Biju Das 
> > > ---
> > > New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/
> > > ---
> > >  .../devicetree/bindings/display/bridge/lvds-codec.yaml | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml 
> > > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > index 68951d56ebba..3248be31eceb 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > @@ -79,6 +79,9 @@ properties:
> > >The GPIO used to control the power down line of this device.
> > >  maxItems: 1
> > >
> > > +  vcc-supply:
> > > +maxItems: 1
> >
> > Probably should be 'power-supply' to align with the 'simple' panels.
> > That's also to signify there's only 1 supply. Using 'vcc' would
> > encourage adding 'vdd-supply', 'vddio-supply', etc. A second supply I'll
> > NAK because at that point it's not a simple bridge with no configuration
> > (it's arguably already there).
>
> Fully agreed.
>
> Do I get your Ab or Rb line with s/vcc/power/ and the commit message
> updated to
>
> dt-bindings: display: bridge: lvds-codec: Document power-supply property
>
> Document optional power-supply property that may be used to specify the
> regulator powering up the device.
>
> ?

Yes, if not too late.

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: gpu: samsung-rotator: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sun, Aug 30, 2020 at 01:30:02PM +0200, Krzysztof Kozlowski wrote:
> Additional properties or nodes actually might appear (e.g. power
> domains) so use unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
> 'iommus', 'power-domains' do not match any of the regexes: 
> 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Tue, Sep 01, 2020 at 03:50:00PM +0100, Mark Brown wrote:
> On Sat, 29 Aug 2020 16:24:52 +0200, Krzysztof Kozlowski wrote:
> > Additional properties actually might appear (e.g. assigned-clocks) so
> > use unevaluatedProperties to fix dtbs_check warnings like:
> > 
> >   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: 
> > system-controller@105c:
> > 'assigned-clock-parents', 'assigned-clocks' do not match any of the 
> > regexes: 'pinctrl-[0-9]+'
> 
> Applied to
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
> 
> Thanks!
> 
> [1/1] ASoC: samsung-i2s: Use unevaluatedProperties
>   commit: 8187d8300251a99e40e288be80bef6a15b7b22e4

Please revert or drop. All these 'unevaluatedProperties' changes are 
wrong.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 06/10] dt-bindings: sound: samsung-i2s: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:57PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. power-domains) so use
> unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2s@1144:
> Additional properties are not allowed ('power-domains', '#address-cells', 
> 'interrupts', '#size-cells' were unexpected)
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/sound/samsung-i2s.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 02/10] dt-bindings: gpu: arm,mali-midgard: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:53PM +0200, Krzysztof Kozlowski wrote:
> Additional properties or nodes actually might appear (e.g. operating
> points table) so use unevaluatedProperties to fix dtbs_check warnings
> like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac:
> 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 03/10] dt-bindings: timer: exynos4210-mct: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:54PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. clocks) so use
> unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: timer@101c:
> 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/timer/samsung,exynos4210-mct.yaml   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sat, Aug 29, 2020 at 04:24:52PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. assigned-clocks) so
> use unevaluatedProperties to fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: 
> system-controller@105c:
> 'assigned-clock-parents', 'assigned-clocks' do not match any of the 
> regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

NAK. See 
https://lore.kernel.org/r/cal_jsqkpxjxshps34_tcf9bwgkxznsv4mvqr-wkrnknqvtg...@mail.gmail.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: gpu: arm, mali-utgard: Use unevaluatedProperties

2020-09-03 Thread Rob Herring
On Sun, Aug 30, 2020 at 2:40 AM Krzysztof Kozlowski  wrote:
>
> Additional properties or nodes actually might appear (e.g. operating
> points table) so use unevaluatedProperties to fix dtbs_check warnings
> like:
>
>   arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300:
> 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+'

When unevaluatedProperties support is actually implemented (there's a
prototype), this will still be a warning. You need to document any
additional properties/nodes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/5] dt-bindings: display/bridge: nwl-dsi: Document video_pll clock

2020-08-28 Thread Rob Herring
On Fri, 28 Aug 2020 14:13:29 +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras 
> 
> Add documentation for a new clock 'video_pll'.
> 
> Signed-off-by: Robert Chiras 
> ---
>  Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
 mipi_dsi@30a0: clocks: [[4294967295, 163], [4294967295, 244], [4294967295, 
245], [4294967295, 164], [4294967295, 128]] is too short
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
 mipi_dsi@30a0: clock-names: ['core', 'rx_esc', 'tx_esc', 'phy_ref', 
'lcdif'] is too short
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml


See https://patchwork.ozlabs.org/patch/1353197

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH RFC v6 1/6] dt-bindings: display: add Unisoc's drm master bindings

2020-08-28 Thread Rob Herring
On Tue, Jul 28, 2020 at 4:08 AM Kevin Tang  wrote:
>
> From: Kevin Tang 
>
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
>
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> ---
>  .../devicetree/bindings/display/sprd/drm.yaml  | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml

If you want bindings reviewed, then you need to Cc
devicet...@vger.kernel.org. Otherwise you may be waiting until the 6th
version or later or never.

>
> diff --git a/Documentation/devicetree/bindings/display/sprd/drm.yaml 
> b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> new file mode 100644
> index 000..b5792c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: GPL-2.0

New bindings should be dual licensed:

(GPL-2.0-only OR BSD-2-Clause)

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/drm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc DRM master device

DRM is a Linux thing and shouldn't be part of a binding.

> +
> +maintainers:
> +  - Mark Rutland 

No, this should be you or someone that knows the h/w.

> +
> +description: |
> +  The Unisoc DRM master device is a virtual device needed to list all
> +  DPU devices or other display interface nodes that comprise the
> +  graphics subsystem.
> +
> +properties:
> +  compatible:
> +const: sprd,display-subsystem
> +
> +  ports:
> +description:
> +  Should contain a list of phandles pointing to display interface port
> +  of DPU devices.
> +
> +required:
> +  - compatible
> +  - ports
> +
> +examples:
> +  - |
> +display-subsystem {
> +compatible = "sprd,display-subsystem";
> +ports = <_out>;

We generally try to avoid this virtual node as it doesn't represent
any h/w. Can't you bind the driver to the DPU directly?

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 1/2] dt-bindings: display: himax, hx8837: Add Himax HX8837 bindings

2020-08-25 Thread Rob Herring
On Wed, 19 Aug 2020 12:22:45 +0200, Lubomir Rintel wrote:
> Himax HX8837 is a secondary display controller used to drive the panel
> on OLPC platforms.
> 
> Signed-off-by: Lubomir Rintel 
> 
> ---
> Changes since v3:
> - Moved to bindings/display/
> - Added the ports
> - Converted to YAML
> - Removed Pavel's Ack, because the changes are substantial
> 
> Changes since v2:
> - s/betweend/between/
> 
> Changes since v1:
> - s/load-gpio/load-gpios/
> - Use interrupt bindings instead of gpio for the IRQ
> 
>  .../bindings/display/bridge/himax,hx8837.yaml | 96 +++
>  1 file changed, 96 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] dt-bindings: display: simple: add Innolux LS075AT011

2020-08-25 Thread Rob Herring
On Wed, 19 Aug 2020 12:12:05 +0200, Lubomir Rintel wrote:
> Add the Innolux LS075AT011 7.5" (1200x900) color/reflective LCD panel to
> the panel-simple compatible list. This panel is used in the OLPC laptops.
> 
> Signed-off-by: Lubomir Rintel 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 22/36] dt-bindings: host1x: Document new interconnect properties

2020-08-24 Thread Rob Herring
On Fri, 14 Aug 2020 03:06:07 +0300, Dmitry Osipenko wrote:
> Most of Host1x devices have at least one memory client. These clients
> are directly connected to the memory controller. The new interconnect
> properties represent the memory client's connection to the memory
> controller.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  .../display/tegra/nvidia,tegra20-host1x.txt   | 68 +++
>  1 file changed, 68 insertions(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/8] dt-bindings: display: mxsfb: Convert binding to YAML

2020-08-24 Thread Rob Herring
On Thu, Aug 13, 2020 at 04:29:03AM +0300, Laurent Pinchart wrote:
> Convert the mxsfb binding to YAML. The deprecated binding is dropped, as
> neither the DT sources nor the driver support it anymore.

Ah, the first display controller I worked on...

> 
> The compatible strings are messy, and DT sources use different kinds of
> combination of documented and undocumented values. Keep it simple for
> now, and update the example to make it valid. Aligning the binding with
> the existing DT sources will be performed separately.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../devicetree/bindings/display/mxsfb.txt |  87 -
>  .../devicetree/bindings/display/mxsfb.yaml| 115 ++
>  MAINTAINERS   |   2 +-
>  3 files changed, 116 insertions(+), 88 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/mxsfb.txt
>  create mode 100644 Documentation/devicetree/bindings/display/mxsfb.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt 
> b/Documentation/devicetree/bindings/display/mxsfb.txt
> deleted file mode 100644
> index c985871c46b3..
> --- a/Documentation/devicetree/bindings/display/mxsfb.txt
> +++ /dev/null
> @@ -1,87 +0,0 @@
> -* Freescale MXS LCD Interface (LCDIF)
> -
> -New bindings:
> -=
> -Required properties:
> -- compatible:Should be "fsl,imx23-lcdif" for i.MX23.
> - Should be "fsl,imx28-lcdif" for i.MX28.
> - Should be "fsl,imx6sx-lcdif" for i.MX6SX.
> - Should be "fsl,imx8mq-lcdif" for i.MX8MQ.
> -- reg:   Address and length of the register set for LCDIF
> -- interrupts:Should contain LCDIF interrupt
> -- clocks:A list of phandle + clock-specifier pairs, one for each
> - entry in 'clock-names'.
> -- clock-names:   A list of clock names. For MXSFB it should contain:
> -- "pix" for the LCDIF block clock
> -- (MX6SX-only) "axi", "disp_axi" for the bus interface clock
> -
> -Required sub-nodes:
> -  - port: The connection to an encoder chip.
> -
> -Example:
> -
> - lcdif1: display-controller@222 {
> - compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
> - reg = <0x0222 0x4000>;
> - interrupts = ;
> - clocks = < IMX6SX_CLK_LCDIF1_PIX>,
> -  < IMX6SX_CLK_LCDIF_APB>,
> -  < IMX6SX_CLK_DISPLAY_AXI>;
> - clock-names = "pix", "axi", "disp_axi";
> -
> - port {
> - parallel_out: endpoint {
> - remote-endpoint = <_in_parallel>;
> - };
> - };
> - };
> -
> -Deprecated bindings:
> -
> -Required properties:
> -- compatible:Should be "fsl,imx23-lcdif" for i.MX23.
> - Should be "fsl,imx28-lcdif" for i.MX28.
> -- reg:   Address and length of the register set for LCDIF
> -- interrupts:Should contain LCDIF interrupts
> -- display:   phandle to display node (see below for details)
> -
> -* display node
> -
> -Required properties:
> -- bits-per-pixel:<16> for RGB565, <32> for RGB888/666.
> -- bus-width: number of data lines.  Could be <8>, <16>, <18> or <24>.
> -
> -Required sub-node:
> -- display-timings:   Refer to binding doc display-timing.txt for details.
> -
> -Examples:
> -
> -lcdif@8003 {
> - compatible = "fsl,imx28-lcdif";
> - reg = <0x8003 2000>;
> - interrupts = <38 86>;
> -
> - display: display {
> - bits-per-pixel = <32>;
> - bus-width = <24>;
> -
> - display-timings {
> - native-mode = <>;
> - timing0: timing0 {
> - clock-frequency = <3350>;
> - hactive = <800>;
> - vactive = <480>;
> - hfront-porch = <164>;
> - hback-porch = <89>;
> - hsync-len = <10>;
> - vback-porch = <23>;
> - vfront-porch = <10>;
> - vsync-len = <10>;
> - hsync-active = <0>;
> - vsync-active = <0>;
> - de-active = <1>;
> - pixelclk-active = <0>;
> - };
> - };
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/display/mxsfb.yaml 
> b/Documentation/devicetree/bindings/display/mxsfb.yaml
> new file mode 100644
> index ..202381ec5bb7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mxsfb.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mxsfb.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> 

Re: [PATCH 2/8] dt-bindings: display: mxsfb: Add and fix compatible strings

2020-08-24 Thread Rob Herring
On Mon, Aug 17, 2020 at 03:04:06AM +0300, Laurent Pinchart wrote:
> Hi Sam,
> 
> On Sun, Aug 16, 2020 at 08:39:33AM +0200, Sam Ravnborg wrote:
> > On Thu, Aug 13, 2020 at 04:29:04AM +0300, Laurent Pinchart wrote:
> > > Additional compatible strings have been added in DT source for the
> > > i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
> > > Most of the upstream DT sources use the fsl,imx28-lcdif compatible
> > > string, which mostly predates the realization that the LCDIF in the
> > > i.MX6 and newer SoCs have extra features compared to the i.MX28.
> > > 
> > > Update the bindings to add the missing compatible strings, with the
> > > correct fallback values. This fails to validate some of the upstream DT
> > > sources. Instead of adding the incorrect compatible fallback to the
> > > binding, the sources should be updated separately.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > >  .../devicetree/bindings/display/mxsfb.yaml | 18 +-
> > >  1 file changed, 13 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/mxsfb.yaml 
> > > b/Documentation/devicetree/bindings/display/mxsfb.yaml
> > > index 202381ec5bb7..ec6533b1d4a3 100644
> > > --- a/Documentation/devicetree/bindings/display/mxsfb.yaml
> > > +++ b/Documentation/devicetree/bindings/display/mxsfb.yaml
> > > @@ -15,11 +15,19 @@ description: |
> > >  
> > >  properties:
> > >compatible:
> > > -enum:
> > > -  - fsl,imx23-lcdif
> > > -  - fsl,imx28-lcdif
> > > -  - fsl,imx6sx-lcdif
> > > -  - fsl,imx8mq-lcdif
> > > +oneOf:
> > > +  - enum:
> > > +  - fsl,imx23-lcdif
> > > +  - fsl,imx28-lcdif
> > > +  - fsl,imx6sx-lcdif
> >
> > Indent correct.
> > 
> > > +  - items:
> > > +- enum:
> > > +  - fsl,imx6sl-lcdif
> > > +  - fsl,imx6sll-lcdif
> > > +  - fsl,imx6ul-lcdif
> > > +  - fsl,imx7d-lcdif
> > > +  - fsl,imx8mq-lcdif
> >
> > Indent shall be two more spaces like above.
> > (This is at least my best uderstanding)
> 
> I think you're right. I wonder why dt_binding_check doesn't complain.
> I'll fix it anyway.

Because I haven't integrated yamllint yet. I do have a config file at 
least.

> 
> > > +- const: fsl,imx6sx-lcdif
> > 
> > With the above the following compatibles are supported:
> > 
> > "fsl,imx23-lcdif"
> > "fsl,imx28-lcdif"
> > "fsl,imx6sx-lcdif"
> > "fsl,imx8mq-lcdif"
> > 
> > "fsl,imx6sl-lcdif", "fsl,imx6sx-lcdif"
> > "fsl,imx6sll-lcdif", "fsl,imx6sx-lcdif"
> > "fsl,imx6ul-lcdif", "fsl,imx6sx-lcdif"
> > "fsl,imx7d-lcdif", "fsl,imx6sx-lcdif"
> > "fsl,imx8mq-lcdif", "fsl,imx6sx-lcdif"
> > 
> > So the fallback value is the later "fsl,imx6sx-lcdif" which looks ok.
> > 
> > With indent fixed (or explained why I am wrong):
> > Reviewed-by: Sam Ravnborg 
> > 
> > >  
> > >reg:
> > >  maxItems: 1
> 
> -- 
> Regards,
> 
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 4/9] dt-bindings: display: renesas, lvds: Document r8a774e1 bindings

2020-08-24 Thread Rob Herring
On Wed, 12 Aug 2020 15:02:12 +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu 
> 
> Document the RZ/G2H (R8A774E1) LVDS bindings.
> 
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 
> ---
>  .../devicetree/bindings/display/bridge/renesas,lvds.txt  | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 5/9] dt-bindings: display: renesas, dw-hdmi: Add r8a774e1 support

2020-08-24 Thread Rob Herring
On Wed, 12 Aug 2020 15:02:13 +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu 
> 
> Document RZ/G2H (R8A774E1) SoC bindings.
> 
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 
> ---
>  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt   | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property

2020-08-24 Thread Rob Herring
On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote:
> Document optional vcc-supply property that may be used as VCC source.
> 
> Signed-off-by: Biju Das 
> ---
> New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/
> ---
>  .../devicetree/bindings/display/bridge/lvds-codec.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml 
> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> index 68951d56ebba..3248be31eceb 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> @@ -79,6 +79,9 @@ properties:
>The GPIO used to control the power down line of this device.
>  maxItems: 1
>  
> +  vcc-supply:
> +maxItems: 1

Probably should be 'power-supply' to align with the 'simple' panels. 
That's also to signify there's only 1 supply. Using 'vcc' would 
encourage adding 'vdd-supply', 'vddio-supply', etc. A second supply I'll 
NAK because at that point it's not a simple bridge with no configuration 
(it's arguably already there).

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

2020-08-24 Thread Rob Herring
On Mon, Aug 10, 2020 at 07:08:02PM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
> 
> Signed-off-by: Krishna Manikandan 
> 
> Changes in v2:
> - Changed dpu to DPU (Sam Ravnborg)
> - Fixed indentation issues (Sam Ravnborg)
> - Added empty line between different properties (Sam Ravnborg)
> - Replaced reference txt files with  their corresponding
>   yaml files (Sam Ravnborg)
> - Modified the file to use "|" only when it is
>   necessary (Sam Ravnborg)
> 
> Changes in v3:
> - Corrected the license used (Rob Herring)
> - Added maxItems for properties (Rob Herring)
> - Dropped generic descriptions (Rob Herring)
> - Added ranges property (Rob Herring)
> - Corrected the indendation (Rob Herring)
> - Added additionalProperties (Rob Herring)
> - Split dsi file into two, one for dsi controller
>   and another one for dsi phy per target (Rob Herring)
> - Corrected description for pinctrl-names (Rob Herring)
> - Corrected the examples used in yaml file (Rob Herring)
> - Delete dsi.txt and dpu.txt (Rob Herring)
> 
> Changes in v4:
> - Move schema up by one level (Rob Herring)
>     - Add patternProperties for mdp node (Rob Herring)
> - Corrected description of some properties (Rob Herring)
> 
> Changes in v5:
> - Correct the indentation (Rob Herring)
>     - Remove unnecessary description from properties (Rob Herring)
> - Correct the number of interconnect entries (Rob Herring)
> - Add interconnect names for sc7180 (Rob Herring)
>     - Add description for ports (Rob Herring)
> - Remove common properties (Rob Herring)
> - Add unevalutatedProperties (Rob Herring)
> - Reference existing dsi controller yaml in the common
>       dsi controller file (Rob Herring)
> - Correct the description of clock names to include only the
>   clocks that are required (Rob Herring)
> - Remove properties which are already covered under the common
>   binding (Rob Herring)
> - Add dsi phy supply nodes which are required for sc7180 and
>   sdm845 targets (Rob Herring)
> - Add type ref for syscon-sfpb (Rob Herring)
> 
> Changes in v6:
>     - Fixed errors during dt_binding_check (Rob Herring)
> - Add maxItems for phys and phys-names (Rob Herring)
> - Use unevaluatedProperties wherever required (Rob Herring)
> - Removed interrupt controller from required properties for
>   dsi controller (Rob Herring)
> - Add constraints for dsi-phy reg-names based on the compatible
>   phy version (Rob Herring)
>     - Add constraints for dsi-phy supply nodes based on the
>   compatible phy version (Rob Herring)
> 
> Changes in v7:
> - Add default value for qcom,mdss-mdp-transfer-time-us (Rob Herring)
> - Modify the schema for data-lanes (Rob Herring)
> - Split the phy schema into separate schemas based on
>   the phy version (Rob Herring)
> 
> Changes in v8:
> - Resolve merge conflicts with latest dsi.txt file
> - Include dp yaml change also in the same series

I'm done reviewing this because I'm tired of repeating myself and you're 
just throwing crap at the wall and seeing what sticks. Get someone else 
working on QCom stuff to review because I'm done until someone I know 
and trust reviews it.

> ---
>  .../bindings/display/msm/dpu-sc7180.yaml   | 236 +++
>  .../bindings/display/msm/dpu-sdm845.yaml   | 216 ++
>  .../devicetree/bindings/display/msm/dpu.txt| 141 
>  .../display/msm/dsi-common-controller.yaml | 249 
> +
>  .../display/msm/dsi-controller-sc7180.yaml | 120 ++
>  .../display/msm/dsi-controller-sdm845.yaml | 120 ++

Once again, what's the difference between dsi-controller-sc7180.yaml and 
dsi-controller-sdm845.yaml? I don't see one. If there's not a 
difference, why do we have msm/dsi-common-controller.yaml? If there is a 
difference dsi-controller-sc7180.yaml and dsi-controller-sdm845.yaml 
should *only* have what's different because 
msm/dsi-common-controller.yaml should have everything that is the same.

>  .../bindings/display/msm/dsi-phy-10nm.yaml |  62 +
>  .../bindings/display/msm/dsi-phy-14nm.yaml |  62 +
>  .../bindings/display/msm/dsi-phy-20nm.yaml |  66 ++
>  .../bindings/display/msm/dsi-phy-28nm.yaml |  62 +
>  .../bindings/display/msm/dsi-phy-sc7180.yaml   |  80 +++
>  .../bindings/display/msm/dsi-phy-sdm845.yaml   |  82 +++
>  .../devicetree/bindin

Re: [PATCH v1 1/2] ite-it6505 change trigger conditions

2020-08-24 Thread Rob Herring
On Mon, Aug 10, 2020 at 06:11:15PM +0800, allen wrote:
> it6505 changes trigger conditions.

Patches must have a Signed-off-by with a full name.


> ---
>  Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> index 2c50016..bf0e889 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> @@ -73,7 +73,7 @@ examples:
>  
>  dp-bridge@5c {
>  compatible = "ite,it6505";
> -interrupts = <152 IRQ_TYPE_EDGE_FALLING 152 0>;
> +interrupts = <152 IRQ_TYPE_LEVEL_LOW 152 0>;

How does this have 2 interrupts which are the same irq number, but 
different flags?

>  reg = <0x5c>;
>  pinctrl-names = "default";
>  pinctrl-0 = <_pins>;
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/7] dt-bindings: display: renesas, lvds: Document r8a7742 bindings

2020-08-24 Thread Rob Herring
On Fri, 07 Aug 2020 18:49:50 +0100, Lad Prabhakar wrote:
> Document the RZ/G1H (R8A7742) LVDS bindings.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  .../devicetree/bindings/display/bridge/renesas,lvds.txt  | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/7] dt-bindings: display: renesas, du: Document the r8a7742 bindings

2020-08-24 Thread Rob Herring
On Fri, 07 Aug 2020 18:49:48 +0100, Lad Prabhakar wrote:
> Document the RZ/G1H (R8A7742) SoC in the R-Car DU bindings.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 
> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/3 v3] dt-bindings: backlight: Add Kinetic KTD253 bindings

2020-08-24 Thread Rob Herring
On Wed, 19 Aug 2020 22:51:49 +0200, Linus Walleij wrote:
> This adds device tree bindings for the Kinetic KTD253
> white LED backlight driver.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Sam Ravnborg 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v2->v3:
> - Drop the pointless cargo-culted "default-on" property that
>   we were not using
> - Correct the brightness in the example to something legal (13)
> ChangeLog v1->v2:
> - Create common.yaml for backlight as suggested by Sam and
>   use that.
> - Rename the GPIO line "enable-gpios"
> ---
>  .../leds/backlight/kinetic,ktd253.yaml| 46 +++
>  1 file changed, 46 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3 v3] dt-bindings: backlight: Add some common backlight properties

2020-08-24 Thread Rob Herring
On Wed, Aug 19, 2020 at 10:51:48PM +0200, Linus Walleij wrote:
> Let's use a common.yaml include for the backlight like we do with
> the LEDs. The LEDs are inherently incompatible so their bindings
> cannot be reused for backlight.
> 
> Cc: devicet...@vger.kernel.org
> Suggested-by: Sam Ravnborg 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v2->v3:
> - Drop the | for the description
> - Drop the "default-on" property, we're not using it.
> - Drop the minimum 0 for unsigned u32:s
> ChangeLog v1->v2:
> - New patch as suggested by Sam.
> ---
>  .../bindings/leds/backlight/common.yaml   | 34 +++
>  1 file changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/common.yaml

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1 21/21] arm64: dts: mt8192: add display node

2020-08-20 Thread Rob Herring
On Thu, Aug 20, 2020 at 12:06 AM Yongqiang Niu
 wrote:
>
> add display node
>
> Signed-off-by: Yongqiang Niu 
> ---
>  arch/arm64/boot/dts/mediatek/mt8192.dtsi | 126 
> +++
>  1 file changed, 126 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> index 931e1ca..d2a814d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> @@ -17,6 +17,13 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> +aliases {
> +   ovl0 = 
> +   ovl_2l0 = _2l0;
> +   ovl_2l2 = _2l2;
> +   rdma0 = 
> +   rdma4 = 

No, please don't add a bunch of custom aliases that you probably don't need.

> +   };
> clk26m: oscillator@0 {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> @@ -449,6 +456,125 @@
> #clock-cells = <1>;
> };
>
> +mutex: mutex@14001000 {
> +   compatible = "mediatek,mt8192-disp-mutex";
> +   reg = <0 0x14001000 0 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_MM_DISP_CONFIG>,
> +< CLK_MM_26MHZ>,
> +< CLK_MM_DISP_MUTEX0>;
> +   };
> +   ovl0: ovl@14005000 {
> +   compatible = "mediatek,mt8192-disp-ovl";
> +   reg = <0 0x14005000 0 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_MM_DISP_OVL0>;
> +   //iommus = < M4U_PORT_L0_OVL_RDMA0>,
> +   //   < M4U_PORT_L0_OVL_RDMA0_HDR>;
> +   power-domains = < MT8192_POWER_DOMAIN_DISP>;
> +   //mediatek,gce-client-reg = < SUBSYS_1400 
> 0x5000 0x1000>;
> +   };
> +
> +   ovl_2l0: ovl@14006000 {
> +   compatible = "mediatek,mt8192-disp-ovl-2l";
> +   reg = <0 0x14006000 0 0x1000>;
> +   interrupts = ;
> +   power-domains = < MT8192_POWER_DOMAIN_DISP>;
> +   clocks = < CLK_MM_DISP_OVL0_2L>;
> +   //iommus = < M4U_PORT_L1_OVL_2L_RDMA0>,
> +   //   < M4U_PORT_L1_OVL_2L_RDMA0_HDR>;
> +   //mediatek,gce-client-reg = < SUBSYS_1400 
> 0x6000 0x1000>;
> +   };
> +
> +   rdma0: rdma@14007000 {
> +   compatible = "mediatek,mt8192-disp-rdma";
> +   reg = <0 0x14007000 0 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_MM_DISP_RDMA0>;
> +   //iommus = < M4U_PORT_L0_DISP_RDMA0>;
> +   mediatek,rdma_fifo_size = <5>;
> +   power-domains = < MT8192_POWER_DOMAIN_DISP>;
> +   //mediatek,gce-client-reg = < SUBSYS_1400 
> 0x7000 0x1000>;
> +   };
> +
> +   color0: color@14009000 {
> +   compatible = "mediatek,mt8192-disp-color",
> +"mediatek,mt8173-disp-color";
> +   reg = <0 0x14009000 0 0x1000>;
> +   interrupts = ;
> +   power-domains = < MT8192_POWER_DOMAIN_DISP>;
> +   clocks = < CLK_MM_DISP_COLOR0>;
> +   //mediatek,gce-client-reg = < SUBSYS_1400 
> 0x9000 0x1000>;
> +   };
> +
> +   ccorr0: ccorr@1400a000 {
> +   compatible = "mediatek,mt8192-disp-ccorr";
> +   reg = <0 0x1400a000 0 0x1000>;
> +   interrupts = ;
> +   power-domains = < MT8192_POWER_DOMAIN_DISP>;
> +   clocks = < CLK_MM_DISP_CCORR0>;
> +   //mediatek,gce-client-reg = < SUBSYS_1400 
> 0xa000 0x1000>;
> +   };
> +
> +   aal0: aal@1400b000 {
> +   compatible = "mediatek,mt8192-disp-aal";
> +   reg = <0 0x1400b000 0 0x1000>;
> +   interrupts = ;
> +   power-domains = < MT8192_POWER_DOMAIN_DISP>;
> +   clocks = < CLK_MM_DISP_AAL0>;
> +   //mediatek,gce-client-reg = < SUBSYS_1400 
> 0xb000 0x1000>;
> +   };
> +
> +   gamma0: gamma@1400c000 {
> +   compatible = "mediatek,mt8192-disp-gamma";
> +   reg = <0 0x1400c000 0 0x1000>;
> +   interrupts = ;
> +   power-domains = < MT8192_POWER_DOMAIN_DISP>;
> +   clocks = < CLK_MM_DISP_GAMMA0>;
> +   //mediatek,gce-client-reg = < 

Re: [PATCH 49/49] dt: display: Add binds for the DPE and DSI controller for Kirin 960/970

2020-08-19 Thread Rob Herring
On Wed, 19 Aug 2020 13:46:17 +0200, Mauro Carvalho Chehab wrote:
> Add a description of the bindings used by Kirin 960/970 Display
> Serial Interface (DSI) controller and by its Display Engine (DPE).
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  .../display/hisilicon,hi3660-dpe.yaml |  99 +
>  .../display/hisilicon,hi3660-dsi.yaml | 102 ++
>  .../boot/dts/hisilicon/hikey970-drm.dtsi  |   4 +-
>  3 files changed, 203 insertions(+), 2 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/hisilicon,hi3660-dpe.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/hisilicon,hi3660-dsi.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

Error: 
Documentation/devicetree/bindings/display/hisilicon,hi3660-dsi.example.dts:25.31-32
 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:342: 
Documentation/devicetree/bindings/display/hisilicon,hi3660-dsi.example.dt.yaml] 
Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1367: dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1347736

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/3] dma-heap: Devicetree binding for chunk heap

2020-08-18 Thread Rob Herring
On Tue, 18 Aug 2020 17:04:15 +0900, Hyesoo Yu wrote:
> Document devicetree binding for chunk heap on dma heap framework
> 
> Signed-off-by: Hyesoo Yu 
> ---
>  .../devicetree/bindings/dma-buf/chunk_heap.yaml| 46 
> ++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma-buf/chunk_heap.example.dt.yaml:
 chunk_default_heap: 'alignment', 'memory-region' do not match any of the 
regexes: 'pinctrl-[0-9]+'


See https://patchwork.ozlabs.org/patch/1346687

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: Whitespace clean-ups in schema files

2020-08-14 Thread Rob Herring
On Thu, Aug 13, 2020 at 4:31 AM Luca Ceresoli  wrote:
>
> Hi Rob,
>
> On 12/08/20 22:36, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which should always be 2 spaces more than the preceding
> > keyword.
> >
> > Found with yamllint (which I plan to integrate into the checks).
>
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
> > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > index 3d4e1685cc55..28c6461b9a9a 100644
> > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > @@ -95,10 +95,10 @@ allOf:
> ># Devices without builtin crystal
> >properties:
> >  clock-names:
> > -minItems: 1
> > -maxItems: 2
> > -items:
> > -  enum: [ xin, clkin ]
> > +  minItems: 1
> > +  maxItems: 2
> > +  items:
> > +enum: [ xin, clkin ]
> >  clocks:
> >minItems: 1
> >maxItems: 2
>
> Thanks for noticing, LGTM.
>
> [...]
>
> > diff --git 
> > a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml 
> > b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > index d7dac16a3960..36dc7b56a453 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > @@ -33,8 +33,8 @@ properties:
> >  $ref: /schemas/types.yaml#/definitions/uint32
> >
> >touchscreen-min-pressure:
> > -description: minimum pressure on the touchscreen to be achieved in 
> > order for the
> > - touchscreen driver to report a touch event.
> > +description: minimum pressure on the touchscreen to be achieved in 
> > order
> > +  for the touchscreen driver to report a touch event.
>
> Out of personal taste, I find the original layout more pleasant and
> readable. This third option is also good, especially for long descriptions:
>
>   description:
> minimum pressure on the touchscreen to be achieved in order for the
> touchscreen driver to report a touch event.
>
> At first glance yamllint seems to support exactly these two by default:
>
> > With indentation: {spaces: 4, check-multi-line-strings: true}

Turning on check-multi-line-strings results in 10K+ warnings, so no.

The other issue is the style ruamel.yaml wants to write out is as the
patch does above. This matters when doing some scripted
transformations where we read in the files and write them back out. I
can somewhat work around that by first doing a pass with no changes
and then another pass with the actual changes, but that's completely
scriptable. Hopefully, ruamel learns to preserve the style better.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: Whitespace clean-ups in schema files

2020-08-12 Thread Rob Herring
On Wed, Aug 12, 2020 at 4:32 PM Joe Perches  wrote:
>
> On Wed, 2020-08-12 at 14:36 -0600, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which should always be 2 spaces more than the preceding
>  ^
> > keyword.

keyword is the key part...

> []
> > diff --git a/Documentation/devicetree/bindings/arm/arm,integrator.yaml 
> > b/Documentation/devicetree/bindings/arm/arm,integrator.yaml
> > index 192ded470e32..f0daf990e077 100644
> > --- a/Documentation/devicetree/bindings/arm/arm,integrator.yaml
> > +++ b/Documentation/devicetree/bindings/arm/arm,integrator.yaml
> > @@ -67,9 +67,9 @@ patternProperties:
> >compatible:
> >  items:
> >- enum:
> > -- arm,integrator-ap-syscon
> > -- arm,integrator-cp-syscon
> > -- arm,integrator-sp-syscon
> > +  - arm,integrator-ap-syscon
> > +  - arm,integrator-cp-syscon
> > +  - arm,integrator-sp-syscon
>
> Confused a bit here.
>   - enum:
> 10 spaces to dash
> old line:
> - arm,integrator-ap-syscon
> 12 spaces to dash
> new line:
>   - arm,integrator-ap-syscon
> 14 spaces to dash
>
> Is it supposed to be 2 spaces more than the preceding line
> or 4 more?

If the preceding line is a list entry (i.e. starts with '-'), then
it's 4 more spaces. It's always 2 more spaces than the preceding
keyword start (aka json-schema vocabulary).

Arguably, this style is a bit inconsistent in that the '-' counts
toward as indentation of the current line, but not the preceding line.
However, I think this style is a bit less error prone and easier to
review. With the other style (always N more spaces) it's harder to
distinguish lists vs. dicts. For example, you can have something like
this:

- key:
  - foo
  - bar

- key:
foo
bar

- key:
  - foo
bar

All 3 of these could be valid. Which one was intended? (Can't really
tell here, but you can with actual DT schema.)

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: Whitespace clean-ups in schema files

2020-08-12 Thread Rob Herring
On Wed, Aug 12, 2020 at 3:34 PM Sam Ravnborg  wrote:
>
> Hi Rob.
>
> On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which should always be 2 spaces more than the preceding
> > keyword.
> >
> > Found with yamllint (which I plan to integrate into the checks).
>
> I have browsed through the patch - and there was only a few things
> that jumped at me.
>
> With these points considered:
> Acked-by: Sam Ravnborg 
>
> I expect only some (few) of my points to actually results in any updates.
>
> I look forward to have the lint functionality as part of the built-in
> tools so we catch these things early.
>
> Sam
>
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
> > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index f63895c8ce2d..88814a2a14a5 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -273,8 +273,8 @@ properties:
> >- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK 
> > Board
> >- kontron,imx6ull-n6411-som # Kontron N6411 SOM
> >- myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation 
> > Board
> > -  - toradex,colibri-imx6ull-eval# Colibri iMX6ULL 
> > Module on Colibri Evaluation Board
> > -  - toradex,colibri-imx6ull-wifi-eval   # Colibri iMX6ULL 
> > Wi-Fi / Bluetooth Module on Colibri Evaluation Board
> > +  - toradex,colibri-imx6ull-eval  # Colibri iMX6ULL Module 
> > on Colibri Eval Board
> > +  - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi 
> > / BT Module on Colibri Eval Board
> >- const: fsl,imx6ull
>
> This change looks bad as it drops the alignment with the comments below.
> See following patch chunck:

Yes, but as a whole there's no alignment in this file. Even the rest
of the entries for the hunk below aren't aligned.

Perhaps this form would be better:

# Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board
  - toradex,colibri-imx6ull-wifi-eval

But I really don't want to go fix this in the whole file...

> >- description: Kontron N6411 S Board
> > @@ -312,9 +312,12 @@ properties:
> >- toradex,colibri-imx7d   # Colibri iMX7 
> > Dual Module
> >- toradex,colibri-imx7d-aster # Colibri iMX7 
> > Dual Module on Aster Carrier Board
> >- toradex,colibri-imx7d-emmc  # Colibri iMX7 
> > Dual 1GB (eMMC) Module
> > -  - toradex,colibri-imx7d-emmc-aster# Colibri iMX7 
> > Dual 1GB (eMMC) Module on Aster Carrier Board
> > -  - toradex,colibri-imx7d-emmc-eval-v3  # Colibri iMX7 
> > Dual 1GB (eMMC) Module on Colibri Evaluation Board V3
> > -  - toradex,colibri-imx7d-eval-v3   # Colibri iMX7 
> > Dual Module on Colibri Evaluation Board V3
> > +  - toradex,colibri-imx7d-emmc-aster# Colibri iMX7 
> > Dual 1GB (eMMC) Module on
> > +#  Aster Carrier 
> > Board
>
>
>
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml 
> > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
> > index 177d48c5bd97..e89c1ea62ffa 100644
> > --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
> > @@ -25,8 +25,7 @@ properties:
> >compatible:
> >  items:
> >- enum:
> > -- dlink,dir-685-panel
> > -
> > +  - dlink,dir-685-panel
> >- const: ilitek,ili9322
> >
> >reset-gpios: true
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml 
> > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> > index a39332276bab..76a9068a85dd 100644
> > --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> > @@ -13,8 +13,7 @@ properties:
> >compatible:
> >  items:
> >- enum:
> > -- bananapi,lhr050h41
> > -
> > +  - bananapi,lhr050h41
> >- const: ilitek,ili9881c
> >
>
> The extra lines i

Re: [PATCH V3 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge

2020-08-12 Thread Rob Herring
On Sun, 09 Aug 2020 12:57:04 +0200, Marek Vasut wrote:
> Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
> 
> Signed-off-by: Marek Vasut 
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt 
> Cc: Rob Herring 
> Cc: Sam Ravnborg 
> Cc: devicet...@vger.kernel.org
> ---
> V2: Fix dt_binding_check errors
> V3: Add ... at the end of example
> ---
>  .../display/bridge/toshiba,tc358762.yaml  | 127 ++
>  1 file changed, 127 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RESEND v7, PATCH 1/7] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display

2020-08-12 Thread Rob Herring
On Sat, Aug 08, 2020 at 10:53:45AM +0800, Yongqiang Niu wrote:
> rdma fifo size may be different even in same SOC, add this
> property to the corresponding rdma
> 
> Change-Id: I67635ec7f3f59cf4cbc7737285e5e28ff0ab71c9
> Signed-off-by: Yongqiang Niu 
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 14 
> ++
>  1 file changed, 14 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index b91e709..e6bbe32 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -66,6 +66,11 @@ Required properties (DMA function blocks):
>argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>for details.
>  
> +Optional properties (RDMA function blocks):
> +- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC, 
> add this

mediatek,rdma-fifo-size

What's the range/set of valid values?

> +  property to the corresponding rdma
> +  the value is the Max value which defined in hardware data sheet.
> +
>  Examples:
>  
>  mmsys: clock-controller@1400 {
> @@ -207,3 +212,12 @@ od@14023000 {
>   power-domains = < MT8173_POWER_DOMAIN_MM>;
>   clocks = < CLK_MM_DISP_OD>;
>  };
> +
> +rdma1: rdma@1400c000 {

Does a new property really need a whole new example?

> + compatible = "mediatek,mt8183-disp-rdma";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_RDMA1>;
> + mediatek,rdma_fifo_size = <2048>;
> +};
> -- 
> 1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3 v2] dt-bindings: backlight: Add some common backlight properties

2020-08-12 Thread Rob Herring
On Wed, Aug 12, 2020 at 2:58 AM Linus Walleij  wrote:
>
> Let's use a common.yaml include for the backlight like we do with
> the LEDs. The LEDs are inherently incompatible so their bindings
> cannot be reused for backlight.
>
> Cc: devicet...@vger.kernel.org
> Suggested-by: Sam Ravnborg 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - New patch as suggested by Sam.
> ---
>  .../bindings/leds/backlight/common.yaml   | 42 +++
>  1 file changed, 42 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/common.yaml

I'd expect some refactoring here with existing backlight schemas
including the ones I just added for 5.9.

Ideally, we shouldn't have any property have a type definition more
than once. (We don't have any way to detect that though it wouldn't be
hard to write a program to do so).

> diff --git a/Documentation/devicetree/bindings/leds/backlight/common.yaml 
> b/Documentation/devicetree/bindings/leds/backlight/common.yaml
> new file mode 100644
> index ..8ae7e3818b0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/common.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common backlight properties
> +
> +maintainers:
> +  - Lee Jones 
> +  - Daniel Thompson 
> +  - Jingoo Han 
> +
> +description: |

You don't need '|' if there's no formatting to preserve.

> +  Backlight devices provide backlight for different types of graphical
> +  displays. They are typically but not necessarilt implemented using a white

typo

> +  LED powered by a boost converter.
> +
> +properties:
> +  default-on:
> +description:
> +  The initial state of the backlight can be set to be on with this
> +  property. This is a state applied by the operating system so that the
> +  backlight is always turned on at boot.

Needs a type.

> +
> +  default-brightness:
> +description:
> +  The default brightness that should be applied to the LED by the 
> operating
> +  system on start-up. The brightness should not exceed the brightness the
> +  LED can provide.
> +$ref: /schemas/types.yaml#definitions/uint32
> +minimum: 0

It's an unsigned int, so the min is already 0.

> +
> +  max-brightness:
> +description:
> +  Normally the maximum brightness is determined by the hardware and this
> +  property is not required. This property is used to put a software limit
> +  on the brightness apart from what the driver says, as it could happen
> +  that a LED can be made so bright that it gets damaged or causes damage
> +  due to restrictions in a specific system, such as mounting conditions.
> +$ref: /schemas/types.yaml#definitions/uint32
> +minimum: 0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/14] Add regulator devfreq support to Panfrost

2020-08-10 Thread Rob Herring
On Mon, Aug 10, 2020 at 6:21 AM Daniel Vetter  wrote:
>
> On Fri, Aug 07, 2020 at 06:30:05PM +0200, Clément Péron wrote:
> > On Fri, 7 Aug 2020 at 18:28, Clément Péron  wrote:
> > >
> > > Hi Rob,
> > >
> > > On Fri, 7 Aug 2020 at 18:13, Rob Herring  wrote:
> > > >
> > > > On Fri, Jul 10, 2020 at 3:54 AM Clément Péron  
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > This serie cleans and adds regulator support to Panfrost devfreq.
> > > > > This is mostly based on comment for the freshly introduced lima
> > > > > devfreq.
> > > > >
> > > > > We need to add regulator support because on Allwinner the GPU OPP
> > > > > table defines both frequencies and voltages.
> > > > >
> > > > > First patches [01-07] should not change the actual behavior
> > > > > and introduce a proper panfrost_devfreq struct.
> > > > >
> > > > > Regards,
> > > > > Clément
> > > > >
> > > > > Changes since v4:
> > > > >  - Fix missed a pfdev to >devfreq during rebase
> > > > >
> > > > > Changes since v3:
> > > > >  - Collect Steven Price reviewed-by tags
> > > > >  - Rebase on next/master (next-20200709)
> > > > >
> > > > > Changes since v2:
> > > > >  - Collect Alyssa Rosenzweig reviewed-by tags
> > > > >  - Fix opp_set_regulator before adding opp_table (introduce in v2)
> > > > >  - Call err_fini in case opp_add_table failed
> > > > >
> > > > > Changes since v1:
> > > > >  - Collect Steven Price reviewed-by tags
> > > > >  - Fix spinlock comment
> > > > >  - Drop OPP clock-name patch
> > > > >  - Drop device_property_test patch
> > > > >  - Add rename error labels patch
> > > > >
> > > > > Clément Péron (14):
> > > > >   drm/panfrost: avoid static declaration
> > > > >   drm/panfrost: clean headers in devfreq
> > > > >   drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle
> > > > >   drm/panfrost: introduce panfrost_devfreq struct
> > > > >   drm/panfrost: use spinlock instead of atomic
> > > > >   drm/panfrost: properly handle error in probe
> > > > >   drm/panfrost: rename error labels in device_init
> > > > >   drm/panfrost: move devfreq_init()/fini() in device
> > > > >   drm/panfrost: dynamically alloc regulators
> > > > >   drm/panfrost: add regulators to devfreq
> > > > >   arm64: defconfig: Enable devfreq cooling device
> > > > >   arm64: dts: allwinner: h6: Add cooling map for GPU
> > > > >   [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
> > > > >   [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be 
> > > > > always
> > > >
> > > > Patches 1-10 applied to drm-misc.
> > >
> > > This serie has been superseded by v5.
> > >
> > > Could you apply the v5 instead.
> >
> > Oups forget my email
> >
> > I got an issue with my gmail...
>
> drm-misc is a non-rebasing tree (because it's got lots of
> maintainers/committers). Which means we need fixup patches now.
>
> Not that currently drm-misc-next isn't in linux-next because of the merge
> window, so just rebasing on top of linux-next wont work (at least not
> until -rc1 is out). You can get the tree here meanwhile:
>
> https://cgit.freedesktop.org/drm/drm-misc/

I applied v5 so there's nothing to do. The gmail issue was gmail put
v4 and v5 in the same conversion (under v4) which it likes to do
somewhat randomly and with no regard to actual threading. :(

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] panfrost: Make sure GPU is powered on when reading GPU_LATEST_FLUSH_ID

2020-08-07 Thread Rob Herring
On Thu, Jun 11, 2020 at 2:59 AM Tomeu Vizoso  wrote:
>
> Bifrost devices do support the flush reduction feature, so on first job
> submit we were trying to read the register while still powered off.
>
> If the GPU is powered off, the feature doesn't bring any benefit, so
> don't try to read.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>  drivers/gpu/drm/panfrost/panfrost_gpu.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)

Both patches applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked

2020-08-07 Thread Rob Herring
On Sun, Jun 14, 2020 at 12:36 AM Navid Emamdoost
 wrote:
>
> in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which
> increments the counter even in case of failure, leading to incorrect
> ref count. In case of failure, decrement the ref count before returning.
>
> Signed-off-by: Navid Emamdoost 
> ---
>  drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)

Applied.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/14] Add regulator devfreq support to Panfrost

2020-08-07 Thread Rob Herring
On Fri, Jul 10, 2020 at 3:54 AM Clément Péron  wrote:
>
> Hi,
>
> This serie cleans and adds regulator support to Panfrost devfreq.
> This is mostly based on comment for the freshly introduced lima
> devfreq.
>
> We need to add regulator support because on Allwinner the GPU OPP
> table defines both frequencies and voltages.
>
> First patches [01-07] should not change the actual behavior
> and introduce a proper panfrost_devfreq struct.
>
> Regards,
> Clément
>
> Changes since v4:
>  - Fix missed a pfdev to >devfreq during rebase
>
> Changes since v3:
>  - Collect Steven Price reviewed-by tags
>  - Rebase on next/master (next-20200709)
>
> Changes since v2:
>  - Collect Alyssa Rosenzweig reviewed-by tags
>  - Fix opp_set_regulator before adding opp_table (introduce in v2)
>  - Call err_fini in case opp_add_table failed
>
> Changes since v1:
>  - Collect Steven Price reviewed-by tags
>  - Fix spinlock comment
>  - Drop OPP clock-name patch
>  - Drop device_property_test patch
>  - Add rename error labels patch
>
> Clément Péron (14):
>   drm/panfrost: avoid static declaration
>   drm/panfrost: clean headers in devfreq
>   drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle
>   drm/panfrost: introduce panfrost_devfreq struct
>   drm/panfrost: use spinlock instead of atomic
>   drm/panfrost: properly handle error in probe
>   drm/panfrost: rename error labels in device_init
>   drm/panfrost: move devfreq_init()/fini() in device
>   drm/panfrost: dynamically alloc regulators
>   drm/panfrost: add regulators to devfreq
>   arm64: defconfig: Enable devfreq cooling device
>   arm64: dts: allwinner: h6: Add cooling map for GPU
>   [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
>   [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always

Patches 1-10 applied to drm-misc.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH RFC v6 0/6] Add Unisoc's drm kms module

2020-08-04 Thread Rob Herring
On Tue, Jul 28, 2020 at 4:12 AM Daniel Vetter  wrote:
>
> On Tue, Jul 28, 2020 at 12:08 PM Kevin Tang  wrote:
> >
> > From: Kevin Tang 
>
> Hm still no ack for dt bindings? We need that for merging.

If it's not sent to the DT list so it gets into patchwork that's never
going to happen. Nor are any semi-automated tests of the schema.


> Also what's the maintainer plan here? Imo best would be to put this
> into the drm-misc group maintainer model, with commit rights and all:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> MAINTAINERS patch to do that would be good.
> -Daniel
>
> >
> > ChangeList:
> > v1:
> > 1. only upstream modeset and atomic at first commit.
> > 2. remove some unused code;
> > 3. use alpha and blend_mode properties;
> > 3. add yaml support;
> > 4. remove auto-adaptive panel driver;
> > 5. bugfix
> >
> > v2:
> > 1. add sprd crtc and plane module for KMS, preparing for multi crtc
> > 2. remove gem drivers, use generic CMA handlers
> > 3. remove redundant "module_init", all the sub modules loading by KMS
> >
> > v3:
> > 1. multi crtc design have problem, so rollback to v1
> >
> > v4:
> > 1. update to gcc-linaro-7.5.0
> > 2. update to Linux 5.6-rc3
> > 3. remove pm_runtime support
> > 4. add COMPILE_TEST, remove unused kconfig
> > 5. "drm_dev_put" on drm_unbind
> > 6. fix some naming convention issue
> > 7. remove semaphore lock for crtc flip
> > 8. remove static variables
> >
> > v5:
> > 1. optimize encoder and connector code implementation
> > 2. use "platform_get_irq" and "platform_get_resource"
> > 3. drop useless function return type, drop unless debug log
> > 4. custom properties should be separate, so drop it
> > 5. use DRM_XXX replase pr_xxx
> > 6. drop dsi hal callback ops
> > 7. drop unless callback ops checking
> > 8. add comments for sprd dpu structure
> >
> > v6:
> > 1. Access registers via readl/writel
> > 2. Checking for unsupported KMS properties (format, rotation, blend_mode, 
> > etc) on plane_check ops
> > 3. Remove always true checks for dpu core ops
> >
> > Kevin Tang (6):
> >   dt-bindings: display: add Unisoc's drm master bindings
> >   drm/sprd: add Unisoc's drm kms master
> >   dt-bindings: display: add Unisoc's dpu bindings
> >   drm/sprd: add Unisoc's drm display controller driver
> >   dt-bindings: display: add Unisoc's mipi dsi bindings
> >   drm/sprd: add Unisoc's drm mipi dsi driver
> >
> >  .../devicetree/bindings/display/sprd/dphy.yaml |   75 +
> >  .../devicetree/bindings/display/sprd/dpu.yaml  |   82 ++
> >  .../devicetree/bindings/display/sprd/drm.yaml  |   36 +
> >  .../devicetree/bindings/display/sprd/dsi.yaml  |   98 ++
> >  drivers/gpu/drm/Kconfig|2 +
> >  drivers/gpu/drm/Makefile   |1 +
> >  drivers/gpu/drm/sprd/Kconfig   |   12 +
> >  drivers/gpu/drm/sprd/Makefile  |   13 +
> >  drivers/gpu/drm/sprd/disp_lib.c|   57 +
> >  drivers/gpu/drm/sprd/disp_lib.h|   16 +
> >  drivers/gpu/drm/sprd/dphy/Makefile |7 +
> >  drivers/gpu/drm/sprd/dphy/pll/Makefile |3 +
> >  drivers/gpu/drm/sprd/dphy/pll/megacores_sharkle.c  |  473 +++
> >  drivers/gpu/drm/sprd/dphy/sprd_dphy_api.c  |  201 +++
> >  drivers/gpu/drm/sprd/dphy/sprd_dphy_api.h  |   22 +
> >  drivers/gpu/drm/sprd/dpu/Makefile  |3 +
> >  drivers/gpu/drm/sprd/dpu/dpu_r2p0.c|  503 +++
> >  drivers/gpu/drm/sprd/dsi/Makefile  |8 +
> >  drivers/gpu/drm/sprd/dsi/core/Makefile |4 +
> >  drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.c  |  964 +
> >  drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0.h  | 1477 
> > 
> >  drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.c  |  328 +
> >  drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.h  |   32 +
> >  drivers/gpu/drm/sprd/dsi/sprd_dsi_api.c|  590 
> >  drivers/gpu/drm/sprd/dsi/sprd_dsi_api.h|   26 +
> >  drivers/gpu/drm/sprd/sprd_dphy.c   |  209 +++
> >  drivers/gpu/drm/sprd/sprd_dphy.h   |   50 +
> >  drivers/gpu/drm/sprd/sprd_dpu.c|  668 +
> >  drivers/gpu/drm/sprd/sprd_dpu.h|  190 +++
> >  drivers/gpu/drm/sprd/sprd_drm.c|  227 +++
> >  drivers/gpu/drm/sprd/sprd_drm.h|   18 +
> >  drivers/gpu/drm/sprd/sprd_dsi.c|  571 
> >  drivers/gpu/drm/sprd/sprd_dsi.h|  108 ++
> >  33 files changed, 7074 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/sprd/dphy.yaml
> >  create mode 100644 Documentation/devicetree/bindings/display/sprd/dpu.yaml
> >  create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml
> >  create mode 100644 Documentation/devicetree/bindings/display/sprd/dsi.yaml
> >  

Re: [PATCH v4 1/6] dt-bindings: mediatek: add mt7623 display-nodes

2020-08-04 Thread Rob Herring
On Tue, Aug 4, 2020 at 11:19 AM Frank Wunderlich
 wrote:
>
> CC Rob Herring and devicetree-list

Resend or it is not in my patchwork queue.

But this is simple enough:

Acked-by: Rob Herring 

>
> > Gesendet: Dienstag, 04. August 2020 um 18:55 Uhr
> > Von: "Frank Wunderlich" 
> > An: linux-media...@lists.infradead.org
> > Cc: "Frank Wunderlich" , "Chun-Kuang Hu" 
> > , "Philipp Zabel" , "David 
> > Airlie" , "Daniel Vetter" , "Matthias 
> > Brugger" , dri-devel@lists.freedesktop.org, 
> > linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org
> > Betreff: [PATCH v4 1/6] dt-bindings: mediatek: add mt7623 display-nodes
> >
> > From: Frank Wunderlich 
> >
> > mt7623 uses mt2701/mt8173 for drm, but have own compatibles
> >
> > Signed-off-by: Frank Wunderlich 
> > ---
> >  .../devicetree/bindings/display/mediatek/mediatek,disp.txt| 2 +-
> >  .../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 2 +-
> >  .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 4 ++--
> >  .../devicetree/bindings/display/mediatek/mediatek,hdmi.txt| 4 
> >  4 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > index b91e709db7a4..121220745d46 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > @@ -43,7 +43,7 @@ Required properties (all function blocks):
> >   "mediatek,-dpi"   - DPI controller, see 
> > mediatek,dpi.txt
> >   "mediatek,-disp-mutex"- display mutex
> >   "mediatek,-disp-od"   - overdrive
> > -  the supported chips are mt2701, mt2712 and mt8173.
> > +  the supported chips are mt2701, mt7623, mt2712 and mt8173.
> >  - reg: Physical base address and length of the function block register 
> > space
> >  - interrupts: The interrupt signal from the function block (required, 
> > except for
> >merge and split function blocks).
> > diff --git 
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt 
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> > index 77def4456706..dc1ebd13cc88 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> > @@ -7,7 +7,7 @@ output bus.
> >
> >  Required properties:
> >  - compatible: "mediatek,-dpi"
> > -  the supported chips are mt2701 , mt8173 and mt8183.
> > +  the supported chips are mt2701, mt7623, mt8173 and mt8183.
> >  - reg: Physical base address and length of the controller's registers
> >  - interrupts: The interrupt signal from the function block.
> >  - clocks: device clocks
> > diff --git 
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > index 8e4729de8c85..f06f24d405a5 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > @@ -7,7 +7,7 @@ channel output.
> >
> >  Required properties:
> >  - compatible: "mediatek,-dsi"
> > -  the supported chips are mt2701, mt8173 and mt8183.
> > +- the supported chips are mt2701, mt7623, mt8173 and mt8183.
> >  - reg: Physical base address and length of the controller's registers
> >  - interrupts: The interrupt signal from the function block.
> >  - clocks: device clocks
> > @@ -26,7 +26,7 @@ The MIPI TX configuration module controls the MIPI D-PHY.
> >
> >  Required properties:
> >  - compatible: "mediatek,-mipi-tx"
> > -  the supported chips are mt2701, mt8173 and mt8183.
> > +- the supported chips are mt2701, 7623, mt8173 and mt8183.
> >  - reg: Physical base address and length of the controller's registers
> >  - clocks: PLL reference clock
> >  - clock-output-names: name of the output clock line to the DSI encoder
> > diff --git 
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt 
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> > index 7b124242b0c5..6b1c586403e4 100644
> > --- a/Documentation/devicet

Re: [PATCH 2/3] dt-bindings: Add DT bindings for Chefree CH101OLHLWH-002

2020-07-31 Thread Rob Herring
On Tue, 28 Jul 2020 22:12:41 +0200, Marek Vasut wrote:
> Add DT bindings for Chefree CH101OLHLWH-002 10.1" 1280x800 LCD.
> This panel is connected via LVDS.
> 
> Signed-off-by: Marek Vasut 
> To: dri-devel@lists.freedesktop.org
> Cc: Rob Herring 
> Cc: Sam Ravnborg 
> Cc: devicet...@vger.kernel.org
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3] dt-bindings: Add vendor prefix for Chefree

2020-07-31 Thread Rob Herring
On Tue, 28 Jul 2020 22:12:40 +0200, Marek Vasut wrote:
> The Chefree Technology Corp. is an LCD panel manufacturer.
> 
> Signed-off-by: Marek Vasut 
> To: dri-devel@lists.freedesktop.org
> Cc: Rob Herring 
> Cc: Sam Ravnborg 
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/9] drivers: usb: dwc3-qcom: Add sdm660 compatible

2020-07-31 Thread Rob Herring
On Sun, 26 Jul 2020 13:12:00 +0200, Konrad Dybcio wrote:
> Signed-off-by: Konrad Dybcio 
> ---
>  Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
>  drivers/usb/dwc3/dwc3-qcom.c | 1 +
>  2 files changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/9] phy: qcom-qusb2: Add support for SDM630/660

2020-07-31 Thread Rob Herring
On Sun, 26 Jul 2020 13:11:59 +0200, Konrad Dybcio wrote:
> QUSB on these SoCs actually uses *almost* the same
> configuration that msm8996 does, so we can reuse
> the phy_cfg from there with just a single change
> (se clock scheme).
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
>  drivers/phy/qualcomm/phy-qcom-qusb2.c | 7 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 5/5] dt-bindings: display: imx: add bindings for DCSS

2020-07-31 Thread Rob Herring
On Fri, 31 Jul 2020 11:18:33 +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu 
> 
> Add bindings for iMX8MQ Display Controller Subsystem.
> 
> Signed-off-by: Laurentiu Palcu 
> ---
> Changes in v9:
>  * Include imx8mq-clock.h in the example so we can use clock names
>instead of their values;
> 
>  .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 108 ++
>  1 file changed, 108 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-31 Thread Rob Herring
On Thu, Jul 30, 2020 at 10:44 AM Jim Quinlan  wrote:
>
> On Wed, Jul 29, 2020 at 10:28 AM Rob Herring  wrote:
> >
> > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig  wrote:
> > >
> > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > > > I started using devm_kcalloc() but at least two reviewers convinced me
> > > > to just use kcalloc().  In addition, when I was using devm_kcalloc()
> > > > it was awkward because 'dev' is not available to this function.
> > > >
> > > > It comes down to whether unbind/binding the device N times is actually
> > > > a reasonable usage.  As for my experience I've seen two cases: (1) my
> > > > overnight "bind/unbind the PCIe RC driver" script, and we have a
> > > > customer who does an unbind/bind as a hail mary to bring back life to
> > > > their dead EP device.  If the latter case happens repeatedly, there
> > > > are bigger problems.
> > >
> > > We can't just leak the allocations.  Do you have a pointer to the
> > > arguments against managed resources?  I'm generally not a huge fan
> > > of the managed resources, but for a case like this they actually seem
> > > useful.  If we don't use the managed resources we'll at leat need
> > > to explicitly free the resources when freeing the device.
> >
> > The lifetime for devm_kcalloc may not be what we want here. devm
> > allocs are freed on probe fail or remove, not on freeing the device
> > (there is a just in case free there too though).
>
> What do you suggest doing as an alternative?

I believe I gave it already. Put a kfree in the struct device release
function. But you can't be passing the pointer from device to device
if you go that route. You'd have to either copy the struct or check if
it's the same as the parent's and skip the kfree in that case.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-29 Thread Rob Herring
On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig  wrote:
>
> On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > I started using devm_kcalloc() but at least two reviewers convinced me
> > to just use kcalloc().  In addition, when I was using devm_kcalloc()
> > it was awkward because 'dev' is not available to this function.
> >
> > It comes down to whether unbind/binding the device N times is actually
> > a reasonable usage.  As for my experience I've seen two cases: (1) my
> > overnight "bind/unbind the PCIe RC driver" script, and we have a
> > customer who does an unbind/bind as a hail mary to bring back life to
> > their dead EP device.  If the latter case happens repeatedly, there
> > are bigger problems.
>
> We can't just leak the allocations.  Do you have a pointer to the
> arguments against managed resources?  I'm generally not a huge fan
> of the managed resources, but for a case like this they actually seem
> useful.  If we don't use the managed resources we'll at leat need
> to explicitly free the resources when freeing the device.

The lifetime for devm_kcalloc may not be what we want here. devm
allocs are freed on probe fail or remove, not on freeing the device
(there is a just in case free there too though).

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-28 Thread Rob Herring
On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan  wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
>
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
>
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code.  These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> Signed-off-by: Jim Quinlan 
> ---

[...]

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8eea3f6e29a4..4b718d199efe 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct device_node 
> *np, int index,
>  }
>  EXPORT_SYMBOL(of_io_request_and_map);
>
> +#ifdef CONFIG_HAS_DMA
>  /**
> - * of_dma_get_range - Get DMA range info
> + * of_dma_get_range - Get DMA range info and put it into a map array
>   * @np:device node to get DMA range info
> - * @dma_addr:  pointer to store initial DMA address of DMA range
> - * @paddr: pointer to store initial CPU address of DMA range
> - * @size:  pointer to store size of DMA range
> + * @map:   dma range structure to return
>   *
>   * Look in bottom up direction for the first "dma-ranges" property
> - * and parse it.
> - *  dma-ranges format:
> + * and parse it.  Put the information into a DMA offset map array.
> + *
> + * dma-ranges format:
>   * DMA addr (dma_addr) : naddr cells
>   * CPU addr (phys_addr_t)  : pna cells
>   * size: nsize cells
>   *
> - * It returns -ENODEV if "dma-ranges" property was not found
> - * for this device in DT.
> + * It returns -ENODEV if "dma-ranges" property was not found for this
> + * device in the DT.
>   */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 
> *size)
> +int of_dma_get_range(struct device_node *np, const struct bus_dma_region 
> **map)
>  {
> struct device_node *node = of_node_get(np);
> const __be32 *ranges = NULL;
> -   int len;
> -   int ret = 0;
> bool found_dma_ranges = false;
> struct of_range_parser parser;
> struct of_range range;
> -   u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> +   struct bus_dma_region *r;
> +   int len, num_ranges = 0;
> +   int ret;
>
> while (node) {
> ranges = of_get_property(node, "dma-ranges", );
> @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64 
> *dma_addr, u64 *paddr, u64 *siz
> }
>
> of_dma_range_parser_init(, node);
> +   for_each_of_range(, )
> +   num_ranges++;
> +
> +   of_dma_range_parser_init(, node);
> +
> +   ret = -ENOMEM;
> +   r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> +   if (!r)
> +   goto out;

AFAICT, you have the error cases covered, but you are leaking memory
if the device is removed.

[...]

> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..49242dd6176e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
> /* Initialise vdev subdevice */
> snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> rvdev->dev.parent = >dev;
> -   rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> +   rvdev->dev.dma_range_map = rproc->dev.parent->dma_range_map;

But doing this means you can't just free the dma_range_map. You need
to do a copy here or you'd have to refcount it. Or I suppose you could
check if it the child has a different dma_range_map ptr than the
parent.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

2020-07-27 Thread Rob Herring
On Mon, 27 Jul 2020 13:13:47 +0530, Sumit Semwal wrote:
> The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> 1080x2246 and 6.18 inches size. It is found in some of the Poco F1
> phones.
> 
> Signed-off-by: Sumit Semwal 
> 
> ---
> v2: remove ports node, making port@0 directly under panel@0 node.
> v3: updated to replace port@0 to just 'port'.
> ---
>  .../display/panel/tianma,nt36672a.yaml| 95 +++
>  1 file changed, 95 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [v6] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

2020-07-27 Thread Rob Herring
On Thu, Jul 16, 2020 at 08:15:28PM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
> 
> Signed-off-by: Krishna Manikandan 
> 
> Changes in v2:
> - Changed dpu to DPU (Sam Ravnborg)
> - Fixed indentation issues (Sam Ravnborg)
> - Added empty line between different properties (Sam Ravnborg)
> - Replaced reference txt files with  their corresponding
>   yaml files (Sam Ravnborg)
> - Modified the file to use "|" only when it is
>   necessary (Sam Ravnborg)
> 
> Changes in v3:
> - Corrected the license used (Rob Herring)
> - Added maxItems for properties (Rob Herring)
> - Dropped generic descriptions (Rob Herring)
> - Added ranges property (Rob Herring)
> - Corrected the indendation (Rob Herring)
> - Added additionalProperties (Rob Herring)
> - Split dsi file into two, one for dsi controller
>   and another one for dsi phy per target (Rob Herring)
> - Corrected description for pinctrl-names (Rob Herring)
> - Corrected the examples used in yaml file (Rob Herring)
> - Delete dsi.txt and dpu.txt (Rob Herring)
> 
> Changes in v4:
> - Move schema up by one level (Rob Herring)
>     - Add patternProperties for mdp node (Rob Herring)
> - Corrected description of some properties (Rob Herring)
> 
> Changes in v5:
> - Correct the indentation (Rob Herring)
>     - Remove unnecessary description from properties (Rob Herring)
> - Correct the number of interconnect entries (Rob Herring)
> - Add interconnect names for sc7180 (Rob Herring)
>     - Add description for ports (Rob Herring)
> - Remove common properties (Rob Herring)
> - Add unevalutatedProperties (Rob Herring)
> - Reference existing dsi controller yaml in the common
>       dsi controller file (Rob Herring)
> - Correct the description of clock names to include only the
>   clocks that are required (Rob Herring)
> - Remove properties which are already covered under the common
>   binding (Rob Herring)
> - Add dsi phy supply nodes which are required for sc7180 and
>   sdm845 targets (Rob Herring)
> - Add type ref for syscon-sfpb (Rob Herring)
> 
> Changes in v6:
>     - Fixed errors during dt_binding_check (Rob Herring)
> - Add maxItems for phys and phys-names (Rob Herring)
> - Use unevaluatedProperties wherever required (Rob Herring)
> - Removed interrupt controller from required properties for
>   dsi controller (Rob Herring)
> - Add constraints for dsi-phy reg-names based on the compatible
>   phy version (Rob Herring)
> - Add constraints for dsi-phy supply nodes based on the
>   compatible phy version (Rob Herring)
> ---
>  .../bindings/display/msm/dpu-sc7180.yaml   | 236 
>  .../bindings/display/msm/dpu-sdm845.yaml   | 216 ++
>  .../devicetree/bindings/display/msm/dpu.txt| 141 
>  .../display/msm/dsi-common-controller.yaml | 180 +++
>  .../display/msm/dsi-controller-sc7180.yaml | 120 ++
>  .../display/msm/dsi-controller-sdm845.yaml | 120 ++
>  .../bindings/display/msm/dsi-phy-sc7180.yaml   |  80 +++
>  .../bindings/display/msm/dsi-phy-sdm845.yaml   |  82 +++
>  .../devicetree/bindings/display/msm/dsi-phy.yaml   | 126 +++
>  .../devicetree/bindings/display/msm/dsi.txt| 246 
> -
>  10 files changed, 1160 insertions(+), 387 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-common-controller.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml 
> b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> new file mode 100644
> index 000..

Re: [PATCH 9/9] soc/qcom: Add REVID driver

2020-07-27 Thread Rob Herring
On Sun, Jul 26, 2020 at 01:12:06PM +0200, Konrad Dybcio wrote:
> From: Xiaozhe Shi 
> 
> Add the REVID device driver. The REVID driver will print out the PMIC
> revision at probe time.
> 
> Signed-off-by: Xiaozhe Shi 
> [konradyb...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8,
> convert binding to yaml]
> Signed-off-by: Konrad Dybcio 
> ---
>  .../bindings/soc/qcom/qcom,qpnp-revid.yaml|  38 ++

Bindings should be a separate patch. checkpatch.pl will tell you this.

>  drivers/soc/qcom/Kconfig  |   9 +
>  drivers/soc/qcom/Makefile |   1 +
>  drivers/soc/qcom/qpnp-revid.c | 288 ++
>  include/linux/qpnp/qpnp-revid.h   | 369 ++
>  5 files changed, 705 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
>  create mode 100644 drivers/soc/qcom/qpnp-revid.c
>  create mode 100644 include/linux/qpnp/qpnp-revid.h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 9/9] soc/qcom: Add REVID driver

2020-07-27 Thread Rob Herring
On Sun, 26 Jul 2020 13:12:06 +0200, Konrad Dybcio wrote:
> From: Xiaozhe Shi 
> 
> Add the REVID device driver. The REVID driver will print out the PMIC
> revision at probe time.
> 
> Signed-off-by: Xiaozhe Shi 
> [konradyb...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8,
> convert binding to yaml]
> Signed-off-by: Konrad Dybcio 
> ---
>  .../bindings/soc/qcom/qcom,qpnp-revid.yaml|  38 ++
>  drivers/soc/qcom/Kconfig  |   9 +
>  drivers/soc/qcom/Makefile |   1 +
>  drivers/soc/qcom/qpnp-revid.c | 288 ++
>  include/linux/qpnp/qpnp-revid.h   | 369 ++
>  5 files changed, 705 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
>  create mode 100644 drivers/soc/qcom/qpnp-revid.c
>  create mode 100644 include/linux/qpnp/qpnp-revid.h
> 


My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml:  while 
scanning a block scalar
  in "", line 22, column 18
found a tab character where an indentation space is expected
  in "", line 24, column 1
Documentation/devicetree/bindings/Makefile:20: recipe for target 
'Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.example.dts' failed
make[1]: *** 
[Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml:
 ignoring, error parsing file
warning: no schema found in file: 
./Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml:
 ignoring, error parsing file
warning: no schema found in file: 
./Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
Makefile:1347: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1336467

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/3] dt-bindings: Add DT bindings for Powertip PH800480T013

2020-07-27 Thread Rob Herring
On Sat, 25 Jul 2020 23:13:34 +0200, Marek Vasut wrote:
> Add DT bindings for Powertip PH800480T013 800x480 parallel LCD,
> this one is used in the Raspberry Pi 7" touchscreen display unit.
> 
> Signed-off-by: Marek Vasut 
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt 
> Cc: Rob Herring 
> Cc: Sam Ravnborg 
> Cc: devicet...@vger.kernel.org
> ---
>  .../panel/powertip,ph800480t013-idf02.yaml| 28 +++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml:
 $id: 
'http://devicetree.org/schemas/display/panel/powertip,ph800480t013-idf02#' does 
not match 'http://devicetree.org/schemas/.*\\.yaml#'
Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml:
 $id: relative path/filename doesn't match actual path or filename
expected: 
http://devicetree.org/schemas/display/panel/powertip,ph800480t013-idf02.yaml#
Documentation/devicetree/bindings/Makefile:20: recipe for target 
'Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.example.dts'
 failed
make[1]: *** 
[Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.example.dts]
 Error 1
make[1]: *** Waiting for unfinished jobs
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml:
 ignoring, error in schema: $id
warning: no schema found in file: 
./Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml:
 ignoring, error in schema: $id
warning: no schema found in file: 
./Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml
Makefile:1347: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1336335

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge

2020-07-27 Thread Rob Herring
On Sat, 25 Jul 2020 23:14:56 +0200, Marek Vasut wrote:
> Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
> 
> Signed-off-by: Marek Vasut 
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt 
> Cc: Rob Herring 
> Cc: Sam Ravnborg 
> Cc: devicet...@vger.kernel.org
> ---
>  .../display/bridge/toshiba,tc358762.yaml  | 116 ++
>  1 file changed, 116 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dts:20.13-23:
 Warning (reg_format): /example-0/bridge@0:reg: property has invalid length (4 
bytes) (#address-cells == 1, #size-cells == 1)
Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 Warning (spi_bus_reg): Failed prerequisite 'reg_format'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 example-0: bridge@0:reg:0: [0] is too short
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 bridge@0: '#address-cells', '#size-cells', 'port@0', 'port@1' do not match any 
of the regexes: 'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml:
 bridge@0: 'ports' is a required property


See https://patchwork.ozlabs.org/patch/1336337

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/4] dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02

2020-07-23 Thread Rob Herring
On Mon, 20 Jul 2020 01:10:04 +0800, Icenowy Zheng wrote:
> Feixin K101-IM2BYL02 is a drop-in replacement of K101-IM2BA02 panel
> (which is already supported by panel-feixin-k101-im2ba02 driver) with
> the same pinout. It utilizes an Ilitek ILI9881C controller chip, so its
> compatible string should be added to ilitek,ili9881c file.
> 
> Add the compatible string for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml   | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

2020-07-23 Thread Rob Herring
On Wed, Jul 22, 2020 at 11:28:15AM +0530, Sumit Semwal wrote:
> The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
> and 6.18 inches size. It is found in some of the Poco F1 phones.
> 
> Signed-off-by: Sumit Semwal 
> Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16

You know better...

> ---
> v2: remove ports node, making port@0 directly under panel@0 node.
> ---
>  .../display/panel/tianma,nt36672a.yaml| 104 ++
>  1 file changed, 104 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml 
> b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> new file mode 100644
> index ..cb1799fbbd32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> @@ -0,0 +1,104 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Tianma model NT36672A DSI Panel display driver
> +
> +maintainers:
> +  - Sumit Semwal 
> +
> +description: |
> +  The nt36672a panel from Tianma is a FHD+ LCD display panel with a 
> resolution
> +  of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: tianma,nt36672a
> +
> +  reg:
> +description: DSI virtual channel of the peripheral
> +
> +  reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> +  can be configured using mux, pinctrl, pinctrl-names (active high)
> +
> +  vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> +  Power IC supply
> +
> +  vddpos-supply:
> +description: phandle of the positive boost supply regulator
> +
> +  vddneg-supply:
> +description: phandle of the negative boost supply regulator
> +
> +  pinctrl-names:
> +description: Pinctrl for panel active and suspend
> +
> +  pinctrl-0:
> +description: Active pinctrls
> +
> +  pinctrl-1:
> +description: Suspend pinctrls
> +
> +  port@0:

Just 'port' as there can only be 1 in this case.

You can do just: 'port: true' as panel-common.yaml already has a 
definition.

> +type: object
> +description: DSI input port driven by master DSI
> +properties:
> +  reg:
> +const: 0
> +
> +required:
> +  - reg
> +
> +required:
> +  - compatible
> +  - reg
> +  - vddi0-supply
> +  - vddpos-supply
> +  - vddneg-supply
> +  - reset-gpios
> +  - pinctrl-names
> +  - pinctrl-0
> +  - pinctrl-1
> +  - port@0
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |+
> +#include 
> +dsi0 {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  panel@0 {
> +compatible = "tianma,nt36672a";
> +reg = <0>;
> +vddi0-supply = <_l14a_1p88>;
> +vddpos-supply = <>;
> +vddneg-supply = <>;
> +
> +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> +
> +pinctrl-names = "panel_active", "panel_suspend";
> +pinctrl-0 = <_dsi_active>;
> +pinctrl-1 = <_dsi_suspend>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +  reg = <0>;
> +  tianma_nt36672a_in_0: endpoint {
> +remote-endpoint = <_out>;
> +  };
> +};
> +  };
> +};
> +
> +...
> -- 
> 2.27.0
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [v7, PATCH 4/7] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display

2020-07-23 Thread Rob Herring
On Thu, Jul 23, 2020 at 10:03:15AM +0800, Yongqiang Niu wrote:
> Update device tree binding document for rdma_fifo_size
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 14 
> ++
>  1 file changed, 14 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index b91e709..e6bbe32 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -66,6 +66,11 @@ Required properties (DMA function blocks):
>argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>for details.
>  
> +Optional properties (RDMA function blocks):
> +- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC, 
> add this

s/_/-/

> +  property to the corresponding rdma
> +  the value is the Max value which defined in hardware data sheet.
> +
>  Examples:
>  
>  mmsys: clock-controller@1400 {
> @@ -207,3 +212,12 @@ od@14023000 {
>   power-domains = < MT8173_POWER_DOMAIN_MM>;
>   clocks = < CLK_MM_DISP_OD>;
>  };
> +
> +rdma1: rdma@1400c000 {
> + compatible = "mediatek,mt8183-disp-rdma";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_RDMA1>;
> + mediatek,rdma_fifo_size = <2048>;
> +};
> -- 
> 1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings

2020-07-23 Thread Rob Herring
On Wed, 22 Jul 2020 09:40:38 +0200, Swapnil Jakhade wrote:
> From: Yuti Amonkar 
> 
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
> 
> Signed-off-by: Yuti Amonkar 
> Signed-off-by: Swapnil Jakhade 
> Reviewed-by: Rob Herring 
> Reviewed-by: Laurent Pinchart 
> ---
>  .../bindings/display/bridge/cdns,mhdp.yaml| 127 ++
>  1 file changed, 127 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.example.dt.yaml:
 example-0: dp-bridge@f0fb00:reg:0: [240, 4211081216, 0, 16777216] is too 
long


See https://patchwork.ozlabs.org/patch/1333631

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings

2020-07-23 Thread Rob Herring
On Wed, Jul 22, 2020 at 09:40:38AM +0200, Swapnil Jakhade wrote:
> From: Yuti Amonkar 
> 
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
> 
> Signed-off-by: Yuti Amonkar 
> Signed-off-by: Swapnil Jakhade 
> Reviewed-by: Rob Herring 
> Reviewed-by: Laurent Pinchart 
> ---
>  .../bindings/display/bridge/cdns,mhdp.yaml| 127 ++
>  1 file changed, 127 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml 
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> new file mode 100644
> index ..cdf5760d4ec5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Cadence MHDP bridge
> +
> +maintainers:
> +  - Swapnil Jakhade 
> +  - Yuti Amonkar 
> +
> +properties:
> +  compatible:
> +enum:
> +  - cdns,mhdp8546
> +  - ti,j721e-mhdp8546
> +
> +  reg:
> +minItems: 1
> +maxItems: 2
> +items:
> +  - description:
> +  Register block of mhdptx apb registers up to PHY mapped area 
> (AUX_CONFIG_P).
> +  The AUX and PMA registers are not part of this range, they are 
> instead
> +  included in the associated PHY.
> +  - description:
> +  Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7 
> SoCs.
> +
> +  reg-names:
> +minItems: 1
> +maxItems: 2
> +items:
> +  - const: mhdptx
> +  - const: j721e-intg
> +
> +  clocks:
> +maxItems: 1
> +description:
> +  DP bridge clock, used by the IP to know how to translate a number of
> +  clock cycles into a time (which is used to comply with DP standard 
> timings
> +  and delays).
> +
> +  phys:

maxItems: 1

> +description:
> +  phandle to the DisplayPort PHY.
> +
> +  ports:
> +type: object
> +description:
> +  Ports as described in Documentation/devicetree/bindings/graph.txt.
> +
> +properties:
> +  '#address-cells':
> +const: 1
> +
> +  '#size-cells':
> +const: 0
> +
> +  port@0:
> +type: object
> +description:
> +  Input port representing the DP bridge input.
> +
> +  port@1:
> +type: object
> +description:
> +  Output port representing the DP bridge output.
> +
> +required:
> +  - port@0
> +  - port@1
> +  - '#address-cells'
> +  - '#size-cells'
> +
> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: ti,j721e-mhdp8546
> +then:
> +  properties:
> +reg:
> +  minItems: 2
> +reg-names:
> +  minItems: 2

else:
  properties:
reg:
  maxItems: 1
reg-names:
  maxItems: 1

> +
> +required:
> +  - compatible
> +  - clocks
> +  - reg
> +  - reg-names
> +  - phys
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +mhdp: dp-bridge@f0fb00 {
> +compatible = "cdns,mhdp8546";
> +reg = <0xf0 0xfb00 0x0 0x100>;
> +reg-names = "mhdptx";
> +clocks = <_clock>;
> +phys = <_phy>;
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> + reg = <0>;
> + dp_bridge_input: endpoint {
> +remote-endpoint = <_dpi_output>;
> + };
> +  };
> +
> +  port@1 {
> + reg = <1>;
> + dp_bridge_output: endpoint {
> +remote-endpoint = <_dp_connector_input>;
> + };
> +  };
> +};
> +};
> +...
> -- 
> 2.26.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH for v5.9] dt-bindings: drm/bridge: Replace HTTP links with HTTPS ones

2020-07-21 Thread Rob Herring
On Sun, 19 Jul 2020 19:44:57 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  .../devicetree/bindings/display/bridge/ti,sn65dsi86.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH for v5.9] drm/tilcdc: Replace HTTP links with HTTPS ones

2020-07-21 Thread Rob Herring
On Sun, 19 Jul 2020 19:24:38 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH for v5.9] ARM: dts: mxs: Replace HTTP links with HTTPS ones

2020-07-21 Thread Rob Herring
On Sun, Jul 19, 2020 at 12:10:08PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  arch/arm/boot/dts/imx23-pinfunc.h | 4 ++--
>  arch/arm/boot/dts/imx28-pinfunc.h | 4 ++--
>  arch/arm/boot/dts/imx53-tx53-x13x.dts | 4 ++--
>  arch/arm/boot/dts/mxs-pinfunc.h   | 4 ++--
>  include/video/imx-ipu-v3.h| 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx23-pinfunc.h 
> b/arch/arm/boot/dts/imx23-pinfunc.h
> index 5c0f32ca3a93..f9d7eb6679de 100644
> --- a/arch/arm/boot/dts/imx23-pinfunc.h
> +++ b/arch/arm/boot/dts/imx23-pinfunc.h
> @@ -7,8 +7,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html

Replace the license text with SPDX tags instead.

>   */
>  
>  #ifndef __DT_BINDINGS_MX23_PINCTRL_H__
> diff --git a/arch/arm/boot/dts/imx28-pinfunc.h 
> b/arch/arm/boot/dts/imx28-pinfunc.h
> index e11f69ba0fe4..ffd5412b70ae 100644
> --- a/arch/arm/boot/dts/imx28-pinfunc.h
> +++ b/arch/arm/boot/dts/imx28-pinfunc.h
> @@ -7,8 +7,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html
>   */
>  
>  #ifndef __DT_BINDINGS_MX28_PINCTRL_H__
> diff --git a/arch/arm/boot/dts/imx53-tx53-x13x.dts 
> b/arch/arm/boot/dts/imx53-tx53-x13x.dts
> index 6cdf2082c742..a34d98cf6ed4 100644
> --- a/arch/arm/boot/dts/imx53-tx53-x13x.dts
> +++ b/arch/arm/boot/dts/imx53-tx53-x13x.dts
> @@ -41,8 +41,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm/boot/dts/mxs-pinfunc.h b/arch/arm/boot/dts/mxs-pinfunc.h
> index c6da987b20cb..6766292eee30 100644
> --- a/arch/arm/boot/dts/mxs-pinfunc.h
> +++ b/arch/arm/boot/dts/mxs-pinfunc.h
> @@ -7,8 +7,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html
>   */
>  
>  #ifndef __DT_BINDINGS_MXS_PINCTRL_H__
> diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
> index 06b0b57e996c..749490e3c66e 100644
> --- a/include/video/imx-ipu-v3.h
> +++ b/include/video/imx-ipu-v3.h
> @@ -5,8 +5,8 @@
>   * Public License.  You may obtain a copy of the GNU Lesser General
>   * Public License Version 2.1 or later at the following locations:
>   *
> - * http://www.opensource.org/licenses/lgpl-license.html
> - * http://www.gnu.org/copyleft/lgpl.html
> + * https://www.opensource.org/licenses/lgpl-license.html
> + * https://www.gnu.org/copyleft/lgpl.html
>   */
>  
>  #ifndef __DRM_IPU_H__
> -- 
> 2.27.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 0/2] Fix warnings in display/bridge/nwl-dsi.yaml DT example

2020-07-21 Thread Rob Herring
On Fri, Jul 3, 2020 at 5:47 AM Ondrej Jirman  wrote:
>
> This patchset fixes warnings in the example in display/bridge/nwl-dsi.yaml
> revealed during port of display/panel/rocktech,jh057n00900.yaml to
> yaml.
>
> Please take a look.
>
> thank you and regards,
>   Ondrej Jirman
>
> Ondrej Jirman (2):
>   dt-bindings: display: Fix example in nwl-dsi.yaml
>   dt-binding: display: Allow a single port node on rocktech,jh057n00900

Series applied to drm-misc.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/5] dt-bindings: display: panel-dpi: Add bits-per-color property

2020-07-21 Thread Rob Herring
On Tue, Jul 21, 2020 at 3:23 AM Maxime Ripard  wrote:
>
> On Mon, Jul 20, 2020 at 08:10:26PM -0600, Rob Herring wrote:
> > On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> > > From: Chen-Yu Tsai 
> > >
> > > Some LCD panels do not support 24-bit true color, or 8bits per channel
> > > RGB. Many low end ones only support up to 6 bits per channel natively.
> >
> > This should be implied by the panel's compatible property.
>
> I'm not sure it should, or at least it's not sufficient. Some panels
> while 24 bits capable might only have the higher bits connected to save
> off a couple of pins per color, in which case we should probably
> describe that somehow.

That's the bus/interface format which the 2nd paragraph said this was
not for. If it was, then just bits per component is not enough.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

2020-07-20 Thread Rob Herring
On Thu, Jul 16, 2020 at 09:08:57PM +0530, Sumit Semwal wrote:
> The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
> and 6.18 inches size. It is found in some of the Poco F1 phones.
> 
> Signed-off-by: Sumit Semwal 
> ---
>  .../display/panel/tianma,nt36672a.yaml| 110 ++
>  1 file changed, 110 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml 
> b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> new file mode 100644
> index ..3c583ca926ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Tianma model NT36672A DSI Panel display driver
> +
> +maintainers:
> +  - Sumit Semwal 
> +
> +description: |
> +  The nt36672a panel from Tianma is a FHD+ LCD display panel with a 
> resolution
> +  of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: tianma,nt36672a
> +
> +  reg:
> +description: DSI virtual channel of the peripheral
> +
> +  reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> +  can be configured using mux, pinctrl, pinctrl-names (active high)
> +
> +  vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> +  Power IC supply
> +
> +  vddpos-supply:
> +description: phandle of the positive boost supply regulator
> +
> +  vddneg-supply:
> +description: phandle of the negative boost supply regulator
> +
> +  pinctrl-names:
> +description: Pinctrl for panel active and suspend
> +
> +  pinctrl-0:
> +description: Active pinctrls
> +
> +  pinctrl-1:
> +description: Suspend pinctrls

I think the pinctrl should go in the DSI controller node, not the 
display unless it is settings for 'reset-gpios'.

> +
> +  ports:
> +type: object
> +properties:
> +  port@0:
> +type: object
> +description: DSI input port driven by master DSI
> +properties:
> +  reg:
> +const: 0
> +
> +required:
> +  - reg

For a single port, you can do just 'port' (without ports node).

> +
> +required:
> +  - compatible
> +  - reg
> +  - vddi0-supply
> +  - vddpos-supply
> +  - vddneg-supply
> +  - reset-gpios
> +  - pinctrl-names
> +  - pinctrl-0
> +  - pinctrl-1
> +  - ports
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |+
> +#include 
> +dsi0 {

dsi {

> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  panel@0 {
> +compatible = "tianma,nt36672a";
> +reg = <0>;
> +vddi0-supply = <_l14a_1p88>;
> +vddpos-supply = <>;
> +vddneg-supply = <>;
> +
> +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> +
> +pinctrl-names = "panel_active", "panel_suspend";
> +pinctrl-0 = <_dsi_active>;
> +pinctrl-1 = <_dsi_suspend>;
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> +reg = <0>;
> +tianma_nt36672a_in_0: endpoint {
> +  remote-endpoint = <_out>;
> +};
> +  };
> +};
> +  };
> +};
> +
> +...
> -- 
> 2.27.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/5] dt-bindings: arm: sunxi: Add compatible for MSI Primo73 tablet

2020-07-20 Thread Rob Herring
On Tue, 14 Jul 2020 15:13:03 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai 
> 
> Document board compatible name for MSI Primo73 tablet.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
>  1 file changed, 5 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/5] dt-bindings: display: panel-dpi: Add bits-per-color property

2020-07-20 Thread Rob Herring
On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai 
> 
> Some LCD panels do not support 24-bit true color, or 8bits per channel
> RGB. Many low end ones only support up to 6 bits per channel natively.

This should be implied by the panel's compatible property.

> Add a device tree property to describe the native bit depth of the
> panel. This is separate from the bus width or format of the connection
> to the display output.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../devicetree/bindings/display/panel/panel-dpi.yaml  | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> index 0cd74c8dab42..8eb013fb1969 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> @@ -26,6 +26,9 @@ properties:
>height-mm: true
>label: true
>panel-timing: true
> +  bits-per-color:
> +description:
> +  Shall contain an integer describing the number of bits per color.
>port: true
>power-supply: true
>reset-gpios: true
> @@ -42,6 +45,7 @@ examples:
>  panel {
>  compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
>  label = "osddisplay";
> +bits-per-color = <8>;
>  power-supply = <_supply>;
>  backlight = <>;
>  
> -- 
> 2.27.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 4/4] dt-bindings: display: imx: add bindings for DCSS

2020-07-20 Thread Rob Herring
On Mon, Jul 20, 2020 at 10:55 AM Laurentiu Palcu
 wrote:
>
> Hi Rob,
>
> On Mon, Jul 20, 2020 at 10:49:27AM -0600, Rob Herring wrote:
> > On Fri, 17 Jul 2020 17:41:29 +0300, Laurentiu Palcu wrote:
> > > From: Laurentiu Palcu 
> > >
> > > Add bindings for iMX8MQ Display Controller Subsystem.
> > >
> > > Signed-off-by: Laurentiu Palcu 
> > > ---
> > >  .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
> > >  1 file changed, 104 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> > >
> >
> >
> > Please add Acked-by/Reviewed-by tags when posting new versions. However,
> > there's no need to repost patches *only* to add the tags. The upstream
> > maintainer will do that for acks received on the version they apply.
> >
> > If a tag was not added on purpose, please state why and what changed.
>
> Well, I kind of did exactly that... in the cover letter. I stated
> clearly why this patch needs another look... :/

Put information closest to where it applies which is this patch. I
don't read cover letters typically.

R-by still stands.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 4/4] dt-bindings: display: imx: add bindings for DCSS

2020-07-20 Thread Rob Herring
On Fri, 17 Jul 2020 17:41:29 +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu 
> 
> Add bindings for iMX8MQ Display Controller Subsystem.
> 
> Signed-off-by: Laurentiu Palcu 
> ---
>  .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
>  1 file changed, 104 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] dt-binding: display: Allow a single port node on rocktech, jh057n00900

2020-07-15 Thread Rob Herring
On Fri, 03 Jul 2020 13:47:17 +0200, Ondrej Jirman wrote:
> The display has one port. Allow it in the binding.
> 
> Signed-off-by: Ondrej Jirman 
> ---
>  .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml  | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] dt-bindings: display: Fix example in nwl-dsi.yaml

2020-07-15 Thread Rob Herring
On Fri, 03 Jul 2020 13:47:16 +0200, Ondrej Jirman wrote:
> The example is now validated against rocktech,jh057n00900 schema
> that was ported to yaml, and didn't validate with:
> 
> - '#address-cells', '#size-cells', 'port@0' do not match any of
>   the regexes: 'pinctrl-[0-9]+'
> - 'vcc-supply' is a required property
> - 'iovcc-supply' is a required property
> - 'reset-gpios' is a required property
> 
> Fix it.
> 
> Signed-off-by: Ondrej Jirman 
> ---
>  .../devicetree/bindings/display/bridge/nwl-dsi.yaml  | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCHv1 1/4] dt-bindings: display: panel-dsi-cm: convert to YAML

2020-07-15 Thread Rob Herring
On Tue, 30 Jun 2020 00:33:12 +0200, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  .../bindings/display/panel/panel-dsi-cm.txt   |  29 -
>  .../bindings/display/panel/panel-dsi-cm.yaml  | 100 ++
>  2 files changed, 100 insertions(+), 29 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/3] dt-bindings: add binding for Ilitek ili9488 based display panels

2020-07-15 Thread Rob Herring
On Sat, 13 Jun 2020 19:37:03 +0530, Kamlesh Gurudasani wrote:
> This adds binding for ilitek,ili9488 based display panels
> 
> Signed-off-by: Kamlesh Gurudasani 
> ---
>  .../bindings/display/ilitek,ili9488.yaml   | 71 
> ++
>  1 file changed, 71 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3] dt-bindings: add vendor prefix for EastRising Technology Co., Ltd

2020-07-15 Thread Rob Herring
On Sat, 13 Jun 2020 19:36:46 +0530, Kamlesh Gurudasani wrote:
> Add vendor prefix for display manufacturer company EastRising
> Technology Co.,Ltd
> 
> [1]https://eastrising.en.ec21.com/
> 
> Signed-off-by: Kamlesh Gurudasani 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Freedreno] [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and speed booting

2020-07-15 Thread Rob Herring
On Tue, Jul 14, 2020 at 4:54 PM Bjorn Andersson
 wrote:
>
> On Tue 14 Jul 15:13 PDT 2020, Rob Herring wrote:
>
> > On Tue, Jul 14, 2020 at 10:33 AM Jeffrey Hugo  
> > wrote:
> > >
> > > On Mon, Jul 13, 2020 at 5:50 PM Doug Anderson  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Jul 13, 2020 at 1:25 PM Rob Herring  wrote:
> > > > >
> > > > > On Mon, Jul 13, 2020 at 9:08 AM Doug Anderson  
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Jul 13, 2020 at 7:11 AM Rob Herring  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Fri, Jul 10, 2020 at 5:02 PM Douglas Anderson 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > I found that if I ever had a little mistake in my kernel config,
> > > > > > > > or device tree, or graphics driver that my system would sit in 
> > > > > > > > a loop
> > > > > > > > at bootup trying again and again and again.  An example log was:
> > > > > > >
> > > > > > > Why do we care about optimizing the error case?
> > > > > >
> > > > > > It actually results in a _fully_ infinite loop.  That is: if 
> > > > > > anything
> > > > > > small causes a component of DRM to fail to probe then the whole 
> > > > > > system
> > > > > > doesn't boot because it just loops trying to probe over and over
> > > > > > again.  The messages I put in the commit message are printed over 
> > > > > > and
> > > > > > over and over again.
> > > > >
> > > > > Sounds like a bug as that's not what should happen.
> > > > >
> > > > > If you defer during boot (initcalls), then you'll be on the deferred
> > > > > list until late_initcall and everything is retried. After
> > > > > late_initcall, only devices getting added should trigger probing. But
> > > > > maybe the adding and then removing a device is causing a re-trigger.
> > > >
> > > > Right, I'm nearly certain that the adding and then removing is causing
> > > > a re-trigger.  I believe the loop would happen for any case where we
> > > > have a probe function that:
> > > >
> > > > 1. Adds devices.
> > > > 2. After adding devices it decides that it needs to defer.
> > > > 3. Removes the devices it added.
> > > > 4. Return -EPROBE_DEFER from its probe function.
> > > >
> > > > Specifically from what I know about how -EPROBE_DEFER works I'm not
> > > > sure how it wouldn't cause an infinite loop in that case.
> > > >
> > > > Perhaps the missing part of my explanation, though, is why it never
> > > > gets out of this infinite loop.  In my case I purposely made the
> > > > bridge chip "ti-sn65dsi86.c" return an error (-EINVAL) in its probe
> > > > every time.  Obviously I wasn't going to get a display up like this,
> > > > but I just wanted to not loop forever at bootup.  I tracked down
> > > > exactly why we get an - EPROBE_DEFER over and over in this case.
> > > >
> > > > You can see it in msm_dsi_host_register().  If some components haven't
> > > > shown up when that function runs it will _always_ return
> > > > -EPROBE_DEFER.
> > > >
> > > > In my case, since I caused the bridge to fail to probe, those
> > > > components will _never_ show up.  That means that
> > > > msm_dsi_host_register() will _always_ return -EPROBE_DEFER.
> > > >
> > > > I haven't dug through all the DRM code enough, but it doesn't
> > > > necessarily seem like the wrong behavior.  If the bridge driver or a
> > > > panel was a module then (presumably) they could show up later and so
> > > > it should be OK for it to defer, right?
> > > >
> > > > So with all that, it doesn't really feel like this is a bug so much as
> > > > it's an unsupported use case.  The current deferral logic simply can't
> > > > handle the case we're throwing at it.  You cannot return -EPROBE_DEFER
> > > > if your probe function adds devices each time through the probe
> > > > function.
> > >

Re: [Freedreno] [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and speed booting

2020-07-14 Thread Rob Herring
On Tue, Jul 14, 2020 at 10:33 AM Jeffrey Hugo  wrote:
>
> On Mon, Jul 13, 2020 at 5:50 PM Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Mon, Jul 13, 2020 at 1:25 PM Rob Herring  wrote:
> > >
> > > On Mon, Jul 13, 2020 at 9:08 AM Doug Anderson  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Jul 13, 2020 at 7:11 AM Rob Herring  wrote:
> > > > >
> > > > > On Fri, Jul 10, 2020 at 5:02 PM Douglas Anderson 
> > > > >  wrote:
> > > > > >
> > > > > > I found that if I ever had a little mistake in my kernel config,
> > > > > > or device tree, or graphics driver that my system would sit in a 
> > > > > > loop
> > > > > > at bootup trying again and again and again.  An example log was:
> > > > >
> > > > > Why do we care about optimizing the error case?
> > > >
> > > > It actually results in a _fully_ infinite loop.  That is: if anything
> > > > small causes a component of DRM to fail to probe then the whole system
> > > > doesn't boot because it just loops trying to probe over and over
> > > > again.  The messages I put in the commit message are printed over and
> > > > over and over again.
> > >
> > > Sounds like a bug as that's not what should happen.
> > >
> > > If you defer during boot (initcalls), then you'll be on the deferred
> > > list until late_initcall and everything is retried. After
> > > late_initcall, only devices getting added should trigger probing. But
> > > maybe the adding and then removing a device is causing a re-trigger.
> >
> > Right, I'm nearly certain that the adding and then removing is causing
> > a re-trigger.  I believe the loop would happen for any case where we
> > have a probe function that:
> >
> > 1. Adds devices.
> > 2. After adding devices it decides that it needs to defer.
> > 3. Removes the devices it added.
> > 4. Return -EPROBE_DEFER from its probe function.
> >
> > Specifically from what I know about how -EPROBE_DEFER works I'm not
> > sure how it wouldn't cause an infinite loop in that case.
> >
> > Perhaps the missing part of my explanation, though, is why it never
> > gets out of this infinite loop.  In my case I purposely made the
> > bridge chip "ti-sn65dsi86.c" return an error (-EINVAL) in its probe
> > every time.  Obviously I wasn't going to get a display up like this,
> > but I just wanted to not loop forever at bootup.  I tracked down
> > exactly why we get an - EPROBE_DEFER over and over in this case.
> >
> > You can see it in msm_dsi_host_register().  If some components haven't
> > shown up when that function runs it will _always_ return
> > -EPROBE_DEFER.
> >
> > In my case, since I caused the bridge to fail to probe, those
> > components will _never_ show up.  That means that
> > msm_dsi_host_register() will _always_ return -EPROBE_DEFER.
> >
> > I haven't dug through all the DRM code enough, but it doesn't
> > necessarily seem like the wrong behavior.  If the bridge driver or a
> > panel was a module then (presumably) they could show up later and so
> > it should be OK for it to defer, right?
> >
> > So with all that, it doesn't really feel like this is a bug so much as
> > it's an unsupported use case.  The current deferral logic simply can't
> > handle the case we're throwing at it.  You cannot return -EPROBE_DEFER
> > if your probe function adds devices each time through the probe
> > function.
> >
> > Assuming all the above makes sense, that means we're stuck with:
> >
> > a) This patch series, which makes us not add devices.
> >
> > b) Some other patch series which rearchitects the MSM graphics stack
> > to not return -EPROBE_DEFER in this case.
>
> This isn't a MSM specific issue.  This is an issue with how the DSI
> interface works, and how software is structured in Linux.  I would
> expect that pretty much any DSI host in the kernel would have some
> version of this issue.
>
> The problem is that DSI is not "hot pluggable", so to give the DRM
> stack the info it needs, we need both the DSI controller (aka the MSM
> graphics stack in your case), and the thing it connects to (in your
> case, the TI bridge, normally the actual panel) because the DRM stack
> expects that if init completes, it has certain information
> (resolution, etc), and some of that information is in the DSI
> controller, and some of it is on the DSI device.

Ah yes, DRM's lack of hot-plug and discrete component support... Is
that not improved with some of the bridge rework?

Anyways, given there is a child dependency on the parent, I don't
think we should work-around DRM deficiencies in DT.

BTW, There's also a deferred probe timeout you can use which stops
deferring probe some number of seconds after late_initcall.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2.1 1/8] dt-bindings: media: renesas, fcp: Convert binding to YAML

2020-07-13 Thread Rob Herring
On Wed, 01 Jul 2020 09:05:25 +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car FCP text binding to YAML.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Niklas Söderlund 
> ---
> Changes since v2:
> 
> - Refer to the correct device in the comment above the example
> 
> Changes since v1:
> 
> - Simplify comments on compatible strings
> - Update MAINTAINERS
> ---
>  .../devicetree/bindings/media/renesas,fcp.txt | 34 ---
>  .../bindings/media/renesas,fcp.yaml   | 56 +++
>  MAINTAINERS   |  2 +-
>  3 files changed, 57 insertions(+), 35 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.txt
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,fcp.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   3   4   5   6   7   8   9   10   >