* Re: [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: Leo Yan
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Suzuki K Poulose, Stephen Boyd, linux-doc, linux-kernel,
devicetree, linux-arm-kernel, linux-arm-msm, linux-soc,
Mike Leach, Sudeep Holla
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
* Re: [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: Jacob Chen
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Heiko Stuebner, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAFLEztSQ1-WU7KAXzuB66htXiaQN4wd=XmM5XtjZcoONt77XmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> +&i2c0 {
>> + status = "okay";
>> + clock-frequency = <400000>;
>> +
>> + rk818: pmic@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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170418150133.31679-1-andrew.smirnov@gmail.com>
Enable PCIe peripheral on this board.
Cc: yurovsky@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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@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: Shawn Guo
Cc: Andrey Smirnov, yurovsky-Re5JQEeQqe8AvxtiuMwx3w, Dong Aisheng,
Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170418150133.31679-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: yurovsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: Dong Aisheng <aisheng.dong-3arQi8VN3Tc@public.gmane.org>
Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Signed-off-by: Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
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@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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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: Shawn Guo
Cc: Dong Aisheng, Mark Rutland, devicetree, Andrey Smirnov,
Russell King, linux-kernel, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel, yurovsky
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@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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@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@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: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, 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@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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@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@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: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, 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@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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@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@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@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@IMX7_POWER_DOMAIN_PCIE_PHY {
+ #power-domain-cells = <0>;
+ reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
+ power-supply = <®_1p0d>;
+ };
+ };
+ };
};
aips2: aips-bus@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: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, 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@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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@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: Shawn Guo
Cc: Andrey Smirnov, yurovsky, Dong Aisheng, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, 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@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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@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: Shawn Guo
Cc: Dong Aisheng, Mark Rutland, devicetree, Andrey Smirnov,
Russell King, linux-kernel, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel, yurovsky
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@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 0/4] staging: add ccree crypto driver
From: Gilad Ben-Yossef @ 2017-04-18 14:07 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Mark Rutland,
Greg Kroah-Hartman, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b
Cc: linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, gilad.benyossef-5wv7dgnIgG8,
Binoy Jayan, Ofir Drang
Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
accelerators. It is supported by a long lived series of out of tree
drivers, which I am now in the process of unifying and upstreaming.
This is the first drop, supporting the new CryptoCell 712 REE.
The code still needs some cleanup before maturing to a proper
upstream driver, which I am in the process of doing. However,
as discussion of some of the capabilities of the hardware and
its application to some dm-crypt and dm-verity features recently
took place I though it is better to do this in the open via the
staging tree.
A Git repository based off of Linux 4.11-rc7 is available at
https://github.com/gby/linux.git branch ccree.
Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
CC: Binoy Jayan <binoy.jayan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CC: Ofir Drang <ofir.drang-5wv7dgnIgG8@public.gmane.org>
Gilad Ben-Yossef (4):
staging: add ccree crypto driver
staging: ccree: add TODO list
staging: ccree: add devicetree bindings
MAINTAINERS: add Gilad BY as maintainer for ccree
.../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
MAINTAINERS | 8 +
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 2 +-
drivers/staging/ccree/Kconfig | 52 +
drivers/staging/ccree/Makefile | 3 +
drivers/staging/ccree/TODO | 27 +
drivers/staging/ccree/bsp.h | 21 +
drivers/staging/ccree/cc_bitops.h | 62 +
drivers/staging/ccree/cc_crypto_ctx.h | 299 +++
drivers/staging/ccree/cc_hal.h | 35 +
drivers/staging/ccree/cc_hw_queue_defs.h | 603 +++++
drivers/staging/ccree/cc_lli_defs.h | 57 +
drivers/staging/ccree/cc_pal_log.h | 188 ++
drivers/staging/ccree/cc_pal_log_plat.h | 33 +
drivers/staging/ccree/cc_pal_types.h | 97 +
drivers/staging/ccree/cc_pal_types_plat.h | 29 +
drivers/staging/ccree/cc_regs.h | 106 +
drivers/staging/ccree/dx_crys_kernel.h | 180 ++
drivers/staging/ccree/dx_env.h | 224 ++
drivers/staging/ccree/dx_host.h | 155 ++
drivers/staging/ccree/dx_reg_base_host.h | 34 +
drivers/staging/ccree/dx_reg_common.h | 26 +
drivers/staging/ccree/hash_defs.h | 78 +
drivers/staging/ccree/hw_queue_defs_plat.h | 43 +
drivers/staging/ccree/ssi_aead.c | 2832 ++++++++++++++++++++
drivers/staging/ccree/ssi_aead.h | 120 +
drivers/staging/ccree/ssi_buffer_mgr.c | 1876 +++++++++++++
drivers/staging/ccree/ssi_buffer_mgr.h | 105 +
drivers/staging/ccree/ssi_cipher.c | 1503 +++++++++++
drivers/staging/ccree/ssi_cipher.h | 89 +
drivers/staging/ccree/ssi_config.h | 61 +
drivers/staging/ccree/ssi_driver.c | 557 ++++
drivers/staging/ccree/ssi_driver.h | 228 ++
drivers/staging/ccree/ssi_fips.c | 65 +
drivers/staging/ccree/ssi_fips.h | 70 +
drivers/staging/ccree/ssi_fips_data.h | 315 +++
drivers/staging/ccree/ssi_fips_ext.c | 96 +
drivers/staging/ccree/ssi_fips_ll.c | 1681 ++++++++++++
drivers/staging/ccree/ssi_fips_local.c | 369 +++
drivers/staging/ccree/ssi_fips_local.h | 77 +
drivers/staging/ccree/ssi_hash.c | 2751 +++++++++++++++++++
drivers/staging/ccree/ssi_hash.h | 101 +
drivers/staging/ccree/ssi_ivgen.c | 301 +++
drivers/staging/ccree/ssi_ivgen.h | 72 +
drivers/staging/ccree/ssi_pm.c | 150 ++
drivers/staging/ccree/ssi_pm.h | 46 +
drivers/staging/ccree/ssi_pm_ext.c | 60 +
drivers/staging/ccree/ssi_pm_ext.h | 33 +
drivers/staging/ccree/ssi_request_mgr.c | 713 +++++
drivers/staging/ccree/ssi_request_mgr.h | 60 +
drivers/staging/ccree/ssi_sram_mgr.c | 138 +
drivers/staging/ccree/ssi_sram_mgr.h | 80 +
drivers/staging/ccree/ssi_sysfs.c | 440 +++
drivers/staging/ccree/ssi_sysfs.h | 54 +
55 files changed, 17429 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
create mode 100644 drivers/staging/ccree/Kconfig
create mode 100644 drivers/staging/ccree/Makefile
create mode 100644 drivers/staging/ccree/TODO
create mode 100644 drivers/staging/ccree/bsp.h
create mode 100644 drivers/staging/ccree/cc_bitops.h
create mode 100644 drivers/staging/ccree/cc_crypto_ctx.h
create mode 100644 drivers/staging/ccree/cc_hal.h
create mode 100644 drivers/staging/ccree/cc_hw_queue_defs.h
create mode 100644 drivers/staging/ccree/cc_lli_defs.h
create mode 100644 drivers/staging/ccree/cc_pal_log.h
create mode 100644 drivers/staging/ccree/cc_pal_log_plat.h
create mode 100644 drivers/staging/ccree/cc_pal_types.h
create mode 100644 drivers/staging/ccree/cc_pal_types_plat.h
create mode 100644 drivers/staging/ccree/cc_regs.h
create mode 100644 drivers/staging/ccree/dx_crys_kernel.h
create mode 100644 drivers/staging/ccree/dx_env.h
create mode 100644 drivers/staging/ccree/dx_host.h
create mode 100644 drivers/staging/ccree/dx_reg_base_host.h
create mode 100644 drivers/staging/ccree/dx_reg_common.h
create mode 100644 drivers/staging/ccree/hash_defs.h
create mode 100644 drivers/staging/ccree/hw_queue_defs_plat.h
create mode 100644 drivers/staging/ccree/ssi_aead.c
create mode 100644 drivers/staging/ccree/ssi_aead.h
create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.c
create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.h
create mode 100644 drivers/staging/ccree/ssi_cipher.c
create mode 100644 drivers/staging/ccree/ssi_cipher.h
create mode 100644 drivers/staging/ccree/ssi_config.h
create mode 100644 drivers/staging/ccree/ssi_driver.c
create mode 100644 drivers/staging/ccree/ssi_driver.h
create mode 100644 drivers/staging/ccree/ssi_fips.c
create mode 100644 drivers/staging/ccree/ssi_fips.h
create mode 100644 drivers/staging/ccree/ssi_fips_data.h
create mode 100644 drivers/staging/ccree/ssi_fips_ext.c
create mode 100644 drivers/staging/ccree/ssi_fips_ll.c
create mode 100644 drivers/staging/ccree/ssi_fips_local.c
create mode 100644 drivers/staging/ccree/ssi_fips_local.h
create mode 100644 drivers/staging/ccree/ssi_hash.c
create mode 100644 drivers/staging/ccree/ssi_hash.h
create mode 100644 drivers/staging/ccree/ssi_ivgen.c
create mode 100644 drivers/staging/ccree/ssi_ivgen.h
create mode 100644 drivers/staging/ccree/ssi_pm.c
create mode 100644 drivers/staging/ccree/ssi_pm.h
create mode 100644 drivers/staging/ccree/ssi_pm_ext.c
create mode 100644 drivers/staging/ccree/ssi_pm_ext.h
create mode 100644 drivers/staging/ccree/ssi_request_mgr.c
create mode 100644 drivers/staging/ccree/ssi_request_mgr.h
create mode 100644 drivers/staging/ccree/ssi_sram_mgr.c
create mode 100644 drivers/staging/ccree/ssi_sram_mgr.h
create mode 100644 drivers/staging/ccree/ssi_sysfs.c
create mode 100644 drivers/staging/ccree/ssi_sysfs.h
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-18 14:04 UTC (permalink / raw)
To: Viresh Kumar
Cc: Masahiro Yamada, Rob Herring, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Benoît Cousson, Tony Lindgren, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai
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@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] fpga: region: add missing DT documentation for config complete timeout
From: Tobias Klauser @ 2017-04-18 13:40 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer
Cc: Rob Herring, Mark Rutland, linux-fpga-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Commit 42d5ec954719 ("fpga: add config complete timeout") introduced the
config complete property but didn't include the corresponding DT binding
documentation. Add it now.
Signed-off-by: Tobias Klauser <tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org>
---
Documentation/devicetree/bindings/fpga/fpga-region.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
index 81bf3adba24b..6db8aeda461a 100644
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -193,6 +193,8 @@ Optional properties:
- region-freeze-timeout-us : The maximum time in microseconds to wait for
bridges to successfully become disabled before the region has been
programmed.
+- config-complete-timeout-us : The maximum time in microseconds time for the
+ FPGA to go to operating mode after the region has been programmed.
- child nodes : devices in the FPGA after programming.
In the example below, when an overlay is applied targeting fpga-region0,
--
2.12.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Peter Rosin @ 2017-04-18 13:36 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel, Greg Kroah-Hartman, Mark Rutland, devicetree,
Lars-Peter Clausen, Wolfram Sang, linux-iio, Jonathan Corbet,
linux-doc, kernel, Paul Gortmaker, Rob Herring, linux-i2c,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <1492509996.2432.63.camel@pengutronix.de>
On 2017-04-18 12:06, Philipp Zabel wrote:
> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
>> Allow specifying that a single multiplexer controller can be used to
>> control several parallel multiplexers, thus enabling sharing of the
>> multiplexer controller by different consumers.
>>
>> Add a binding for a first mux controller in the form of a GPIO based mux
>> controller.
>>
>> Acked-by: Jonathan Cameron <jic23@kernel.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> Documentation/devicetree/bindings/mux/gpio-mux.txt | 69 +++++++++
>> .../devicetree/bindings/mux/mux-controller.txt | 157 +++++++++++++++++++++
>> MAINTAINERS | 6 +
>> include/dt-bindings/mux/mux.h | 16 +++
>> 4 files changed, 248 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.txt
>> create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt
>> create mode 100644 include/dt-bindings/mux/mux.h
>>
>> diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt b/Documentation/devicetree/bindings/mux/gpio-mux.txt
>> new file mode 100644
>> index 000000000000..b8f746344d80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mux/gpio-mux.txt
>> @@ -0,0 +1,69 @@
>> +GPIO-based multiplexer controller bindings
>> +
>> +Define what GPIO pins are used to control a multiplexer. Or several
>> +multiplexers, if the same pins control more than one multiplexer.
>> +
>> +Required properties:
>> +- compatible : "gpio-mux"
>> +- mux-gpios : list of gpios used to control the multiplexer, least
>> + significant bit first.
>> +- #mux-control-cells : <0>
>> +* Standard mux-controller bindings as decribed in mux-controller.txt
>> +
>> +Optional properties:
>> +- idle-state : if present, the state the mux will have when idle. The
>> + special state MUX_IDLE_AS_IS is the default.
>> +
>> +The multiplexer state is defined as the number represented by the
>> +multiplexer GPIO pins, where the first pin is the least significant
>> +bit. An active pin is a binary 1, an inactive pin is a binary 0.
>> +
>> +Example:
>> +
>> + mux: mux-controller {
>> + compatible = "gpio-mux";
>> + #mux-control-cells = <0>;
>> +
>> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
>> + <&pioA 1 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + adc-mux {
>> + compatible = "io-channel-mux";
>> + io-channels = <&adc 0>;
>> + io-channel-names = "parent";
>> +
>> + mux-controls = <&mux>;
>> +
>> + channels = "sync-1", "in", "out", "sync-2";
>> + };
>
> Could you explain in more detail the reasoning behind this split between
> the mux controller and the actual mux?
> For SoC internal video bus muxes that are controlled by a register
> bitfield, it seems a bit strange to have to split them into two device
> tree nodes.
The background for the split is in the cover letter.
Basically, when the same set of gpio lines control several muxes, and
when these muxes are used for unrelated things, you needs some extra
complexity.
The mux controller is what controls those gpio lines, and thus the mux
state for all muxes they are connected to. The consumers refer to the
mux controller and request a certain state. So, the consumers naturally
need to interact or else they would destroy the mux state for each other.
Regarding the device tree layout, perhaps the mux consumers could be
children of the mux controller, but I think that would make the mux
controller more like a bus instead of a class. Anyway, I don't want to
go there again, because I remember it as a messy place. Maybe I could
do better now than I did way back when, but I'm not going willingly
and someone would have to force me.
The benefit of the split is that the mux consumer need no longer concern
itself with if the mux is controlled by gpio lines, an I2C based chip
like the ADG792 or if it is controlled by some mmio register. You can
thus avoid building muxing sub-sub-systems like drivers/i2c/muxes for
every subsystem needing muxing.
The drawback is that you get an extra device tree node for the mux
controller that may not make sense if it is in no way possible to
reuse your driver for HW with a different mux. Which may be the case
for your video case? But for generic stuff like ADC lines and I2C
buses, muxing options are diverse...
> Basically I'm trying to figure out whether a video mux (which has a mux
> control plus OF-graph bindings to describe its ports and connections)
> would fit into the same category as an adc-mux or i2c-mux, or whether it
> would be better to handle them as a specialized form of mux-controller.
I did read some earlier thread about your muxing requirements and I got
the impression that you also had HW which controlled the mux with
gpio lines? In that case, the mux subsystem seems like a perfect fit
with a new syscon/mmio/reg based mux driver (or whatever the name should
be, I think I'd go with syscon) pretty much as suggested in your RFC
patches. And then of course reuse the existing gpio-mux driver for the
other case.
The video-mux would fit as a mux consumer just like the iio-mux and the
i2c-mux are mux consumers, with input 0/input 1 being the port that
would be selected with the mux I guess. I don't think there should be a
bunch of video code inside the drivers/mux subdir, for the same reason
there's no iio/i2c code in there.
If I got things wrong when I skimmed whatever I came across, and if the
mmio register is the only mux control option in the stars, it becomes
less obvious... It's of course still possible to hook into the mux
subsystem, but the benefit is questionable. And you do get the extra
device tree node. You could of course also implement a mux driver
outside of drivers/mux and thus make use of the mux api, but it's tiny
and any benefit is truly small.
Cheers,
peda
^ permalink raw reply
* Re: [PATCH] of: Add vendor prefix for ROHM Semiconductor
From: Geert Uytterhoeven @ 2017-04-18 13:35 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree@vger.kernel.org, Linux-Renesas, Marek Vasut,
Rob Herring, Geert Uytterhoeven
In-Reply-To: <20170416180111.16795-1-marek.vasut+renesas@gmail.com>
On Sun, Apr 16, 2017 at 8:01 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> ROHM Semiconductor Co., Ltd. offer PMICs, touchscreen controllers etc.
> http://www.rohm.com/web/global/
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk
From: Guenter Roeck @ 2017-04-18 13:18 UTC (permalink / raw)
To: William Wu
Cc: Felipe Balbi, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
Heiko Stübner, linux-kernel,
linux-usb-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Frank Wang,
Tao Huang, Doug Anderson, Brian Norris,
daniel.meng-TNX95d0MmH7DzftRWevZcw, wulf
In-Reply-To: <1492492659-19266-1-git-send-email-william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Apr 17, 2017 at 10:17 PM, William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> This patch adds a quirk to disable USB 2.0 MAC linestate check
> during HS transmit. Refer the dwc3 databook, we can use it for
> some special platforms if the linestate not reflect the expected
> line state(J) during transmission.
>
> When use this quirk, the controller implements a fixed 40-bit
> TxEndDelay after the packet is given on UTMI and ignores the
> linestate during the transmit of a token (during token-to-token
> and token-to-data IPGAP).
>
> On some rockchip platforms (e.g. rk3399), it requires to disable
> the u2mac linestate check to decrease the SSPLIT token to SETUP
> token inter-packet delay from 566ns to 466ns, and fix the issue
> that FS/LS devices not recognized if inserted through USB 3.0 HUB.
>
> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> Changes in v2:
> - fix coding style
>
> Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
> drivers/usb/dwc3/core.c | 14 ++++++++++----
> drivers/usb/dwc3/core.h | 4 ++++
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index f658f39..6a89f0c 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -45,6 +45,8 @@ Optional properties:
> a free-running PHY clock.
> - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
> from P0 to P1/P2/P3 without delay.
> + - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
> + during HS transmit.
All other disable-something quirks are named
"snps,dis-something-quirk". Maybe use the same naming convention ?
> - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
> utmi_l1_suspend_n, false when asserts utmi_sleep_n
> - snps,hird-threshold: HIRD threshold
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 455d89a..03429c5 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
> dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
> }
>
> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> +
My understanding is that the register was only introduced with dwc3
revision 2.50a. Is it ok to read and write it unconditionally ?
> /*
> * Enable hardware control of sending remote wakeup in HS when
> * the device is in the L1 state.
> */
> - if (dwc->revision >= DWC3_REVISION_290A) {
> - reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> + if (dwc->revision >= DWC3_REVISION_290A)
> reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> - dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
> - }
> +
> + if (dwc->tx_ipgap_linecheck_dis_quirk)
> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
> +
> + dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>
> return 0;
>
> @@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> "snps,dis-u2-freeclk-exists-quirk");
> dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
> "snps,dis-del-phy-power-chg-quirk");
> + dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
> + "snps,tx-ipgap-linecheck-dis-quirk");
>
> dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
> "snps,tx_de_emphasis_quirk");
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 981c77f..3c2537b 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -204,6 +204,7 @@
> #define DWC3_GCTL_DSBLCLKGTNG BIT(0)
>
> /* Global User Control 1 Register */
> +#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
> #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
>
> /* Global USB2 PHY Configuration Register */
> @@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
> * provide a free-running PHY clock.
> * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
> * change quirk.
> + * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
> + * check during HS transmit.
> * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
> * @tx_de_emphasis: Tx de-emphasis value
> * 0 - -6dB de-emphasis
> @@ -1004,6 +1007,7 @@ struct dwc3 {
> unsigned dis_rxdet_inp3_quirk:1;
> unsigned dis_u2_freeclk_exists_quirk:1;
> unsigned dis_del_phy_power_chg_quirk:1;
> + unsigned tx_ipgap_linecheck_dis_quirk:1;
>
> unsigned tx_de_emphasis_quirk:1;
> unsigned tx_de_emphasis:2;
> --
> 2.0.0
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt
From: Niklas Cassel @ 2017-04-18 12:39 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, David S. Miller, Joao Pinto,
Niklas Cassel, Alexandre TORGUE, Giuseppe CAVALLARO,
Thierry Reding, Eric Engestrom
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
The hardware has a LPI interrupt.
There is already code in the stmmac driver to parse and handle the
interrupt. However, this information was missing from the DT binding.
At the same time, improve the description of the existing interrupts.
Signed-off-by: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
---
Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c384ce..c3a7be6615c5 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -7,9 +7,12 @@ Required properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupts: Should contain the STMMAC interrupts
-- interrupt-names: Should contain the interrupt names "macirq"
- "eth_wake_irq" if this interrupt is supported in the "interrupts"
- property
+- interrupt-names: Should contain a list of interrupt names corresponding to
+ the interrupts in the interrupts property, if available.
+ Valid interrupt names are:
+ - "macirq" (combined signal for various interrupt events)
+ - "eth_wake_irq" (the interrupt to manage the remote wake-up packet detection)
+ - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
- phy-mode: See ethernet.txt file in the same directory.
- snps,reset-gpio gpio number for phy reset.
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
@@ -152,8 +155,8 @@ Examples:
compatible = "st,spear600-gmac";
reg = <0xe0800000 0x8000>;
interrupt-parent = <&vic1>;
- interrupts = <24 23>;
- interrupt-names = "macirq", "eth_wake_irq";
+ interrupts = <24 23 22>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
mac-address = [000000000000]; /* Filled in by U-Boot */
max-frame-size = <3800>;
phy-mode = "gmii";
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver
From: Andy Shevchenko @ 2017-04-18 12:31 UTC (permalink / raw)
To: Eugeniy Paltsev, dmaengine-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dan Williams,
Vinod Koul, Rob Herring, Alexey Brodkin
In-Reply-To: <1491573855-1039-3-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote:
> This patch adds support for the DW AXI DMAC controller.
>
> DW AXI DMAC is a part of upcoming development board from Synopsys.
>
> In this driver implementation only DMA_MEMCPY and DMA_SG transfers
> are supported.
>
> +++ b/drivers/dma/axi_dma_platform.c
> @@ -0,0 +1,1044 @@
> +/*
> + * Synopsys DesignWare AXI DMA Controller driver.
> + *
> + * Copyright (C) 2017 Synopsys, Inc. (www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/dmaengine.h>
> +#include <linux/dmapool.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
Are you sure you still need of.h along with depends OF ?
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/property.h>
> +#include <linux/types.h>
> +
> +#include "axi_dma_platform.h"
> +#include "axi_dma_platform_reg.h"
Can't you have this in one header?
> +#include "dmaengine.h"
> +#include "virt-dma.h"
> +#define AXI_DMA_BUSWIDTHS \
> + (DMA_SLAVE_BUSWIDTH_1_BYTE | \
> + DMA_SLAVE_BUSWIDTH_2_BYTES | \
> + DMA_SLAVE_BUSWIDTH_4_BYTES | \
> + DMA_SLAVE_BUSWIDTH_8_BYTES | \
> + DMA_SLAVE_BUSWIDTH_16_BYTES | \
> + DMA_SLAVE_BUSWIDTH_32_BYTES | \
> + DMA_SLAVE_BUSWIDTH_64_BYTES)
> +/* TODO: check: do we need to use BIT() macro here? */
Still TODO? I remember I answered to this on the first round.
> +
> +static inline void
> +axi_dma_iowrite32(struct axi_dma_chip *chip, u32 reg, u32 val)
> +{
> + iowrite32(val, chip->regs + reg);
Are you going to use IO ports for this IP? I don't think so.
Wouldn't be better to call readl()/writel() instead?
> +}
> +static inline void
> +axi_chan_iowrite64(struct axi_dma_chan *chan, u32 reg, u64 val)
> +{
> + iowrite32(val & 0xFFFFFFFF, chan->chan_regs + reg);
Useless conjunction.
> + iowrite32(val >> 32, chan->chan_regs + reg + 4);
> +}
Can your hardware get 8 bytes at once?
For such cases we have iowrite64() for 64-bit kernels
But with readq()/writeq() we have specific helpers to make this pretty,
i.e. lo_hi_readq() / lo_hi_writeq() (or hi_lo_*() variants).
> +static inline void axi_chan_irq_disable(struct axi_dma_chan *chan,
> u32 irq_mask)
> +{
> + u32 val;
> +
> + if (likely(irq_mask == DWAXIDMAC_IRQ_ALL)) {
> + axi_chan_iowrite32(chan, CH_INTSTATUS_ENA,
> DWAXIDMAC_IRQ_NONE);
> + } else {
I don't see the benefit. (Yes, I see one read-less path, I think it
makes perplexity for nothing here)
> + val = axi_chan_ioread32(chan, CH_INTSTATUS_ENA);
> + val &= ~irq_mask;
> + axi_chan_iowrite32(chan, CH_INTSTATUS_ENA, val);
> + }
> +}
> +static inline void axi_chan_disable(struct axi_dma_chan *chan)
> +{
> +}
> +
> +static inline void axi_chan_enable(struct axi_dma_chan *chan)
> +{
> +}
> +static u32 axi_chan_get_xfer_width(struct axi_dma_chan *chan,
> dma_addr_t src,
> + dma_addr_t dst, size_t len)
> +{
> + u32 max_width = chan->chip->dw->hdata->m_data_width;
> + size_t sdl = (src | dst | len);
Redundant parens, redundant temporary variable (you may do this in
place).
> +
> + return min_t(size_t, __ffs(sdl), max_width);
> +}
> +static void axi_desc_put(struct axi_dma_desc *desc)
> +{
> + struct axi_dma_chan *chan = desc->chan;
> + struct dw_axi_dma *dw = chan->chip->dw;
> + struct axi_dma_desc *child, *_next;
> + unsigned int descs_put = 0;
> + list_for_each_entry_safe(child, _next, &desc->xfer_list,
> xfer_list) {
xfer_list looks redundant.
Can you elaborate why virtual channel management is not working for you?
> + list_del(&child->xfer_list);
> + dma_pool_free(dw->desc_pool, child, child-
> >vd.tx.phys);
> + descs_put++;
> + }
> +}
> +/* Called in chan locked context */
> +static void axi_chan_block_xfer_start(struct axi_dma_chan *chan,
> + struct axi_dma_desc *first)
> +{
> + u32 reg, irq_mask;
> + u8 lms = 0;
Does it make any sense? It looks like lms is always 0.
Or I miss the source of its value?
> + u32 priority = chan->chip->dw->hdata->priority[chan->id];
Reversed xmas tree, please.
Btw, are you planning to use priority at all? For now on I didn't see a
single driver (from the set I have checked, like 4-5 of them) that uses
priority anyhow. It makes driver more complex for nothing.
> +
> + if (unlikely(axi_chan_is_hw_enable(chan))) {
> + dev_err(chan2dev(chan), "%s is non-idle!\n",
> + axi_chan_name(chan));
> +
> + return;
> + }
> +}
> +static void dma_chan_free_chan_resources(struct dma_chan *dchan)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> +
> + /* ASSERT: channel hw is idle */
> + if (axi_chan_is_hw_enable(chan))
> + dev_err(dchan2dev(dchan), "%s is non-idle!\n",
> + axi_chan_name(chan));
> +
> + axi_chan_disable(chan);
> + axi_chan_irq_disable(chan, DWAXIDMAC_IRQ_ALL);
> +
> + vchan_free_chan_resources(&chan->vc);
> +
> + dev_vdbg(dchan2dev(dchan), "%s: %s: descriptor still
> allocated: %u\n",
> + __func__, axi_chan_name(chan),
Redundant __func__ parameter for debug prints.
> + atomic_read(&chan->descs_allocated));
> +
> + pm_runtime_put(chan->chip->dev);
> +}
> +static struct dma_async_tx_descriptor *
> +dma_chan_prep_dma_sg(struct dma_chan *dchan,
> + struct scatterlist *dst_sg, unsigned int
> dst_nents,
> + struct scatterlist *src_sg, unsigned int
> src_nents,
> + unsigned long flags)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> + struct axi_dma_desc *first = NULL, *desc = NULL, *prev =
> NULL;
> + size_t dst_len = 0, src_len = 0, xfer_len = 0;
> + dma_addr_t dst_adr = 0, src_adr = 0;
> + u32 src_width, dst_width;
> + size_t block_ts, max_block_ts;
> + u32 reg;
> + u8 lms = 0;
Same about lms.
> +
> + dev_dbg(chan2dev(chan), "%s: %s: sn: %d dn: %d flags: 0x%lx",
> + __func__, axi_chan_name(chan), src_nents, dst_nents,
> flags);
Ditto for __func__.
> +
>
> + if (unlikely(dst_nents == 0 || src_nents == 0))
> + return NULL;
> +
> + if (unlikely(dst_sg == NULL || src_sg == NULL))
> + return NULL;
If we need those checks they should go to dmaengine.h/dmaengine.c.
> +static void axi_chan_list_dump_lli(struct axi_dma_chan *chan,
> + struct axi_dma_desc *desc_head)
> +{
> + struct axi_dma_desc *desc;
> +
> + axi_chan_dump_lli(chan, desc_head);
> + list_for_each_entry(desc, &desc_head->xfer_list, xfer_list)
> + axi_chan_dump_lli(chan, desc);
> +}
> +
> +
Redundant (one) empty line.
> +static void axi_chan_handle_err(struct axi_dma_chan *chan, u32
> status)
> +{
> + /* WARN about bad descriptor */
>
> + dev_err(chan2dev(chan),
> + "Bad descriptor submitted for %s, cookie: %d, irq:
> 0x%08x\n",
> + axi_chan_name(chan), vd->tx.cookie, status);
> + axi_chan_list_dump_lli(chan, vd_to_axi_desc(vd));
As I said earlier dw_dmac is *bad* example of the (virtual channel
based) DMA driver.
I guess you may just fail the descriptor and don't pretend it has been
processed successfully.
> +static int dma_chan_pause(struct dma_chan *dchan)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> + unsigned long flags;
> + unsigned int timeout = 20; /* timeout iterations */
> + int ret = -EAGAIN;
> + u32 val;
> +
> + spin_lock_irqsave(&chan->vc.lock, flags);
> +
> + val = axi_dma_ioread32(chan->chip, DMAC_CHEN);
> + val |= BIT(chan->id) << DMAC_CHAN_SUSP_SHIFT |
> + BIT(chan->id) << DMAC_CHAN_SUSP_WE_SHIFT;
> + axi_dma_iowrite32(chan->chip, DMAC_CHEN, val);
You have helpers which you don't use. Why?
> +
> + while (timeout--) {
In such cases I prefer do {} while (); to explicitly show that body goes
at least once.
> + if (axi_chan_irq_read(chan) &
> DWAXIDMAC_IRQ_SUSPENDED) {
> + ret = 0;
> + break;
> + }
> + udelay(2);
> + }
> +
> + axi_chan_irq_clear(chan, DWAXIDMAC_IRQ_SUSPENDED);
> +
> + chan->is_paused = true;
> +
> + spin_unlock_irqrestore(&chan->vc.lock, flags);
> +
> + return ret;
> +}
> +
> +/* Called in chan locked context */
> +static inline void axi_chan_resume(struct axi_dma_chan *chan)
> +{
> + u32 val;
> +
> + val = axi_dma_ioread32(chan->chip, DMAC_CHEN);
> + val &= ~(BIT(chan->id) << DMAC_CHAN_SUSP_SHIFT);
> + val |= (BIT(chan->id) << DMAC_CHAN_SUSP_WE_SHIFT);
> + axi_dma_iowrite32(chan->chip, DMAC_CHEN, val);
Use helper.
> +
> + chan->is_paused = false;
> +}
> +static int axi_dma_runtime_suspend(struct device *dev)
> +{
> + struct axi_dma_chip *chip = dev_get_drvdata(dev);
> +
> + dev_info(dev, "PAL: %s\n", __func__);
Noisy and useless.
We have functional tracer in kernel. Use it.
> +
> + axi_dma_irq_disable(chip);
> + axi_dma_disable(chip);
> +
> + clk_disable_unprepare(chip->clk);
> +
> + return 0;
> +}
> +
> +static int axi_dma_runtime_resume(struct device *dev)
> +{
> + struct axi_dma_chip *chip = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + dev_info(dev, "PAL: %s\n", __func__);
Ditto.
> +
> + ret = clk_prepare_enable(chip->clk);
> + if (ret < 0)
> + return ret;
> +
> + axi_dma_enable(chip);
> + axi_dma_irq_enable(chip);
> +
> + return 0;
> +}
> +static int dw_probe(struct platform_device *pdev)
> +{
> + struct axi_dma_chip *chip;
> + struct resource *mem;
> + struct dw_axi_dma *dw;
> + struct dw_axi_dma_hcfg *hdata;
> + u32 i;
> + int ret;
> +
> + chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> + if (!chip)
> + return -ENOMEM;
> +
> + dw = devm_kzalloc(&pdev->dev, sizeof(*dw), GFP_KERNEL);
> + if (!dw)
> + return -ENOMEM;
> +
> + hdata = devm_kzalloc(&pdev->dev, sizeof(*hdata), GFP_KERNEL);
> + if (!hdata)
> + return -ENOMEM;
> +
> + chip->dw = dw;
> + chip->dev = &pdev->dev;
> + chip->dw->hdata = hdata;
> +
> + chip->irq = platform_get_irq(pdev, 0);
> + if (chip->irq < 0)
> + return chip->irq;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + chip->regs = devm_ioremap_resource(chip->dev, mem);
> + if (IS_ERR(chip->regs))
> + return PTR_ERR(chip->regs);
> +
> + chip->clk = devm_clk_get(chip->dev, NULL);
> + if (IS_ERR(chip->clk))
> + return PTR_ERR(chip->clk);
> +
> + ret = parse_device_properties(chip);
> + if (ret)
> + return ret;
> +
> + dw->chan = devm_kcalloc(chip->dev, hdata->nr_channels,
> + sizeof(*dw->chan), GFP_KERNEL);
> + if (!dw->chan)
> + return -ENOMEM;
> +
> + ret = devm_request_irq(chip->dev, chip->irq,
> dw_axi_dma_intretupt,
> + IRQF_SHARED, DRV_NAME, chip);
> + if (ret)
> + return ret;
> +
> + /* Lli address must be aligned to a 64-byte boundary */
> + dw->desc_pool = dmam_pool_create(DRV_NAME, chip->dev,
> + sizeof(struct axi_dma_desc),
> 64, 0);
> + if (!dw->desc_pool) {
> + dev_err(chip->dev, "No memory for descriptors dma
> pool\n");
> + return -ENOMEM;
> + }
> +
> + INIT_LIST_HEAD(&dw->dma.channels);
> + for (i = 0; i < hdata->nr_channels; i++) {
> + struct axi_dma_chan *chan = &dw->chan[i];
> +
> + chan->chip = chip;
> + chan->id = (u8)i;
> + chan->chan_regs = chip->regs + COMMON_REG_LEN + i *
> CHAN_REG_LEN;
> + atomic_set(&chan->descs_allocated, 0);
> +
> + chan->vc.desc_free = vchan_desc_put;
> + vchan_init(&chan->vc, &dw->dma);
> + }
> +
> + /* Set capabilities */
> + dma_cap_set(DMA_MEMCPY, dw->dma.cap_mask);
> + dma_cap_set(DMA_SG, dw->dma.cap_mask);
> +
> + /* DMA capabilities */
> + dw->dma.chancnt = hdata->nr_channels;
> + dw->dma.src_addr_widths = AXI_DMA_BUSWIDTHS;
> + dw->dma.dst_addr_widths = AXI_DMA_BUSWIDTHS;
> + dw->dma.directions = BIT(DMA_MEM_TO_MEM);
> + dw->dma.residue_granularity =
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> +
> + dw->dma.dev = chip->dev;
> + dw->dma.device_tx_status = dma_chan_tx_status;
> + dw->dma.device_issue_pending = dma_chan_issue_pending;
> + dw->dma.device_terminate_all = dma_chan_terminate_all;
> + dw->dma.device_pause = dma_chan_pause;
> + dw->dma.device_resume = dma_chan_resume;
> +
> + dw->dma.device_alloc_chan_resources =
> dma_chan_alloc_chan_resources;
> + dw->dma.device_free_chan_resources =
> dma_chan_free_chan_resources;
> +
> + dw->dma.device_prep_dma_memcpy = dma_chan_prep_dma_memcpy;
> + dw->dma.device_prep_dma_sg = dma_chan_prep_dma_sg;
> +
> + platform_set_drvdata(pdev, chip);
> +
> + pm_runtime_enable(chip->dev);
> +
> + /*
> + * We can't just call pm_runtime_get here instead of
> + * pm_runtime_get_noresume + axi_dma_runtime_resume because
> we need
> + * driver to work also without Runtime PM.
> + */
> + pm_runtime_get_noresume(chip->dev);
> + ret = axi_dma_runtime_resume(chip->dev);
> + if (ret < 0)
> + goto err_pm_disable;
> +
> + axi_dma_hw_init(chip);
> +
> + pm_runtime_put(chip->dev);
> +
> + ret = dma_async_device_register(&dw->dma);
> + if (ret)
> + goto err_pm_disable;
> +
> + dev_info(chip->dev, "DesignWare AXI DMA Controller, %d
> channels\n",
> + dw->hdata->nr_channels);
> +
> + return 0;
> +
> +err_pm_disable:
> + pm_runtime_disable(chip->dev);
> +
> + return ret;
> +}
> +
> +static int dw_remove(struct platform_device *pdev)
> +{
> + struct axi_dma_chip *chip = platform_get_drvdata(pdev);
> + struct dw_axi_dma *dw = chip->dw;
> + struct axi_dma_chan *chan, *_chan;
> + u32 i;
> +
> + /* Enable clk before accessing to registers */
> + clk_prepare_enable(chip->clk);
> + axi_dma_irq_disable(chip);
> + for (i = 0; i < dw->hdata->nr_channels; i++) {
> + axi_chan_disable(&chip->dw->chan[i]);
> + axi_chan_irq_disable(&chip->dw->chan[i],
> DWAXIDMAC_IRQ_ALL);
> + }
> + axi_dma_disable(chip);
> +
> + pm_runtime_disable(chip->dev);
> + axi_dma_runtime_suspend(chip->dev);
> +
> + devm_free_irq(chip->dev, chip->irq, chip);
> +
> + list_for_each_entry_safe(chan, _chan, &dw->dma.channels,
> + vc.chan.device_node) {
> + list_del(&chan->vc.chan.device_node);
> + tasklet_kill(&chan->vc.task);
> + }
> +
> + dma_async_device_unregister(&dw->dma);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops dw_axi_dma_pm_ops = {
> + SET_RUNTIME_PM_OPS(axi_dma_runtime_suspend,
> axi_dma_runtime_resume, NULL)
> +};
Have you tried to build with CONFIG_PM disabled?
I'm pretty sure you need __maybe_unused applied to your PM ops.
> +struct axi_dma_chan {
> + struct axi_dma_chip *chip;
> + void __iomem *chan_regs;
> + u8 id;
> + atomic_t descs_allocated;
> +
> + struct virt_dma_chan vc;
> +
> + /* these other elements are all protected by vc.lock */
> + bool is_paused;
I still didn't get (already forgot) why you can't use dma_status instead
for the active descriptor?
> +};
> +/* LLI == Linked List Item */
> +struct __attribute__ ((__packed__)) axi_dma_lli {
...
> + __le64 sar;
> + __le64 dar;
> + __le32 block_ts_lo;
> + __le32 block_ts_hi;
> + __le64 llp;
> + __le32 ctl_lo;
> + __le32 ctl_hi;
> + __le32 sstat;
> + __le32 dstat;
> + __le32 status_lo;
> + __le32 ststus_hi;
> + __le32 reserved_lo;
> + __le32 reserved_hi;
> +};
Just __packed here.
> +
> +struct axi_dma_desc {
> + struct axi_dma_lli lli;
> +
> + struct virt_dma_desc vd;
> + struct axi_dma_chan *chan;
> + struct list_head xfer_list;
This looks redundant. Already asked above about it.
> +};
> +
> +/* Common registers offset */
> +#define DMAC_ID 0x000 /* R DMAC ID */
> +#define DMAC_COMPVER 0x008 /* R DMAC Component Version
> */
> +#define DMAC_CFG 0x010 /* R/W DMAC Configuration */
> +#define DMAC_CHEN 0x018 /* R/W DMAC Channel Enable */
> +#define DMAC_CHEN_L 0x018 /* R/W DMAC Channel Enable
> 00-31 */
> +#define DMAC_CHEN_H 0x01C /* R/W DMAC Channel Enable
> 32-63 */
> +#define DMAC_INTSTATUS 0x030 /* R DMAC Interrupt
> Status */
> +#define DMAC_COMMON_INTCLEAR 0x038 /* W DMAC Interrupt Clear
> */
> +#define DMAC_COMMON_INTSTATUS_ENA 0x040 /* R DMAC Interrupt Status
> Enable */
> +#define DMAC_COMMON_INTSIGNAL_ENA 0x048 /* R/W DMAC Interrupt Signal
> Enable */
> +#define DMAC_COMMON_INTSTATUS 0x050 /* R DMAC Interrupt Status
> */
> +#define DMAC_RESET 0x058 /* R DMAC Reset Register1 */
> +
> +/* DMA channel registers offset */
> +#define CH_SAR 0x000 /* R/W Chan Source
> Address */
> +#define CH_DAR 0x008 /* R/W Chan Destination
> Address */
> +#define CH_BLOCK_TS 0x010 /* R/W Chan Block Transfer
> Size */
> +#define CH_CTL 0x018 /* R/W Chan Control */
> +#define CH_CTL_L 0x018 /* R/W Chan Control 00-31 */
> +#define CH_CTL_H 0x01C /* R/W Chan Control 32-63 */
> +#define CH_CFG 0x020 /* R/W Chan Configuration
> */
> +#define CH_CFG_L 0x020 /* R/W Chan Configuration 00-31
> */
> +#define CH_CFG_H 0x024 /* R/W Chan Configuration 32-63
> */
> +#define CH_LLP 0x028 /* R/W Chan Linked List
> Pointer */
> +#define CH_STATUS 0x030 /* R Chan Status */
> +#define CH_SWHSSRC 0x038 /* R/W Chan SW Handshake
> Source */
> +#define CH_SWHSDST 0x040 /* R/W Chan SW Handshake
> Destination */
> +#define CH_BLK_TFR_RESUMEREQ 0x048 /* W Chan Block Transfer
> Resume Req */
> +#define CH_AXI_ID 0x050 /* R/W Chan AXI ID */
> +#define CH_AXI_QOS 0x058 /* R/W Chan AXI QOS */
> +#define CH_SSTAT 0x060 /* R Chan Source Status */
> +#define CH_DSTAT 0x068 /* R Chan Destination Status */
> +#define CH_SSTATAR 0x070 /* R/W Chan Source Status
> Fetch Addr */
> +#define CH_DSTATAR 0x078 /* R/W Chan Destination
> Status Fetch Addr */
> +#define CH_INTSTATUS_ENA 0x080 /* R/W Chan Interrupt Status
> Enable */
> +#define CH_INTSTATUS 0x088 /* R/W Chan Interrupt
> Status */
> +#define CH_INTSIGNAL_ENA 0x090 /* R/W Chan Interrupt Signal
> Enable */
> +#define CH_INTCLEAR 0x098 /* W Chan Interrupt Clear */
I'm wondering if you can use regmap API instead.
> +
> +
Redundant (one) empty line.
> +/* DMAC_CFG */
> +#define DMAC_EN_MASK 0x00000001U
GENMASK()
> +#define DMAC_EN_POS 0
Usually _SHIFT, but it's up to you.
> +
> +#define INT_EN_MASK 0x00000002U
GENMASK()
> +#define INT_EN_POS 1
> +
_SHIFT ?
> +#define CH_CTL_L_DST_MSIZE_POS 18
> +#define CH_CTL_L_SRC_MSIZE_POS 14
Ditto.
> +enum {
> + DWAXIDMAC_BURST_TRANS_LEN_1 = 0x0,
> + DWAXIDMAC_BURST_TRANS_LEN_4,
> + DWAXIDMAC_BURST_TRANS_LEN_8,
> + DWAXIDMAC_BURST_TRANS_LEN_16,
> + DWAXIDMAC_BURST_TRANS_LEN_32,
> + DWAXIDMAC_BURST_TRANS_LEN_64,
> + DWAXIDMAC_BURST_TRANS_LEN_128,
> + DWAXIDMAC_BURST_TRANS_LEN_256,
> + DWAXIDMAC_BURST_TRANS_LEN_512,
> + DWAXIDMAC_BURST_TRANS_LEN_1024
..._1024, ?
> +};
Hmm... do you need them in the header?
> +#define CH_CFG_H_TT_FC_POS 0
> +enum {
> + DWAXIDMAC_TT_FC_MEM_TO_MEM_DMAC = 0x0,
> + DWAXIDMAC_TT_FC_MEM_TO_PER_DMAC,
> + DWAXIDMAC_TT_FC_PER_TO_MEM_DMAC,
> + DWAXIDMAC_TT_FC_PER_TO_PER_DMAC,
> + DWAXIDMAC_TT_FC_PER_TO_MEM_SRC,
> + DWAXIDMAC_TT_FC_PER_TO_PER_SRC,
> + DWAXIDMAC_TT_FC_MEM_TO_PER_DST,
> + DWAXIDMAC_TT_FC_PER_TO_PER_DST
> +};
Some of definitions are the same as for dw_dmac, right? We might split
them to a common header, though I have no strong opinion about it.
Vinod?
> +/**
> + * Dw axi dma channel interrupts
Dw axi dma - > DW AXI DMA?
> + *
> + * @DWAXIDMAC_IRQ_NONE: Bitmask of no one interrupt
> + * @DWAXIDMAC_IRQ_BLOCK_TRF: Block transfer complete
> + * @DWAXIDMAC_IRQ_DMA_TRF: Dma transfer complete
> + * @DWAXIDMAC_IRQ_SRC_TRAN: Source transaction complete
> + * @DWAXIDMAC_IRQ_DST_TRAN: Destination transaction complete
> + * @DWAXIDMAC_IRQ_SRC_DEC_ERR: Source decode error
> + * @DWAXIDMAC_IRQ_DST_DEC_ERR: Destination decode error
> + * @DWAXIDMAC_IRQ_SRC_SLV_ERR: Source slave error
> + * @DWAXIDMAC_IRQ_DST_SLV_ERR: Destination slave error
> + * @DWAXIDMAC_IRQ_LLI_RD_DEC_ERR: LLI read decode error
> + * @DWAXIDMAC_IRQ_LLI_WR_DEC_ERR: LLI write decode error
> + * @DWAXIDMAC_IRQ_LLI_RD_SLV_ERR: LLI read slave error
> + * @DWAXIDMAC_IRQ_LLI_WR_SLV_ERR: LLI write slave error
> + * @DWAXIDMAC_IRQ_INVALID_ERR: LLI invalide error or Shadow register
> error
> + * @DWAXIDMAC_IRQ_MULTIBLKTYPE_ERR: Slave Interface Multiblock type
> error
> + * @DWAXIDMAC_IRQ_DEC_ERR: Slave Interface decode error
> + * @DWAXIDMAC_IRQ_WR2RO_ERR: Slave Interface write to read only error
> + * @DWAXIDMAC_IRQ_RD2RWO_ERR: Slave Interface read to write only
> error
> + * @DWAXIDMAC_IRQ_WRONCHEN_ERR: Slave Interface write to channel
> error
> + * @DWAXIDMAC_IRQ_SHADOWREG_ERR: Slave Interface shadow reg error
> + * @DWAXIDMAC_IRQ_WRONHOLD_ERR: Slave Interface hold error
> + * @DWAXIDMAC_IRQ_LOCK_CLEARED: Lock Cleared Status
> + * @DWAXIDMAC_IRQ_SRC_SUSPENDED: Source Suspended Status
> + * @DWAXIDMAC_IRQ_SUSPENDED: Channel Suspended Status
> + * @DWAXIDMAC_IRQ_DISABLED: Channel Disabled Status
> + * @DWAXIDMAC_IRQ_ABORTED: Channel Aborted Status
> + * @DWAXIDMAC_IRQ_ALL_ERR: Bitmask of all error interrupts
> + * @DWAXIDMAC_IRQ_ALL: Bitmask of all interrupts
> + */
> +enum {
> + DWAXIDMAC_IRQ_NONE = 0x0,
Just 0.
> + DWAXIDMAC_IRQ_BLOCK_TRF = BIT(0),
> + DWAXIDMAC_IRQ_DMA_TRF = BIT(1),
> + DWAXIDMAC_IRQ_SRC_TRAN = BIT(3),
> + DWAXIDMAC_IRQ_DST_TRAN = BIT(4),
> + DWAXIDMAC_IRQ_SRC_DEC_ERR = BIT(5),
> + DWAXIDMAC_IRQ_DST_DEC_ERR = BIT(6),
> + DWAXIDMAC_IRQ_SRC_SLV_ERR = BIT(7),
> + DWAXIDMAC_IRQ_DST_SLV_ERR = BIT(8),
> + DWAXIDMAC_IRQ_LLI_RD_DEC_ERR = BIT(9),
> + DWAXIDMAC_IRQ_LLI_WR_DEC_ERR = BIT(10),
> + DWAXIDMAC_IRQ_LLI_RD_SLV_ERR = BIT(11),
> + DWAXIDMAC_IRQ_LLI_WR_SLV_ERR = BIT(12),
> + DWAXIDMAC_IRQ_INVALID_ERR = BIT(13),
> + DWAXIDMAC_IRQ_MULTIBLKTYPE_ERR = BIT(14),
> + DWAXIDMAC_IRQ_DEC_ERR = BIT(16),
> + DWAXIDMAC_IRQ_WR2RO_ERR = BIT(17),
> + DWAXIDMAC_IRQ_RD2RWO_ERR = BIT(18),
> + DWAXIDMAC_IRQ_WRONCHEN_ERR = BIT(19),
> + DWAXIDMAC_IRQ_SHADOWREG_ERR = BIT(20),
> + DWAXIDMAC_IRQ_WRONHOLD_ERR = BIT(21),
> + DWAXIDMAC_IRQ_LOCK_CLEARED = BIT(27),
> + DWAXIDMAC_IRQ_SRC_SUSPENDED = BIT(28),
> + DWAXIDMAC_IRQ_SUSPENDED = BIT(29),
> + DWAXIDMAC_IRQ_DISABLED = BIT(30),
> + DWAXIDMAC_IRQ_ABORTED = BIT(31),
> + DWAXIDMAC_IRQ_ALL_ERR = 0x003F7FE0,
GENMASK() | GENMASK() ?
> + DWAXIDMAC_IRQ_ALL = 0xFFFFFFFF
GENMASK()
> +};
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: omap4-droid4: Stop disabling SRAM and GPMC
From: Sebastian Reichel @ 2017-04-18 12:17 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA, Benoît Cousson,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott
In-Reply-To: <20170328004612.16350-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
Hi,
On Mon, Mar 27, 2017 at 05:46:12PM -0700, Tony Lindgren wrote:
> I disabled SRAM and GPMC originally when seeing errors with
> omap_barriers_init(). But that is no longer happening probably
> because the memory range is now properly configured to 1021 MB
> instead of 1024 MB. So let's enable SRAM and GPMC so we get
> omap_barriers_init() working and can idle the GPMC.
>
> Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
> Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Tested-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
-- Sebastian
> arch/arm/boot/dts/omap4-droid4-xt894.dts | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> @@ -24,8 +24,7 @@
>
> /*
> * We seem to have only 1021 MB accessible, 1021 - 1022 is locked,
> - * then 1023 - 1024 seems to contain mbm. For SRAM, see the notes
> - * below about SRAM and L3_ICLK2 being unused by default,
> + * then 1023 - 1024 seems to contain mbm.
> */
> memory {
> device_type = "memory";
> @@ -176,11 +175,6 @@
> };
> };
>
> -/* L3_2 interconnect is unused, SRAM, GPMC and L3_ICLK2 disabled */
> -&gpmc {
> - status = "disabled";
> -};
> -
> &hdmi {
> status = "okay";
> pinctrl-0 = <&dss_hdmi_pins>;
> @@ -356,11 +350,6 @@
> };
> };
>
> -/* L3_2 interconnect is unused, SRAM, GPMC and L3_ICLK2 disabled */
> -&ocmcram {
> - status = "disabled";
> -};
> -
> &omap4_pmx_core {
>
> /* hdmi_hpd.gpio_63 */
> --
> 2.12.1
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: reuse firefly dtsi
From: Eddie Cai @ 2017-04-18 12:15 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eddie Cai
firefly reload is very similar with firefly board, so reuse firefly dtsi
Signed-off-by: Eddie Cai <eddie.cai.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 310 ------------------
arch/arm/boot/dts/rk3288-firefly-reload.dts | 368 ++--------------------
2 files changed, 34 insertions(+), 644 deletions(-)
delete mode 100644 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
deleted file mode 100644
index 8134966..0000000
--- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
+++ /dev/null
@@ -1,310 +0,0 @@
-/*
- * Device tree file for Firefly Rockchip RK3288 Core board
- * Copyright (c) 2016 Randy Li <ayaka-xPW3/0Ywev/iB9QmIjCX8w@public.gmane.org>
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
-
-#include <dt-bindings/input/input.h>
-#include "rk3288.dtsi"
-
-/ {
- memory@0 {
- device_type = "memory";
- reg = <0 0x80000000>;
- };
-
- ext_gmac: external-gmac-clock {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <125000000>;
- clock-output-names = "ext_gmac";
- };
-
-
- vcc_flash: flash-regulator {
- compatible = "regulator-fixed";
- regulator-name = "vcc_flash";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_io>;
- };
-};
-
-&cpu0 {
- cpu0-supply = <&vdd_cpu>;
-};
-
-&emmc {
- bus-width = <8>;
- cap-mmc-highspeed;
- disable-wp;
- mmc-ddr-1_8v;
- mmc-hs200-1_8v;
- non-removable;
- num-slots = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_pwr>, <&emmc_bus8>;
- vmmc-supply = <&vcc_io>;
- vqmmc-supply = <&vcc_flash>;
- status = "okay";
-};
-
-&gmac {
- assigned-clocks = <&cru SCLK_MAC>;
- assigned-clock-parents = <&ext_gmac>;
- clock_in_out = "input";
- pinctrl-names = "default";
- pinctrl-0 = <&rgmii_pins>, <&phy_rst>, <&phy_pmeb>, <&phy_int>;
- phy-supply = <&vcc_lan>;
- phy-mode = "rgmii";
- snps,reset-active-low;
- snps,reset-delays-us = <0 10000 1000000>;
- snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
- tx_delay = <0x30>;
- rx_delay = <0x10>;
- status = "ok";
-};
-
-&i2c0 {
- clock-frequency = <400000>;
- status = "okay";
-
- vdd_cpu: syr827@40 {
- compatible = "silergy,syr827";
- fcs,suspend-voltage-selector = <1>;
- reg = <0x40>;
- regulator-name = "vdd_cpu";
- regulator-min-microvolt = <850000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
- regulator-boot-on;
- regulator-enable-ramp-delay = <300>;
- regulator-ramp-delay = <8000>;
- vin-supply = <&vcc_sys>;
- };
-
- vdd_gpu: syr828@41 {
- compatible = "silergy,syr828";
- fcs,suspend-voltage-selector = <1>;
- reg = <0x41>;
- regulator-name = "vdd_gpu";
- regulator-min-microvolt = <850000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
- vin-supply = <&vcc_sys>;
- };
-
- act8846: act8846@5a {
- compatible = "active-semi,act8846";
- reg = <0x5a>;
- pinctrl-names = "default";
- pinctrl-0 = <&pmic_vsel>, <&pwr_hold>;
- system-power-controller;
-
- vp1-supply = <&vcc_sys>;
- vp2-supply = <&vcc_sys>;
- vp3-supply = <&vcc_sys>;
- vp4-supply = <&vcc_sys>;
- inl1-supply = <&vcc_sys>;
- inl2-supply = <&vcc_sys>;
- inl3-supply = <&vcc_20>;
-
- regulators {
- vcc_ddr: REG1 {
- regulator-name = "vcc_ddr";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- };
-
- vcc_io: REG2 {
- regulator-name = "vcc_io";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_log: REG3 {
- regulator-name = "vdd_log";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1100000>;
- regulator-always-on;
- };
-
- vcc_20: REG4 {
- regulator-name = "vcc_20";
- regulator-min-microvolt = <2000000>;
- regulator-max-microvolt = <2000000>;
- regulator-always-on;
- };
-
- vccio_sd: REG5 {
- regulator-name = "vccio_sd";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- vdd10_lcd: REG6 {
- regulator-name = "vdd10_lcd";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- };
-
- vcca_18: REG7 {
- regulator-name = "vcca_18";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
-
- vcca_33: REG8 {
- regulator-name = "vcca_33";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vcc_lan: REG9 {
- regulator-name = "vcca_lan";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- vdd_10: REG10 {
- regulator-name = "vdd_10";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- regulator-always-on;
- };
-
- vccio_wl: vcc_18: REG11 {
- regulator-name = "vcc_18";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- vcc18_lcd: REG12 {
- regulator-name = "vcc18_lcd";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
- };
- };
-};
-
-&io_domains {
- status = "okay";
-
- audio-supply = <&vccio_wl>;
- bb-supply = <&vcc_io>;
- dvp-supply = <&dovdd_1v8>;
- flash0-supply = <&vcc_flash>;
- flash1-supply = <&vcc_lan>;
- gpio30-supply = <&vcc_io>;
- gpio1830-supply = <&vcc_io>;
- lcdc-supply = <&vcc_io>;
- sdcard-supply = <&vccio_sd>;
- wifi-supply = <&vccio_wl>;
-};
-
-&pinctrl {
- pcfg_output_high: pcfg-output-high {
- output-high;
- };
-
- pcfg_output_low: pcfg-output-low {
- output-low;
- };
-
- pcfg_pull_up_drv_12ma: pcfg-pull-up-drv-12ma {
- bias-pull-up;
- drive-strength = <12>;
- };
-
- act8846 {
- pwr_hold: pwr-hold {
- rockchip,pins = <0 1 RK_FUNC_GPIO &pcfg_output_high>;
- };
-
- pmic_vsel: pmic-vsel {
- rockchip,pins = <7 14 RK_FUNC_GPIO &pcfg_output_low>;
- };
- };
-
- gmac {
- phy_int: phy-int {
- rockchip,pins = <0 9 RK_FUNC_GPIO &pcfg_pull_up>;
- };
-
- phy_pmeb: phy-pmeb {
- rockchip,pins = <0 8 RK_FUNC_GPIO &pcfg_pull_up>;
- };
-
- phy_rst: phy-rst {
- rockchip,pins = <4 8 RK_FUNC_GPIO &pcfg_output_high>;
- };
- };
-};
-
-&tsadc {
- rockchip,hw-tshut-mode = <0>;
- rockchip,hw-tshut-polarity = <0>;
- status = "okay";
-};
-
-&vopb {
- status = "okay";
-};
-
-&vopb_mmu {
- status = "okay";
-};
-
-&vopl {
- status = "okay";
-};
-
-&vopl_mmu {
- status = "okay";
-};
-
-&wdt {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index d0b3204a..da8f219 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -1,6 +1,7 @@
/*
* Device tree file for Firefly Rockchip RK3288 Core board
* Copyright (c) 2016 Randy Li <ayaka-xPW3/0Ywev/iB9QmIjCX8w@public.gmane.org>
+ * Copyright (c) 2017 Eddie Cai <eddie.cai.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
*
* This file is dual-licensed: you can use it either under the terms
* of the GPL or the X11 license, at your option. Note that this dual
@@ -42,362 +43,61 @@
*/
/dts-v1/;
-#include "rk3288-firefly-reload-core.dtsi"
+#include "rk3288-firefly.dtsi"
/ {
model = "Firefly-RK3288-reload";
compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
+};
- gpio-keys {
- compatible = "gpio-keys";
-
- power {
- wakeup-source;
- gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
- label = "GPIO Power";
- linux,code = <KEY_POWER>;
- pinctrl-names = "default";
- pinctrl-0 = <&pwr_key>;
- };
- };
-
- ir-receiver {
- compatible = "gpio-ir-receiver";
- gpios = <&gpio7 RK_PA0 GPIO_ACTIVE_LOW>;
- };
-
- leds {
- compatible = "gpio-leds";
-
- power {
- gpios = <&gpio8 RK_PA2 GPIO_ACTIVE_LOW>;
- label = "firefly:blue:power";
- pinctrl-names = "default";
- pinctrl-0 = <&power_led>;
- panic-indicator;
+&act8846 {
+ regulators {
+ /delete-node/ REG7;
+ /delete-node/ REG8;
+ /delete-node/ REG9;
+ vcca_33: REG7 {
+ regulator-name = "vcca_33";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
};
- work {
- gpios = <&gpio8 RK_PA1 GPIO_ACTIVE_LOW>;
- label = "firefly:blue:user";
- linux,default-trigger = "rc-feedback";
- pinctrl-names = "default";
- pinctrl-0 = <&work_led>;
+ vcc_lan: REG8 {
+ regulator-name = "vcc_lan";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
};
- };
-
- sdio_pwrseq: sdio-pwrseq {
- compatible = "mmc-pwrseq-simple";
- clocks = <&hym8563>;
- clock-names = "ext_clock";
- pinctrl-names = "default";
- pinctrl-0 = <&wifi_enable>;
- reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
- };
- sound {
- compatible = "simple-audio-card";
- simple-audio-card,name = "SPDIF";
- simple-audio-card,dai-link@1 { /* S/PDIF - S/PDIF */
- cpu { sound-dai = <&spdif>; };
- codec { sound-dai = <&spdif_out>; };
+ vccio_pmu: REG9 {
+ regulator-name = "vccio_pmu";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
};
};
-
- spdif_out: spdif-out {
- compatible = "linux,spdif-dit";
- #sound-dai-cells = <0>;
- };
-
- vcc_host_5v: usb-host-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&host_vbus_drv>;
- regulator-name = "vcc_host_5v";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-always-on;
- vin-supply = <&vcc_5v>;
- };
-
- vcc_5v: vcc_sys: vsys-regulator {
- compatible = "regulator-fixed";
- regulator-name = "vcc_5v";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- vcc_sd: sdmmc-regulator {
- compatible = "regulator-fixed";
- gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&sdmmc_pwr>;
- regulator-name = "vcc_sd";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- startup-delay-us = <100000>;
- vin-supply = <&vcc_io>;
- };
-
- vcc_otg_5v: usb-otg-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&otg_vbus_drv>;
- regulator-name = "vcc_otg_5v";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-always-on;
- vin-supply = <&vcc_5v>;
- };
-
- dovdd_1v8: dovdd-1v8-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&dvp_pwr>;
- regulator-name = "dovdd_1v8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_io>;
- };
-
- vcc28_dvp: vcc28-dvp-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&dvp_pwr>;
- regulator-name = "vcc28_dvp";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- vin-supply = <&vcc_io>;
- };
-
- af_28: af_28-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&dvp_pwr>;
- regulator-name = "af_28";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- vin-supply = <&vcc_io>;
- };
-
- dvdd_1v2: af_28-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio7 RK_PB4 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&cif_pwr>;
- regulator-name = "dvdd_1v2";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- vin-supply = <&vcc_io>;
- };
-
- vbat_wl: wifi-regulator {
- compatible = "regulator-fixed";
- regulator-name = "vbat_wl";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vcc_io>;
- };
-};
-
-&i2c0 {
- hym8563: hym8563@51 {
- compatible = "haoyu,hym8563";
- reg = <0x51>;
- #clock-cells = <0>;
- clock-frequency = <32768>;
- clock-output-names = "xin32k";
- interrupt-parent = <&gpio7>;
- interrupts = <RK_PA4 IRQ_TYPE_EDGE_FALLING>;
- pinctrl-names = "default";
- pinctrl-0 = <&rtc_int>;
- };
-};
-
-&i2c2 {
- status = "okay";
-
- codec: es8328@10 {
- compatible = "everest,es8328";
- DVDD-supply = <&vcca_33>;
- AVDD-supply = <&vcca_33>;
- PVDD-supply = <&vcca_33>;
- HPVDD-supply = <&vcca_33>;
- clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
- clock-names = "i2s_hclk", "i2s_clk";
- reg = <0x10>;
- };
-};
-
-&i2s {
- status = "okay";
-};
-
-&sdmmc {
- bus-width = <4>;
- cap-mmc-highspeed;
- cap-sd-highspeed;
- card-detect-delay = <200>;
- disable-wp;
- num-slots = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&sdmmc_clk>, <&sdmmc_cmd>, <&sdmmc_cd>, <&sdmmc_bus4>;
- vmmc-supply = <&vcc_sd>;
- vqmmc-supply = <&vccio_sd>;
- status = "okay";
-};
-
-&sdio0 {
- bus-width = <4>;
- cap-sd-highspeed;
- cap-sdio-irq;
- disable-wp;
- mmc-pwrseq = <&sdio_pwrseq>;
- non-removable;
- num-slots = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&sdio0_bus4>, <&sdio0_cmd>, <&sdio0_clk>, <&sdio0_int>;
- sd-uhs-sdr12;
- sd-uhs-sdr25;
- sd-uhs-sdr50;
- sd-uhs-ddr50;
- vmmc-supply = <&vbat_wl>;
- vqmmc-supply = <&vccio_wl>;
- status = "okay";
-};
-
-&spdif {
- status = "okay";
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>;
- status = "okay";
};
-&uart1 {
- status = "okay";
-};
-
-&uart2 {
- status = "okay";
-};
-
-&uart3 {
- status = "okay";
+&emmc {
+ mmc-hs200-1_8v;
};
-&usbphy {
- status = "okay";
-};
-
-&usb_host1 {
- pinctrl-names = "default";
- pinctrl-0 = <&usbhub_rst>;
- status = "okay";
-};
-
-&usb_otg {
- status = "okay";
+&ir {
+ gpios = <&gpio7 RK_PA0 GPIO_ACTIVE_LOW>;
};
&pinctrl {
- ir {
- ir_int: ir-int {
- rockchip,pins = <7 0 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-
- dvp {
- dvp_pwr: dvp-pwr {
- rockchip,pins = <0 11 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- cif_pwr: cif-pwr {
- rockchip,pins = <7 12 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- hym8563 {
- rtc_int: rtc-int {
- rockchip,pins = <7 4 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-
- keys {
- pwr_key: pwr-key {
- rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ act8846 {
+ pmic_vsel: pmic-vsel {
+ rockchip,pins = <7 14 RK_FUNC_GPIO &pcfg_output_low>;
};
};
- leds {
- power_led: power-led {
- rockchip,pins = <8 2 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- work_led: work-led {
- rockchip,pins = <8 1 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- sdmmc {
- /*
- * Default drive strength isn't enough to achieve even
- * high-speed mode on firefly board so bump up to 12ma.
- */
- sdmmc_bus4: sdmmc-bus4 {
- rockchip,pins = <6 16 RK_FUNC_1 &pcfg_pull_up_drv_12ma>,
- <6 17 RK_FUNC_1 &pcfg_pull_up_drv_12ma>,
- <6 18 RK_FUNC_1 &pcfg_pull_up_drv_12ma>,
- <6 19 RK_FUNC_1 &pcfg_pull_up_drv_12ma>;
- };
-
- sdmmc_clk: sdmmc-clk {
- rockchip,pins = <6 20 RK_FUNC_1 &pcfg_pull_none_12ma>;
- };
-
- sdmmc_cmd: sdmmc-cmd {
- rockchip,pins = <6 21 RK_FUNC_1 &pcfg_pull_up_drv_12ma>;
- };
-
- sdmmc_pwr: sdmmc-pwr {
- rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- sdio {
- wifi_enable: wifi-enable {
- rockchip,pins = <4 28 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- usb_host {
- host_vbus_drv: host-vbus-drv {
- rockchip,pins = <0 14 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- usbhub_rst: usbhub-rst {
- rockchip,pins = <8 3 RK_FUNC_GPIO &pcfg_output_high>;
+ ir {
+ ir_int: ir-int {
+ rockchip,pins = <7 0 RK_FUNC_GPIO &pcfg_pull_up>;
};
};
+};
- usb_otg {
- otg_vbus_drv: otg-vbus-drv {
- rockchip,pins = <0 12 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
+&pwm1 {
+ status = "okay";
};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803
From: Chen-Yu Tsai @ 2017-04-18 12:07 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, linux-sunxi
In-Reply-To: <20170417115747.7300-9-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, Apr 17, 2017 at 7:57 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
> controllable via I2C/RSB bus.
>
> Add support for them.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v2:
> - Place AXP803 codes before AXP806/809 ones.
> - Fixed some errors in regulator description.
> - Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.
>
> drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++++++++++++++-----
> include/linux/mfd/axp20x.h | 37 +++++++++
> 2 files changed, 168 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
> index 0b9d4e3e52c7..2ed15e4a7a82 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
[...]
> @@ -492,20 +578,38 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
> {
> u32 reg = 0;
>
> - /* Only AXP806 has poly-phase outputs */
> - if (axp20x->variant != AXP806_ID)
> - return false;
> + /*
> + * Currently in our supported AXP variants, only AXP806 and AXP803
Nit: mention them in ascending order.
Otherwise,
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v3 09/12] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Chen-Yu Tsai @ 2017-04-18 11:58 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Lee Jones, Rob Herring, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, linux-sunxi
In-Reply-To: <6D57E4F4-DD87-400F-A21B-85778434AADC-h8G6r0blFSE@public.gmane.org>
On Tue, Apr 18, 2017 at 6:55 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> 于 2017年4月18日 GMT+08:00 下午6:38:09, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>>On Mon, Apr 17, 2017 at 7:57 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>>> As axp20x-regulator now supports AXP803, add a cell for it.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> ---
>>> Changes in v3:
>>> - Make the new cell one-liner.
>>>
>>> drivers/mfd/axp20x.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>>> index 1dc6235778eb..431b7f118606 100644
>>> --- a/drivers/mfd/axp20x.c
>>> +++ b/drivers/mfd/axp20x.c
>>> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
>>> .name = "axp20x-pek",
>>> .num_resources =
>>ARRAY_SIZE(axp803_pek_resources),
>>> .resources = axp803_pek_resources,
>>> - }
>>> + },
>>> + { .name = "axp20x-regulator" }
>>
>>It's best to have a trailing comma, so we don't have to change the line
>>again when we add more cells, like you just did with the previous line.
>
> Should I also add it in previous mfd patch? (and remove the addition of the comma in this patch)
Since Lee already said he merged it, I suggest you keep it the way it is,
unless he says otherwise. Or your new patches might not apply correctly,
and you waste time doing one more round.
Maintainers don't always push the latest branches, for a number of reasons.
Sometimes it's because the merge window is closed, and you're not supposed
to put anything that's not for the next release into -next. Other times it
might because they are still working through their backlog. Or they may
have just forgotten.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Pavel Machek @ 2017-04-18 11:51 UTC (permalink / raw)
To: Sakari Ailus
Cc: Philipp Zabel, Peter Rosin, Rob Herring, Mark Rutland,
Steve Longerbeam, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170418105540.GH7456-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4139 bytes --]
On Tue 2017-04-18 13:55:40, Sakari Ailus wrote:
> On Tue, Apr 18, 2017 at 12:34:53PM +0200, Pavel Machek wrote:
> > On Tue 2017-04-18 13:08:41, Sakari Ailus wrote:
> > > Hi Philipp,
> > >
> > > On Tue, Apr 18, 2017 at 10:19:04AM +0200, Philipp Zabel wrote:
> > > > On Thu, 2017-04-13 at 17:48 +0200, Philipp Zabel wrote:
> > > > > This adds device tree binding documentation for mmio-based syscon
> > > > > multiplexers controlled by a single bitfield in a syscon register
> > > > > range.
> > > > >
> > > > > Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > > > > ---
> > > > > Documentation/devicetree/bindings/mux/mmio-mux.txt | 56 ++++++++++++++++++++++
> > > > > 1 file changed, 56 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> > > > > new file mode 100644
> > > > > index 0000000000000..11d96f5d98583
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> > > > > @@ -0,0 +1,56 @@
> > > > > +MMIO bitfield-based multiplexer controller bindings
> > > > > +
> > > > > +Define a syscon bitfield to be used to control a multiplexer. The parent
> > > > > +device tree node must be a syscon node to provide register access.
> > > > > +
> > > > > +Required properties:
> > > > > +- compatible : "gpio-mux"
> > > > > +- reg : register base of the register containing the control bitfield
> > > > > +- bit-mask : bitmask of the control bitfield in the control register
> > > > > +- bit-shift : bit offset of the control bitfield in the control register
> > > > > +- #mux-control-cells : <0>
> > > > > +* Standard mux-controller bindings as decribed in mux-controller.txt
> > > > > +
> > > > > +Optional properties:
> > > > > +- idle-state : if present, the state the mux will have when idle. The
> > > > > + special state MUX_IDLE_AS_IS is the default.
> > > > > +
> > > > > +The multiplexer state is defined as the value of the bitfield described
> > > > > +by the reg, bit-mask, and bit-shift properties, accessed through the parent
> > > > > +syscon.
> > > > > +
> > > > > +Example:
> > > > > +
> > > > > + syscon {
> > > > > + compatible = "syscon";
> > > > > +
> > > > > + mux: mux-controller@3 {
> > > > > + compatible = "mmio-mux";
> > > > > + reg = <0x3>;
> > > > > + bit-mask = <0x1>;
> > > > > + bit-shift = <5>;
> > > > > + #mux-control-cells = <0>;
> > > > > + };
> > > > > + };
> > > > > +
> > > > > + video-mux {
> > > > > + compatible = "video-mux";
> > > > > + mux-controls = <&mux>;
> > > > > +
> > > > > + ports {
> > > > > + /* input 0 */
> > > > > + port@0 {
> > > > > + reg = <0>;
> > > > > + };
> > > > > +
> > > > > + /* input 1 */
> > > > > + port@1 {
> > > > > + reg = <1>;
> > > > > + };
> > > > > +
> > > > > + /* output */
> > > > > + port@2 {
> > > > > + reg = <2>;
> > > > > + };
> > > > > + };
> > > > > + };
> > > >
> > > > So Pavel (added to Cc:) suggested to merge these into one node for the
> > > > video mux, as really we are describing a single hardware entity that
> > > > happens to be multiplexing multiple video buses into one:
> > >
> > > Two drivers will be needed in a way or another to disconnect the dependency
> > > between the video switch driver and the MUX implementation. Are there ways
> > > to do that cleanly other than having two devices?
> >
> > Yes.
> >
> > Device tree describes hardware, not the driver structure.
>
> I think you you could view the MUX control as a device, too, and that's
> separate from the actual video switch.
Actually, I believe what matters here is hardware. There's some chip,
somewhere, that does the switching, and the device tree should should
basically describe that switch.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller
From: Greg Kroah-Hartman @ 2017-04-18 11:44 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Rob Herring,
Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker, Philipp Zabel, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <bdeecccf-02d6-226b-8516-1d41e3602a7a-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On Tue, Apr 18, 2017 at 12:59:50PM +0200, Peter Rosin wrote:
> On 2017-04-18 10:51, Greg Kroah-Hartman wrote:
> > On Thu, Apr 13, 2017 at 06:43:07PM +0200, Peter Rosin wrote:
> >> +config MUX_GPIO
> >> + tristate "GPIO-controlled Multiplexer"
> >> + depends on OF && GPIOLIB
> >
> > Why have the gpio and mux core in the same patch?
>
> One is not usable w/o the other. I can split them if you want to?
Then why are they two different config options? Add the core code in
one patch, and then add the gpio controled mutiplexer in a separate
patch.
> >> +static struct class mux_class = {
> >> + .name = "mux",
> >> + .owner = THIS_MODULE,
> >> +};
> >
> > No Documentation/ABI/ update for your sysfs files? Please do so.
>
> Ok I'll look into it. Wasn't even aware that I added any. But there's the
> new class of course...
Hint, you have files, the devices that belong to the class :)
> >> +static int __init mux_init(void)
> >> +{
> >> + return class_register(&mux_class);
> >> +}
> >> +
> >> +static DEFINE_IDA(mux_ida);
> >
> > When your module is unloaded, you forgot to clean this structure up with
> > what was done with it.
>
> I was under the impression that not providing an exit function for modules
> made the module infrastructure prevent unloading (by bumping some reference
> counter). Maybe that is a misconception?
Ah, messy, don't do that. Make it so you can unload your module please,
why wouldn't you want that to happen?
> >> + mux_chip = kzalloc(sizeof(*mux_chip) +
> >> + controllers * sizeof(*mux_chip->mux) +
> >> + sizeof_priv, GFP_KERNEL);
> >> + if (!mux_chip)
> >> + return NULL;
> >
> > You don't return PTR_ERR(-ENOMEM)? Ok, why not? (I'm not arguing for
> > it, just curious...)
>
> There's no particular reason. Do you think I should change it?
What does the caller do with an error? Pass it up to where? Who gets
it? Don't you want the caller to know you are out of memory?
> >> +
> >> + device_initialize(&mux_chip->dev);
> >
> > Why are you not registering the device here as well? Why have this be a
> > two step process?
>
> Because of idle state handling. The drivers are expected to fill in
> the desired idle state(s) after allocating the mux controller(s).
> Then, when registering, the desired idle state is activated (if the
> idle state is not idle-as-is, of course) and as a last step the mux
> is "advertised".
Ok, is that documented in the functions somewhere?
> >> + ret = device_add(&mux_chip->dev);
> >> + if (ret < 0)
> >> + dev_err(&mux_chip->dev,
> >> + "device_add failed in mux_chip_register: %d\n", ret);
> >
> > Did you run checkpatch.pl in strict mode on this new file? Please do so :)
>
> I did, and did it again just to be sure, and I do not get any complaints.
> So, what's wrong?
You list the function name in the printk string, it should complain
that __func__ should be used. Oh well, it's just a perl script, it
doesn't always catch everything.
isn't always correct :)
> >> +EXPORT_SYMBOL_GPL(devm_mux_chip_alloc);
> >
> >
> > Having devm functions that create/destroy other struct devices worries
> > me, do we have other examples of this happening today? Are you sure you
> > got the reference counting all correct?
>
> drivers/iio/industrialio_core.c:devm_iio_device_alloc
>
> Or is the iio case different in some subtle way that I'm missing?
I don't know, hopefully you got it all correct, I haven't audited that
code path in a long time :)
> >> +
> >> +static int devm_mux_chip_match(struct device *dev, void *res, void *data)
> >> +{
> >> + struct mux_chip **r = res;
> >> +
> >> + if (WARN_ON(!r || !*r))
> >
> > How can this happen?
>
> It shouldn't. I copied the pattern from the iio subsystem.
Then it should be removed there too...
> >> +void devm_mux_chip_free(struct device *dev, struct mux_chip *mux_chip)
> >> +{
> >> + WARN_ON(devres_release(dev, devm_mux_chip_release,
> >> + devm_mux_chip_match, mux_chip));
> >
> > What can someone do with these WARN_ON() splats in the kernel log?
>
> Don't know. Again, I copied the pattern from the iio subsystem.
If you don't know what it should be used for, don't copy it!
Cargo-cult coding is horrible, please no.
> >> + /* ...or it's just contended. */
> >> + down_write(&mux->lock);
> >
> > Why use a read/write lock at all? Have you tested this to verify it
> > really is faster and needed?
>
> For one of the HW configuration that drove the development, the same mux
> controller is used to mux both an I2C channel and a couple of ADC lines.
>
> If there is no kind of reader/writer locking going on, there is no way to
> do ADC readings concurrently with an I2C transfer even when the consumers
> want the mux in the same position. With an ordinary mutex controlling the
> mux position, the consumers will unconditionally get serialized, which
> seems like a waste to me. Or maybe I'm missing something?
Why is serializing things a "waste"? Again, a rw semaphore is slower,
takes more logic to get correct, and is very complex at times. If you
are not SURE you need it, and that it matters, don't use it. And if you
do use it, document the heck out of it how you need it and why.
> >> +
> >> + if (mux->cached_state == state) {
> >> + /*
> >> + * Hmmm, someone else changed the mux to my liking.
> >> + * That makes me wonder how long I waited for nothing?
> >> + */
> >> + downgrade_write(&mux->lock);
> >
> > Oh that always scares me... Are you _sure_ this is correct? And
> > needed?
>
> It might not be needed, and it would probably work ok to just fall
> through and call mux_control_set unconditionally. What is it that
> always scares you exactly? Relying on cached state to be correct?
> Downgrading writer locks?
downgrading a writer lock scares me, especially for something as
"simple" as this type of interface. Again, don't use it unless you
_have_ to. Simple is good, start with that always.
> >> + if (mux->idle_state != MUX_IDLE_AS_IS &&
> >> + mux->idle_state != mux->cached_state)
> >> + ret = mux_control_set(mux, mux->idle_state);
> >> +
> >> + up_read(&mux->lock);
> >
> > You require a lock to be held for a "global" function? Without
> > documentation? Or even a sparse marking? That's asking for trouble...
>
> Documentation I can handle, but where should I look to understand how I
> should add sparse markings?
Run sparse on the code and see what it says :)
> The mux needs to be locked somehow. But as I stated in the cover letter
> the rwsem isn't a perfect fit.
>
> I'm using an rwsem to lock a mux, but that isn't really a
> perfect fit. Is there a better locking primitive that I don't
> know about that fits better? I had a mutex at one point, but
> that didn't allow any concurrent accesses at all. At least
> the rwsem allows concurrent access as long as all users
> agree on the mux state, but I suspect that the rwsem will
> degrade to the mutex situation pretty quickly if there is
> any contention.
>
> Also, the lock doesn't add anything if there is only one consumer of
> a mux controller. Maybe there should be some mechanism for shortcutting
> the locking for the (more common?) single-consumer case?
>
> But again, I need the locking for my multi-consumer use case.
Go back to a mutex, and having a function that requires it to be held
is, icky.
> >> +/*
> >> + * Using subsys_initcall instead of module_init here to ensure - for the
> >> + * non-modular case - that the subsystem is initialized when mux consumers
> >> + * and mux controllers start to use it /without/ relying on link order.
> >> + * For the modular case, the ordering is ensured with module dependencies.
> >> + */
> >> +subsys_initcall(mux_init);
> >
> > Even with subsys_initcall you are relying on link order, you do realize
> > that? What about other subsystems that rely on this? :)
>
> Yes, that is true, but if others start relying on this, that's their problem,
> right? :-)
Yes, but no need to document something that isn't true. You are relying
on link order here.
> >> +struct mux_control_ops {
> >> + int (*set)(struct mux_control *mux, int state);
> >> +};
> >> +
> >> +/* These defines match the constants from the dt-bindings. On purpose. */
> >
> > Why on purpose?
>
> I sure wasn't an accident? :-)
>
> Want me to remove it?
At least explain _why_ you are doing this, that would help, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 05/11] drm/sun4i: abstract a engine type
From: Icenowy Zheng @ 2017-04-18 11:05 UTC (permalink / raw)
To: Maxime Ripard
Cc: Rob Herring, Chen-Yu Tsai, David Airlie, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170418085548.4cisone2yfcuizcp@lukather>
于 2017年4月18日 GMT+08:00 下午4:55:48, Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
>Hi,
>
>Thanks for that rework.
>
>On Sun, Apr 16, 2017 at 08:08:43PM +0800, Icenowy Zheng wrote:
>> As we are going to add support for the Allwinner DE2 engine in
>sun4i-drm
>> driver, we will finally have two types of display engines -- the DE1
>> backend and the DE2 mixer. They both do some display blending and
>feed
>> graphics data to TCON, so I choose to call them both "engine" here.
>>
>> Abstract the engine type to void * and a ops struct, which contains
>> functions that should be called outside the engine-specified code (in
>> TCON, CRTC or TV Encoder code).
>>
>> A dedicated Kconfig option is also added to control whether
>> sun4i-backend-specified code (sun4i_backend.c and sun4i_layer.c)
>should
>> be built. As we removed the codes in CRTC code that directly call the
>> layer code, we can now extract the layer part and combine it with the
>> backend part into a new module, sun4i-backend.ko.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> Changes in v4:
>> - Comments to tag the color correction functions as optional.
>> - Check before calling the optional functions.
>> - Change layers_init to satisfy new PATCH v4 04/11.
>>
>> drivers/gpu/drm/sun4i/Kconfig | 10 ++++++++++
>> drivers/gpu/drm/sun4i/Makefile | 6 ++++--
>> drivers/gpu/drm/sun4i/sun4i_backend.c | 26
>+++++++++++++++++++-------
>> drivers/gpu/drm/sun4i/sun4i_backend.h | 5 -----
>> drivers/gpu/drm/sun4i/sun4i_crtc.c | 14 +++++++-------
>> drivers/gpu/drm/sun4i/sun4i_crtc.h | 7 ++++---
>> drivers/gpu/drm/sun4i/sun4i_drv.h | 3 ++-
>> drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +-
>> drivers/gpu/drm/sun4i/sun4i_layer.h | 3 ++-
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
>> drivers/gpu/drm/sun4i/sun4i_tv.c | 11 ++++++-----
>> drivers/gpu/drm/sun4i/sunxi_engine.h | 35
>+++++++++++++++++++++++++++++++++++
>> 12 files changed, 91 insertions(+), 33 deletions(-)
>> create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
>>
>> diff --git a/drivers/gpu/drm/sun4i/Kconfig
>b/drivers/gpu/drm/sun4i/Kconfig
>> index a4b357db8856..5a8227f37cc4 100644
>> --- a/drivers/gpu/drm/sun4i/Kconfig
>> +++ b/drivers/gpu/drm/sun4i/Kconfig
>> @@ -12,3 +12,13 @@ config DRM_SUN4I
>> Choose this option if you have an Allwinner SoC with a
>> Display Engine. If M is selected the module will be called
>> sun4i-drm.
>> +
>> +config DRM_SUN4I_BACKEND
>> + tristate "Support for Allwinner A10 Display Engine Backend"
>> + depends on DRM_SUN4I
>> + default DRM_SUN4I
>> + help
>> + Choose this option if you have an Allwinner SoC with the
>> + original Allwinner Display Engine, which has a backend to
>> + do some alpha blending and feed graphics to TCON. If M is
>> + selected the module will be called sun4i-backend.
>> diff --git a/drivers/gpu/drm/sun4i/Makefile
>b/drivers/gpu/drm/sun4i/Makefile
>> index 59b757350a1f..1db1068b9be1 100644
>> --- a/drivers/gpu/drm/sun4i/Makefile
>> +++ b/drivers/gpu/drm/sun4i/Makefile
>> @@ -5,9 +5,11 @@ sun4i-tcon-y += sun4i_tcon.o
>> sun4i-tcon-y += sun4i_rgb.o
>> sun4i-tcon-y += sun4i_dotclock.o
>> sun4i-tcon-y += sun4i_crtc.o
>> -sun4i-tcon-y += sun4i_layer.o
>> +
>> +sun4i-backend-y += sun4i_layer.o
>> +sun4i-backend-y += sun4i_backend.o
>>
>> obj-$(CONFIG_DRM_SUN4I) += sun4i-drm.o sun4i-tcon.o
>> -obj-$(CONFIG_DRM_SUN4I) += sun4i_backend.o
>> +obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o
>> obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
>> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
>b/drivers/gpu/drm/sun4i/sun4i_backend.c
>> index d660741ba475..a16c96a002a4 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
>> @@ -23,6 +23,8 @@
>>
>> #include "sun4i_backend.h"
>> #include "sun4i_drv.h"
>> +#include "sun4i_layer.h"
>> +#include "sunxi_engine.h"
>>
>> static const u32 sunxi_rgb2yuv_coef[12] = {
>> 0x00000107, 0x00000204, 0x00000064, 0x00000108,
>> @@ -30,9 +32,10 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
>> 0x000001c1, 0x00003e88, 0x00003fb8, 0x00000808
>> };
>>
>> -void sun4i_backend_apply_color_correction(struct sun4i_backend
>*backend)
>> +static void sun4i_backend_apply_color_correction(void *engine)
>> {
>> int i;
>> + struct sun4i_backend *backend = engine;
>
>I'm not really fond of passing an opaque pointer here, and hope that
>things will work out.
>
>I think having a common structure, holding the common thingsand a more
>specific structure for that one would work better.
>
>Something like
>
>struct sunxi_engine {
> struct regmap *regs;
>};
>
>struct sun4i_backend {
> struct sunxi_engine engine;
>
> struct clk *sat_clk;
> struct reset_control *sat_reset;
>
>};
Sounds good ;-)
>
>static void sun4i_backend_apply_color_correction(struct sunxi_engine
>*engine)
>struct sun4i_backend *backend = container_of(engine, struct
>sun4i_backend, engine);
>
>...
>
>> +static const struct sunxi_engine_ops sun4i_backend_engine_ops = {
>> + .commit = sun4i_backend_commit,
>> + .layers_init = sun4i_layers_init,
>> + .apply_color_correction = sun4i_backend_apply_color_correction,
>> + .disable_color_correction = sun4i_backend_disable_color_correction,
>
>Please align the values with tabs, like done in the other structures
>created that way in this driver.
>
>> static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
>> @@ -56,7 +55,7 @@ static void sun4i_crtc_atomic_flush(struct drm_crtc
>*crtc,
>>
>> DRM_DEBUG_DRIVER("Committing plane changes\n");
>>
>> - sun4i_backend_commit(scrtc->backend);
>> + scrtc->engine_ops->commit(scrtc->engine);
>
>You rely on the backend having setup things properly, which is pretty
>fragile. Ideally, you should have a function to check that engine_ops
>and commit is !NULL, and call it, and the consumers would use that
>function...
If it's really NULL how should the function return?
>
>> @@ -362,7 +361,9 @@ static void sun4i_tv_disable(struct drm_encoder
>*encoder)
>> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
>> SUN4I_TVE_EN_ENABLE,
>> 0);
>> - sun4i_backend_disable_color_correction(backend);
>> +
>> + if (crtc->engine_ops->disable_color_correction)
>> + crtc->engine_ops->disable_color_correction(crtc->engine);
>> }
>
>... Instead of having to do it in some cases, but not always ...
>
>> static void sun4i_tv_enable(struct drm_encoder *encoder)
>> @@ -370,11 +371,11 @@ static void sun4i_tv_enable(struct drm_encoder
>*encoder)
>> struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
>> struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
>> struct sun4i_tcon *tcon = crtc->tcon;
>> - struct sun4i_backend *backend = crtc->backend;
>>
>> DRM_DEBUG_DRIVER("Enabling the TV Output\n");
>>
>> - sun4i_backend_apply_color_correction(backend);
>> + if (crtc->engine_ops->apply_color_correction)
>> + crtc->engine_ops->apply_color_correction(crtc->engine);
>>
>> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
>> SUN4I_TVE_EN_ENABLE,
>> diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h
>b/drivers/gpu/drm/sun4i/sunxi_engine.h
>> new file mode 100644
>> index 000000000000..a9128abda66f
>> --- /dev/null
>> +++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
>> @@ -0,0 +1,35 @@
>> +/*
>> + * Copyright (C) 2017 Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + */
>> +
>> +#ifndef _SUNXI_ENGINE_H_
>> +#define _SUNXI_ENGINE_H_
>> +
>> +struct sun4i_crtc;
>> +
>> +struct sunxi_engine_ops {
>> + /* Commit the changes to the engine */
>> + void (*commit)(void *engine);
>> + /* Initialize layers (planes) for this engine */
>> + struct drm_plane **(*layers_init)(struct drm_device *drm,
>> + struct sun4i_crtc *crtc);
>> +
>> + /*
>> + * These are optional functions for the TV Encoder. Please check
>> + * their presence before calling them.
>> + *
>> + * The first function applies the color space correction needed
>> + * for outputing correct TV signal.
>> + *
>> + * The second function disabled the correction.
>> + */
>> + void (*apply_color_correction)(void *engine);
>> + void (*disable_color_correction)(void *engine);
>
>... And have to document it.
>
>Please also use kerneldoc for those comments.
>
>Thanks again!
>Maxime
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ 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