* [PATCH] ARM: dts: aspeed: remove unhandled fttmr010,pwm-outputs
From: Corentin Labbe @ 2022-01-27 12:19 UTC (permalink / raw)
To: a.kartashev, andrew, joel, robh+dt
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Corentin Labbe
fttmr010,pwm-outputs is not handled by its timer driver, so this
property is useless.
Fixes: 67ac01d03862 ("ARM: dts: aspeed: add device tree for YADRO VEGMAN BMC")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
arch/arm/boot/dts/aspeed-bmc-vegman.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
index 1a5b25b2ea29..43af63910571 100644
--- a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
+++ b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
@@ -166,7 +166,6 @@ &sdhci1 {
};
&timer {
- fttmr010,pwm-outputs = <5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_timer5_default>;
#pwm-cells = <3>;
--
2.34.1
^ permalink raw reply related
* [PATCH] arm64: dts: meson-sm1: fix wrong GPIO domain for GPIOE_2
From: Dongjin Kim @ 2022-01-27 12:25 UTC (permalink / raw)
To: Rob Herring, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
GPIOE_2 is in AO domain and "<&gpio GPIOE_2 ...>" changes the state of
GPIOZ_14 connected to INTR of 'RTL8211F' on ODROID-HC and TF_PWR_EN of
'FC8731' on BPI-M5
Fixes: 1f80a5cf74a6 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator")
Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts")
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
index 212c6aa5a3b8..5751c48620ed 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
@@ -123,7 +123,7 @@ vddio_c: regulator-vddio_c {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
- enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
enable-active-high;
regulator-always-on;
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
index bf29afac645f..d4349b355e4a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
@@ -52,7 +52,7 @@ tf_io: gpio-regulator-tf_io {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_5v>;
- enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
enable-active-high;
regulator-always-on;
--
2.32.0
^ permalink raw reply related
* [PATCH] arm64: dts: meson-g12b-odroid-n2: fix typo 'dio2133'
From: Dongjin Kim @ 2022-01-27 12:29 UTC (permalink / raw)
To: Rob Herring, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
Typo in audio amplifier node, dioo2133 -> dio2133
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
index aa5898a58b89..120f2551a28b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
@@ -22,7 +22,7 @@ aliases {
spi0 = &spicc0;
};
- dioo2133: audio-amplifier-0 {
+ dio2133: audio-amplifier-0 {
compatible = "simple-audio-amplifier";
enable-gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
VCC-supply = <&vcc_5v>;
@@ -222,7 +222,7 @@ sound {
audio-widgets = "Line", "Lineout";
audio-aux-devs = <&tdmout_b>, <&tdmout_c>, <&tdmin_a>,
<&tdmin_b>, <&tdmin_c>, <&tdmin_lb>,
- <&dioo2133>;
+ <&dio2133>;
audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
"TDMOUT_B IN 1", "FRDDR_B OUT 1",
"TDMOUT_B IN 2", "FRDDR_C OUT 1",
--
2.32.0
^ permalink raw reply related
* [PATCH] dt-bindings: gpio: convert faraday,ftgpio01 to yaml
From: Corentin Labbe @ 2022-01-27 12:30 UTC (permalink / raw)
To: brgl, conleylee, linus.walleij, robh+dt
Cc: devicetree, linux-gpio, linux-kernel, Corentin Labbe
Converts gpio/faraday,ftgpio010.txt to yaml.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
This commit will cause arch/arm/boot/dts/moxart-uc7112lx.dts to fail DT validation,
but the GPIO driver need an interrupt so the current moxart DT is incomplete and the error is appropriate.
.../bindings/gpio/faraday,ftgpio010.txt | 27 ---------
.../bindings/gpio/faraday,ftgpio010.yaml | 59 +++++++++++++++++++
2 files changed, 59 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt
create mode 100644 Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml
diff --git a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt
deleted file mode 100644
index d04236558619..000000000000
--- a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Faraday Technology FTGPIO010 GPIO Controller
-
-Required properties:
-
-- compatible : Should be one of
- "cortina,gemini-gpio", "faraday,ftgpio010"
- "moxa,moxart-gpio", "faraday,ftgpio010"
- "faraday,ftgpio010"
-- reg : Should contain registers location and length
-- interrupts : Should contain the interrupt line for the GPIO block
-- gpio-controller : marks this as a GPIO controller
-- #gpio-cells : Should be 2, see gpio/gpio.txt
-- interrupt-controller : marks this as an interrupt controller
-- #interrupt-cells : a standard two-cell interrupt flag, see
- interrupt-controller/interrupts.txt
-
-Example:
-
-gpio@4d000000 {
- compatible = "cortina,gemini-gpio", "faraday,ftgpio010";
- reg = <0x4d000000 0x100>;
- interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml
new file mode 100644
index 000000000000..dfd10b76c9d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/faraday,ftgpio010.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Faraday Technology FTGPIO010 GPIO Controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: "cortina,gemini-gpio"
+ - const: "faraday,ftgpio010"
+ - items:
+ - const: "moxa,moxart-gpio"
+ - const: "faraday,ftgpio010"
+ - const: "faraday,ftgpio010"
+ reg:
+ maxItems: 1
+ resets:
+ maxItems: 1
+ clocks:
+ maxItems: 1
+ interrupts:
+ maxItems: 1
+ description: Should contain the interrupt line for the GPIO block
+ gpio-controller: true
+ "#gpio-cells":
+ const: 2
+ interrupt-controller: true
+ "#interrupt-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ gpio@4d000000 {
+ compatible = "cortina,gemini-gpio", "faraday,ftgpio010";
+ reg = <0x4d000000 0x100>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v9] arm64: dts: qcom: sc7280: Add WPSS remoteproc node
From: Manikanta Pubbisetty @ 2022-01-27 12:40 UTC (permalink / raw)
To: agross, bjorn.andersson, robh+dt, swboyd
Cc: linux-arm-msm, devicetree, linux-kernel, quic_sibis, kuabhs,
quic_pillair, Manikanta Pubbisetty
From: Rakesh Pillai <quic_pillair@quicinc.com>
Add the WPSS remoteproc node in dts for
PIL loading.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rakesh Pillai <quic_pillair@quicinc.com>
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
---
Changes from v8:
- Enable remoteproc_wpss from sc7280-idp.dtsi as the change is common for IDP and IDP2
Changes from v7:
- Remove wpss_mem from reserved memory. Its part of board dtsi.
Changes from v6:
- Swap the oder of two properties in wpss_mem reserved memory
Changes from v5:
- Update the clock names
arch/arm64/boot/dts/qcom/sc7280-idp.dtsi | 4 +++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 51 ++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
index a146d0d..7287e51 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
@@ -634,3 +634,7 @@
bias-pull-up;
};
};
+
+&remoteproc_wpss {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 937c2e0..e7c0745 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2603,6 +2603,57 @@
status = "disabled";
};
+ remoteproc_wpss: remoteproc@8a00000 {
+ compatible = "qcom,sc7280-wpss-pil";
+ reg = <0 0x08a00000 0 0x10000>;
+
+ interrupts-extended = <&intc GIC_SPI 587 IRQ_TYPE_EDGE_RISING>,
+ <&wpss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&wpss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&wpss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&wpss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&wpss_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ clocks = <&gcc GCC_WPSS_AHB_BDG_MST_CLK>,
+ <&gcc GCC_WPSS_AHB_CLK>,
+ <&gcc GCC_WPSS_RSCP_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "ahb_bdg", "ahb",
+ "rscp", "xo";
+
+ power-domains = <&rpmhpd SC7280_CX>,
+ <&rpmhpd SC7280_MX>;
+ power-domain-names = "cx", "mx";
+
+ memory-region = <&wpss_mem>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&wpss_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ resets = <&aoss_reset AOSS_CC_WCSS_RESTART>,
+ <&pdc_reset PDC_WPSS_SYNC_RESET>;
+ reset-names = "restart", "pdc_sync";
+
+ qcom,halt-regs = <&tcsr_mutex 0x37000>;
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_WPSS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_WPSS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "wpss";
+ qcom,remote-pid = <13>;
+ };
+ };
+
dc_noc: interconnect@90e0000 {
reg = <0 0x090e0000 0 0x5080>;
compatible = "qcom,sc7280-dc-noc";
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] arm64: dts: meson-sm1-odroid: use correct enable-gpio pin for tf-io regulator
From: Lutz Koschorreck @ 2022-01-27 12:38 UTC (permalink / raw)
To: Neil Armstrong
Cc: Rob Herring, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <651adde5-4887-4701-5183-6a35a443574c@baylibre.com>
On Thu, Jan 27, 2022 at 11:15:12AM +0100, Neil Armstrong wrote:
> Hi,
>
> On 27/01/2022 00:43, Lutz Koschorreck wrote:
> > The interrupt pin of the external ethernet phy is used, instead of the
> > enable-gpio pin of the tf-io regulator. The GPIOE_2 pin is located in
> > the gpio_ao bank.
> > Using open drain prevents reboot issues.
> >
> > This causes phy interrupt problems at system startup.
> > [ 76.645190] irq 36: nobody cared (try booting with the "irqpoll" option)
> > [ 76.649617] CPU: 0 PID: 1416 Comm: irq/36-0.0:00 Not tainted 5.16.0 #2
> > [ 76.649629] Hardware name: Hardkernel ODROID-HC4 (DT)
> > [ 76.649635] Call trace:
> > [ 76.649638] dump_backtrace+0x0/0x1c8
> > [ 76.649658] show_stack+0x14/0x60
> > [ 76.649667] dump_stack_lvl+0x64/0x7c
> > [ 76.649676] dump_stack+0x14/0x2c
> > [ 76.649683] __report_bad_irq+0x38/0xe8
> > [ 76.649695] note_interrupt+0x220/0x3a0
> > [ 76.649704] handle_irq_event_percpu+0x58/0x88
> > [ 76.649713] handle_irq_event+0x44/0xd8
> > [ 76.649721] handle_fasteoi_irq+0xa8/0x130
> > [ 76.649730] generic_handle_domain_irq+0x38/0x58
> > [ 76.649738] gic_handle_irq+0x9c/0xb8
> > [ 76.649747] call_on_irq_stack+0x28/0x38
> > [ 76.649755] do_interrupt_handler+0x7c/0x80
> > [ 76.649763] el1_interrupt+0x34/0x80
> > [ 76.649772] el1h_64_irq_handler+0x14/0x20
> > [ 76.649781] el1h_64_irq+0x74/0x78
> > [ 76.649788] irq_finalize_oneshot.part.56+0x68/0xf8
> > [ 76.649796] irq_thread_fn+0x5c/0x98
> > [ 76.649804] irq_thread+0x13c/0x260
> > [ 76.649812] kthread+0x144/0x178
> > [ 76.649822] ret_from_fork+0x10/0x20
> > [ 76.649830] handlers:
> > [ 76.653170] [<0000000025a6cd31>] irq_default_primary_handler threaded [<0000000093580eb7>] phy_interrupt
> > [ 76.661256] Disabling IRQ #36
> >
> > Fixes: 1f80a5cf74a6 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator")
> >
> > Signed-off-by: Lutz Koschorreck <theleks@ko-hh.de>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> > index 0bd1e98a0eef..ddb1b345397f 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> > @@ -48,7 +48,7 @@ tf_io: gpio-regulator-tf_io {
> > regulator-max-microvolt = <3300000>;
> > vin-supply = <&vcc_5v>;
> >
> > - enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
> > + enable-gpio = <&gpio_ao GPIOE_2 GPIO_OPEN_DRAIN>;
>
> Wow, indeed it's not the right GPIO chip... my bad.
>
> > enable-active-high;
> > regulator-always-on;
> >
>
> Concerning the GPIO_OPEN_DRAIN, it's right since the line has a pull-up, does it really fix reboot issues ?
There is a 10k pull up on the pin of C4 and HC4. Therefore it is fine to
set to GPIO_OPEN_DRAIN. If this pin is left ACTIVE_HIGH and I call
reboot, the bootloader is does not came up, it is an boot loop. Tobetter
fixed that with a reset device driver, but I think using GPIO_OPEN_DRAIN
is the right solution.
>
> Anyway, can you split the changes ? First for gpio_ao, second for GPIO_OPEN_DRAIN ?
Yes of cause. I will generate a new patch set.
>
> Neil
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-g12b-odroid-n2: fix typo 'dio2133'
From: Neil Armstrong @ 2022-01-27 12:59 UTC (permalink / raw)
To: Dongjin Kim, Rob Herring, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <YfKQJejh0bfGYvof@anyang>
On 27/01/2022 13:29, Dongjin Kim wrote:
> Typo in audio amplifier node, dioo2133 -> dio2133
>
Fixes: ef599f5f3e10 ("arm64: dts: meson: convert ODROID-N2 to dtsi")
Fixes: 67d141c1f8e6 ("arm64: dts: meson: odroid-n2: add jack audio output support")
> Signed-off-by: Dongjin Kim <tobetter@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
> index aa5898a58b89..120f2551a28b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
> @@ -22,7 +22,7 @@ aliases {
> spi0 = &spicc0;
> };
>
> - dioo2133: audio-amplifier-0 {
> + dio2133: audio-amplifier-0 {
> compatible = "simple-audio-amplifier";
> enable-gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
> VCC-supply = <&vcc_5v>;
> @@ -222,7 +222,7 @@ sound {
> audio-widgets = "Line", "Lineout";
> audio-aux-devs = <&tdmout_b>, <&tdmout_c>, <&tdmin_a>,
> <&tdmin_b>, <&tdmin_c>, <&tdmin_lb>,
> - <&dioo2133>;
> + <&dio2133>;
> audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
> "TDMOUT_B IN 1", "FRDDR_B OUT 1",
> "TDMOUT_B IN 2", "FRDDR_C OUT 1",
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: sc7280: Add WCN6750 WiFi node
From: Manikanta Pubbisetty @ 2022-01-27 12:59 UTC (permalink / raw)
To: agross, bjorn.andersson, robh+dt
Cc: linux-arm-msm, devicetree, Manikanta Pubbisetty
Add DTS node for WCN6750 WiFi chipset.
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
---
Depends on:
- https://patchwork.kernel.org/project/linux-arm-msm/patch/1643287248-1092-1-git-send-email-quic_mpubbise@quicinc.com/
- https://patchwork.kernel.org/project/linux-wireless/list/?series=605793
Changes from V1:
- Corrected the case for hex values
arch/arm64/boot/dts/qcom/sc7280-idp.dtsi | 7 +++++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 47 ++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
index 7287e51..e6b86bd 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
@@ -638,3 +638,10 @@
&remoteproc_wpss {
status = "okay";
};
+
+&wifi {
+ status = "okay";
+ wifi-firmware {
+ iommus = <&apps_smmu 0x1c02 0x1>;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index e7c0745..bb57274 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -83,6 +83,11 @@
#size-cells = <2>;
ranges;
+ wlan_ce_mem: memory@4cd000 {
+ no-map;
+ reg = <0x0 0x4cd000 0x0 0x1000>;
+ };
+
hyp_mem: memory@80000000 {
reg = <0x0 0x80000000 0x0 0x600000>;
no-map;
@@ -1574,6 +1579,48 @@
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ wifi: wifi@17a10040 {
+ compatible = "qcom,wcn6750-wifi";
+ reg = <0 0x17a10040 0 0x0>;
+ reg-names = "msi_addr";
+ iommus = <&apps_smmu 0x1c00 0x1>;
+ interrupts = <GIC_SPI 768 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 769 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 770 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 771 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 772 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 773 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 774 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 775 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 776 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 777 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 778 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 779 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 780 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 781 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 782 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 783 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 784 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 785 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 786 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 787 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 788 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 789 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 790 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 791 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 792 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 793 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 794 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 795 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 796 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 797 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 798 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 799 IRQ_TYPE_EDGE_RISING>;
+ qcom,rproc = <&remoteproc_wpss>;
+ memory-region = <&wlan_fw_mem &wlan_ce_mem>;
+ status = "disabled";
+ };
+
pcie1: pci@1c08000 {
compatible = "qcom,pcie-sc7280";
reg = <0 0x01c08000 0 0x3000>,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] arm64: dts: meson-sm1: fix wrong GPIO domain for GPIOE_2
From: Neil Armstrong @ 2022-01-27 13:00 UTC (permalink / raw)
To: Dongjin Kim, Rob Herring, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <YfKPSvnFKOaLr74+@anyang>
Hi,
On 27/01/2022 13:25, Dongjin Kim wrote:
> GPIOE_2 is in AO domain and "<&gpio GPIOE_2 ...>" changes the state of
> GPIOZ_14 connected to INTR of 'RTL8211F' on ODROID-HC and TF_PWR_EN of
> 'FC8731' on BPI-M5
>
> Fixes: 1f80a5cf74a6 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator")
> Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts")
>
> Signed-off-by: Dongjin Kim <tobetter@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
> index 212c6aa5a3b8..5751c48620ed 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
> @@ -123,7 +123,7 @@ vddio_c: regulator-vddio_c {
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <3300000>;
>
> - enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
> + enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> regulator-always-on;
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> index bf29afac645f..d4349b355e4a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> @@ -52,7 +52,7 @@ tf_io: gpio-regulator-tf_io {
> regulator-max-microvolt = <3300000>;
> vin-supply = <&vcc_5v>;
>
> - enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
> + enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> regulator-always-on;
>
>
Thanks for the fixes,
can you send 2 patches fixing each files instead ?
Thanks,
Neil
^ permalink raw reply
* [PATCH v2] arm64: dts: meson-sm1-odroid: use correct enable-gpio pin for tf-io regulator
From: Lutz Koschorreck @ 2022-01-27 13:05 UTC (permalink / raw)
To: Rob Herring, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
The interrupt pin of the external ethernet phy is used, instead of the
enable-gpio pin of the tf-io regulator. The GPIOE_2 pin is located in
the gpio_ao bank.
This causes phy interrupt problems at system startup.
[ 76.645190] irq 36: nobody cared (try booting with the "irqpoll" option)
[ 76.649617] CPU: 0 PID: 1416 Comm: irq/36-0.0:00 Not tainted 5.16.0 #2
[ 76.649629] Hardware name: Hardkernel ODROID-HC4 (DT)
[ 76.649635] Call trace:
[ 76.649638] dump_backtrace+0x0/0x1c8
[ 76.649658] show_stack+0x14/0x60
[ 76.649667] dump_stack_lvl+0x64/0x7c
[ 76.649676] dump_stack+0x14/0x2c
[ 76.649683] __report_bad_irq+0x38/0xe8
[ 76.649695] note_interrupt+0x220/0x3a0
[ 76.649704] handle_irq_event_percpu+0x58/0x88
[ 76.649713] handle_irq_event+0x44/0xd8
[ 76.649721] handle_fasteoi_irq+0xa8/0x130
[ 76.649730] generic_handle_domain_irq+0x38/0x58
[ 76.649738] gic_handle_irq+0x9c/0xb8
[ 76.649747] call_on_irq_stack+0x28/0x38
[ 76.649755] do_interrupt_handler+0x7c/0x80
[ 76.649763] el1_interrupt+0x34/0x80
[ 76.649772] el1h_64_irq_handler+0x14/0x20
[ 76.649781] el1h_64_irq+0x74/0x78
[ 76.649788] irq_finalize_oneshot.part.56+0x68/0xf8
[ 76.649796] irq_thread_fn+0x5c/0x98
[ 76.649804] irq_thread+0x13c/0x260
[ 76.649812] kthread+0x144/0x178
[ 76.649822] ret_from_fork+0x10/0x20
[ 76.649830] handlers:
[ 76.653170] [<0000000025a6cd31>] irq_default_primary_handler threaded [<0000000093580eb7>] phy_interrupt
[ 76.661256] Disabling IRQ #36
Fixes: 1f80a5cf74a6 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator")
Signed-off-by: Lutz Koschorreck <theleks@ko-hh.de>
only gpio bank
---
arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
index 0bd1e98a0eef..ed7cd5f53046 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
@@ -48,7 +48,7 @@ tf_io: gpio-regulator-tf_io {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_5v>;
- enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
enable-active-high;
regulator-always-on;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: meson-sm1-odroid: use correct enable-gpio pin for tf-io regulator
From: Neil Armstrong @ 2022-01-27 13:09 UTC (permalink / raw)
To: Lutz Koschorreck, Rob Herring, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20220127130537.GA187347@odroid-VirtualBox>
On 27/01/2022 14:05, Lutz Koschorreck wrote:
> The interrupt pin of the external ethernet phy is used, instead of the
> enable-gpio pin of the tf-io regulator. The GPIOE_2 pin is located in
> the gpio_ao bank.
>
> This causes phy interrupt problems at system startup.
> [ 76.645190] irq 36: nobody cared (try booting with the "irqpoll" option)
> [ 76.649617] CPU: 0 PID: 1416 Comm: irq/36-0.0:00 Not tainted 5.16.0 #2
> [ 76.649629] Hardware name: Hardkernel ODROID-HC4 (DT)
> [ 76.649635] Call trace:
> [ 76.649638] dump_backtrace+0x0/0x1c8
> [ 76.649658] show_stack+0x14/0x60
> [ 76.649667] dump_stack_lvl+0x64/0x7c
> [ 76.649676] dump_stack+0x14/0x2c
> [ 76.649683] __report_bad_irq+0x38/0xe8
> [ 76.649695] note_interrupt+0x220/0x3a0
> [ 76.649704] handle_irq_event_percpu+0x58/0x88
> [ 76.649713] handle_irq_event+0x44/0xd8
> [ 76.649721] handle_fasteoi_irq+0xa8/0x130
> [ 76.649730] generic_handle_domain_irq+0x38/0x58
> [ 76.649738] gic_handle_irq+0x9c/0xb8
> [ 76.649747] call_on_irq_stack+0x28/0x38
> [ 76.649755] do_interrupt_handler+0x7c/0x80
> [ 76.649763] el1_interrupt+0x34/0x80
> [ 76.649772] el1h_64_irq_handler+0x14/0x20
> [ 76.649781] el1h_64_irq+0x74/0x78
> [ 76.649788] irq_finalize_oneshot.part.56+0x68/0xf8
> [ 76.649796] irq_thread_fn+0x5c/0x98
> [ 76.649804] irq_thread+0x13c/0x260
> [ 76.649812] kthread+0x144/0x178
> [ 76.649822] ret_from_fork+0x10/0x20
> [ 76.649830] handlers:
> [ 76.653170] [<0000000025a6cd31>] irq_default_primary_handler threaded [<0000000093580eb7>] phy_interrupt
> [ 76.661256] Disabling IRQ #36
>
> Fixes: 1f80a5cf74a6 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator")
>
> Signed-off-by: Lutz Koschorreck <theleks@ko-hh.de>
>
> only gpio bank
Spurious lines, will remove while applying
> ---
> arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> index 0bd1e98a0eef..ed7cd5f53046 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
> @@ -48,7 +48,7 @@ tf_io: gpio-regulator-tf_io {
> regulator-max-microvolt = <3300000>;
> vin-supply = <&vcc_5v>;
>
> - enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
> + enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> regulator-always-on;
>
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sc7280: Add nodes to support WoW on WCN6750
From: Manikanta Pubbisetty @ 2022-01-27 13:11 UTC (permalink / raw)
To: agross, bjorn.andersson, robh+dt
Cc: linux-arm-msm, devicetree, Manikanta Pubbisetty
Add nodes to support WoW (Wake on Wireless) feature on WCN6750
WiFi hardware.
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
---
Depends on:
- https://patchwork.kernel.org/project/linux-arm-msm/list/?series=609101
- https://patchwork.kernel.org/project/linux-wireless/list/?series=608934
arch/arm64/boot/dts/qcom/sc7280.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index bb57274..ed393ab 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -517,6 +517,17 @@
interrupt-controller;
#interrupt-cells = <2>;
};
+
+ wlan_smp2p_out: wlan-ap-to-wpss {
+ qcom,entry-name = "wlan";
+ #qcom,smem-state-cells = <1>;
+ }
+
+ wlan_smp2p_in: wlan-wpss-to-ap {
+ qcom,entry-name = "wlan";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ }
};
pmu {
@@ -1619,6 +1630,8 @@
qcom,rproc = <&remoteproc_wpss>;
memory-region = <&wlan_fw_mem &wlan_ce_mem>;
status = "disabled";
+ qcom,smem-states = <&wlan_smp2p_out 0>;
+ qcom,smem-state-names = "wlan-smp2p-out";
};
pcie1: pci@1c08000 {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed: remove unhandled fttmr010,pwm-outputs
From: Andrei Kartashev @ 2022-01-27 13:17 UTC (permalink / raw)
To: Corentin Labbe, andrew, joel, robh+dt
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20220127121952.3985981-1-clabbe@baylibre.com>
Hello,
Good catch! I miss this on porting DTS from local tree, based on
Intel's one. Since there is no such driver in upstream kernel
(https://github.com/Intel-BMC/linux/blob/dev-5.15-intel/drivers/pwm/pwm-fttmr010.c
), both this and beeper sections could be completely removed.
I will send another patch with cleanup.
Thank you.
On Thu, 2022-01-27 at 12:19 +0000, Corentin Labbe wrote:
> fttmr010,pwm-outputs is not handled by its timer driver, so this
> property is useless.
> Fixes: 67ac01d03862 ("ARM: dts: aspeed: add device tree for YADRO
> VEGMAN BMC")
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> arch/arm/boot/dts/aspeed-bmc-vegman.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
> b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
> index 1a5b25b2ea29..43af63910571 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
> +++ b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
> @@ -166,7 +166,6 @@ &sdhci1 {
> };
>
> &timer {
> - fttmr010,pwm-outputs = <5>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_timer5_default>;
> #pwm-cells = <3>;
--
Best regards,
Andrei Kartashev
^ permalink raw reply
* Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree
From: Greg KH @ 2022-01-27 13:21 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree, Andrew Lunn,
Vivien Didelot, Florian Fainelli, Vladimir Oltean
In-Reply-To: <20220127120039.GE9150@pengutronix.de>
On Thu, Jan 27, 2022 at 01:00:39PM +0100, Oleksij Rempel wrote:
> On Thu, Jan 27, 2022 at 12:30:20PM +0100, Greg KH wrote:
> > On Thu, Jan 27, 2022 at 12:23:05PM +0100, Oleksij Rempel wrote:
> > > On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> > > > On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > > > > Similar to the option to set a netdev name in device tree for switch
> > > > > ports by using the property "label" in the DSA framework, this patch
> > > > > adds this functionality to the usbnet infrastructure.
> > > > >
> > > > > This will help to name the interfaces properly throughout supported
> > > > > devices. This provides stable interface names which are useful
> > > > > especially in embedded use cases.
> > > >
> > > > Stable interface names are for userspace to set, not the kernel.
> > > >
> > > > Why would USB care about this? If you need something like this, get it
> > > > from the USB device itself, not DT, which should have nothing to do with
> > > > USB as USB is a dynamic, self-describing, bus. Unlike DT.
> > > >
> > > > So I do not think this is a good idea.
> > >
> > > This is needed for embedded devices with integrated USB Ethernet
> > > controller. Currently I have following use cases to solve:
> > > - Board with one or multiple USB Ethernet controllers with external PHY.
> > > The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
> >
> > The phy is for the USB controller, not the Ethernet controller, right?
> > If for the ethernet controller, ugh, that's a crazy design and I would
> > argue a broken one. But whatever, DT should not be used to describe a
> > USB device itself.
> >
> > > - Board with USB Ethernet controller with DSA switch. The USB ethernet
> > > controller is attached to the CPU port of DSA switch. In this case,
> > > DSA switch is the sub-node of the USB device.
> >
> > What do you mean exactly by "sub node"? USB does not have such a term.
>
> Here are some examples:
>
> - |
> usb@11270000 {
> reg = <0x11270000 0x1000>;
How can a USB device have a register?
And what does 11270000 mean?
> #address-cells = <1>;
> #size-cells = <0>;
>
> ethernet@1 {
> compatible = "usb424,ec00";
> reg = <1>;
> label = "LAN0";
Where did that come from? That should be added in userspace, not from
the kernel.
> // there is no internal eeprom, so MAC address is taken from
> // NVMEM of the SoC.
> local-mac-address = [00 00 00 00 00 00];
>
> mdio {
> ethernet-phy@4 {
> reg = <4>;
> // Interrupt is attached to the SoC or the GPIO
> // controller of the same USB devices.
> interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
> // same about reset. It is attached to the SoC
> // or GPIO controller of the USB device.
> reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
> reset-assert-us = <10000>;
> reset-deassert-us = <1000>;
> // some external clock provider
> clocks = <&clk>
> qca,smarteee-tw-us-1g = <24>;
> qca,clk-out-frequency = <125000000>;
So this device does not follow the spec for this driver in that you have
to get the values for the phy from DT and not the device itself? Why
not fix the firmware in the device to report this?
Anyway, this feels really wrong, USB should not be involved in DT by
virtue of how the bus was designed.
And again, pick your names in userspace, embedded is not "special" here.
You can do persistant network device names in a very trivial shell
script if needed, we used to do it that way 18 years ago :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support
From: Laurent Pinchart @ 2022-01-27 13:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Joerg Roedel, Will Deacon, Rob Herring,
Linux IOMMU,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas, Magnus Damm
In-Reply-To: <CAMuHMdXgg8XApJETkN1oDDSy=N01kJaTz4DADyD9ZOM0ZXXttA@mail.gmail.com>
Hi Geert,
On Thu, Jan 27, 2022 at 12:05:31PM +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 25, 2022 at 6:33 PM Yoshihiro Shimoda wrote:
> > Document the compatible values for the IPMMU-VMSA blocks in
> > the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> Thanks for your patch!
>
> > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > @@ -44,6 +44,10 @@ properties:
> > - renesas,ipmmu-r8a77990 # R-Car E3
> > - renesas,ipmmu-r8a77995 # R-Car D3
> > - renesas,ipmmu-r8a779a0 # R-Car V3U
> > + - items:
> > + - enum:
> > + - renesas,ipmmu-r8a779f0 # R-Car S4-8
> > + - const: renesas,rcar-gen4-ipmmu-vmsa # R-Car Gen4
>
> I'm wondering if we need the family-specific fallback.
> For R-Car Gen3, we don't have it, and match on (all) the SoC-specific
> compatible values instead.
> Do you remember why we decided to do it that way?
I'm afraid I don't. You know my usual opinion of SoC-specific compatible
strings :-)
> At least R-Car V3M/V3H/D3 have slight differences in the register bits,
> but I don't think that was the reason.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree
From: Lucas Stach @ 2022-01-27 14:01 UTC (permalink / raw)
To: Greg KH, Oleksij Rempel
Cc: Florian Fainelli, devicetree, linux-usb, Andrew Lunn, netdev,
Oliver Neukum, linux-kernel, Vivien Didelot, Rob Herring, kernel,
Jakub Kicinski, Vladimir Oltean, David S. Miller
In-Reply-To: <YfKcYXjfhVKUKfzY@kroah.com>
Hi Greg,
Am Donnerstag, dem 27.01.2022 um 14:21 +0100 schrieb Greg KH:
> On Thu, Jan 27, 2022 at 01:00:39PM +0100, Oleksij Rempel wrote:
> > On Thu, Jan 27, 2022 at 12:30:20PM +0100, Greg KH wrote:
> > > On Thu, Jan 27, 2022 at 12:23:05PM +0100, Oleksij Rempel wrote:
> > > > On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> > > > > On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > > > > > Similar to the option to set a netdev name in device tree for switch
> > > > > > ports by using the property "label" in the DSA framework, this patch
> > > > > > adds this functionality to the usbnet infrastructure.
> > > > > >
> > > > > > This will help to name the interfaces properly throughout supported
> > > > > > devices. This provides stable interface names which are useful
> > > > > > especially in embedded use cases.
> > > > >
> > > > > Stable interface names are for userspace to set, not the kernel.
> > > > >
> > > > > Why would USB care about this? If you need something like this, get it
> > > > > from the USB device itself, not DT, which should have nothing to do with
> > > > > USB as USB is a dynamic, self-describing, bus. Unlike DT.
> > > > >
> > > > > So I do not think this is a good idea.
> > > >
> > > > This is needed for embedded devices with integrated USB Ethernet
> > > > controller. Currently I have following use cases to solve:
> > > > - Board with one or multiple USB Ethernet controllers with external PHY.
> > > > The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
> > >
> > > The phy is for the USB controller, not the Ethernet controller, right?
> > > If for the ethernet controller, ugh, that's a crazy design and I would
> > > argue a broken one. But whatever, DT should not be used to describe a
> > > USB device itself.
> > >
> > > > - Board with USB Ethernet controller with DSA switch. The USB ethernet
> > > > controller is attached to the CPU port of DSA switch. In this case,
> > > > DSA switch is the sub-node of the USB device.
> > >
> > > What do you mean exactly by "sub node"? USB does not have such a term.
> >
> > Here are some examples:
> >
> > - |
> > usb@11270000 {
> > reg = <0x11270000 0x1000>;
>
> How can a USB device have a register?
>
> And what does 11270000 mean?
>
>
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > ethernet@1 {
> > compatible = "usb424,ec00";
> > reg = <1>;
> > label = "LAN0";
>
> Where did that come from? That should be added in userspace, not from
> the kernel.
>
> > // there is no internal eeprom, so MAC address is taken from
> > // NVMEM of the SoC.
> > local-mac-address = [00 00 00 00 00 00];
> >
> > mdio {
> > ethernet-phy@4 {
> > reg = <4>;
> > // Interrupt is attached to the SoC or the GPIO
> > // controller of the same USB devices.
> > interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
> > // same about reset. It is attached to the SoC
> > // or GPIO controller of the USB device.
> > reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
> > reset-assert-us = <10000>;
> > reset-deassert-us = <1000>;
> > // some external clock provider
> > clocks = <&clk>
> > qca,smarteee-tw-us-1g = <24>;
> > qca,clk-out-frequency = <125000000>;
>
> So this device does not follow the spec for this driver in that you have
> to get the values for the phy from DT and not the device itself? Why
> not fix the firmware in the device to report this?
>
> Anyway, this feels really wrong, USB should not be involved in DT by
> virtue of how the bus was designed.
While one can argue about the kind of information provided here, it is
well defined how DT can augment the information about a device on a
runtime discoverable bus like USB. There is even a DT binding that
lists you as the maintainer of this standard:
Documentation/devicetree/bindings/usb/usb-device.yaml
USB is not special here, PCI has the same way for DT to augment runtime
discovered device information and that is even covered by the ancient
IEEE 1275 Open Firmware standard.
Regards,
Lucas
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: convert net/cortina,gemini-ethernet to yaml
From: Rob Herring @ 2022-01-27 14:03 UTC (permalink / raw)
To: Corentin Labbe
Cc: davem, linux-arm-kernel, linux-kernel, kuba, robh+dt,
linus.walleij, devicetree, ulli.kroll, netdev
In-Reply-To: <20220126211128.3663486-1-clabbe@baylibre.com>
On Wed, 26 Jan 2022 21:11:28 +0000, Corentin Labbe wrote:
> Converts net/cortina,gemini-ethernet.txt to yaml
> This permits to detect some missing properties like interrupts
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> .../bindings/net/cortina,gemini-ethernet.txt | 92 ------------
> .../bindings/net/cortina,gemini-ethernet.yaml | 138 ++++++++++++++++++
> 2 files changed, 138 insertions(+), 92 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
> create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml: patternProperties:^ethernet-port@[0-9]+$:properties:reg: 'oneOf' conditional failed, one must be fixed:
[{'description': 'DMA/TOE memory'}, {'description': 'GMAC memory area of the port'}] is too long
[{'description': 'DMA/TOE memory'}, {'description': 'GMAC memory area of the port'}] is too short
False schema does not allow 2
1 was expected
hint: "minItems" is only needed if less than the "items" list length
from schema $id: http://devicetree.org/meta-schemas/items.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml: ignoring, error in schema: patternProperties: ^ethernet-port@[0-9]+$: properties: reg
Documentation/devicetree/bindings/net/cortina,gemini-ethernet.example.dt.yaml:0:0: /example-0/ethernet@60000000: failed to match any schema with compatible: ['cortina,gemini-ethernet']
Documentation/devicetree/bindings/net/cortina,gemini-ethernet.example.dt.yaml:0:0: /example-0/ethernet@60000000/ethernet-port@0: failed to match any schema with compatible: ['cortina,gemini-ethernet-port']
Documentation/devicetree/bindings/net/cortina,gemini-ethernet.example.dt.yaml:0:0: /example-0/ethernet@60000000/ethernet-port@1: failed to match any schema with compatible: ['cortina,gemini-ethernet-port']
doc reference errors (make refcheckdocs):
MAINTAINERS: Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
See https://patchwork.ozlabs.org/patch/1584680
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: nvmem: convert mtk-efuse.txt to YAML schema
From: Rob Herring @ 2022-01-27 14:03 UTC (permalink / raw)
To: Chunfeng Yun
Cc: linux-mediatek, linux-kernel, devicetree, Rob Herring,
linux-arm-kernel, Srinivas Kandagatla, Andrew-CT Chen,
Matthias Brugger
In-Reply-To: <20220127085930.15637-1-chunfeng.yun@mediatek.com>
On Thu, 27 Jan 2022 16:59:30 +0800, Chunfeng Yun wrote:
> Convert mtk-efuse.txt to YAML schema mediatek,efuse.yaml
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> v3: add reviewed-by Rob
>
> v2:
> 1. remove description of subnodes which is covered by nvmem.yaml suggested by Rob
> 2. change the example which is commoner than mt8173's
> ---
> .../bindings/nvmem/mediatek,efuse.yaml | 86 +++++++++++++++++++
> .../devicetree/bindings/nvmem/mtk-efuse.txt | 43 ----------
> 2 files changed, 86 insertions(+), 43 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> delete mode 100644 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/nvmem/mediatek,efuse.example.dts:25.43-28.15: Warning (unique_unit_address_if_enabled): /example-0/efuse@11c10000/usb3-tx-imp@184: duplicate unit-address (also used in node /example-0/efuse@11c10000/usb3-rx-imp@184)
Documentation/devicetree/bindings/nvmem/mediatek,efuse.example.dts:37.45-40.15: Warning (unique_unit_address_if_enabled): /example-0/efuse@11c10000/usb3-tx-imp@186: duplicate unit-address (also used in node /example-0/efuse@11c10000/usb3-rx-imp@186)
Documentation/devicetree/bindings/nvmem/mediatek,efuse.example.dts:49.42-52.15: Warning (unique_unit_address_if_enabled): /example-0/efuse@11c10000/usb2-intr-p0@188: duplicate unit-address (also used in node /example-0/efuse@11c10000/usb2-intr-p1@188)
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1584864
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH net-next v1 2/4] dt-bindings: net: add schema for Microchip/SMSC LAN95xx USB Ethernet controllers
From: Rob Herring @ 2022-01-27 14:03 UTC (permalink / raw)
To: Oleksij Rempel
Cc: netdev, Rob Herring, Oliver Neukum, linux-usb, linux-kernel,
Jakub Kicinski, kernel, devicetree, David S. Miller
In-Reply-To: <20220127104905.899341-3-o.rempel@pengutronix.de>
On Thu, 27 Jan 2022 11:49:03 +0100, Oleksij Rempel wrote:
> Create initial schema for Microchip/SMSC LAN95xx USB Ethernet controllers and
> import all currently supported USB IDs form drivers/net/usb/smsc95xx.c
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> .../bindings/net/microchip,lan95xx.yaml | 82 +++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
>
Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consider if they are expected or the schema is
incorrect. These may not be new warnings.
Note that it is not yet a requirement to have 0 warnings for dtbs_check.
This will change in the future.
Full log is available here: https://patchwork.ozlabs.org/patch/1584951
smsc@2: $nodename:0: 'smsc@2' does not match '^ethernet(@.*)?$'
arch/arm/boot/dts/tegra30-ouya.dt.yaml
usbether@1: $nodename:0: 'usbether@1' does not match '^ethernet(@.*)?$'
arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dt.yaml
arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dt.yaml
arch/arm/boot/dts/bcm2835-rpi-b.dt.yaml
arch/arm/boot/dts/bcm2835-rpi-b-plus.dt.yaml
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dt.yaml
arch/arm/boot/dts/bcm2836-rpi-2-b.dt.yaml
arch/arm/boot/dts/bcm2837-rpi-3-b.dt.yaml
arch/arm/boot/dts/omap3-beagle-xm-ab.dt.yaml
arch/arm/boot/dts/omap3-beagle-xm.dt.yaml
arch/arm/boot/dts/omap4-panda-a4.dt.yaml
arch/arm/boot/dts/omap4-panda.dt.yaml
arch/arm/boot/dts/omap4-panda-es.dt.yaml
usbether@3: $nodename:0: 'usbether@3' does not match '^ethernet(@.*)?$'
arch/arm/boot/dts/omap5-uevm.dt.yaml
^ permalink raw reply
* Re: [PATCH v5 1/2] leds: ktd20xx: Extension of the KTD20xx family of LED drivers from Kinetic
From: Andy Shevchenko @ 2022-01-27 14:06 UTC (permalink / raw)
To: Florian Eckert
Cc: Pavel Machek, Rob Herring, Eckert.Florian,
Linux Kernel Mailing List, Linux LED Subsystem, devicetree,
kernel test robot
In-Reply-To: <20220127090841.396-2-fe@dev.tdt.de>
On Thu, Jan 27, 2022 at 11:08 AM Florian Eckert <fe@dev.tdt.de> wrote:
>
> Introducing the KTD2061/58/59/60 RGB LED drivers. The difference in
> these are the address numbers on the I2C bus that the device listens to.
>
> All KT20xx units can drive up to 12 LEDs.
>
> Due to the hardware limitation, we can only set 7 colors and the color
> black (LED off) for each LED independently and not the full RGB range.
> This is because the chip only has two color registers.
>
> To control the LEDs independently, the chip has to be configured in a
> special way.
>
> Color register 0 must be loaded with the current value 0mA, and color
> register 1 must be loaded with the value 'kinetic,led-current' from the
> device tree node. If the property is omitted, the register is loaded
> with the default value (0x28 = 5mA).
>
> To select a color for an LED, a combination must be written to the color
> selection register of that LED. This range for selecting the value is 3
> bits wide (RGB). A '0' in any of the bits uses color register '0' and a
> '1' uses color register '1'.
>
> So we could choose the following combination for each LED:
> R G B
> 0 0 0 = Black (off)
> 0 0 1 = Blue
> 0 1 0 = green
> 0 1 1 = Cyan
> 1 0 0 = Red
> 1 0 1 = Magenta
> 1 1 0 = Yellow
> 1 1 1 = White
>
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
> Reported-by: kernel test robot <lkp@intel.com>
Absence of a feature can't be reported. If you wish to give credit,
use changelog for that (it's basically part of the review process).
Anyways, codewise it looks good enough, hence FWIW,
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> ---
> MAINTAINERS | 6 +
> drivers/leds/Kconfig | 12 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-ktd20xx.c | 569 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 588 insertions(+)
> create mode 100644 drivers/leds/leds-ktd20xx.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a58544f7b699..04d68985d348 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10739,6 +10739,12 @@ S: Maintained
> F: Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
> F: drivers/video/backlight/ktd253-backlight.c
>
> +KTD20XX LED CONTROLLER DRIVER
> +M: Florian Eckert <fe@dev.tdt.de>
> +L: linux-leds@vger.kernel.org
> +S: Maintained
> +F: drivers/leds/leds-ktd20xx.c
> +
> KTEST
> M: Steven Rostedt <rostedt@goodmis.org>
> M: John Hawley <warthog9@eaglescrag.net>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 6090e647daee..a96e6bf7918b 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -157,6 +157,18 @@ config LEDS_EL15203000
> To compile this driver as a module, choose M here: the module
> will be called leds-el15203000.
>
> +config LEDS_KTD20XX
> + tristate "LED Support for KTD2061/58/59/60 LED driver chip"
> + depends on LEDS_CLASS && I2C
> + depends on LEDS_CLASS_MULTICOLOR
> + select REGMAP_I2C
> + help
> + If you say yes here you get support for the Kinetic
> + KTD2061, KTD2058, KTD2059 and KTD2060 LED driver.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called leds-ktd20xx.
> +
> config LEDS_TURRIS_OMNIA
> tristate "LED support for CZ.NIC's Turris Omnia"
> depends on LEDS_CLASS_MULTICOLOR
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index e58ecb36360f..5a86e72ea722 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -34,6 +34,7 @@ obj-$(CONFIG_LEDS_IP30) += leds-ip30.o
> obj-$(CONFIG_LEDS_IPAQ_MICRO) += leds-ipaq-micro.o
> obj-$(CONFIG_LEDS_IS31FL319X) += leds-is31fl319x.o
> obj-$(CONFIG_LEDS_IS31FL32XX) += leds-is31fl32xx.o
> +obj-${CONFIG_LEDS_KTD20XX} += leds-ktd20xx.o
> obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
> obj-$(CONFIG_LEDS_LM3532) += leds-lm3532.o
> obj-$(CONFIG_LEDS_LM3533) += leds-lm3533.o
> diff --git a/drivers/leds/leds-ktd20xx.c b/drivers/leds/leds-ktd20xx.c
> new file mode 100644
> index 000000000000..be6d1e8b6d68
> --- /dev/null
> +++ b/drivers/leds/leds-ktd20xx.c
> @@ -0,0 +1,569 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * LEDs driver for the Kinetic KDT20xx device
> + *
> + * Copyright (C) 2021 TDT AG Florian Eckert <fe@dev.tdt.de>
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/leds.h>
> +#include <linux/led-class-multicolor.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/property.h>
> +#include <linux/regmap.h>
> +
> +/* I2C Register Map */
> +#define KTD20XX_ID 0x00
> +#define KTD20XX_MONITOR 0x01
> +#define KTD20XX_CONTROL 0x02
> +
> +/* Color0 Configuration Registers */
> +#define KTD20XX_IRED0 0x03
> +#define KTD20XX_IGRN0 0x04
> +#define KTD20XX_IBLU0 0x05
> +
> +/* Color1 Configuration Registers */
> +#define KTD20XX_IRED1 0x06
> +#define KTD20XX_IGRN1 0x07
> +#define KTD20XX_IBLU1 0x08
> +
> +/* Selection Configuration Register */
> +#define KTD20XX_ISELA12 0x09
> +#define KTD20XX_ISELA34 0x0A
> +#define KTD20XX_ISELB12 0x0B
> +#define KTD20XX_ISELB34 0x0C
> +#define KTD20XX_ISELC12 0x0D
> +#define KTD20XX_ISELC34 0x0E
> +
> +#define KTD20XX_MAX_LEDS 12
> +#define KTD20XX_LED_CHANNELS 3
> +
> +enum ktd20xx_led_number {
> + /* ISELA12 */
> + RGB_A1,
> + RGB_A2,
> + /* ISELA34 */
> + RGB_A3,
> + RGB_A4,
> + /* ISELB12 */
> + RGB_B1,
> + RGB_B2,
> + /* ISELB34 */
> + RGB_B3,
> + RGB_B4,
> + /* ISELC12 */
> + RGB_C1,
> + RGB_C2,
> + /* ISELC34 */
> + RGB_C3,
> + RGB_C4,
> +};
> +
> +enum ktd20xx_control_mode {
> + CONTROL_MODE_OFF,
> + CONTROL_MODE_NIGHT,
> + CONTROL_MODE_NORMAL,
> + CONTROL_MODE_RESET,
> +};
> +
> +static const struct reg_default ktd20xx_reg_defs[] = {
> + /* Color0 Configuration Registers */
> + {KTD20XX_IRED0, 0x28},
> + {KTD20XX_IGRN0, 0x28},
> + {KTD20XX_IBLU0, 0x28},
> + /* Color1 Configuration Registers */
> + {KTD20XX_IRED1, 0x60},
> + {KTD20XX_IGRN1, 0x60},
> + {KTD20XX_IBLU1, 0x60},
> + /* Selection Configuration Register */
> + {KTD20XX_ISELA12, 0x00},
> + {KTD20XX_ISELA34, 0x00},
> + {KTD20XX_ISELB12, 0x00},
> + {KTD20XX_ISELB34, 0x00},
> + {KTD20XX_ISELC12, 0x00},
> + {KTD20XX_ISELC34, 0x00},
> +};
> +
> +/* Chip values */
> +static const struct reg_field kt20xx_control_mode = REG_FIELD(KTD20XX_CONTROL, 6, 7);
> +static const struct reg_field kt20xx_faderate = REG_FIELD(KTD20XX_CONTROL, 0, 2);
> +static const struct reg_field kt20xx_vendor = REG_FIELD(KTD20XX_ID, 5, 7);
> +static const struct reg_field kt20xx_chip_id = REG_FIELD(KTD20XX_ID, 0, 4);
> +static const struct reg_field kt20xx_chip_rev = REG_FIELD(KTD20XX_MONITOR, 4, 7);
> +
> +/* ISELA1 and ISELA2 */
> +static const struct reg_field kt20xx_a1_select = REG_FIELD(KTD20XX_ISELA12, 4, 6);
> +static const struct reg_field kt20xx_a1_enable = REG_FIELD(KTD20XX_ISELA12, 7, 7);
> +static const struct reg_field kt20xx_a2_select = REG_FIELD(KTD20XX_ISELA12, 0, 2);
> +static const struct reg_field kt20xx_a2_enable = REG_FIELD(KTD20XX_ISELA12, 3, 3);
> +
> +/* ISELA3 and ISELA4 */
> +static const struct reg_field kt20xx_a3_select = REG_FIELD(KTD20XX_ISELA34, 4, 6);
> +static const struct reg_field kt20xx_a3_enable = REG_FIELD(KTD20XX_ISELA34, 7, 7);
> +static const struct reg_field kt20xx_a4_select = REG_FIELD(KTD20XX_ISELA34, 0, 2);
> +static const struct reg_field kt20xx_a4_enable = REG_FIELD(KTD20XX_ISELA34, 3, 3);
> +
> +/* ISELB1 and ISELB2 */
> +static const struct reg_field kt20xx_b1_select = REG_FIELD(KTD20XX_ISELB12, 4, 6);
> +static const struct reg_field kt20xx_b1_enable = REG_FIELD(KTD20XX_ISELB12, 7, 7);
> +static const struct reg_field kt20xx_b2_select = REG_FIELD(KTD20XX_ISELB12, 0, 2);
> +static const struct reg_field kt20xx_b2_enable = REG_FIELD(KTD20XX_ISELB12, 3, 3);
> +
> +/* ISELB3 and ISELB4 */
> +static const struct reg_field kt20xx_b3_select = REG_FIELD(KTD20XX_ISELB34, 4, 6);
> +static const struct reg_field kt20xx_b3_enable = REG_FIELD(KTD20XX_ISELB34, 7, 7);
> +static const struct reg_field kt20xx_b4_select = REG_FIELD(KTD20XX_ISELB34, 0, 2);
> +static const struct reg_field kt20xx_b4_enable = REG_FIELD(KTD20XX_ISELB34, 3, 3);
> +
> +/* ISELC1 and ISELC2 */
> +static const struct reg_field kt20xx_c1_select = REG_FIELD(KTD20XX_ISELC12, 4, 6);
> +static const struct reg_field kt20xx_c1_enable = REG_FIELD(KTD20XX_ISELC12, 7, 7);
> +static const struct reg_field kt20xx_c2_select = REG_FIELD(KTD20XX_ISELC12, 0, 2);
> +static const struct reg_field kt20xx_c2_enable = REG_FIELD(KTD20XX_ISELC12, 3, 3);
> +
> +/* ISELC3 and ISELC4 */
> +static const struct reg_field kt20xx_c3_select = REG_FIELD(KTD20XX_ISELC34, 4, 6);
> +static const struct reg_field kt20xx_c3_enable = REG_FIELD(KTD20XX_ISELC34, 7, 7);
> +static const struct reg_field kt20xx_c4_select = REG_FIELD(KTD20XX_ISELC34, 0, 2);
> +static const struct reg_field kt20xx_c4_enable = REG_FIELD(KTD20XX_ISELC34, 3, 3);
> +
> +static const struct regmap_range ktd20xx_volatile_ranges = {
> + .range_min = KTD20XX_ID,
> + .range_max = KTD20XX_CONTROL,
> +};
> +
> +static const struct regmap_access_table ktd20xx_volatile_table = {
> + .yes_ranges = &ktd20xx_volatile_ranges,
> + .n_yes_ranges = 1,
> +};
> +
> +static const struct regmap_range ktd20xx_readable_ranges = {
> + .range_min = KTD20XX_ID,
> + .range_max = KTD20XX_MONITOR,
> +};
> +
> +static const struct regmap_access_table ktd20xx_readable_table = {
> + .yes_ranges = &ktd20xx_readable_ranges,
> + .n_yes_ranges = 1,
> +};
> +
> +static const struct regmap_config ktd20xx_regmap_config = {
> + .name = "ktd20xx_regmap",
> + .reg_bits = 8,
> + .val_bits = 8,
> +
> + .max_register = KTD20XX_ISELC34,
> +
> + .volatile_table = &ktd20xx_volatile_table,
> + .rd_table = &ktd20xx_readable_table,
> +
> + .reg_defaults = ktd20xx_reg_defs,
> + .num_reg_defaults = ARRAY_SIZE(ktd20xx_reg_defs),
> + .cache_type = REGCACHE_FLAT,
> +};
> +
> +struct ktd20xx_led {
> + struct led_classdev_mc mc_cdev;
> + struct mc_subled subled_info[KTD20XX_LED_CHANNELS];
> + int index;
> + struct regmap_field *enable;
> + struct regmap_field *select;
> + struct ktd20xx *chip;
> +};
> +
> +struct ktd20xx {
> + struct mutex lock;
> + struct i2c_client *client;
> + struct regmap *regmap;
> + struct regmap_field *control_mode;
> + struct regmap_field *faderate;
> + struct regmap_field *vendor;
> + struct regmap_field *chip_id;
> + struct regmap_field *chip_rev;
> + struct ktd20xx_led leds[KTD20XX_MAX_LEDS];
> +};
> +
> +static int ktd20xx_hwinit(struct ktd20xx *chip)
> +{
> + struct device *dev = &chip->client->dev;
> + int ret;
> + unsigned int value;
> +
> + /*
> + * If the device tree property 'kinetic,led-current' is found
> + * then set this value into the color0 register as the max current
> + * for all color channel LEDs. If this property is not set then
> + * use the default value 0x28 set by the chip after a hardware reset.
> + * The hardware default value 0x28 corresponds to 5mA.
> + */
> + /* Set color1 register current value to 0x00 and therefor 0mA */
> + regmap_write(chip->regmap, KTD20XX_IRED1, 0);
> + regmap_write(chip->regmap, KTD20XX_IGRN1, 0);
> + regmap_write(chip->regmap, KTD20XX_IBLU1, 0);
> +
> + ret = device_property_read_u32(dev, "kinetic,led-current", &value);
> + if (ret) {
> + dev_warn(dev, "property 'kinetic,led-current' not found. Using default hardware value 0x28 (5mA).\n");
> + } else {
> + dev_dbg(dev, "property 'kinetic,led-current' found. Using value 0x%02x.\n",
> + value);
> + regmap_write(chip->regmap, KTD20XX_IRED0, value);
> + regmap_write(chip->regmap, KTD20XX_IGRN0, value);
> + regmap_write(chip->regmap, KTD20XX_IBLU0, value);
> + }
> +
> + /* Enable chip to run in 'normal mode' */
> + regmap_field_write(chip->control_mode, CONTROL_MODE_NORMAL);
> +
> + return 0;
> +}
> +
> +static struct ktd20xx_led *mcled_cdev_to_led(struct led_classdev_mc *mc_cdev)
> +{
> + return container_of(mc_cdev, struct ktd20xx_led, mc_cdev);
> +}
> +
> +static int ktd20xx_brightness_set(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
> + struct ktd20xx_led *led = mcled_cdev_to_led(mc_dev);
> + struct device *dev = &led->chip->client->dev;
> + unsigned long rgb = 0;
> + int ret;
> + int i;
> +
> + mutex_lock(&led->chip->lock);
> + ret = regmap_field_write(led->enable, brightness ? 1 : 0);
> + if (ret) {
> + dev_err(dev, "Cannot set enable flag of LED %d error: %d\n",
> + led->index, ret);
> + goto out_unlock;
> + }
> +
> + for (i = 0; i < led->mc_cdev.num_colors; i++) {
> + unsigned int intensity = mc_dev->subled_info[i].intensity;
> + unsigned int channel = mc_dev->subled_info[i].channel;
> +
> + if (intensity > 0)
> + __set_bit(channel, &rgb);
> + }
> +
> + /*
> + * To use the color0 registers as default value after a hardware
> + * reset, we have to invert the rgb channel selection.
> + */
> + ret = regmap_field_write(led->select, ~rgb);
> + if (ret) {
> + dev_err(dev, "Can not set RGB for LED %d error: %d\n",
> + led->index, ret);
> + goto out_unlock;
> + }
> +
> +out_unlock:
> + mutex_unlock(&led->chip->lock);
> + return ret;
> +}
> +
> +static int ktd20xx_probe_dt(struct ktd20xx *chip)
> +{
> + struct device *dev = &chip->client->dev;
> + struct led_init_data init_data = {};
> + struct fwnode_handle *child = NULL;
> + struct led_classdev *led_cdev;
> + struct ktd20xx_led *led;
> + int color;
> + int i = 0;
> + int ret;
> +
> + device_for_each_child_node(dev, child) {
> + led = &chip->leds[i];
> +
> + ret = fwnode_property_read_u32(child, "reg", &led->index);
> + if (ret) {
> + dev_err(dev, "missing property 'reg'\n");
> + goto child_out;
> + }
> + if (led->index >= KTD20XX_MAX_LEDS) {
> + dev_warn(dev, "property 'reg' is greater then '%i'\n",
> + KTD20XX_MAX_LEDS);
> + ret = -EINVAL;
> + goto child_out;
> + }
> +
> + ret = fwnode_property_read_u32(child, "color", &color);
> + if (ret) {
> + dev_err(dev, "missing property 'color'\n");
> + goto child_out;
> + }
> + if (color != LED_COLOR_ID_MULTI) {
> + dev_warn(dev, "property 'color' is not equal to the value 'LED_COLOR_ID_MULTI'\n");
> + ret = -EINVAL;
> + goto child_out;
> + }
> +
> + led->subled_info[0].color_index = LED_COLOR_ID_RED;
> + led->subled_info[0].channel = 2;
> + led->subled_info[0].intensity = 1;
> + led->subled_info[1].color_index = LED_COLOR_ID_GREEN;
> + led->subled_info[1].channel = 1;
> + led->subled_info[1].intensity = 1;
> + led->subled_info[2].color_index = LED_COLOR_ID_BLUE;
> + led->subled_info[2].channel = 0;
> + led->subled_info[2].intensity = 1;
> +
> + led->mc_cdev.subled_info = led->subled_info;
> + led->mc_cdev.num_colors = KTD20XX_LED_CHANNELS;
> +
> + init_data.fwnode = child;
> +
> + led->chip = chip;
> + led_cdev = &led->mc_cdev.led_cdev;
> + led_cdev->brightness_set_blocking = ktd20xx_brightness_set;
> +
> + switch (led->index) {
> + case RGB_A1:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a1_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a1_enable);
> + break;
> + case RGB_A2:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a2_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a2_enable);
> + break;
> + case RGB_A3:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a3_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a3_enable);
> + break;
> + case RGB_A4:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a4_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_a4_enable);
> + break;
> + case RGB_B1:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b1_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b1_enable);
> + break;
> + case RGB_B2:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b2_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b2_enable);
> + break;
> + case RGB_B3:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b3_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b3_enable);
> + break;
> + case RGB_B4:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b4_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_b4_enable);
> + break;
> + case RGB_C1:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c1_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c1_enable);
> + break;
> + case RGB_C2:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c2_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c2_enable);
> + break;
> + case RGB_C3:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c3_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c3_enable);
> + break;
> + case RGB_C4:
> + led->select = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c4_select);
> + led->enable = devm_regmap_field_alloc(dev,
> + chip->regmap, kt20xx_c4_enable);
> + break;
> + }
> +
> + ret = devm_led_classdev_multicolor_register_ext(dev,
> + &led->mc_cdev,
> + &init_data);
> +
> + if (ret) {
> + dev_err(dev, "led register err: %d\n", ret);
> + goto child_out;
> + }
> +
> + i++;
> + }
> +
> + return 0;
> +
> +child_out:
> + fwnode_handle_put(child);
> + return ret;
> +}
> +
> +/*
> + * The chip also offers the option "Night Mode".
> + * All LED current settings are divided by 16 for a 0 to 1.5mA current
> + * setting range.
> + */
> +static ssize_t nightmode_show(struct device *dev, struct device_attribute *a,
> + char *buf)
> +{
> + struct ktd20xx *chip = dev_get_drvdata(dev);
> + unsigned int value;
> +
> + mutex_lock(&chip->lock);
> + regmap_field_read(chip->control_mode, &value);
> + mutex_unlock(&chip->lock);
> +
> + return sysfs_emit(buf, "%d\n", value == CONTROL_MODE_NIGHT ? 1 : 0);
> +}
> +
> +static ssize_t nightmode_store(struct device *dev, struct device_attribute *a,
> + const char *buf, size_t count)
> +{
> + struct ktd20xx *chip = dev_get_drvdata(dev);
> + bool value;
> + int ret;
> +
> + ret = kstrtobool(buf, &value);
> + if (ret)
> + return ret;
> +
> + mutex_lock(&chip->lock);
> + ret = regmap_field_write(chip->control_mode,
> + value == 1 ? CONTROL_MODE_NIGHT : CONTROL_MODE_NORMAL);
> + mutex_unlock(&chip->lock);
> +
> + if (ret)
> + return ret;
> +
> + return count;
> +}
> +static DEVICE_ATTR_RW(nightmode);
> +
> +static struct attribute *ktd20xx_led_controller_attrs[] = {
> + &dev_attr_nightmode.attr,
> + NULL
> +};
> +ATTRIBUTE_GROUPS(ktd20xx_led_controller);
> +
> +static int ktd20xx_probe(struct i2c_client *client)
> +{
> + unsigned int chip_rev;
> + struct ktd20xx *chip;
> + unsigned int chip_id;
> + unsigned int vendor;
> + struct device *dev;
> + int ret;
> +
> + chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
> + if (!chip)
> + return -ENOMEM;
> +
> + mutex_init(&chip->lock);
> + chip->client = client;
> + dev = &client->dev;
> + i2c_set_clientdata(client, chip);
> +
> + chip->regmap = devm_regmap_init_i2c(client, &ktd20xx_regmap_config);
> + if (IS_ERR(chip->regmap)) {
> + return dev_err_probe(dev, PTR_ERR(chip->regmap),
> + "Failed to allocate register map\n");
> + }
> +
> + chip->control_mode = devm_regmap_field_alloc(dev, chip->regmap,
> + kt20xx_control_mode);
> + chip->faderate = devm_regmap_field_alloc(dev, chip->regmap,
> + kt20xx_faderate);
> + chip->vendor = devm_regmap_field_alloc(dev, chip->regmap,
> + kt20xx_vendor);
> + chip->chip_id = devm_regmap_field_alloc(dev, chip->regmap,
> + kt20xx_chip_id);
> + chip->chip_rev = devm_regmap_field_alloc(dev, chip->regmap,
> + kt20xx_chip_rev);
> +
> + /* Reset all registers to hardware device default settings */
> + regmap_field_write(chip->control_mode, CONTROL_MODE_RESET);
> +
> + ret = regmap_field_read(chip->vendor, &vendor);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to read vendor\n");
> +
> + ret = regmap_field_read(chip->chip_id, &chip_id);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to read chip id\n");
> +
> + ret = regmap_field_read(chip->chip_rev, &chip_rev);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to read chip rev\n");
> +
> + dev_dbg(dev, "vendor: 0x%02x chip-id: 0x%02x chip-rev: 0x%02x\n",
> + vendor, chip_id, chip_rev);
> +
> + ret = ktd20xx_probe_dt(chip);
> + if (ret)
> + return ret;
> +
> + ret = ktd20xx_hwinit(chip);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int ktd20xx_remove(struct i2c_client *client)
> +{
> + struct ktd20xx *chip = i2c_get_clientdata(client);
> +
> + mutex_lock(&chip->lock);
> + regmap_field_write(chip->control_mode, CONTROL_MODE_OFF);
> + mutex_unlock(&chip->lock);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id ktd20xx_id[] = {
> + { "ktd20xx", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, ktd20xx_id);
> +
> +static const struct of_device_id of_ktd20xx_leds_match[] = {
> + { .compatible = "kinetic,ktd20xx", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, of_ktd20xx_leds_match);
> +
> +static struct i2c_driver ktd20xx_driver = {
> + .driver = {
> + .name = "ktd20xx",
> + .dev_groups = ktd20xx_led_controller_groups,
> + .of_match_table = of_ktd20xx_leds_match,
> + },
> + .probe_new = ktd20xx_probe,
> + .remove = ktd20xx_remove,
> + .id_table = ktd20xx_id,
> +};
> +module_i2c_driver(ktd20xx_driver);
> +
> +MODULE_DESCRIPTION("Kinetic KTD20xx LED driver");
> +MODULE_AUTHOR("Florian Eckert <fe@dev.tdt.de>");
> +MODULE_LICENSE("GPL v2");
> --
> 2.20.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 2/2] clk: imx: Remove audio_mclk_root_clk
From: Abel Vesa @ 2022-01-27 14:10 UTC (permalink / raw)
To: Stephen Boyd, Rob Herring, Shawn Guo, Sascha Hauer,
Mike Turquette
Cc: Pengutronix Kernel Team, Peng Fan, Fabio Estevam, NXP Linux Team,
Frank Li, devicetree, linux-arm-kernel, Linux Kernel Mailing List,
linux-clk, David Wolfe
In-Reply-To: <20220127141052.1900174-1-abel.vesa@nxp.com>
The audio_mclk_root_clk was added as a gate with the CCGR121 (0x4790),
but according to the reference manual, there is no such gate. The
CCGR121 belongs to ECSPI2 and it is not shared.
Fixes: 8f6d8094b215b57 ("ARM: imx: add imx7d clk tree support")
Reported-by: David Wolfe <david.wolfe@nxp.com>
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
---
drivers/clk/imx/clk-imx7d.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index c4e0f1c07192..3f6fd7ef2a68 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -849,7 +849,6 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
hws[IMX7D_WDOG4_ROOT_CLK] = imx_clk_hw_gate4("wdog4_root_clk", "wdog_post_div", base + 0x49f0, 0);
hws[IMX7D_KPP_ROOT_CLK] = imx_clk_hw_gate4("kpp_root_clk", "ipg_root_clk", base + 0x4aa0, 0);
hws[IMX7D_CSI_MCLK_ROOT_CLK] = imx_clk_hw_gate4("csi_mclk_root_clk", "csi_mclk_post_div", base + 0x4490, 0);
- hws[IMX7D_AUDIO_MCLK_ROOT_CLK] = imx_clk_hw_gate4("audio_mclk_root_clk", "audio_mclk_post_div", base + 0x4790, 0);
hws[IMX7D_WRCLK_ROOT_CLK] = imx_clk_hw_gate4("wrclk_root_clk", "wrclk_post_div", base + 0x47a0, 0);
hws[IMX7D_USB_CTRL_CLK] = imx_clk_hw_gate4("usb_ctrl_clk", "ahb_root_clk", base + 0x4680, 0);
hws[IMX7D_USB_PHY1_CLK] = imx_clk_hw_gate4("usb_phy1_clk", "pll_usb1_main_clk", base + 0x46a0, 0);
--
2.31.1
^ permalink raw reply related
* [PATCH 1/2] arm: dts: imx7: Use audio_mclk_post_div instead audio_mclk_root_clk
From: Abel Vesa @ 2022-01-27 14:10 UTC (permalink / raw)
To: Stephen Boyd, Rob Herring, Shawn Guo, Sascha Hauer,
Mike Turquette
Cc: Pengutronix Kernel Team, Peng Fan, Fabio Estevam, NXP Linux Team,
Frank Li, devicetree, linux-arm-kernel, Linux Kernel Mailing List,
linux-clk
The audio_mclk_root_clk was added as a gate with the CCGR121 (0x4790),
but according to the reference manual, there is no such gate. Moreover,
the consumer driver of the mentioned clock might gate it and leave
the ECSPI2 (the true owner of that gate) hanging. So lets use the
audio_mclk_post_div, which is the parent.
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 4 ++--
arch/arm/boot/dts/imx7-mba7.dtsi | 2 +-
arch/arm/boot/dts/imx7d-nitrogen7.dts | 2 +-
arch/arm/boot/dts/imx7d-pico-hobbit.dts | 4 ++--
arch/arm/boot/dts/imx7d-pico-pi.dts | 4 ++--
arch/arm/boot/dts/imx7d-sdb.dts | 4 ++--
arch/arm/boot/dts/imx7s-warp.dts | 4 ++--
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 62b771c1d5a9..f1c60b0cb143 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -40,7 +40,7 @@ simple-audio-card,cpu {
dailink_master: simple-audio-card,codec {
sound-dai = <&codec>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
};
};
};
@@ -293,7 +293,7 @@ codec: sgtl5000@a {
compatible = "fsl,sgtl5000";
#sound-dai-cells = <0>;
reg = <0x0a>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sai1_mclk>;
VDDA-supply = <®_module_3v3_avdd>;
diff --git a/arch/arm/boot/dts/imx7-mba7.dtsi b/arch/arm/boot/dts/imx7-mba7.dtsi
index 49086c6b6a0a..3df6dff7734a 100644
--- a/arch/arm/boot/dts/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/imx7-mba7.dtsi
@@ -302,7 +302,7 @@ &i2c2 {
tlv320aic32x4: audio-codec@18 {
compatible = "ti,tlv320aic32x4";
reg = <0x18>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
clock-names = "mclk";
ldoin-supply = <®_audio_3v3>;
iov-supply = <®_audio_3v3>;
diff --git a/arch/arm/boot/dts/imx7d-nitrogen7.dts b/arch/arm/boot/dts/imx7d-nitrogen7.dts
index e0751e6ba3c0..a31de900139d 100644
--- a/arch/arm/boot/dts/imx7d-nitrogen7.dts
+++ b/arch/arm/boot/dts/imx7d-nitrogen7.dts
@@ -288,7 +288,7 @@ &i2c4 {
codec: wm8960@1a {
compatible = "wlf,wm8960";
reg = <0x1a>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
clock-names = "mclk";
wlf,shared-lrclk;
};
diff --git a/arch/arm/boot/dts/imx7d-pico-hobbit.dts b/arch/arm/boot/dts/imx7d-pico-hobbit.dts
index 7b2198a9372c..d917dc4f2f22 100644
--- a/arch/arm/boot/dts/imx7d-pico-hobbit.dts
+++ b/arch/arm/boot/dts/imx7d-pico-hobbit.dts
@@ -31,7 +31,7 @@ simple-audio-card,cpu {
dailink_master: simple-audio-card,codec {
sound-dai = <&sgtl5000>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
};
};
};
@@ -41,7 +41,7 @@ sgtl5000: codec@a {
#sound-dai-cells = <0>;
reg = <0x0a>;
compatible = "fsl,sgtl5000";
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
VDDA-supply = <®_2p5v>;
VDDIO-supply = <®_vref_1v8>;
};
diff --git a/arch/arm/boot/dts/imx7d-pico-pi.dts b/arch/arm/boot/dts/imx7d-pico-pi.dts
index 70bea95c06d8..f263e391e24c 100644
--- a/arch/arm/boot/dts/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/imx7d-pico-pi.dts
@@ -31,7 +31,7 @@ simple-audio-card,cpu {
dailink_master: simple-audio-card,codec {
sound-dai = <&sgtl5000>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
};
};
};
@@ -41,7 +41,7 @@ sgtl5000: codec@a {
#sound-dai-cells = <0>;
reg = <0x0a>;
compatible = "fsl,sgtl5000";
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
VDDA-supply = <®_2p5v>;
VDDIO-supply = <®_vref_1v8>;
};
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 7813ef960f6e..f053f5122741 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -385,14 +385,14 @@ &i2c4 {
codec: wm8960@1a {
compatible = "wlf,wm8960";
reg = <0x1a>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
clock-names = "mclk";
wlf,shared-lrclk;
wlf,hp-cfg = <2 2 3>;
wlf,gpio-cfg = <1 3>;
assigned-clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_SRC>,
<&clks IMX7D_PLL_AUDIO_POST_DIV>,
- <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
assigned-clock-parents = <&clks IMX7D_PLL_AUDIO_POST_DIV>;
assigned-clock-rates = <0>, <884736000>, <12288000>;
};
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 4f1edef06c92..e8734d218b9d 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -75,7 +75,7 @@ simple-audio-card,cpu {
dailink_master: simple-audio-card,codec {
sound-dai = <&codec>;
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
};
};
};
@@ -232,7 +232,7 @@ codec: sgtl5000@a {
#sound-dai-cells = <0>;
reg = <0x0a>;
compatible = "fsl,sgtl5000";
- clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_DIV>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sai1_mclk>;
VDDA-supply = <&vgen4_reg>;
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v4 00/27] drm/rockchip: RK356x VOP2 support
From: Michael Riesch @ 2022-01-27 14:16 UTC (permalink / raw)
To: Sascha Hauer, dri-devel
Cc: linux-arm-kernel, linux-rockchip, devicetree, kernel, Andy Yan,
Benjamin Gaignard, Sandy Huang, Heiko Stübner, Peter Geis
In-Reply-To: <20220126145549.617165-1-s.hauer@pengutronix.de>
Hello Sascha,
On 1/26/22 15:55, Sascha Hauer wrote:
> This is v4 of adding RK356x VOP2 support. Due to popular demand I added
> a changelog to each patch, at least starting with changes to v3, I
> didn't care to add the older changes as well. I hopefully integrated all
> feedback I received to v3. Additionally I added some patches to the HDMI
> driver to support resolutions up to 4k@60Hz. The patches are mostly
> taken from the downstream kernel. Some have been send to public lists,
> but were never applied upstream for reasons I do not know. The patches
> are a bit more intrusive than needed for my case, but are present in the
> downstream kernel for a long time, so I decided just to take them
> instead of stripping them down to my needs. With these patches I
> successfully used the driver with 4k@30Hz. 4k@60Hz doesn't work for me,
> I hope this is due to my low quality cable.
The cable might be the issue indeed, at least in my tests 4k@60Hz worked
just fine. On a RK3568 EVB1, using
$ modetest -M rockchip -s 69:{1920x1080,3840x2160}-{30,60}
and a HP 27f 4K monitor:
Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
Thanks for your work and best regards,
Michael
>
> Sascha
>
> Changes since v3:
> - added changelog to each patch
> - Add 4k support to hdmi driver
> - rebase on v5.17-rc1
>
> Changes since v2:
> - Add pin names to HDMI supply pin description
> - Add hclk support to HDMI driver
> - Dual license rockchip-vop2 binding, update binding
> - Add HDMI connector to board dts files
> - drop unnecessary gamma_lut registers from vop2
> - Update dclk_vop[012] clock handling, no longer hacks needed
> - Complete regmap conversion
>
> Changes since v1:
> - drop all unnecessary waiting for frames within atomic modeset and plane update
> - Cluster subwin support removed
> - gamma support removed
> - unnecessary irq_lock removed
> - interrupt handling simplified
> - simplified zpos handling
> - drop is_alpha_support(), use fb->format->has_alpha instead
> - use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi regulators
> - Use fixed number of planes per video port
> - Drop homegrown regmap code from vop2 driver (not complete yet)
> - Add separate include file for vop2 driver to not pollute the vop include
>
> Andy Yan (1):
> drm: rockchip: Add VOP2 driver
>
> Benjamin Gaignard (1):
> dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568
> HDMI
>
> Douglas Anderson (2):
> drm/rockchip: dw_hdmi: Use auto-generated tables
> drm/rockchip: dw_hdmi: Set cur_ctr to 0 always
>
> Michael Riesch (1):
> arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a
>
> Nickey Yang (1):
> drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz
>
> Sascha Hauer (21):
> drm/encoder: Add of_graph port to struct drm_encoder
> drm/rockchip: dw_hdmi: Do not leave clock enabled in error case
> drm/rockchip: dw_hdmi: rename vpll clock to reference clock
> drm/rockchip: dw_hdmi: add rk3568 support
> drm/rockchip: dw_hdmi: add regulator support
> drm/rockchip: dw_hdmi: Add support for hclk
> drm/rockchip: dw_hdmi: drop mode_valid hook
> clk: rockchip: rk3568: Add more PLL rates
> dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional
> dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name
> dt-bindings: display: rockchip: dw-hdmi: Add regulator support
> dt-bindings: display: rockchip: dw-hdmi: Add additional clock
> dt-bindings: display: rockchip: Add binding for VOP2
> arm64: dts: rockchip: rk3399: reorder hmdi clocks
> arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'
> arm64: dts: rockchip: rk356x: Add VOP2 nodes
> arm64: dts: rockchip: rk356x: Add HDMI nodes
> arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi
> clk: rk3568: drop CLK_SET_RATE_PARENT from dclk_vop*
> clk: rk3568: Add CLK_SET_RATE_PARENT to the HDMI reference clock
> drm/rockchip: Make VOP driver optional
>
> .../display/rockchip/rockchip,dw-hdmi.yaml | 29 +-
> .../display/rockchip/rockchip-vop2.yaml | 146 +
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +-
> .../boot/dts/rockchip/rk3566-quartz64-a.dts | 48 +
> arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 +
> .../boot/dts/rockchip/rk3568-evb1-v10.dts | 48 +
> arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 +
> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 86 +
> drivers/clk/rockchip/clk-rk3568.c | 14 +-
> drivers/gpu/drm/rockchip/Kconfig | 14 +
> drivers/gpu/drm/rockchip/Makefile | 4 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 293 +-
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +-
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 7 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 15 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2665 +++++++++++++++++
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 480 +++
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 285 ++
> include/drm/drm_encoder.h | 2 +
> include/dt-bindings/soc/rockchip,vop2.h | 14 +
> 21 files changed, 4039 insertions(+), 130 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> create mode 100644 include/dt-bindings/soc/rockchip,vop2.h
>
^ permalink raw reply
* [PATCH v2] ARM: dts: aspeed: vegman: remove beeper
From: Andrei Kartashev @ 2022-01-27 14:16 UTC (permalink / raw)
To: andrew, joel, robh+dt
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Corentin Labbe
Beeper definition is a leftover from internal fork and not actual for
upstream kernel. It could be removed both beeper node and corresponded
timer node.
Fixes: 67ac01d03862 ("ARM: dts: aspeed: add device tree for YADRO VEGMAN BMC")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Andrei Kartashev <a.kartashev@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-vegman.dtsi | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
index 1a5b25b2ea29..8ee4e6aab40e 100644
--- a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
+++ b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
@@ -79,11 +79,6 @@ power_ok {
gpios = <&gpio ASPEED_GPIO(AA, 5) GPIO_ACTIVE_LOW>;
};
};
-
- beeper {
- compatible = "pwm-beeper";
- pwms = <&timer 5 1000000 0>;
- };
};
&fmc {
@@ -165,14 +160,6 @@ &sdhci1 {
disable-wp;
};
-&timer {
- fttmr010,pwm-outputs = <5>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_timer5_default>;
- #pwm-cells = <3>;
- status = "okay";
-};
-
&uart1 {
status = "okay";
pinctrl-names = "default";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] dt-bindings: panel: Introduce a panel-lvds binding
From: Maxime Ripard @ 2022-01-27 14:22 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Thierry Reding, Sam Ravnborg, Daniel Vetter, David Airlie,
Rob Herring, Frank Rowand, devicetree, dri-devel, Rob Herring
In-Reply-To: <Yd2Ahn3+FVv/Aks7@pendragon.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
Hi Laurent,
On Tue, Jan 11, 2022 at 03:05:10PM +0200, Laurent Pinchart wrote:
> On Tue, Jan 11, 2022 at 12:06:35PM +0100, Maxime Ripard wrote:
> > Following the previous patch, let's introduce a generic panel-lvds
> > binding that documents the panels that don't have any particular
> > constraint documented.
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >
> > ---
> >
> > Changes from v2:
> > - Added a MAINTAINERS entry
> >
> > Changes from v1:
> > - Added missing compatible
> > - Fixed lint
> > ---
> > .../bindings/display/panel/panel-lvds.yaml | 57 +++++++++++++++++++
> > MAINTAINERS | 1 +
> > 2 files changed, 58 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> > new file mode 100644
> > index 000000000000..fcc50db6a812
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> > @@ -0,0 +1,57 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/panel-lvds.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Generic LVDS Display Panel Device Tree Bindings
> > +
> > +maintainers:
> > + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > + - Thierry Reding <thierry.reding@gmail.com>
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > + - $ref: /schemas/display/lvds.yaml/#
> > +
> > +select:
> > + properties:
> > + compatible:
> > + contains:
> > + const: panel-lvds
> > +
> > + not:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - advantech,idk-1110wr
> > + - advantech,idk-2121wr
> > + - innolux,ee101ia-01d
> > + - mitsubishi,aa104xd12
> > + - mitsubishi,aa121td01
> > + - sgd,gktw70sdae4se
>
> I still don't like this :-( Couldn't we instead do
>
> select:
> properties:
> compatible:
> contains:
> enum:
> - auo,b101ew05
> - tbs,a711-panel
>
> ?
That works too, I'll send another version.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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