* [PATCH v6 5/8] coresight: use const for device_node structures
From: Mathieu Poirier @ 2017-04-18 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491485461-22800-6-git-send-email-leo.yan@linaro.org>
On Thu, Apr 06, 2017 at 09:30:58PM +0800, Leo Yan wrote:
> Almost low level functions from open firmware have used const to
> qualify device_node structures, so add const for device_node
> parameters in of_coresight related functions.
>
> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
I agree with these changes but the patch needs to be split up - please see
below.
> ---
> drivers/hwtracing/coresight/of_coresight.c | 6 +++---
> include/linux/coresight.h | 8 ++++----
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 78d2399..46eec0f 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -52,7 +52,7 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
> endpoint, of_dev_node_match);
> }
>
> -static void of_coresight_get_ports(struct device_node *node,
> +static void of_coresight_get_ports(const struct device_node *node,
> int *nr_inport, int *nr_outport)
Move this to a patch by itself as it is not related to this driver.
> {
> struct device_node *ep = NULL;
> @@ -101,7 +101,7 @@ static int of_coresight_alloc_memory(struct device *dev,
> return 0;
> }
>
> -int of_coresight_get_cpu(struct device_node *node)
> +int of_coresight_get_cpu(const struct device_node *node)
Move this to the previous patch in this set. There is not need to undo what you
just did there.
> {
> int cpu;
> bool found;
> @@ -128,7 +128,7 @@ int of_coresight_get_cpu(struct device_node *node)
> EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
>
> struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node)
> + struct device *dev, const struct device_node *node)
Same here, move this to a new patch (the same one as of_coresight_get_ports()).
> {
> int i = 0, ret = 0;
> struct coresight_platform_data *pdata;
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index bf96678..4915254 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -263,13 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, u32 offset,
> #endif
>
> #ifdef CONFIG_OF
> -extern int of_coresight_get_cpu(struct device_node *node);
> +extern int of_coresight_get_cpu(const struct device_node *node);
> extern struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node);
> + struct device *dev, const struct device_node *node);
> #else
> -static inline int of_coresight_get_cpu(struct device_node *node) { return 0; }
> +static inline int of_coresight_get_cpu(const struct device_node *node) { return 0; }
> static inline struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node) { return NULL; }
> + struct device *dev, const struct device_node *node) { return NULL; }
> #endif
>
> #ifdef CONFIG_PID_NS
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v6 3/8] coresight: of_get_coresight_platform_data: Add missing of_node_put
From: Mathieu Poirier @ 2017-04-18 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491485461-22800-4-git-send-email-leo.yan@linaro.org>
On Thu, Apr 06, 2017 at 09:30:56PM +0800, Leo Yan wrote:
> From: Suzuki K Poulose <suzuki.poulose@arm.com>
>
> The of_get_coresight_platform_data iterates over the possible CPU nodes
> to find a given cpu phandle. However it does not drop the reference
> to the node pointer returned by the of_get_coresight_platform_data.
>
> This patch also introduces another minor fix is to use
> of_cpu_device_node_get() to replace of_get_cpu_node().
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> [Leo: minor tweaks for of_get_coresight_platform_data]
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
Suzuki sent a Reviewed-by for this, it should be added here.
> ---
> drivers/hwtracing/coresight/of_coresight.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 629e031..1a77280 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -108,7 +108,8 @@ struct coresight_platform_data *of_get_coresight_platform_data(
> struct coresight_platform_data *pdata;
> struct of_endpoint endpoint, rendpoint;
> struct device *rdev;
> - struct device_node *dn;
> + bool found;
> + struct device_node *dn, *np;
> struct device_node *ep = NULL;
> struct device_node *rparent = NULL;
> struct device_node *rport = NULL;
> @@ -175,17 +176,19 @@ struct coresight_platform_data *of_get_coresight_platform_data(
> } while (ep);
> }
>
> - /* Affinity defaults to CPU0 */
> - pdata->cpu = 0;
> dn = of_parse_phandle(node, "cpu", 0);
> - for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
> - if (dn == of_get_cpu_node(cpu, NULL)) {
> - pdata->cpu = cpu;
> + for_each_possible_cpu(cpu) {
> + np = of_cpu_device_node_get(cpu);
> + found = (dn == np);
> + of_node_put(np);
> + if (found)
> break;
> - }
> }
> of_node_put(dn);
>
> + /* Affinity to CPU0 if no cpu nodes are found */
> + pdata->cpu = found ? cpu : 0;
> +
> return pdata;
> }
> EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 1/3] ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM
From: Wadim Egorov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFLEztSQ1-WU7KAXzuB66htXiaQN4wd=XmM5XtjZcoONt77XmQ@mail.gmail.com>
>> +&i2c0 {
>> + status = "okay";
>> + clock-frequency = <400000>;
>> +
>> + rk818: pmic at 1c {
>> + compatible = "rockchip,rk818";
>> + reg = <0x1c>;
>> + interrupt-parent = <&gpio0>;
>> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pmic_int>;
>> + rockchip,system-power-controller;
>> + wakeup-source;
>> + #clock-cells = <1>;
>> +
> I think you miss "clock-output-names = "xin32k" here.
Yes, thanks for catching that. I will fix this later.
^ permalink raw reply
* [PATCH v2 7/7] ARM: dts: imx7d-sdb: Enable PCIe peripheral
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Enable PCIe peripheral on this board.
Cc: yurovsky at gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7d-sdb.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index d6f2dda..65dda66 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -349,6 +349,12 @@
};
};
+&pcie {
+ pinctrl-names = "default";
+ reset-gpio = <&extended_io 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
&pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: imx7d: Add node for PCIe controller
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Cc: yurovsky at gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7d.dtsi | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index f6dee41..f46814a 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -42,6 +42,7 @@
*/
#include "imx7s.dtsi"
+#include <dt-bindings/reset/imx7-reset.h>
/ {
cpus {
@@ -127,6 +128,42 @@
fsl,num-rx-queues=<3>;
status = "disabled";
};
+
+ pcie: pcie at 0x33800000 {
+ compatible = "fsl,imx7d-pcie", "snps,dw-pcie";
+ reg = <0x33800000 0x4000>,
+ <0x4ff00000 0x80000>;
+ reg-names = "dbi", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x81000000 0 0 0x4ff80000 0 0x00010000 /* downstream I/O */
+ 0x82000000 0 0x40000000 0x40000000 0 0x0ff00000>; /* non-prefetchable memory */
+ num-lanes = <1>;
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_PCIE_CTRL_ROOT_CLK>,
+ <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>,
+ <&clks IMX7D_PCIE_PHY_ROOT_CLK>;
+ clock-names = "pcie", "pcie_bus", "pcie_phy";
+ assigned-clocks = <&clks IMX7D_PCIE_CTRL_ROOT_SRC>,
+ <&clks IMX7D_PCIE_PHY_ROOT_SRC>;
+ assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_250M_CLK>,
+ <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
+
+ fsl,max-link-speed = <2>;
+ power-domains = <&pgc_pcie_phy>;
+ resets = <&src IMX7_RESET_PCIEPHY>,
+ <&src IMX7_RESET_PCIE_CTRL_APPS_EN>;
+ reset-names = "pciephy", "apps";
+ status = "disabled";
+ };
};
&ca_funnel_ports {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/7] ARM: dts: imx7d-sdb: Add GPIO expander node
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Add node for U38, a 74LV595PW serial-in shift register that acts as a
GPIO expander on the board.
Cc: yurovsky at gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7d-sdb.dts | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 5be01a1..d6f2dda 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -52,6 +52,27 @@
reg = <0x80000000 0x80000000>;
};
+ spi4 {
+ compatible = "spi-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi4>;
+ gpio-sck = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ gpio-mosi = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ num-chipselects = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ extended_io: gpio-expander at 0 {
+ compatible = "fairchild,74hc595";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ registers-number = <1>;
+ spi-max-frequency = <100000>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -642,5 +663,13 @@
fsl,pins = <
MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x110b0
>;
+
+ pinctrl_spi4: spi4grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO09__GPIO1_IO9 0x59
+ MX7D_PAD_GPIO1_IO12__GPIO1_IO12 0x59
+ MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x59
+ >;
+ };
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/7] ARM: dts: imx7s: Mark 'gpr' compatible with i.MX6 variant
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
List GPR block as compatible "fsl,imx6q-iomuxc-gpr" to support drivers
requesting it that way (PCIe driver is one example).
Cc: yurovsky at gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7s.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 5ba1289..d46ee0f 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -491,7 +491,8 @@
};
gpr: iomuxc-gpr at 30340000 {
- compatible = "fsl,imx7d-iomuxc-gpr", "syscon";
+ compatible = "fsl,imx7d-iomuxc-gpr",
+ "fsl,imx6q-iomuxc-gpr", "syscon";
reg = <0x30340000 0x10000>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/7] ARM: dts: imx7s: Add node for GPC
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Add node for GPC and specify as a parent interrupt controller for SoC bus.
Cc: yurovsky at gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx7s.dtsi | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 7148eac..5ba1289 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -42,6 +42,7 @@
*/
#include <dt-bindings/clock/imx7d-clock.h>
+#include <dt-bindings/power/imx7-power.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -119,7 +120,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
- interrupt-parent = <&intc>;
+ interrupt-parent = <&gpc>;
ranges;
funnel at 30041000 {
@@ -301,6 +302,7 @@
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
#interrupt-cells = <3>;
interrupt-controller;
+ interrupt-parent = <&intc>;
reg = <0x31001000 0x1000>,
<0x31002000 0x2000>,
<0x31004000 0x2000>,
@@ -309,6 +311,7 @@
timer {
compatible = "arm,armv7-timer";
+ interrupt-parent = <&intc>;
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
@@ -565,6 +568,27 @@
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
#reset-cells = <1>;
};
+
+ gpc: gpc at 303a0000 {
+ compatible = "fsl,imx7d-gpc";
+ reg = <0x303a0000 0x10000>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&intc>;
+ #power-domain-cells = <1>;
+
+ pgc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pgc_pcie_phy: pgc-power-domain at IMX7_POWER_DOMAIN_PCIE_PHY {
+ #power-domain-cells = <0>;
+ reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
+ power-supply = <®_1p0d>;
+ };
+ };
+ };
};
aips2: aips-bus at 30400000 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/7] ARM: imx: Select GPCv2 for i.MX7
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
GPCv2 IP block is a part of i.MX7 SoC. Select it to make corresponding
driver availible to support DT changes following this patch.
Cc: yurovsky at gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/mach-imx/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 936c59d..1a4ea3a 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -532,6 +532,7 @@ config SOC_IMX7D
bool "i.MX7 Dual support"
select PINCTRL_IMX7D
select ARM_GIC
+ select IMX_GPCV2
select HAVE_ARM_ARCH_TIMER
select HAVE_IMX_ANATOP
select HAVE_IMX_MMDC
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/7] ARM: dts: i.MX: Reintroduce 'anatop-enable-bit' where appropriate
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Now that support for 'anatop-enable-bit' has been added to ANADIG
driver, reintroduce 'anatop-enable-bit' for all applicable LDOs.
Cc: yurovsky at gmail.com
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 1 +
5 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf64..ec398ea 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -643,6 +643,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -657,6 +658,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -671,6 +673,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2875000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index cc9572e..3243af4 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -530,6 +530,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -544,6 +545,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -558,6 +560,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2850000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index dd4ec85..97199ee 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -586,6 +586,7 @@
anatop-min-bit-val = <4>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1375000>;
+ anatop-enable-bit = <0>;
};
regulator-3p0 {
@@ -600,6 +601,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
regulator-2p5 {
@@ -614,6 +616,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2100000>;
anatop-max-voltage = <2875000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index b9d7d2d..6da2b77 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -542,6 +542,7 @@
anatop-min-bit-val = <0>;
anatop-min-voltage = <2625000>;
anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
};
reg_arm: regulator-vddcore {
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 5d3a43b..7148eac 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -517,6 +517,7 @@
anatop-min-bit-val = <8>;
anatop-min-voltage = <800000>;
anatop-max-voltage = <1200000>;
+ anatop-enable-bit = <0>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/7] i.MX7 PCIe related device tree changes
From: Andrey Smirnov @ 2017-04-18 15:01 UTC (permalink / raw)
To: linux-arm-kernel
Shawn, everyone:
This is second version of the series that includes changes made to
device-tree in order to support PCIe on i.MX7 platform.
Changes since [v1]:
- All 'anatop-enable-bit' patches are squashed into one
- Added patch to enable GPCv2 driver on i.MX7
- Dropped accidentally introduced unsupported DT properties
- A number of node renaming for readability/clarity purpose
[v1] http://lkml.kernel.org/r/20170413133242.5068-1-andrew.smirnov at gmail.com
Andrey Smirnov (7):
ARM: dts: i.MX: Reintroduce 'anatop-enable-bit' where appropriate
ARM: imx: Select GPCv2 for i.MX7
ARM: dts: imx7s: Add node for GPC
ARM: dts: imx7s: Mark 'gpr' compatible with i.MX6 variant
ARM: dts: imx7d-sdb: Add GPIO expander node
ARM: dts: imx7d: Add node for PCIe controller
ARM: dts: imx7d-sdb: Enable PCIe peripheral
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7d-sdb.dts | 35 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx7d.dtsi | 37 +++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx7s.dtsi | 30 ++++++++++++++++++++++++++++--
arch/arm/mach-imx/Kconfig | 1 +
8 files changed, 111 insertions(+), 2 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 5/7] regulator: arizona-ldo1: Move pdata into a separate structure
From: Krzysztof Kozlowski @ 2017-04-18 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-7-git-send-email-rf@opensource.wolfsonmicro.com>
On Tue, Apr 18, 2017 at 12:43 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> In preparation for sharing this driver with Madera, move the pdata
> for the LDO1 regulator out of struct arizona_pdata into a dedicated
> pdata struct for this driver. As a result the code in
> arizona_ldo1_of_get_pdata() can be made independent of struct arizona.
>
> This patch also updates the definition of struct arizona_pdata and
> the use of this pdata in mach-crag6410-module.c
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> arch/arm/mach-s3c64xx/mach-crag6410-module.c | 8 ++++--
> drivers/regulator/arizona-ldo1.c | 39 +++++++++++++++-------------
> include/linux/mfd/arizona/pdata.h | 4 +--
> include/linux/regulator/arizona-ldo1.h | 24 +++++++++++++++++
> 4 files changed, 53 insertions(+), 22 deletions(-)
> create mode 100644 include/linux/regulator/arizona-ldo1.h
>
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> index ccc3ab8..ea5f216 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> @@ -209,7 +209,9 @@
> };
>
> static struct arizona_pdata wm5102_reva_pdata = {
> - .ldoena = S3C64XX_GPN(7),
> + .ldo1 = {
> + .ldoena = S3C64XX_GPN(7),
> + },
> .gpio_base = CODEC_GPIO_BASE,
> .irq_flags = IRQF_TRIGGER_HIGH,
> .micd_pol_gpio = CODEC_GPIO_BASE + 4,
> @@ -239,7 +241,9 @@
> };
>
> static struct arizona_pdata wm5102_pdata = {
> - .ldoena = S3C64XX_GPN(7),
> + .ldo1 = {
> + .ldoena = S3C64XX_GPN(7),
> + },
> .gpio_base = CODEC_GPIO_BASE,
> .irq_flags = IRQF_TRIGGER_HIGH,
> .micd_pol_gpio = CODEC_GPIO_BASE + 2,
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] Revert "arm64: Increase the max granular size"
From: Catalin Marinas @ 2017-04-18 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+sq2CeTZyTrc3kC-kJEyrT5Tt5Wr47F=OVaCHwMRZk96qo4HA@mail.gmail.com>
On Mon, Apr 17, 2017 at 04:08:52PM +0530, Sunil Kovvuri wrote:
> >> >> Do you have an explanation on the performance variation when
> >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network stack
> >> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
> >> >> non-coherent DMA?).
> >> >
> >> > network stack use SKB_DATA_ALIGN to align.
> >> > ---
> >> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
> >> > ~(SMP_CACHE_BYTES - 1))
> >> >
> >> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
> >> > ---
> >> > I think this is the reason of performance regression.
> >> >
> >>
> >> Yes this is the reason for performance regression. Due to increases L1 cache alignment the
> >> object is coming from next kmalloc slab and skb->truesize is changing from 2304 bytes to
> >> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of less send buffers.
>
> With what traffic did you check 'skb->truesize' ?
> Increase from 2304 to 4352 bytes doesn't seem to be real. I checked
> with ICMP pkts with maximum
> size possible with 1500byte MTU and I don't see such a bump. If the
> bump is observed with Iperf
> sending TCP packets then I suggest to check if TSO is playing a part over here.
I haven't checked truesize but I added some printks to __alloc_skb() (on
a Juno platform) and the size argument to this function is 1720 on many
occasions. With sizeof(struct skb_shared_info) of 320, the actual data
allocation is exactly 2048 when using 64 byte L1_CACHE_SIZE. With a
128 byte cache size, it goes slightly over 2K, hence the 4K slab
allocation. The 1720 figure surprised me a bit as well since I was
expecting something close to 1500.
The thing that worries me is that skb->data may be used as a buffer to
DMA into. If that's the case, skb_shared_info is wrongly aligned based
on SMP_CACHE_BYTES only and can lead to corruption on a non-DMA-coherent
platform. It should really be ARCH_DMA_MINALIGN.
IIUC, the Cavium platform has coherent DMA, so it shouldn't be an issue
if we go back to 64 byte cache lines. However, we don't really have an
easy way to check (maybe taint the kernel if CWG is different from
ARCH_DMA_MINALIGN *and* the non-coherent DMA API is called).
--
Catalin
^ permalink raw reply
* [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT
From: Paul Gortmaker @ 2017-04-18 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170405183458.193068-1-mka@chromium.org>
On Wed, Apr 5, 2017 at 2:34 PM, Matthias Kaehlcke <mka@chromium.org> wrote:
> The operand is an integer constant, make the constness explicit by
> adding the modifier. This is needed for clang to generate valid code
> and also works with gcc.
Actually it doesn't work with all gcc. I've got an older arm64 toolchain that I
only use for syntax checking (and hence I don't care if it is the latest and
greatest) and this commit breaks it:
arch/arm64/crypto/sha1-ce-glue.c:21:2: error: invalid 'asm': invalid
operand prefix '%c'
asm(".globl " #sym "; .set " #sym ", %c0" :: "i"(val));
I'm currently reverting this change locally so I can continue to use the old
toolchain:
$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.8-2013.12 - Linaro
GCC 2013.11) 4.8.3 20131202 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
$ aarch64-linux-gnu-as --version
GNU assembler (crosstool-NG linaro-1.13.1-4.8-2013.12 - Linaro GCC
2013.11) 2.24.0.20131220
Copyright 2013 Free Software Foundation, Inc.
Maybe it is finally too old and nobody cares, but I thought it worth a mention.
Paul.
--
>
> Also change the constraint of the operand from 'I' ("Integer constant
> that is valid as an immediate operand in an ADD instruction", AArch64)
> to 'i' ("An immediate integer operand").
>
> Based-on-patch-from: Greg Hackmann <ghackmann@google.com>
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in v2:
> - Changed operand constraint from I to i
> - Updated commit message
> - Changed 'From' tag to 'Based-on-patch-from'
>
> arch/arm64/crypto/sha1-ce-glue.c | 2 +-
> arch/arm64/crypto/sha2-ce-glue.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/crypto/sha1-ce-glue.c b/arch/arm64/crypto/sha1-ce-glue.c
> index aefda9868627..6b520e3f3ab1 100644
> --- a/arch/arm64/crypto/sha1-ce-glue.c
> +++ b/arch/arm64/crypto/sha1-ce-glue.c
> @@ -18,7 +18,7 @@
> #include <linux/module.h>
>
> #define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> + asm(".globl " #sym "; .set " #sym ", %c0" :: "i"(val));
>
> MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
> MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
> diff --git a/arch/arm64/crypto/sha2-ce-glue.c b/arch/arm64/crypto/sha2-ce-glue.c
> index 7cd587564a41..e3abe11de48c 100644
> --- a/arch/arm64/crypto/sha2-ce-glue.c
> +++ b/arch/arm64/crypto/sha2-ce-glue.c
> @@ -18,7 +18,7 @@
> #include <linux/module.h>
>
> #define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> + asm(".globl " #sym "; .set " #sym ", %c0" :: "i"(val));
>
> MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto Extensions");
> MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
> --
> 2.12.2.715.g7642488e1d-goog
>
^ permalink raw reply
* arm64: Question about warnings due to unspecified ASM operand width
From: Ard Biesheuvel @ 2017-04-18 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418013156.GB105296@google.com>
On 18 April 2017 at 02:31, Matthias Kaehlcke <mka@chromium.org> wrote:
> Hi,
>
> During my work on improving support for kernel builds with clang I
> came across a bunch of warnings on arm64 builds about the width of
> operands in assembly not being specified:
>
> arch/arm64/include/asm/arch_timer.h:92:46: error: value size does
> not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths]
> asm volatile("mrs %0, cntfrq_el0" : "=r" (val));
>
> I understand that this is usually not a problem and might even be
> desired to give the compiler more flexiblity in the use of the
> available registers.
>
> My goal is to eventually build the kernel without warnings, not
> necessarily fixing all of them, warnings can also be disabled, e.g.
> in case of spurious warnings or a high number of occurrences that is
> too expensive to fix.
>
> Before delving into 'fixing' these 'asm-operand-widths' warnings I'd
> be interested to know if this is actually desirable or if it is
> preferred to keep the operand width unspecified in certain cases.
>
Hi Matthias,
The root cause is that Clang infers the size of the register from the
size of the operand, while GCC always uses an xN register for a %
placeholder.
With msr/mrs instructions, we can only use xN registers, and so the
only way to fix this is to ensure that we always use 64-bit operands
even for 32-bit system registers. This may be possible in most cases,
but assigning 32-bit struct fields becomes a bit painful this way, and
'fixing' what is arguably not broken to begin with may not be
something Catalin is eager to accept.
Do you know if there is a rationale behind this disparity?
--
Ard.
^ permalink raw reply
* [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."
From: Catalin Marinas @ 2017-04-18 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492117462-19886-1-git-send-email-sstabellini@kernel.org>
On Thu, Apr 13, 2017 at 02:04:21PM -0700, Stefano Stabellini wrote:
> The following commit:
>
> commit 815dd18788fe0d41899f51b91d0560279cf16b0d
> Author: Bart Van Assche <bart.vanassche@sandisk.com>
> Date: Fri Jan 20 13:04:04 2017 -0800
>
> treewide: Consolidate get_dma_ops() implementations
>
> rearranges get_dma_ops in a way that xen_dma_ops are not returned when
> running on Xen anymore, dev->dma_ops is returned instead (see
> arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
> include/linux/dma-mapping.h:get_dma_ops).
>
> Fix the problem by storing dev->dma_ops in dev_archdata, and setting
> dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
> by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
> dev_archdata when needed. It also allows us to remove __generic_dma_ops
> from common headers.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> Tested-by: Julien Grall <julien.grall@arm.com>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> CC: linux at armlinux.org.uk
> CC: catalin.marinas at arm.com
> CC: will.deacon at arm.com
> CC: boris.ostrovsky at oracle.com
> CC: jgross at suse.com
> CC: Julien Grall <julien.grall@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 2/2] arm64: Fix power-of-ten vs. power-of-two prefixes in comments etc.
From: Catalin Marinas @ 2017-04-18 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXTgCEesv3imtnzs6Mcnkp22KW_rx0Jiv3_zce7bR3AVQ@mail.gmail.com>
On Mon, Apr 17, 2017 at 01:54:49PM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 17, 2017 at 1:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Apr 13, 2017 at 01:18:58PM +0100, David Woodhouse wrote:
> >> Less important than in user-visible messages, but still good practice as
> >> there's still no excuse for ARM64 code to look like it was written before
> >> 1996.
> >>
> >> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Hi David,
> >
> > I'd be happy to take the Renesas portions of this change if they were
> > broken out into a separate patch. The reason I would prefer a separate
> > patch is to avoid the possibility of conflicts, even trivial ones.
>
> s/possibility/reality/, unless this series goes in before v4.12-rc1.
Maybe the arm-soc guys can take both patches on top of the other series
they pull, in which case, for both patches:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] ARM: Fix rd_size declaration
From: Johannes Thumshirn @ 2017-04-18 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492524472.2628.3.camel@sandisk.com>
On Tue, Apr 18, 2017 at 02:07:53PM +0000, Bart Van Assche wrote:
> Hello Johannes,
>
> Thanks for the review. But are you aware that with the current content an
> include guard is overkill because it is safe to evaluate the "extern unsigned
> long rd_size" declaration multiple times?
Yes I am. But once someone does changes to this header and forgets the include
guard as well it may cause errors.
I am aware that this is rather cosmetic than needed, that's why I declared it
as a nit.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumshirn at suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* [PATCH] ARM: Fix rd_size declaration
From: Bart Van Assche @ 2017-04-18 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418073526.GA6056@linux-x5ow.site>
On Tue, 2017-04-18 at 09:35 +0200, Johannes Thumshirn wrote:
> On Mon, Apr 17, 2017 at 04:10:03PM -0700, Bart Van Assche wrote:
> > The global variable 'rd_size' is declared as 'int' in source file
> > arch/arm/kernel/atags_parse.c and as 'unsigned long' in
> > drivers/block/brd.c. Fix this inconsistency.
> >
> > Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Jens Axboe <axboe@kernel.dk>
> > Cc: Jan Kara <jack@suse.cz>
> > Cc: <yanaijie@huawei.com>
> > Cc: <zhaohongjiang@huawei.com>
> > Cc: <miaoxie@huawei.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-block at vger.kernel.org
> > ---
> > diff --git a/include/linux/brd.h b/include/linux/brd.h
> > new file mode 100644
> > index 000000000000..dbb0f92fefc8
> > --- /dev/null
> > +++ b/include/linux/brd.h
> > @@ -0,0 +1 @@
> > +extern unsigned long rd_size;
>
> Small nit, can you add an include guard here as well?
Hello Johannes,
Thanks for the review. But are you aware that with the current content an
include guard is overkill because it is safe to evaluate the "extern unsigned
long rd_size" declaration multiple times?
Bart.
^ permalink raw reply
* [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly
From: Greg Kroah-Hartman @ 2017-04-18 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491245884-15852-14-git-send-email-labbott@redhat.com>
On Mon, Apr 03, 2017 at 11:57:55AM -0700, Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available and setting one up messed up the coherency model.
> These days, CMA can be allocated directly from the APIs. Switch to using
> this model to avoid needing a dummy device. This also mitigates some of
> the caching problems (e.g. dma_alloc_coherent only returning uncached
> memory).
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> drivers/staging/android/ion/Kconfig | 7 +++
> drivers/staging/android/ion/Makefile | 3 +-
> drivers/staging/android/ion/ion_cma_heap.c | 97 ++++++++----------------------
> 3 files changed, 35 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
> index 206c4de..15108c4 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -10,3 +10,10 @@ menuconfig ION
> If you're not using Android its probably safe to
> say N here.
>
> +config ION_CMA_HEAP
> + bool "Ion CMA heap support"
> + depends on ION && CMA
> + help
> + Choose this option to enable CMA heaps with Ion. This heap is backed
> + by the Contiguous Memory Allocator (CMA). If your system has these
> + regions, you should say Y here.
> diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
> index 26672a0..66d0c4a 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
> ion_page_pool.o ion_system_heap.o \
> - ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
> + ion_carveout_heap.o ion_chunk_heap.o
> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> ifdef CONFIG_COMPAT
> obj-$(CONFIG_ION) += compat_ion.o
> endif
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c
> index d562fd7..f3e0f59 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -19,24 +19,19 @@
> #include <linux/slab.h>
> #include <linux/errno.h>
> #include <linux/err.h>
> -#include <linux/dma-mapping.h>
> +#include <linux/cma.h>
> +#include <linux/scatterlist.h>
>
> #include "ion.h"
> #include "ion_priv.h"
>
> struct ion_cma_heap {
> struct ion_heap heap;
> - struct device *dev;
> + struct cma *cma;
> };
>
> #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
>
> -struct ion_cma_buffer_info {
> - void *cpu_addr;
> - dma_addr_t handle;
> - struct sg_table *table;
> -};
> -
>
> /* ION CMA heap operations functions */
> static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
> @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
> unsigned long flags)
> {
> struct ion_cma_heap *cma_heap = to_cma_heap(heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info;
> -
> - dev_dbg(dev, "Request buffer allocation len %ld\n", len);
> -
> - if (buffer->flags & ION_FLAG_CACHED)
> - return -EINVAL;
> + struct sg_table *table;
> + struct page *pages;
> + int ret;
>
> - info = kzalloc(sizeof(*info), GFP_KERNEL);
> - if (!info)
> + pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
> + if (!pages)
> return -ENOMEM;
>
> - info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
> - GFP_HIGHUSER | __GFP_ZERO);
> -
> - if (!info->cpu_addr) {
> - dev_err(dev, "Fail to allocate buffer\n");
> + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + if (!table)
> goto err;
> - }
>
> - info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
> - if (!info->table)
> + ret = sg_alloc_table(table, 1, GFP_KERNEL);
> + if (ret)
> goto free_mem;
>
> - if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
> - len))
> - goto free_table;
> - /* keep this for memory release */
> - buffer->priv_virt = info;
> - buffer->sg_table = info->table;
> - dev_dbg(dev, "Allocate buffer %p\n", buffer);
> + sg_set_page(table->sgl, pages, len, 0);
> +
> + buffer->priv_virt = pages;
> + buffer->sg_table = table;
> return 0;
>
> -free_table:
> - kfree(info->table);
> free_mem:
> - dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> + kfree(table);
> err:
> - kfree(info);
> + cma_release(cma_heap->cma, pages, buffer->size);
> return -ENOMEM;
> }
>
> static void ion_cma_free(struct ion_buffer *buffer)
> {
> struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> + struct page *pages = buffer->priv_virt;
>
> - dev_dbg(dev, "Release buffer %p\n", buffer);
> /* release memory */
> - dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
> + cma_release(cma_heap->cma, pages, buffer->size);
> /* release sg table */
> - sg_free_table(info->table);
> - kfree(info->table);
> - kfree(info);
> -}
> -
> -static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
> - struct vm_area_struct *vma)
> -{
> - struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> -
> - return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
> - buffer->size);
> -}
> -
> -static void *ion_cma_map_kernel(struct ion_heap *heap,
> - struct ion_buffer *buffer)
> -{
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> - /* kernel memory mapping has been done at allocation time */
> - return info->cpu_addr;
> -}
> -
> -static void ion_cma_unmap_kernel(struct ion_heap *heap,
> - struct ion_buffer *buffer)
> -{
> + sg_free_table(buffer->sg_table);
> + kfree(buffer->sg_table);
> }
>
> static struct ion_heap_ops ion_cma_ops = {
> .allocate = ion_cma_allocate,
> .free = ion_cma_free,
> - .map_user = ion_cma_mmap,
> - .map_kernel = ion_cma_map_kernel,
> - .unmap_kernel = ion_cma_unmap_kernel,
> + .map_user = ion_heap_map_user,
> + .map_kernel = ion_heap_map_kernel,
> + .unmap_kernel = ion_heap_unmap_kernel,
> };
>
> struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
> @@ -147,7 +102,7 @@ struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
> * get device from private heaps data, later it will be
> * used to make the link with reserved CMA memory
> */
> - cma_heap->dev = data->priv;
> + cma_heap->cma = data->priv;
> cma_heap->heap.type = ION_HEAP_TYPE_DMA;
> return &cma_heap->heap;
> }
With CMA disabled, I get the following build error with this patch
applied:
drivers/built-in.o: In function `ion_heap_create':
(.text+0x21036f): undefined reference to `ion_cma_heap_create'
drivers/built-in.o: In function `ion_heap_destroy':
(.text+0x21040c): undefined reference to `ion_cma_heap_destroy'
So some Kconfig dependancy isn't quite correct here. Can you fix that
up and resend the remaining patches? I'd like to get this into 4.12-rc1
if possible...
thanks,
greg k-h
^ permalink raw reply
* [PATCH V2] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-18 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418051526.GN28191@vireshk-i7>
On Tuesday, April 18, 2017 10:45:26 AM Viresh Kumar wrote:
> On 17-04-17, 18:40, Rafael J. Wysocki wrote:
> > On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote:
> > > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote:
> > > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
> > > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote:
> > > > >> Compiling the DT file with W=1, DTC warns like follows:
> > > > >>
> > > > >> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> > > > >> unit name, but no reg property
> > > > >>
> > > > >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > > > >> "reg" property.
> > > > >>
> > > > >> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > >> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > > > >> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > > > >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > > > >> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> > > > >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > > > >> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > >
> > > > > OK, so any ACKs from the DT side? Rob?
> > > > >
> > > > > Thanks,
> > > > > Rafael
> > > >
> > > >
> > > >
> > > > I see Rob's Acked-by.
> > > >
> > > > https://lkml.org/lkml/2017/4/13/648
> > >
> > > Indeed. Thanks!
> >
> > But it doesn't apply on top of -rc7 for me, so I guess there is new 4.12-candidate
> > material in the DTS tree that conflicts with this, in which case it is better to route
> > it through the DTS tree IMO.
>
> Yes a minor conflict. I have sent the rebased version now, see if you
> want to apply it directly or want arm-soc guys to do it.
I'm going to apply the rebased one.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] arm64: xen: Implement EFI reset_system callback
From: Matt Fleming @ 2017-04-18 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406155453.GA3966@leverpostej>
On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
>
> Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> rather than spreading it further.
>
> IMO, given reset_system is a *mandatory* function, the Xen wrapper
> should provide an implementation.
>
> I don't see why you can't implement a wrapper that calls the usual Xen
> poweroff/reset functions.
I realise I'm making a sweeping generalisation, but adding
EFI_PARAVIRT is almost always the wrong thing to do.
I'd much prefer to see Mark's idea implemented.
^ permalink raw reply
* [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
From: David Laight @ 2017-04-18 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E205199C0@FRAEML521-MBX.china.huawei.com>
From: Gabriele Paoloni
> Sent: 13 April 2017 10:11
> > > Till now only the Intel ixgbe could support enable
> > > Relaxed ordering in the drivers for special architecture,
> > > but the ARCH_WANT_RELAX_ORDER is looks like a general name
> > > for all arch, so rename to a specific name for intel
> > > card looks more appropriate.
> > >
> > > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> >
> > This is not a driver specific facility.
> >
> > Any driver can test this symbol and act accordingly.
> >
> > Just because IXGBE is the first and only user, doesn't mean
> > the facility is driver specific.
>
>
> Please correct me if I am wrong but my understanding is that the standard
> way to enable/disable relaxed ordering is to set/clear bit 4 of the Device
> Control Register (PCI_EXP_DEVCTL_RELAX_EN 0x0010 /* Enable relaxed
> ordering */).
> Now I have looked up for all drivers either enabling or disabling relaxed
> ordering and none of them seems to need a symbol to decide whether to
> enable it or not.
> Also it seems to me enabling/disabling relaxed ordering is never bound to the
> host architecture.
>
> So why this should be (or it is expected to be) a generic symbol?
> Wouldn't it be more correct to have this as a driver specific symbol now and
> move it to a generic one later once we have other drivers requiring it?
'Relaxed ordering' is a bit in the TLP header.
A device (like the ixgbe hardware) can set it for some transactions and
still have the transactions 'ordered enough' for the driver to work.
(If all transactions have 'relaxed ordering' set then I suspect it is
almost impossible to write a working driver.)
The host side could (probably does) have a bit to enable 'relaxed ordering',
it could also enforce stronger ordering than required by the PCIe spec
(eg keeping reads in order).
Clearly, on some sparc64 systems, ixgbe needs to use 'relaxed ordering'.
To me this requires two separate bits be enabled:
1) to the ixgbe driver to generate the 'relaxed' TLP.
2) to the host to actually act on them.
If the ixgbe driver works when both are enabled why have options to
disable either (except for bug-finding)?
David
^ permalink raw reply
* Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340)
From: Mark Rutland @ 2017-04-18 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512268.28092.8.camel@v3.sk>
On Tue, Apr 18, 2017 at 12:44:28PM +0200, Lubomir Rintel wrote:
> Hi,
Hi,
> I'm getting a crash that looks awfully lot like what ddc37832a1 [ARM:
> 8634/1: hw_breakpoint: blacklist Scorpion CPUs] aims to fix.
Just to check, have you successfully booted a kernel on this board
before? i.e. is this a new crash?
> My hardware doesn't use a Scorpion CPU though -- it uses a Cortex-A9
> (cpuid=0x412fc091).
>
> [????0.157000] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> [????0.157000] Modules linked in:
> [????0.157000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-0.rc3.git0.2.spear2.fc26.armv7hl #1
> [????0.157000] Hardware name: ST SPEAr1340 SoC with Flattened Device Tree
> [????0.157000] task: ef102b80 task.stack: ef0fa000
> [????0.157000] PC is at arch_hw_breakpoint_init+0x130/0x2a0
> [????0.157000] LR is at arch_hw_breakpoint_init+0x7c/0x2a0
> [????0.157000] pc : [<c0e0538c>]????lr : [<c0e052d8>]????psr: 60000013
It would be helpful to know which specific access that is.
Can you figure that out with addr2line, e.g.
$ addr2line -ife vmlinux c0e0538c
Thanks,
Mark
^ permalink raw reply
* [PATCH] ARM: V7M: Preserve registers across switch from Thread to Handler mode
From: Vladimir Murzin @ 2017-04-18 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490861391-35484-2-git-send-email-vladimir.murzin@arm.com>
On 30/03/17 09:09, Vladimir Murzin wrote:
> According to ARMv7 ARM, when exception is taken content of r0-r3, r12
> is unknown (see ExceptionTaken() pseudocode). Even though existent
> implementations keep these register unchanged, preserve them to be in
> line with architecture.
>
> Reported-by: Dobromir Stefanov <dobromir.stefanov@arm.com>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm/mm/proc-v7m.S | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
> index 5049777..47a5acc 100644
> --- a/arch/arm/mm/proc-v7m.S
> +++ b/arch/arm/mm/proc-v7m.S
> @@ -135,9 +135,11 @@ __v7m_setup_cont:
> dsb
> mov r6, lr @ save LR
> ldr sp, =init_thread_union + THREAD_START_SP
> + stmia sp, {r0-r3, r12}
> cpsie i
> svc #0
> 1: cpsid i
> + ldmia sp, {r0-r3, r12}
> str r5, [r12, #11 * 4] @ restore the original SVC vector entry
> mov lr, r6 @ restore LR
>
>
Ok for patch tracker?
Vladimir
^ 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