* [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp
@ 2021-06-01 17:49 Tim Harvey
2021-06-01 17:49 ` [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config Tim Harvey
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Tim Harvey @ 2021-06-01 17:49 UTC (permalink / raw)
To: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-arm-kernel, Tim Harvey
Override the default temperature alert/crit for Industrial temp IMX8M
Mini.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
.../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
index c769fadbd008..512b76cd7c3b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
@@ -493,3 +493,15 @@
>;
};
};
+
+&cpu_alert0 {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "passive";
+};
+
+&cpu_crit0 {
+ temperature = <105000>;
+ hysteresis = <2000>;
+ type = "critical";
+};
--
2.17.1
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config 2021-06-01 17:49 [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Tim Harvey @ 2021-06-01 17:49 ` Tim Harvey 2021-07-24 18:19 ` Tim Harvey 2021-06-01 17:49 ` [PATCH 3/4] arm64: dts: imx8mm-venice-gw7901: add support for USB hub subload Tim Harvey ` (2 subsequent siblings) 3 siblings, 1 reply; 18+ messages in thread From: Tim Harvey @ 2021-06-01 17:49 UTC (permalink / raw) To: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Cc: devicetree, linux-arm-kernel, Tim Harvey Fix various MP5416 PMIC configurations: - Update regulator names per dt-bindings - ensure values fit among valid register values - add required regulator-max-microamp property - add regulator-always-on prop Signed-off-by: Tim Harvey <tharvey@gateworks.com> --- .../dts/freescale/imx8mm-venice-gw700x.dtsi | 56 ++++++++++++------- 1 file changed, 37 insertions(+), 19 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi index 512b76cd7c3b..f4eb827baed7 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi @@ -283,65 +283,83 @@ reg = <0x69>; regulators { + /* vdd_0p95: DRAM/GPU/VPU */ buck1 { - regulator-name = "vdd_0p95"; - regulator-min-microvolt = <805000>; + regulator-name = "buck1"; + regulator-min-microvolt = <800000>; regulator-max-microvolt = <1000000>; - regulator-max-microamp = <2500000>; + regulator-min-microamp = <3800000>; + regulator-max-microamp = <6800000>; regulator-boot-on; + regulator-always-on; }; + /* vdd_soc */ buck2 { - regulator-name = "vdd_soc"; - regulator-min-microvolt = <805000>; + regulator-name = "buck2"; + regulator-min-microvolt = <800000>; regulator-max-microvolt = <900000>; - regulator-max-microamp = <1000000>; + regulator-min-microamp = <2200000>; + regulator-max-microamp = <5200000>; regulator-boot-on; + regulator-always-on; }; + /* vdd_arm */ buck3_reg: buck3 { - regulator-name = "vdd_arm"; - regulator-min-microvolt = <805000>; + regulator-name = "buck3"; + regulator-min-microvolt = <800000>; regulator-max-microvolt = <1000000>; - regulator-max-microamp = <2200000>; - regulator-boot-on; + regulator-min-microamp = <3800000>; + regulator-max-microamp = <6800000>; + regulator-always-on; }; + /* vdd_1p8 */ buck4 { - regulator-name = "vdd_1p8"; + regulator-name = "buck4"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; - regulator-max-microamp = <500000>; + regulator-min-microamp = <2200000>; + regulator-max-microamp = <5200000>; regulator-boot-on; + regulator-always-on; }; + /* nvcc_snvs_1p8 */ ldo1 { - regulator-name = "nvcc_snvs_1p8"; + regulator-name = "ldo1"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; - regulator-max-microamp = <300000>; regulator-boot-on; + regulator-always-on; }; + /* vdd_snvs_0p8 */ ldo2 { - regulator-name = "vdd_snvs_0p8"; + regulator-name = "ldo2"; regulator-min-microvolt = <800000>; regulator-max-microvolt = <800000>; regulator-boot-on; + regulator-always-on; }; + /* vdd_0p9 */ ldo3 { - regulator-name = "vdd_0p95"; - regulator-min-microvolt = <800000>; - regulator-max-microvolt = <800000>; + regulator-name = "ldo3"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; regulator-boot-on; + regulator-always-on; }; + /* vdd_1p8 */ ldo4 { - regulator-name = "vdd_1p8"; + regulator-name = "ldo4"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-boot-on; + regulator-always-on; }; }; }; -- 2.17.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config 2021-06-01 17:49 ` [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config Tim Harvey @ 2021-07-24 18:19 ` Tim Harvey 2021-07-26 1:01 ` Shawn Guo 0 siblings, 1 reply; 18+ messages in thread From: Tim Harvey @ 2021-07-24 18:19 UTC (permalink / raw) To: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Cc: Device Tree Mailing List, Linux ARM Mailing List On Tue, Jun 1, 2021 at 10:49 AM Tim Harvey <tharvey@gateworks.com> wrote: > > Fix various MP5416 PMIC configurations: > - Update regulator names per dt-bindings > - ensure values fit among valid register values > - add required regulator-max-microamp property > - add regulator-always-on prop > > Signed-off-by: Tim Harvey <tharvey@gateworks.com> > --- > .../dts/freescale/imx8mm-venice-gw700x.dtsi | 56 ++++++++++++------- > 1 file changed, 37 insertions(+), 19 deletions(-) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > index 512b76cd7c3b..f4eb827baed7 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > @@ -283,65 +283,83 @@ > reg = <0x69>; > > regulators { > + /* vdd_0p95: DRAM/GPU/VPU */ > buck1 { > - regulator-name = "vdd_0p95"; > - regulator-min-microvolt = <805000>; > + regulator-name = "buck1"; > + regulator-min-microvolt = <800000>; > regulator-max-microvolt = <1000000>; > - regulator-max-microamp = <2500000>; > + regulator-min-microamp = <3800000>; > + regulator-max-microamp = <6800000>; > regulator-boot-on; > + regulator-always-on; > }; > > + /* vdd_soc */ > buck2 { > - regulator-name = "vdd_soc"; > - regulator-min-microvolt = <805000>; > + regulator-name = "buck2"; > + regulator-min-microvolt = <800000>; > regulator-max-microvolt = <900000>; > - regulator-max-microamp = <1000000>; > + regulator-min-microamp = <2200000>; > + regulator-max-microamp = <5200000>; > regulator-boot-on; > + regulator-always-on; > }; > > + /* vdd_arm */ > buck3_reg: buck3 { > - regulator-name = "vdd_arm"; > - regulator-min-microvolt = <805000>; > + regulator-name = "buck3"; > + regulator-min-microvolt = <800000>; > regulator-max-microvolt = <1000000>; > - regulator-max-microamp = <2200000>; > - regulator-boot-on; > + regulator-min-microamp = <3800000>; > + regulator-max-microamp = <6800000>; > + regulator-always-on; > }; > > + /* vdd_1p8 */ > buck4 { > - regulator-name = "vdd_1p8"; > + regulator-name = "buck4"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <1800000>; > - regulator-max-microamp = <500000>; > + regulator-min-microamp = <2200000>; > + regulator-max-microamp = <5200000>; > regulator-boot-on; > + regulator-always-on; > }; > > + /* nvcc_snvs_1p8 */ > ldo1 { > - regulator-name = "nvcc_snvs_1p8"; > + regulator-name = "ldo1"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <1800000>; > - regulator-max-microamp = <300000>; > regulator-boot-on; > + regulator-always-on; > }; > > + /* vdd_snvs_0p8 */ > ldo2 { > - regulator-name = "vdd_snvs_0p8"; > + regulator-name = "ldo2"; > regulator-min-microvolt = <800000>; > regulator-max-microvolt = <800000>; > regulator-boot-on; > + regulator-always-on; > }; > > + /* vdd_0p9 */ > ldo3 { > - regulator-name = "vdd_0p95"; > - regulator-min-microvolt = <800000>; > - regulator-max-microvolt = <800000>; > + regulator-name = "ldo3"; > + regulator-min-microvolt = <900000>; > + regulator-max-microvolt = <900000>; > regulator-boot-on; > + regulator-always-on; > }; > > + /* vdd_1p8 */ > ldo4 { > - regulator-name = "vdd_1p8"; > + regulator-name = "ldo4"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <1800000>; > regulator-boot-on; > + regulator-always-on; > }; > }; > }; > -- > 2.17.1 > Shawn, Is there anything you want changed here? Best regards, Tim ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config 2021-07-24 18:19 ` Tim Harvey @ 2021-07-26 1:01 ` Shawn Guo 2021-07-27 16:05 ` Tim Harvey 0 siblings, 1 reply; 18+ messages in thread From: Shawn Guo @ 2021-07-26 1:01 UTC (permalink / raw) To: Tim Harvey Cc: Rob Herring, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Device Tree Mailing List, Linux ARM Mailing List On Sat, Jul 24, 2021 at 11:19:21AM -0700, Tim Harvey wrote: > On Tue, Jun 1, 2021 at 10:49 AM Tim Harvey <tharvey@gateworks.com> wrote: > > > > Fix various MP5416 PMIC configurations: > > - Update regulator names per dt-bindings > > - ensure values fit among valid register values > > - add required regulator-max-microamp property > > - add regulator-always-on prop > > > > Signed-off-by: Tim Harvey <tharvey@gateworks.com> > > --- > > .../dts/freescale/imx8mm-venice-gw700x.dtsi | 56 ++++++++++++------- > > 1 file changed, 37 insertions(+), 19 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > index 512b76cd7c3b..f4eb827baed7 100644 > > --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > @@ -283,65 +283,83 @@ > > reg = <0x69>; > > > > regulators { > > + /* vdd_0p95: DRAM/GPU/VPU */ > > buck1 { > > - regulator-name = "vdd_0p95"; > > - regulator-min-microvolt = <805000>; > > + regulator-name = "buck1"; > > + regulator-min-microvolt = <800000>; > > regulator-max-microvolt = <1000000>; > > - regulator-max-microamp = <2500000>; > > + regulator-min-microamp = <3800000>; > > + regulator-max-microamp = <6800000>; > > regulator-boot-on; > > + regulator-always-on; > > }; > > > > + /* vdd_soc */ > > buck2 { > > - regulator-name = "vdd_soc"; > > - regulator-min-microvolt = <805000>; > > + regulator-name = "buck2"; > > + regulator-min-microvolt = <800000>; > > regulator-max-microvolt = <900000>; > > - regulator-max-microamp = <1000000>; > > + regulator-min-microamp = <2200000>; > > + regulator-max-microamp = <5200000>; > > regulator-boot-on; > > + regulator-always-on; > > }; > > > > + /* vdd_arm */ > > buck3_reg: buck3 { > > - regulator-name = "vdd_arm"; > > - regulator-min-microvolt = <805000>; > > + regulator-name = "buck3"; > > + regulator-min-microvolt = <800000>; > > regulator-max-microvolt = <1000000>; > > - regulator-max-microamp = <2200000>; > > - regulator-boot-on; > > + regulator-min-microamp = <3800000>; > > + regulator-max-microamp = <6800000>; > > + regulator-always-on; > > }; > > > > + /* vdd_1p8 */ > > buck4 { > > - regulator-name = "vdd_1p8"; > > + regulator-name = "buck4"; > > regulator-min-microvolt = <1800000>; > > regulator-max-microvolt = <1800000>; > > - regulator-max-microamp = <500000>; > > + regulator-min-microamp = <2200000>; > > + regulator-max-microamp = <5200000>; > > regulator-boot-on; > > + regulator-always-on; > > }; > > > > + /* nvcc_snvs_1p8 */ > > ldo1 { > > - regulator-name = "nvcc_snvs_1p8"; > > + regulator-name = "ldo1"; > > regulator-min-microvolt = <1800000>; > > regulator-max-microvolt = <1800000>; > > - regulator-max-microamp = <300000>; > > regulator-boot-on; > > + regulator-always-on; > > }; > > > > + /* vdd_snvs_0p8 */ > > ldo2 { > > - regulator-name = "vdd_snvs_0p8"; > > + regulator-name = "ldo2"; > > regulator-min-microvolt = <800000>; > > regulator-max-microvolt = <800000>; > > regulator-boot-on; > > + regulator-always-on; > > }; > > > > + /* vdd_0p9 */ > > ldo3 { > > - regulator-name = "vdd_0p95"; > > - regulator-min-microvolt = <800000>; > > - regulator-max-microvolt = <800000>; > > + regulator-name = "ldo3"; > > + regulator-min-microvolt = <900000>; > > + regulator-max-microvolt = <900000>; > > regulator-boot-on; > > + regulator-always-on; > > }; > > > > + /* vdd_1p8 */ > > ldo4 { > > - regulator-name = "vdd_1p8"; > > + regulator-name = "ldo4"; > > regulator-min-microvolt = <1800000>; > > regulator-max-microvolt = <1800000>; > > regulator-boot-on; > > + regulator-always-on; > > }; > > }; > > }; > > -- > > 2.17.1 > > > > Shawn, > > Is there anything you want changed here? Tim, Could you resend the series? For some reason, I cannot find the original posting in my mailbox. Shawn ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config 2021-07-26 1:01 ` Shawn Guo @ 2021-07-27 16:05 ` Tim Harvey 0 siblings, 0 replies; 18+ messages in thread From: Tim Harvey @ 2021-07-27 16:05 UTC (permalink / raw) To: Shawn Guo Cc: Rob Herring, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Device Tree Mailing List, Linux ARM Mailing List On Sun, Jul 25, 2021 at 6:01 PM Shawn Guo <shawnguo@kernel.org> wrote: > > On Sat, Jul 24, 2021 at 11:19:21AM -0700, Tim Harvey wrote: > > On Tue, Jun 1, 2021 at 10:49 AM Tim Harvey <tharvey@gateworks.com> wrote: > > > > > > Fix various MP5416 PMIC configurations: > > > - Update regulator names per dt-bindings > > > - ensure values fit among valid register values > > > - add required regulator-max-microamp property > > > - add regulator-always-on prop > > > > > > Signed-off-by: Tim Harvey <tharvey@gateworks.com> > > > --- > > > .../dts/freescale/imx8mm-venice-gw700x.dtsi | 56 ++++++++++++------- > > > 1 file changed, 37 insertions(+), 19 deletions(-) > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > > index 512b76cd7c3b..f4eb827baed7 100644 > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > > @@ -283,65 +283,83 @@ > > > reg = <0x69>; > > > > > > regulators { > > > + /* vdd_0p95: DRAM/GPU/VPU */ > > > buck1 { > > > - regulator-name = "vdd_0p95"; > > > - regulator-min-microvolt = <805000>; > > > + regulator-name = "buck1"; > > > + regulator-min-microvolt = <800000>; > > > regulator-max-microvolt = <1000000>; > > > - regulator-max-microamp = <2500000>; > > > + regulator-min-microamp = <3800000>; > > > + regulator-max-microamp = <6800000>; > > > regulator-boot-on; > > > + regulator-always-on; > > > }; > > > > > > + /* vdd_soc */ > > > buck2 { > > > - regulator-name = "vdd_soc"; > > > - regulator-min-microvolt = <805000>; > > > + regulator-name = "buck2"; > > > + regulator-min-microvolt = <800000>; > > > regulator-max-microvolt = <900000>; > > > - regulator-max-microamp = <1000000>; > > > + regulator-min-microamp = <2200000>; > > > + regulator-max-microamp = <5200000>; > > > regulator-boot-on; > > > + regulator-always-on; > > > }; > > > > > > + /* vdd_arm */ > > > buck3_reg: buck3 { > > > - regulator-name = "vdd_arm"; > > > - regulator-min-microvolt = <805000>; > > > + regulator-name = "buck3"; > > > + regulator-min-microvolt = <800000>; > > > regulator-max-microvolt = <1000000>; > > > - regulator-max-microamp = <2200000>; > > > - regulator-boot-on; > > > + regulator-min-microamp = <3800000>; > > > + regulator-max-microamp = <6800000>; > > > + regulator-always-on; > > > }; > > > > > > + /* vdd_1p8 */ > > > buck4 { > > > - regulator-name = "vdd_1p8"; > > > + regulator-name = "buck4"; > > > regulator-min-microvolt = <1800000>; > > > regulator-max-microvolt = <1800000>; > > > - regulator-max-microamp = <500000>; > > > + regulator-min-microamp = <2200000>; > > > + regulator-max-microamp = <5200000>; > > > regulator-boot-on; > > > + regulator-always-on; > > > }; > > > > > > + /* nvcc_snvs_1p8 */ > > > ldo1 { > > > - regulator-name = "nvcc_snvs_1p8"; > > > + regulator-name = "ldo1"; > > > regulator-min-microvolt = <1800000>; > > > regulator-max-microvolt = <1800000>; > > > - regulator-max-microamp = <300000>; > > > regulator-boot-on; > > > + regulator-always-on; > > > }; > > > > > > + /* vdd_snvs_0p8 */ > > > ldo2 { > > > - regulator-name = "vdd_snvs_0p8"; > > > + regulator-name = "ldo2"; > > > regulator-min-microvolt = <800000>; > > > regulator-max-microvolt = <800000>; > > > regulator-boot-on; > > > + regulator-always-on; > > > }; > > > > > > + /* vdd_0p9 */ > > > ldo3 { > > > - regulator-name = "vdd_0p95"; > > > - regulator-min-microvolt = <800000>; > > > - regulator-max-microvolt = <800000>; > > > + regulator-name = "ldo3"; > > > + regulator-min-microvolt = <900000>; > > > + regulator-max-microvolt = <900000>; > > > regulator-boot-on; > > > + regulator-always-on; > > > }; > > > > > > + /* vdd_1p8 */ > > > ldo4 { > > > - regulator-name = "vdd_1p8"; > > > + regulator-name = "ldo4"; > > > regulator-min-microvolt = <1800000>; > > > regulator-max-microvolt = <1800000>; > > > regulator-boot-on; > > > + regulator-always-on; > > > }; > > > }; > > > }; > > > -- > > > 2.17.1 > > > > > > > Shawn, > > > > Is there anything you want changed here? > > Tim, > > Could you resend the series? For some reason, I cannot find the > original posting in my mailbox. > > Shawn Sure... probably better anyway as I was asking you to drop one of them from the series. Tim ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 3/4] arm64: dts: imx8mm-venice-gw7901: add support for USB hub subload 2021-06-01 17:49 [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Tim Harvey 2021-06-01 17:49 ` [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config Tim Harvey @ 2021-06-01 17:49 ` Tim Harvey 2021-07-24 18:21 ` Tim Harvey 2021-06-01 17:49 ` [PATCH 4/4] arm64: dts: imx8mm-venice-gw7901: enable pull-down on gpio outputs Tim Harvey 2021-06-02 7:10 ` [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Frieder Schrempf 3 siblings, 1 reply; 18+ messages in thread From: Tim Harvey @ 2021-06-01 17:49 UTC (permalink / raw) To: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Cc: devicetree, linux-arm-kernel, Tim Harvey The USB hub has it's reset as GPIO4_IO17 but can be sub-loaded and VBUS provided by a VBUS regulator with GPIO4_IO2 as the enable and GPIO1_IO15 as the active-low over-current. Enable pull-up for GPIO4_IO17 to keep hub out of reset and move VBUS enable to GPIO4_IO2. Additionally enable pull-up on GPIO1_IO15 so that if the hub is loaded it never over-currents. This allows USB to work in both configurations without a device-tree change. Signed-off-by: Tim Harvey <tharvey@gateworks.com> --- arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts index 5a1e9df39bec..db43ee28bdb6 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts @@ -216,7 +216,7 @@ pinctrl-0 = <&pinctrl_reg_usb2>; compatible = "regulator-fixed"; regulator-name = "usb_usb2_vbus"; - gpio = <&gpio4 17 GPIO_ACTIVE_HIGH>; + gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>; enable-active-high; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; @@ -824,8 +824,9 @@ pinctrl_reg_usb2: regusb1grp { fsl,pins = < - MX8MM_IOMUXC_SAI1_TXD5_GPIO4_IO17 0x41 - MX8MM_IOMUXC_GPIO1_IO15_USB2_OTG_OC 0x41 + MX8MM_IOMUXC_SAI1_RXD0_GPIO4_IO2 0x41 + MX8MM_IOMUXC_SAI1_TXD5_GPIO4_IO17 0x140 + MX8MM_IOMUXC_GPIO1_IO15_USB2_OTG_OC 0x140 >; }; -- 2.17.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 3/4] arm64: dts: imx8mm-venice-gw7901: add support for USB hub subload 2021-06-01 17:49 ` [PATCH 3/4] arm64: dts: imx8mm-venice-gw7901: add support for USB hub subload Tim Harvey @ 2021-07-24 18:21 ` Tim Harvey 0 siblings, 0 replies; 18+ messages in thread From: Tim Harvey @ 2021-07-24 18:21 UTC (permalink / raw) To: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Cc: Device Tree Mailing List, Linux ARM Mailing List On Tue, Jun 1, 2021 at 10:49 AM Tim Harvey <tharvey@gateworks.com> wrote: > > The USB hub has it's reset as GPIO4_IO17 but can be sub-loaded and > VBUS provided by a VBUS regulator with GPIO4_IO2 as the enable and > GPIO1_IO15 as the active-low over-current. > > Enable pull-up for GPIO4_IO17 to keep hub out of reset and move VBUS > enable to GPIO4_IO2. Additionally enable pull-up on GPIO1_IO15 so that > if the hub is loaded it never over-currents. > > This allows USB to work in both configurations without a device-tree > change. > > Signed-off-by: Tim Harvey <tharvey@gateworks.com> > --- > arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts > index 5a1e9df39bec..db43ee28bdb6 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts > @@ -216,7 +216,7 @@ > pinctrl-0 = <&pinctrl_reg_usb2>; > compatible = "regulator-fixed"; > regulator-name = "usb_usb2_vbus"; > - gpio = <&gpio4 17 GPIO_ACTIVE_HIGH>; > + gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>; > enable-active-high; > regulator-min-microvolt = <5000000>; > regulator-max-microvolt = <5000000>; > @@ -824,8 +824,9 @@ > > pinctrl_reg_usb2: regusb1grp { > fsl,pins = < > - MX8MM_IOMUXC_SAI1_TXD5_GPIO4_IO17 0x41 > - MX8MM_IOMUXC_GPIO1_IO15_USB2_OTG_OC 0x41 > + MX8MM_IOMUXC_SAI1_RXD0_GPIO4_IO2 0x41 > + MX8MM_IOMUXC_SAI1_TXD5_GPIO4_IO17 0x140 > + MX8MM_IOMUXC_GPIO1_IO15_USB2_OTG_OC 0x140 > >; > }; > > -- > 2.17.1 > Shawn, Is there anything you want changed here? Best regards, Tim ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 4/4] arm64: dts: imx8mm-venice-gw7901: enable pull-down on gpio outputs 2021-06-01 17:49 [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Tim Harvey 2021-06-01 17:49 ` [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config Tim Harvey 2021-06-01 17:49 ` [PATCH 3/4] arm64: dts: imx8mm-venice-gw7901: add support for USB hub subload Tim Harvey @ 2021-06-01 17:49 ` Tim Harvey 2021-07-24 18:19 ` Tim Harvey 2021-06-02 7:10 ` [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Frieder Schrempf 3 siblings, 1 reply; 18+ messages in thread From: Tim Harvey @ 2021-06-01 17:49 UTC (permalink / raw) To: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Cc: devicetree, linux-arm-kernel, Tim Harvey Enable internal pull-down on UART transceiver GPIO config pins. Signed-off-by: Tim Harvey <tharvey@gateworks.com> --- arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts index db43ee28bdb6..0216facb2aef 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts @@ -877,9 +877,9 @@ pinctrl_uart3_gpio: uart3gpiogrp { fsl,pins = < - MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6 0x40000041 /* RS232# */ - MX8MM_IOMUXC_SAI1_RXD5_GPIO4_IO7 0x40000041 /* RS422# */ - MX8MM_IOMUXC_SAI1_RXD6_GPIO4_IO8 0x40000041 /* RS485# */ + MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6 0x40000110 /* RS232# */ + MX8MM_IOMUXC_SAI1_RXD5_GPIO4_IO7 0x40000110 /* RS422# */ + MX8MM_IOMUXC_SAI1_RXD6_GPIO4_IO8 0x40000110 /* RS485# */ >; }; -- 2.17.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 4/4] arm64: dts: imx8mm-venice-gw7901: enable pull-down on gpio outputs 2021-06-01 17:49 ` [PATCH 4/4] arm64: dts: imx8mm-venice-gw7901: enable pull-down on gpio outputs Tim Harvey @ 2021-07-24 18:19 ` Tim Harvey 0 siblings, 0 replies; 18+ messages in thread From: Tim Harvey @ 2021-07-24 18:19 UTC (permalink / raw) To: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Cc: Device Tree Mailing List, Linux ARM Mailing List On Tue, Jun 1, 2021 at 10:49 AM Tim Harvey <tharvey@gateworks.com> wrote: > > Enable internal pull-down on UART transceiver GPIO config pins. > > Signed-off-by: Tim Harvey <tharvey@gateworks.com> > --- > arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts > index db43ee28bdb6..0216facb2aef 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts > @@ -877,9 +877,9 @@ > > pinctrl_uart3_gpio: uart3gpiogrp { > fsl,pins = < > - MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6 0x40000041 /* RS232# */ > - MX8MM_IOMUXC_SAI1_RXD5_GPIO4_IO7 0x40000041 /* RS422# */ > - MX8MM_IOMUXC_SAI1_RXD6_GPIO4_IO8 0x40000041 /* RS485# */ > + MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6 0x40000110 /* RS232# */ > + MX8MM_IOMUXC_SAI1_RXD5_GPIO4_IO7 0x40000110 /* RS422# */ > + MX8MM_IOMUXC_SAI1_RXD6_GPIO4_IO8 0x40000110 /* RS485# */ > >; > }; > > -- > 2.17.1 > Shawn, Is there anything you want changed here? Best regards, Tim ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-01 17:49 [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Tim Harvey ` (2 preceding siblings ...) 2021-06-01 17:49 ` [PATCH 4/4] arm64: dts: imx8mm-venice-gw7901: enable pull-down on gpio outputs Tim Harvey @ 2021-06-02 7:10 ` Frieder Schrempf 2021-06-04 15:42 ` Tim Harvey 3 siblings, 1 reply; 18+ messages in thread From: Frieder Schrempf @ 2021-06-02 7:10 UTC (permalink / raw) To: Tim Harvey, Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Cc: devicetree, linux-arm-kernel On 01.06.21 19:49, Tim Harvey wrote: > Override the default temperature alert/crit for Industrial temp IMX8M > Mini. > > Signed-off-by: Tim Harvey <tharvey@gateworks.com> > --- > .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > index c769fadbd008..512b76cd7c3b 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > @@ -493,3 +493,15 @@ > >; > }; > }; > + > +&cpu_alert0 { > + temperature = <95000>; > + hysteresis = <2000>; > + type = "passive"; > +}; > + > +&cpu_crit0 { > + temperature = <105000>; > + hysteresis = <2000>; > + type = "critical"; > +}; As this is not really board-specific, I think the proper way to handle this for all boards is to let the thermal driver read the temperature grading from the OTP fuses and set the trip-points accordingly, similar to what is done on i.MX6 [1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/imx_thermal.c?h=v5.13-rc4#n508 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-02 7:10 ` [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Frieder Schrempf @ 2021-06-04 15:42 ` Tim Harvey 2021-06-07 7:20 ` Frieder Schrempf 0 siblings, 1 reply; 18+ messages in thread From: Tim Harvey @ 2021-06-04 15:42 UTC (permalink / raw) To: Frieder Schrempf Cc: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Device Tree Mailing List, Linux ARM Mailing List On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf <frieder.schrempf@kontron.de> wrote: > > On 01.06.21 19:49, Tim Harvey wrote: > > Override the default temperature alert/crit for Industrial temp IMX8M > > Mini. > > > > Signed-off-by: Tim Harvey <tharvey@gateworks.com> > > --- > > .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > index c769fadbd008..512b76cd7c3b 100644 > > --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > > @@ -493,3 +493,15 @@ > > >; > > }; > > }; > > + > > +&cpu_alert0 { > > + temperature = <95000>; > > + hysteresis = <2000>; > > + type = "passive"; > > +}; > > + > > +&cpu_crit0 { > > + temperature = <105000>; > > + hysteresis = <2000>; > > + type = "critical"; > > +}; > > As this is not really board-specific, I think the proper way to handle this for all boards is to let the thermal driver read the temperature grading from the OTP fuses and set the trip-points accordingly, similar to what is done on i.MX6 [1]. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/imx_thermal.c?h=v5.13-rc4#n508 Frieder, Yes, I thought about adding that kind of support to imx8mm_thermal.c but the difference is that imx8mm has alerts defined by dt and imx6 does not so is it right to override dt alerts on imx8m? What if someone designs a board that they specifically want a lower alert than the cpu grade they are using based on something else on the board? My approach to this was to eventually actually adjust the imx8m dt alerts in boot firmware based on some boot firmware setting or specific board support and leave the kernel alone. Best regards, Tim ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-04 15:42 ` Tim Harvey @ 2021-06-07 7:20 ` Frieder Schrempf 2021-06-07 7:30 ` Jacky Bai 0 siblings, 1 reply; 18+ messages in thread From: Frieder Schrempf @ 2021-06-07 7:20 UTC (permalink / raw) To: Tim Harvey Cc: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Device Tree Mailing List, Linux ARM Mailing List On 04.06.21 17:42, Tim Harvey wrote: > On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf > <frieder.schrempf@kontron.de> wrote: >> >> On 01.06.21 19:49, Tim Harvey wrote: >>> Override the default temperature alert/crit for Industrial temp IMX8M >>> Mini. >>> >>> Signed-off-by: Tim Harvey <tharvey@gateworks.com> >>> --- >>> .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>> index c769fadbd008..512b76cd7c3b 100644 >>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>> @@ -493,3 +493,15 @@ >>> >; >>> }; >>> }; >>> + >>> +&cpu_alert0 { >>> + temperature = <95000>; >>> + hysteresis = <2000>; >>> + type = "passive"; >>> +}; >>> + >>> +&cpu_crit0 { >>> + temperature = <105000>; >>> + hysteresis = <2000>; >>> + type = "critical"; >>> +}; >> >> As this is not really board-specific, I think the proper way to handle this for all boards is to let the thermal driver read the temperature grading from the OTP fuses and set the trip-points accordingly, similar to what is done on i.MX6 [1]. >> >> [1] https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fthermal%2Fimx_thermal.c%3Fh%3Dv5.13-rc4%23n508&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C7635e5c10c3e4d3fba3208d9276f5426%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637584181370793415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1Ed1rcaki%2FIPpFmii%2FEVc%2FAzPkzTzS9m8nplyFS90s8%3D&reserved=0 > > Frieder, > > Yes, I thought about adding that kind of support to imx8mm_thermal.c > but the difference is that imx8mm has alerts defined by dt and imx6 > does not so is it right to override dt alerts on imx8m? What if > someone designs a board that they specifically want a lower alert than > the cpu grade they are using based on something else on the board? > > My approach to this was to eventually actually adjust the imx8m dt > alerts in boot firmware based on some boot firmware setting or > specific board support and leave the kernel alone. Allowing board-specific trip points sounds like a valid request, but I still think we need a way to handle the temperature grading in the driver if no board-specific trip-points are given. What if we just set the temperature property in the trip nodes in imx8mm.dtsi to zero? The thermal driver would detect this and setup the correct values according to the grading. If the dt already provides non-zero temperature values (through the board dts) the driver will just leave the values and disregard the grading. I think this solution would be covering all needs. ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-07 7:20 ` Frieder Schrempf @ 2021-06-07 7:30 ` Jacky Bai 2021-06-07 7:53 ` Frieder Schrempf 0 siblings, 1 reply; 18+ messages in thread From: Jacky Bai @ 2021-06-07 7:30 UTC (permalink / raw) To: Frieder Schrempf, tharvey Cc: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dl-linux-imx, Device Tree Mailing List, Linux ARM Mailing List > Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override > thermal cfg for industrial temp > > On 04.06.21 17:42, Tim Harvey wrote: > > On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf > > <frieder.schrempf@kontron.de> wrote: > >> > >> On 01.06.21 19:49, Tim Harvey wrote: > >>> Override the default temperature alert/crit for Industrial temp > >>> IMX8M Mini. > >>> > >>> Signed-off-by: Tim Harvey <tharvey@gateworks.com> > >>> --- > >>> .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 > ++++++++++++ > >>> 1 file changed, 12 insertions(+) > >>> > >>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>> index c769fadbd008..512b76cd7c3b 100644 > >>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>> @@ -493,3 +493,15 @@ > >>> >; > >>> }; > >>> }; > >>> + > >>> +&cpu_alert0 { > >>> + temperature = <95000>; > >>> + hysteresis = <2000>; > >>> + type = "passive"; > >>> +}; > >>> + > >>> +&cpu_crit0 { > >>> + temperature = <105000>; > >>> + hysteresis = <2000>; > >>> + type = "critical"; > >>> +}; > >> > >> As this is not really board-specific, I think the proper way to handle this for > all boards is to let the thermal driver read the temperature grading from the > OTP fuses and set the trip-points accordingly, similar to what is done on i.MX6 > [1]. > >> ... > > > > Frieder, > > > > Yes, I thought about adding that kind of support to imx8mm_thermal.c > > but the difference is that imx8mm has alerts defined by dt and imx6 > > does not so is it right to override dt alerts on imx8m? What if > > someone designs a board that they specifically want a lower alert than > > the cpu grade they are using based on something else on the board? > > > > My approach to this was to eventually actually adjust the imx8m dt > > alerts in boot firmware based on some boot firmware setting or > > specific board support and leave the kernel alone. > > Allowing board-specific trip points sounds like a valid request, but I still think > we need a way to handle the temperature grading in the driver if no > board-specific trip-points are given. > > What if we just set the temperature property in the trip nodes in imx8mm.dtsi > to zero? The thermal driver would detect this and setup the correct values > according to the grading. If the dt already provides non-zero temperature > values (through the board dts) the driver will just leave the values and > disregard the grading. > > I think this solution would be covering all needs. I thought to add the grading check in the imx8mm_thermal.c to dynamically set the trip points temp, but it seems hard to do it due to the fact of_thermal is used, as no helper API is exported by of_thermal, no better way to override the trip point temp. glad to see any good suggestions. BR Jacky Bai ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-07 7:30 ` Jacky Bai @ 2021-06-07 7:53 ` Frieder Schrempf 2021-06-07 8:00 ` Jacky Bai 0 siblings, 1 reply; 18+ messages in thread From: Frieder Schrempf @ 2021-06-07 7:53 UTC (permalink / raw) To: Jacky Bai, tharvey Cc: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dl-linux-imx, Device Tree Mailing List, Linux ARM Mailing List On 07.06.21 09:30, Jacky Bai wrote: >> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override >> thermal cfg for industrial temp >> >> On 04.06.21 17:42, Tim Harvey wrote: >>> On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf >>> <frieder.schrempf@kontron.de> wrote: >>>> >>>> On 01.06.21 19:49, Tim Harvey wrote: >>>>> Override the default temperature alert/crit for Industrial temp >>>>> IMX8M Mini. >>>>> >>>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com> >>>>> --- >>>>> .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 >> ++++++++++++ >>>>> 1 file changed, 12 insertions(+) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>> index c769fadbd008..512b76cd7c3b 100644 >>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>> @@ -493,3 +493,15 @@ >>>>> >; >>>>> }; >>>>> }; >>>>> + >>>>> +&cpu_alert0 { >>>>> + temperature = <95000>; >>>>> + hysteresis = <2000>; >>>>> + type = "passive"; >>>>> +}; >>>>> + >>>>> +&cpu_crit0 { >>>>> + temperature = <105000>; >>>>> + hysteresis = <2000>; >>>>> + type = "critical"; >>>>> +}; >>>> >>>> As this is not really board-specific, I think the proper way to handle this for >> all boards is to let the thermal driver read the temperature grading from the >> OTP fuses and set the trip-points accordingly, similar to what is done on i.MX6 >> [1]. >>>> > ... >>> >>> Frieder, >>> >>> Yes, I thought about adding that kind of support to imx8mm_thermal.c >>> but the difference is that imx8mm has alerts defined by dt and imx6 >>> does not so is it right to override dt alerts on imx8m? What if >>> someone designs a board that they specifically want a lower alert than >>> the cpu grade they are using based on something else on the board? >>> >>> My approach to this was to eventually actually adjust the imx8m dt >>> alerts in boot firmware based on some boot firmware setting or >>> specific board support and leave the kernel alone. >> >> Allowing board-specific trip points sounds like a valid request, but I still think >> we need a way to handle the temperature grading in the driver if no >> board-specific trip-points are given. >> >> What if we just set the temperature property in the trip nodes in imx8mm.dtsi >> to zero? The thermal driver would detect this and setup the correct values >> according to the grading. If the dt already provides non-zero temperature >> values (through the board dts) the driver will just leave the values and >> disregard the grading. >> >> I think this solution would be covering all needs. > > I thought to add the grading check in the imx8mm_thermal.c to dynamically set the trip points > temp, but it seems hard to do it due to the fact of_thermal is used, as no helper API is exported by > of_thermal, no better way to override the trip point temp. > > glad to see any good suggestions. Right, the driver doesn't handle the trip-points directly. This is all hidden in the framework. So this might not be so easy to implement. What about this other approach: Adding all the possible trip-points for the different gradings to the SoC-devicetree and then let the thermal driver remove the trip nodes from the dt that are not valid for the detected grading, just before the driver registers the sensor/zone. ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-07 7:53 ` Frieder Schrempf @ 2021-06-07 8:00 ` Jacky Bai 2021-06-07 8:34 ` Frieder Schrempf 0 siblings, 1 reply; 18+ messages in thread From: Jacky Bai @ 2021-06-07 8:00 UTC (permalink / raw) To: Frieder Schrempf, tharvey Cc: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dl-linux-imx, Device Tree Mailing List, Linux ARM Mailing List > Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override > thermal cfg for industrial temp > > On 07.06.21 09:30, Jacky Bai wrote: > >> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override > >> thermal cfg for industrial temp > >> > >> On 04.06.21 17:42, Tim Harvey wrote: > >>> On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf > >>> <frieder.schrempf@kontron.de> wrote: > >>>> > >>>> On 01.06.21 19:49, Tim Harvey wrote: > >>>>> Override the default temperature alert/crit for Industrial temp > >>>>> IMX8M Mini. > >>>>> > >>>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com> > >>>>> --- > >>>>> .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 > >> ++++++++++++ > >>>>> 1 file changed, 12 insertions(+) > >>>>> > >>>>> diff --git > >>>>> a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>> index c769fadbd008..512b76cd7c3b 100644 > >>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>> @@ -493,3 +493,15 @@ > >>>>> >; > >>>>> }; > >>>>> }; > >>>>> + > >>>>> +&cpu_alert0 { > >>>>> + temperature = <95000>; > >>>>> + hysteresis = <2000>; > >>>>> + type = "passive"; > >>>>> +}; > >>>>> + > >>>>> +&cpu_crit0 { > >>>>> + temperature = <105000>; > >>>>> + hysteresis = <2000>; > >>>>> + type = "critical"; > >>>>> +}; > >>>> > >>>> As this is not really board-specific, I think the proper way to > >>>> handle this for > >> all boards is to let the thermal driver read the temperature grading > >> from the OTP fuses and set the trip-points accordingly, similar to > >> what is done on i.MX6 [1]. > >>>> > > ... > >>> > >>> Frieder, > >>> > >>> Yes, I thought about adding that kind of support to imx8mm_thermal.c > >>> but the difference is that imx8mm has alerts defined by dt and imx6 > >>> does not so is it right to override dt alerts on imx8m? What if > >>> someone designs a board that they specifically want a lower alert > >>> than the cpu grade they are using based on something else on the board? > >>> > >>> My approach to this was to eventually actually adjust the imx8m dt > >>> alerts in boot firmware based on some boot firmware setting or > >>> specific board support and leave the kernel alone. > >> > >> Allowing board-specific trip points sounds like a valid request, but > >> I still think we need a way to handle the temperature grading in the > >> driver if no board-specific trip-points are given. > >> > >> What if we just set the temperature property in the trip nodes in > >> imx8mm.dtsi to zero? The thermal driver would detect this and setup > >> the correct values according to the grading. If the dt already > >> provides non-zero temperature values (through the board dts) the > >> driver will just leave the values and disregard the grading. > >> > >> I think this solution would be covering all needs. > > > > I thought to add the grading check in the imx8mm_thermal.c to > > dynamically set the trip points temp, but it seems hard to do it due > > to the fact of_thermal is used, as no helper API is exported by of_thermal, > no better way to override the trip point temp. > > > > glad to see any good suggestions. > > Right, the driver doesn't handle the trip-points directly. This is all hidden in the > framework. So this might not be so easy to implement. > > What about this other approach: Adding all the possible trip-points for the > different gradings to the SoC-devicetree and then let the thermal driver > remove the trip nodes from the dt that are not valid for the detected grading, > just before the driver registers the sensor/zone. It is more reasonable for the firmware/bootloader to handle this by checking the grading. BR Jacky Bai ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-07 8:00 ` Jacky Bai @ 2021-06-07 8:34 ` Frieder Schrempf 2021-06-11 18:55 ` Tim Harvey 0 siblings, 1 reply; 18+ messages in thread From: Frieder Schrempf @ 2021-06-07 8:34 UTC (permalink / raw) To: Jacky Bai, tharvey Cc: Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dl-linux-imx, Device Tree Mailing List, Linux ARM Mailing List On 07.06.21 10:00, Jacky Bai wrote: >> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override >> thermal cfg for industrial temp >> >> On 07.06.21 09:30, Jacky Bai wrote: >>>> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override >>>> thermal cfg for industrial temp >>>> >>>> On 04.06.21 17:42, Tim Harvey wrote: >>>>> On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf >>>>> <frieder.schrempf@kontron.de> wrote: >>>>>> >>>>>> On 01.06.21 19:49, Tim Harvey wrote: >>>>>>> Override the default temperature alert/crit for Industrial temp >>>>>>> IMX8M Mini. >>>>>>> >>>>>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com> >>>>>>> --- >>>>>>> .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 >>>> ++++++++++++ >>>>>>> 1 file changed, 12 insertions(+) >>>>>>> >>>>>>> diff --git >>>>>>> a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>> index c769fadbd008..512b76cd7c3b 100644 >>>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>> @@ -493,3 +493,15 @@ >>>>>>> >; >>>>>>> }; >>>>>>> }; >>>>>>> + >>>>>>> +&cpu_alert0 { >>>>>>> + temperature = <95000>; >>>>>>> + hysteresis = <2000>; >>>>>>> + type = "passive"; >>>>>>> +}; >>>>>>> + >>>>>>> +&cpu_crit0 { >>>>>>> + temperature = <105000>; >>>>>>> + hysteresis = <2000>; >>>>>>> + type = "critical"; >>>>>>> +}; >>>>>> >>>>>> As this is not really board-specific, I think the proper way to >>>>>> handle this for >>>> all boards is to let the thermal driver read the temperature grading >>>> from the OTP fuses and set the trip-points accordingly, similar to >>>> what is done on i.MX6 [1]. >>>>>> >>> ... >>>>> >>>>> Frieder, >>>>> >>>>> Yes, I thought about adding that kind of support to imx8mm_thermal.c >>>>> but the difference is that imx8mm has alerts defined by dt and imx6 >>>>> does not so is it right to override dt alerts on imx8m? What if >>>>> someone designs a board that they specifically want a lower alert >>>>> than the cpu grade they are using based on something else on the board? >>>>> >>>>> My approach to this was to eventually actually adjust the imx8m dt >>>>> alerts in boot firmware based on some boot firmware setting or >>>>> specific board support and leave the kernel alone. >>>> >>>> Allowing board-specific trip points sounds like a valid request, but >>>> I still think we need a way to handle the temperature grading in the >>>> driver if no board-specific trip-points are given. >>>> >>>> What if we just set the temperature property in the trip nodes in >>>> imx8mm.dtsi to zero? The thermal driver would detect this and setup >>>> the correct values according to the grading. If the dt already >>>> provides non-zero temperature values (through the board dts) the >>>> driver will just leave the values and disregard the grading. >>>> >>>> I think this solution would be covering all needs. >>> >>> I thought to add the grading check in the imx8mm_thermal.c to >>> dynamically set the trip points temp, but it seems hard to do it due >>> to the fact of_thermal is used, as no helper API is exported by of_thermal, >> no better way to override the trip point temp. >>> >>> glad to see any good suggestions. >> >> Right, the driver doesn't handle the trip-points directly. This is all hidden in the >> framework. So this might not be so easy to implement. >> >> What about this other approach: Adding all the possible trip-points for the >> different gradings to the SoC-devicetree and then let the thermal driver >> remove the trip nodes from the dt that are not valid for the detected grading, >> just before the driver registers the sensor/zone. > > It is more reasonable for the firmware/bootloader to handle this by checking the grading. If possible, I would rather like to avoid creating another dependency on bootloader/firmware. I think the kernel should be able to detect the grading by itself and adjust its behavior accordingly. We also do this for the speed grading in cpufreq. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-07 8:34 ` Frieder Schrempf @ 2021-06-11 18:55 ` Tim Harvey 2021-06-29 7:48 ` Frieder Schrempf 0 siblings, 1 reply; 18+ messages in thread From: Tim Harvey @ 2021-06-11 18:55 UTC (permalink / raw) To: Frieder Schrempf Cc: Jacky Bai, Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dl-linux-imx, Device Tree Mailing List, Linux ARM Mailing List On Mon, Jun 7, 2021 at 1:34 AM Frieder Schrempf <frieder.schrempf@kontron.de> wrote: > > On 07.06.21 10:00, Jacky Bai wrote: > >> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override > >> thermal cfg for industrial temp > >> > >> On 07.06.21 09:30, Jacky Bai wrote: > >>>> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override > >>>> thermal cfg for industrial temp > >>>> > >>>> On 04.06.21 17:42, Tim Harvey wrote: > >>>>> On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf > >>>>> <frieder.schrempf@kontron.de> wrote: > >>>>>> > >>>>>> On 01.06.21 19:49, Tim Harvey wrote: > >>>>>>> Override the default temperature alert/crit for Industrial temp > >>>>>>> IMX8M Mini. > >>>>>>> > >>>>>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com> > >>>>>>> --- > >>>>>>> .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 > >>>> ++++++++++++ > >>>>>>> 1 file changed, 12 insertions(+) > >>>>>>> > >>>>>>> diff --git > >>>>>>> a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>>>> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>>>> index c769fadbd008..512b76cd7c3b 100644 > >>>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi > >>>>>>> @@ -493,3 +493,15 @@ > >>>>>>> >; > >>>>>>> }; > >>>>>>> }; > >>>>>>> + > >>>>>>> +&cpu_alert0 { > >>>>>>> + temperature = <95000>; > >>>>>>> + hysteresis = <2000>; > >>>>>>> + type = "passive"; > >>>>>>> +}; > >>>>>>> + > >>>>>>> +&cpu_crit0 { > >>>>>>> + temperature = <105000>; > >>>>>>> + hysteresis = <2000>; > >>>>>>> + type = "critical"; > >>>>>>> +}; > >>>>>> > >>>>>> As this is not really board-specific, I think the proper way to > >>>>>> handle this for > >>>> all boards is to let the thermal driver read the temperature grading > >>>> from the OTP fuses and set the trip-points accordingly, similar to > >>>> what is done on i.MX6 [1]. > >>>>>> > >>> ... > >>>>> > >>>>> Frieder, > >>>>> > >>>>> Yes, I thought about adding that kind of support to imx8mm_thermal.c > >>>>> but the difference is that imx8mm has alerts defined by dt and imx6 > >>>>> does not so is it right to override dt alerts on imx8m? What if > >>>>> someone designs a board that they specifically want a lower alert > >>>>> than the cpu grade they are using based on something else on the board? > >>>>> > >>>>> My approach to this was to eventually actually adjust the imx8m dt > >>>>> alerts in boot firmware based on some boot firmware setting or > >>>>> specific board support and leave the kernel alone. > >>>> > >>>> Allowing board-specific trip points sounds like a valid request, but > >>>> I still think we need a way to handle the temperature grading in the > >>>> driver if no board-specific trip-points are given. > >>>> > >>>> What if we just set the temperature property in the trip nodes in > >>>> imx8mm.dtsi to zero? The thermal driver would detect this and setup > >>>> the correct values according to the grading. If the dt already > >>>> provides non-zero temperature values (through the board dts) the > >>>> driver will just leave the values and disregard the grading. > >>>> > >>>> I think this solution would be covering all needs. > >>> > >>> I thought to add the grading check in the imx8mm_thermal.c to > >>> dynamically set the trip points temp, but it seems hard to do it due > >>> to the fact of_thermal is used, as no helper API is exported by of_thermal, > >> no better way to override the trip point temp. > >>> > >>> glad to see any good suggestions. > >> > >> Right, the driver doesn't handle the trip-points directly. This is all hidden in the > >> framework. So this might not be so easy to implement. > >> > >> What about this other approach: Adding all the possible trip-points for the > >> different gradings to the SoC-devicetree and then let the thermal driver > >> remove the trip nodes from the dt that are not valid for the detected grading, > >> just before the driver registers the sensor/zone. > > > > It is more reasonable for the firmware/bootloader to handle this by checking the grading. > > If possible, I would rather like to avoid creating another dependency on bootloader/firmware. I think the kernel should be able to detect the grading by itself and adjust its behavior accordingly. We also do this for the speed grading in cpufreq. Frieder and Jacky, I'm ok with dropping this dt patch and instead implementing something in boot firmware that automatically detects and adjusts there. I'm not given the time to work through a more complicated or more elegant solution kernel-only approach for this and handling it in the boot firmware will not break anything or create a dependence from where we currently stand. We already have things in boot firmware that populate mac addresses, mtd partition ids, etc in dt during runtime. Best regards, Tim ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp 2021-06-11 18:55 ` Tim Harvey @ 2021-06-29 7:48 ` Frieder Schrempf 0 siblings, 0 replies; 18+ messages in thread From: Frieder Schrempf @ 2021-06-29 7:48 UTC (permalink / raw) To: Tim Harvey Cc: Jacky Bai, Rob Herring, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dl-linux-imx, Device Tree Mailing List, Linux ARM Mailing List, Zhang Rui, Daniel Lezcano, Amit Kucheria, linux-pm Hi Tim, On 11.06.21 20:55, Tim Harvey wrote: > On Mon, Jun 7, 2021 at 1:34 AM Frieder Schrempf > <frieder.schrempf@kontron.de> wrote: >> >> On 07.06.21 10:00, Jacky Bai wrote: >>>> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override >>>> thermal cfg for industrial temp >>>> >>>> On 07.06.21 09:30, Jacky Bai wrote: >>>>>> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override >>>>>> thermal cfg for industrial temp >>>>>> >>>>>> On 04.06.21 17:42, Tim Harvey wrote: >>>>>>> On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf >>>>>>> <frieder.schrempf@kontron.de> wrote: >>>>>>>> >>>>>>>> On 01.06.21 19:49, Tim Harvey wrote: >>>>>>>>> Override the default temperature alert/crit for Industrial temp >>>>>>>>> IMX8M Mini. >>>>>>>>> >>>>>>>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com> >>>>>>>>> --- >>>>>>>>> .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 12 >>>>>> ++++++++++++ >>>>>>>>> 1 file changed, 12 insertions(+) >>>>>>>>> >>>>>>>>> diff --git >>>>>>>>> a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>>>> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>>>> index c769fadbd008..512b76cd7c3b 100644 >>>>>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi >>>>>>>>> @@ -493,3 +493,15 @@ >>>>>>>>> >; >>>>>>>>> }; >>>>>>>>> }; >>>>>>>>> + >>>>>>>>> +&cpu_alert0 { >>>>>>>>> + temperature = <95000>; >>>>>>>>> + hysteresis = <2000>; >>>>>>>>> + type = "passive"; >>>>>>>>> +}; >>>>>>>>> + >>>>>>>>> +&cpu_crit0 { >>>>>>>>> + temperature = <105000>; >>>>>>>>> + hysteresis = <2000>; >>>>>>>>> + type = "critical"; >>>>>>>>> +}; >>>>>>>> >>>>>>>> As this is not really board-specific, I think the proper way to >>>>>>>> handle this for >>>>>> all boards is to let the thermal driver read the temperature grading >>>>>> from the OTP fuses and set the trip-points accordingly, similar to >>>>>> what is done on i.MX6 [1]. >>>>>>>> >>>>> ... >>>>>>> >>>>>>> Frieder, >>>>>>> >>>>>>> Yes, I thought about adding that kind of support to imx8mm_thermal.c >>>>>>> but the difference is that imx8mm has alerts defined by dt and imx6 >>>>>>> does not so is it right to override dt alerts on imx8m? What if >>>>>>> someone designs a board that they specifically want a lower alert >>>>>>> than the cpu grade they are using based on something else on the board? >>>>>>> >>>>>>> My approach to this was to eventually actually adjust the imx8m dt >>>>>>> alerts in boot firmware based on some boot firmware setting or >>>>>>> specific board support and leave the kernel alone. >>>>>> >>>>>> Allowing board-specific trip points sounds like a valid request, but >>>>>> I still think we need a way to handle the temperature grading in the >>>>>> driver if no board-specific trip-points are given. >>>>>> >>>>>> What if we just set the temperature property in the trip nodes in >>>>>> imx8mm.dtsi to zero? The thermal driver would detect this and setup >>>>>> the correct values according to the grading. If the dt already >>>>>> provides non-zero temperature values (through the board dts) the >>>>>> driver will just leave the values and disregard the grading. >>>>>> >>>>>> I think this solution would be covering all needs. >>>>> >>>>> I thought to add the grading check in the imx8mm_thermal.c to >>>>> dynamically set the trip points temp, but it seems hard to do it due >>>>> to the fact of_thermal is used, as no helper API is exported by of_thermal, >>>> no better way to override the trip point temp. >>>>> >>>>> glad to see any good suggestions. >>>> >>>> Right, the driver doesn't handle the trip-points directly. This is all hidden in the >>>> framework. So this might not be so easy to implement. >>>> >>>> What about this other approach: Adding all the possible trip-points for the >>>> different gradings to the SoC-devicetree and then let the thermal driver >>>> remove the trip nodes from the dt that are not valid for the detected grading, >>>> just before the driver registers the sensor/zone. >>> >>> It is more reasonable for the firmware/bootloader to handle this by checking the grading. >> >> If possible, I would rather like to avoid creating another dependency on bootloader/firmware. I think the kernel should be able to detect the grading by itself and adjust its behavior accordingly. We also do this for the speed grading in cpufreq. > > Frieder and Jacky, > > I'm ok with dropping this dt patch and instead implementing something > in boot firmware that automatically detects and adjusts there. I'm not > given the time to work through a more complicated or more elegant > solution kernel-only approach for this and handling it in the boot > firmware will not break anything or create a dependence from where we > currently stand. We already have things in boot firmware that populate > mac addresses, mtd partition ids, etc in dt during runtime. From my point of view you can also keep this patch until this is solved properly. Still, in the long run I think we need a solution that automatically handles the different SoC temperature gradings even if of_thermal is used and there is only a single devicetree to describe the SoC variants. It's similar to the case of the CPU's frequency/voltage setpoints in cpufreq. I'm Cc-ing people from the thermal subsystem. Maybe they have some suggestion or this case has already been discussed elsewhere. Best regards Frieder ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-07-27 16:05 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-01 17:49 [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Tim Harvey 2021-06-01 17:49 ` [PATCH 2/4] arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config Tim Harvey 2021-07-24 18:19 ` Tim Harvey 2021-07-26 1:01 ` Shawn Guo 2021-07-27 16:05 ` Tim Harvey 2021-06-01 17:49 ` [PATCH 3/4] arm64: dts: imx8mm-venice-gw7901: add support for USB hub subload Tim Harvey 2021-07-24 18:21 ` Tim Harvey 2021-06-01 17:49 ` [PATCH 4/4] arm64: dts: imx8mm-venice-gw7901: enable pull-down on gpio outputs Tim Harvey 2021-07-24 18:19 ` Tim Harvey 2021-06-02 7:10 ` [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp Frieder Schrempf 2021-06-04 15:42 ` Tim Harvey 2021-06-07 7:20 ` Frieder Schrempf 2021-06-07 7:30 ` Jacky Bai 2021-06-07 7:53 ` Frieder Schrempf 2021-06-07 8:00 ` Jacky Bai 2021-06-07 8:34 ` Frieder Schrempf 2021-06-11 18:55 ` Tim Harvey 2021-06-29 7:48 ` Frieder Schrempf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).