* [PATCH 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: sean.wang @ 2017-04-13 7:05 UTC (permalink / raw)
To: herbert, mpm, robh+dt, mark.rutland, clabbe.montjoie,
prasannatsmkumar, romain.perier, shannon.nelson
Cc: weiyongjun1, devicetree, linux-crypto, linux-mediatek,
linux-arm-kernel, linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1492067108-14748-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Document the devicetree bindings for Mediatek random number
generator which could be found on MT7623 SoC or other similar
Mediatek SoCs.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt
new file mode 100644
index 0000000..a6d62a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for Mediatek random number generator
+found in Mediatek SoC family
+
+Required properties:
+- compatible : Should be "mediatek,mt7623-rng"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : Should contain "rng" entries;
+- reg : Specifies base physical address and size of the registers
+
+Example:
+
+rng: rng@1020f000 {
+ compatible = "mediatek,mt7623-rng";
+ reg = <0 0x1020f000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_TRNG>;
+ clock-names = "rng";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: sean.wang @ 2017-04-13 7:05 UTC (permalink / raw)
To: herbert, mpm, robh+dt, mark.rutland, clabbe.montjoie,
prasannatsmkumar, romain.perier, shannon.nelson
Cc: weiyongjun1, devicetree, linux-crypto, linux-mediatek,
linux-arm-kernel, linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1492067108-14748-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds support for hardware random generator on MT7623 SoC
and should also work on other similar Mediatek SoCs. Currently,
the driver is already tested successfully with rng-tools.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/char/hw_random/Kconfig | 16 +++-
drivers/char/hw_random/Makefile | 2 +-
drivers/char/hw_random/mtk-rng.c | 174 +++++++++++++++++++++++++++++++++++++++
3 files changed, 190 insertions(+), 2 deletions(-)
create mode 100644 drivers/char/hw_random/mtk-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 0cafe08..af782ce 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
Generator hardware found on Cavium SoCs.
To compile this driver as a module, choose M here: the
- module will be called cavium_rng.
+ module will be called mtk-rng.
If unsure, say Y.
+config HW_RANDOM_MTK
+ tristate "Mediatek Random Number Generator support"
+ depends on HW_RANDOM
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ default y
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here. the
+ module will be called mtk-rng.
+
+ If unsure, say Y.
+
endif # HW_RANDOM
config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 5f52b1e..68be716 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -1,7 +1,6 @@
#
# Makefile for HW Random Number Generator (RNG) device drivers.
#
-
obj-$(CONFIG_HW_RANDOM) += rng-core.o
rng-core-y := core.o
obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
@@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
+obj-$(CONFIG_HW_RANDOM_MTK) += mtk-rng.o
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
new file mode 100644
index 0000000..6561ee0
--- /dev/null
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -0,0 +1,174 @@
+/*
+ * Driver for Mediatek Hardware Random Number Generator
+ *
+ * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ *
+ * 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.
+ *
+ * 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.
+ */
+#define MTK_RNG_DEV KBUILD_MODNAME
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define USEC_POLL 2
+#define TIMEOUT_POLL 20
+
+#define RNG_CTRL 0x00
+#define RNG_EN BIT(0)
+#define RNG_READY BIT(31)
+
+#define RNG_DATA 0x08
+
+#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
+
+struct mtk_rng {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *clk;
+ struct hwrng rng;
+};
+
+static int mtk_rng_init(struct hwrng *rng)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ u32 val;
+ int err;
+
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ return err;
+
+ val = readl(priv->base + RNG_CTRL);
+ val |= RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ return 0;
+}
+
+static void mtk_rng_cleanup(struct hwrng *rng)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ u32 val;
+
+ val = readl(priv->base + RNG_CTRL);
+ val &= ~RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ clk_disable_unprepare(priv->clk);
+}
+
+static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ int ready;
+
+ ready = readl(priv->base + RNG_CTRL) & RNG_READY;
+ if (!ready && wait)
+ readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
+ ready & RNG_READY, USEC_POLL,
+ TIMEOUT_POLL);
+ return !!ready;
+}
+
+static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ int retval = 0;
+
+ while (max >= sizeof(u32)) {
+ if (!mtk_rng_wait_ready(rng, wait))
+ break;
+
+ *(u32 *)buf = readl(priv->base + RNG_DATA);
+ retval += sizeof(u32);
+ buf += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ if (unlikely(wait && max))
+ dev_warn(priv->dev, "timeout might be not properly set\n");
+
+ return retval || !wait ? retval : -EIO;
+}
+
+static int mtk_rng_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret;
+ struct mtk_rng *priv;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "no iomem resource\n");
+ return -ENXIO;
+ }
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = &pdev->dev;
+ priv->rng.name = pdev->name;
+ priv->rng.init = mtk_rng_init;
+ priv->rng.cleanup = mtk_rng_cleanup;
+ priv->rng.read = mtk_rng_read;
+
+ priv->clk = devm_clk_get(&pdev->dev, "rng");
+ if (IS_ERR(priv->clk)) {
+ ret = PTR_ERR(priv->clk);
+ dev_err(&pdev->dev, "no clock for device: %d\n", ret);
+ return ret;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ ret = devm_hwrng_register(&pdev->dev, &priv->rng);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register rng device: %d\n",
+ ret);
+ return ret;
+ }
+
+ dev_info(&pdev->dev, "registered RNG driver\n");
+
+ return 0;
+}
+
+static const struct of_device_id mtk_rng_match[] = {
+ { .compatible = "mediatek,mt7623-rng" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mtk_rng_match);
+
+static struct platform_driver mtk_rng_driver = {
+ .probe = mtk_rng_probe,
+ .driver = {
+ .name = MTK_RNG_DEV,
+ .of_match_table = mtk_rng_match,
+ },
+};
+
+module_platform_driver(mtk_rng_driver);
+
+MODULE_DESCRIPTION("Mediatek Random Number Generator Driver");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Daniel Kurtz (2):
arm64: dts: mt8173: Fix mdp device tree
media: mtk-mdp: Fix mdp device tree
Minghsiu Tsai (1):
dt-bindings: mt8173: Fix mdp device tree
.../devicetree/bindings/media/mediatek-mdp.txt | 12 +-
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 ++++++++++-----------
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
3 files changed, 64 insertions(+), 76 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei
Cc: devicetree, Minghsiu Tsai, srv_heupstream, Wu-Cheng Li,
linux-kernel, linux-mediatek, Yingjoe Chen, Eddie Huang,
linux-arm-kernel, linux-media
In-Reply-To: <1492068787-17838-1-git-send-email-minghsiu.tsai@mediatek.com>
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index 4182063..0d03e3a 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -2,7 +2,7 @@
Media Data Path is used for scaling and color space conversion.
-Required properties (controller (parent) node):
+Required properties (controller node):
- compatible: "mediatek,mt8173-mdp"
- mediatek,vpu: the node of video processor unit, see
Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
@@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
for details.
Example:
-mdp {
- compatible = "mediatek,mt8173-mdp";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- mediatek,vpu = <&vpu>;
-
mdp_rdma0: rdma@14001000 {
compatible = "mediatek,mt8173-mdp-rdma";
+ "mediatek,mt8173-mdp";
reg = <0 0x14001000 0 0x1000>;
clocks = <&mmsys CLK_MM_MDP_RDMA0>,
<&mmsys CLK_MM_MUTEX_32K>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_RDMA0>;
mediatek,larb = <&larb0>;
+ mediatek,vpu = <&vpu>;
};
mdp_rdma1: rdma@14002000 {
@@ -106,4 +101,3 @@ mdp {
iommus = <&iommu M4U_PORT_MDP_WROT1>;
mediatek,larb = <&larb4>;
};
-};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: mt8173: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek, Minghsiu Tsai
In-Reply-To: <1492068787-17838-1-git-send-email-minghsiu.tsai@mediatek.com>
From: Daniel Kurtz <djkurtz@chromium.org>
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 +++++++++++++++----------------
1 file changed, 60 insertions(+), 66 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 6922252..d28a363 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -792,80 +792,74 @@
#clock-cells = <1>;
};
- mdp {
- compatible = "mediatek,mt8173-mdp";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
+ mdp_rdma0: rdma@14001000 {
+ compatible = "mediatek,mt8173-mdp-rdma",
+ "mediatek,mt8173-mdp";
+ reg = <0 0x14001000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA0>;
+ mediatek,larb = <&larb0>;
mediatek,vpu = <&vpu>;
+ };
- mdp_rdma0: rdma@14001000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- reg = <0 0x14001000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA0>,
- <&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA0>;
- mediatek,larb = <&larb0>;
- };
-
- mdp_rdma1: rdma@14002000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- reg = <0 0x14002000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA1>,
- <&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA1>;
- mediatek,larb = <&larb4>;
- };
+ mdp_rdma1: rdma@14002000 {
+ compatible = "mediatek,mt8173-mdp-rdma";
+ reg = <0 0x14002000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA1>,
+ <&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA1>;
+ mediatek,larb = <&larb4>;
+ };
- mdp_rsz0: rsz@14003000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14003000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ0>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz0: rsz@14003000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14003000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_rsz1: rsz@14004000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14004000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ1>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz1: rsz@14004000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14004000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_rsz2: rsz@14005000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14005000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ2>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz2: rsz@14005000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14005000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ2>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_wdma0: wdma@14006000 {
- compatible = "mediatek,mt8173-mdp-wdma";
- reg = <0 0x14006000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WDMA>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WDMA>;
- mediatek,larb = <&larb0>;
- };
+ mdp_wdma0: wdma@14006000 {
+ compatible = "mediatek,mt8173-mdp-wdma";
+ reg = <0 0x14006000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WDMA>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WDMA>;
+ mediatek,larb = <&larb0>;
+ };
- mdp_wrot0: wrot@14007000 {
- compatible = "mediatek,mt8173-mdp-wrot";
- reg = <0 0x14007000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WROT0>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WROT0>;
- mediatek,larb = <&larb0>;
- };
+ mdp_wrot0: wrot@14007000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14007000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT0>;
+ mediatek,larb = <&larb0>;
+ };
- mdp_wrot1: wrot@14008000 {
- compatible = "mediatek,mt8173-mdp-wrot";
- reg = <0 0x14008000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WROT1>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WROT1>;
- mediatek,larb = <&larb4>;
- };
+ mdp_wrot1: wrot@14008000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14008000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT1>;
+ mediatek,larb = <&larb4>;
};
ovl0: ovl@1400c000 {
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] media: mtk-mdp: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak, Houlong Wei
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Eddie Huang, Yingjoe Chen,
Wu-Cheng Li, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Minghsiu Tsai
In-Reply-To: <1492068787-17838-1-git-send-email-minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..a5ad586 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(&mdp->vpulock);
/* Iterate over sibling MDP function blocks */
- for_each_child_of_node(dev->of_node, node) {
+ for_each_child_of_node(dev->of_node->parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;
--
1.9.1
--
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 v5 3/4] net: dsa: LAN9303: add I2C managed mode support
From: Juergen Borleis @ 2017-04-13 7:33 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
In-Reply-To: <20170413073343.8067-1-jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: mark.rutland-5wv7dgnIgG8@public.gmane.org
---
.../devicetree/bindings/net/dsa/lan9303.txt | 62 ++++++++++++
drivers/net/dsa/Kconfig | 17 ++++
drivers/net/dsa/Makefile | 6 ++
drivers/net/dsa/lan9303_i2c.c | 109 +++++++++++++++++++++
4 files changed, 194 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dsa/lan9303.txt
create mode 100644 drivers/net/dsa/lan9303_i2c.c
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
new file mode 100644
index 0000000000000..2edc2561467a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
@@ -0,0 +1,62 @@
+SMSC/MicroChip LAN9303 three port ethernet switch
+-------------------------------------------------
+
+Required properties:
+
+- compatible: should be "smsc,lan9303-i2c"
+
+Optional properties:
+
+- reset-gpios: GPIO to be used to reset the whole device
+- reset-duration: reset duration in milliseconds, defaults to 200 ms
+
+Subnodes:
+
+The integrated switch subnode should be specified according to the binding
+described in dsa/dsa.txt. The CPU port of this switch is always port 0.
+
+Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
+configured to use 1/2/3 instead. This hardware configuration will be
+auto-detected and mapped accordingly.
+
+Example:
+
+I2C managed mode:
+
+ master: masterdevice@X {
+ status = "okay";
+
+ fixed-link { /* RMII fixed link to LAN9303 */
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ switch: switch@a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ status = "okay";
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <200>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 { /* RMII fixed link to master */
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1;
+ };
+
+ port@2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 31a2b229106dd..83887c68ef7a3 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -50,4 +50,21 @@ config NET_DSA_MT7530
This enables support for the Mediatek MT7530 Ethernet switch
chip.
+menuconfig NET_DSA_SMSC_LAN9303
+ tristate "SMSC/Microchip LAN9303 3-ports 10/100 ethernet switch"
+ depends on NET_DSA
+ select NET_DSA_TAG_LAN9303
+ ---help---
+ This enables support for the SMSC/Microchip LAN9303 3 port ethernet
+ switch chips.
+
+config NET_DSA_SMSC_LAN9303_I2C
+ bool "I2C managed mode"
+ depends on NET_DSA_SMSC_LAN9303
+ depends on I2C && OF
+ select REGMAP_I2C
+ ---help---
+ Enable access functions if the SMSC/Microchip LAN9303 is configured
+ for I2C managed mode.
+
endmenu
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 2ae07f4fbf635..e626aeba8525e 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -1,8 +1,14 @@
+lan9303-objs-y := lan9303-core.o
+lan9303-objs-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
+
obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_BCM_SF2) += bcm-sf2.o
bcm-sf2-objs := bcm_sf2.o bcm_sf2_cfp.o
obj-$(CONFIG_NET_DSA_QCA8K) += qca8k.o
obj-$(CONFIG_NET_DSA_MT7530) += mt7530.o
+obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303.o
+lan9303-objs := $(lan9303-objs-y)
+
obj-y += b53/
obj-y += mv88e6xxx/
obj-$(CONFIG_NET_DSA_LOOP) += dsa_loop.o dsa_loop_bdinfo.o
diff --git a/drivers/net/dsa/lan9303_i2c.c b/drivers/net/dsa/lan9303_i2c.c
new file mode 100644
index 0000000000000..23d942440e4b2
--- /dev/null
+++ b/drivers/net/dsa/lan9303_i2c.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright (C) 2017 Pengutronix, Juergen Borleis <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@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
+ * 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/kernel.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+
+#include "lan9303.h"
+
+struct lan9303_i2c {
+ struct i2c_client *device;
+ struct lan9303 chip;
+};
+
+static const struct regmap_config lan9303_i2c_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 1,
+ .can_multi_write = true,
+ .max_register = 0x0ff, /* address bits 0..1 are not used */
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+
+ .volatile_table = &lan9303_register_set,
+ .wr_table = &lan9303_register_set,
+ .rd_table = &lan9303_register_set,
+
+ .cache_type = REGCACHE_NONE,
+};
+
+static int lan9303_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct lan9303_i2c *sw_dev;
+ int ret;
+
+ sw_dev = devm_kzalloc(&client->dev, sizeof(struct lan9303_i2c),
+ GFP_KERNEL);
+ if (!sw_dev)
+ return -ENOMEM;
+
+ sw_dev->chip.regmap = devm_regmap_init_i2c(client,
+ &lan9303_i2c_regmap_config);
+ if (IS_ERR(sw_dev->chip.regmap)) {
+ ret = PTR_ERR(sw_dev->chip.regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ /* link forward and backward */
+ sw_dev->device = client;
+ i2c_set_clientdata(client, sw_dev);
+ sw_dev->chip.dev = &client->dev;
+
+ ret = lan9303_probe(&sw_dev->chip, client->dev.of_node);
+ if (ret != 0)
+ return ret;
+
+ dev_info(&client->dev, "LAN9303 I2C driver loaded successfully\n");
+
+ return 0;
+}
+
+static int lan9303_i2c_remove(struct i2c_client *client)
+{
+ struct lan9303_i2c *sw_dev;
+
+ sw_dev = i2c_get_clientdata(client);
+ if (!sw_dev)
+ return -ENODEV;
+
+ return lan9303_remove(&sw_dev->chip);
+}
+
+/*-------------------------------------------------------------------------*/
+
+static const struct i2c_device_id lan9303_i2c_id[] = {
+ { "lan9303", 0 },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, lan9303_i2c_id);
+
+static const struct of_device_id lan9303_i2c_of_match[] = {
+ { .compatible = "smsc,lan9303-i2c", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, lan9303_i2c_of_match);
+
+static struct i2c_driver lan9303_i2c_driver = {
+ .driver = {
+ .name = "LAN9303_I2C",
+ .of_match_table = of_match_ptr(lan9303_i2c_of_match),
+ },
+ .probe = lan9303_i2c_probe,
+ .remove = lan9303_i2c_remove,
+ .id_table = lan9303_i2c_id,
+};
+module_i2c_driver(lan9303_i2c_driver);
--
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
* [PATCH v5 4/4] net: dsa: LAN9303: add MDIO managed mode support
From: Juergen Borleis @ 2017-04-13 7:33 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
In-Reply-To: <20170413073343.8067-1-jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
When the LAN9303 device is in MDIO manged mode, all register accesses must
be done via MDIO.
Please note: this code is compile time tested only due to the absence of such
configured hardware. It is based on a patch from Stefan Roese from 2014.
Signed-off-by: Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: mark.rutland-5wv7dgnIgG8@public.gmane.org
---
.../devicetree/bindings/net/dsa/lan9303.txt | 45 ++++++-
drivers/net/dsa/Kconfig | 8 ++
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/lan9303_mdio.c | 144 +++++++++++++++++++++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/dsa/lan9303_mdio.c
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
index 2edc2561467a7..04f2965a44676 100644
--- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt
+++ b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
@@ -3,7 +3,10 @@ SMSC/MicroChip LAN9303 three port ethernet switch
Required properties:
-- compatible: should be "smsc,lan9303-i2c"
+- compatible: should be
+ - "smsc,lan9303-i2c" for I2C managed mode
+ or
+ - "smsc,lan9303-mdio" for mdio managed mode
Optional properties:
@@ -60,3 +63,43 @@ I2C managed mode:
};
};
};
+
+MDIO managed mode:
+
+ master: masterdevice@X {
+ status = "okay";
+ phy-handle = <&switch>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch: switch-phy@0 {
+ compatible = "smsc,lan9303-mdio";
+ reg = <0>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <100>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1;
+ };
+
+ port@2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
+ };
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 83887c68ef7a3..e52b298853474 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -67,4 +67,12 @@ config NET_DSA_SMSC_LAN9303_I2C
Enable access functions if the SMSC/Microchip LAN9303 is configured
for I2C managed mode.
+config NET_DSA_SMSC_LAN9303_MDIO
+ bool "MDIO managed mode"
+ depends on NET_DSA_SMSC_LAN9303
+ depends on OF_MDIO
+ ---help---
+ Enable access functions if the SMSC/Microchip LAN9303 is configured
+ for MDIO managed mode.
+
endmenu
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index e626aeba8525e..e782d9648bc8c 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -1,5 +1,6 @@
lan9303-objs-y := lan9303-core.o
lan9303-objs-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
+lan9303-objs-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_BCM_SF2) += bcm-sf2.o
diff --git a/drivers/net/dsa/lan9303_mdio.c b/drivers/net/dsa/lan9303_mdio.c
new file mode 100644
index 0000000000000..87c5cfa946a92
--- /dev/null
+++ b/drivers/net/dsa/lan9303_mdio.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2017 Pengutronix, Juergen Borleis <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
+ *
+ * Partially based on a patch from
+ * Copyright (c) 2014 Stefan Roese <sr-ynQEQJNshbs@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
+ * 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/kernel.h>
+#include <linux/module.h>
+#include <linux/mdio.h>
+#include <linux/phy.h>
+#include <linux/of.h>
+
+#include "lan9303.h"
+
+/* Generate phy-addr and -reg from the input address */
+#define PHY_ADDR(x) ((((x) >> 6) + 0x10) & 0x1f)
+#define PHY_REG(x) (((x) >> 1) & 0x1f)
+
+struct lan9303_mdio {
+ struct mdio_device *device;
+ struct lan9303 chip;
+};
+
+static void lan9303_mdio_real_write(struct mdio_device *mdio, int reg, u16 val)
+{
+ mdio->bus->write(mdio->bus, PHY_ADDR(reg), PHY_REG(reg), val);
+}
+
+static int lan9303_mdio_write(void *ctx, uint32_t reg, uint32_t val)
+{
+ struct lan9303_mdio *sw_dev = (struct lan9303_mdio *)ctx;
+
+ mutex_lock(&sw_dev->device->bus->mdio_lock);
+ lan9303_mdio_real_write(sw_dev->device, reg, val & 0xffff);
+ lan9303_mdio_real_write(sw_dev->device, reg + 2, (val >> 16) & 0xffff);
+ mutex_unlock(&sw_dev->device->bus->mdio_lock);
+
+ return 0;
+}
+
+static u16 lan9303_mdio_real_read(struct mdio_device *mdio, int reg)
+{
+ return mdio->bus->read(mdio->bus, PHY_ADDR(reg), PHY_REG(reg));
+}
+
+static int lan9303_mdio_read(void *ctx, uint32_t reg, uint32_t *val)
+{
+ struct lan9303_mdio *sw_dev = (struct lan9303_mdio *)ctx;
+
+ mutex_lock(&sw_dev->device->bus->mdio_lock);
+ *val = lan9303_mdio_real_read(sw_dev->device, reg);
+ *val |= (lan9303_mdio_real_read(sw_dev->device, reg + 2) << 16);
+ mutex_unlock(&sw_dev->device->bus->mdio_lock);
+
+ return 0;
+}
+
+static const struct regmap_config lan9303_mdio_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 1,
+ .can_multi_write = true,
+ .max_register = 0x0ff, /* address bits 0..1 are not used */
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+
+ .volatile_table = &lan9303_register_set,
+ .wr_table = &lan9303_register_set,
+ .rd_table = &lan9303_register_set,
+
+ .reg_read = lan9303_mdio_read,
+ .reg_write = lan9303_mdio_write,
+
+ .cache_type = REGCACHE_NONE,
+};
+
+static int lan9303_mdio_probe(struct mdio_device *mdiodev)
+{
+ struct lan9303_mdio *sw_dev;
+ int ret;
+
+ sw_dev = devm_kzalloc(&mdiodev->dev, sizeof(struct lan9303_mdio),
+ GFP_KERNEL);
+ if (!sw_dev)
+ return -ENOMEM;
+
+ sw_dev->chip.regmap = devm_regmap_init(&mdiodev->dev, NULL, sw_dev,
+ &lan9303_mdio_regmap_config);
+ if (IS_ERR(sw_dev->chip.regmap)) {
+ ret = PTR_ERR(sw_dev->chip.regmap);
+ dev_err(&mdiodev->dev, "regmap init failed: %d\n", ret);
+ return ret;
+ }
+
+ /* link forward and backward */
+ sw_dev->device = mdiodev;
+ dev_set_drvdata(&mdiodev->dev, sw_dev);
+ sw_dev->chip.dev = &mdiodev->dev;
+
+ ret = lan9303_probe(&sw_dev->chip, mdiodev->dev.of_node);
+ if (ret != 0)
+ return ret;
+
+ dev_info(&mdiodev->dev, "LAN9303 MDIO driver loaded successfully\n");
+
+ return 0;
+}
+
+static void lan9303_mdio_remove(struct mdio_device *mdiodev)
+{
+ struct lan9303_mdio *sw_dev = dev_get_drvdata(&mdiodev->dev);
+
+ if (!sw_dev)
+ return;
+
+ lan9303_remove(&sw_dev->chip);
+}
+
+/*-------------------------------------------------------------------------*/
+
+static const struct of_device_id lan9303_mdio_of_match[] = {
+ { .compatible = "smsc,lan9303-mdio" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, lan9303_mdio_of_match);
+
+static struct mdio_driver lan9303_mdio_driver = {
+ .mdiodrv.driver = {
+ .name = "LAN9303_MDIO",
+ .of_match_table = of_match_ptr(lan9303_mdio_of_match),
+ },
+ .probe = lan9303_mdio_probe,
+ .remove = lan9303_mdio_remove,
+};
+mdio_module_driver(lan9303_mdio_driver);
--
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 v5 1/4] gpio: mvebu: Add limited PWM support
From: Ralph Sennhauser @ 2017-04-13 7:45 UTC (permalink / raw)
To: Thierry Reding
Cc: Andrew Lunn, Linus Walleij, Alexandre Courbot, Rob Herring,
Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170412171121.GB11964@ulmo.ba.sec>
On Wed, 12 Apr 2017 19:11:21 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Sun, Apr 09, 2017 at 08:09:27PM +0200, Ralph Sennhauser wrote:
> > From: Andrew Lunn <andrew@lunn.ch>
> >
> > Armada 370/XP devices can 'blink' GPIO lines with a configurable on
> > and off period. This can be modelled as a PWM.
> >
> > However, there are only two sets of PWM configuration registers for
> > all the GPIO lines. This driver simply allows a single GPIO line per
> > GPIO chip of 32 lines to be used as a PWM. Attempts to use more
> > return EBUSY.
> >
> > Due to the interleaving of registers it is not simple to separate
> > the PWM driver from the GPIO driver. Thus the GPIO driver has been
> > extended with a PWM driver.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > URL: https://patchwork.ozlabs.org/patch/427287/
> > URL: https://patchwork.ozlabs.org/patch/427295/
> > [Ralph Sennhauser:
> > * Port forward
> > * Merge PWM portion into gpio-mvebu.c
> > * Switch to atomic PWM API
> > * Add new compatible string marvell,armada-370-xp-gpio
> > * Update and merge documentation patch
> > * Update MAINTAINERS]
> > Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> > Tested-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > .../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
> > MAINTAINERS | 2 +
> > drivers/gpio/gpio-mvebu.c | 324
> > ++++++++++++++++++++- 3 files changed, 346 insertions(+), 12
> > deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> > b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt index
> > a6f3bec..fe49e9d 100644 ---
> > a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt +++
> > b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt @@ -38,6
> > +38,24 @@ Required properties:
> > - #gpio-cells: Should be two. The first cell is the pin number. The
> > second cell is reserved for flags, unused at the moment.
> >
> > +Optional properties:
> > +
> > +In order to use the gpio lines in PWM mode, some additional
> > optional +properties are required. Only Armada 370 and XP support
> > these properties. +
> > +- compatible: Must contain "marvell,armada-370-xp-gpio"
> > +
> > +- reg: an additional register set is needed, for the GPIO Blink
> > + Counter on/off registers.
> > +
> > +- reg-names: Must contain an entry "pwm" corresponding to the
> > + additional register range needed for pwm operation.
> > +
> > +- #pwm-cells: Should be two. The first cell is the GPIO line
> > number. The
> > + second cell is the period in nanoseconds.
> > +
> > +- clocks: Must be a phandle to the clock for the gpio controller.
> > +
> > Example:
> >
> > gpio0: gpio@d0018100 {
> > @@ -51,3 +69,17 @@ Example:
> > #interrupt-cells = <2>;
> > interrupts = <16>, <17>, <18>, <19>;
> > };
> > +
> > + gpio1: gpio@18140 {
> > + compatible = "marvell,armada-370-xp-gpio";
> > + reg = <0x18140 0x40>, <0x181c8 0x08>;
> > + reg-names = "gpio", "pwm";
> > + ngpios = <17>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + #pwm-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + interrupts = <87>, <88>, <89>;
> > + clocks = <&coreclk 0>;
> > + };
>
> This is going to need an Acked-by from one of the device tree
> maintainers. Rob and devicetree@vger.kernel.org are on Cc, but I
> suspect nobody might look for the binding change "hidden" in this
> patch.
>
> Maybe best to split this off into a separate patch, or explicitly ping
> Rob to look at this patch.
Hi Thierry,
Rob asked for the new compatible string so he did see it presumably. As
you prefer to have an ACK by him I'll see to getting one for the driver
(bindings part). The patch could be split but then one might want to
split it even further. Like this the first patch in the series is a nice
self contained package.
>
<snip/>
>
> > +
> > + mvpwm->clk_rate = clk_get_rate(mvchip->clk);
> > + if (!mvpwm->clk_rate) {
> > + dev_err(dev, "failed to get clock rate\n");
> > + return -EINVAL;
> > + }
> > +
> > + mvpwm->chip.dev = dev;
> > + mvpwm->chip.ops = &mvebu_pwm_ops;
> > + mvpwm->chip.base = mvchip->chip.base;
> > + mvpwm->chip.npwm = mvchip->chip.ngpio;
>
> I still would've done this differently. If you use this with a PWM
> user you have to hook it up via DT anyway, so it doesn't matter
> whether you specify the PWM index or the GPIO via some other
> property. The _only_ use-case where this might actually be an
> advantage is if you request a PWM via the sysfs interface.
Let me answer this in the other mail where you bring this up.
>
<snip/>
> All of my comments are effectively of a bikeshed nature, so from a PWM
> perspective this is:
>
> Acked-by: Thierry Reding <thierry.reding@gmail.com>
Thanks for the detailed review and the ACK. Will work on all the
mentioned bits for v6.
Ralph
^ permalink raw reply
* Re: [PATCH v5 0/4] gpio: mvebu: Add PWM fan support
From: Ralph Sennhauser @ 2017-04-13 7:49 UTC (permalink / raw)
To: Thierry Reding
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412171656.GC11964-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
On Wed, 12 Apr 2017 19:16:56 +0200
Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Apr 09, 2017 at 08:09:26PM +0200, Ralph Sennhauser wrote:
> > Hi Therry,
> >
> > Resending this as v5 with some minor changes since v4. What is
> > missing is an ACK from you so Linus can merge the driver and
> > Gregory the dts changes. For this driver to make it into 4.12 it
> > would be nice to have it in next soon. I hope you can make some
> > room in your schedule to have another look at this series.
> >
> > Thanks
> > Ralph
> >
> > ---
> >
> > Notes:
> >
> > About npwm = 1:
> > The only way I can think of to achieve that requires reading the
> > GPIO line from the device tree. This would prevent a user to
> > dynamically choose a line. Which is fine for the fan found on
> > Mamba but let's take some development board with freely accessible
> > GPIOs and suddenly we limit the use of this driver. Given the
> > above, npwm = ngpio with only one usable at a time is a more
> > accurate
>
> I think "accurate" is perhaps not the word I'd choose. "npwm" is
> defined as "number of PWMs controlled by this chip", and that's
> effectively just the one. It's implied that all PWMs exposed by a
> chip can be used concurrently.
I'm not native English so some terms might be off a tad in how I use
them, replace accurate with what you think I meant ;).
The "it's implied" sounds like a contract and EBUSY a violation thereof.
>
> Anyway, I can see how npwm = ngpio might be more convenient, and if
> that is what you want to do, I don't feel strongly enough to object.
The goal is a pwm-fan driver for Mamba. So npwm=1 would work just fine
from that stand point. It's indeed the sysfs case I had in mind which
would be hampered. Whether to consider that one valid / desirable I
don't want to judge. For me it's a hypothetical use case for others it
might be real.
For this series I want just this one device to work and getting the
bindings right to not prevent others extending the driver later when
they need.
The driver which is under rework here is in use for 2 years, so I went
with the feature set provided by it which is more than I need. It's a
one of it's kind driver and I only have this single use case, so really
your call.
Thanks
Ralph
--
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 1/2] dt-bindings: Document STM32 I2S bindings
From: Olivier MOYSAN @ 2017-04-13 8:01 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland@arm.com, Rob Herring, alsa-devel@alsa-project.org,
Alexandre TORGUE, devicetree@vger.kernel.org, Arnaud POULIQUEN,
tiwai@suse.com, lgirdwood@gmail.com, mcoquelin.stm32@gmail.com,
perex@perex.cz, linux-arm-kernel@lists.infradead.org,
Benjamin GAIGNARD
In-Reply-To: <20170412153831.r2urwvfseipfsrsi@sirena.org.uk>
Hello Mark,
On 04/12/2017 05:38 PM, Mark Brown wrote:
> On Wed, Apr 12, 2017 at 12:58:16PM +0000, Olivier MOYSAN wrote:
>> On 04/12/2017 01:32 PM, Mark Brown wrote:
>
>>> It is totally normal to just not use one direction in a given system, we
>>> don't normally need to do anything special to handle things. I'm a bit
>>> confused as to what's different here and needs configuring?
>
>> The IP does not provide an audio channel configured either as rx or tx.
>> I agree, that in such case, the cpu driver does not generally need
>> to worry about direction and there is nothing special required to handle it.
>
> No, that's not what I'm saying - such hardware would be extremely
> unusual.
>
>> Here the IP provides 2 channels, 1 tx and 1 rx, which may be active or
>> not. The driver has to know which channel is used, and if both channels
>> have to be managed. The affected registers depend on selected channel.
>
> This sounds like essentially every audio controller out there. The
> overwhelming majority of controllers do exactly as you describe and have
> both directions in the same IP, this really doesn't seem at all unusual.
> Off the top of my head I can only think of one SoC family which combines
> multiple IPs to do bidirectional audio (though I didn't check).
>
> It really feels like there is something different here and I'm just
> missing it.
>
Yes, I think I need to give more details on design choices.
The IP provides 2 channels.
I can see mainly 3 solutions to link dais to these channels:
1) 2 static dais NOT exclusive
- dai tx
- dai rx
The IP exhibits a mode register, where you select mode TX, RX or FD.
There are 2 two options to manage this register.
option 1:
start first channel with mode RX or TX
when second channel is started, mode has to be changed to FD.
Transfers have to be stopped before changing configuration
registers, so this leads to cuts in audio stream.
option 2:
start a first channel with mode FD.
In this case, we may have unpredictable behavior for the stream
which is not already started. probably underrun/overrun.
So, this solution rises problem for full-duplex management.
2) 3 static dais exclusive
- dai tx
- dai rx
- dai rx-tx (fd)
This is the current implementation.
The choice of the dai is done at probe time. It is provided by DT
through sound-dai parameter.
When dai fd is selected, after starting first stream, we assume that
second stream will be started. In this case we wait for second stream
to be available before enabling IP and starting transfers.
3) 1 dynamic dai
- dai rx or tx or fd (according to dma conf in IP node)
Here the driver exposes only a single dai constructed from dma
configuration provided by IP DT node.
This allows to get ride of sound-dai parameter.
This was my suggestion after Rob comments on DT bindings.
Hope this will help clarifying design constraints.
>> Moreover specific processing has to be performed if both channels are used.
>
> Given that this case has to be supported anyway I'd be more inclined to
> ask the question the other way around TBH.
>
Best regards
olivier
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board
From: Heiko Stübner @ 2017-04-13 8:22 UTC (permalink / raw)
To: Kever Yang
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jianqun Xu, Liang Chen,
Brian Norris, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andy Yan,
Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Will Deacon, Mark Rutland, Catalin Marinas, Matthias Brugger
In-Reply-To: <6d1eb0cc-fe3b-a483-123c-8558096c0846-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Donnerstag, 13. April 2017, 12:00:19 CEST schrieb Kever Yang:
> Hi Heiko,
>
> On 04/12/2017 09:29 PM, Heiko Stuebner wrote:
> > Hi Kever,
> >
> > Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang:
> >> Firefly-rk3399 is a bord from T-Firefly, you can find detail about
> >> it here:
> >> http://en.t-firefly.com/en/firenow/Firefly_RK3399/
> >>
> >> This patch add basic node for the board and make it able to bring
> >> up.
> >>
> >> Peripheral works:
> >> - usb hub which connect to ehci controller;
> >> - UART2 debug
> >> - eMMC
> >> - PCIe
> >>
> >> Not work:
> >> - USB 3.0 HOST, type-C port
> >> - sdio, sd-card
> >>
> >> Not test for other peripheral:
> >> - HDMI
> >> - Ethernet
> >> - OPTICAL
> >> - WiFi/BT
> >> - MIPI CSI/DSI
> >> - IR
> >> - EDP/DP
> >>
> >> Signed-off-by: Kever Yang <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >
> > applied for 4.13, as we're a bit late for 4.12, with the following
changes:
> Thanks for your help, I'm not familiar with the devices status on upstream
> because not working on kernel upstream for a long time.
>
> > - commit subject
> > - dropped status from backlight (as there is no disabled common node
> >
> > and it's specific to the firefly itself)
> >
> > - quite some reordering of properties
> > - reordered regulator nodes per their addresses: 0x1b < 0x40
> > - dropped obsolete regulator-compatible properties
> > - fixed gpio-irq on the mpu6500
> > - dropped out-of-tree orientation properties of mpu6500
> >
> > --> please provide the optional "mount-matrix" in a follow-up patch
> >
> > see bindings/iio/imu/inv_mpu6050.txt
>
> Maybe we can drop this mpu6050 node first? I can't find binding file for it.
The binding (and driver in the kernel) is the same as for the mpu6050.
So you can find the documentation in
Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
Someone should add the other ids from
drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
to the binding.
mount-matrix is optional, so the basic node itself can stay in the dt.
Heiko
--
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 v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash
From: Cyrille Pitchen @ 2017-04-13 8:24 UTC (permalink / raw)
To: Guochun Mao
Cc: Cyrille Pitchen, Mark Rutland, devicetree, Richard Weinberger,
Russell King, linux-kernel, Rob Herring, linux-mtd,
Matthias Brugger, linux-mediatek, David Woodhouse,
linux-arm-kernel
In-Reply-To: <1492051237.2866.36.camel@mhfsdcap03>
Hi Guochun,
Le 13/04/2017 à 04:40, Guochun Mao a écrit :
> Hi Cyrille,
>
> On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote:
>> Hi Guochun,
>>
>> Le 05/04/2017 à 10:37, Guochun Mao a écrit :
>>> When nor's size larger than 16MByte, nor's address width maybe
>>> set to 3 or 4, and controller should change address width according
>>> to nor's setting.
>>>
>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>st
Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>>> ---
>>> drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> index e661877..b637770 100644
>>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
>>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> @@ -104,6 +104,8 @@
>>> #define MTK_NOR_MAX_RX_TX_SHIFT 6
>>> /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
>>> #define MTK_NOR_MAX_SHIFT 7
>>> +/* nor controller 4-byte address mode enable bit */
>>> +#define MTK_NOR_4B_ADDR_EN BIT(4)
>>>
>>> /* Helpers for accessing the program data / shift data registers */
>>> #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
>>> @@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor)
>>> 10000);
>>> }
>>>
>>> +static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
>>> +{
>>> + u8 val;
>>> + struct spi_nor *nor = &mt8173_nor->nor;
>>> +
>>> + val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
>>> +
>>> + switch (nor->addr_width) {
>>> + case 3:
>>> + val &= ~MTK_NOR_4B_ADDR_EN;
>>> + break;
>>> + case 4:
>>> + val |= MTK_NOR_4B_ADDR_EN;
>>> + break;
>>> + default:
>>> + dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
>>> + nor->addr_width);
>>> + break;
>>> + }
>>> +
>>> + writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
>>> +}
>>> +
>>> static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
>>> {
>>> int i;
>>>
>>> + mt8173_nor_set_addr_width(mt8173_nor);
>>> +
>>> for (i = 0; i < 3; i++) {
>>
>> Should it be 'i < nor->addr_width' instead of 'i < 3' ?
>> Does it work when accessing data after 128Mbit ?
>
> Yes, it can work.
>
> Let's see the whole function,
>
> static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
> {
> int i;
>
> mt8173_nor_set_addr_width(mt8173_nor);
>
> for (i = 0; i < 3; i++) {
> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG
> + i * 4);
> addr >>= 8;
> }
> /* Last register is non-contiguous */
> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR3_REG);
> }
>
> The nor controller has 4 registers for address.
> This '3' indicates the number of contiguous address' registers
> base + MTK_NOR_RADR0_REG(0x10)
> base + MTK_NOR_RADR1_REG(0x14)
> base + MTK_NOR_RADR2_REG(0x18),
> but the last address register is non-contiguous,
> it's base + MTK_NOR_RADR3_REG(0xc8)
>
> mt8173_nor_set_addr will set addr into these 4 registers by Byte.
> The bit MTK_NOR_4B_ADDR_EN will decide whether 3-byte(0x10,0x14,0x18)
> or 4-byte(0x10,0x14,x018,0xc8) been sent to nor device.
> and, it can access data after 128Mbit when sent 4-byte address.
Indeed, you're right. Sorry for the noise!
>
> Best regards,
>
> Guochun
>
>>
>> Best regards,
>>
>> Cyrille
>>
>>> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4);
>>> addr >>= 8;
>>>
>>
>
>
>
^ permalink raw reply
* Re: [PATCHv4 0/2] Nokia H4+ support
From: Marcel Holtmann @ 2017-04-13 8:33 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Gustavo F. Padovan, Johan Hedberg, Rob Herring, Pavel Machek,
Linux Bluetooth, devicetree, linux-kernel
In-Reply-To: <20170413002659.25821-1-sre@kernel.org>
Hi Sebastian,
> Here is the fourth revision of the nokia bluetooth patchset. Compared
> to the previous one the following things have changed:
>
> * Drop patch 1-8 (applied by Marcel) and update Cc/To for patchset
> * Order includes in the driver alphabetically
> * Explicitly include <linux/of.h> in the nokia bluetooth driver
>
> -- Sebastian
>
> Sebastian Reichel (2):
> dt-bindings: net: bluetooth: Add nokia-bluetooth
> Bluetooth: add nokia driver
both patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: PrasannaKumar Muralidharan @ 2017-04-13 8:39 UTC (permalink / raw)
To: sean.wang
Cc: Herbert Xu, Matt Mackall, Rob Herring, Mark Rutland,
Corentin LABBE, Romain Perier, shannon.nelson, Wei Yongjun,
devicetree, linux-crypto, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede
In-Reply-To: <1492067108-14748-3-git-send-email-sean.wang@mediatek.com>
Hi Sean,
Mostly looks good, have few minor comments.
On 13 April 2017 at 12:35, <sean.wang@mediatek.com> wrote:
> +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int ready;
> +
> + ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> + if (!ready && wait)
> + readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> + ready & RNG_READY, USEC_POLL,
> + TIMEOUT_POLL);
> + return !!ready;
> +}
Use readl_poll_timeout_atomic's return value or -EIO instead of
!!ready. This will simplify mtk_rng_read.
> +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int retval = 0;
> +
> + while (max >= sizeof(u32)) {
> + if (!mtk_rng_wait_ready(rng, wait))
> + break;
> +
> + *(u32 *)buf = readl(priv->base + RNG_DATA);
> + retval += sizeof(u32);
> + buf += sizeof(u32);
> + max -= sizeof(u32);
> + }
> +
> + if (unlikely(wait && max))
> + dev_warn(priv->dev, "timeout might be not properly set\n");
Is this really necessary? Better to choose proper timeout than
providing this warning message. In rare cases if the timeout could
occur due to some reason (may be a hardware fault) print appropriate
warning message.
> + return retval || !wait ? retval : -EIO;
> +}
Set retavl to mtk_rng_wait_ready and return retval.
Regards,
Prasanna
^ permalink raw reply
* Re: [PATCH 1/2] mfd: arizona: Add GPIO maintain state flag
From: Charles Keepax @ 2017-04-13 9:15 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Rob Herring, linus.walleij, lee.jones, gnurou, mark.rutland,
linux-gpio, devicetree, linux-kernel, patches
In-Reply-To: <1491903267.4826.8.camel@rf-debian.wolfsonmicro.main>
On Tue, Apr 11, 2017 at 10:34:27AM +0100, Richard Fitzgerald wrote:
> On Mon, 2017-04-10 at 15:17 -0500, Rob Herring wrote:
> > On Fri, Apr 07, 2017 at 01:38:44PM +0100, Charles Keepax wrote:
> > > The Arizona devices only maintain the state of output GPIOs whilst the
> > > CODEC is active, this can cause issues if the CODEC suspends whilst
> > > something is relying on the state of one of its GPIOs. However, in
> > > many systems the CODEC GPIOs are used for audio related features
> > > and thus the state of the GPIOs is unimportant whilst the CODEC is
> > > suspended. Often keeping the CODEC resumed in such a system would
> > > incur a power impact that is unacceptable.
> > >
> > > Add a flag through the second cell of the GPIO specifier in device
> > > tree, to allow the user to select whether a GPIO being configured as
> > > an output should keep the CODEC resumed.
> >
> > If the whole codec can't be suspended, why does this need to be per
> > GPIO? You could just have a single boolean property.
> >
>
> Three reasons I can think of:
>
> 1) The GPIO binding already provides for passing extra information
> through the binding ("Exact meaning of each specifier cell is controller
> specific" as it says in the main gpio binding doc) so why add yet
> another custom property to do it?
>
> 2) Doing it through the gpio means that if ultimately the child DT node
> that is using it gets disabled (status="disabled") or that driver isn't
> in use the codec will be able to go to sleep. That won't happen with a
> brute-force "big lock".
>
> 3) The codec only has to be kept awake while any such GPIO is actually
> in use. See (2)
>
Yeah option 3 is the primary issue here, we only want to keep the
CODEC enabled whilst specific GPIOs are in use. As GPIOs can be
dynamically requested/released by things in the kernel we want to
know which GPIOs require the CODEC to be kept alive. Also in the
future one might be tempted to add maintain whilst high and
maintain whilst low options for lines with pulls on them to
further optimise power.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default
From: Philipp Zabel @ 2017-04-13 10:07 UTC (permalink / raw)
To: Hans Verkuil
Cc: Steve Longerbeam, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
nick-gcszYUEDH4VrovVCs/uTlw, markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-medi
In-Reply-To: <6c22519f-64f8-7213-d458-23470bdd5ecd-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On Wed, 2017-04-12 at 09:03 +0200, Hans Verkuil wrote:
[...]
> >> Do you have a git tree with this patch? It is really hard to review without
> >> having the full imx-media-csi.c source.
> >
> > The patch applies on top of
> >
> > https://github.com/slongerbeam/mediatree.git imx-media-staging-md-v14
> >
> > I have uploaded a branch
> >
> > git://git.pengutronix.de/git/pza/linux imx-media-staging-md-v14+color
> >
> > with the patch applied on top.
> >
> >> I think one problem is that it is not clearly defined how subdevs and colorspace
> >> information should work.
>
> Ah, having the full source helped.
>
> Ignore my previous review, it was incorrect.
Ok.
> I'll have to think about this some more. I'll get back to this, but it may take some
> time since my vacation starts tomorrow. The spec is simply unclear about how to handle
> this so we have to come up with some guidelines.
Yes, please. Until then, have a nice vacation.
regards
Philipp
--
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 0/4] XRA1403,gpio - add XRA1403 gpio expander driver
From: Nandor Han @ 2017-04-13 10:27 UTC (permalink / raw)
To: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, robh+dt, mark.rutland, linux-gpio, devicetree,
linux-kernel
Cc: Nandor Han
The patchset will add a driver to support basic functionality for
XRA1403 device. Features supported:
- get/set GPIO direction (input, output)
- get/set GPIO level (low, high)
Documentation: A gpio-xra1403.txt file was added to document the DTS
bindings related to driver.
Testing:
1.1 XRA1403 connected to iMX53 MCU
1.2 Use the GPIO tools provided by kernel from tools/gpio dir
2.1 `lsgpio`
root@csmon ppd:~# lsgpio
GPIO chip: gpiochip8, "xra1403", 16 GPIO lines
line 0: unnamed unused [output]
line 1: unnamed unused [output]
line 2: unnamed unused [output]
line 3: unnamed unused [output]
line 4: unnamed unused [output]
line 5: unnamed unused
line 6: unnamed unused
line 7: unnamed unused [output]
line 8: unnamed unused [output]
line 9: unnamed unused
line 10: unnamed unused [output]
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused [output]
GPIO chip: gpiochip7, "xra1403", 16 GPIO lines
line 0: unnamed unused
line 1: unnamed unused
line 2: unnamed unused
line 3: unnamed unused
line 4: unnamed unused
line 5: unnamed unused
line 6: unnamed unused
line 7: unnamed unused
line 8: unnamed unused
line 9: unnamed unused
line 10: unnamed unused
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused
3.1 `gpio-hammer`
root@csmon ppd:~# gpio-hammer -n gpiochip8 -o0 -o1 -o2 -o3
Hammer lines [0, 1, 2, 3] on gpiochip8, initial states: [0, 0, 0, 0]
[\] [0: 0, 1: 0, 2: 0, 3: 0]
...
[\] [0: 1, 1: 1, 2: 1, 3: 1]
When using `gpio-hammer` I also attached an oscilloscope to one of the pins and I was
able to monitor and validate the GPIO status.
Nandor Han (4):
dt-bindings: gpio - add exar to vendor prefixes list
gpio - Add EXAR XRA1403 SPI GPIO expander driver
doc,dts - add XRA1403 DTS binding documentation
Add XRA1403 support to MAINTAINERS file
.../devicetree/bindings/gpio/gpio-xra1403.txt | 46 ++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
MAINTAINERS | 8 +
drivers/gpio/Kconfig | 5 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-xra1403.c | 236 +++++++++++++++++++++
6 files changed, 297 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
create mode 100644 drivers/gpio/gpio-xra1403.c
--
2.10.1
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: gpio - add exar to vendor prefixes list
From: Nandor Han @ 2017-04-13 10:27 UTC (permalink / raw)
To: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, robh+dt, mark.rutland, linux-gpio, devicetree,
linux-kernel
Cc: Nandor Han
In-Reply-To: <cover.1492077070.git.nandor.han@ge.com>
Add Exar Corporation to vendors list.
Signed-off-by: Nandor Han <nandor.han@ge.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c7d1b72..ba9058c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -104,6 +104,7 @@ ettus NI Ettus Research
eukrea Eukréa Electromatique
everest Everest Semiconductor Co. Ltd.
everspin Everspin Technologies, Inc.
+exar Exar Corporation
excito Excito
ezchip EZchip Semiconductor
faraday Faraday Technology Corporation
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/4] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Nandor Han @ 2017-04-13 10:27 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, daniel.vetter-/w4YWyX8dFk,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Nandor Han, Semi Malinen
In-Reply-To: <cover.1492077070.git.nandor.han-JJi787mZWgc@public.gmane.org>
This is a simple driver that provides a /sys/class/gpio
interface for controlling and configuring the GPIO lines.
It does not provide support for chip select or interrupts.
Signed-off-by: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
Signed-off-by: Semi Malinen <semi.malinen-JJi787mZWgc@public.gmane.org>
---
drivers/gpio/Kconfig | 5 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-xra1403.c | 236 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 242 insertions(+)
create mode 100644 drivers/gpio/gpio-xra1403.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 63ceed2..53cbe9b 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1214,6 +1214,11 @@ config GPIO_PISOSR
GPIO driver for SPI compatible parallel-in/serial-out shift
registers. These are input only devices.
+config GPIO_XRA1403
+ tristate "EXAR XRA1403 16-bit GPIO expander"
+ help
+ GPIO driver for EXAR XRA1403 16-bit SPI-based GPIO expander.
+
endmenu
menu "SPI or I2C GPIO expanders"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 095598e..76dc3d7 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -140,6 +140,7 @@ obj-$(CONFIG_GPIO_XGENE) += gpio-xgene.o
obj-$(CONFIG_GPIO_XGENE_SB) += gpio-xgene-sb.o
obj-$(CONFIG_GPIO_XILINX) += gpio-xilinx.o
obj-$(CONFIG_GPIO_XLP) += gpio-xlp.o
+obj-$(CONFIG_GPIO_XRA1403) += gpio-xra1403.o
obj-$(CONFIG_GPIO_XTENSA) += gpio-xtensa.o
obj-$(CONFIG_GPIO_ZEVIO) += gpio-zevio.o
obj-$(CONFIG_GPIO_ZYNQ) += gpio-zynq.o
diff --git a/drivers/gpio/gpio-xra1403.c b/drivers/gpio/gpio-xra1403.c
new file mode 100644
index 0000000..e6966d9
--- /dev/null
+++ b/drivers/gpio/gpio-xra1403.c
@@ -0,0 +1,236 @@
+/*
+ * GPIO driver for EXAR XRA1403 16-bit GPIO expander
+ *
+ * Copyright (c) 2017, General Electric Company
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/bitops.h>
+#include <linux/gpio/driver.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/regmap.h>
+
+/* XRA1403 registers */
+#define XRA_GSR 0x00 /* GPIO State */
+#define XRA_OCR 0x02 /* Output Control */
+#define XRA_PIR 0x04 /* Input Polarity Inversion */
+#define XRA_GCR 0x06 /* GPIO Configuration */
+#define XRA_PUR 0x08 /* Input Internal Pull-up Resistor Enable/Disable */
+#define XRA_IER 0x0A /* Input Interrupt Enable */
+#define XRA_TSCR 0x0C /* Output Three-State Control */
+#define XRA_ISR 0x0E /* Input Interrupt Status */
+#define XRA_REIR 0x10 /* Input Rising Edge Interrupt Enable */
+#define XRA_FEIR 0x12 /* Input Falling Edge Interrupt Enable */
+#define XRA_IFR 0x14 /* Input Filter Enable/Disable */
+
+struct xra1403 {
+ struct gpio_chip chip;
+ struct regmap *regmap;
+};
+
+static const struct regmap_config xra1403_regmap_cfg = {
+ .reg_bits = 7,
+ .pad_bits = 1,
+ .val_bits = 8,
+
+ .max_register = XRA_IFR | 0x01,
+};
+
+static unsigned int to_reg(unsigned int reg, unsigned int offset)
+{
+ return reg + (offset > 7);
+}
+
+static int xra1403_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ struct xra1403 *xra = gpiochip_get_data(chip);
+
+ return regmap_update_bits(xra->regmap, to_reg(XRA_GCR, offset),
+ BIT(offset % 8), BIT(offset % 8));
+}
+
+static int xra1403_direction_output(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+ int ret;
+ struct xra1403 *xra = gpiochip_get_data(chip);
+
+ ret = regmap_update_bits(xra->regmap, to_reg(XRA_GCR, offset),
+ BIT(offset % 8), 0);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(xra->regmap, to_reg(XRA_OCR, offset),
+ BIT(offset % 8), value ? BIT(offset % 8) : 0);
+
+ return ret;
+}
+
+static int xra1403_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ int ret;
+ unsigned int val;
+ struct xra1403 *xra = gpiochip_get_data(chip);
+
+ ret = regmap_read(xra->regmap, to_reg(XRA_GCR, offset), &val);
+ if (ret)
+ return ret;
+
+ return !!(val & BIT(offset % 8));
+}
+
+static int xra1403_get(struct gpio_chip *chip, unsigned int offset)
+{
+ int ret;
+ unsigned int val;
+ struct xra1403 *xra = gpiochip_get_data(chip);
+
+ ret = regmap_read(xra->regmap, to_reg(XRA_GSR, offset), &val);
+ if (ret)
+ return ret;
+
+ return !!(val & BIT(offset % 8));
+}
+
+static void xra1403_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ int ret;
+ struct xra1403 *xra = gpiochip_get_data(chip);
+
+ ret = regmap_update_bits(xra->regmap, to_reg(XRA_OCR, offset),
+ BIT(offset % 8), value ? BIT(offset % 8) : 0);
+ if (ret)
+ dev_err(chip->parent, "Failed to set pin: %d, ret: %d\n",
+ offset, ret);
+}
+
+#ifdef CONFIG_DEBUG_FS
+static void xra1403_dbg_show(struct seq_file *s, struct gpio_chip *chip)
+{
+ int reg;
+ struct xra1403 *xra = gpiochip_get_data(chip);
+ int value[xra1403_regmap_cfg.max_register];
+ int i;
+ unsigned int gcr;
+ unsigned int gsr;
+
+ seq_puts(s, "xra reg:");
+ for (reg = 0; reg <= xra1403_regmap_cfg.max_register; reg++)
+ seq_printf(s, " %2.2x", reg);
+ seq_puts(s, "\n value:");
+ for (reg = 0; reg < xra1403_regmap_cfg.max_register; reg++) {
+ regmap_read(xra->regmap, reg, &value[reg]);
+ seq_printf(s, " %2.2x", value[reg]);
+ }
+ seq_puts(s, "\n");
+
+ gcr = value[XRA_GCR + 1] << 8 | value[XRA_GCR];
+ gsr = value[XRA_GSR + 1] << 8 | value[XRA_GSR];
+ for (i = 0; i < chip->ngpio; i++) {
+ const char *label = gpiochip_is_requested(chip, i);
+
+ if (!label)
+ continue;
+
+ seq_printf(s, " gpio-%-3d (%-12s) %s %s\n",
+ chip->base + i, label,
+ (gcr & BIT(i)) ? "in" : "out",
+ (gsr & BIT(i)) ? "hi" : "lo");
+ }
+}
+#else
+#define xra1403_dbg_show NULL
+#endif
+
+static int xra1403_probe(struct spi_device *spi)
+{
+ struct xra1403 *xra;
+ struct gpio_desc *reset_gpio;
+ int ret;
+
+ xra = devm_kzalloc(&spi->dev, sizeof(*xra), GFP_KERNEL);
+ if (!xra)
+ return -ENOMEM;
+
+ /* bring the chip out of reset if reset pin is provided*/
+ reset_gpio = devm_gpiod_get_optional(&spi->dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(reset_gpio))
+ dev_warn(&spi->dev, "Could not get reset-gpios\n");
+
+ xra->chip.direction_input = xra1403_direction_input;
+ xra->chip.direction_output = xra1403_direction_output;
+ xra->chip.get_direction = xra1403_get_direction;
+ xra->chip.get = xra1403_get;
+ xra->chip.set = xra1403_set;
+
+ xra->chip.dbg_show = xra1403_dbg_show;
+
+ xra->chip.ngpio = 16;
+ xra->chip.label = "xra1403";
+
+ xra->chip.base = -1;
+ xra->chip.can_sleep = true;
+ xra->chip.parent = &spi->dev;
+ xra->chip.owner = THIS_MODULE;
+
+ xra->regmap = devm_regmap_init_spi(spi, &xra1403_regmap_cfg);
+ if (IS_ERR(xra->regmap)) {
+ ret = PTR_ERR(xra->regmap);
+ dev_err(&spi->dev, "Failed to allocate regmap: %d\n", ret);
+ return ret;
+ }
+
+ ret = devm_gpiochip_add_data(&spi->dev, &xra->chip, xra);
+ if (ret < 0) {
+ dev_err(&spi->dev, "Unable to register gpiochip\n");
+ return ret;
+ }
+
+ spi_set_drvdata(spi, xra);
+
+ return 0;
+}
+
+static const struct spi_device_id xra1403_ids[] = {
+ { "xra1403" },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, xra1403_ids);
+
+static const struct of_device_id xra1403_spi_of_match[] = {
+ { .compatible = "exar,xra1403" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, xra1403_spi_of_match);
+
+static struct spi_driver xra1403_driver = {
+ .probe = xra1403_probe,
+ .id_table = xra1403_ids,
+ .driver = {
+ .name = "xra1403",
+ .of_match_table = of_match_ptr(xra1403_spi_of_match),
+ },
+};
+
+module_spi_driver(xra1403_driver);
+
+MODULE_AUTHOR("Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>");
+MODULE_AUTHOR("Semi Malinen <semi.malinen-JJi787mZWgc@public.gmane.org>");
+MODULE_DESCRIPTION("GPIO expander driver for EXAR XRA1403");
+MODULE_LICENSE("GPL v2");
--
2.10.1
--
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 3/4] doc,dts - add XRA1403 DTS binding documentation
From: Nandor Han @ 2017-04-13 10:27 UTC (permalink / raw)
To: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, robh+dt, mark.rutland, linux-gpio, devicetree,
linux-kernel
Cc: Nandor Han
In-Reply-To: <cover.1492077070.git.nandor.han@ge.com>
Add the XRA1403 DTS binding documentation.
Signed-off-by: Nandor Han <nandor.han@ge.com>
---
.../devicetree/bindings/gpio/gpio-xra1403.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xra1403.txt b/Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
new file mode 100644
index 0000000..e13cc39
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
@@ -0,0 +1,46 @@
+GPIO Driver for XRA1403 16-BIT GPIO Expander With Reset Input from EXAR
+
+The XRA1403 is an 16-bit GPIO expander with an SPI interface. Features available:
+ - Individually programmable inputs:
+ - Internal pull-up resistors
+ - Polarity inversion
+ - Individual interrupt enable
+ - Rising edge and/or Falling edge interrupt
+ - Input filter
+ - Individually programmable outputs
+ - Output Level Control
+ - Output Three-State Control
+
+Properties
+----------
+Check documentation for SPI and GPIO controllers regarding properties needed to configure the node.
+
+ - compatible = "exar,xra1403".
+ - reg - SPI id of the device.
+ - gpio-controller - marks the node as gpio.
+ - #gpio-cells - should be two where the first cell is the pin number
+ and the second one is used for optional parameters.
+
+Optional properties:
+-------------------
+ - reset-gpios: in case available used to control the device reset line.
+ - interrupt-controller - marks the node as interrupt controller.
+ - #interrupt-cells - should be two and represents the number of cells
+ needed to encode interrupt source.
+
+Example
+--------
+
+ gpioxra0: gpio@2 {
+ compatible = "exar,xra1403";
+ reg = <2>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <1000000>;
+ };
--
2.10.1
^ permalink raw reply related
* [PATCH v2 4/4] Add XRA1403 support to MAINTAINERS file
From: Nandor Han @ 2017-04-13 10:27 UTC (permalink / raw)
To: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, robh+dt, mark.rutland, linux-gpio, devicetree,
linux-kernel
Cc: Nandor Han
In-Reply-To: <cover.1492077070.git.nandor.han@ge.com>
Add XRA1403 support to MAINTAINERS list.
Signed-off-by: Nandor Han <nandor.han@ge.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 892e958..0c5b984 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14013,6 +14013,14 @@ L: linux-kernel@vger.kernel.org
S: Supported
F: drivers/char/xillybus/
+XRA1403 GPIO EXPANDER
+M: Nandor Han <nandor.han@ge.com>
+M: Semi Malinen <semi.malinen@ge.com>
+L: linux-gpio@vger.kernel.org
+S: Maintained
+F: drivers/gpio/gpio-xra1403.c
+F: Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
+
XTENSA XTFPGA PLATFORM SUPPORT
M: Max Filippov <jcmvbkbc@gmail.com>
L: linux-xtensa@linux-xtensa.org
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: Corentin Labbe @ 2017-04-13 11:06 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w,
romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
shannon.nelson-QHcLZuEGTsvQT0dZR+AlfA,
weiyongjun1-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1492067108-14748-3-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hello
I have some minor comment below:
On Thu, Apr 13, 2017 at 03:05:08PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> This patch adds support for hardware random generator on MT7623 SoC
> and should also work on other similar Mediatek SoCs. Currently,
> the driver is already tested successfully with rng-tools.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> drivers/char/hw_random/Kconfig | 16 +++-
> drivers/char/hw_random/Makefile | 2 +-
> drivers/char/hw_random/mtk-rng.c | 174 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 190 insertions(+), 2 deletions(-)
> create mode 100644 drivers/char/hw_random/mtk-rng.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 0cafe08..af782ce 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
> Generator hardware found on Cavium SoCs.
>
> To compile this driver as a module, choose M here: the
> - module will be called cavium_rng.
> + module will be called mtk-rng.
Unwanted change
>
> If unsure, say Y.
>
> +config HW_RANDOM_MTK
> + tristate "Mediatek Random Number Generator support"
> + depends on HW_RANDOM
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + default y
> + ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on Mediatek SoCs.
> +
> + To compile this driver as a module, choose M here. the
> + module will be called mtk-rng.
> +
> + If unsure, say Y.
> +
> endif # HW_RANDOM
>
> config UML_RANDOM
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index 5f52b1e..68be716 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -1,7 +1,6 @@
> #
> # Makefile for HW Random Number Generator (RNG) device drivers.
> #
> -
Another unwanted change
> obj-$(CONFIG_HW_RANDOM) += rng-core.o
> rng-core-y := core.o
> obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
> @@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
> obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
> obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
> obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
> +obj-$(CONFIG_HW_RANDOM_MTK) += mtk-rng.o
> diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
> new file mode 100644
> index 0000000..6561ee0
> --- /dev/null
> +++ b/drivers/char/hw_random/mtk-rng.c
> @@ -0,0 +1,174 @@
> +/*
> + * Driver for Mediatek Hardware Random Number Generator
> + *
> + * Copyright (C) 2017 Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@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.
> + *
> + * 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.
> + */
> +#define MTK_RNG_DEV KBUILD_MODNAME
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hw_random.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +#define USEC_POLL 2
> +#define TIMEOUT_POLL 20
> +
> +#define RNG_CTRL 0x00
> +#define RNG_EN BIT(0)
> +#define RNG_READY BIT(31)
Keep only one space between define and name
> +
> +#define RNG_DATA 0x08
> +
> +#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
> +
> +struct mtk_rng {
> + struct device *dev;
> + void __iomem *base;
> + struct clk *clk;
> + struct hwrng rng;
> +};
> +
> +static int mtk_rng_init(struct hwrng *rng)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + u32 val;
> + int err;
> +
> + err = clk_prepare_enable(priv->clk);
> + if (err)
> + return err;
> +
> + val = readl(priv->base + RNG_CTRL);
> + val |= RNG_EN;
> + writel(val, priv->base + RNG_CTRL);
> +
> + return 0;
> +}
> +
> +static void mtk_rng_cleanup(struct hwrng *rng)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + u32 val;
> +
> + val = readl(priv->base + RNG_CTRL);
> + val &= ~RNG_EN;
> + writel(val, priv->base + RNG_CTRL);
> +
> + clk_disable_unprepare(priv->clk);
> +}
> +
> +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int ready;
> +
> + ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> + if (!ready && wait)
> + readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> + ready & RNG_READY, USEC_POLL,
> + TIMEOUT_POLL);
> + return !!ready;
> +}
> +
> +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int retval = 0;
> +
> + while (max >= sizeof(u32)) {
> + if (!mtk_rng_wait_ready(rng, wait))
> + break;
> +
> + *(u32 *)buf = readl(priv->base + RNG_DATA);
> + retval += sizeof(u32);
> + buf += sizeof(u32);
> + max -= sizeof(u32);
> + }
> +
> + if (unlikely(wait && max))
> + dev_warn(priv->dev, "timeout might be not properly set\n");
> +
> + return retval || !wait ? retval : -EIO;
> +}
> +
> +static int mtk_rng_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + int ret;
> + struct mtk_rng *priv;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "no iomem resource\n");
> + return -ENXIO;
> + }
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = &pdev->dev;
> + priv->rng.name = pdev->name;
> + priv->rng.init = mtk_rng_init;
> + priv->rng.cleanup = mtk_rng_cleanup;
> + priv->rng.read = mtk_rng_read;
> +
> + priv->clk = devm_clk_get(&pdev->dev, "rng");
> + if (IS_ERR(priv->clk)) {
> + ret = PTR_ERR(priv->clk);
> + dev_err(&pdev->dev, "no clock for device: %d\n", ret);
> + return ret;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
You get that resource twice
Regards
Corentin Labbe
--
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: [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Oza Oza @ 2017-04-13 11:41 UTC (permalink / raw)
To: Robin Murphy
Cc: Linux IOMMU, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <b02ace9b-f8f3-269d-6db4-3c1b1ea1e816-5wv7dgnIgG8@public.gmane.org>
On Wed, Mar 29, 2017 at 11:12 PM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
> On 29/03/17 06:46, Oza Oza wrote:
>> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>> On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
>>>> For PCI masters not represented in DT, we pass the OF node of their
>>>> associated host bridge to of_dma_configure(), such that they can inherit
>>>> the appropriate DMA configuration from whatever is described there.
>>>> Unfortunately, whilst this has worked for the "dma-coherent" property,
>>>> it turns out to miss the case where the host bridge node has a non-empty
>>>> "dma-ranges", since nobody is expecting the 'device' to be a bus itself.
>>>>
>>>> It transpires, though, that the de-facto interface since the prototype
>>>> change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
>>>> re-use") is very clear-cut: either the master_np argument is redundant
>>>> with dev->of_node, or dev->of_node is NULL and master_np is the relevant
>>>> parent bus. Let's ratify that behaviour, then teach the whole
>>>> of_dma_configure() pipeline to cope with both cases properly.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>
> [...]
>
>>>
>>> pci and memory mapped device world is different.
>
> ???
>
> No they aren't. There is nothing magic about PCI. PCI *is* a
> memory-mapped bus.
>
> The only PCI-specific aspect here is the Linux code path which passes a
> host controller node into of_dma_configure() where the latter expects a
> node for the actual endpoint device. It managed to work for
> "dma-coherent", because that may appear either directly on a device node
> or on any of its parent buses, but "dma-ranges" is *only* valid for DT
> nodes representing buses, thus reveals that using a parent bus to stand
> in for a device isn't actually correct. I only posted that horrible hack
> patch to prove the point that having a child node to represent the
> actual device is indeed sufficient to make of_dma_configure() work
> correctly for PCI masters as-is (modulo the other issues).
>
>> of course if you talk
>>> from iommu perspective, all the master are same for IOMMU
>
> I don't understand what you mean by that. There's nothing about IOMMUs
> here, it's purely about parsing DT properties correctly.
>
>>> but the original intention of the patch is to try to solve 2 problems.
>>> please refer to https://lkml.org/lkml/2017/3/29/10
>
> One patch should not solve two separate problems anyway. Taking a step
> back, there are at least 3 things that this discussion has brought up:
>
> 1) The way in which we call of_dma_configure() for PCI devices causes
> the "dma-ranges" property on PCI host controllers to be ignored.
>
> 2) of_dma_get_range() only considers the first entry in any "dma-ranges"
> property.
>
> 3) When of_dma_configure() does set a DMA mask, there is nothing on
> arm64 and other architectures to prevent drivers overriding that with a
> wider mask later.
>
> Those are 3 separate problems, to solve with 3 or more separate patches,
> and I have deliberately put the second and third to one side for the
> moment. This patch fixes problem 1.
>
>>> 1) expose generic API for pci world clients to configure their
>>> dma-ranges. right now there is none.
>>> 2) same API can be used by IOMMU to derive dma_mask.
>>>
>>> while the current patch posted to handle dma-ranges for both memory
>>> mapped and pci devices, which I think is overdoing.
>
> No, of_dma_configure() handles the "dma-ranges" property as it is
> defined in the DT spec to describe the mapping between a child bus
> address space and a parent bus address space. Whether those
> memory-mapped parent and child buses are PCI, ISA, AMBA, HyperTransport,
> or anything else is irrelevant other than for the encoding of the
> address specifiers. All this patch does is sort out the cases where we
> have a real device node to start at, from the cases where we don't and
> so start directly at the device's parent bus node instead.
>
>>> besides we have different configuration of dma-ranges based on iommu
>>> is enabled or not enabled.
>
> That doesn't sound right, unless you mean the firmware actually programs
> the host controller's AXI bridge differently for system configurations
> where the IOMMU is expected to be used or not? (and even then, I don't
> really see why it would be necessary to do that...)
>
>>> #define PCIE_DMA_RANGES dma-ranges = <0x43000000 0x00 0x80000000 0x00
>>> 0x80000000 0x00 0x80000000 \
>>> 0x43000000 0x08 0x00000000 0x08
>>> 0x00000000 0x08 0x00000000 \
>>> 0x43000000 0x80 0x00000000 0x80
>>> 0x00000000 0x40 0x00000000>;
>>> Not sure if this patch will consider above dma-ranges.
>>>
>>> my suggestion is to leave existing of_dma_get_range as is, and have
>>> new function for pci world as discussed in
>>> please refer to https://lkml.org/lkml/2017/3/29/10
>
> And then we keep adding new functions to do the exact same thing for
> every other discoverable bus type whose bridge is be described in DT? I
> fail to see how that is in any way better than simply fixing the
> existing code to work as it was intended to.
>
> of_dma_get_ranges() uses of_translate_dma_address() just the same way as
> existing PowerPC PCI code does, which further disproves your assertion
> that parsing PCI addresses is somehow special - it's really only a
> matter of getting the right number of address cells in order to to read
> a child address to give to of_translate_dma_address() in the first
> place. Incidentally, I now notice that the proposed
> of_pci_get_dma_ranges() is incomplete as it doesn't use
> of_translate_dma_address() or otherwise traverse upwards through the
> dma-ranges of any further parent buses.
>
>>>
>>> Regards,
>>> Oza.
>>
>> also I see that, in case of multiple ranges of_dma_get_range doesnt handle that.
>> and also it is not meant to handle.
>
> Yes, the existing code doesn't handle multiple dma-ranges entries,
> because nobody's had the need to implement that so far, and this patch
> does not change that because it's fixing a separate problem.
>
> Now, of course of_dma_get_range() *should* be capable of handling
> multiple entries regardless of this patch, and I'm going to write *that*
> patch right now (it's going to be a case of adding a handful of lines
> which probably won't even conflict with this one at all). If we had a
> bunch of different range parsing functions, we'd then have to duplicate
> the equivalent logic across all of them, which is clearly undesirable
> when it can easily be avoided altogether.
>
> Robin.
>
>> so with this patch will return wrong size and hence wrong dma_mask.
>> having said, I think it is better to separate pci world dma-ranges
>> function on of_pci.c
>>
>> for which my discussion with Rob already, (same thread)
>> https://lkml.org/lkml/2017/3/29/10
>> Waiting for Rob's viewpoint on this.
>>
>>
>> Regards,
>> Oza.
>>
>
first of all the patch
https://lkml.org/lkml/2017/3/30/304
is not only to address the original problem of dma_mask but also to
provide generic APIs
to PCI RC drivers such as pcie-iproc.c or even rcar to get their dma-ranges.
this API not only provides basis to retrieve the ranges but also it
should have capability to handle
inbound memory flags.
having said that the PCI dma-ranges do differ slightly from
traditional memory ranges.
because it has got flags.
now those flags could be IORESOURCE_CACHEABLE or anything else.
our SOC will be having use of these flags in near future (although can
not discuss details as of now).
but in short we will need these flags to be taken care which were
passed form DT.
so PCIe iproc driver calls this function to get all teh information
about dma-ranges.
now if such function exists, other framework could also make use of it
to get resources and figure out dma_mask.
and in that case you really need not change of_dma_get_range.
not only of_dma_get_range can hdnle PCI flags property but also it can
not handle multiple ranges because finally it has only
single *dma_addr, *paddr, *size out parameters.
so the burdon will be on API to fix the behavior as what to return
rather than having Caller to choose what to do with the ranges.
coming back to my current patch
currently it does not do flag handling, but in near future I will have
to add, but for that, this patch
https://lkml.org/lkml/2017/3/30/304
needs to bring under consideration to be ACKed.
hope this explains the need of API.
Regards,
Oza.
--
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 RFC 0/5] *** SPI Slave mode support ***
From: jiada_wang @ 2017-04-13 12:13 UTC (permalink / raw)
To: broonie, robh+dt, mark.rutland, shawnguo, kernel, fabio.estevam
Cc: Jiada Wang, devicetree, linux-kernel, linux-arm-kernel, linux-spi
From: Jiada Wang <jiada_wang@mentor.com>
v1:
add Slave mode support in SPI core
spidev create slave device when SPI controller work in slave mode
spi-imx support to work in slave mode
Jiada Wang (5):
spi: core: add support to work in Slave mode
spi: spidev: use different name for SPI controller slave mode device
spi: imx: add selection for iMX53 and iMX6 controller
ARM: dts: imx: change compatiblity for SPI controllers on imx53 later
soc
spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips
Documentation/devicetree/bindings/spi/spi-bus.txt | 27 ++-
Documentation/spi/spi-summary | 19 +-
arch/arm/boot/dts/imx53.dtsi | 4 +-
arch/arm/boot/dts/imx6q.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 8 +-
arch/arm/boot/dts/imx6sl.dtsi | 8 +-
arch/arm/boot/dts/imx6sx.dtsi | 8 +-
arch/arm/boot/dts/imx6ul.dtsi | 8 +-
drivers/spi/Kconfig | 14 +-
drivers/spi/spi-imx.c | 216 ++++++++++++++++++++--
drivers/spi/spi.c | 23 ++-
drivers/spi/spidev.c | 15 +-
include/linux/spi/spi.h | 15 ++
13 files changed, 310 insertions(+), 57 deletions(-)
--
2.7.4
^ 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