* [PATCH 0/6] arm64: dts: rockchip: ROC-PC fixes
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
This series is trying to fix the Linux boot and other
regulators stuff for ROC-RK3399-PC board.
patch 1: attach pinctrl to pwm2 pin
patch 2-4: libretech naming conventions
patch 5-6: regulator renaming, input rails fixes
Any inputs?
Jagan.
Jagan Teki (6):
arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin
dt-bindings: arm: rockchip: Use libretech for roc-pc binding
arm64: dts: rockchip: Use libretech model, compatible for ROC-PC
arm64: dts: rockchip: Rename roc-pc with libretech notation
arm64: dts: rockchip: Rename vcc12v_sys into dc_12v for roc-rk3399-pc
arm64: dts: rockchip: Fix roc-rk3399-pc regulator input rails
.../devicetree/bindings/arm/rockchip.yaml | 11 +++---
arch/arm64/boot/dts/rockchip/Makefile | 2 +-
...dts => rk3399-libretech-roc-rk3399-pc.dts} | 38 ++++++++++---------
3 files changed, 27 insertions(+), 24 deletions(-)
rename arch/arm64/boot/dts/rockchip/{rk3399-roc-pc.dts => rk3399-libretech-roc-rk3399-pc.dts} (95%)
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/6] arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
In-Reply-To: <20190919052822.10403-1-jagan@amarulasolutions.com>
ROC-PC is not able to boot linux console if PWM2_d is
unattached to any pinctrl logic.
To be precise the linux boot hang with last logs as,
...
.....
[ 0.003367] Console: colour dummy device 80x25
[ 0.003788] printk: console [tty0] enabled
[ 0.004178] printk: bootconsole [uart8250] disabled
In ROC-PC the PWM2_d pin is connected to LOG_DVS_PWM of
VDD_LOG. So, for normal working operations this needs to
active and pull-down.
This patch fix, by attaching pinctrl active and pull-down
the pwm2.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
index 19f7732d728c..c53f3d571620 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
@@ -548,6 +548,8 @@
};
&pwm2 {
+ pinctrl-names = "active";
+ pinctrl-0 = <&pwm2_pin_pull_down>;
status = "okay";
};
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/6] dt-bindings: arm: rockchip: Use libretech for roc-pc binding
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
In-Reply-To: <20190919052822.10403-1-jagan@amarulasolutions.com>
Though the ROC-PC is manufactured by firefly, it is co-designed
by libretch like other Libretech computer boards from allwinner,
amlogic does.
So, it is always meaningful to keep maintain those vendors who
are part of design participation so-that the linux mainline
code will expose outside world who are the makers of such
hardware prototypes.
So, update the dt-bindings of ROC-PC with libretch notation
like other libretech computer boards does.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 110fcca1a94e..bb65a10e85ce 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -87,11 +87,6 @@ properties:
- const: firefly,roc-rk3328-cc
- const: rockchip,rk3328
- - description: Firefly ROC-RK3399-PC
- items:
- - const: firefly,roc-rk3399-pc
- - const: rockchip,rk3399
-
- description: FriendlyElec NanoPi4 series boards
items:
- enum:
@@ -364,6 +359,12 @@ properties:
- const: leez,p710
- const: rockchip,rk3399
+ - description: Libre Computer Board ROC-RK3399-PC
+ items:
+ - const: libretech,roc-rk3399-pc
+ - const: firefly,roc-rk3399-pc
+ - const: rockchip,rk3399
+
- description: Mecer Xtreme Mini S6
items:
- const: mecer,xms6
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/6] arm64: dts: rockchip: Use libretech model, compatible for ROC-PC
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
In-Reply-To: <20190919052822.10403-1-jagan@amarulasolutions.com>
Though the ROC-PC is manufactured by firefly, it is co-designed
by libretch like other Libretech computer boards from allwinner,
amlogic does.
So, it is always meaningful to keep maintain those vendors who
are part of design participation so-that the linux mainline
code will expose outside world who are the makers of such
hardware prototypes.
So,
- append the compatible to "libretech,roc-rk3399-pc" and
- update the model to "Libre Computer Board ROC-RK3399-PC"
like other libretech computer boards does.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
index c53f3d571620..e09bcbdd92f5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
@@ -9,8 +9,8 @@
#include "rk3399-opp.dtsi"
/ {
- model = "Firefly ROC-RK3399-PC Board";
- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
+ model = "Libre Computer Board ROC-RK3399-PC";
+ compatible = "libretech,roc-rk3399-pc", "firefly,roc-rk3399-pc", "rockchip,rk3399";
chosen {
stdout-path = "serial2:1500000n8";
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/6] arm64: dts: rockchip: Rename roc-pc with libretech notation
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
In-Reply-To: <20190919052822.10403-1-jagan@amarulasolutions.com>
Though the ROC-PC is manufactured by firefly, it is co-designed
by libretch like other Libretech computer boards from allwinner,
amlogic does.
So, it is always meaningful to keep maintain those vendors who
are part of design participation so-that the linux mainline
code will expose outside world who are the makers of such
hardware prototypes.
So, rename the existing rk3399-roc-pc.dts with libretch notation,
rk3399-libretech-roc-rk3399-pc.dts
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 2 +-
.../{rk3399-roc-pc.dts => rk3399-libretech-roc-rk3399-pc.dts} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm64/boot/dts/rockchip/{rk3399-roc-pc.dts => rk3399-libretech-roc-rk3399-pc.dts} (100%)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 1f18a9392d15..73c10ddb4300 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -21,12 +21,12 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-libretech-roc-rk3399-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
-dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
similarity index 100%
rename from arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
rename to arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/6] arm64: dts: rockchip: Rename vcc12v_sys into dc_12v for roc-rk3399-pc
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
In-Reply-To: <20190919052822.10403-1-jagan@amarulasolutions.com>
It is always better practice to follow regulator naming conventions
as per the schematics for future references.
This would indeed helpful to review and check the naming convention
directly on schematics, both for the code reviewers and the developers.
So, rename vcc12v_sys into dc_12v as per rk3399 power tree as per
roc-rk3399-pc schematics.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
.../boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
index e09bcbdd92f5..51242ea5447d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
@@ -57,9 +57,9 @@
* should be placed inside mp8859, but not until mp8859 has
* its own dt-binding.
*/
- vcc12v_sys: mp8859-dcdc1 {
+ dc_12v: mp8859-dcdc1 {
compatible = "regulator-fixed";
- regulator-name = "vcc12v_sys";
+ regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <12000000>;
@@ -85,7 +85,7 @@
regulator-boot-on;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
- vin-supply = <&vcc12v_sys>;
+ vin-supply = <&dc_12v>;
};
/* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
@@ -118,7 +118,7 @@
regulator-boot-on;
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc12v_sys>;
+ vin-supply = <&dc_12v>;
};
vdd_log: vdd-log {
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 6/6] arm64: dts: rockchip: Fix roc-rk3399-pc regulator input rails
From: Jagan Teki @ 2019-09-19 5:28 UTC (permalink / raw)
To: Heiko Stuebner, Levin Du, Akash Gajjar, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-rockchip, Jagan Teki, Da Xue,
linux-amarula, linux-arm-kernel
In-Reply-To: <20190919052822.10403-1-jagan@amarulasolutions.com>
Few, know rk808 pmic regulators VCC[1-4], VCC[6-7], VCC[9-11],
VDD_LOG, VDD_GPU, VDD_CPU_B, VCC3V3_SYS are inputting with vcc_sys
which is 5V power rail from dc_12v.
So, replace the vin-supply of above mentioned regulators
with vcc_sys as per the PMIC-RK808-D page of roc-rk3399-pc
schematics.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
.../rk3399-libretech-roc-rk3399-pc.dts | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
index 51242ea5447d..1eddb2e00809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
@@ -85,7 +85,7 @@
regulator-boot-on;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
- vin-supply = <&dc_12v>;
+ vin-supply = <&vcc_sys>;
};
/* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
@@ -129,7 +129,7 @@
regulator-boot-on;
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1400000>;
- vin-supply = <&vcc3v3_sys>;
+ vin-supply = <&vcc_sys>;
};
};
@@ -202,16 +202,16 @@
rockchip,system-power-controller;
wakeup-source;
- vcc1-supply = <&vcc3v3_sys>;
- vcc2-supply = <&vcc3v3_sys>;
- vcc3-supply = <&vcc3v3_sys>;
- vcc4-supply = <&vcc3v3_sys>;
- vcc6-supply = <&vcc3v3_sys>;
- vcc7-supply = <&vcc3v3_sys>;
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
vcc8-supply = <&vcc3v3_sys>;
- vcc9-supply = <&vcc3v3_sys>;
- vcc10-supply = <&vcc3v3_sys>;
- vcc11-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc_sys>;
+ vcc10-supply = <&vcc_sys>;
+ vcc11-supply = <&vcc_sys>;
vcc12-supply = <&vcc3v3_sys>;
vddio-supply = <&vcc1v8_pmu>;
@@ -385,7 +385,7 @@
regulator-ramp-delay = <1000>;
regulator-always-on;
regulator-boot-on;
- vin-supply = <&vcc3v3_sys>;
+ vin-supply = <&vcc_sys>;
regulator-state-mem {
regulator-off-in-suspend;
@@ -404,7 +404,7 @@
regulator-ramp-delay = <1000>;
regulator-always-on;
regulator-boot-on;
- vin-supply = <&vcc3v3_sys>;
+ vin-supply = <&vcc_sys>;
regulator-state-mem {
regulator-off-in-suspend;
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-09-19 5:36 UTC (permalink / raw)
To: Jassi Brar, Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY2G8s9gV8Pu+f__8-bubjCJsVQrQikbVMZXmpTwSMBxiQ@mail.gmail.com>
Hi Jassi,
> Subject: Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, Sep 18, 2019 at 5:00 AM Andre Przywara
> <andre.przywara@arm.com> wrote:
>
> > >
> > > >
> > > > > + };
> > > > > +};
> > > >
> > > > If this is the data structure that this mailbox controller uses, I
> > > > would expect this to be documented somewhere, or even exported.
> > >
> > > Export this structure in include/linux/mailbox/smc-mailbox.h?
> >
> > For instance, even though I am not sure this is really desired or helpful, since
> we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that
> mailbox.
> >
> > But at least the expected format should be documented, which could just be
> in writing, not necessarily in code.
> >
> Yes, the packet format is specified by the controller and defined in some
> header for clients to include. Other platforms do that already.
So you prefer add the structure in include/linux/mailbox/smc-mailbox.h?
Thanks,
Peng.
>
>
>
> > > > > +
> > > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
> > > > > + unsigned long, unsigned long,
> > > > > + unsigned long, unsigned long,
> > > > > + unsigned long); static
> smc_mbox_fn
> > > > > +*invoke_smc_mbox_fn;
> > > > > +
> > > > > +static int arm_smc_send_data(struct mbox_chan *link, void
> > > > > +*data) { struct arm_smc_chan_data *chan_data = link->con_priv;
> > > > > +struct arm_smccc_mbox_cmd *cmd = data; unsigned long ret;
> > > > > + u32 function_id;
> > > > > +
> > > > > + function_id = chan_data->function_id; if (!function_id)
> > > > > + function_id = cmd->function_id;
> > > > > +
> > > > > + if (function_id & BIT(30)) {
> > > >
> > > > if (ARM_SMCCC_IS_64(function_id)) {
> > >
> > > ok
> > >
> > > >
> > > > > + ret = invoke_smc_mbox_fn(function_id,
> cmd->args_smccc64[0],
> > > > > + cmd->args_smccc64[1],
> > > > > + cmd->args_smccc64[2],
> > > > > + cmd->args_smccc64[3],
> > > > > + cmd->args_smccc64[4],
> > > > > + cmd->args_smccc64[5]); }
> else
> > > > > + {
> > > > > + ret = invoke_smc_mbox_fn(function_id,
> cmd->args_smccc32[0],
> > > > > + cmd->args_smccc32[1],
> > > > > + cmd->args_smccc32[2],
> > > > > + cmd->args_smccc32[3],
> > > > > + cmd->args_smccc32[4],
> > > > > + cmd->args_smccc32[5]); }
> > > > > +
> > > > > + mbox_chan_received_data(link, (void *)ret);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static unsigned long __invoke_fn_hvc(unsigned int function_id,
> > > > > + unsigned long arg0, unsigned
> long arg1,
> > > > > + unsigned long arg2, unsigned
> long arg3,
> > > > > + unsigned long arg4, unsigned
> long
> > > > > +arg5) { struct arm_smccc_res res;
> > > > > +
> > > > > + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > > + arg5, 0, &res);
> > > > > + return res.a0;
> > > > > +}
> > > > > +
> > > > > +static unsigned long __invoke_fn_smc(unsigned int function_id,
> > > > > + unsigned long arg0, unsigned
> long arg1,
> > > > > + unsigned long arg2, unsigned
> long arg3,
> > > > > + unsigned long arg4, unsigned
> long
> > > > > +arg5) { struct arm_smccc_res res;
> > > > > +
> > > > > + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > > + arg5, 0, &res);
> > > > > + return res.a0;
> > > > > +}
> > > > > +
> > > > > +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
> > > > > + .send_data = arm_smc_send_data,
> > > > > +};
> > > > > +
> > > > > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > > > > +struct device *dev = &pdev->dev; struct mbox_controller *mbox;
> > > > > +struct arm_smc_chan_data *chan_data; int ret;
> > > > > + u32 function_id = 0;
> > > > > +
> > > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox"))
> > > > > + invoke_smc_mbox_fn = __invoke_fn_smc; else
> > > > > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > > > > +
> > > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); if
> > > > > + (!mbox)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + mbox->num_chans = 1;
> > > > > + mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans),
> > > > > + mbox->GFP_KERNEL);
> > > > > + if (!mbox->chans)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL);
> > > > > + if (!chan_data)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + of_property_read_u32(dev->of_node, "arm,func-id",
> > > > > + &function_id); chan_data->function_id = function_id;
> > > > > +
> > > > > + mbox->chans->con_priv = chan_data;
> > > > > +
> > > > > + mbox->txdone_poll = false;
> > > > > + mbox->txdone_irq = false;
> > > >
> > > > Don't we need to provide something to confirm reception to the
> > > > client? In our case we can set this as soon as the smc/hvc returns.
> > >
> > > As smc/hvc returns, it means the transfer is over and receive is done.
> >
> > I understand that, but was wondering if the Linux mailbox framework knows
> about that? In my older version I was calling mbox_chan_received_data()
> after the smc call returned.
> >
> The code already does that at the end of send_data
>
> > Also there is mbox_chan_txdone() with which a controller driver can signal
> TX completion explicitly.
> >
> No. Controller can use that only if it has specified txdone_irq, which is not the
> case here.
>
> Thanks
_______________________________________________
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 V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-19 5:41 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, Gerald Schaefer, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Kirill A . Shutemov,
Dan Williams, Vlastimil Babka, linux-arm-kernel,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <955491d9-d8aa-0a93-4fb9-3d15acfbcbf8@arm.com>
Le 19/09/2019 à 06:56, Anshuman Khandual a écrit :
>
>
> On 09/18/2019 09:56 PM, Christophe Leroy wrote:
>>
>>
>> Le 18/09/2019 à 07:04, Anshuman Khandual a écrit :
>>>
>>>
>>> On 09/13/2019 03:31 PM, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :
>>>>>
>>>>>>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>>>>
>>>>>> #ifdefs have to be avoided as much as possible, see below
>>>>>
>>>>> Yeah but it has been bit difficult to avoid all these $ifdef because of the
>>>>> availability (or lack of it) for all these pgtable helpers in various config
>>>>> combinations on all platforms.
>>>>
>>>> As far as I can see these pgtable helpers should exist everywhere at least via asm-generic/ files.
>>>
>>> But they might not actually do the right thing.
>>>
>>>>
>>>> Can you spot a particular config which fails ?
>>>
>>> Lets consider the following example (after removing the $ifdefs around it)
>>> which though builds successfully but fails to pass the intended test. This
>>> is with arm64 config 4K pages sizes with 39 bits VA space which ends up
>>> with a 3 level page table arrangement.
>>>
>>> static void __init p4d_clear_tests(p4d_t *p4dp)
>>> {
>>> p4d_t p4d = READ_ONCE(*p4dp);
>>
>> My suggestion was not to completely drop the #ifdef but to do like you did in pgd_clear_tests() for instance, ie to add the following test on top of the function:
>>
>> if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
>> return;
>>
>
> Sometimes this does not really work. On some platforms, combination of
> __PAGETABLE_PUD_FOLDED and __ARCH_HAS_5LEVEL_HACK decide whether the
> helpers such as __pud() or __pgd() is even available for that platform.
> Ideally it should have been through generic falls backs in include/*/
> but I guess there might be bugs on the platform or it has not been
> changed to adopt 5 level page table framework with required folding
> macros etc.
Yes. As I suggested below, most likely that's better to retain the
#ifdef __ARCH_HAS_5LEVEL_HACK but change the #ifdef
__PAGETABLE_PUD_FOLDED by a runtime test of mm_pud_folded(mm)
As pointed by Gerald, some arches don't have __PAGETABLE_PUD_FOLDED
because they are deciding dynamically if they fold the level on not, but
have mm_pud_folded(mm)
>
>>>
>>> p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
>>> WRITE_ONCE(*p4dp, p4d);
>>> p4d_clear(p4dp);
>>> p4d = READ_ONCE(*p4dp);
>>> WARN_ON(!p4d_none(p4d));
>>> }
>>>
>>> The following test hits an error at WARN_ON(!p4d_none(p4d))
>>>
>>> [ 16.757333] ------------[ cut here ]------------
>>> [ 16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187 arch_pgtable_tests_init+0x24c/0x474
[...]
>>> [ 16.781282] ---[ end trace 042e6c40c0a3b038 ]---
>>>
>>> On arm64 (4K page size|39 bits VA|3 level page table)
>>>
>>> #elif CONFIG_PGTABLE_LEVELS == 3 /* Applicable here */
>>> #define __ARCH_USE_5LEVEL_HACK
>>> #include <asm-generic/pgtable-nopud.h>
>>>
>>> Which pulls in
>>>
>>> #include <asm-generic/pgtable-nop4d-hack.h>
>>>
>>> which pulls in
>>>
>>> #include <asm-generic/5level-fixup.h>
>>>
>>> which defines
>>>
>>> static inline int p4d_none(p4d_t p4d)
>>> {
>>> return 0;
>>> }
>>>
>>> which will invariably trigger WARN_ON(!p4d_none(p4d)).
>>>
>>> Similarly for next test p4d_populate_tests() which will always be
>>> successful because p4d_bad() invariably returns negative.
>>>
>>> static inline int p4d_bad(p4d_t p4d)
>>> {
>>> return 0;
>>> }
>>>
>>> static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
>>> pud_t *pudp)
>>> {
>>> p4d_t p4d;
>>>
>>> /*
>>> * This entry points to next level page table page.
>>> * Hence this must not qualify as p4d_bad().
>>> */
>>> pud_clear(pudp);
>>> p4d_clear(p4dp);
>>> p4d_populate(mm, p4dp, pudp);
>>> p4d = READ_ONCE(*p4dp);
>>> WARN_ON(p4d_bad(p4d));
>>> }
>>>
>>> We should not run these tests for the above config because they are
>>> not applicable and will invariably produce same result.
>>>
[...]
>>>>
>>>> So it shouldn't be an issue. Maybe if a couple of arches miss them, the best would be to fix the arches, since that's the purpose of your testsuite isn't it ?
>>>
>>> The run time failures as explained previously is because of the folding which
>>> needs to be protected as they are not even applicable. The compile time
>>> failures are because pxx_populate() signatures are platform specific depending
>>> on how many page table levels they really support.
>>>
>>
>> So IIUC, the compiletime problem is around __ARCH_HAS_5LEVEL_HACK. For all #if !defined(__PAGETABLE_PXX_FOLDED), something equivalent to the following should make the trick.
>>
>> if (mm_pxx_folded())
>> return;
>>
>>
>> For the __ARCH_HAS_5LEVEL_HACK stuff, I think we should be able to regroup all impacted functions inside a single #ifdef __ARCH_HAS_5LEVEL_HACK
>
> I was wondering if it will be better to
>
> 1) Minimize all #ifdefs in the code which might fail on some platforms
> 2) Restrict proposed test module to platforms where it builds and runs
> 3) Enable other platforms afterwards after fixing their build problems or other requirements
I understand that __ARCH_HAS_5LEVEL_HACK is an HACK as its name
suggests, so you can't expect all platforms to go for an HACK. I think
you can keep a single #ifdef __ARCH_HAS_5LEVEL_HACK / #else / #endif and
put all relevant tests inside it.
For things like __PAGETABLE_PXX_FOLDED dependancies, I still think that
they can all be replaced by a runtime test of mm_pxx_folded().
Can you try that and see what problem remains ?
>
> Would that be a better approach instead ?
>
Based on the above, that might be the approach to take, yes.
Christophe
_______________________________________________
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] mm/pgtable/debug: Fix test validating architecture page table helpers
From: Christophe Leroy @ 2019-09-19 5:44 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Dave Hansen, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, Jason Gunthorpe, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Tetsuo Handa, Vlastimil Babka, linux-snps-arc, Kees Cook,
Mark Brown, Kirill A . Shutemov, Thomas Gleixner, Gerald Schaefer,
linux-arm-kernel, Sri Krishna chowdary, Masahiro Yamada,
Greg Kroah-Hartman, Ard Biesheuvel, linux-mips, Ralf Baechle,
linux-kernel, Paul Burton, Mike Rapoport, Vineet Gupta,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <cb338e2e-23b1-b8af-811c-57feb6f4e7b4@arm.com>
Le 18/09/2019 à 09:32, Anshuman Khandual a écrit :
>
>
> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>> Fix build failure on powerpc.
>>
>> Fix preemption imbalance.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> mm/arch_pgtable_test.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>> --- a/mm/arch_pgtable_test.c
>> +++ b/mm/arch_pgtable_test.c
>> @@ -24,6 +24,7 @@
>> #include <linux/swap.h>
>> #include <linux/swapops.h>
>> #include <linux/sched/mm.h>
>> +#include <linux/highmem.h>
>> #include <asm/pgalloc.h>
>> #include <asm/pgtable.h>
>>
>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>> p4d_clear_tests(p4dp);
>> pgd_clear_tests(mm, pgdp);
>>
>> + pte_unmap(ptep);
>> +
>> pmd_populate_tests(mm, pmdp, saved_ptep);
>> pud_populate_tests(mm, pudp, saved_pmdp);
>> p4d_populate_tests(mm, p4dp, saved_pudp);
>>
>
> Hello Christophe,
>
> I am planning to fold this fix into the current patch and retain your
> Signed-off-by. Are you okay with it ?
>
No problem, do whatever is convenient for you. You can keep the
signed-off-by, or use tested-by: as I tested it on PPC32.
Christophe
_______________________________________________
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 v2] of: restore old handling of cells_name=NULL in of_*_phandle_with_args()
From: Uwe Kleine-König @ 2019-09-19 6:19 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Geert Uytterhoeven, Robin Murphy,
Joerg Roedel, linux-kernel@vger.kernel.org, Will Deacon,
linux-mediatek@lists.infradead.org, kernel@pengutronix.de,
Matthias Brugger, Geert Uytterhoeven, Frank Rowand, Peter Rosin,
linux-arm-kernel@lists.infradead.org, Marek Szyprowski
In-Reply-To: <20190918201954.2phyqxqhoj5jwklt@pengutronix.de>
On Wed, Sep 18, 2019 at 10:19:54PM +0200, Uwe Kleine-König wrote:
> On Wed, Sep 18, 2019 at 03:09:06PM -0500, Rob Herring wrote:
> > Can I get a proper patch please.
>
> I don't understand what is wrong with my patch. Can you please expand
> what you are missing? I just tried to git-am it and the result looks
> fine.
I see that the commit this patch is fixing isn't in Linus' tree yet. Do
you want instead of this commit fixing the previous one a single good
patch that replaces e42ee61017f5 ("of: Let of_for_each_phandle fallback
to non-negative cell_count")?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 v2] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
From: kbuild test robot @ 2019-09-19 6:40 UTC (permalink / raw)
To: Fancy Fang
Cc: s.hauer@pengutronix.de, sboyd@kernel.org, mturquette@baylibre.com,
linux-kernel@vger.kernel.org, kbuild-all, kernel@pengutronix.de,
shawnguo@kernel.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <20190919030912.16957-1-chen.fang@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
Hi Fancy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190918]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Fancy-Fang/clk-imx7ulp-remove-IMX7ULP_CLK_MIPI_PLL-clock/20190919-111243
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/imx7ulp.dtsi:279.13-14 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 71749 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v2 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Lukasz Luba @ 2019-09-19 6:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, devicetree, willy.mh.wolff.ml,
linux-samsung-soc@vger.kernel.org,
Bartłomiej Żołnierkiewicz, linux-pm,
linux-kernel@vger.kernel.org, robh+dt, Chanwoo Choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPcxG-mMKy5u-b0+xj_sOmrq5yq5-LYJx0Ds6_+yo_=JbA@mail.gmail.com>
Hi Krzysztof,
On 9/18/19 8:51 PM, Krzysztof Kozlowski wrote:
> On Mon, 16 Sep 2019 at 12:07, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>
>> Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings.
>> Introduce minor fixes in the old documentation.
>>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>> Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>> index 3b2485b84b3f..49afe794daaa 100644
>> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
>> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>> @@ -1,7 +1,9 @@
>> * LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C
>>
>> Required properties:
>> -- compatible : Should be - "jedec,lpddr3"
>> +- compatible : should be one of the following:
>> + Generic default - "jedec,lpddr3".
>
> The convention is first compatible, then description. I gave you the
> example to base on - at25. Why making it different?
I have checked at25 that you pointed me to and also checked at24, which
has a bit longer "compatible" section.
I found that there are many "jedec,spi-nor" compatible devices, which I
thought would be a better example for my "jedec,lpddr3".
For example, two configurations, where you have a single labels or dual
(with specific device)
arch/arm/boot/dts/imx6dl-rex-basic.dts:
compatible = "sst,sst25vf016b", "jedec,spi-nor";
arch/arm/boot/dts/imx6q-ba16.dtsi:
compatible = "jedec,spi-nor";
The 'compatible' in documentation for the "jedec,spi-nor" is slightly
different (similar to at24).
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
It has a long explanation, which is also OK. So I thought that it is
quite flexible what you put in there.
I have also checked Cadance QSPI controller.
Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
The controller might be built-in into different vendor SoC's
and the "compatible" is ready to reflect it in similar fashion but
with a short explanation in this section.
Therefore, what you see in the patch draw heavily on Cadence's qspi,
with a bit of inspiration from jedec,spi-nor usage.
Should I change it to at25 "compatible" style and send next patch?
PS. Thank you for taking the other two patches. I will not respond in
their threads to keep the traffic low.
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-19 7:04 UTC (permalink / raw)
To: Y.b. Lu
Cc: dann frazier, Will Deacon, Adrian Hunter, Leo Li, Nicolin Chen,
linux-mmc, Fabio Estevam, Christoph Hellwig, Linux ARM
In-Reply-To: <VI1PR0401MB22376A0EA85123B2AEB72EDEF8890@VI1PR0401MB2237.eurprd04.prod.outlook.com>
Hi,
This is not the issue, since the problem has been observed with eMMC
too, and is sporadic in nature.
Please could you answer the question posed: are the eSDHC controllers
DMA coherent or are they not coherent?
Thanks.
On Thu, Sep 19, 2019 at 04:13:20AM +0000, Y.b. Lu wrote:
> Sorry. My email was rejected by mailing lists. Let me re-send.
>
> Hi Russell,
>
> I’m not sure what board you were using for LX2160A.
> We had an known issue for eSDHC controller and all NXP Layerscape RDB boards.
> eSDHC couldn’t provide power-cycle to SD card, and even worse, board reset couldn’t provide power-cycle to SD card either.
> But for UHS-I SD card, it’s required to have a power-cycle to reset card if it goes into UHS-I mode. Otherwise, we don’t know what will happen when kernel initializes SD card after a reboot/reset.
>
> I could reproduce that issue with below steps on latest mainline kernel.
> 1. Power off board, and power on board.
> 2. Start up kernel, the SD card works fine in UHS-I mode.
> 3. Reboot/reset board. (This couldn’t provide power-cycle to SD card)
> 4. Start up kernel, the SD card gets that ADMA error issue.
>
> So could you have a try to power off/power on the board, and then start up kernel. Don’t use reboot, or board reset button.
> Or you can remove SD card and start up kernel, and insert SD card when kernel has been started up.
> Thanks a lot.
>
> Best regards,
> Yangbo Lu
>
>
> From: Li Yang <leoyang.li@nxp.com>
> Sent: Wednesday, September 18, 2019 1:48 AM
> To: Fabio Estevam <festevam@gmail.com>; Y.b. Lu <yangbo.lu@nxp.com>
> Cc: Adrian Hunter <adrian.hunter@intel.com>; Christoph Hellwig <hch@lst.de>; Linux ARM <linux-arm-kernel@lists.infradead.org>; Nicolin Chen <nicoleotsuka@gmail.com>; Russell King - ARM Linux admin <linux@armlinux.org.uk>; Will Deacon <will.deacon@arm.com>; dann frazier <dann.frazier@canonical.com>; linux-mmc <linux-mmc@vger.kernel.org>
> Subject: Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
>
>
>
> On Tue, Sep 17, 2019 at 6:31 PM Fabio Estevam <mailto:festevam@gmail.com> wrote:
> [Adding Li Yang]
>
> On Tue, Sep 17, 2019 at 10:52 AM Russell King - ARM Linux admin
> <mailto:linux@armlinux.org.uk> wrote:
>
> > The pressing question seems to be this:
> >
> > Are the eSDHC on the LX2160A DMA coherent or are they not?
> >
> > Any chances of finding out internally what the true answer to that,
> > rather than me poking about trying stuff experimentally? Having a
> > definitive answer for a potentially data-corrupting change would
> > be really good...
>
> Li Yang,
>
> Could you please help to confirm Russell's question?
> Adding Yangbo who is working on SDHC.
>
> Regards,
> Leo
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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 2/3] arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk
From: Schrempf Frieder @ 2019-09-19 7:17 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
leonard.crestez@nxp.com, daniel.lezcano@linaro.org,
ping.bai@nxp.com, daniel.baluta@nxp.com, jun.li@nxp.com,
l.stach@pengutronix.de, abel.vesa@nxp.com,
andrew.smirnov@gmail.com, angus@akkea.ca, ccaione@baylibre.com,
agx@sigxcpu.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Linux-imx@nxp.com
In-Reply-To: <1568869559-28611-2-git-send-email-Anson.Huang@nxp.com>
Hi Anson,
I have a question, that is not directly related to this patch.
I see that for the usdhc1 and usdhc3 nodes, there is an 'assigned-clock'
and 'assigned-clock-rates' property but not for usdhc2. The same applies
to the mx8mq and mx8mn dtsi file.
Is there any reason for this? If not can you fix it?
Thanks,
Frieder
On 19.09.19 07:05, Anson Huang wrote:
> On i.MX8MM, usdhc's ipg clock is from IMX8MM_CLK_IPG_ROOT,
> assign it explicitly instead of using IMX8MM_CLK_DUMMY.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index 7c4dcce..8aafad2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -694,7 +694,7 @@
> compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
> reg = <0x30b40000 0x10000>;
> interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MM_CLK_DUMMY>,
> + clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
> <&clk IMX8MM_CLK_NAND_USDHC_BUS>,
> <&clk IMX8MM_CLK_USDHC1_ROOT>;
> clock-names = "ipg", "ahb", "per";
> @@ -710,7 +710,7 @@
> compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
> reg = <0x30b50000 0x10000>;
> interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MM_CLK_DUMMY>,
> + clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
> <&clk IMX8MM_CLK_NAND_USDHC_BUS>,
> <&clk IMX8MM_CLK_USDHC2_ROOT>;
> clock-names = "ipg", "ahb", "per";
> @@ -724,7 +724,7 @@
> compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
> reg = <0x30b60000 0x10000>;
> interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MM_CLK_DUMMY>,
> + clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
> <&clk IMX8MM_CLK_NAND_USDHC_BUS>,
> <&clk IMX8MM_CLK_USDHC3_ROOT>;
> clock-names = "ipg", "ahb", "per";
>
_______________________________________________
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] mfd: mt6360: add pmic mt6360 driver
From: Lee Jones @ 2019-09-19 7:18 UTC (permalink / raw)
To: Gene Chen
Cc: gene_chen, linux-kernel, linux-mediatek, matthias.bgg, Wilma.Wu,
linux-arm-kernel, shufan_lee
In-Reply-To: <CAE+NS37XG+kfbj6yJrL5A-d2O_aiRU90yV5TUk3Kfa0Rv7dWmw@mail.gmail.com>
On Thu, 19 Sep 2019, Gene Chen wrote:
> Lee Jones <lee.jones@linaro.org> 於 2019年9月18日 週三 下午6:51寫道：
> >
> > On Wed, 18 Sep 2019, Gene Chen wrote:
> >
> > > From: Gene Chen <gene_chen@richtek.com>
> > >
> > > Add mfd driver for mt6360 pmic chip include
> > > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck
> > >
> > > Signed-off-by: Gene Chen <gene_chen@richtek.com
> > > ---
> >
> > This looks different from the one you sent before, but I don't see a
> > version bump or any changelog in this space. Please re-submit with
> > the differences noted.
> >
>
> the change is
> 1. add missing include file
> 2. modify commit message
>
> this patch is regarded as version 1
It's different to the first one you sent to the list, so it needs a
version bump and a change log. There also appears to still be issues
with it, if the auto-builders are to be believed.
Do ensure you thoroughly test your patches before sending upstream.
Please fix the issues and resubmit your v3 with a nice changelog.
> > > drivers/mfd/Kconfig | 12 +
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/mt6360-core.c | 463 +++++++++++++++++++++++++++++++++++++
> > > include/linux/mfd/mt6360-private.h | 279 ++++++++++++++++++++++
> > > include/linux/mfd/mt6360.h | 33 +++
> > > 5 files changed, 788 insertions(+)
> > > create mode 100644 drivers/mfd/mt6360-core.c
> > > create mode 100644 include/linux/mfd/mt6360-private.h
> > > create mode 100644 include/linux/mfd/mt6360.h
> >
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] sched/eas: introduce system-wide overutil indicator
From: YT Chang @ 2019-09-19 7:20 UTC (permalink / raw)
To: Peter Zijlstra, Matthias Brugger
Cc: linux-arm-kernel, YT Chang, linux-mediatek, linux-kernel,
wsd_upstream
When the system is overutilization, the load-balance crossing
clusters will be triggered and scheduler will not use energy
aware scheduling to choose CPUs.
The overutilization means the loading of ANY CPUs
exceeds threshold (80%).
However, only 1 heavy task or while-1 program will run on highest
capacity CPUs and it still result to trigger overutilization. So
the system will not use Energy Aware scheduling.
To avoid it, a system-wide over-utilization indicator to trigger
load-balance cross clusters.
The policy is:
The loading of "ALL CPUs in the highest capacity"
exceeds threshold(80%) or
The loading of "Any CPUs not in the highest capacity"
exceed threshold(80%)
Signed-off-by: YT Chang <yt.chang@mediatek.com>
---
kernel/sched/fair.c | 76 +++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 65 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 036be95..f4c3d70 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5182,10 +5182,71 @@ static inline bool cpu_overutilized(int cpu)
static inline void update_overutilized_status(struct rq *rq)
{
if (!READ_ONCE(rq->rd->overutilized) && cpu_overutilized(rq->cpu)) {
- WRITE_ONCE(rq->rd->overutilized, SG_OVERUTILIZED);
- trace_sched_overutilized_tp(rq->rd, SG_OVERUTILIZED);
+ if (capacity_orig_of(cpu_of(rq)) < rq->rd->max_cpu_capacity) {
+ WRITE_ONCE(rq->rd->overutilized, SG_OVERUTILIZED);
+ trace_sched_overutilized_tp(rq->rd, SG_OVERUTILIZED);
+ }
}
}
+
+static
+void update_system_overutilized(struct sched_domain *sd, struct cpumask *cpus)
+{
+ unsigned long group_util;
+ bool intra_overutil = false;
+ unsigned long max_capacity;
+ struct sched_group *group = sd->groups;
+ struct root_domain *rd;
+ int this_cpu;
+ bool overutilized;
+ int i;
+
+ this_cpu = smp_processor_id();
+ rd = cpu_rq(this_cpu)->rd;
+ overutilized = READ_ONCE(rd->overutilized);
+ max_capacity = rd->max_cpu_capacity;
+
+ do {
+ group_util = 0;
+ for_each_cpu_and(i, sched_group_span(group), cpus) {
+ group_util += cpu_util(i);
+ if (cpu_overutilized(i)) {
+ if (capacity_orig_of(i) < max_capacity) {
+ intra_overutil = true;
+ break;
+ }
+ }
+ }
+
+ /*
+ * A capacity base hint for over-utilization.
+ * Not to trigger system overutiled if heavy tasks
+ * in Big.cluster, so
+ * add the free room(20%) of Big.cluster is impacted which means
+ * system-wide over-utilization,
+ * that considers whole cluster not single cpu
+ */
+ if (group->group_weight > 1 && (group->sgc->capacity * 1024 <
+ group_util * capacity_margin)) {
+ intra_overutil = true;
+ break;
+ }
+
+ group = group->next;
+
+ } while (group != sd->groups && !intra_overutil);
+
+ if (overutilized != intra_overutil) {
+ if (intra_overutil == true) {
+ WRITE_ONCE(rd->overutilized, SG_OVERUTILIZED);
+ trace_sched_overutilized_tp(rd, SG_OVERUTILIZED);
+ } else {
+ WRITE_ONCE(rd->overutilized, 0);
+ trace_sched_overutilized_tp(rd, 0);
+ }
+ }
+}
+
#else
static inline void update_overutilized_status(struct rq *rq) { }
#endif
@@ -8242,15 +8303,6 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
/* update overload indicator if we are at root domain */
WRITE_ONCE(rd->overload, sg_status & SG_OVERLOAD);
-
- /* Update over-utilization (tipping point, U >= 0) indicator */
- WRITE_ONCE(rd->overutilized, sg_status & SG_OVERUTILIZED);
- trace_sched_overutilized_tp(rd, sg_status & SG_OVERUTILIZED);
- } else if (sg_status & SG_OVERUTILIZED) {
- struct root_domain *rd = env->dst_rq->rd;
-
- WRITE_ONCE(rd->overutilized, SG_OVERUTILIZED);
- trace_sched_overutilized_tp(rd, SG_OVERUTILIZED);
}
}
@@ -8476,6 +8528,8 @@ static struct sched_group *find_busiest_group(struct lb_env *env)
*/
update_sd_lb_stats(env, &sds);
+ update_system_overutilized(env->sd, env->cpus);
+
if (sched_energy_enabled()) {
struct root_domain *rd = env->dst_rq->rd;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Krzysztof Kozlowski @ 2019-09-19 7:28 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, willy.mh.wolff.ml,
linux-samsung-soc@vger.kernel.org,
Bartłomiej Żołnierkiewicz, linux-pm,
linux-kernel@vger.kernel.org, robh+dt, Chanwoo Choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <4a0d1d2c-cd1d-5df4-d4b1-f2dd1ef3bb72@partner.samsung.com>
On Thu, 19 Sep 2019 at 08:49, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
> Hi Krzysztof,
>
> On 9/18/19 8:51 PM, Krzysztof Kozlowski wrote:
> > On Mon, 16 Sep 2019 at 12:07, Lukasz Luba <l.luba@partner.samsung.com> wrote:
> >>
> >> Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings.
> >> Introduce minor fixes in the old documentation.
> >>
> >> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> >> ---
> >> Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++++++---
> >> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
> >> index 3b2485b84b3f..49afe794daaa 100644
> >> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
> >> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
> >> @@ -1,7 +1,9 @@
> >> * LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C
> >>
> >> Required properties:
> >> -- compatible : Should be - "jedec,lpddr3"
> >> +- compatible : should be one of the following:
> >> + Generic default - "jedec,lpddr3".
> >
> > The convention is first compatible, then description. I gave you the
> > example to base on - at25. Why making it different?
>
> I have checked at25 that you pointed me to and also checked at24, which
> has a bit longer "compatible" section.
>
> I found that there are many "jedec,spi-nor" compatible devices, which I
> thought would be a better example for my "jedec,lpddr3".
> For example, two configurations, where you have a single labels or dual
> (with specific device)
> arch/arm/boot/dts/imx6dl-rex-basic.dts:
> compatible = "sst,sst25vf016b", "jedec,spi-nor";
> arch/arm/boot/dts/imx6q-ba16.dtsi:
> compatible = "jedec,spi-nor";
>
> The 'compatible' in documentation for the "jedec,spi-nor" is slightly
> different (similar to at24).
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> It has a long explanation, which is also OK. So I thought that it is
> quite flexible what you put in there.
It is flexible but I see clear pattern in existing sources:
jedec,spi-nor.txt
compatible : May include a device-specific ..
...
Supported chip names:
at25df321a
...
at25.txt:
- compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
Example "<vendor>,<type>" values:
"anvo,anv32e61w"
"microchip,25lc040"
In these cases the doc says that "compatible should be" and then you
have the list of values. Your example says that the compatible should
be "Generic default" or "For Samsung 542x SoC"... :) The difference is
slight but putting the value first is a simple and elegant solution.
In your case one has to go to the end of sentence to find the most
important information - the compatible value.
> I have also checked Cadance QSPI controller.
> Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
> The controller might be built-in into different vendor SoC's
> and the "compatible" is ready to reflect it in similar fashion but
> with a short explanation in this section.
I see. I do not find this pattern as much readable as jedec-spi-nor or
at25 therefore I mentioned them as an example to base on ("Exactly the
same as AT24 or AT25 EEPROM bindings."). We can avoid also this entire
discussion with YAML (which also follows approach of at25 - value
first).
> Therefore, what you see in the patch draw heavily on Cadence's qspi,
> with a bit of inspiration from jedec,spi-nor usage.
>
> Should I change it to at25 "compatible" style and send next patch?
Yes, please. Or go to YAML and make entire discussion obsolete.
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 v1 1/9] ASoC: wm8994: Do not register inapplicable controls for WM1811
From: Krzysztof Kozlowski @ 2019-09-19 7:38 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, broonie, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-2-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:26PM +0200, Sylwester Nawrocki wrote:
> In case of WM1811 device there are currently being registered controls
> referring to registers not existing on that device.
> It has been noticed when getting values of "AIF1ADC2 Volume", "AIF1DAC2
> Volume" controls was failing during ALSA state restoring at boot time:
> "amixer: Mixer hw:0 load error: Device or resource busy"
>
> Reading some registers through I2C was failing with EBUSY error and indeed
> those registers were not available according to the datasheet.
>
> To fix this controls not available on WM1811 are moved to a separate array
> and registered only for WM8994 and WM8958.
>
> There are some further differences between WM8994 and WM1811, e.g. registers
> 603h, 604h, 605h, which are not covered in this patch.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> sound/soc/codecs/wm8994.c | 43 +++++++++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 17 deletions(-)
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
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 v2 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Lukasz Luba @ 2019-09-19 7:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, devicetree, willy.mh.wolff.ml,
linux-samsung-soc@vger.kernel.org,
Bartłomiej Żołnierkiewicz, linux-pm,
linux-kernel@vger.kernel.org, robh+dt, Chanwoo Choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPfBueaf2UVik8x2L_D_PTxdkvRukuWL3xh_jDiLKtt7pQ@mail.gmail.com>
On 9/19/19 9:28 AM, Krzysztof Kozlowski wrote:
> On Thu, 19 Sep 2019 at 08:49, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>
>> Hi Krzysztof,
>>
>> On 9/18/19 8:51 PM, Krzysztof Kozlowski wrote:
>>> On Mon, 16 Sep 2019 at 12:07, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>>>
>>>> Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings.
>>>> Introduce minor fixes in the old documentation.
>>>>
>>>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>>>> ---
>>>> Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++++++---
>>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>> index 3b2485b84b3f..49afe794daaa 100644
>>>> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>> @@ -1,7 +1,9 @@
>>>> * LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C
>>>>
>>>> Required properties:
>>>> -- compatible : Should be - "jedec,lpddr3"
>>>> +- compatible : should be one of the following:
>>>> + Generic default - "jedec,lpddr3".
>>>
>>> The convention is first compatible, then description. I gave you the
>>> example to base on - at25. Why making it different?
>>
>> I have checked at25 that you pointed me to and also checked at24, which
>> has a bit longer "compatible" section.
>>
>> I found that there are many "jedec,spi-nor" compatible devices, which I
>> thought would be a better example for my "jedec,lpddr3".
>> For example, two configurations, where you have a single labels or dual
>> (with specific device)
>> arch/arm/boot/dts/imx6dl-rex-basic.dts:
>> compatible = "sst,sst25vf016b", "jedec,spi-nor";
>> arch/arm/boot/dts/imx6q-ba16.dtsi:
>> compatible = "jedec,spi-nor";
>>
>> The 'compatible' in documentation for the "jedec,spi-nor" is slightly
>> different (similar to at24).
>> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> It has a long explanation, which is also OK. So I thought that it is
>> quite flexible what you put in there.
>
> It is flexible but I see clear pattern in existing sources:
> jedec,spi-nor.txt
> compatible : May include a device-specific ..
> ...
> Supported chip names:
> at25df321a
> ...
>
> at25.txt:
> - compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
> Example "<vendor>,<type>" values:
> "anvo,anv32e61w"
> "microchip,25lc040"
>
> In these cases the doc says that "compatible should be" and then you
> have the list of values. Your example says that the compatible should
> be "Generic default" or "For Samsung 542x SoC"... :) The difference is
> slight but putting the value first is a simple and elegant solution.
> In your case one has to go to the end of sentence to find the most
> important information - the compatible value.
>
>> I have also checked Cadance QSPI controller.
>> Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
>> The controller might be built-in into different vendor SoC's
>> and the "compatible" is ready to reflect it in similar fashion but
>> with a short explanation in this section.
>
> I see. I do not find this pattern as much readable as jedec-spi-nor or
> at25 therefore I mentioned them as an example to base on ("Exactly the
> same as AT24 or AT25 EEPROM bindings."). We can avoid also this entire
> discussion with YAML (which also follows approach of at25 - value
> first).
>
>> Therefore, what you see in the patch draw heavily on Cadence's qspi,
>> with a bit of inspiration from jedec,spi-nor usage.
>>
>> Should I change it to at25 "compatible" style and send next patch?
>
> Yes, please. Or go to YAML and make entire discussion obsolete.
OK I will change it to at25 style.
Regards,
Lukasz
_______________________________________________
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 v2] pwm: atmel: Remove platform_device_id and use only dt bindings
From: Claudiu.Beznea @ 2019-09-19 7:47 UTC (permalink / raw)
To: kamel.bouhara, thierry.reding, linux-pwm, linux-kernel
Cc: alexandre.belloni, gregory.clement, Ludovic.Desroches,
thomas.petazzoni, linux-arm-kernel
In-Reply-To: <20190918145716.32022-1-kamel.bouhara@bootlin.com>
On 18.09.2019 17:57, Kamel Bouhara wrote:
> Since commit 26202873bb51 ("avr32: remove support for AVR32
> architecture") there is no more user of platform_device_id and we
> should only use dt bindings
>
> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
> Changelog:
> v1->v2
>
> - Remove whole function atmel_pwm_get_driver_data and call
> of_device_get_match_data from atmel_pwm_probe
>
> drivers/pwm/Kconfig | 2 +-
> drivers/pwm/pwm-atmel.c | 35 +++--------------------------------
> 2 files changed, 4 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index a7e57516959e..b51fb1a33aa2 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -44,7 +44,7 @@ config PWM_AB8500
>
> config PWM_ATMEL
> tristate "Atmel PWM support"
> - depends on ARCH_AT91
> + depends on ARCH_AT91 && OF
> help
> Generic PWM framework driver for Atmel SoC.
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index e5e1eaf372fa..f7cf0a86a37c 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -318,19 +318,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
> },
> };
>
> -static const struct platform_device_id atmel_pwm_devtypes[] = {
> - {
> - .name = "at91sam9rl-pwm",
> - .driver_data = (kernel_ulong_t)&atmel_sam9rl_pwm_data,
> - }, {
> - .name = "sama5d3-pwm",
> - .driver_data = (kernel_ulong_t)&atmel_sama5_pwm_data,
> - }, {
> - /* sentinel */
> - },
> -};
> -MODULE_DEVICE_TABLE(platform, atmel_pwm_devtypes);
> -
> static const struct of_device_id atmel_pwm_dt_ids[] = {
> {
> .compatible = "atmel,at91sam9rl-pwm",
> @@ -350,19 +337,6 @@ static const struct of_device_id atmel_pwm_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, atmel_pwm_dt_ids);
>
> -static inline const struct atmel_pwm_data *
> -atmel_pwm_get_driver_data(struct platform_device *pdev)
> -{
> - const struct platform_device_id *id;
> -
> - if (pdev->dev.of_node)
> - return of_device_get_match_data(&pdev->dev);
> -
> - id = platform_get_device_id(pdev);
> -
> - return (struct atmel_pwm_data *)id->driver_data;
> -}
> -
> static int atmel_pwm_probe(struct platform_device *pdev)
> {
> const struct atmel_pwm_data *data;
> @@ -370,7 +344,7 @@ static int atmel_pwm_probe(struct platform_device *pdev)
> struct resource *res;
> int ret;
>
> - data = atmel_pwm_get_driver_data(pdev);
> + data = of_device_get_match_data(&pdev->dev);
> if (!data)
> return -ENODEV;
>
> @@ -396,10 +370,8 @@ static int atmel_pwm_probe(struct platform_device *pdev)
> atmel_pwm->chip.dev = &pdev->dev;
> atmel_pwm->chip.ops = &atmel_pwm_ops;
>
> - if (pdev->dev.of_node) {
> - atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> - atmel_pwm->chip.of_pwm_n_cells = 3;
> - }
> + atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> + atmel_pwm->chip.of_pwm_n_cells = 3;
>
> atmel_pwm->chip.base = -1;
> atmel_pwm->chip.npwm = 4;
> @@ -437,7 +409,6 @@ static struct platform_driver atmel_pwm_driver = {
> .name = "atmel-pwm",
> .of_match_table = of_match_ptr(atmel_pwm_dt_ids),
> },
> - .id_table = atmel_pwm_devtypes,
> .probe = atmel_pwm_probe,
> .remove = atmel_pwm_remove,
> };
>
_______________________________________________
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] stmmac: selftest: avoid large stack usage
From: Jose Abreu @ 2019-09-19 7:58 UTC (permalink / raw)
To: Arnd Bergmann, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190918195454.2056139-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Sep/18/2019, 20:54:34 (UTC+00:00)
> + if (!cfg || !cfg->enable) {
> value &= ~XGMAC_RSSE;
> writel(value, ioaddr + XGMAC_RSS_CTRL);
> return 0;
> }
>
> for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
> - ret = dwxgmac2_rss_write_reg(ioaddr, true, i, *key++);
> + if (cfg)
> + ret = dwxgmac2_rss_write_reg(ioaddr, true, i, cfg->key[i]);
> + else
> + ret = dwxgmac2_rss_write_reg(ioaddr, true, i, 0);
> +
> if (ret)
> return ret;
> }
>
> for (i = 0; i < ARRAY_SIZE(cfg->table); i++) {
> - ret = dwxgmac2_rss_write_reg(ioaddr, false, i, cfg->table[i]);
> + if (cfg)
> + ret = dwxgmac2_rss_write_reg(ioaddr, false, i, cfg->table[i]);
> + else
> + ret = dwxgmac2_rss_write_reg(ioaddr, false, i, 0);
> +
I don't get these "if (cfg)" checks. You already check earlier if cfg is
NULL and return if so. I don't think you need these extra checks.
Also, your subject line should be something like: "net: stmmac:
selftests: ..."
---
Thanks,
Jose Miguel Abreu
_______________________________________________
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 v1 2/9] mfd: wm8994: Add support for MCLKn clock control
From: Krzysztof Kozlowski @ 2019-09-19 7:59 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, broonie, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-3-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:27PM +0200, Sylwester Nawrocki wrote:
> The WM1811/WM8994/WM8958 audio CODEC DT bindings specify two optional
> clocks: "MCLK1", "MCLK2". Add code for getting those clocks in the MFD
> part of the wm8994 driver so they can be further handled in the audio
> CODEC part.
I think these are needed only for the codec so how about getting them in
codec's probe?
Best regards,
Krzysztof
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> drivers/mfd/wm8994-core.c | 9 +++++++++
> include/linux/mfd/wm8994/core.h | 9 +++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c
> index 1e9fe7d92597..02c19a0bdeb0 100644
> --- a/drivers/mfd/wm8994-core.c
> +++ b/drivers/mfd/wm8994-core.c
> @@ -7,6 +7,7 @@
> * Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
> */
>
> +#include <linux/clk.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> @@ -333,6 +334,14 @@ static int wm8994_device_init(struct wm8994 *wm8994, int irq)
>
> dev_set_drvdata(wm8994->dev, wm8994);
>
> + wm8994->mclk[WM8994_MCLK1].id = "MCLK1";
> + wm8994->mclk[WM8994_MCLK2].id = "MCLK2";
> +
> + ret = devm_clk_bulk_get_optional(wm8994->dev, ARRAY_SIZE(wm8994->mclk),
> + wm8994->mclk);
> + if (ret != 0)
> + return ret;
> +
> /* Add the on-chip regulators first for bootstrapping */
> ret = mfd_add_devices(wm8994->dev, 0,
> wm8994_regulator_devs,
> diff --git a/include/linux/mfd/wm8994/core.h b/include/linux/mfd/wm8994/core.h
> index e8b093522ffd..320297a1b70c 100644
> --- a/include/linux/mfd/wm8994/core.h
> +++ b/include/linux/mfd/wm8994/core.h
> @@ -10,12 +10,19 @@
> #ifndef __MFD_WM8994_CORE_H__
> #define __MFD_WM8994_CORE_H__
>
> +#include <linux/clk.h>
> #include <linux/mutex.h>
> #include <linux/interrupt.h>
> #include <linux/regmap.h>
>
> #include <linux/mfd/wm8994/pdata.h>
>
> +enum {
> + WM8994_MCLK1,
> + WM8994_MCLK2,
> + WM8994_NUM_MCLK
> +};
> +
> enum wm8994_type {
> WM8994 = 0,
> WM8958 = 1,
> @@ -60,6 +67,8 @@ struct wm8994 {
> struct device *dev;
> struct regmap *regmap;
>
> + struct clk_bulk_data mclk[WM8994_NUM_MCLK];
> +
> bool ldo_ena_always_driven;
>
> int gpio_base;
> --
> 2.17.1
>
_______________________________________________
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 v1 3/9] ASoC: wm8994: Add support for setting MCLKn clock rate
From: Krzysztof Kozlowski @ 2019-09-19 8:00 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, broonie, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-4-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:28PM +0200, Sylwester Nawrocki wrote:
> Extend the set_sysclk() handler so we also set frequency of the MCLK1,
> MCLK2 clocks through clk API when those clocks are specified in DT for
> the device.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> sound/soc/codecs/wm8994.c | 30 +++++++++++++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
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 1/1] sched/eas: introduce system-wide overutil indicator
From: Vincent Guittot @ 2019-09-19 8:00 UTC (permalink / raw)
To: YT Chang
Cc: wsd_upstream, Peter Zijlstra, linux-kernel, linux-mediatek,
Matthias Brugger, LAK
In-Reply-To: <1568877622-28073-1-git-send-email-yt.chang@mediatek.com>
On Thu, 19 Sep 2019 at 09:20, YT Chang <yt.chang@mediatek.com> wrote:
>
> When the system is overutilization, the load-balance crossing
s/overutilization/overutilized/
> clusters will be triggered and scheduler will not use energy
> aware scheduling to choose CPUs.
>
> The overutilization means the loading of ANY CPUs
s/ANY/any/
> exceeds threshold (80%).
>
> However, only 1 heavy task or while-1 program will run on highest
> capacity CPUs and it still result to trigger overutilization. So
> the system will not use Energy Aware scheduling.
>
> To avoid it, a system-wide over-utilization indicator to trigger
> load-balance cross clusters.
The current rd->overutilized is already system wide. I mean that as
soon as one CPU is overutilized, the whole system is considered as
overutilized whereas you would like a finer grain level of
overutilization.
I remember a patch that was proposing a per sched_domain
overutilization detection. The load_balance at one sched_domain level
was enabled only if the child level was not able to handle the
overutilization and the energy aware scheduling was still used in the
other sched_domain
>
> The policy is:
> The loading of "ALL CPUs in the highest capacity"
> exceeds threshold(80%) or
> The loading of "Any CPUs not in the highest capacity"
> exceed threshold(80%)
Do you have UCs or figures that show a benefit with this change ?
>
> Signed-off-by: YT Chang <yt.chang@mediatek.com>
> ---
> kernel/sched/fair.c | 76 +++++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 65 insertions(+), 11 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 036be95..f4c3d70 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5182,10 +5182,71 @@ static inline bool cpu_overutilized(int cpu)
> static inline void update_overutilized_status(struct rq *rq)
> {
> if (!READ_ONCE(rq->rd->overutilized) && cpu_overutilized(rq->cpu)) {
> - WRITE_ONCE(rq->rd->overutilized, SG_OVERUTILIZED);
> - trace_sched_overutilized_tp(rq->rd, SG_OVERUTILIZED);
> + if (capacity_orig_of(cpu_of(rq)) < rq->rd->max_cpu_capacity) {
> + WRITE_ONCE(rq->rd->overutilized, SG_OVERUTILIZED);
> + trace_sched_overutilized_tp(rq->rd, SG_OVERUTILIZED);
> + }
> }
> }
> +
> +static
> +void update_system_overutilized(struct sched_domain *sd, struct cpumask *cpus)
> +{
> + unsigned long group_util;
> + bool intra_overutil = false;
> + unsigned long max_capacity;
> + struct sched_group *group = sd->groups;
> + struct root_domain *rd;
> + int this_cpu;
> + bool overutilized;
> + int i;
> +
> + this_cpu = smp_processor_id();
> + rd = cpu_rq(this_cpu)->rd;
> + overutilized = READ_ONCE(rd->overutilized);
> + max_capacity = rd->max_cpu_capacity;
> +
> + do {
> + group_util = 0;
> + for_each_cpu_and(i, sched_group_span(group), cpus) {
> + group_util += cpu_util(i);
> + if (cpu_overutilized(i)) {
> + if (capacity_orig_of(i) < max_capacity) {
> + intra_overutil = true;
> + break;
> + }
> + }
> + }
> +
> + /*
> + * A capacity base hint for over-utilization.
> + * Not to trigger system overutiled if heavy tasks
> + * in Big.cluster, so
> + * add the free room(20%) of Big.cluster is impacted which means
> + * system-wide over-utilization,
> + * that considers whole cluster not single cpu
> + */
> + if (group->group_weight > 1 && (group->sgc->capacity * 1024 <
> + group_util * capacity_margin)) {
> + intra_overutil = true;
> + break;
> + }
> +
> + group = group->next;
> +
> + } while (group != sd->groups && !intra_overutil);
> +
> + if (overutilized != intra_overutil) {
> + if (intra_overutil == true) {
> + WRITE_ONCE(rd->overutilized, SG_OVERUTILIZED);
> + trace_sched_overutilized_tp(rd, SG_OVERUTILIZED);
> + } else {
> + WRITE_ONCE(rd->overutilized, 0);
> + trace_sched_overutilized_tp(rd, 0);
> + }
> + }
> +}
> +
> #else
> static inline void update_overutilized_status(struct rq *rq) { }
> #endif
> @@ -8242,15 +8303,6 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
>
> /* update overload indicator if we are at root domain */
> WRITE_ONCE(rd->overload, sg_status & SG_OVERLOAD);
> -
> - /* Update over-utilization (tipping point, U >= 0) indicator */
> - WRITE_ONCE(rd->overutilized, sg_status & SG_OVERUTILIZED);
> - trace_sched_overutilized_tp(rd, sg_status & SG_OVERUTILIZED);
> - } else if (sg_status & SG_OVERUTILIZED) {
> - struct root_domain *rd = env->dst_rq->rd;
> -
> - WRITE_ONCE(rd->overutilized, SG_OVERUTILIZED);
> - trace_sched_overutilized_tp(rd, SG_OVERUTILIZED);
> }
> }
>
> @@ -8476,6 +8528,8 @@ static struct sched_group *find_busiest_group(struct lb_env *env)
> */
> update_sd_lb_stats(env, &sds);
>
> + update_system_overutilized(env->sd, env->cpus);
This should be called only if (sched_energy_enabled())
> +
> if (sched_energy_enabled()) {
> struct root_domain *rd = env->dst_rq->rd;
>
> --
> 1.9.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox