* Re: [PATCH v3 08/10] dmaengine: dw: Add dummy device_caps callback
From: Serge Semin @ 2020-05-28 20:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Andy Shevchenko, Vinod Koul, Viresh Kumar,
Dan Williams, Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann,
Rob Herring, linux-mips, devicetree, dmaengine,
Linux Kernel Mailing List
In-Reply-To: <CAHp75VdrOJF6R9YDpeV7x+9=DZJULM0hsfdr0o_Jmgf69CRKvQ@mail.gmail.com>
On Thu, May 28, 2020 at 11:29:16PM +0300, Andy Shevchenko wrote:
> On Thu, May 28, 2020 at 6:30 PM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> >
> > On Thu, May 28, 2020 at 05:53:03PM +0300, Andy Shevchenko wrote:
> > > On Wed, May 27, 2020 at 01:50:19AM +0300, Serge Semin wrote:
> > > > Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may
> > > > have non-uniform DMA capabilities per device channels, let's add
> > > > the DW DMA specific device_caps callback to expose that specifics up to
> > > > the DMA consumer. It's a dummy function for now. We'll fill it in with
> > > > capabilities overrides in the next commits.
> > >
> > > I think per se it is not worth to have it separated. Squash into the next one.
> >
> > bikeshadding?
>
> Actually no.
>
> > There is no any difference whether I add a dummy callback, then
> > fill it in in a following up patch, or have the callback added together
> > with some content. Let's see what Vinod thinks of it. Until then I'll stick with
> > the current solution.
>
> The rule of thumb that we don't add dead code or code which is useless
> per se. Go ahead and provide it with some usefulness.
Actually yes. I've seen examples, which preparation patches first added
prototypes with empty functionality, that in follow-up patches have been
filled with a required code. I've seen Greg accepted such approach. So it's
absolutely normal and acceptable.
-Sergey
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: clock: renesas: cpg: Convert to json-schema
From: Rob Herring @ 2020-05-28 20:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michael Turquette, linux-renesas-soc, Stephen Boyd, devicetree,
linux-clk, Rob Herring
In-Reply-To: <20200518081644.23683-1-geert+renesas@glider.be>
On Mon, 18 May 2020 10:16:44 +0200, Geert Uytterhoeven wrote:
> Convert the Renesas Clock Pulse Generator (CPG) Device Tree
> binding documentation to json-schema, combining support for:
> - R-Mobile APE6 (R8A73A4) and A1 (R8A7740),
> - R-Car M1 (R8A7778) and H1 (R8A7779),
> - RZ/A1 (R7S72100),
> - SH-Mobile AG5 (SH73A0).
>
> Keep the example for R-Mobile A1, which shows most properties.
> Drop the consumer examples, as they do not belong here.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - Remove unneeded 'allOf' container around '$ref',
>
> To be queued in clk-renesas-for-v5.8.
>
> For a clean dtbs_check, this depends on commit e47cb97f153193d4 ("ARM:
> dts: r8a7740: Add missing extal2 to CPG node") in v5.7-rc6.
>
> As these bindings are very similar, I merged them into a single
> document. SoC-specific differences are mostly limited to the "clocks"
> and "clock-output-names" properties, and "#power-domain-cells" for clock
> domain providers.
>
> JFYI, the diffstat for the individual conversions would look like:
> .../clock/renesas,r8a73a4-cpg-clocks.txt | 33 --------
> .../clock/renesas,r8a73a4-cpg-clocks.yaml | 70 ++++++++++++++++
> .../clock/renesas,r8a7740-cpg-clocks.txt | 41 ----------
> .../clock/renesas,r8a7740-cpg-clocks.yaml | 81 +++++++++++++++++++
> .../clock/renesas,r8a7778-cpg-clocks.txt | 47 -----------
> .../clock/renesas,r8a7778-cpg-clocks.yaml | 64 +++++++++++++++
> .../clock/renesas,r8a7779-cpg-clocks.txt | 49 -----------
> .../clock/renesas,r8a7779-cpg-clocks.yaml | 65 +++++++++++++++
> .../bindings/clock/renesas,rz-cpg-clocks.txt | 53 ------------
> .../bindings/clock/renesas,rz-cpg-clocks.yaml | 66 +++++++++++++++
> .../clock/renesas,sh73a0-cpg-clocks.txt | 35 --------
> .../clock/renesas,sh73a0-cpg-clocks.yaml | 69 ++++++++++++++++
> 12 files changed, 415 insertions(+), 258 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.txt
> create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt
> create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt
> create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt
> create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt
> create mode 100644 Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.txt
> create mode 100644 Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.yaml
> ---
> .../bindings/clock/renesas,cpg-clocks.yaml | 241 ++++++++++++++++++
> .../clock/renesas,r8a73a4-cpg-clocks.txt | 33 ---
> .../clock/renesas,r8a7740-cpg-clocks.txt | 41 ---
> .../clock/renesas,r8a7778-cpg-clocks.txt | 47 ----
> .../clock/renesas,r8a7779-cpg-clocks.txt | 49 ----
> .../bindings/clock/renesas,rz-cpg-clocks.txt | 53 ----
> .../clock/renesas,sh73a0-cpg-clocks.txt | 35 ---
> 7 files changed, 241 insertions(+), 258 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.txt
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt
> delete mode 100644 Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: regulator: Convert anatop regulator to json-schema
From: Rob Herring @ 2020-05-28 20:31 UTC (permalink / raw)
To: Anson Huang
Cc: lgirdwood, broonie, paul.liu, linux-kernel, devicetree, Linux-imx
In-Reply-To: <1589788505-18024-1-git-send-email-Anson.Huang@nxp.com>
On Mon, May 18, 2020 at 03:55:05PM +0800, Anson Huang wrote:
> Convert the anatop regulator binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../bindings/regulator/anatop-regulator.txt | 40 ---------
> .../bindings/regulator/anatop-regulator.yaml | 94 ++++++++++++++++++++++
> 2 files changed, 94 insertions(+), 40 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> create mode 100644 Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
>
> diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> deleted file mode 100644
> index a3106c7..0000000
> --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -Anatop Voltage regulators
> -
> -Required properties:
> -- compatible: Must be "fsl,anatop-regulator"
> -- regulator-name: A string used as a descriptive name for regulator outputs
> -- anatop-reg-offset: Anatop MFD register offset
> -- anatop-vol-bit-shift: Bit shift for the register
> -- anatop-vol-bit-width: Number of bits used in the register
> -- anatop-min-bit-val: Minimum value of this register
> -- anatop-min-voltage: Minimum voltage of this regulator
> -- anatop-max-voltage: Maximum voltage of this regulator
> -
> -Optional properties:
> -- anatop-delay-reg-offset: Anatop MFD step time register offset
> -- anatop-delay-bit-shift: Bit shift for the step time register
> -- anatop-delay-bit-width: Number of bits used in the step time register
> -- vin-supply: The supply for this regulator
> -- anatop-enable-bit: Regulator enable bit offset
> -
> -Any property defined as part of the core regulator
> -binding, defined in regulator.txt, can also be used.
> -
> -Example:
> -
> - regulator-vddpu {
> - compatible = "fsl,anatop-regulator";
> - regulator-name = "vddpu";
> - regulator-min-microvolt = <725000>;
> - regulator-max-microvolt = <1300000>;
> - regulator-always-on;
> - anatop-reg-offset = <0x140>;
> - anatop-vol-bit-shift = <9>;
> - anatop-vol-bit-width = <5>;
> - anatop-delay-reg-offset = <0x170>;
> - anatop-delay-bit-shift = <24>;
> - anatop-delay-bit-width = <2>;
> - anatop-min-bit-val = <1>;
> - anatop-min-voltage = <725000>;
> - anatop-max-voltage = <1300000>;
> - };
> diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
> new file mode 100644
> index 0000000..a8c9dd0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/anatop-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale Anatop Voltage Regulators
> +
> +maintainers:
> + - Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
> +
> +allOf:
> + - $ref: "regulator.yaml#"
> +
> +properties:
> + compatible:
> + const: fsl,anatop-regulator
> +
> + regulator-name:
> + $ref: '/schemas/types.yaml#/definitions/string'
> + description: string used as a descriptive name for regulator outputs
Standard property, right? It already has a definition.
> +
> + anatop-reg-offset:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the anatop MFD register offset.
> +
> + anatop-vol-bit-shift:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the bit shift for the register.
> +
> + anatop-vol-bit-width:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the number of bits used in the register.
> +
> + anatop-min-bit-val:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the minimum value of this register.
> +
> + anatop-min-voltage:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the minimum voltage of this regulator.
> +
> + anatop-max-voltage:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the maximum voltage of this regulator.
> +
> + anatop-delay-reg-offset:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the anatop MFD step time register offset.
> +
> + anatop-delay-bit-shift:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the bit shift for the step time register.
> +
> + anatop-delay-bit-width:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the number of bits used in the step time register.
> +
> + anatop-enable-bit:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing regulator enable bit offset.
> +
> + vin-supply:
> + $ref: '/schemas/types.yaml#/definitions/phandle'
> + description: input supply phandle.
> +
> +required:
> + - compatible
> + - regulator-name
> + - anatop-reg-offset
> + - anatop-vol-bit-shift
> + - anatop-vol-bit-width
> + - anatop-min-bit-val
> + - anatop-min-voltage
> + - anatop-max-voltage
Add here:
unevaluatedProperties: false
> +
> +examples:
> + - |
> + regulator-vddpu {
> + compatible = "fsl,anatop-regulator";
> + regulator-name = "vddpu";
> + regulator-min-microvolt = <725000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-always-on;
> + anatop-reg-offset = <0x140>;
> + anatop-vol-bit-shift = <9>;
> + anatop-vol-bit-width = <5>;
> + anatop-delay-reg-offset = <0x170>;
> + anatop-delay-bit-shift = <24>;
> + anatop-delay-bit-width = <2>;
> + anatop-min-bit-val = <1>;
> + anatop-min-voltage = <725000>;
> + anatop-max-voltage = <1300000>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v3 10/10] dmaengine: dw: Initialize max_sg_nents with nollp flag
From: Andy Shevchenko @ 2020-05-28 20:31 UTC (permalink / raw)
To: Serge Semin
Cc: Andy Shevchenko, Serge Semin, Vinod Koul, Viresh Kumar,
Dan Williams, Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann,
Rob Herring, linux-mips, devicetree, dmaengine,
Linux Kernel Mailing List
In-Reply-To: <20200528155017.ayetroojyvxl74kb@mobilestation>
On Thu, May 28, 2020 at 6:52 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
> On Thu, May 28, 2020 at 05:56:30PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 01:50:21AM +0300, Serge Semin wrote:
...
> > In principal I agree, one nit below.
> > If you are okay with it, feel free to add my Rb tag.
> > > + /*
> > > + * It might be crucial for some devices to have the hardware
> > > + * accelerated multi-block transfers supported, aka LLPs in DW DMAC
> > > + * notation. So if LLPs are supported then max_sg_nents is set to
> > > + * zero which means unlimited number of SG entries can be handled in a
> > > + * single DMA transaction, otherwise it's just one SG entry.
> > > + */
> >
> > > + caps->max_sg_nents = dwc->nollp;
> >
>
> > To be on the safer side I would explicitly do it like
> >
> > if (dwc->nollp)
> > /* your nice comment */
> > = 1;
> > else
> > /* Unlimited */
> > = 0;
> >
> > type or content of nollp theoretically can be changed and this will affect maximum segments.
>
> Agree. Though I don't like formatting you suggested. If I add my nice comment
> between if-statement and assignment the the former will be look detached from
> the if-statement, which seems a bit ugly. So I'd leave the comment above the
> whole if-else statement, especially seeing I've already mentioned there about
> the unlimited number of SG entries there.
>
> /*
> * It might be crucial for some devices to have the hardware
> * accelerated multi-block transfers supported, aka LLPs in DW DMAC
> * notation. So if LLPs are supported then max_sg_nents is set to
> * zero which means unlimited number of SG entries can be handled in a
> * single DMA transaction, otherwise it's just one SG entry.
> */
> if (dwc->nollp)
> caps->max_sg_nents = 1;
> else
> caps->max_sg_nents = 0;
Fine with me, thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 08/10] dmaengine: dw: Add dummy device_caps callback
From: Andy Shevchenko @ 2020-05-28 20:29 UTC (permalink / raw)
To: Serge Semin
Cc: Andy Shevchenko, Serge Semin, Vinod Koul, Viresh Kumar,
Dan Williams, Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann,
Rob Herring, linux-mips, devicetree, dmaengine,
Linux Kernel Mailing List
In-Reply-To: <20200528152740.ggld7wkmaqiq4g6o@mobilestation>
On Thu, May 28, 2020 at 6:30 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> On Thu, May 28, 2020 at 05:53:03PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 01:50:19AM +0300, Serge Semin wrote:
> > > Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may
> > > have non-uniform DMA capabilities per device channels, let's add
> > > the DW DMA specific device_caps callback to expose that specifics up to
> > > the DMA consumer. It's a dummy function for now. We'll fill it in with
> > > capabilities overrides in the next commits.
> >
> > I think per se it is not worth to have it separated. Squash into the next one.
>
> bikeshadding?
Actually no.
> There is no any difference whether I add a dummy callback, then
> fill it in in a following up patch, or have the callback added together
> with some content. Let's see what Vinod thinks of it. Until then I'll stick with
> the current solution.
The rule of thumb that we don't add dead code or code which is useless
per se. Go ahead and provide it with some usefulness.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sm6125 SoC and xiaomi,willow
From: Rob Herring @ 2020-05-28 20:28 UTC (permalink / raw)
To: Eli Riggs
Cc: Rob Herring, devicetree, Andy Gross, linux-arm-msm,
Bjorn Andersson, ~postmarketos/upstreaming, linux-kernel
In-Reply-To: <20200517115410.3374-1-eli@rje.li>
On Sun, 17 May 2020 04:54:06 -0700, Eli Riggs wrote:
> Add compatibles for SM6125 aka SDM665 aka Snapdragon 665, as well
> as xiaomi,willow aka Xiaomi Redmi Note 8T, the international
> edition of the Note 8.
>
> Signed-off-by: Eli Riggs <eli@rje.li>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: thermal: tsens: Add zeroc interrupt support in yaml
From: Rob Herring @ 2020-05-28 20:26 UTC (permalink / raw)
To: Manaf Meethalavalappu Pallikunhi
Cc: linux-pm, Rob Herring, Daniel Lezcano, Andy Gross, linux-kernel,
devicetree, Bjorn Andersson, Zhang Rui, Amit Kucheria,
linux-arm-msm
In-Reply-To: <20200517104627.29501-3-manafm@codeaurora.org>
On Sun, 17 May 2020 16:16:27 +0530, Manaf Meethalavalappu Pallikunhi wrote:
> Add zeroc interrupt support for tsens in yaml.
>
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
> ---
> .../bindings/thermal/qcom-tsens.yaml | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: clock: Add YAML schemas for LPASS clocks on SC7180
From: Rob Herring @ 2020-05-28 20:25 UTC (permalink / raw)
To: Taniya Das
Cc: Stephen Boyd, Michael Turquette , David Brown,
Rajendra Nayak, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
Andy Gross, devicetree
In-Reply-To: <1589707344-8871-3-git-send-email-tdas@codeaurora.org>
On Sun, May 17, 2020 at 02:52:22PM +0530, Taniya Das wrote:
> The LPASS(Low Power Audio Subsystem) clock provider have a bunch of generic
> properties that are needed in a device tree. Also add clock ids for GCC
> LPASS and LPASS Core clock IDs for LPASS client to request for the clocks.
>
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---
> .../bindings/clock/qcom,sc7180-lpasscorecc.yaml | 101 +++++++++++++++++++++
> include/dt-bindings/clock/qcom,gcc-sc7180.h | 1 +
> .../dt-bindings/clock/qcom,lpasscorecc-sc7180.h | 29 ++++++
> 3 files changed, 131 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
> create mode 100644 include/dt-bindings/clock/qcom,lpasscorecc-sc7180.h
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
> new file mode 100644
> index 0000000..c025a0ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/qcom,sc7180-lpasscorecc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm LPASS Core Clock Controller Binding for SC7180
> +
> +maintainers:
> + - Taniya Das <tdas@codeaurora.org>
> +
> +description: |
> + Qualcomm LPASS core clock control module which supports the clocks and
> + power domains on SC7180.
> +
> + See also:
> + - dt-bindings/clock/qcom,lpasscorecc-sc7180.h
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,sc7180-lpasshm
> + - qcom,sc7180-lpasscorecc
> +
> + clocks:
> + items:
> + - description: gcc_lpass_sway clock from GCC
> +
> + clock-names:
> + items:
> + - const: gcc_lpass_sway
> +
> + power-domains:
> + items:
> + - description: LPASS CORE HM GSDCR
For single entry, 'maxItems: 1' is enough.
> +
> + '#clock-cells':
> + const: 1
> +
> + '#power-domain-cells':
> + const: 1
> +
> + reg:
> + minItems: 1
> + maxItems: 2
> + items:
> + - description: lpass audio cc register
> + - description: lpass core cc register
audio then core
> +
> + reg-names:
> + items:
> + - const: lpass_core_cc
> + - const: lpass_audio_cc
core then audio?
2 reg-names required, but 1 reg allowed?
> +
> +if:
> + properties:
> + compatible:
> + contains:
> + const: qcom,sc7180-lpasshm
> +then:
> + properties:
> + reg:
> + items:
> + - description: lpass hm core register
reg-names allowed in this case?
Ideally, this would have just 'maxItems: 1' to just disallow the 2nd
entry above.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - '#clock-cells'
> + - '#power-domain-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,gcc-sc7180.h>
> + #include <dt-bindings/clock/qcom,lpasscorecc-sc7180.h>
> + clock-controller@63000000 {
> + compatible = "qcom,sc7180-lpasshm";
> + reg = <0 0x63000000 0 0x28>;
> + clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>;
> + clock-names = "gcc_lpass_sway";
> + #clock-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> + - |
> + clock-controller@62d00000 {
> + compatible = "qcom,sc7180-lpasscorecc";
> + reg = <0 0x62d00000 0 0x50000>,
> + <0 0x62780000 0 0x30000>;
> + reg-names = "lpass_core_cc", "lpass_audio_cc";
> + clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>;
> + clock-names = "gcc_lpass_sway";
> + power-domains = <&lpass_hm LPASS_CORE_HM_GDSCR>;
> + #clock-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +...
> diff --git a/include/dt-bindings/clock/qcom,gcc-sc7180.h b/include/dt-bindings/clock/qcom,gcc-sc7180.h
> index 1258fd0..439476c 100644
> --- a/include/dt-bindings/clock/qcom,gcc-sc7180.h
> +++ b/include/dt-bindings/clock/qcom,gcc-sc7180.h
> @@ -137,6 +137,7 @@
> #define GCC_MSS_NAV_AXI_CLK 127
> #define GCC_MSS_Q6_MEMNOC_AXI_CLK 128
> #define GCC_MSS_SNOC_AXI_CLK 129
> +#define GCC_LPASS_CFG_NOC_SWAY_CLK 130
>
> /* GCC resets */
> #define GCC_QUSB2PHY_PRIM_BCR 0
> diff --git a/include/dt-bindings/clock/qcom,lpasscorecc-sc7180.h b/include/dt-bindings/clock/qcom,lpasscorecc-sc7180.h
> new file mode 100644
> index 0000000..a55d01d
> --- /dev/null
> +++ b/include/dt-bindings/clock/qcom,lpasscorecc-sc7180.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_QCOM_LPASS_CORE_CC_SC7180_H
> +#define _DT_BINDINGS_CLK_QCOM_LPASS_CORE_CC_SC7180_H
> +
> +/* LPASS_CORE_CC clocks */
> +#define LPASS_LPAAUDIO_DIG_PLL 0
> +#define LPASS_LPAAUDIO_DIG_PLL_OUT_ODD 1
> +#define CORE_CLK_SRC 2
> +#define EXT_MCLK0_CLK_SRC 3
> +#define LPAIF_PRI_CLK_SRC 4
> +#define LPAIF_SEC_CLK_SRC 5
> +#define LPASS_AUDIO_CORE_CORE_CLK 6
> +#define LPASS_AUDIO_CORE_EXT_MCLK0_CLK 7
> +#define LPASS_AUDIO_CORE_LPAIF_PRI_IBIT_CLK 8
> +#define LPASS_AUDIO_CORE_LPAIF_SEC_IBIT_CLK 9
> +#define LPASS_AUDIO_CORE_SYSNOC_MPORT_CORE_CLK 10
> +
> +/* LPASS Core power domains */
> +#define LPASS_CORE_HM_GDSCR 0
> +
> +/* LPASS Audio power domains */
> +#define LPASS_AUDIO_HM_GDSCR 0
> +#define LPASS_PDC_HM_GDSCR 1
> +
> +#endif
> --
> Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
> of the Code Aurora Forum, hosted by the Linux Foundation.
>
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: display: Convert ingenic,lcd.txt to YAML
From: Rob Herring @ 2020-05-28 20:17 UTC (permalink / raw)
To: Paul Cercueil
Cc: Rob Herring, David Airlie, Daniel Vetter, devicetree, od,
linux-kernel, Greg Kroah-Hartman, dri-devel, Rafael J . Wysocki
In-Reply-To: <20200516215057.392609-1-paul@crapouillou.net>
On Sat, 16 May 2020 23:50:46 +0200, Paul Cercueil wrote:
> Convert the ingenic,lcd.txt to a new ingenic,lcd.yaml file.
>
> In the process, the new ingenic,jz4780-lcd compatible string has been
> added.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> This patch comes from a different patchset so it's effectively a V2.
>
> Changes were:
> - lcd_pclk and lcd clocks are in the correct order now,
> - Add 'port' and 'ports' properties, and document the valid ports.
>
> .../bindings/display/ingenic,lcd.txt | 45 -------
> .../bindings/display/ingenic,lcd.yaml | 126 ++++++++++++++++++
> 2 files changed, 126 insertions(+), 45 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.txt
> create mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add binding for current-from-voltage
From: Jonathan Bakker @ 2020-05-28 20:16 UTC (permalink / raw)
To: Rob Herring
Cc: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel,
devicetree, linus.walleij
In-Reply-To: <20200528201306.GA594238@bogus>
Hi Rob,
On 2020-05-28 1:13 p.m., Rob Herring wrote:
> On Fri, May 15, 2020 at 07:26:18PM -0700, Jonathan Bakker wrote:
>> Some devices may require a current adc, but only have a voltage
>> ADC onboard. In order to read the current, they have a resistor
>> connected to the ADC. Add bindings for this possibility.
>>
>> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
>> ---
>> .../iio/adc/linux,current-from-voltage.yaml | 47 +++++++++++++++++++
>> 1 file changed, 47 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml b/Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml
>> new file mode 100644
>> index 000000000000..385d317607c3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml
>> @@ -0,0 +1,47 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/iio/adc/linux,current-from-voltage.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Current ADC from voltage ADC and resistor
>> +
>> +maintainers:
>> + - Jonathan Bakker <xc-racer2@live.ca>
>> +
>> +properties:
>> + compatible:
>> + const: linux,current-from-voltage
>
> How is an ADC with a resistor attached a Linux thing? So you don't need
> 'linux', but then 'current-from-voltage' isn't the best naming. I don't
> have a suggestion ATM.
>
The good/bad news is that I was re-implementing an existing driver under a new name :)
The compatible is current-sense-shunt for this exact same purpose.
Thanks,
Jonathan
>> +
>> + io-channel-names:
>> + const: adc
>> +
>> + io-channels:
>> + maxItems: 1
>> + description: Voltage ADC channel
>> +
>> + linux,resistor-ohms:
>> + description: Strength of resistor connected to voltage ADC
>
> Wouldn't you need this to be micro-ohms? Otherwise, there'd be too much
> voltage drop?
>
> Rob
>
^ permalink raw reply
* Re: [PATCH v4 4/6] dt-bindings: interrupt-controller: Add Loongson PCH PIC
From: Rob Herring @ 2020-05-28 20:15 UTC (permalink / raw)
To: Jiaxun Yang
Cc: linux-kernel, devicetree, Thomas Gleixner, Rob Herring,
Jason Cooper, linux-mips, maz, Huacai Chen
In-Reply-To: <20200516082912.3673033-4-jiaxun.yang@flygoat.com>
On Sat, 16 May 2020 16:29:04 +0800, Jiaxun Yang wrote:
> Add binding for Loongson PCH PIC Controller.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> --
> v2:
> - Fix naming
> - Mark loongson,pic-base-vec as required
> ---
> .../loongson,pch-pic.yaml | 53 +++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: interrupt-controller: Add Loongson HTVEC
From: Rob Herring @ 2020-05-28 20:14 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Thomas Gleixner, linux-kernel, Rob Herring, Huacai Chen,
Jason Cooper, linux-mips, devicetree, maz
In-Reply-To: <20200516082912.3673033-2-jiaxun.yang@flygoat.com>
On Sat, 16 May 2020 16:29:02 +0800, Jiaxun Yang wrote:
> Add binding for Loongson-3 HyperTransport Interrupt Vector Controller.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> --
> v4: Drop ref, '|', add additionalProperties, fix example
> ---
> .../interrupt-controller/loongson,htvec.yaml | 58 +++++++++++++++++++
> 1 file changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add binding for current-from-voltage
From: Rob Herring @ 2020-05-28 20:13 UTC (permalink / raw)
To: Jonathan Bakker
Cc: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel,
devicetree, linus.walleij
In-Reply-To: <BN6PR04MB06600A3AFE160C6E07BF5B2CA3BA0@BN6PR04MB0660.namprd04.prod.outlook.com>
On Fri, May 15, 2020 at 07:26:18PM -0700, Jonathan Bakker wrote:
> Some devices may require a current adc, but only have a voltage
> ADC onboard. In order to read the current, they have a resistor
> connected to the ADC. Add bindings for this possibility.
>
> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
> ---
> .../iio/adc/linux,current-from-voltage.yaml | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml b/Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml
> new file mode 100644
> index 000000000000..385d317607c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/linux,current-from-voltage.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/linux,current-from-voltage.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Current ADC from voltage ADC and resistor
> +
> +maintainers:
> + - Jonathan Bakker <xc-racer2@live.ca>
> +
> +properties:
> + compatible:
> + const: linux,current-from-voltage
How is an ADC with a resistor attached a Linux thing? So you don't need
'linux', but then 'current-from-voltage' isn't the best naming. I don't
have a suggestion ATM.
> +
> + io-channel-names:
> + const: adc
> +
> + io-channels:
> + maxItems: 1
> + description: Voltage ADC channel
> +
> + linux,resistor-ohms:
> + description: Strength of resistor connected to voltage ADC
Wouldn't you need this to be micro-ohms? Otherwise, there'd be too much
voltage drop?
Rob
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: gpio: renesas,rcar-gpio: Add r8a7742 (RZ/G1H) support
From: Rob Herring @ 2020-05-28 20:06 UTC (permalink / raw)
To: Lad Prabhakar
Cc: devicetree, linux-gpio, Rob Herring, Linus Walleij, linux-kernel,
Geert Uytterhoeven, Prabhakar, Bartosz Golaszewski
In-Reply-To: <1589557527-6057-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 15 May 2020 16:45:27 +0100, Lad Prabhakar wrote:
> Renesas RZ/G1H (R8A7742) SoC GPIO blocks are identical to the R-Car Gen2
> family. Add support for its GPIO controllers.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v2->v3:
> 1: Rebased the patch as binding were converted into json format.
> I have restored the Acks' from Geert and Rob
> (https://patchwork.kernel.org/patch/11518759/).
>
> v1->v2:
> * No change
> ---
> Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 14/17] dt-bindings: power: renesas,apmu: Document r8a7742 support
From: Rob Herring @ 2020-05-28 20:05 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Ulf Hansson, linux-watchdog, Prabhakar, linux-kernel, linux-i2c,
Wim Van Sebroeck, netdev, Wolfram Sang, linux-mmc,
Geert Uytterhoeven, David S. Miller, linux-renesas-soc,
Rob Herring, Sergei Shtylyov, Guenter Roeck, Jens Axboe,
devicetree, linux-ide
In-Reply-To: <1589555337-5498-15-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 15 May 2020 16:08:54 +0100, Lad Prabhakar wrote:
> Document APMU and SMP enable method for RZ/G1H (also known as r8a7742)
> SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/power/renesas,apmu.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 11/17] dt-bindings: net: renesas,ether: Document R8A7742 SoC
From: Rob Herring @ 2020-05-28 20:04 UTC (permalink / raw)
To: Lad Prabhakar
Cc: David S. Miller, Jens Axboe, Rob Herring, netdev, linux-watchdog,
Wolfram Sang, Prabhakar, Wim Van Sebroeck, linux-kernel,
linux-renesas-soc, linux-mmc, Ulf Hansson, linux-i2c,
Geert Uytterhoeven, Guenter Roeck, linux-ide, Sergei Shtylyov,
devicetree
In-Reply-To: <1589555337-5498-12-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 15 May 2020 16:08:51 +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/renesas,ether.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 10/17] dt-bindings: net: renesas,ravb: Add support for r8a7742 SoC
From: Rob Herring @ 2020-05-28 20:04 UTC (permalink / raw)
To: Lad Prabhakar
Cc: devicetree, netdev, linux-renesas-soc, linux-mmc, Prabhakar,
linux-watchdog, Guenter Roeck, Ulf Hansson, Jens Axboe,
Sergei Shtylyov, Wim Van Sebroeck, David S. Miller, linux-kernel,
linux-i2c, linux-ide, Rob Herring, Wolfram Sang,
Geert Uytterhoeven
In-Reply-To: <1589555337-5498-11-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 15 May 2020 16:08:50 +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 08/17] dt-bindings: ata: renesas,rcar-sata: Add r8a7742 support
From: Rob Herring @ 2020-05-28 20:04 UTC (permalink / raw)
To: Lad Prabhakar
Cc: linux-renesas-soc, Rob Herring, Guenter Roeck, Wolfram Sang,
David S. Miller, Sergei Shtylyov, linux-kernel, linux-ide,
Ulf Hansson, Geert Uytterhoeven, Prabhakar, netdev, Jens Axboe,
devicetree, linux-watchdog, linux-i2c, Wim Van Sebroeck,
linux-mmc
In-Reply-To: <1589555337-5498-9-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 15 May 2020 16:08:48 +0100, Lad Prabhakar wrote:
> Document SATA support for the RZ/G1H, which is compatible with
> R-Car Gen2 SoC family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 02/17] dt-bindings: i2c: renesas,iic: Document r8a7742 support
From: Rob Herring @ 2020-05-28 20:03 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Rob Herring, Ulf Hansson, Jens Axboe,
Wolfram Sang, Sergei Shtylyov, David S. Miller, linux-mmc,
linux-i2c, linux-ide, Prabhakar, devicetree, Guenter Roeck,
linux-watchdog, netdev, Wim Van Sebroeck, linux-renesas-soc,
linux-kernel
In-Reply-To: <1589555337-5498-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 15 May 2020 16:08:42 +0100, Lad Prabhakar wrote:
> Document IIC controller for RZ/G1H (R8A7742) SoC, which is compatible
> with R-Car Gen2 SoC family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/i2c/renesas,iic.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 01/17] dt-bindings: i2c: renesas,i2c: Document r8a7742 support
From: Rob Herring @ 2020-05-28 20:03 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Ulf Hansson, Guenter Roeck, linux-renesas-soc,
linux-kernel, Jens Axboe, linux-mmc, David S. Miller, netdev,
Wolfram Sang, Wim Van Sebroeck, devicetree, Prabhakar,
Rob Herring, linux-i2c, linux-ide, linux-watchdog,
Sergei Shtylyov
In-Reply-To: <1589555337-5498-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, 15 May 2020 16:08:41 +0100, Lad Prabhakar wrote:
> Document i2c controller for RZ/G1H (R8A7742) SoC, which is compatible
> with R-Car Gen2 SoC family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/i2c/renesas,i2c.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling
From: Rob Herring @ 2020-05-28 19:59 UTC (permalink / raw)
To: Guido Günther
Cc: Laurent Pinchart, David Airlie, Daniel Vetter, Shawn Guo,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <9884c56219e9bdbeec179c27ea2b734dbb5f1289.1589548223.git.agx@sigxcpu.org>
On Fri, May 15, 2020 at 03:12:12PM +0200, Guido Günther wrote:
> No need to encode the SoC specifics in the bridge driver. For the
> imx8mq we can use the mux-input-bridge.
You can't just change bindings like this. You'd still have to support
the "old" way. But IMO, this way is the right way.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 ------
> 1 file changed, 6 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 4/6] drm/bridge/nwl-dsi: Drop mux handling
From: Rob Herring @ 2020-05-28 19:57 UTC (permalink / raw)
To: Guido Günther
Cc: Laurent Pinchart, David Airlie, Daniel Vetter, Shawn Guo,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <951688795f969ebcbf9fb3c38065ccce6f488235.1589548223.git.agx@sigxcpu.org>
On Fri, May 15, 2020 at 03:12:13PM +0200, Guido Günther wrote:
> This will be handled via the mux-input-bridge.
You can't do this. What happens booting a kernel with this change and an
un-modified dtb? You just broke it.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> drivers/gpu/drm/bridge/Kconfig | 1 -
> drivers/gpu/drm/bridge/nwl-dsi.c | 61 --------------------------------
> 2 files changed, 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3886c0f41bdd..11444f841e35 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -78,7 +78,6 @@ config DRM_NWL_MIPI_DSI
> select DRM_PANEL_BRIDGE
> select GENERIC_PHY_MIPI_DPHY
> select MFD_SYSCON
> - select MULTIPLEXER
> select REGMAP_MMIO
> help
> This enables the Northwest Logic MIPI DSI Host controller as
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
> index b14d725bf609..8839f333f39c 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -12,7 +12,6 @@
> #include <linux/math64.h>
> #include <linux/mfd/syscon.h>
> #include <linux/module.h>
> -#include <linux/mux/consumer.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> #include <linux/phy/phy.h>
> @@ -44,9 +43,6 @@ enum transfer_direction {
> DSI_PACKET_RECEIVE,
> };
>
> -#define NWL_DSI_ENDPOINT_LCDIF 0
> -#define NWL_DSI_ENDPOINT_DCSS 1
> -
> struct nwl_dsi_plat_clk_config {
> const char *id;
> struct clk *clk;
> @@ -94,7 +90,6 @@ struct nwl_dsi {
> struct reset_control *rst_esc;
> struct reset_control *rst_dpi;
> struct reset_control *rst_pclk;
> - struct mux_control *mux;
>
> /* DSI clocks */
> struct clk *phy_ref_clk;
> @@ -1018,14 +1013,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
> }
> dsi->tx_esc_clk = clk;
>
> - dsi->mux = devm_mux_control_get(dsi->dev, NULL);
> - if (IS_ERR(dsi->mux)) {
> - ret = PTR_ERR(dsi->mux);
> - if (ret != -EPROBE_DEFER)
> - DRM_DEV_ERROR(dsi->dev, "Failed to get mux: %d\n", ret);
> - return ret;
> - }
> -
> base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(base))
> return PTR_ERR(base);
> @@ -1073,47 +1060,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
> return 0;
> }
>
> -static int nwl_dsi_select_input(struct nwl_dsi *dsi)
> -{
> - struct device_node *remote;
> - u32 use_dcss = 1;
> - int ret;
> -
> - remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
> - NWL_DSI_ENDPOINT_LCDIF);
> - if (remote) {
> - use_dcss = 0;
> - } else {
> - remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
> - NWL_DSI_ENDPOINT_DCSS);
> - if (!remote) {
> - DRM_DEV_ERROR(dsi->dev,
> - "No valid input endpoint found\n");
> - return -EINVAL;
> - }
> - }
> -
> - DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
> - (use_dcss) ? "DCSS" : "LCDIF");
> - ret = mux_control_try_select(dsi->mux, use_dcss);
> - if (ret < 0)
> - DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
> -
> - of_node_put(remote);
> - return ret;
> -}
You could however make these functions generic for any bridge to use.
Define a function that checks for mux-control property and if found sets
up the mux (IIRC, there's already a concept of a default state). That
should be callable from somewhere generic too.
Rob
^ permalink raw reply
* Re: [PATCH v3 09/10] dmaengine: dw: Introduce max burst length hw config
From: Serge Semin @ 2020-05-28 19:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Vinod Koul, Viresh Kumar, Dan Williams,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528154022.3reghhjcd4dnsr3g@mobilestation>
On Thu, May 28, 2020 at 06:40:22PM +0300, Serge Semin wrote:
> On Thu, May 28, 2020 at 05:52:24PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 01:50:20AM +0300, Serge Semin wrote:
> > > IP core of the DW DMA controller may be synthesized with different
> > > max burst length of the transfers per each channel. According to Synopsis
> > > having the fixed maximum burst transactions length may provide some
> > > performance gain. At the same time setting up the source and destination
> > > multi size exceeding the max burst length limitation may cause a serious
> > > problems. In our case the DMA transaction just hangs up. In order to fix
> > > this lets introduce the max burst length platform config of the DW DMA
> > > controller device and don't let the DMA channels configuration code
> > > exceed the burst length hardware limitation.
> > >
> > > Note the maximum burst length parameter can be detected either in runtime
> > > from the DWC parameter registers or from the dedicated DT property.
> > > Depending on the IP core configuration the maximum value can vary from
> > > channel to channel so by overriding the channel slave max_burst capability
> > > we make sure a DMA consumer will get the channel-specific max burst
> > > length.
> >
> > ...
> >
> > > static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
> > > {
> > > + struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
> > >
> >
>
> > Perhaps,
> >
> > /* DesignWare DMA supports burst value from 0 */
> > caps->min_burst = 0;
>
> Regarding min_burst being zero. I don't fully understand what it means.
> It means no burst or burst with minimum length or what?
> In fact DW DMA burst length starts from 1. Remember the burst-length run-time
> parameter we were arguing about? Anyway the driver makes sure that both
> 0 and 1 requested burst length are setup as burst length of 1 in the
> CTLx.SRC_MSIZE, CTLx.DST_MSIZE fields.
>
> I agree with the rest of your comments below.
>
> -Sergey
>
> >
It would be also better to initialize the dw->dma.min_burst field instead
of setting caps->min_burst in the dwc_caps callback, since the min burst length
can't vary from channel to channel and it will be copied to the caps->min_burst
field anyway in the dma_get_slave_caps() method.
-Sergey
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-gw54xx: allow boot firmware to set eth1 MAC
From: Tim Harvey @ 2020-05-28 19:53 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
devicetree, linux-arm-kernel, linux-kernel, Rob Herring,
Tim Harvey
The GW54xx has a PCIe based GbE as the 2nd ethernet device. The
boot firmware will populate the local-mac-address field of the
device aliased to ethernet1 thus adding the PCIe device to
dt allows boot firmware to set its MAC address.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index c40583d..5527f95 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -9,6 +9,7 @@
/ {
/* these are used by bootloader for disabling nodes */
aliases {
+ ethernet1 = ð1;
led0 = &led0;
led1 = &led1;
led2 = &led2;
@@ -398,6 +399,23 @@
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ pcie@0,0,0 {
+ reg = <0x0000 0 0 0 0>;
+
+ pcie@1,0,0 {
+ reg = <0x0000 0 0 0 0>;
+
+ pcie@2,8,0 {
+ reg = <0x4000 0 0 0 0>;
+
+ eth1: pcie@8,0,0 {
+ reg = <0x0000 0 0 0 0>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+ };
};
&pwm1 {
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx6qdl-gw53xx: allow boot firmware to set eth1 MAC
From: Tim Harvey @ 2020-05-28 19:53 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
devicetree, linux-arm-kernel, linux-kernel, Rob Herring,
Tim Harvey
The GW53xx has a PCIe based GbE as the 2nd ethernet device. The
boot firmware will populate the local-mac-address field of the
device aliased to ethernet1 thus adding the PCIe device to
dt allows boot firmware to set its MAC address.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 8942bec..6601d07 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -8,6 +8,7 @@
/ {
/* these are used by bootloader for disabling nodes */
aliases {
+ ethernet1 = ð1;
led0 = &led0;
led1 = &led1;
led2 = &led2;
@@ -341,6 +342,23 @@
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ pcie@0,0,0 {
+ reg = <0x0000 0 0 0 0>;
+
+ pcie@1,0,0 {
+ reg = <0x0000 0 0 0 0>;
+
+ pcie@2,4,0 {
+ reg = <0x2000 0 0 0 0>;
+
+ eth1: pcie@4,0,0 {
+ reg = <0x0000 0 0 0 0>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+ };
};
&pwm2 {
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox