* [PATCH v2 2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013)
From: Stanislav Jakubek @ 2024-03-26 12:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
In-Reply-To: <32c507337ab80c550fb1df08f7014d1e31eb4c32.1711454680.git.stano.jakubek@gmail.com>
Add a device tree for the Motorola Moto G (2013) smartphone based
on the Qualcomm MSM8226 SoC.
Initially supported features:
- Buttons (Volume Down/Up, Power)
- eMMC
- Hall Effect Sensor
- SimpleFB display
- TMP108 temperature sensor
- Vibrator
Note: the dhob and shob reserved-memory regions are seemingly a part of some
Motorola specific (firmware?) mechanism, see [1].
[1] https://github.com/LineageOS/android_kernel_motorola_msm8226/blob/cm-14.1/Documentation/devicetree/bindings/misc/hob_ram.txt
Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
---
Changes in V2:
- split hob-ram reserved-memory region into dhob and shob
- add a note and a link to downstream documentation with more
information about these regions
arch/arm/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/msm8226-motorola-falcon.dts | 359 ++++++++++++++++++
2 files changed, 360 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index 6478a39b3be5..3eacbf5c0785 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_QCOM) += \
+ msm8226-motorola-falcon.dtb \
qcom-apq8016-sbc.dtb \
qcom-apq8026-asus-sparrow.dtb \
qcom-apq8026-huawei-sturgeon.dtb \
diff --git a/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts b/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
new file mode 100644
index 000000000000..029e1b1659c9
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
@@ -0,0 +1,359 @@
+// SPDX-License-Identifier: BSD-3-Clause
+
+/dts-v1/;
+
+#include "qcom-msm8226.dtsi"
+#include "pm8226.dtsi"
+
+/delete-node/ &smem_region;
+
+/ {
+ model = "Motorola Moto G (2013)";
+ compatible = "motorola,falcon", "qcom,msm8226";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = &sdhc_1;
+ };
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@3200000 {
+ compatible = "simple-framebuffer";
+ reg = <0x03200000 0x800000>;
+ width = <720>;
+ height = <1280>;
+ stride = <(720 * 3)>;
+ format = "r8g8b8";
+ vsp-supply = <®_lcd_pos>;
+ vsn-supply = <®_lcd_neg>;
+ vddio-supply = <&vddio_disp_vreg>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ event-hall-sensor {
+ label = "Hall Effect Sensor";
+ gpios = <&tlmm 51 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ linux,can-disable;
+ };
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&tlmm 106 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ debounce-interval = <15>;
+ };
+ };
+
+ vddio_disp_vreg: regulator-vddio-disp {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio_disp";
+ gpio = <&tlmm 34 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&pm8226_l8>;
+ startup-delay-us = <300>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@3200000 {
+ reg = <0x03200000 0x800000>;
+ no-map;
+ };
+
+ dhob@f500000 {
+ reg = <0x0f500000 0x40000>;
+ no-map;
+ };
+
+ shob@f540000 {
+ reg = <0x0f540000 0x2000>;
+ no-map;
+ };
+
+ smem_region: smem@fa00000 {
+ reg = <0x0fa00000 0x100000>;
+ no-map;
+ };
+
+ /* Actually <0x0fa00000 0x500000>, but first 100000 is smem */
+ reserved@fb00000 {
+ reg = <0x0fb00000 0x400000>;
+ no-map;
+ };
+ };
+};
+
+&blsp1_i2c3 {
+ status = "okay";
+
+ regulator@3e {
+ compatible = "ti,tps65132";
+ reg = <0x3e>;
+ pinctrl-0 = <®_lcd_default>;
+ pinctrl-names = "default";
+
+ reg_lcd_pos: outp {
+ regulator-name = "outp";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <6000000>;
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ enable-gpios = <&tlmm 31 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_lcd_neg: outn {
+ regulator-name = "outn";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <6000000>;
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ enable-gpios = <&tlmm 33 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp108";
+ reg = <0x48>;
+ interrupts-extended = <&tlmm 13 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&temp_alert_default>;
+ pinctrl-names = "default";
+ #thermal-sensor-cells = <0>;
+ };
+};
+
+&pm8226_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+ status = "okay";
+};
+
+&pm8226_vib {
+ status = "okay";
+};
+
+&rpm_requests {
+ regulators {
+ compatible = "qcom,rpm-pm8226-regulators";
+
+ pm8226_s3: s3 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ };
+
+ pm8226_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2200000>;
+ };
+
+ pm8226_s5: s5 {
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1150000>;
+ };
+
+ pm8226_l1: l1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+
+ pm8226_l2: l2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l3: l3 {
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1337500>;
+ };
+
+ pm8226_l4: l4 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l5: l5 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l6: l6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allow-set-load;
+ };
+
+ pm8226_l7: l7 {
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1850000>;
+ };
+
+ pm8226_l8: l8 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l9: l9 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+
+ pm8226_l10: l10 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l12: l12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l14: l14 {
+ regulator-min-microvolt = <2750000>;
+ regulator-max-microvolt = <2750000>;
+ };
+
+ pm8226_l15: l15 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ pm8226_l16: l16 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3350000>;
+ };
+
+ pm8226_l17: l17 {
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l18: l18 {
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l19: l19 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ };
+
+ pm8226_l20: l20 {
+ regulator-min-microvolt = <3075000>;
+ regulator-max-microvolt = <3075000>;
+ };
+
+ pm8226_l21: l21 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ regulator-allow-set-load;
+ };
+
+ pm8226_l22: l22 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l23: l23 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l24: l24 {
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <1350000>;
+ };
+
+ pm8226_l25: l25 {
+ regulator-min-microvolt = <1775000>;
+ regulator-max-microvolt = <2125000>;
+ };
+
+ pm8226_l26: l26 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+
+ pm8226_l27: l27 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+
+ pm8226_l28: l28 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ };
+
+ pm8226_lvs1: lvs1 {
+ regulator-always-on;
+ };
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&pm8226_l17>;
+ vqmmc-supply = <&pm8226_l6>;
+
+ bus-width = <8>;
+ non-removable;
+
+ status = "okay";
+};
+
+&smbb {
+ qcom,fast-charge-safe-current = <2000000>;
+ qcom,fast-charge-current-limit = <1900000>;
+ qcom,fast-charge-safe-voltage = <4400000>;
+ qcom,minimum-input-voltage = <4300000>;
+
+ status = "okay";
+};
+
+&tlmm {
+ reg_lcd_default: reg-lcd-default-state {
+ pins = "gpio31", "gpio33";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ reg_vddio_disp_default: reg-vddio-disp-default-state {
+ pins = "gpio34";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ temp_alert_default: temp-alert-default-state {
+ pins = "gpio13";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-disable;
+ };
+};
+
+&usb {
+ extcon = <&smbb>;
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usb_hs_phy {
+ extcon = <&smbb>;
+ v1p8-supply = <&pm8226_l10>;
+ v3p3-supply = <&pm8226_l20>;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
From: Stanislav Jakubek @ 2024-03-26 12:10 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
Document the Motorola Moto G (2013), which is a smartphone based
on the Qualcomm MSM8226 SoC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
---
Changes in V2:
- collect Krzysztof's A-b
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 66beaac60e1d..d2910982ae86 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -137,6 +137,7 @@ properties:
- microsoft,dempsey
- microsoft,makepeace
- microsoft,moneypenny
+ - motorola,falcon
- samsung,s3ve3g
- const: qcom,msm8226
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for CV18XX/SG200X series SoC
From: Inochi Amaoto @ 2024-03-26 12:06 UTC (permalink / raw)
To: Krzysztof Kozlowski, Inochi Amaoto, Vinod Koul, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen Wang, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <1525c377-af73-4204-8a2b-983c6d99316c@linaro.org>
On Tue, Mar 26, 2024 at 12:50:33PM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 12:41, Inochi Amaoto wrote:
> >>>
> >>> The driver does use this file.
> >>
> >> I checked and could not find. Please point me to specific parts of the code.
> >>
> >
> > In cv1800_dmamux_route_allocate.
> >> + regmap_set_bits(dmamux->regmap,
> >> + DMAMUX_CH_REG(chid),
> >> + DMAMUX_CH_SET(chid, devid));
> >> +
> >> + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
> >> + DMAMUX_INT_CH_MASK(chid, cpuid),
> >> + DMAMUX_INT_CH_BIT(chid, cpuid));
> >
> > I think this is.
>
> So where exactly? I don't see any define being used here.
> CV1800_SDMA_DMA_INT_MUX is not in your header. DMAMUX_ is not in your
> header. So what are you pointing?
>
> I don't understand this communication. Are you mocking me here or what?
> It's waste of my time.
>
I apologize for my misunderstanding and your wasted time. I had
previously thought that hardware constants is also binding. This
leads to a weird communication between us. Since I agree and
understand this file is not a binding, I will remove this file in
the next version. Anyway, thanks for your kindly explanation.
Regards,
Inochi.
> >
> >>>
> >>>>> And considering the limitation of this dmamux, maybe only devices that
> >>>>> require dma as a must can have the dma assigned.
> >>>>> Due to the fact, I think it may be a long time to wait for this header
> >>>>> to be used as the binding header.
> >>>>
> >>>> I don't understand. You did not provide a single reason why this is a
> >>>> binding. Reason is: mapping IDs between DTS and driver. Where is this
> >>>> reason?
> >>>>
> >>>
> >>> It seems like that I misunderstood something. This file provides one-one
> >>> mapping between the dma device id and cpuid, which is both used in the
> >>> dts and driver. For dts, it provides device id and cpu id mapping. And
> >>> for driver, it is used as the directive to tell how to write the mapping
> >>> register.
> >>
> >> So where is it? I looked for DMA_TDM0_RX - nothing. Then DMA_I2C1_RX -
> >> nothing. Then any "DMA_" - also looks nothing.
> >>
> >
> > It is just the value writed, so I say it is just a one-one mapping.
> > Maybe I misunderstand the binding meaning? Is the binding a mapping
> > between the dts and something defind in the driver (not the real
> > device)?
>
> Binding headers contains IDs which are used by the driver and DTS code.
> Hardware constants are not bindings. Register values, addresses,
> whatever hardware is using is not a binding.
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH] dt-bindings: crypto: ti,omap-sham: Convert to dtschema
From: Animesh Agarwal @ 2024-03-26 12:01 UTC (permalink / raw)
Cc: animeshagarwal28, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-crypto, devicetree,
linux-kernel
Convert the OMAP SoC SHA crypto Module bindings to DT Schema.
Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com>
---
.../devicetree/bindings/crypto/omap-sham.txt | 28 ----------
.../bindings/crypto/ti,omap-sham.yaml | 56 +++++++++++++++++++
2 files changed, 56 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt
create mode 100644 Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt
deleted file mode 100644
index ad9115569611..000000000000
--- a/Documentation/devicetree/bindings/crypto/omap-sham.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-OMAP SoC SHA crypto Module
-
-Required properties:
-
-- compatible : Should contain entries for this and backward compatible
- SHAM versions:
- - "ti,omap2-sham" for OMAP2 & OMAP3.
- - "ti,omap4-sham" for OMAP4 and AM33XX.
- - "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
-- ti,hwmods: Name of the hwmod associated with the SHAM module
-- reg : Offset and length of the register set for the module
-- interrupts : the interrupt-specifier for the SHAM module.
-
-Optional properties:
-- dmas: DMA specifiers for the rx dma. See the DMA client binding,
- Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: DMA request name. Should be "rx" if a dma is present.
-
-Example:
- /* AM335x */
- sham: sham@53100000 {
- compatible = "ti,omap4-sham";
- ti,hwmods = "sham";
- reg = <0x53100000 0x200>;
- interrupts = <109>;
- dmas = <&edma 36>;
- dma-names = "rx";
- };
diff --git a/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
new file mode 100644
index 000000000000..7a2529cc4cae
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/ti,omap-sham.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP SoC SHA crypto Module
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,omap2-sham
+ - ti,omap4-sham
+ - ti,omap5-sham
+
+ ti,hwmods:
+ description: Name of the hwmod associated with the SHAM module
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [sham]
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+dependencies:
+ dmas: [dma-names]
+
+additionalProperties: false
+
+required:
+ - compatible
+ - ti,hwmods
+ - reg
+ - interrupts
+
+examples:
+ - |
+ sham@53100000 {
+ compatible = "ti,omap4-sham";
+ ti,hwmods = "sham";
+ reg = <0x53100000 0x200>;
+ interrupts = <109>;
+ dmas = <&edma 36>;
+ dma-names = "rx";
+ };
--
2.44.0
^ permalink raw reply related
* Re: [PATCH 5/5] arm64: dts: Add device tree source for the Au-Zone Maivin Starter Kit
From: Krzysztof Kozlowski @ 2024-03-26 12:01 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20240326091100.GA17454@pendragon.ideasonboard.com>
On 26/03/2024 10:11, Laurent Pinchart wrote:
> Hi Krzysztof,
>
> On Tue, Mar 26, 2024 at 08:12:45AM +0100, Krzysztof Kozlowski wrote:
>> On 25/03/2024 21:32, Laurent Pinchart wrote:
>>> The Maivin board is an AI vision starter kit sold by Au-Zone
>>> Technologies, developed in collaboration with Toradex and Vision
>>> Components. It is based on a Toradex Verdin i.MX8MP SoM.
>>>
>>> Add a device tree that covers the base set the peripherals found on the
>>> board:
>>
>> Please use subject prefixes matching the subsystem. You can get them for
>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
>> your patch is touching.
>> And drop redundant parts.
>> arm64: dts: imx8mp-maivin: Add Au-Zone Maivin Starter Kit board
>
> Including in the command line the name of the dts that is being added
> doesn't seem to be a very common practice. See for instance
>
> 6d382d51d979 arm64: dts: freescale: Add SKOV IMX8MP CPU revB board
>
> I can use
>
> arm64: dts: freescale Add Au-Zone Maivin Starter Kit
>
> if you prefer.
It's also fine (plus missing : after freescale).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
From: Tommaso Merciai @ 2024-03-26 12:00 UTC (permalink / raw)
To: Adam Ford
Cc: Laurent Pinchart, linux-arm-kernel, marex, alexander.stein,
frieder.schrempf, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Philipp Zabel, Vinod Koul, Kishon Vijay Abraham I,
Catalin Marinas, Will Deacon, Liu Ying, Ulf Hansson, Lucas Stach,
dri-devel, devicetree, linux-kernel, linux-phy, linux-pm
In-Reply-To: <CAHCN7xKWUQwfNmTB_bu4Kqm-b6PSPBHvyf8yfRbL53rB20-=DQ@mail.gmail.com>
Hi Adam,
On Tue, Mar 26, 2024 at 06:43:26AM -0500, Adam Ford wrote:
> On Tue, Mar 26, 2024 at 2:46 AM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> >
> > Hi Laurent,
> >
> > On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> > > Hi Tommaso,
> > >
> > > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > > > Hi Adam, Lucas,
> > > > Thanks for this series.
> > > >
> > > > This series make HDMI work on evk.
> > > > All is working properly on my side.
> > > >
> > > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > > > Hope this help.
> > > >
> > > > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
> > >
> > > The DRM side has been merged already. The only missing patches are for
> > > the PHY, and the latest version can be found in
> > > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> > > You can test that series and send a Tested-by tag. I'm crossing my
> > > fingers and hoping it will be merged in v6.10.
> > (same here :) )
> >
> > Thanks for sharing! :)
> >
> > To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
> > All is working properly on my side.
> > I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
> > then I'm thinking this is the latest.
> >
> > I'm going to switch to your suggestion that looks more recent :)
>
> Sorry about the confusion. I was confused by the versioning too when
> I pulled from different parts of Lucas' stuff. Since varying
> components were applied at different times, and the remaining part was
> based on the wrong starting point and not applied, I reverted back to
> the versioning of the PHY which was the only remaining part other than
> device tree stuff.
No problem, thanks for clarify :)
Thanks & Regards,
Tommaso
>
> adam
> >
> > Thanks again,
> > Tommaso
> >
> > >
> > > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > > > other systems, the Parallel Video Interface (PVI) and the
> > > > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > > > and routes it to the PVI which converts passes the parallel video
> > > > > to the HDMI bridge. The HDMI system has a corresponding power
> > > > > domain controller whose driver was partially written, but the
> > > > > device tree for it was never applied, so some changes to the
> > > > > power domain should be harmless because they've not really been
> > > > > used yet.
> > > > >
> > > > > This series is adapted from multiple series from Lucas Stach with
> > > > > edits and suggestions from feedback from various series, but it
> > > > > since it's difficult to use and test them independently,
> > > > > I merged them into on unified series. The version history is a
> > > > > bit ambiguous since different components were submitted at different
> > > > > times and had different amount of retries. In an effort to merge them
> > > > > I used the highest version attempt.
> > > > >
> > > > > Adam Ford (3):
> > > > > dt-bindings: soc: imx: add missing clock and power-domains to
> > > > > imx8mp-hdmi-blk-ctrl
> > > > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > > > > domain
> > > > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > > > >
> > > > > Lucas Stach (9):
> > > > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > > > > phy: freescale: add Samsung HDMI PHY
> > > > > arm64: dts: imx8mp: add HDMI power-domains
> > > > > arm64: dts: imx8mp: add HDMI irqsteer
> > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > > > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > > > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > > > > arm64: dts: imx8mp: add HDMI display pipeline
> > > > >
> > > > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml | 102 ++
> > > > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++
> > > > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 +
> > > > > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +-
> > > > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++
> > > > > arch/arm64/configs/defconfig | 1 +
> > > > > drivers/gpu/drm/bridge/imx/Kconfig | 18 +
> > > > > drivers/gpu/drm/bridge/imx/Makefile | 2 +
> > > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 ++++
> > > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++
> > > > > drivers/phy/freescale/Kconfig | 6 +
> > > > > drivers/phy/freescale/Makefile | 1 +
> > > > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 +++++++++++++++++
> > > > > drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 10 +-
> > > > > 14 files changed, 1876 insertions(+), 13 deletions(-)
> > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > > > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > > > > create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > > > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for CV18XX/SG200X series SoC
From: Krzysztof Kozlowski @ 2024-03-26 11:50 UTC (permalink / raw)
To: Inochi Amaoto, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB4953EA589A0FF36DC6FCF0E8BB352@IA1PR20MB4953.namprd20.prod.outlook.com>
On 26/03/2024 12:41, Inochi Amaoto wrote:
>>>
>>> The driver does use this file.
>>
>> I checked and could not find. Please point me to specific parts of the code.
>>
>
> In cv1800_dmamux_route_allocate.
>> + regmap_set_bits(dmamux->regmap,
>> + DMAMUX_CH_REG(chid),
>> + DMAMUX_CH_SET(chid, devid));
>> +
>> + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
>> + DMAMUX_INT_CH_MASK(chid, cpuid),
>> + DMAMUX_INT_CH_BIT(chid, cpuid));
>
> I think this is.
So where exactly? I don't see any define being used here.
CV1800_SDMA_DMA_INT_MUX is not in your header. DMAMUX_ is not in your
header. So what are you pointing?
I don't understand this communication. Are you mocking me here or what?
It's waste of my time.
>
>>>
>>>>> And considering the limitation of this dmamux, maybe only devices that
>>>>> require dma as a must can have the dma assigned.
>>>>> Due to the fact, I think it may be a long time to wait for this header
>>>>> to be used as the binding header.
>>>>
>>>> I don't understand. You did not provide a single reason why this is a
>>>> binding. Reason is: mapping IDs between DTS and driver. Where is this
>>>> reason?
>>>>
>>>
>>> It seems like that I misunderstood something. This file provides one-one
>>> mapping between the dma device id and cpuid, which is both used in the
>>> dts and driver. For dts, it provides device id and cpu id mapping. And
>>> for driver, it is used as the directive to tell how to write the mapping
>>> register.
>>
>> So where is it? I looked for DMA_TDM0_RX - nothing. Then DMA_I2C1_RX -
>> nothing. Then any "DMA_" - also looks nothing.
>>
>
> It is just the value writed, so I say it is just a one-one mapping.
> Maybe I misunderstand the binding meaning? Is the binding a mapping
> between the dts and something defind in the driver (not the real
> device)?
Binding headers contains IDs which are used by the driver and DTS code.
Hardware constants are not bindings. Register values, addresses,
whatever hardware is using is not a binding.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: wm8974: Convert to dtschema
From: Mark Brown @ 2024-03-26 11:49 UTC (permalink / raw)
To: lgirdwood, robh, krzysztof.kozlowski+dt, conor+dt,
Kartik Agarwala
Cc: patches, linux-sound, devicetree, linux-kernel,
javier.carrasco.cruz
In-Reply-To: <20240325181943.116733-1-agarwala.kartik@gmail.com>
On Mon, 25 Mar 2024 23:49:42 +0530, Kartik Agarwala wrote:
> Convert WM8974 audio CODEC bindings from text to dtschema.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: wm8974: Convert to dtschema
commit: b340f56a74b62d8ce8617650c8ab4a26c87ba5c5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH v3 8/8] arm64: dts: allwinner: h616: enable DVFS for all boards
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
With the DT bindings now describing the format of the CPU OPP tables, we
can include the OPP table in each board's .dts file, and specify the CPU
power supply.
This allows to enable DVFS, and get up to 50% of performance benefit in
the highest OPP, or up to 60% power savings in the lowest OPP, compared
to the fixed 1GHz @ 1.0V OPP we are running in by default at the moment.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi | 5 +++++
arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts | 5 +++++
arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts | 5 +++++
.../boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi | 5 +++++
.../arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts | 5 +++++
arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts | 5 +++++
.../boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts | 5 +++++
7 files changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
index af421ba24ce0c..d12b01c5f41b6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -62,6 +63,10 @@ wifi_pwrseq: wifi-pwrseq {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&mmc0 {
vmmc-supply = <®_dldo1>;
/* Card detection pin is not connected */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
index b5d713926a341..a360d8567f955 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -6,12 +6,17 @@
/dts-v1/;
#include "sun50i-h616-orangepi-zero.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
/ {
model = "OrangePi Zero2";
compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
};
+&cpu0 {
+ cpu-supply = <®_dcdca>;
+};
+
&emac0 {
allwinner,rx-delay-ps = <3100>;
allwinner,tx-delay-ps = <700>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
index 959b6fd18483b..26d25b5b59e0f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -32,6 +33,10 @@ reg_vcc5v: vcc5v {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdca>;
+};
+
&ehci0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
index 8c1263a3939e7..e92d150aaf1c1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
@@ -4,6 +4,11 @@
*/
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
&mmc2 {
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts
index 21ca1977055d9..6a4f0da972330 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -53,6 +54,10 @@ reg_vcc3v3: vcc3v3 {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&ehci1 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
index b3b1b8692125f..e1cd7572a14ce 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
@@ -6,12 +6,17 @@
/dts-v1/;
#include "sun50i-h616-orangepi-zero.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
/ {
model = "OrangePi Zero3";
compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&emac0 {
allwinner,tx-delay-ps = <700>;
phy-mode = "rgmii-rxid";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
index ac0a2b7ea6f31..a6458b7a86713 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -51,6 +52,10 @@ wifi_pwrseq: wifi_pwrseq {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&ehci0 {
status = "okay";
};
--
2.25.1
^ permalink raw reply related
* [PATCH v3 7/8] arm64: dts: allwinner: h616: Add CPU OPPs table
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
Add an Operating Performance Points table for the CPU cores to enable
Dynamic Voltage & Frequency Scaling (DVFS) on the H616.
The values were taken from the BSP sources. The (newer) H700 chips we
have seen seem to use a separate speed bin, its OPP values were taken
from a live system and added to the mix.
Also add the needed cpu_speed_grade nvmem cell and the cooling cells
properties, to enable passive cooling.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
[Andre: rework to minimise opp-microvolt properties]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../dts/allwinner/sun50i-h616-cpu-opp.dtsi | 125 ++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 8 ++
2 files changed, 133 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
new file mode 100644
index 0000000000000..6073fdf672592
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2023 Martin Botka <martin@somainline.org>
+
+/ {
+ cpu_opp_table: opp-table-cpu {
+ compatible = "allwinner,sun50i-h616-operating-points";
+ nvmem-cells = <&cpu_speed_grade>;
+ opp-shared;
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x3f>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x12>;
+ };
+
+ opp-720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2d>;
+ };
+
+ opp-792000000 {
+ opp-hz = /bits/ 64 <792000000>;
+ opp-microvolt-speed1 = <900000>;
+ opp-microvolt-speed4 = <940000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x12>;
+ };
+
+ opp-936000000 {
+ opp-hz = /bits/ 64 <936000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x0d>;
+ };
+
+ opp-1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt-speed0 = <950000>;
+ opp-microvolt-speed1 = <940000>;
+ opp-microvolt-speed2 = <950000>;
+ opp-microvolt-speed3 = <950000>;
+ opp-microvolt-speed4 = <1020000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x1f>;
+ };
+
+ opp-10320000 {
+ opp-hz = /bits/ 64 <1032000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x20>;
+ };
+
+ opp-1104000000 {
+ opp-hz = /bits/ 64 <1104000000>;
+ opp-microvolt-speed0 = <1000000>;
+ opp-microvolt-speed2 = <1000000>;
+ opp-microvolt-speed3 = <1000000>;
+ opp-microvolt-speed5 = <950000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2d>;
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt-speed0 = <1050000>;
+ opp-microvolt-speed1 = <1020000>;
+ opp-microvolt-speed2 = <1050000>;
+ opp-microvolt-speed3 = <1050000>;
+ opp-microvolt-speed4 = <1100000>;
+ opp-microvolt-speed5 = <1020000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x3f>;
+ };
+
+ opp-1320000000 {
+ opp-hz = /bits/ 64 <1320000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x1d>;
+ };
+
+ opp-1416000000 {
+ opp-hz = /bits/ 64 <1416000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2d>;
+ };
+
+ opp-1512000000 {
+ opp-hz = /bits/ 64 <1512000000>;
+ opp-microvolt-speed1 = <1100000>;
+ opp-microvolt-speed3 = <1100000>;
+ opp-microvolt-speed5 = <1160000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2a>;
+ };
+ };
+};
+
+&cpu0 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu1 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu2 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu3 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
index b2e85e52d1a12..c0fa466fa9f07 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -26,6 +26,7 @@ cpu0: cpu@0 {
reg = <0>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -34,6 +35,7 @@ cpu1: cpu@1 {
reg = <1>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -42,6 +44,7 @@ cpu2: cpu@2 {
reg = <2>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -50,6 +53,7 @@ cpu3: cpu@3 {
reg = <3>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
};
@@ -156,6 +160,10 @@ sid: efuse@3006000 {
ths_calibration: thermal-sensor-calibration@14 {
reg = <0x14 0x8>;
};
+
+ cpu_speed_grade: cpu-speed-grade@0 {
+ reg = <0x0 2>;
+ };
};
watchdog: watchdog@30090a0 {
--
2.25.1
^ permalink raw reply related
* [PATCH v3 6/8] cpufreq: sun50i: Add H616 support
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin, Mark Rutland, Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
The Allwinner H616/H618 SoCs have different OPP tables per SoC version
and die revision. The SoC version is stored in NVMEM, as before, though
encoded differently. The die revision is in a different register, in the
SRAM controller. Firmware already exports that value in a standardised
way, through the SMCCC SoCID mechanism. We need both values, as some chips
have the same SoC version, but they don't support the same frequencies and
they get differentiated by the die revision.
Add the new compatible string and tie the new translation function to
it. This mechanism not only covers the original H616 SoC, but also its
very close sibling SoCs H618 and H700, so add them to the list as well.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 61 ++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index bd170611c7906..f9e9fc340f848 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -10,6 +10,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/arm-smccc.h>
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/nvmem-consumer.h>
@@ -46,14 +47,71 @@ static u32 sun50i_h6_efuse_xlate(u32 speedbin)
return 0;
}
+/*
+ * Judging by the OPP tables in the vendor BSP, the quality order of the
+ * returned speedbin index is 4 -> 0/2 -> 3 -> 1, from worst to best.
+ * 0 and 2 seem identical from the OPP tables' point of view.
+ */
+static u32 sun50i_h616_efuse_xlate(u32 speedbin)
+{
+ int ver_bits = arm_smccc_get_soc_id_revision();
+ u32 value = 0;
+
+ switch (speedbin & 0xffff) {
+ case 0x2000:
+ value = 0;
+ break;
+ case 0x2400:
+ case 0x7400:
+ case 0x2c00:
+ case 0x7c00:
+ if (ver_bits != SMCCC_RET_NOT_SUPPORTED && ver_bits <= 1) {
+ /* ic version A/B */
+ value = 1;
+ } else {
+ /* ic version C and later version */
+ value = 2;
+ }
+ break;
+ case 0x5000:
+ case 0x5400:
+ case 0x6000:
+ value = 3;
+ break;
+ case 0x5c00:
+ value = 4;
+ break;
+ case 0x5d00:
+ value = 0;
+ break;
+ case 0x6c00:
+ value = 5;
+ break;
+ default:
+ pr_warn("sun50i-cpufreq-nvmem: unknown speed bin 0x%x, using default bin 0\n",
+ speedbin & 0xffff);
+ value = 0;
+ break;
+ }
+
+ return value;
+}
+
static struct sunxi_cpufreq_data sun50i_h6_cpufreq_data = {
.efuse_xlate = sun50i_h6_efuse_xlate,
};
+static struct sunxi_cpufreq_data sun50i_h616_cpufreq_data = {
+ .efuse_xlate = sun50i_h616_efuse_xlate,
+};
+
static const struct of_device_id cpu_opp_match_list[] = {
{ .compatible = "allwinner,sun50i-h6-operating-points",
.data = &sun50i_h6_cpufreq_data,
},
+ { .compatible = "allwinner,sun50i-h616-operating-points",
+ .data = &sun50i_h616_cpufreq_data,
+ },
{}
};
@@ -230,6 +288,9 @@ static struct platform_driver sun50i_cpufreq_driver = {
static const struct of_device_id sun50i_cpufreq_match_list[] = {
{ .compatible = "allwinner,sun50i-h6" },
+ { .compatible = "allwinner,sun50i-h616" },
+ { .compatible = "allwinner,sun50i-h618" },
+ { .compatible = "allwinner,sun50i-h700" },
{}
};
MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
--
2.25.1
^ permalink raw reply related
* [PATCH v3 5/8] cpufreq: sun50i: Add support for opp_supported_hw
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
The opp_supported_hw DT property allows the DT to specify a mask of chip
revisions that a certain OPP is eligible for. This allows for easy
limiting of maximum frequencies, for instance.
Add support for that in the sun50i-cpufreq-nvmem driver. We support both
the existing opp-microvolt suffix properties as well as the
opp-supported-hw property, the generic code figures out which is needed
automatically.
However if none of the DT OPP nodes contain an opp-supported-hw
property, the core code will ignore all OPPs and the driver will fail
probing. So check the DT's eligibility first before using that feature.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 62 ++++++++++++++++++++++----
1 file changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 7b44f3b13e7d2..bd170611c7906 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -57,6 +57,41 @@ static const struct of_device_id cpu_opp_match_list[] = {
{}
};
+/**
+ * dt_has_supported_hw() - Check if any OPPs use opp-supported-hw
+ *
+ * If we ask the cpufreq framework to use the opp-supported-hw feature, it
+ * will ignore every OPP node without that DT property. If none of the OPPs
+ * have it, the driver will fail probing, due to the lack of OPPs.
+ *
+ * Returns true if we have at least one OPP with the opp-supported-hw property.
+ */
+static bool dt_has_supported_hw(void)
+{
+ bool has_opp_supported_hw = false;
+ struct device_node *np, *opp;
+ struct device *cpu_dev;
+
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev)
+ return -ENODEV;
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
+ if (!np)
+ return -ENOENT;
+
+ for_each_child_of_node(np, opp) {
+ if (of_find_property(opp, "opp-supported-hw", NULL)) {
+ has_opp_supported_hw = true;
+ break;
+ }
+ }
+
+ of_node_put(np);
+
+ return has_opp_supported_hw;
+}
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
*
@@ -110,7 +145,8 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
{
int *opp_tokens;
char name[MAX_NAME_LEN];
- unsigned int cpu;
+ unsigned int cpu, supported_hw;
+ struct dev_pm_opp_config config = {};
int speed;
int ret;
@@ -125,7 +161,18 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
return speed;
}
+ /*
+ * We need at least one OPP with the "opp-supported-hw" property,
+ * or else the upper layers will ignore every OPP and will bail out.
+ */
+ if (dt_has_supported_hw()) {
+ supported_hw = 1U << speed;
+ config.supported_hw = &supported_hw;
+ config.supported_hw_count = 1;
+ }
+
snprintf(name, MAX_NAME_LEN, "speed%d", speed);
+ config.prop_name = name;
for_each_possible_cpu(cpu) {
struct device *cpu_dev = get_cpu_device(cpu);
@@ -135,12 +182,11 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
goto free_opp;
}
- opp_tokens[cpu] = dev_pm_opp_set_prop_name(cpu_dev, name);
- if (opp_tokens[cpu] < 0) {
- ret = opp_tokens[cpu];
- pr_err("Failed to set prop name\n");
+ ret = dev_pm_opp_set_config(cpu_dev, &config);
+ if (ret < 0)
goto free_opp;
- }
+
+ opp_tokens[cpu] = ret;
}
cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1,
@@ -155,7 +201,7 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
free_opp:
for_each_possible_cpu(cpu)
- dev_pm_opp_put_prop_name(opp_tokens[cpu]);
+ dev_pm_opp_clear_config(opp_tokens[cpu]);
kfree(opp_tokens);
return ret;
@@ -169,7 +215,7 @@ static void sun50i_cpufreq_nvmem_remove(struct platform_device *pdev)
platform_device_unregister(cpufreq_dt_pdev);
for_each_possible_cpu(cpu)
- dev_pm_opp_put_prop_name(opp_tokens[cpu]);
+ dev_pm_opp_clear_config(opp_tokens[cpu]);
kfree(opp_tokens);
}
--
2.25.1
^ permalink raw reply related
* [PATCH v3 4/8] cpufreq: sun50i: Refactor speed bin decoding
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Brandon Cheo Fusi <fusibrandon13@gmail.com>
Make converting the speed bin value into a speed grade generic and
determined by a platform specific callback. Also change the prototypes
involved to encode the speed bin directly in the return value.
This allows to extend the driver more easily to support more SoCs.
Signed-off-by: Brandon Cheo Fusi <fusibrandon13@gmail.com>
[Andre: merge output into return value]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 74 +++++++++++++++++---------
1 file changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 32a9c88f8ff6d..7b44f3b13e7d2 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -25,19 +25,52 @@
static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
+struct sunxi_cpufreq_data {
+ u32 (*efuse_xlate)(u32 speedbin);
+};
+
+static u32 sun50i_h6_efuse_xlate(u32 speedbin)
+{
+ u32 efuse_value;
+
+ efuse_value = (speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
+
+ /*
+ * We treat unexpected efuse values as if the SoC was from
+ * the slowest bin. Expected efuse values are 1-3, slowest
+ * to fastest.
+ */
+ if (efuse_value >= 1 && efuse_value <= 3)
+ return efuse_value - 1;
+ else
+ return 0;
+}
+
+static struct sunxi_cpufreq_data sun50i_h6_cpufreq_data = {
+ .efuse_xlate = sun50i_h6_efuse_xlate,
+};
+
+static const struct of_device_id cpu_opp_match_list[] = {
+ { .compatible = "allwinner,sun50i-h6-operating-points",
+ .data = &sun50i_h6_cpufreq_data,
+ },
+ {}
+};
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
- * @versions: Set to the value parsed from efuse
*
- * Returns 0 if success.
+ * Returns non-negative speed bin index on success, a negative error
+ * value otherwise.
*/
-static int sun50i_cpufreq_get_efuse(u32 *versions)
+static int sun50i_cpufreq_get_efuse(void)
{
struct nvmem_cell *speedbin_nvmem;
struct device_node *np;
struct device *cpu_dev;
- u32 *speedbin, efuse_value;
- size_t len;
+ const struct of_device_id *match;
+ const struct sunxi_cpufreq_data *opp_data;
+ u32 *speedbin;
int ret;
cpu_dev = get_cpu_device(0);
@@ -48,12 +81,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
if (!np)
return -ENOENT;
- ret = of_device_is_compatible(np,
- "allwinner,sun50i-h6-operating-points");
- if (!ret) {
+ match = of_match_node(cpu_opp_match_list, np);
+ if (!match) {
of_node_put(np);
return -ENOENT;
}
+ opp_data = match->data;
speedbin_nvmem = of_nvmem_cell_get(np, NULL);
of_node_put(np);
@@ -61,25 +94,16 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
return dev_err_probe(cpu_dev, PTR_ERR(speedbin_nvmem),
"Could not get nvmem cell\n");
- speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ speedbin = nvmem_cell_read(speedbin_nvmem, NULL);
nvmem_cell_put(speedbin_nvmem);
if (IS_ERR(speedbin))
return PTR_ERR(speedbin);
- efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
- /*
- * We treat unexpected efuse values as if the SoC was from
- * the slowest bin. Expected efuse values are 1-3, slowest
- * to fastest.
- */
- if (efuse_value >= 1 && efuse_value <= 3)
- *versions = efuse_value - 1;
- else
- *versions = 0;
+ ret = opp_data->efuse_xlate(*speedbin);
kfree(speedbin);
- return 0;
+
+ return ret;
};
static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
@@ -87,7 +111,7 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
int *opp_tokens;
char name[MAX_NAME_LEN];
unsigned int cpu;
- u32 speed = 0;
+ int speed;
int ret;
opp_tokens = kcalloc(num_possible_cpus(), sizeof(*opp_tokens),
@@ -95,10 +119,10 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
if (!opp_tokens)
return -ENOMEM;
- ret = sun50i_cpufreq_get_efuse(&speed);
- if (ret) {
+ speed = sun50i_cpufreq_get_efuse();
+ if (speed < 0) {
kfree(opp_tokens);
- return ret;
+ return speed;
}
snprintf(name, MAX_NAME_LEN, "speed%d", speed);
--
2.25.1
^ permalink raw reply related
* [PATCH v3 3/8] dt-bindings: opp: Describe H616 OPPs and opp-supported-hw
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
Compared to the existing Allwinner H6 OPP scheme, the H616 uses a
similar NVMEM based mechanism to determine the silicon revision, which
is required to select the right frequency / voltage pair for the OPPs.
However it limits the maximum frequency for some speed bins, also seems
to not support all frequencies in all speed bins, which requires us to
introduce the opp-supported-hw property.
Add this property to the list of allowed properties, also drop the
requirement for the revision specific opp-microvolt properties, since
they might not be needed if using opp-supported-hw.
Also use to opportunity to adjust some wording, and drop a sentence
referring to the Linux driver and the OPP subsystem.
Shorten the existing example and add another example, showcasing the
opp-supported-hw property.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../allwinner,sun50i-h6-operating-points.yaml | 86 +++++++++----------
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
index 51f62c3ae1947..d679b2e4a7199 100644
--- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
+++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
@@ -13,25 +13,25 @@ maintainers:
description: |
For some SoCs, the CPU frequency subset and voltage value of each
OPP varies based on the silicon variant in use. Allwinner Process
- Voltage Scaling Tables defines the voltage and frequency value based
- on the speedbin blown in the efuse combination. The
- sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
- provide the OPP framework with required information.
+ Voltage Scaling Tables define the voltage and frequency values based
+ on the speedbin blown in the efuse combination.
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
- const: allwinner,sun50i-h6-operating-points
+ enum:
+ - allwinner,sun50i-h6-operating-points
+ - allwinner,sun50i-h616-operating-points
nvmem-cells:
description: |
A phandle pointing to a nvmem-cells node representing the efuse
- registers that has information about the speedbin that is used
+ register that has information about the speedbin that is used
to select the right frequency/voltage value pair. Please refer
- the for nvmem-cells bindings
- Documentation/devicetree/bindings/nvmem/nvmem.txt and also
+ to the nvmem-cells bindings in
+ Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the
examples below.
opp-shared: true
@@ -47,15 +47,17 @@ patternProperties:
properties:
opp-hz: true
clock-latency-ns: true
+ opp-microvolt: true
+ opp-supported-hw:
+ description: |
+ A single 32 bit bitmap value, representing compatible HW, one
+ bit per speed bin index.
patternProperties:
"^opp-microvolt-speed[0-9]$": true
required:
- opp-hz
- - opp-microvolt-speed0
- - opp-microvolt-speed1
- - opp-microvolt-speed2
unevaluatedProperties: false
@@ -77,58 +79,54 @@ examples:
opp-microvolt-speed2 = <800000>;
};
- opp-720000000 {
+ opp-1080000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <720000000>;
+ opp-hz = /bits/ 64 <1080000000>;
- opp-microvolt-speed0 = <880000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
+ opp-microvolt-speed0 = <1060000>;
+ opp-microvolt-speed1 = <880000>;
+ opp-microvolt-speed2 = <840000>;
};
- opp-816000000 {
+ opp-1488000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <816000000>;
+ opp-hz = /bits/ 64 <1488000000>;
- opp-microvolt-speed0 = <880000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
+ opp-microvolt-speed0 = <1160000>;
+ opp-microvolt-speed1 = <1000000>;
+ opp-microvolt-speed2 = <960000>;
};
+ };
- opp-888000000 {
- clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <888000000>;
-
- opp-microvolt-speed0 = <940000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
- };
+ - |
+ opp-table {
+ compatible = "allwinner,sun50i-h616-operating-points";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
- opp-1080000000 {
+ opp-480000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1080000000>;
+ opp-hz = /bits/ 64 <480000000>;
- opp-microvolt-speed0 = <1060000>;
- opp-microvolt-speed1 = <880000>;
- opp-microvolt-speed2 = <840000>;
+ opp-microvolt = <900000>;
+ opp-supported-hw = <0x1f>;
};
- opp-1320000000 {
+ opp-792000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1320000000>;
+ opp-hz = /bits/ 64 <792000000>;
- opp-microvolt-speed0 = <1160000>;
- opp-microvolt-speed1 = <940000>;
- opp-microvolt-speed2 = <900000>;
+ opp-microvolt-speed1 = <900000>;
+ opp-microvolt-speed4 = <940000>;
+ opp-supported-hw = <0x12>;
};
- opp-1488000000 {
+ opp-1512000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1488000000>;
+ opp-hz = /bits/ 64 <1512000000>;
- opp-microvolt-speed0 = <1160000>;
- opp-microvolt-speed1 = <1000000>;
- opp-microvolt-speed2 = <960000>;
+ opp-microvolt = <1100000>;
+ opp-supported-hw = <0x0a>;
};
};
--
2.25.1
^ permalink raw reply related
* [PATCH v3 2/8] cpufreq: dt-platdev: Blocklist Allwinner H616/618 SoCs
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
The AllWinner H616 SoC will use the (extended) H6 OPP driver, so add
them to the cpufreq-dt blocklist, to not create the device twice.
This also affects the closely related sibling SoCs H618 and H700.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index b993a498084bc..86d8baa816795 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -104,6 +104,9 @@ static const struct of_device_id allowlist[] __initconst = {
*/
static const struct of_device_id blocklist[] __initconst = {
{ .compatible = "allwinner,sun50i-h6", },
+ { .compatible = "allwinner,sun50i-h616", },
+ { .compatible = "allwinner,sun50i-h618", },
+ { .compatible = "allwinner,sun50i-h700", },
{ .compatible = "apple,arm-platform", },
--
2.25.1
^ permalink raw reply related
* [PATCH v3 1/8] firmware: smccc: Export revision soc_id function
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
The "SoC ID revision" as provided via the SMCCC SOCID interface can be
valuable information for drivers, when certain functionality depends
on a die revision, for instance.
One example is the sun50i-cpufreq-nvmem driver, which needs this
information to determine the speed bin of the SoC.
Export the arm_smccc_get_soc_id_revision() function so that it can be
called by any driver.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/firmware/smccc/smccc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
index db818f9dcb8ee..d670635914ecb 100644
--- a/drivers/firmware/smccc/smccc.c
+++ b/drivers/firmware/smccc/smccc.c
@@ -69,6 +69,7 @@ s32 arm_smccc_get_soc_id_revision(void)
{
return smccc_soc_id_revision;
}
+EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
static int __init smccc_devices_init(void)
{
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/8] cpufreq: sun50i: Add Allwinner H616 support
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin, Mark Rutland, Lorenzo Pieralisi, Sudeep Holla
This series adds cpufreq support to the Allwinner H616 SoC.
v3 has seen only little changes compared to v2, which contained quite
some rework of Martin's original series from about half a year ago[1].
Thanks for the comments on the list, I adjusted the OPP nodes as
suggested. See below for a changelog.
=================
The various H616 chips seem to be qualified by production batches, and
there is a table that translates from some efuses values to actual speed
bin indexes. Also the die revision has a say here: we can derive this
from the SoC ID, already provided by TF-A through the SMCCC SoC ID
interface.
So while the H6 had explicit speed bin indexes in the efuses, this is
conceptually not that different, and after refactoring patch 4/8 this
can be neatly integrated into the existing (H6) sun50i-cpufreq-nvmem
driver.
On top of that, not all chips are qualified to reach the full 1.5GHz,
and the BSP kernel describes different OPPs for each speedbin. This
requires to add support for the opp-supported-hw DT property, to be
able to describe those requirements properly.
Patch 1/8 exports the SoC ID function, so that we can call it from our
driver. Patch 2/8 blocks the affected SoCs from the generic DT cpufreq
driver, patch 3/8 adds the DT binding documentation.
Patch 4/8 refactors the existing speedbin determination for the H6, to
be able to plug in the H616 version later more easily.
Patch 5/8 adds support for the opp-supported-hw property. This is done
in a generic way, so it's usable for other SoCs as well, and the code
will figure out if the current DT requires use of this feature.
Patch 6/8 then eventually adds the H616 bits to the driver, and ties
that to the new compatible string.
Patch 7/8 add the CPU OPP table as a .dtsi to the DT directory, the
values in there were taken from the BSP source.
Patch 8/8 then enables the OPPs for all boards we have DTs for.
Based on v6.9-rc1.
Please have a look!
Cheers,
Andre
[1] https://lore.kernel.org/linux-sunxi/20230904-cpufreq-h616-v1-0-b8842e525c43@somainline.org/T/#u
Changelog v2 .. v3:
- rebased on top of v6.9-rc1
- drop node name suffix from DT bindings
- drop multiple nodes per frequency in DT bindings example
- add H700 nvmem value and OPPs
- print warning for unknown nvmem values
- add #cooling-cells properties to CPU DT nodes
- use one DT node per frequency for OPP table entries
- include OPP table for newly added Longan board
Changelog v1 .. v2:
- extend commit messages
- add H618/H700 SoC IDs
- fix binding compatible enum
- fix binding documentation
- allow additional suffix to OPP node name
- shorten existing DT binding example
- add another (opp-supported-hw) binding example
- move speed bin decoding refactoring to separate patch (Brandon)
- move opp-supported-hw support to separate patch
- merge opp-supported-hw and microvolt suffix handling
- rewrite OPP tables without opp-microvolt-speed suffix
Andre Przywara (2):
cpufreq: sun50i: Add support for opp_supported_hw
arm64: dts: allwinner: h616: enable DVFS for all boards
Brandon Cheo Fusi (1):
cpufreq: sun50i: Refactor speed bin decoding
Martin Botka (5):
firmware: smccc: Export revision soc_id function
cpufreq: dt-platdev: Blocklist Allwinner H616/618 SoCs
dt-bindings: opp: Describe H616 OPPs and opp-supported-hw
cpufreq: sun50i: Add H616 support
arm64: dts: allwinner: h616: Add CPU OPPs table
.../allwinner,sun50i-h6-operating-points.yaml | 86 ++++----
.../sun50i-h616-bigtreetech-cb1.dtsi | 5 +
.../dts/allwinner/sun50i-h616-cpu-opp.dtsi | 125 +++++++++++
.../allwinner/sun50i-h616-orangepi-zero2.dts | 5 +
.../dts/allwinner/sun50i-h616-x96-mate.dts | 5 +
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 8 +
.../sun50i-h618-longan-module-3h.dtsi | 5 +
.../allwinner/sun50i-h618-orangepi-zero2w.dts | 5 +
.../allwinner/sun50i-h618-orangepi-zero3.dts | 5 +
.../sun50i-h618-transpeed-8k618-t.dts | 5 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 197 +++++++++++++++---
drivers/firmware/smccc/smccc.c | 1 +
13 files changed, 378 insertions(+), 77 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
--
2.25.1
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties
From: Stefan Wahren @ 2024-03-26 11:47 UTC (permalink / raw)
To: Krzysztof Kozlowski, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-gpio, Dave Stevenson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <6cc81b1a-12e6-4d81-b6c4-6297c213d5c9@linaro.org>
[add Dave since he's working on DMA for Raspberry Pi 4 and maybe have a
opinion about this]
[drop Emma Anholt old address since she is not involved anymore]
Am 26.03.24 um 08:06 schrieb Krzysztof Kozlowski:
> On 26/03/2024 01:49, Laurent Pinchart wrote:
>> The raspberrypi,bcm2835-firmware devices requires a dma-ranges property,
>> and, as a result, also needs to specify #address-cells and #size-cells.
>> Those properties have been added to thebcm2835-rpi.dtsi in commits
>> be08d278eb09 ("ARM: dts: bcm283x: Add cells encoding format to firmware
>> bus") and 55c7c0621078 ("ARM: dts: bcm283x: Fix vc4's firmware bus DMA
>> limitations"), but the DT bindings haven't been updated, resulting in
>> validation errors:
>>
>> arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb: firmware: '#address-cells', '#size-cells', 'dma-ranges', 'gpio' do not match any of the regexes: 'pinctrl-[0-9]+'
>> from schema $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
>>
>> Fix this by adding the properties to the bindings.
>>
>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Children do not perform any IO on their own, because everything is
> handled by parent. It is really odd to see dma-ranges without ranges.
> Referenced commits might be also wrong.
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
From: Adam Ford @ 2024-03-26 11:43 UTC (permalink / raw)
To: Tommaso Merciai
Cc: Laurent Pinchart, linux-arm-kernel, marex, alexander.stein,
frieder.schrempf, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Philipp Zabel, Vinod Koul, Kishon Vijay Abraham I,
Catalin Marinas, Will Deacon, Liu Ying, Ulf Hansson, Lucas Stach,
dri-devel, devicetree, linux-kernel, linux-phy, linux-pm
In-Reply-To: <ZgJ9P3Wx2A2n9Gt+@tom-HP-ZBook-Fury-15-G7-Mobile-Workstation>
On Tue, Mar 26, 2024 at 2:46 AM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
>
> Hi Laurent,
>
> On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> > Hi Tommaso,
> >
> > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > > Hi Adam, Lucas,
> > > Thanks for this series.
> > >
> > > This series make HDMI work on evk.
> > > All is working properly on my side.
> > >
> > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > > Hope this help.
> > >
> > > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
> >
> > The DRM side has been merged already. The only missing patches are for
> > the PHY, and the latest version can be found in
> > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> > You can test that series and send a Tested-by tag. I'm crossing my
> > fingers and hoping it will be merged in v6.10.
> (same here :) )
>
> Thanks for sharing! :)
>
> To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
> All is working properly on my side.
> I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
> then I'm thinking this is the latest.
>
> I'm going to switch to your suggestion that looks more recent :)
Sorry about the confusion. I was confused by the versioning too when
I pulled from different parts of Lucas' stuff. Since varying
components were applied at different times, and the remaining part was
based on the wrong starting point and not applied, I reverted back to
the versioning of the PHY which was the only remaining part other than
device tree stuff.
adam
>
> Thanks again,
> Tommaso
>
> >
> > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > > other systems, the Parallel Video Interface (PVI) and the
> > > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > > and routes it to the PVI which converts passes the parallel video
> > > > to the HDMI bridge. The HDMI system has a corresponding power
> > > > domain controller whose driver was partially written, but the
> > > > device tree for it was never applied, so some changes to the
> > > > power domain should be harmless because they've not really been
> > > > used yet.
> > > >
> > > > This series is adapted from multiple series from Lucas Stach with
> > > > edits and suggestions from feedback from various series, but it
> > > > since it's difficult to use and test them independently,
> > > > I merged them into on unified series. The version history is a
> > > > bit ambiguous since different components were submitted at different
> > > > times and had different amount of retries. In an effort to merge them
> > > > I used the highest version attempt.
> > > >
> > > > Adam Ford (3):
> > > > dt-bindings: soc: imx: add missing clock and power-domains to
> > > > imx8mp-hdmi-blk-ctrl
> > > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > > > domain
> > > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > > >
> > > > Lucas Stach (9):
> > > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > > > phy: freescale: add Samsung HDMI PHY
> > > > arm64: dts: imx8mp: add HDMI power-domains
> > > > arm64: dts: imx8mp: add HDMI irqsteer
> > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > > > arm64: dts: imx8mp: add HDMI display pipeline
> > > >
> > > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml | 102 ++
> > > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++
> > > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 +
> > > > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +-
> > > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++
> > > > arch/arm64/configs/defconfig | 1 +
> > > > drivers/gpu/drm/bridge/imx/Kconfig | 18 +
> > > > drivers/gpu/drm/bridge/imx/Makefile | 2 +
> > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 ++++
> > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++
> > > > drivers/phy/freescale/Kconfig | 6 +
> > > > drivers/phy/freescale/Makefile | 1 +
> > > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 +++++++++++++++++
> > > > drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 10 +-
> > > > 14 files changed, 1876 insertions(+), 13 deletions(-)
> > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > > > create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for CV18XX/SG200X series SoC
From: Inochi Amaoto @ 2024-03-26 11:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Inochi Amaoto, Vinod Koul, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen Wang, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <cf42e020-9a5b-48bb-bc14-c0cc9498627b@linaro.org>
On Tue, Mar 26, 2024 at 12:31:18PM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 12:15, Inochi Amaoto wrote:
> > On Tue, Mar 26, 2024 at 09:53:09AM +0100, Krzysztof Kozlowski wrote:
> >> On 26/03/2024 08:35, Inochi Amaoto wrote:
> >>>>> +
> >>>>> +required:
> >>>>> + - '#dma-cells'
> >>>>> + - dma-masters
> >>>>> +
> >>>>
> >>>>
> >>>> I don't understand what happened here. Previously you had a child and I
> >>>> proposed to properly describe it with $ref.
> >>>>
> >>>> Now, all children are gone. Binding is supposed to be complete. Based on
> >>>> your cover letter, this is not complete, but why? What is missing and
> >>>> why it cannot be added?
> >>>>
> >>>
> >>> The binding of syscon is removed due to a usb phy subdevices, which needs
> >>> sometime to figure out the actual property. This is why the syscon binding
> >>> is removed.
> >>>
> >>> I think it is better to use the origianl syscon series to evolve after
> >>> the usb phy binding is submitted. The subdevices of syscon may need
> >>> much reverse engineering to know its parameters. So at least for now,
> >>> the syscon binding is hard to be complete.
> >>
> >> Some explanation why dma-router is gone would be useful, but fine.
> >>
> >
> > OK, I will add some comments on the why it is gone.
> >
> >>>
> >>>>
> >>>>> +additionalProperties: false
> >>>>> +
> >>>>> +examples:
> >>>>> + - |
> >>>>> + dma-router {
> >>>>> + compatible = "sophgo,cv1800-dmamux";
> >>>>> + #dma-cells = <2>;
> >>>>> + dma-masters = <&dmac>;
> >>>>> + dma-requests = <8>;
> >>>>> + };
> >>>>> diff --git a/include/dt-bindings/dma/cv1800-dma.h b/include/dt-bindings/dma/cv1800-dma.h
> >>>>> new file mode 100644
> >>>>> index 000000000000..3ce9dac25259
> >>>>> --- /dev/null
> >>>>> +++ b/include/dt-bindings/dma/cv1800-dma.h
> >>>>
> >>>> Filename should match bindings filename.
> >>>>
> >>>
> >>> Thanks.
> >>>
> >>>>
> >>>> Anyway, the problem is that it is a dead header. I don't see it being
> >>>> used, so it is not a binding.
> >>>>
> >>>
> >>> This header is not used because the dmamux node is not defined at now.
> >>
> >> In the driver? The binding header is supposed to be used in the driver,
> >> otherwise it is not a binding.
> >>
> >
> > The driver does use this file.
>
> I checked and could not find. Please point me to specific parts of the code.
>
In cv1800_dmamux_route_allocate.
>+ regmap_set_bits(dmamux->regmap,
>+ DMAMUX_CH_REG(chid),
>+ DMAMUX_CH_SET(chid, devid));
>+
>+ regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
>+ DMAMUX_INT_CH_MASK(chid, cpuid),
>+ DMAMUX_INT_CH_BIT(chid, cpuid));
I think this is.
> >
> >>> And considering the limitation of this dmamux, maybe only devices that
> >>> require dma as a must can have the dma assigned.
> >>> Due to the fact, I think it may be a long time to wait for this header
> >>> to be used as the binding header.
> >>
> >> I don't understand. You did not provide a single reason why this is a
> >> binding. Reason is: mapping IDs between DTS and driver. Where is this
> >> reason?
> >>
> >
> > It seems like that I misunderstood something. This file provides one-one
> > mapping between the dma device id and cpuid, which is both used in the
> > dts and driver. For dts, it provides device id and cpu id mapping. And
> > for driver, it is used as the directive to tell how to write the mapping
> > register.
>
> So where is it? I looked for DMA_TDM0_RX - nothing. Then DMA_I2C1_RX -
> nothing. Then any "DMA_" - also looks nothing.
>
It is just the value writed, so I say it is just a one-one mapping.
Maybe I misunderstand the binding meaning? Is the binding a mapping
between the dts and something defind in the driver (not the real
device)?
Regards,
Inochi.
^ permalink raw reply
* Re: [PATCH v6 2/2] ARM: dts: aspeed: x4tf: Add dts for asus x4tf project
From: Krzysztof Kozlowski @ 2024-03-26 11:39 UTC (permalink / raw)
To: Kelly Hung, robh+dt
Cc: krzysztof.kozlowski+dt, conor+dt, joel, andrew, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, openbmc, kelly_hung,
Allenyy_Hsu
In-Reply-To: <20240326103549.2413515-3-Kelly_Hung@asus.com>
On 26/03/2024 11:35, Kelly Hung wrote:
> Base on aspeed-g6.dtsi and can boot into BMC console.
>
> Signed-off-by: Kelly Hung <Kelly_Hung@asus.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
That's not true.
Please provide a link to lore.kernel.org which will prove that you
received this tag.
> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Please provide a link to lore.kernel.org which will prove that you
received this tag.
Did you read the documentation I was sharing with you?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: arm: aspeed: add ASUS X4TF board
From: Krzysztof Kozlowski @ 2024-03-26 11:36 UTC (permalink / raw)
To: Kelly Hung, robh+dt
Cc: krzysztof.kozlowski+dt, conor+dt, joel, andrew, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, openbmc, kelly_hung,
Allenyy_Hsu, Rob Herring, Zev Weiss, Conor Dooley
In-Reply-To: <20240326103549.2413515-2-Kelly_Hung@asus.com>
On 26/03/2024 11:35, Kelly Hung wrote:
> Document the new compatibles used on ASUS X4TF.
>
> Signed-off-by: Kelly Hung <Kelly_Hung@asus.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
Where did it happen? Where did you receive this tag? Please provide link
to lore.
> Reviewed-by: Zev Weiss <zweiss@equinix.com>
Where did it happen? Where did you receive this tag? Please provide link
to lore.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2 4/4] arm64: dts: exynos: gs101: define all PERIC USI nodes
From: Alim Akhtar @ 2024-03-26 11:35 UTC (permalink / raw)
To: 'Tudor Ambarus', peter.griffin, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
andre.draszik, willmcvicker, kernel-team
In-Reply-To: <20240326103620.298298-5-tudor.ambarus@linaro.org>
Hi Tudor,
> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus@linaro.org>
> Sent: Tuesday, March 26, 2024 4:06 PM
> To: peter.griffin@linaro.org; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org
> Cc: alim.akhtar@samsung.com; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; andre.draszik@linaro.org;
> willmcvicker@google.com; kernel-team@android.com; Tudor Ambarus
> <tudor.ambarus@linaro.org>
> Subject: [PATCH v2 4/4] arm64: dts: exynos: gs101: define all PERIC USI
nodes
>
> Universal Serial Interface (USI) supports three types of serial interface
such
> as UART, SPI and I2C. Each protocol works independently.
> USI can be configured to work as one of these protocols. Define all the
USI
> nodes from the PERIC blocks (USI0-14), in all their possible
configurations.
> These blocks have the TX/RX FIFO depth of 64 bytes.
>
> Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 769
> +++++++++++++++++++
> 1 file changed, 769 insertions(+)
>
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: serial: actions,owl-uart: convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-26 11:34 UTC (permalink / raw)
To: Kanak Shilledar
Cc: krzysztof.kozlowski+dt, robh+dt, devicetree, daniel.baluta,
Kanak Shilledar
In-Reply-To: <20240326110506.78408-1-kanakshilledar@gmail.com>
On 26/03/2024 12:05, Kanak Shilledar wrote:
> From: Kanak Shilledar <kanakshilledar111@protonmail.com>
>
> Convert the Actions Semi Owl UART to newer DT schema.
> Created DT schema based on the .txt file which had
> `compatible`, `reg`, `clocks` and `interrupts` as the
That's not true. Old binding file did not have clocks. You did more than
conversion and I asked you to describe changes which are different than
pure conversion.
Instead of sending another version the same day, can you please read
carefully comments you receive?
> required properties. This binding is used by Actions S500, S700
> and S900 SoC. S700 and S900 use the same UART compatible string.
> Implemented a full node example for the UART, referenced S500 SoC
> devicetree include.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Drop, you made MANY MORE changes than I asked, up to the point of making
it broken.
I don't understand. I asked three things. One you ignored, two
implemented and then added more.
> Signed-off-by: Kanak Shilledar <kanakshilledar111@protonmail.com>
> ---
...
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
That's surprising. Nothing in the changelog explains this.
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/actions,s500-cmu.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + uart0: serial@b0126000 {
> + compatible = "actions,s500-uart", "actions,owl-uart";
> + reg = <0xb0126000 0x1000>;
> + clocks = <&cmu CLK_UART0>;
> + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
NAK.
Examples are not disabled.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v18 8/9] usb: dwc3: qcom: Enable wakeup for applicable ports of multiport
From: Krishna Kurapati @ 2024-03-26 11:32 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, Johan Hovold
Cc: devicetree, linux-arm-msm, linux-usb, linux-kernel, quic_ppratap,
quic_jackp, Krishna Kurapati, Johan Hovold
In-Reply-To: <20240326113253.3010447-1-quic_kriskura@quicinc.com>
DWC3 Qcom wrapper currently supports only wakeup configuration
for single port controllers. Read speed of each port connected
to the controller and enable wakeup for each of them accordingly.
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
---
drivers/usb/dwc3/dwc3-qcom.c | 71 +++++++++++++++++++++---------------
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 35eb338514bc..12182e0f8f45 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -57,6 +57,7 @@ struct dwc3_qcom_port {
int dp_hs_phy_irq;
int dm_hs_phy_irq;
int ss_phy_irq;
+ enum usb_device_speed usb2_speed;
};
struct dwc3_qcom {
@@ -68,7 +69,6 @@ struct dwc3_qcom {
struct reset_control *resets;
struct dwc3_qcom_port ports[DWC3_MAX_PORTS];
u8 num_ports;
- enum usb_device_speed usb2_speed;
struct extcon_dev *edev;
struct extcon_dev *host_edev;
@@ -307,7 +307,7 @@ static bool dwc3_qcom_is_host(struct dwc3_qcom *qcom)
return dwc->xhci;
}
-static enum usb_device_speed dwc3_qcom_read_usb2_speed(struct dwc3_qcom *qcom)
+static enum usb_device_speed dwc3_qcom_read_usb2_speed(struct dwc3_qcom *qcom, int port_index)
{
struct dwc3 *dwc = platform_get_drvdata(qcom->dwc3);
struct usb_device *udev;
@@ -318,14 +318,8 @@ static enum usb_device_speed dwc3_qcom_read_usb2_speed(struct dwc3_qcom *qcom)
*/
hcd = platform_get_drvdata(dwc->xhci);
- /*
- * It is possible to query the speed of all children of
- * USB2.0 root hub via usb_hub_for_each_child(). DWC3 code
- * currently supports only 1 port per controller. So
- * this is sufficient.
- */
#ifdef CONFIG_USB
- udev = usb_hub_find_child(hcd->self.root_hub, 1);
+ udev = usb_hub_find_child(hcd->self.root_hub, port_index + 1);
#else
udev = NULL;
#endif
@@ -356,26 +350,26 @@ static void dwc3_qcom_disable_wakeup_irq(int irq)
disable_irq_nosync(irq);
}
-static void dwc3_qcom_disable_interrupts(struct dwc3_qcom *qcom)
+static void dwc3_qcom_disable_port_interrupts(struct dwc3_qcom_port *port)
{
- dwc3_qcom_disable_wakeup_irq(qcom->ports[0].qusb2_phy_irq);
+ dwc3_qcom_disable_wakeup_irq(port->qusb2_phy_irq);
- if (qcom->usb2_speed == USB_SPEED_LOW) {
- dwc3_qcom_disable_wakeup_irq(qcom->ports[0].dm_hs_phy_irq);
- } else if ((qcom->usb2_speed == USB_SPEED_HIGH) ||
- (qcom->usb2_speed == USB_SPEED_FULL)) {
- dwc3_qcom_disable_wakeup_irq(qcom->ports[0].dp_hs_phy_irq);
+ if (port->usb2_speed == USB_SPEED_LOW) {
+ dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
+ } else if ((port->usb2_speed == USB_SPEED_HIGH) ||
+ (port->usb2_speed == USB_SPEED_FULL)) {
+ dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
} else {
- dwc3_qcom_disable_wakeup_irq(qcom->ports[0].dp_hs_phy_irq);
- dwc3_qcom_disable_wakeup_irq(qcom->ports[0].dm_hs_phy_irq);
+ dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
+ dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
}
- dwc3_qcom_disable_wakeup_irq(qcom->ports[0].ss_phy_irq);
+ dwc3_qcom_disable_wakeup_irq(port->ss_phy_irq);
}
-static void dwc3_qcom_enable_interrupts(struct dwc3_qcom *qcom)
+static void dwc3_qcom_enable_port_interrupts(struct dwc3_qcom_port *port)
{
- dwc3_qcom_enable_wakeup_irq(qcom->ports[0].qusb2_phy_irq, 0);
+ dwc3_qcom_enable_wakeup_irq(port->qusb2_phy_irq, 0);
/*
* Configure DP/DM line interrupts based on the USB2 device attached to
@@ -386,21 +380,37 @@ static void dwc3_qcom_enable_interrupts(struct dwc3_qcom *qcom)
* DP and DM lines as rising edge to detect HS/HS/LS device connect scenario.
*/
- if (qcom->usb2_speed == USB_SPEED_LOW) {
- dwc3_qcom_enable_wakeup_irq(qcom->ports[0].dm_hs_phy_irq,
+ if (port->usb2_speed == USB_SPEED_LOW) {
+ dwc3_qcom_enable_wakeup_irq(port->dm_hs_phy_irq,
IRQ_TYPE_EDGE_FALLING);
- } else if ((qcom->usb2_speed == USB_SPEED_HIGH) ||
- (qcom->usb2_speed == USB_SPEED_FULL)) {
- dwc3_qcom_enable_wakeup_irq(qcom->ports[0].dp_hs_phy_irq,
+ } else if ((port->usb2_speed == USB_SPEED_HIGH) ||
+ (port->usb2_speed == USB_SPEED_FULL)) {
+ dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
IRQ_TYPE_EDGE_FALLING);
} else {
- dwc3_qcom_enable_wakeup_irq(qcom->ports[0].dp_hs_phy_irq,
+ dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
IRQ_TYPE_EDGE_RISING);
- dwc3_qcom_enable_wakeup_irq(qcom->ports[0].dm_hs_phy_irq,
+ dwc3_qcom_enable_wakeup_irq(port->dm_hs_phy_irq,
IRQ_TYPE_EDGE_RISING);
}
- dwc3_qcom_enable_wakeup_irq(qcom->ports[0].ss_phy_irq, 0);
+ dwc3_qcom_enable_wakeup_irq(port->ss_phy_irq, 0);
+}
+
+static void dwc3_qcom_disable_interrupts(struct dwc3_qcom *qcom)
+{
+ int i;
+
+ for (i = 0; i < qcom->num_ports; i++)
+ dwc3_qcom_disable_port_interrupts(&qcom->ports[i]);
+}
+
+static void dwc3_qcom_enable_interrupts(struct dwc3_qcom *qcom)
+{
+ int i;
+
+ for (i = 0; i < qcom->num_ports; i++)
+ dwc3_qcom_enable_port_interrupts(&qcom->ports[i]);
}
static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup)
@@ -427,7 +437,8 @@ static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup)
* freezable workqueue.
*/
if (dwc3_qcom_is_host(qcom) && wakeup) {
- qcom->usb2_speed = dwc3_qcom_read_usb2_speed(qcom);
+ for (i = 0; i < qcom->num_ports; i++)
+ qcom->ports[i].usb2_speed = dwc3_qcom_read_usb2_speed(qcom, i);
dwc3_qcom_enable_interrupts(qcom);
}
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox