* Re: (subset) [PATCH 1/3] ARM: dts: exynos: drop old thermal properties from Exynos4210
From: Krzysztof Kozlowski @ 2022-01-26 12:20 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Rafael J. Wysocki, linux-kernel, Amit Kucheria, linux-pm,
Zhang Rui, Rob Herring, Bartlomiej Zolnierkiewicz, devicetree,
linux-arm-kernel, linux-samsung-soc
In-Reply-To: <c4a6d5a4-647a-f80c-e487-a5434e744bae@linaro.org>
On Wed, 26 Jan 2022 at 12:57, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
> On 25/01/2022 18:04, Krzysztof Kozlowski wrote:
> > On Sat, 22 Jan 2022 14:25:52 +0100, Krzysztof Kozlowski wrote:
> >> The samsung,tmu_gain and samsung,tmu_reference_voltage properties of
> >> Exynos Thermal Management Unit driver are not used since April 2018.
> >> They were removed with commit fccfe0993b5d ("thermal: exynos: remove
> >> parsing of samsung,tmu_gain property") and commit 61020d189dbc
> >> ("thermal: exynos: remove parsing of samsung, tmu_reference_voltage
> >> property"), so drop them also from Exynos4210 DTS.
> >>
> >> [...]
> >
> > Applied, thanks!
> >
> > [1/3] ARM: dts: exynos: drop old thermal properties from Exynos4210
> > commit: e20bd06fc421fba4099be51d3f56b9b1741b499b
> >
>
> I guess up to me to pick 2 and 3
Yes, please.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: renesas: Add panel overlay for Draak and Ebisu boards
From: Geert Uytterhoeven @ 2022-01-26 12:20 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Kieran Bingham, Geert Uytterhoeven, Magnus Damm,
Chris Paterson
In-Reply-To: <20211229193135.28767-4-laurent.pinchart+renesas@ideasonboard.com>
On Wed, Dec 29, 2021 at 8:31 PM Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> The Draak and Ebisu boards support an optional LVDS panel. One
> compatible panel is the Mitsubishi AA104XD12. Add a corresponding DT
> overlay.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dt-bindings: iommu: renesas,ipmmu-vmsa: Reformat renesas,ipmmu-main description
From: Geert Uytterhoeven @ 2022-01-26 12:24 UTC (permalink / raw)
To: Joerg Roedel, Will Deacon, Rob Herring, Yoshihiro Shimoda
Cc: iommu, devicetree, linux-renesas-soc, Geert Uytterhoeven
Remove trailing whitespace and break overly long lines.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
.../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 507853fcc746eea1..67da53e8d4d10aa0 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -69,9 +69,9 @@ properties:
items:
- items:
- description: phandle to main IPMMU
- - description: the interrupt bit number associated with the particular
- cache IPMMU device. The interrupt bit number needs to match the main
- IPMMU IMSSTR register. Only used by cache IPMMU instances.
+ - description: the interrupt bit number associated with the particular
+ cache IPMMU device. The interrupt bit number needs to match the
+ main IPMMU IMSSTR register. Only used by cache IPMMU instances.
description:
Reference to the main IPMMU phandle plus 1 cell. The cell is
the interrupt bit number associated with the particular cache IPMMU
--
2.25.1
^ permalink raw reply related
* Re: (subset) [PATCH 1/3] ARM: dts: exynos: drop old thermal properties from Exynos4210
From: Daniel Lezcano @ 2022-01-26 12:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafael J. Wysocki, linux-kernel, Amit Kucheria, linux-pm,
Zhang Rui, Rob Herring, Bartlomiej Zolnierkiewicz, devicetree,
linux-arm-kernel, linux-samsung-soc
In-Reply-To: <CA+Eumj6rUZ=e6oOZyRMEEoXn2uh0FpuUQbJaT3rsX3rhXT67pQ@mail.gmail.com>
On 26/01/2022 13:20, Krzysztof Kozlowski wrote:
> On Wed, 26 Jan 2022 at 12:57, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>> On 25/01/2022 18:04, Krzysztof Kozlowski wrote:
>>> On Sat, 22 Jan 2022 14:25:52 +0100, Krzysztof Kozlowski wrote:
>>>> The samsung,tmu_gain and samsung,tmu_reference_voltage properties of
>>>> Exynos Thermal Management Unit driver are not used since April 2018.
>>>> They were removed with commit fccfe0993b5d ("thermal: exynos: remove
>>>> parsing of samsung,tmu_gain property") and commit 61020d189dbc
>>>> ("thermal: exynos: remove parsing of samsung, tmu_reference_voltage
>>>> property"), so drop them also from Exynos4210 DTS.
>>>>
>>>> [...]
>>>
>>> Applied, thanks!
>>>
>>> [1/3] ARM: dts: exynos: drop old thermal properties from Exynos4210
>>> commit: e20bd06fc421fba4099be51d3f56b9b1741b499b
>>>
>>
>> I guess up to me to pick 2 and 3
>
> Yes, please.
Ok, I'll wait for Rob's ack
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [RESEND v4 02/10] arm64: dts: freescale: Add the top level dtsi support for imx8dxl
From: Shawn Guo @ 2022-01-26 12:27 UTC (permalink / raw)
To: Abel Vesa
Cc: Rob Herring, Dong Aisheng, Sascha Hauer, Greg Kroah-Hartman,
Fabio Estevam, Pengutronix Kernel Team, linux-i2c, linux-serial,
NXP Linux Team, Linux Kernel Mailing List, linux-arm-kernel,
devicetree, Jacky Bai
In-Reply-To: <1639680494-23183-3-git-send-email-abel.vesa@nxp.com>
On Thu, Dec 16, 2021 at 08:48:06PM +0200, Abel Vesa wrote:
> From: Jacky Bai <ping.bai@nxp.com>
>
> The i.MX8DXL is a device targeting the automotive and industrial
> market segments. The flexibility of the architecture allows for
> use in a wide variety of general embedded applications. The chip
> is designed to achieve both high performance and low power consumption.
> The chip relies on the power efficient dual (2x) Cortex-A35 cluster.
>
> Add the reserved memory node property for dsp reserved memory,
> the wakeup-irq property for SCU node, the imx ion, the rpmsg and the
Not sure what "ion" is.
> cm4 rproc support.
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8dxl.dtsi | 245 +++++++++++++++++++++
> 1 file changed, 245 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dxl.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl.dtsi
> new file mode 100644
> index 000000000000..f16f88882c39
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8dxl.dtsi
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019-2021 NXP
> + */
> +
> +#include <dt-bindings/clock/imx8-clock.h>
> +#include <dt-bindings/firmware/imx/rsrc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/pads-imx8dxl.h>
> +#include <dt-bindings/thermal/thermal.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + ethernet0 = &fec1;
> + ethernet1 = &eqos;
> + gpio0 = &lsio_gpio0;
> + gpio1 = &lsio_gpio1;
> + gpio2 = &lsio_gpio2;
> + gpio3 = &lsio_gpio3;
> + gpio4 = &lsio_gpio4;
> + gpio5 = &lsio_gpio5;
> + gpio6 = &lsio_gpio6;
> + gpio7 = &lsio_gpio7;
> + i2c2 = &i2c2;
> + i2c3 = &i2c3;
> + mmc0 = &usdhc1;
> + mmc1 = &usdhc2;
> + mu1 = &lsio_mu1;
> + serial0 = &lpuart0;
> + serial1 = &lpuart1;
> + serial2 = &lpuart2;
> + serial3 = &lpuart3;
> + };
> +
> + cpus: cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + /* We have 1 clusters with 2 Cortex-A35 cores */
s/clusters/cluster
> + A35_0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a35";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + next-level-cache = <&A35_L2>;
> + clocks = <&clk IMX_SC_R_A35 IMX_SC_PM_CLK_CPU>;
> + #cooling-cells = <2>;
> + operating-points-v2 = <&a35_opp_table>;
> + };
> +
> + A35_1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a35";
> + reg = <0x0 0x1>;
> + enable-method = "psci";
> + next-level-cache = <&A35_L2>;
> + clocks = <&clk IMX_SC_R_A35 IMX_SC_PM_CLK_CPU>;
> + #cooling-cells = <2>;
> + operating-points-v2 = <&a35_opp_table>;
> + };
> +
> + A35_L2: l2-cache0 {
> + compatible = "cache";
> + };
> + };
> +
> + a35_opp_table: opp-table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-900000000 {
> + opp-hz = /bits/ 64 <900000000>;
> + opp-microvolt = <1000000>;
> + clock-latency-ns = <150000>;
> + };
> +
> + opp-1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt = <1100000>;
> + clock-latency-ns = <150000>;
> + opp-suspend;
> + };
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + dsp_reserved: dsp@92400000 {
> + reg = <0 0x92400000 0 0x2000000>;
> + no-map;
> + };
> + };
> +
> + gic: interrupt-controller@51a00000 {
> + compatible = "arm,gic-v3";
> + reg = <0x0 0x51a00000 0 0x10000>, /* GIC Dist */
> + <0x0 0x51b00000 0 0xc0000>; /* GICR (RD_base + SGI_base) */
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + pmu {
> + compatible = "arm,armv8-pmuv3";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> +
> + scu {
> + compatible = "fsl,imx-scu";
> + mbox-names = "tx0",
> + "rx0",
> + "gip3";
> + mboxes = <&lsio_mu1 0 0
> + &lsio_mu1 1 0
> + &lsio_mu1 3 3>;
> +
> + pd: imx8dxl-pd {
> + compatible = "fsl,imx8dxl-scu-pd", "fsl,scu-pd";
> + #power-domain-cells = <1>;
> + };
> +
> + clk: clock-controller {
> + compatible = "fsl,imx8dxl-clk", "fsl,scu-clk";
> + #clock-cells = <2>;
> + clocks = <&xtal32k &xtal24m>;
> + clock-names = "xtal_32KHz", "xtal_24Mhz";
> + };
> +
> + iomuxc: pinctrl {
> + compatible = "fsl,imx8dxl-iomuxc";
> + };
> +
> + ocotp: imx8qx-ocotp {
> + compatible = "fsl,imx8dxl-scu-ocotp", "fsl,imx8qxp-scu-ocotp";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + fec_mac0: mac@2c4 {
> + reg = <0x2c4 6>;
> + };
> +
> + fec_mac1: mac@2c6 {
> + reg = <0x2c6 6>;
> + };
> + };
> +
> + watchdog {
> + compatible = "fsl,imx-sc-wdt";
> + timeout-sec = <60>;
> + };
> +
> + tsens: thermal-sensor {
> + compatible = "fsl,imx-sc-thermal";
> + #thermal-sensor-cells = <1>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* Physical Secure */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* Physical Non-Secure */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* Virtual */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* Hypervisor */
> + };
> +
> + thermal_zones: thermal-zones {
> + cpu-thermal0 {
> + polling-delay-passive = <250>;
> + polling-delay = <2000>;
> + thermal-sensors = <&tsens IMX_SC_R_SYSTEM>;
> +
> + trips {
> + cpu_alert0: trip0 {
> + temperature = <107000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
Have a newline between nodes.
> + cpu_crit0: trip1 {
> + temperature = <127000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + cooling-maps {
> + map0 {
> + trip = <&cpu_alert0>;
> + cooling-device =
> + <&A35_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A35_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> + };
> +
> + clk_dummy: clock-dummy {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + clock-output-names = "clk_dummy";
> + };
Why do we need this?
Shawn
> +
> + xtal32k: clock-xtal32k {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + clock-output-names = "xtal_32KHz";
> + };
> +
> + xtal24m: clock-xtal24m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24000000>;
> + clock-output-names = "xtal_24MHz";
> + };
> +
> + sc_pwrkey: sc-powerkey {
> + compatible = "fsl,imx8-pwrkey";
> + linux,keycode = <KEY_POWER>;
> + wakeup-source;
> + };
> +
> + /* sorted in register address */
> + #include "imx8-ss-adma.dtsi"
> + #include "imx8-ss-conn.dtsi"
> + #include "imx8-ss-ddr.dtsi"
> + #include "imx8-ss-lsio.dtsi"
> +};
> +
> +#include "imx8dxl-ss-adma.dtsi"
> +#include "imx8dxl-ss-conn.dtsi"
> +#include "imx8dxl-ss-lsio.dtsi"
> +#include "imx8dxl-ss-ddr.dtsi"
> --
> 2.31.1
>
^ permalink raw reply
* [PATCH v2] dt-bindings: irqchip: renesas-irqc: Add R-Car V3U support
From: Geert Uytterhoeven @ 2022-01-26 12:32 UTC (permalink / raw)
To: Thomas Gleixner, Marc Zyngier, Rob Herring
Cc: linux-kernel, devicetree, linux-renesas-soc, Geert Uytterhoeven,
Kieran Bingham
Document support for the Interrupt Controller for External Devices
(INT-EC) in the Renesas R-Car V3U (r8a779a0) SoC.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---
v2:
- Add Tested-by.
---
.../devicetree/bindings/interrupt-controller/renesas,irqc.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
index 79d0358e2f612f24..620f01775e429c3e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
@@ -36,6 +36,7 @@ properties:
- renesas,intc-ex-r8a77980 # R-Car V3H
- renesas,intc-ex-r8a77990 # R-Car E3
- renesas,intc-ex-r8a77995 # R-Car D3
+ - renesas,intc-ex-r8a779a0 # R-Car V3U
- const: renesas,irqc
'#interrupt-cells':
--
2.25.1
^ permalink raw reply related
* Re: [RESEND v4 04/10] arm64: dts: freescale: Add adma subsystem dtsi for imx8dxl
From: Shawn Guo @ 2022-01-26 12:36 UTC (permalink / raw)
To: Abel Vesa
Cc: Rob Herring, Dong Aisheng, Sascha Hauer, Greg Kroah-Hartman,
Fabio Estevam, Pengutronix Kernel Team, linux-i2c, linux-serial,
NXP Linux Team, Linux Kernel Mailing List, linux-arm-kernel,
devicetree, Clark Wang, Jacky Bai
In-Reply-To: <1639680494-23183-5-git-send-email-abel.vesa@nxp.com>
On Thu, Dec 16, 2021 at 08:48:08PM +0200, Abel Vesa wrote:
> Override the I2Cs, LPUARTs, audio_ipg_clk and dma_ipg_clk with
> the i.MX8DXL specific properties.
>
> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> ---
> .../boot/dts/freescale/imx8dxl-ss-adma.dtsi | 53 +++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dxl-ss-adma.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-ss-adma.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl-ss-adma.dtsi
> new file mode 100644
> index 000000000000..eccc31ee8f1b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-ss-adma.dtsi
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019-2021 NXP
> + */
> +
> +&audio_ipg_clk {
> + clock-frequency = <160000000>;
> +};
> +
> +&dma_ipg_clk {
> + clock-frequency = <160000000>;
> +};
> +
> +&i2c0 {
> + compatible = "fsl,imx8dxl-lpi2c", "fsl,imx7ulp-lpi2c";
> + interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&i2c1 {
> + compatible = "fsl,imx8dxl-lpi2c", "fsl,imx7ulp-lpi2c";
> + interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&i2c2 {
> + compatible = "fsl,imx8dxl-lpi2c", "fsl,imx7ulp-lpi2c";
> + interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&i2c3 {
> + compatible = "fsl,imx8dxl-lpi2c", "fsl,imx7ulp-lpi2c";
> + interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&lpuart0 {
> + compatible = "fsl,imx8dxl-lpuart", "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
> + interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&lpuart1 {
> + compatible = "fsl,imx8dxl-lpuart", "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&lpuart2 {
> + compatible = "fsl,imx8dxl-lpuart", "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
> + interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&lpuart3 {
> + compatible = "fsl,imx8dxl-lpuart", "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
> + interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
Drop the newline.
Shawn
^ permalink raw reply
* Re: [RESEND v4 05/10] arm64: dts: freescale: Add the imx8dxl connectivity subsys dtsi
From: Shawn Guo @ 2022-01-26 12:47 UTC (permalink / raw)
To: Abel Vesa
Cc: Rob Herring, Dong Aisheng, Sascha Hauer, Greg Kroah-Hartman,
Fabio Estevam, Pengutronix Kernel Team, linux-i2c, linux-serial,
NXP Linux Team, Linux Kernel Mailing List, linux-arm-kernel,
devicetree, Jacky Bai
In-Reply-To: <1639680494-23183-6-git-send-email-abel.vesa@nxp.com>
On Thu, Dec 16, 2021 at 08:48:09PM +0200, Abel Vesa wrote:
> From: Jacky Bai <ping.bai@nxp.com>
>
> On i.MX8DXL, the Connectivity subsystem includes below peripherals:
> 1x ENET with AVB support, 1x ENET with TSN support, 2x USB OTG,
> 1x eMMC, 2x SD, 1x NAND.
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> ---
> .../boot/dts/freescale/imx8dxl-ss-conn.dtsi | 137 ++++++++++++++++++
> 1 file changed, 137 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi
> new file mode 100644
> index 000000000000..b0059296a03f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019-2021 NXP
> + */
Shouldn't we include imx8-ss-conn.dtsi here? Otherwise, the
/delete-node/ and &conn_subsys reference below looks baseless.
> +
> +/delete-node/ &enet1_lpcg;
> +/delete-node/ &fec2;
> +
> +&conn_subsys {
> + conn_enet0_root_clk: clock-conn-enet0-root {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <250000000>;
> + clock-output-names = "conn_enet0_root_clk";
> + };
> +
> + eqos: ethernet@5b050000 {
> + compatible = "nxp,imx8dxl-dwmac-eqos", "snps,dwmac-5.10a";
> + reg = <0x5b050000 0x10000>;
> + interrupt-parent = <&gic>;
> + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "eth_wake_irq", "macirq";
> + clocks = <&eqos_lpcg IMX_LPCG_CLK_2>,
> + <&eqos_lpcg IMX_LPCG_CLK_4>,
> + <&eqos_lpcg IMX_LPCG_CLK_0>,
> + <&eqos_lpcg IMX_LPCG_CLK_3>,
> + <&eqos_lpcg IMX_LPCG_CLK_1>;
> + clock-names = "stmmaceth", "pclk", "ptp_ref", "tx", "mem";
> + assigned-clocks = <&clk IMX_SC_R_ENET_1 IMX_SC_PM_CLK_PER>;
> + assigned-clock-rates = <125000000>;
> + power-domains = <&pd IMX_SC_R_ENET_1>;
> + clk_csr = <0>;
Is this property documented anywhere?
> + status = "disabled";
> + };
> +
> + usbotg2: usb@5b0e0000 {
> + compatible = "fsl,imx8dxl-usb", "fsl,imx7ulp-usb";
> + reg = <0x5b0e0000 0x200>;
> + interrupt-parent = <&gic>;
> + interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
> + fsl,usbphy = <&usbphy2>;
> + fsl,usbmisc = <&usbmisc2 0>;
> + /*
> + * usbotg1 and usbotg2 share one clcok
s/clcok/clock
> + * scfw disable clock access and keep it always on
> + * in case other core (M4) use one of these.
> + */
> + clocks = <&clk_dummy>;
> + ahb-burst-config = <0x0>;
> + tx-burst-size-dword = <0x10>;
> + rx-burst-size-dword = <0x10>;
> + #stream-id-cells = <1>;
> + power-domains = <&pd IMX_SC_R_USB_1>;
> + status = "disabled";
> + };
> +
> + usbmisc2: usbmisc@5b0e0200 {
> + #index-cells = <1>;
> + compatible = "fsl,imx8dxl-usbmisc", "fsl,imx7ulp-usbmisc";
> + reg = <0x5b0e0200 0x200>;
> + };
> +
> + usbphy2: usbphy@0x5b110000 {
> + compatible = "fsl,imx8dxl-usbphy", "fsl,imx7ulp-usbphy";
> + reg = <0x5b110000 0x1000>;
> + clocks = <&usb2_2_lpcg IMX_LPCG_CLK_7>;
> + status = "disabled";
> + };
> +
> + eqos_lpcg: clock-controller@5b240000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x5b240000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&conn_enet0_root_clk>,
> + <&conn_axi_clk>,
> + <&conn_axi_clk>,
> + <&clk IMX_SC_R_ENET_1 IMX_SC_PM_CLK_PER>,
> + <&conn_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>,
> + <IMX_LPCG_CLK_2>,
> + <IMX_LPCG_CLK_4>,
> + <IMX_LPCG_CLK_5>,
> + <IMX_LPCG_CLK_6>;
> + clock-output-names = "eqos_ptp",
> + "eqos_mem_clk",
> + "eqos_aclk",
> + "eqos_clk",
> + "eqos_csr_clk";
> + power-domains = <&pd IMX_SC_R_ENET_1>;
> + };
> +
> + usb2_2_lpcg: clock-controller@5b280000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x5b280000 0x10000>;
> + #clock-cells = <1>;
> +
Unneeded newline.
Shawn
> + clock-indices = <IMX_LPCG_CLK_7>;
> + clocks = <&conn_ipg_clk>;
> + clock-output-names = "usboh3_2_phy_ipg_clk";
> + };
> +
> +};
> +
> +&enet0_lpcg {
> + clocks = <&conn_enet0_root_clk>,
> + <&conn_enet0_root_clk>,
> + <&conn_axi_clk>,
> + <&clk IMX_SC_R_ENET_0 IMX_SC_C_TXCLK>,
> + <&conn_ipg_clk>,
> + <&conn_ipg_clk>;
> +};
> +
> +&fec1 {
> + compatible = "fsl,imx8dxl-fec", "fsl,imx8qm-fec";
> + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
> + assigned-clocks = <&clk IMX_SC_R_ENET_0 IMX_SC_C_CLKDIV>;
> + assigned-clock-rates = <125000000>;
> +};
> +
> +&usdhc1 {
> + compatible = "fsl,imx8dxl-usdhc", "fsl,imx8qxp-usdhc";
> + interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&usdhc2 {
> + compatible = "fsl,imx8dxl-usdhc", "fsl,imx8qxp-usdhc";
> + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +&usdhc3 {
> + compatible = "fsl,imx8dxl-usdhc", "fsl,imx8qxp-usdhc";
> + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> +};
> --
> 2.31.1
>
^ permalink raw reply
* Re: (EXT) RE: [PATCH v3 3/4] usb: dwc3: imx8mp: Add support for setting SOC specific flags
From: Alexander Stein @ 2022-01-26 12:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Shawn Guo, Sascha Hauer,
Fabio Estevam, Jun Li
Cc: dl-linux-imx, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB4333E8AA7C261C0B3084D8A489599@VI1PR04MB4333.eurprd04.prod.outlook.com>
Am Mittwoch, 19. Januar 2022, 15:14:05 CET schrieb Jun Li:
> > -----Original Message-----
> > From: Alexander Stein <alexander.stein@ew.tq-group.com>
> > Sent: Tuesday, January 18, 2022 9:16 PM
> > To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Rob Herring
> > <robh+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> > <s.hauer@pengutronix.de>; Fabio Estevam <festevam@gmail.com>
> > Cc: Alexander Stein <alexander.stein@ew.tq-group.com>; dl-linux-imx
> > <linux-imx@nxp.com>; linux-usb@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Jun Li
> > <jun.li@nxp.com>
> > Subject: [PATCH v3 3/4] usb: dwc3: imx8mp: Add support for setting SOC
> > specific flags
> >
> > The i.MX8MP glue layer has support for the following flags:
> > * over-current polarity
> > * PWR pad polarity
> > * controlling PPC flag in HCCPARAMS register
> > * permanent port attach for usb2 & usb3 port
> >
> > Allow setting these flags by supporting specific flags in the glue node.
> > In order to get this to work an additional IORESOURCE_MEM and clock is
> > necessary. For backward compatibility this is purely optional.
> >
> > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > ---
> >
> > drivers/usb/dwc3/dwc3-imx8mp.c | 81 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 81 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c
> > b/drivers/usb/dwc3/dwc3-imx8mp.c index 1c8fe657b3a9..3df4313b3740 100644
> > --- a/drivers/usb/dwc3/dwc3-imx8mp.c
> > +++ b/drivers/usb/dwc3/dwc3-imx8mp.c
> > @@ -36,17 +36,66 @@
> >
> > #define USB_WAKEUP_EN_MASK GENMASK(5, 0)
> >
> > +/* USB glue registers */
> > +#define USB_CTRL0 0x00
> > +#define USB_CTRL1 0x04
> > +
> > +#define USB_CTRL0_PORTPWR_EN BIT(12) /* 1 - PPC enabled (default) */
> > +#define USB_CTRL0_USB3_FIXED BIT(22) /* 1 - USB3 permanent attached */
> > +#define USB_CTRL0_USB2_FIXED BIT(23) /* 1 - USB2 permanent attached */
> > +
> > +#define USB_CTRL1_OC_POLARITY BIT(16) /* 0 - HIGH / 1 - LOW */
> > +#define USB_CTRL1_PWR_POLARITY BIT(17) /* 0 - HIGH / 1 - LOW */
> > +
> >
> > struct dwc3_imx8mp {
> >
> > struct device *dev;
> > struct platform_device *dwc3;
> > void __iomem *hsio_blk_base;
> >
> > + void __iomem *glue_base;
> >
> > struct clk *hsio_clk;
> > struct clk *suspend_clk;
> >
> > + struct clk *phy_clk;
> >
> > int irq;
> > bool pm_suspended;
> > bool wakeup_pending;
> >
> > };
> >
> > +static void imx8mp_configure_glue(struct dwc3_imx8mp *dwc3_imx) {
> > + struct device *dev = dwc3_imx->dev;
> > + u32 value;
> > +
> > + if ((!dwc3_imx->glue_base) || (!dwc3_imx->phy_clk))
> > + return;
> > +
> > + value = readl(dwc3_imx->glue_base + USB_CTRL0);
> > +
> > + if (device_property_read_bool(dev, "fsl,permanently-attached"))
> > + value |= (USB_CTRL0_USB2_FIXED | USB_CTRL0_USB3_FIXED);
> > + else
> > + value &= ~(USB_CTRL0_USB2_FIXED | USB_CTRL0_USB3_FIXED);
> > +
> > + if (device_property_read_bool(dev,
> > "fsl,disable-port-power-control"))
> > + value &= ~(USB_CTRL0_PORTPWR_EN);
> > + else
> > + value |= USB_CTRL0_PORTPWR_EN;
> > +
> > + writel(value, dwc3_imx->glue_base + USB_CTRL0);
> > +
> > + value = readl(dwc3_imx->glue_base + USB_CTRL1);
> > + if (device_property_read_bool(dev, "fsl,over-current-active-low"))
> > + value |= USB_CTRL1_OC_POLARITY;
> > + else
> > + value &= ~USB_CTRL1_OC_POLARITY;
> > +
> > + if (device_property_read_bool(dev, "fsl,power-active-low"))
> > + value |= USB_CTRL1_PWR_POLARITY;
> > + else
> > + value &= ~USB_CTRL1_PWR_POLARITY;
> > +
> > + writel(value, dwc3_imx->glue_base + USB_CTRL1); }
> > +
> >
> > static void dwc3_imx8mp_wakeup_enable(struct dwc3_imx8mp *dwc3_imx) {
> >
> > struct dwc3 *dwc3 = platform_get_drvdata(dwc3_imx->dwc3);
> >
> > @@ -100,6 +149,7 @@ static int dwc3_imx8mp_probe(struct platform_device
> > *pdev)
> >
> > struct device *dev = &pdev->dev;
> > struct device_node *dwc3_np, *node = dev->of_node;
> > struct dwc3_imx8mp *dwc3_imx;
> >
> > + struct resource *res;
> >
> > int err, irq;
> >
> > if (!node) {
> >
> > @@ -119,6 +169,15 @@ static int dwc3_imx8mp_probe(struct platform_device
> > *pdev)
> >
> > if (IS_ERR(dwc3_imx->hsio_blk_base))
> >
> > return PTR_ERR(dwc3_imx->hsio_blk_base);
> >
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + if (!res) {
> > + dev_warn(dev, "Base address for glue layer missing.
Continuing
> > without, some features are missing though.");
> > + } else {
> > + dwc3_imx->glue_base = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(dwc3_imx->glue_base))
> > + return PTR_ERR(dwc3_imx->glue_base);
> > + }
> > +
> >
> > dwc3_imx->hsio_clk = devm_clk_get(dev, "hsio");
> > if (IS_ERR(dwc3_imx->hsio_clk)) {
> >
> > err = PTR_ERR(dwc3_imx->hsio_clk);
> >
> > @@ -145,6 +204,24 @@ static int dwc3_imx8mp_probe(struct platform_device
> > *pdev)
> >
> > goto disable_hsio_clk;
> >
> > }
> >
> > + dwc3_imx->phy_clk = devm_clk_get(dev, "phy");
> > + if (PTR_ERR(dwc3_imx->phy_clk) == -ENOENT) {
> > + dev_warn(dev, "PHY clock missing. Continuing without,
some features
> > are missing though.");
Hi,
> What feature needs phy clock turned on here, why phy driver turns on
> this clock is not enough for you?
I have to admit that the clock name 'phy' might be misleading. In this case
the actual clock is IMX8MP_CLK_USB_PHY_ROOT. Apparently this clock (or a
dependent) is necessary to access the USB3_GLUE block in imx8mp. This block
contains the USB3_CTRL0/USB3_CTRL1, we want to access in this case, as well as
the PHY registers, hence the name I guess.
While it is true that phy-fsl-imx8mq-usb enables this clock as well, there is
no guarantee this lock is enabled when we want to access the GLUE registers.
Depending on the probe order it is actually possible the clock is disabled
while dwc3-imx8mp being probed, resulting in a system lockup.
This happens especially if there is only one USB host enabled and the drivers
are built as modules.
Meanwhile I noticed [1] landed last week. So I gave it a try. With that in
place there is no need to use IMX8MP_CLK_USB_PHY_ROOT in this driver anymore.
As it turns out IMX8MP_CLK_USB_ROOT is the required clock (used by imx8mp-blk-
ctrl for USB power domain).
With that, I'll send a new version based on Lucas' patchset.
Thanks for the feedback
Alexander
[1] https://patchwork.kernel.org/project/linux-arm-kernel/cover/
20220119134027.2931945-1-l.stach@pengutronix.de/
^ permalink raw reply
* Re: [RESEND v4 08/10] arm64: dts: imx8dxl: Add i.MX8DXL evk board support
From: Shawn Guo @ 2022-01-26 12:53 UTC (permalink / raw)
To: Abel Vesa
Cc: Rob Herring, Dong Aisheng, Sascha Hauer, Greg Kroah-Hartman,
Fabio Estevam, Pengutronix Kernel Team, linux-i2c, linux-serial,
NXP Linux Team, Linux Kernel Mailing List, linux-arm-kernel,
devicetree, Jacky Bai
In-Reply-To: <1639680494-23183-9-git-send-email-abel.vesa@nxp.com>
On Thu, Dec 16, 2021 at 08:48:12PM +0200, Abel Vesa wrote:
> From: Jacky Bai <ping.bai@nxp.com>
>
> Add i.MX8DXL EVK board support.
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 266 ++++++++++++++++++
> 2 files changed, 267 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 5018b8b1e5f2..f117d3e811ba 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-thor96.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk.dtb
Keep the list sorted.
> dtb-$(CONFIG_ARCH_MXC) += imx8qm-mek.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8qxp-colibri-eval-v3.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> new file mode 100644
> index 000000000000..68dfe722af6d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> @@ -0,0 +1,266 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019-2021 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8dxl.dtsi"
> +
> +/ {
> + model = "Freescale i.MX8DXL EVK";
> + compatible = "fsl,imx8dxl-evk", "fsl,imx8dxl";
> +
> + chosen {
> + stdout-path = &lpuart0;
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x00000000 0x80000000 0 0x40000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /*
> + * 0x8800_0000 ~ 0x8FFF_FFFF is reserved for M4
> + * Shouldn't be used at A core and Linux side.
> + *
> + */
> + m4_reserved: m4@88000000 {
> + no-map;
> + reg = <0 0x88000000 0 0x8000000>;
> + };
> +
> + /* global autoconfigured region for contiguous allocations */
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0 0x14000000>;
> + alloc-ranges = <0 0x98000000 0 0x14000000>;
> + linux,cma-default;
> + };
> + };
> +
> + reg_usdhc2_vmmc: usdhc2-vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "SD1_SPWR";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + gpio = <&lsio_gpio4 30 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + off-on-delay-us = <3480>;
> + };
> +};
> +
> +&lpuart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart0>;
> + status = "okay";
> +};
> +
> +&lpuart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart1>;
> + status = "okay";
> +};
> +
> +&lsio_gpio4 {
> + status = "okay";
> +};
> +
> +&lsio_gpio5 {
> + status = "okay";
> +};
> +
> +&thermal_zones {
> + pmic-thermal0 {
> + polling-delay-passive = <250>;
> + polling-delay = <2000>;
> + thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
Have a newline between property and child node.
> + trips {
> + pmic_alert0: trip0 {
> + temperature = <110000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
Have a newline between nodes.
> + pmic_crit0: trip1 {
> + temperature = <125000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + cooling-maps {
> + map0 {
> + trip = <&pmic_alert0>;
> + cooling-device =
> + <&A35_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A35_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> + bus-width = <8>;
> + no-sd;
> + no-sdio;
> + non-removable;
> + status = "okay";
One level of indent is good enough.
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> + bus-width = <4>;
> + vmmc-supply = <®_usdhc2_vmmc>;
> + cd-gpios = <&lsio_gpio5 1 GPIO_ACTIVE_LOW>;
> + wp-gpios = <&lsio_gpio5 0 GPIO_ACTIVE_HIGH>;
> + max-frequency = <100000000>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hog>;
> +
> + pinctrl_hog: hoggrp {
> + fsl,pins = <
> + IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHB_PAD 0x000514a0
> + IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHK_PAD 0x000014a0
> + IMX8DXL_SPI3_CS0_ADMA_ACM_MCLK_OUT1 0x0600004c
> + IMX8DXL_SNVS_TAMPER_OUT1_LSIO_GPIO2_IO05_IN 0x0600004c
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + IMX8DXL_SPI1_SCK_ADMA_I2C2_SDA 0x06000021
> + IMX8DXL_SPI1_SDO_ADMA_I2C2_SCL 0x06000021
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + IMX8DXL_SPI1_CS0_ADMA_I2C3_SDA 0x06000021
> + IMX8DXL_SPI1_SDI_ADMA_I2C3_SCL 0x06000021
> + >;
> + };
> +
> + pinctrl_lpuart0: lpuart0grp {
> + fsl,pins = <
> + IMX8DXL_UART0_RX_ADMA_UART0_RX 0x06000020
> + IMX8DXL_UART0_TX_ADMA_UART0_TX 0x06000020
> + >;
> + };
> +
> + pinctrl_lpuart1: lpuart1grp {
> + fsl,pins = <
> + IMX8DXL_UART1_TX_ADMA_UART1_TX 0x06000020
> + IMX8DXL_UART1_RX_ADMA_UART1_RX 0x06000020
> + IMX8DXL_UART1_RTS_B_ADMA_UART1_RTS_B 0x06000020
> + IMX8DXL_UART1_CTS_B_ADMA_UART1_CTS_B 0x06000020
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + IMX8DXL_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
> + IMX8DXL_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021
> + IMX8DXL_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021
> + IMX8DXL_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021
> + IMX8DXL_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021
> + IMX8DXL_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021
> + IMX8DXL_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021
> + IMX8DXL_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021
> + IMX8DXL_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021
> + IMX8DXL_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021
> + IMX8DXL_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041
> + >;
> + };
> +
> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
For sake of consistency, we probably should still end the node name with 'grp'.
Shawn
> + fsl,pins = <
> + IMX8DXL_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
> + IMX8DXL_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021
> + IMX8DXL_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021
> + IMX8DXL_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021
> + IMX8DXL_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021
> + IMX8DXL_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021
> + IMX8DXL_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021
> + IMX8DXL_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021
> + IMX8DXL_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021
> + IMX8DXL_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021
> + IMX8DXL_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
> + fsl,pins = <
> + IMX8DXL_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
> + IMX8DXL_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021
> + IMX8DXL_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021
> + IMX8DXL_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021
> + IMX8DXL_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021
> + IMX8DXL_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021
> + IMX8DXL_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021
> + IMX8DXL_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021
> + IMX8DXL_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021
> + IMX8DXL_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021
> + IMX8DXL_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041
> + >;
> + };
> +
> + pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> + fsl,pins = <
> + IMX8DXL_ENET0_RGMII_TX_CTL_LSIO_GPIO4_IO30 0x00000040 /* RESET_B */
> + IMX8DXL_ENET0_RGMII_TXD1_LSIO_GPIO5_IO00 0x00000021 /* WP */
> + IMX8DXL_ENET0_RGMII_TXD2_LSIO_GPIO5_IO01 0x00000021 /* CD */
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + IMX8DXL_ENET0_RGMII_RXC_CONN_USDHC1_CLK 0x06000041
> + IMX8DXL_ENET0_RGMII_RX_CTL_CONN_USDHC1_CMD 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD0_CONN_USDHC1_DATA0 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD1_CONN_USDHC1_DATA1 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD2_CONN_USDHC1_DATA2 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD3_CONN_USDHC1_DATA3 0x00000021
> + IMX8DXL_ENET0_RGMII_TXD0_CONN_USDHC1_VSELECT 0x00000021
> + >;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
> + fsl,pins = <
> + IMX8DXL_ENET0_RGMII_RXC_CONN_USDHC1_CLK 0x06000041
> + IMX8DXL_ENET0_RGMII_RX_CTL_CONN_USDHC1_CMD 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD0_CONN_USDHC1_DATA0 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD1_CONN_USDHC1_DATA1 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD2_CONN_USDHC1_DATA2 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD3_CONN_USDHC1_DATA3 0x00000021
> + IMX8DXL_ENET0_RGMII_TXD0_CONN_USDHC1_VSELECT 0x00000021
> + >;
> + };
> +
> + pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
> + fsl,pins = <
> + IMX8DXL_ENET0_RGMII_RXC_CONN_USDHC1_CLK 0x06000041
> + IMX8DXL_ENET0_RGMII_RX_CTL_CONN_USDHC1_CMD 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD0_CONN_USDHC1_DATA0 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD1_CONN_USDHC1_DATA1 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD2_CONN_USDHC1_DATA2 0x00000021
> + IMX8DXL_ENET0_RGMII_RXD3_CONN_USDHC1_DATA3 0x00000021
> + IMX8DXL_ENET0_RGMII_TXD0_CONN_USDHC1_VSELECT 0x00000021
> + >;
> + };
> +};
> --
> 2.31.1
>
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: tqma8mqml: add PCIe support
From: Shawn Guo @ 2022-01-26 12:56 UTC (permalink / raw)
To: Alexander Stein; +Cc: Rob Herring, Sascha Hauer, devicetree, linux-arm-kernel
In-Reply-To: <20211217102207.722897-1-alexander.stein@ew.tq-group.com>
On Fri, Dec 17, 2021 at 11:22:07AM +0100, Alexander Stein wrote:
> Add PCIe support to TQMa8MxML series.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
It doesn't apply to my imx/dt64 branch. Could you rebase?
Shawn
> ---
> This goes on top of the series recently applied to pci/dwc [1]:
> [PATCH v7 0/8] Add the imx8m pcie phy driver and imx8mm pcie support
> [1] https://patchwork.kernel.org/project/linux-pci/list/?series=589031&state=*
>
> .../dts/freescale/imx8mm-tqma8mqml-mba8mx.dts | 19 +++++++++++++++++++
> .../boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 5 +++++
> arch/arm64/boot/dts/freescale/mba8mx.dtsi | 6 ++++++
> 3 files changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
> index 7844878788f4..286d2df01cfa 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
> @@ -5,6 +5,7 @@
>
> /dts-v1/;
>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> #include "imx8mm-tqma8mqml.dtsi"
> #include "mba8mx.dtsi"
>
> @@ -58,6 +59,24 @@ expander2: gpio@27 {
> };
> };
>
> +&pcie_phy {
> + clocks = <&pcie0_refclk>;
> + status = "okay";
> +};
> +
> +&pcie0 {
> + reset-gpio = <&expander0 14 GPIO_ACTIVE_LOW>;
> + clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
> + <&pcie0_refclk>;
> + clock-names = "pcie", "pcie_aux", "pcie_bus";
> + assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> + <&clk IMX8MM_CLK_PCIE1_CTRL>;
> + assigned-clock-rates = <10000000>, <250000000>;
> + assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> + <&clk IMX8MM_SYS_PLL2_250M>;
> + status = "okay";
> +};
> +
> &sai3 {
> assigned-clocks = <&clk IMX8MM_CLK_SAI3>;
> assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
> index 284e62acc0b4..16ee9b5179e6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
> @@ -227,6 +227,11 @@ eeprom0: eeprom@57 {
> };
> };
>
> +&pcie_phy {
> + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> + fsl,clkreq-unsupported;
> +};
> +
> &usdhc3 {
> pinctrl-names = "default", "state_100mhz", "state_200mhz";
> pinctrl-0 = <&pinctrl_usdhc3>;
> diff --git a/arch/arm64/boot/dts/freescale/mba8mx.dtsi b/arch/arm64/boot/dts/freescale/mba8mx.dtsi
> index e694dacb16af..42e12c190e9e 100644
> --- a/arch/arm64/boot/dts/freescale/mba8mx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/mba8mx.dtsi
> @@ -87,6 +87,12 @@ panel_in_lvds0: endpoint {
> };
> };
>
> + pcie0_refclk: pcie0-refclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
> + };
> +
> reg_12v: regulator-12v {
> compatible = "regulator-fixed";
> regulator-name = "MBA8MX_12V";
> --
> 2.25.1
>
^ permalink raw reply
* [PATCH v4 0/2] Clock based PWM output driver
From: Nikita Travkin @ 2022-01-26 12:58 UTC (permalink / raw)
To: thierry.reding, lee.jones
Cc: u.kleine-koenig, robh+dt, sboyd, krzk, linus.walleij, masneyb,
sean.anderson, linux-pwm, devicetree, linux-kernel,
~postmarketos/upstreaming, Nikita Travkin
This series introduces an "adapter" driver that allows PWM consumers
to control clock outputs with duty-cycle control.
Some platforms (e.g. some Qualcomm chipsets) have "General Purpose"
clocks that can be muxed to GPIO outputs and used as PWM outputs.
Those outputs may be connected to various peripherals such as
leds in display backlight or haptic feedback motor driver.
To avoid re-implementing every single PWM consumer driver with clk
support (like in [1]) and don't put the burden of providing the PWM
sources on the clock drivers (as was proposed in [2]), clk based
pwm controller driver is introduced.
There is an existing driver that provides the opposite function
in drivers/clk/clk-pwm.c with a compatible "pwm-clock" so the new
driver uses the opposite naming scheme: drivers/pwm/pwm-clk.c
and compatible "clk-pwm".
Changes in v2:
- Fix filename in the DT schema.
- Address Uwe's review comments.
Changes in v3:
- Fix node pattern in the core pwm schema.
- Address Uwe's review comments.
Changes in v4:
- Drop the (incorrect) pwm schema change.
- Use generic node name in the dt bindings example.
[1] https://lore.kernel.org/lkml/20191205002503.13088-1-masneyb@onstation.org/
[2] https://lore.kernel.org/lkml/CACRpkdZxu1LfK11OHEx5L_4kyjMZ7qERpvDzFj5u3Pk2kD1qRA@mail.gmail.com/
Nikita Travkin (2):
dt-bindings: pwm: Document clk based PWM controller
pwm: Add clock based PWM output driver
.../devicetree/bindings/pwm/clk-pwm.yaml | 45 ++++++
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-clk.c | 139 ++++++++++++++++++
4 files changed, 195 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/clk-pwm.yaml
create mode 100644 drivers/pwm/pwm-clk.c
--
2.34.1
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: pwm: Document clk based PWM controller
From: Nikita Travkin @ 2022-01-26 12:58 UTC (permalink / raw)
To: thierry.reding, lee.jones
Cc: u.kleine-koenig, robh+dt, sboyd, krzk, linus.walleij, masneyb,
sean.anderson, linux-pwm, devicetree, linux-kernel,
~postmarketos/upstreaming, Nikita Travkin
In-Reply-To: <20220126125849.75572-1-nikita@trvn.ru>
Add YAML devicetree binding for clk based PWM controller
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
--
Changes in v2:
- fix the file name.
Changes in v4:
- Use generic node name in the dt bindings example.
---
.../devicetree/bindings/pwm/clk-pwm.yaml | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/clk-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
new file mode 100644
index 000000000000..d3416ba549b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/clk-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock based PWM controller
+
+maintainers:
+ - Nikita Travkin <nikita@trvn.ru>
+
+description: |
+ Some systems have clocks that can be exposed to external devices.
+ (e.g. by muxing them to GPIO pins)
+ It's often possible to control duty-cycle of such clocks which makes them
+ suitable for generating PWM signal.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: clk-pwm
+
+ clocks:
+ description: Clock used to generate the signal.
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+unevaluatedProperties: false
+
+required:
+ - clocks
+
+examples:
+ - |
+ pwm {
+ compatible = "clk-pwm";
+ #pwm-cells = <2>;
+ clocks = <&gcc 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_clk_flash_default>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/2] pwm: Add clock based PWM output driver
From: Nikita Travkin @ 2022-01-26 12:58 UTC (permalink / raw)
To: thierry.reding, lee.jones
Cc: u.kleine-koenig, robh+dt, sboyd, krzk, linus.walleij, masneyb,
sean.anderson, linux-pwm, devicetree, linux-kernel,
~postmarketos/upstreaming, Nikita Travkin
In-Reply-To: <20220126125849.75572-1-nikita@trvn.ru>
Some systems have clocks exposed to external devices. If the clock
controller supports duty-cycle configuration, such clocks can be used as
pwm outputs. In fact PWM and CLK subsystems are interfaced with in a
similar way and an "opposite" driver already exists (clk-pwm). Add a
driver that would enable pwm devices to be used via clk subsystem.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
--
Changes in v2:
- Address Uwe's review comments:
- Round set clk rate up
- Add a description with limitations of the driver
- Disable and unprepare clock before removing pwmchip
Changes in v3:
- Use 64bit version of div round up
- Address Uwe's review comments:
- Reword the limitations to avoid incorrect claims
- Move the clk_enabled flag assignment
- Drop unnecessary statements
---
drivers/pwm/Kconfig | 10 +++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-clk.c | 139 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 150 insertions(+)
create mode 100644 drivers/pwm/pwm-clk.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 21e3b05a5153..daa2491a4054 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -140,6 +140,16 @@ config PWM_BRCMSTB
To compile this driver as a module, choose M Here: the module
will be called pwm-brcmstb.c.
+config PWM_CLK
+ tristate "Clock based PWM support"
+ depends on HAVE_CLK || COMPILE_TEST
+ help
+ Generic PWM framework driver for outputs that can be
+ muxed to clocks.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-clk.
+
config PWM_CLPS711X
tristate "CLPS711X PWM support"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 708840b7fba8..4a860103c470 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
obj-$(CONFIG_PWM_BERLIN) += pwm-berlin.o
obj-$(CONFIG_PWM_BRCMSTB) += pwm-brcmstb.o
+obj-$(CONFIG_PWM_CLK) += pwm-clk.o
obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
obj-$(CONFIG_PWM_CRC) += pwm-crc.o
obj-$(CONFIG_PWM_CROS_EC) += pwm-cros-ec.o
diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
new file mode 100644
index 000000000000..b3bfa12a0e73
--- /dev/null
+++ b/drivers/pwm/pwm-clk.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Clock based PWM controller
+ *
+ * Copyright (c) 2021 Nikita Travkin <nikita@trvn.ru>
+ *
+ * This is an "adapter" driver that allows PWM consumers to use
+ * system clocks with duty cycle control as PWM outputs.
+ *
+ * Limitations:
+ * - Glitches are possible when new pwm state is applied.
+ * - Due to the fact that exact behavior depends on the underlying
+ * clock driver, various limitations are possible.
+ * - Period depends on the clock and, in general, not guaranteed.
+ * - Underlying clock may not be able to give 0% or 100% duty cycle
+ * (constant off or on), exact behavior will depend on the clock.
+ * - When the PWM is disabled, the clock will be disabled as well,
+ * line state will depend on the clock.
+ */
+
+#include <linux/kernel.h>
+#include <linux/math64.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/pwm.h>
+
+struct pwm_clk_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ bool clk_enabled;
+};
+
+#define to_pwm_clk_chip(_chip) container_of(_chip, struct pwm_clk_chip, chip)
+
+static int pwm_clk_apply(struct pwm_chip *pwm_chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct pwm_clk_chip *chip = to_pwm_clk_chip(pwm_chip);
+ int ret;
+ u32 rate;
+ u64 period = state->period;
+ u64 duty_cycle = state->duty_cycle;
+
+ if (!state->enabled) {
+ if (pwm->state.enabled) {
+ clk_disable(chip->clk);
+ chip->clk_enabled = false;
+ }
+ return 0;
+ } else if (!pwm->state.enabled) {
+ ret = clk_enable(chip->clk);
+ if (ret)
+ return ret;
+ chip->clk_enabled = true;
+ }
+
+ rate = DIV64_U64_ROUND_UP(NSEC_PER_SEC, period);
+ ret = clk_set_rate(chip->clk, rate);
+ if (ret)
+ return ret;
+
+ if (state->polarity == PWM_POLARITY_INVERSED)
+ duty_cycle = period - duty_cycle;
+
+ return clk_set_duty_cycle(chip->clk, duty_cycle, period);
+}
+
+static const struct pwm_ops pwm_clk_ops = {
+ .apply = pwm_clk_apply,
+ .owner = THIS_MODULE,
+};
+
+static int pwm_clk_probe(struct platform_device *pdev)
+{
+ struct pwm_clk_chip *chip;
+ int ret;
+
+ chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(chip->clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(chip->clk),
+ "Failed to get clock\n");
+
+ chip->chip.dev = &pdev->dev;
+ chip->chip.ops = &pwm_clk_ops;
+ chip->chip.npwm = 1;
+
+ ret = clk_prepare(chip->clk);
+ if (ret < 0)
+ dev_err_probe(&pdev->dev, ret, "Failed to prepare clock\n");
+
+ ret = pwmchip_add(&chip->chip);
+ if (ret < 0)
+ dev_err_probe(&pdev->dev, ret, "Failed to add pwm chip\n");
+
+ platform_set_drvdata(pdev, chip);
+ return 0;
+}
+
+static int pwm_clk_remove(struct platform_device *pdev)
+{
+ struct pwm_clk_chip *chip = platform_get_drvdata(pdev);
+
+ pwmchip_remove(&chip->chip);
+
+ if (chip->clk_enabled)
+ clk_disable(chip->clk);
+
+ clk_unprepare(chip->clk);
+
+ return 0;
+}
+
+static const struct of_device_id pwm_clk_dt_ids[] = {
+ { .compatible = "clk-pwm", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, pwm_clk_dt_ids);
+
+static struct platform_driver pwm_clk_driver = {
+ .driver = {
+ .name = "pwm-clk",
+ .of_match_table = pwm_clk_dt_ids,
+ },
+ .probe = pwm_clk_probe,
+ .remove = pwm_clk_remove,
+};
+module_platform_driver(pwm_clk_driver);
+
+MODULE_ALIAS("platform:pwm-clk");
+MODULE_AUTHOR("Nikita Travkin <nikita@trvn.ru>");
+MODULE_DESCRIPTION("Clock based PWM driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: imx: add Protonic PRT8MM board
From: Shawn Guo @ 2022-01-26 13:06 UTC (permalink / raw)
To: Lucas Stach
Cc: Pengutronix Kernel Team, NXP Linux Team, devicetree,
linux-arm-kernel, patchwork-lst
In-Reply-To: <20211217213617.3793534-2-l.stach@pengutronix.de>
On Fri, Dec 17, 2021 at 10:36:17PM +0100, Lucas Stach wrote:
> From: David Jander <david@protonic.nl>
>
> The Protonic PRT8MM is a low-cost agricultural Virtual Terminal. This
> commit adds most of the board functionality sans the display output,
> as the i.MX8MM display support isn't ready yet.
>
> Signed-off-by: David Jander <david@protonic.nl>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> .../boot/dts/freescale/imx8mm-prt8mm.dts | 304 ++++++++++++++++++
> 1 file changed, 304 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts b/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
> new file mode 100644
> index 000000000000..13330ad67760
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
> @@ -0,0 +1,304 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2020 Protonic Holland
> + * Copyright 2019 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/usb/pd.h>
> +#include "imx8mm.dtsi"
> +
> +/ {
> + model = "Protonic PRT8MM";
> + compatible = "prt,prt8mm", "fsl,imx8mm";
> +
> + chosen {
> + stdout-path = &uart4;
> + };
> +
> + memory@40000000 {
> + device_type = "memory";
> + reg = <0x0 0x40000000 0 0x40000000>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_leds>;
> +
> + debug-led0 {
> + label = "DEBUG_LED0";
> + gpios = <&gpio3 0 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + debug-led1 {
> + label = "DEBUG_LED1";
> + gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "cpu";
> + };
> + };
> +
> + sound-ssm2518 {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "ssm2518-audio";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,frame-master = <&cpudai>;
> + simple-audio-card,bitclock-master = <&cpudai>;
> +
> + cpudai: simple-audio-card,cpu {
> + sound-dai = <&sai3>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <&ssm2518>;
> + clocks = <&clk IMX8MM_CLK_SAI3_ROOT>;
> + };
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "okay";
> +
> + ssm2518: audio-codec@34 {
> + compatible = "adi,ssm2518";
> + reg = <0x34>;
> + #sound-dai-cells = <0>;
> + };
> +};
> +
> +&i2c2 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + regulator@60 {
> + compatible = "fcs,fan53555";
> + reg = <0x60>;
> + regulator-name = "0V9_CORE";
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <980000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +};
> +
> +&i2c3 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + status = "okay";
> +
> + rtc@51 {
> + compatible = "nxp,pcf85363";
> + reg = <0x51>;
> + };
> +
> + temp-sense@70 {
> + compatible = "ti,tmp103";
> + reg = <0x70>;
> + };
> +
> + touchscreeen@5d {
slave-address order is broken. I fixed it up and applied both.
Shawn
> + compatible = "goodix,gt911";
> + reg = <0x5d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touchscreen>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <8 IRQ_TYPE_NONE>;
> + irq-gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&sai3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai3>;
> + assigned-clocks = <&clk IMX8MM_CLK_SAI3>;
> + assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
> + assigned-clock-rates = <12288000>;
> + fsl,sai-mclk-direction-output;
> + fsl,sai-asynchronous;
> + status = "okay";
> +};
> +
> +&snvs_pwrkey {
> + status = "okay";
> +};
> +
> +&uart4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart4>;
> + status = "okay";
> +};
> +
> +&usbotg1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg1>;
> + dr_mode = "host";
> + disable-over-current;
> + power-active-high;
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + assigned-clocks = <&clk IMX8MM_CLK_USDHC2>;
> + assigned-clock-rates = <100000000>;
> + cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&usdhc3 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> + assigned-clocks = <&clk IMX8MM_CLK_USDHC3_ROOT>;
> + assigned-clock-rates = <400000000>;
> + bus-width = <8>;
> + non-removable;
> + no-sdio;
> + no-sd;
> + status = "okay";
> +};
> +
> +&wdog1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdog>;
> + fsl,ext-reset-output;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_gpio_leds: ledsgrp {
> + fsl,pins = <
> + MX8MM_IOMUXC_NAND_ALE_GPIO3_IO0 0x00
> + MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1 0x00
> + >;
> + };
> +
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400000c3
> + MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400000c3
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL 0x400000c3
> + MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA 0x400000c3
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400000c3
> + MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400000c3
> + >;
> + };
> +
> + pinctrl_sai3: sai3grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC 0xd6
> + MX8MM_IOMUXC_SAI3_TXC_SAI3_TX_BCLK 0xd6
> + MX8MM_IOMUXC_SAI3_MCLK_SAI3_MCLK 0xd6
> + MX8MM_IOMUXC_SAI3_TXD_SAI3_TX_DATA0 0xd6
> + >;
> + };
> +
> + pinctrl_touchscreen: tsgrp {
> + fsl,pins = <
> + MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x80
> + MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x80
> + >;
> + };
> +
> + pinctrl_uart4: uart4grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX 0x040
> + MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX 0x040
> + >;
> + };
> +
> + pinctrl_usbotg1: usbotg1grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_GPIO1_IO12_USB1_OTG_PWR 0x000
> + MX8MM_IOMUXC_GPIO1_IO13_USB1_OTG_OC 0x000
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190
> + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0
> + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0
> + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0
> + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0
> + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0
> + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x0d4
> + >;
> + };
> +
> + pinctrl_usdhc3: usdhc3grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x190
> + MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d0
> + MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d0
> + MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d0
> + MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d0
> + MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d0
> + MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d0
> + MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d0
> + MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d0
> + MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d0
> + MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x190
> + >;
> + };
> +
> + pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
> + fsl,pins = <
> + MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x194
> + MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4
> + MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d4
> + MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d4
> + MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d4
> + MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d4
> + MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d4
> + MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d4
> + MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d4
> + MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d4
> + MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x194
> + >;
> + };
> +
> + pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
> + fsl,pins = <
> + MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x196
> + MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6
> + MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d6
> + MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d6
> + MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d6
> + MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d6
> + MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d6
> + MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d6
> + MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d6
> + MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d6
> + MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x196
> + >;
> + };
> +
> + pinctrl_wdog: wdoggrp {
> + fsl,pins = <
> + MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
> + >;
> + };
> +};
> --
> 2.30.2
>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: pwm: Document clk based PWM controller
From: Krzysztof Kozlowski @ 2022-01-26 13:14 UTC (permalink / raw)
To: Nikita Travkin, thierry.reding, lee.jones
Cc: u.kleine-koenig, robh+dt, sboyd, linus.walleij, masneyb,
sean.anderson, linux-pwm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20220126125849.75572-2-nikita@trvn.ru>
On 26/01/2022 13:58, Nikita Travkin wrote:
> Add YAML devicetree binding for clk based PWM controller
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> --
> Changes in v2:
> - fix the file name.
> Changes in v4:
> - Use generic node name in the dt bindings example.
> ---
> .../devicetree/bindings/pwm/clk-pwm.yaml | 45 +++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>
> diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
> new file mode 100644
> index 000000000000..d3416ba549b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/clk-pwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Clock based PWM controller
> +
> +maintainers:
> + - Nikita Travkin <nikita@trvn.ru>
> +
> +description: |
> + Some systems have clocks that can be exposed to external devices.
> + (e.g. by muxing them to GPIO pins)
> + It's often possible to control duty-cycle of such clocks which makes them
> + suitable for generating PWM signal.
> +
> +allOf:
> + - $ref: pwm.yaml#
> +
> +properties:
> + compatible:
> + const: clk-pwm
> +
> + clocks:
> + description: Clock used to generate the signal.
> + maxItems: 1
> +
> + "#pwm-cells":
> + const: 2
> +
> +unevaluatedProperties: false
> +
> +required:
You need a compatible. pwm-cells can be skipped as pwm.yaml will require
them.
> + - clocks
> +
> +examples:
> + - |
> + pwm {
> + compatible = "clk-pwm";
> + #pwm-cells = <2>;
> + clocks = <&gcc 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm_clk_flash_default>;
> + };
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/2] pwm: Add clock based PWM output driver
From: Krzysztof Kozlowski @ 2022-01-26 13:18 UTC (permalink / raw)
To: Nikita Travkin, thierry.reding, lee.jones
Cc: u.kleine-koenig, robh+dt, sboyd, linus.walleij, masneyb,
sean.anderson, linux-pwm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20220126125849.75572-3-nikita@trvn.ru>
On 26/01/2022 13:58, Nikita Travkin wrote:
> Some systems have clocks exposed to external devices. If the clock
> controller supports duty-cycle configuration, such clocks can be used as
> pwm outputs. In fact PWM and CLK subsystems are interfaced with in a
> similar way and an "opposite" driver already exists (clk-pwm). Add a
> driver that would enable pwm devices to be used via clk subsystem.
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> --
>
> Changes in v2:
> - Address Uwe's review comments:
> - Round set clk rate up
> - Add a description with limitations of the driver
> - Disable and unprepare clock before removing pwmchip
> Changes in v3:
> - Use 64bit version of div round up
> - Address Uwe's review comments:
> - Reword the limitations to avoid incorrect claims
> - Move the clk_enabled flag assignment
> - Drop unnecessary statements
> ---
> drivers/pwm/Kconfig | 10 +++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-clk.c | 139 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 150 insertions(+)
> create mode 100644 drivers/pwm/pwm-clk.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 21e3b05a5153..daa2491a4054 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -140,6 +140,16 @@ config PWM_BRCMSTB
> To compile this driver as a module, choose M Here: the module
> will be called pwm-brcmstb.c.
>
> +config PWM_CLK
> + tristate "Clock based PWM support"
> + depends on HAVE_CLK || COMPILE_TEST
> + help
> + Generic PWM framework driver for outputs that can be
> + muxed to clocks.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-clk.
> +
> config PWM_CLPS711X
> tristate "CLPS711X PWM support"
> depends on ARCH_CLPS711X || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 708840b7fba8..4a860103c470 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
> obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
> obj-$(CONFIG_PWM_BERLIN) += pwm-berlin.o
> obj-$(CONFIG_PWM_BRCMSTB) += pwm-brcmstb.o
> +obj-$(CONFIG_PWM_CLK) += pwm-clk.o
> obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
> obj-$(CONFIG_PWM_CRC) += pwm-crc.o
> obj-$(CONFIG_PWM_CROS_EC) += pwm-cros-ec.o
> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
> new file mode 100644
> index 000000000000..b3bfa12a0e73
> --- /dev/null
> +++ b/drivers/pwm/pwm-clk.c
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Clock based PWM controller
> + *
> + * Copyright (c) 2021 Nikita Travkin <nikita@trvn.ru>
> + *
> + * This is an "adapter" driver that allows PWM consumers to use
> + * system clocks with duty cycle control as PWM outputs.
> + *
> + * Limitations:
> + * - Glitches are possible when new pwm state is applied.
> + * - Due to the fact that exact behavior depends on the underlying
> + * clock driver, various limitations are possible.
> + * - Period depends on the clock and, in general, not guaranteed.
> + * - Underlying clock may not be able to give 0% or 100% duty cycle
> + * (constant off or on), exact behavior will depend on the clock.
> + * - When the PWM is disabled, the clock will be disabled as well,
> + * line state will depend on the clock.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/math64.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/pwm.h>
> +
> +struct pwm_clk_chip {
> + struct pwm_chip chip;
> + struct clk *clk;
> + bool clk_enabled;
> +};
> +
> +#define to_pwm_clk_chip(_chip) container_of(_chip, struct pwm_clk_chip, chip)
> +
> +static int pwm_clk_apply(struct pwm_chip *pwm_chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct pwm_clk_chip *chip = to_pwm_clk_chip(pwm_chip);
> + int ret;
> + u32 rate;
> + u64 period = state->period;
> + u64 duty_cycle = state->duty_cycle;
> +
> + if (!state->enabled) {
> + if (pwm->state.enabled) {
> + clk_disable(chip->clk);
> + chip->clk_enabled = false;
> + }
> + return 0;
> + } else if (!pwm->state.enabled) {
> + ret = clk_enable(chip->clk);
> + if (ret)
> + return ret;
> + chip->clk_enabled = true;
> + }
> +
> + rate = DIV64_U64_ROUND_UP(NSEC_PER_SEC, period);
> + ret = clk_set_rate(chip->clk, rate);
> + if (ret)
> + return ret;
> +
> + if (state->polarity == PWM_POLARITY_INVERSED)
> + duty_cycle = period - duty_cycle;
> +
> + return clk_set_duty_cycle(chip->clk, duty_cycle, period);
> +}
> +
> +static const struct pwm_ops pwm_clk_ops = {
> + .apply = pwm_clk_apply,
> + .owner = THIS_MODULE,
> +};
> +
> +static int pwm_clk_probe(struct platform_device *pdev)
> +{
> + struct pwm_clk_chip *chip;
> + int ret;
> +
> + chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> + if (!chip)
> + return -ENOMEM;
> +
> + chip->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(chip->clk))
> + return dev_err_probe(&pdev->dev, PTR_ERR(chip->clk),
> + "Failed to get clock\n");
> +
> + chip->chip.dev = &pdev->dev;
> + chip->chip.ops = &pwm_clk_ops;
> + chip->chip.npwm = 1;
> +
> + ret = clk_prepare(chip->clk);
> + if (ret < 0)
> + dev_err_probe(&pdev->dev, ret, "Failed to prepare clock\n");
> +
> + ret = pwmchip_add(&chip->chip);
> + if (ret < 0)
> + dev_err_probe(&pdev->dev, ret, "Failed to add pwm chip\n");
> +
What is the point of probing the driver if pwmchip_add() fails? This
should be rather fatal error.
The same with clock. If preparing clock fails, there is little point in
enabling/disabling it later.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: watchdog: brcm,bcm7038: add more compatible strings
From: Rafał Miłecki @ 2022-01-26 13:21 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Florian Fainelli,
Justin Chen
Cc: linux-watchdog, devicetree, linux-arm-kernel,
bcm-kernel-feedback-list, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This hardware block is used on almost all BCM63xx family chipsets and
BCM4908 which reuses a lot of BCM63xx parts. Add relevant compatible
strings and also include a generic one.
The only SoC with a different block I found is BCM6838 (thus not included
in this change).
It may be worth noting that BCM6338, BCM6345, BCM6348 and BCM63268 don't
include "SoftRst" register but that can be handled by drivers based on
precise compatible string.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../bindings/watchdog/brcm,bcm7038-wdt.yaml | 21 +++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
index a926809352b8..b663f360f571 100644
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
@@ -16,9 +16,22 @@ maintainers:
properties:
compatible:
- enum:
- - brcm,bcm6345-wdt
- - brcm,bcm7038-wdt
+ items:
+ - enum:
+ - brcm,bcm4908-wdt
+ - brcm,bcm60333-wdt
+ - brcm,bcm63138-wdt
+ - brcm,bcm63148-wdt
+ - brcm,bcm63268-wdt
+ - brcm,bcm63381-wdt
+ - brcm,bcm6848-wdt
+ - brcm,bcm6858-wdt
+ - brcm,bcm68360-wdt
+ - brcm,bcm6338-wdt
+ - brcm,bcm6345-wdt
+ - brcm,bcm6348-wdt
+ - brcm,bcm7038-wdt
+ - const: brcm,bcm63xx-wdt
reg:
maxItems: 1
@@ -37,7 +50,7 @@ required:
examples:
- |
watchdog@f040a7e8 {
- compatible = "brcm,bcm7038-wdt";
+ compatible = "brcm,bcm7038-wdt", "brcm,bcm63xx-wdt";
reg = <0xf040a7e8 0x16>;
clocks = <&upg_fixed>;
};
--
2.31.1
^ permalink raw reply related
* [PATCH v2 1/1] arm64: dts: tqma8mqml: add PCIe support
From: Alexander Stein @ 2022-01-26 13:23 UTC (permalink / raw)
To: Rob Herring, Shawn Guo, Sascha Hauer
Cc: Alexander Stein, devicetree, linux-arm-kernel
Add PCIe support to TQMa8MxML series.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
This goes on top of the series recently applied to pci/dwc [1]:
[PATCH v7 0/8] Add the imx8m pcie phy driver and imx8mm pcie support
Changes in v2:
* rebased to Shawn's current imx/dt64 (as of 2022/01/26)
[1] https://patchwork.kernel.org/project/linux-pci/list/?series=589031&state=*
.../dts/freescale/imx8mm-tqma8mqml-mba8mx.dts | 19 +++++++++++++++++++
.../boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 5 +++++
arch/arm64/boot/dts/freescale/mba8mx.dtsi | 6 ++++++
3 files changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
index 7844878788f4..286d2df01cfa 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
@@ -5,6 +5,7 @@
/dts-v1/;
+#include <dt-bindings/phy/phy-imx8-pcie.h>
#include "imx8mm-tqma8mqml.dtsi"
#include "mba8mx.dtsi"
@@ -58,6 +59,24 @@ expander2: gpio@27 {
};
};
+&pcie_phy {
+ clocks = <&pcie0_refclk>;
+ status = "okay";
+};
+
+&pcie0 {
+ reset-gpio = <&expander0 14 GPIO_ACTIVE_LOW>;
+ clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
+ <&pcie0_refclk>;
+ clock-names = "pcie", "pcie_aux", "pcie_bus";
+ assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+ <&clk IMX8MM_CLK_PCIE1_CTRL>;
+ assigned-clock-rates = <10000000>, <250000000>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+ <&clk IMX8MM_SYS_PLL2_250M>;
+ status = "okay";
+};
+
&sai3 {
assigned-clocks = <&clk IMX8MM_CLK_SAI3>;
assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
index 284e62acc0b4..16ee9b5179e6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
@@ -227,6 +227,11 @@ eeprom0: eeprom@57 {
};
};
+&pcie_phy {
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ fsl,clkreq-unsupported;
+};
+
&usdhc3 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc3>;
diff --git a/arch/arm64/boot/dts/freescale/mba8mx.dtsi b/arch/arm64/boot/dts/freescale/mba8mx.dtsi
index f27e3c8de916..3ea34b3a55f8 100644
--- a/arch/arm64/boot/dts/freescale/mba8mx.dtsi
+++ b/arch/arm64/boot/dts/freescale/mba8mx.dtsi
@@ -66,6 +66,12 @@ led2: led2 {
};
};
+ pcie0_refclk: pcie0-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ };
+
reg_hub_vbus: regulator-hub-vbus {
compatible = "regulator-fixed";
regulator-name = "MBA8MX_HUB_VBUS";
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: pwm: Document clk based PWM controller
From: Nikita Travkin @ 2022-01-26 13:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: thierry.reding, lee.jones, u.kleine-koenig, robh+dt, sboyd,
linus.walleij, masneyb, sean.anderson, linux-pwm, devicetree,
linux-kernel, ~postmarketos/upstreaming
In-Reply-To: <48350476-605c-0775-7d18-2601d3360241@kernel.org>
Krzysztof Kozlowski писал(а) 26.01.2022 18:14:
> On 26/01/2022 13:58, Nikita Travkin wrote:
>> Add YAML devicetree binding for clk based PWM controller
>>
>> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
>> --
>> Changes in v2:
>> - fix the file name.
>> Changes in v4:
>> - Use generic node name in the dt bindings example.
>> ---
>> .../devicetree/bindings/pwm/clk-pwm.yaml | 45 +++++++++++++++++++
>> 1 file changed, 45 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>> new file mode 100644
>> index 000000000000..d3416ba549b5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>> @@ -0,0 +1,45 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pwm/clk-pwm.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Clock based PWM controller
>> +
>> +maintainers:
>> + - Nikita Travkin <nikita@trvn.ru>
>> +
>> +description: |
>> + Some systems have clocks that can be exposed to external devices.
>> + (e.g. by muxing them to GPIO pins)
>> + It's often possible to control duty-cycle of such clocks which makes them
>> + suitable for generating PWM signal.
>> +
>> +allOf:
>> + - $ref: pwm.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: clk-pwm
>> +
>> + clocks:
>> + description: Clock used to generate the signal.
>> + maxItems: 1
>> +
>> + "#pwm-cells":
>> + const: 2
>> +
>> +unevaluatedProperties: false
>> +
>> +required:
>
> You need a compatible. pwm-cells can be skipped as pwm.yaml will require
> them.
>
Oops, thanks for noticing that, will add. (Though I'd assume compatible
to be implicitly required as the schema wouldn't even match otherwise...)
Nikita
>> + - clocks
>> +
>> +examples:
>> + - |
>> + pwm {
>> + compatible = "clk-pwm";
>> + #pwm-cells = <2>;
>> + clocks = <&gcc 0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pwm_clk_flash_default>;
>> + };
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH net-next 1/5] dt-bindings: net: xgmac_mdio: Remove unsupported "bus-frequency"
From: Andrew Lunn @ 2022-01-26 13:31 UTC (permalink / raw)
To: Tobias Waldekranz
Cc: davem, kuba, netdev, Madalin Bucur, Rob Herring, Shaohui Xie,
Scott Wood, devicetree, linux-kernel
In-Reply-To: <20220126101432.822818-2-tobias@waldekranz.com>
On Wed, Jan 26, 2022 at 11:14:28AM +0100, Tobias Waldekranz wrote:
> This property has never been supported by the driver. The kernel has
> settled on "clock-frequency" as the standard name for this binding, so
> once that is supported we will document that instead.
>
> Fixes: 7f93c9d90f4d ("power/fsl: add MDIO dt binding for FMan")
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v4 2/2] pwm: Add clock based PWM output driver
From: Nikita Travkin @ 2022-01-26 13:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: thierry.reding, lee.jones, u.kleine-koenig, robh+dt, sboyd,
linus.walleij, masneyb, sean.anderson, linux-pwm, devicetree,
linux-kernel, ~postmarketos/upstreaming
In-Reply-To: <2c65c342-5c04-bcf4-fd75-5c11d26f0b33@kernel.org>
Krzysztof Kozlowski писал(а) 26.01.2022 18:18:
> On 26/01/2022 13:58, Nikita Travkin wrote:
>> Some systems have clocks exposed to external devices. If the clock
>> controller supports duty-cycle configuration, such clocks can be used as
>> pwm outputs. In fact PWM and CLK subsystems are interfaced with in a
>> similar way and an "opposite" driver already exists (clk-pwm). Add a
>> driver that would enable pwm devices to be used via clk subsystem.
>>
>> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
>> --
>>
>> Changes in v2:
>> - Address Uwe's review comments:
>> - Round set clk rate up
>> - Add a description with limitations of the driver
>> - Disable and unprepare clock before removing pwmchip
>> Changes in v3:
>> - Use 64bit version of div round up
>> - Address Uwe's review comments:
>> - Reword the limitations to avoid incorrect claims
>> - Move the clk_enabled flag assignment
>> - Drop unnecessary statements
>> ---
>> drivers/pwm/Kconfig | 10 +++
>> drivers/pwm/Makefile | 1 +
>> drivers/pwm/pwm-clk.c | 139 ++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 150 insertions(+)
>> create mode 100644 drivers/pwm/pwm-clk.c
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index 21e3b05a5153..daa2491a4054 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -140,6 +140,16 @@ config PWM_BRCMSTB
>> To compile this driver as a module, choose M Here: the module
>> will be called pwm-brcmstb.c.
>>
>> +config PWM_CLK
>> + tristate "Clock based PWM support"
>> + depends on HAVE_CLK || COMPILE_TEST
>> + help
>> + Generic PWM framework driver for outputs that can be
>> + muxed to clocks.
>> +
>> + To compile this driver as a module, choose M here: the module
>> + will be called pwm-clk.
>> +
>> config PWM_CLPS711X
>> tristate "CLPS711X PWM support"
>> depends on ARCH_CLPS711X || COMPILE_TEST
>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>> index 708840b7fba8..4a860103c470 100644
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
>> obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
>> obj-$(CONFIG_PWM_BERLIN) += pwm-berlin.o
>> obj-$(CONFIG_PWM_BRCMSTB) += pwm-brcmstb.o
>> +obj-$(CONFIG_PWM_CLK) += pwm-clk.o
>> obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
>> obj-$(CONFIG_PWM_CRC) += pwm-crc.o
>> obj-$(CONFIG_PWM_CROS_EC) += pwm-cros-ec.o
>> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
>> new file mode 100644
>> index 000000000000..b3bfa12a0e73
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-clk.c
>> @@ -0,0 +1,139 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Clock based PWM controller
>> + *
>> + * Copyright (c) 2021 Nikita Travkin <nikita@trvn.ru>
>> + *
>> + * This is an "adapter" driver that allows PWM consumers to use
>> + * system clocks with duty cycle control as PWM outputs.
>> + *
>> + * Limitations:
>> + * - Glitches are possible when new pwm state is applied.
>> + * - Due to the fact that exact behavior depends on the underlying
>> + * clock driver, various limitations are possible.
>> + * - Period depends on the clock and, in general, not guaranteed.
>> + * - Underlying clock may not be able to give 0% or 100% duty cycle
>> + * (constant off or on), exact behavior will depend on the clock.
>> + * - When the PWM is disabled, the clock will be disabled as well,
>> + * line state will depend on the clock.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/math64.h>
>> +#include <linux/err.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/clk.h>
>> +#include <linux/pwm.h>
>> +
>> +struct pwm_clk_chip {
>> + struct pwm_chip chip;
>> + struct clk *clk;
>> + bool clk_enabled;
>> +};
>> +
>> +#define to_pwm_clk_chip(_chip) container_of(_chip, struct pwm_clk_chip, chip)
>> +
>> +static int pwm_clk_apply(struct pwm_chip *pwm_chip, struct pwm_device *pwm,
>> + const struct pwm_state *state)
>> +{
>> + struct pwm_clk_chip *chip = to_pwm_clk_chip(pwm_chip);
>> + int ret;
>> + u32 rate;
>> + u64 period = state->period;
>> + u64 duty_cycle = state->duty_cycle;
>> +
>> + if (!state->enabled) {
>> + if (pwm->state.enabled) {
>> + clk_disable(chip->clk);
>> + chip->clk_enabled = false;
>> + }
>> + return 0;
>> + } else if (!pwm->state.enabled) {
>> + ret = clk_enable(chip->clk);
>> + if (ret)
>> + return ret;
>> + chip->clk_enabled = true;
>> + }
>> +
>> + rate = DIV64_U64_ROUND_UP(NSEC_PER_SEC, period);
>> + ret = clk_set_rate(chip->clk, rate);
>> + if (ret)
>> + return ret;
>> +
>> + if (state->polarity == PWM_POLARITY_INVERSED)
>> + duty_cycle = period - duty_cycle;
>> +
>> + return clk_set_duty_cycle(chip->clk, duty_cycle, period);
>> +}
>> +
>> +static const struct pwm_ops pwm_clk_ops = {
>> + .apply = pwm_clk_apply,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static int pwm_clk_probe(struct platform_device *pdev)
>> +{
>> + struct pwm_clk_chip *chip;
>> + int ret;
>> +
>> + chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
>> + if (!chip)
>> + return -ENOMEM;
>> +
>> + chip->clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(chip->clk))
>> + return dev_err_probe(&pdev->dev, PTR_ERR(chip->clk),
>> + "Failed to get clock\n");
>> +
>> + chip->chip.dev = &pdev->dev;
>> + chip->chip.ops = &pwm_clk_ops;
>> + chip->chip.npwm = 1;
>> +
>> + ret = clk_prepare(chip->clk);
>> + if (ret < 0)
>> + dev_err_probe(&pdev->dev, ret, "Failed to prepare clock\n");
>> +
>> + ret = pwmchip_add(&chip->chip);
>> + if (ret < 0)
>> + dev_err_probe(&pdev->dev, ret, "Failed to add pwm chip\n");
>> +
>
> What is the point of probing the driver if pwmchip_add() fails? This
> should be rather fatal error.
>
> The same with clock. If preparing clock fails, there is little point in
> enabling/disabling it later.
>
Uh oh... Seems like I forgot a return in both cases... For some reason
I had an incorrect assumption in my mind that dev_err_probe is a macro
that does the return on it's own, yet I used it correctly just a couple
of lines earlier...
Thanks for pointing this out! Will fix those in v5.
Nikita
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH net-next 5/5] dt-bindings: net: xgmac_mdio: Add "clock-frequency" and "suppress-preamble"
From: Andrew Lunn @ 2022-01-26 13:36 UTC (permalink / raw)
To: Tobias Waldekranz
Cc: davem, kuba, netdev, Madalin Bucur, Rob Herring, devicetree,
linux-kernel
In-Reply-To: <20220126101432.822818-6-tobias@waldekranz.com>
On Wed, Jan 26, 2022 at 11:14:32AM +0100, Tobias Waldekranz wrote:
> The driver now supports the standard "clock-frequency" and
> "suppress-preamble" properties, do document them in the binding
> description.
>
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
However, you could convert to yaml as well, if you wanted.
> +- clocks
> + Usage: optional
> + Value type: <phandle>
> + Definition: A reference to the input clock of the controller
> + from which the MDC frequency is derived.
That answers my question. However, in the presence of a
'clock-frequency' property it cannot be optional, so -ENODEV seems
reasonable if it is missing. Potentially you also need to handle
-EPROBE_DEFER, although it seems quiet unlikely for an internal SoC
clock.
Andrew
^ permalink raw reply
* Re: [PATCH v6 2/2] serial:sunplus-uart:Add Sunplus SoC UART Driver
From: Greg KH @ 2022-01-26 13:47 UTC (permalink / raw)
To: hammer hsieh
Cc: Jiri Slaby, robh+dt, linux-serial, devicetree, linux-kernel,
p.zabel, wells.lu, hammer.hsieh
In-Reply-To: <CAOX-t573QkixRC7xa1KUOYXfL12Q+Ltxph9rX7V8tm2BMoqxgA@mail.gmail.com>
On Fri, Jan 14, 2022 at 10:22:56AM +0800, hammer hsieh wrote:
> Jiri Slaby <jirislaby@kernel.org> 於 2022年1月13日 週四 下午7:12寫道：
> >
> > On 13. 01. 22, 11:56, hammer hsieh wrote:
> > >> Could you explain me what posted write is and how does it not matter in
> > >> this case?
> > >>
> > >
> > > Each UART ISC register contains
> >
> > No, you still don't follow what I write. Use your favorite web search
> > for "posted write" and/or consult with your HW team.
> >
>
> Maybe this time, we are on the same page.
> Our SP7021 chipset is designed on ARM Cortex-A7 Quad core.
> Register Access through AMBA(AXI bus), and it is non-cached.
>
> Did you mean
> case1 have concern about "posted write", and you want to know why it not matter?
> case2 will be safer?
>
> Case1 :
> spin_lock_irq_save()
> writel(0, target register)
> spin_unlock_irqrestore()
A lock does not mean that your write made it to the device. Please talk
to the hardware designers to properly determine how to correctly write
to the hardware and "know" that the write succeeded or not. This driver
does not seem to take that into consideration at all.
thanks,
greg k-h
^ permalink raw reply
* Re: (EXT) [PATCH 9/9] arm64: dts: imx8mp: add GPU nodes
From: Alexander Stein @ 2022-01-26 13:51 UTC (permalink / raw)
To: Lucas Stach
Cc: Shawn Guo, Rob Herring, linux-arm-kernel, Pengutronix Kernel Team,
NXP Linux Team, Fabio Estevam, devicetree, linux-arm-kernel,
patchwork-lst
In-Reply-To: <20220119134027.2931945-10-l.stach@pengutronix.de>
Am Mittwoch, 19. Januar 2022, 14:40:27 CET schrieb Lucas Stach:
> Add the DT nodes for both the 3D and 2D GPU cores found on the i.MX8MP.
>
> etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204
> etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
> [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0
Unfortunately it does not work when CONFIG_DRM_ETNAVIV=m
etnaviv-gpu 38000000.gpu: model: GC0, revision: 0
etnaviv-gpu 38000000.gpu: Unknown GPU model
etnaviv-gpu 38008000.gpu: model: GC0, revision: 0
etnaviv-gpu 38008000.gpu: Unknown GPU model
When I use CONFIG_DRM_ETNAVIV=y, I get the same log message as you. It's not
related to this patch, but I have no clue if the cause is in blk-ctrl or pgc.
I think (don't know for sure yet) my random errors on USB side are gone when
USB drivers (PHY as well) are built-in. But I might be wrong here.
Best regards,
Alexander
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox