* [PATCH 2/10] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
From: Ziji Hu <huziji@marvell.com>
Export sdhci_start_signal_voltage_switch() from sdhci.c.
Thus vendor sdhci driver can implement its own signal voltage
switch routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 5 +++--
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ea06faf8a437..8e6e4e37e3b4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1832,8 +1832,8 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
spin_unlock_irqrestore(&host->lock, flags);
}
-static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
- struct mmc_ios *ios)
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -1925,6 +1925,7 @@ static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
return 0;
}
}
+EXPORT_SYMBOL_GPL(sdhci_start_signal_voltage_switch);
static int sdhci_card_busy(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 37771de4cafa..cd18b6f19c3b 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -689,6 +689,8 @@ void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 1/10] mmc: sdhci: Export sdhci_set_ios() from sdhci.c
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
From: Ziji Hu <huziji@marvell.com>
Export sdhci_set_ios() in sdhci.c.
Thus vendor sdhci driver can implement its own set_ios() routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 71654b90227f..ea06faf8a437 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1563,7 +1563,7 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
}
EXPORT_SYMBOL_GPL(sdhci_set_uhs_signaling);
-static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
@@ -1723,6 +1723,7 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
mmiowb();
spin_unlock_irqrestore(&host->lock, flags);
}
+EXPORT_SYMBOL_GPL(sdhci_set_ios);
static int sdhci_get_cd(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 766df17fb7eb..37771de4cafa 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -688,6 +688,7 @@ void sdhci_set_power_noreg(struct sdhci_host *host, unsigned char mode,
void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 0/10] mmc: Add support to Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This the second version of the series adding support for the SDHCI
Xenon controller. It can be currently found on the Armada 37xx and the
Armada 7K/8K but will be also used in more Marvell SoC (and not only
the mvebu ones actually).
Some of the remarks had been taking into account since the first
version, according to Ziji Hu, here are the following chcanges:
"Changes in V2:
rebase on v4.9-rc2.
Re-write Xenon bindings. Ajust Xenon DT property naming.
Add a new DT property to indicate eMMC card type, instead of using
variable card_candidate.
Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data
Add support to HS400 retuning."
I think the main open point which remains is about issuing commands
from the ->set_ios() callback (in patch 7).
Ulf, could you comment about it?
Thanks,
Gregory
Gregory CLEMENT (3):
arm64: dts: marvell: add eMMC support for Armada 37xx
arm64: dts: marvell: add sdhci support for Armada 7K/8K
arm64: configs: enable SDHCI driver for Xenon
Ziji Hu (7):
mmc: sdhci: Export sdhci_set_ios() from sdhci.c
mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
dt: bindings: Add bindings for Marvell Xenon SD Host Controller
mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +-
MAINTAINERS | 7 +-
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +-
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 8 +-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 9 +-
arch/arm64/configs/defconfig | 1 +-
drivers/mmc/host/Kconfig | 9 +-
drivers/mmc/host/Makefile | 3 +-
drivers/mmc/host/sdhci-xenon-phy.c | 1181 +++++++-
drivers/mmc/host/sdhci-xenon-phy.h | 157 +-
drivers/mmc/host/sdhci-xenon.c | 598 ++++-
drivers/mmc/host/sdhci-xenon.h | 159 +-
drivers/mmc/host/sdhci.c | 11 +-
drivers/mmc/host/sdhci.h | 4 +-
15 files changed, 2323 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
create mode 100644 drivers/mmc/host/sdhci-xenon-phy.h
create mode 100644 drivers/mmc/host/sdhci-xenon.c
create mode 100644 drivers/mmc/host/sdhci-xenon.h
base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
--
git-series 0.8.10
^ permalink raw reply
* [PATCH v2 1/2] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-10-31 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031105345.16711-1-narmstrong@baylibre.com>
Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
Acked-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 215 ++++++++++++++++++++++
3 files changed, 227 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 3818c5e..6e9fcc3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -69,6 +69,17 @@ config DWMAC_MESON
the stmmac device driver. This driver is used for Meson6,
Meson8, Meson8b and GXBB SoCs.
+config DWMAC_OXNAS
+ tristate "Oxford Semiconductor OXNAS dwmac support"
+ default ARCH_OXNAS
+ depends on OF && COMMON_CLK && (ARCH_OXNAS || COMPILE_TEST)
+ select MFD_SYSCON
+ help
+ Support for Ethernet controller on Oxford Semiconductor OXNAS SoCs.
+
+ This selects the Oxford Semiconductor OXNASSoC glue layer support for
+ the stmmac device driver. This driver is used for OX820.
+
config DWMAC_ROCKCHIP
tristate "Rockchip dwmac support"
default ARCH_ROCKCHIP
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 5d6ece5..8f83a86 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX) += dwmac-lpc18xx.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
+obj-$(CONFIG_DWMAC_OXNAS) += dwmac-oxnas.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
new file mode 100644
index 0000000..de3c36a
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -0,0 +1,215 @@
+/*
+ * Oxford Semiconductor OXNAS DWMAC glue layer
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (C) 2014 Daniel Golle <daniel@makrotopia.org>
+ * Copyright (C) 2013 Ma Haijun <mahaijuns@gmail.com>
+ * Copyright (C) 2012 John Crispin <blogic@openwrt.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.
+ *
+ * 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/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/stmmac.h>
+
+#include "stmmac_platform.h"
+
+/* System Control regmap offsets */
+#define OXNAS_DWMAC_CTRL_REGOFFSET 0x78
+#define OXNAS_DWMAC_DELAY_REGOFFSET 0x100
+
+/* Control Register */
+#define DWMAC_CKEN_RX_IN 14
+#define DWMAC_CKEN_RXN_OUT 13
+#define DWMAC_CKEN_RX_OUT 12
+#define DWMAC_CKEN_TX_IN 10
+#define DWMAC_CKEN_TXN_OUT 9
+#define DWMAC_CKEN_TX_OUT 8
+#define DWMAC_RX_SOURCE 7
+#define DWMAC_TX_SOURCE 6
+#define DWMAC_LOW_TX_SOURCE 4
+#define DWMAC_AUTO_TX_SOURCE 3
+#define DWMAC_RGMII 2
+#define DWMAC_SIMPLE_MUX 1
+#define DWMAC_CKEN_GTX 0
+
+/* Delay register */
+#define DWMAC_TX_VARDELAY_SHIFT 0
+#define DWMAC_TXN_VARDELAY_SHIFT 8
+#define DWMAC_RX_VARDELAY_SHIFT 16
+#define DWMAC_RXN_VARDELAY_SHIFT 24
+#define DWMAC_TX_VARDELAY(d) ((d) << DWMAC_TX_VARDELAY_SHIFT)
+#define DWMAC_TXN_VARDELAY(d) ((d) << DWMAC_TXN_VARDELAY_SHIFT)
+#define DWMAC_RX_VARDELAY(d) ((d) << DWMAC_RX_VARDELAY_SHIFT)
+#define DWMAC_RXN_VARDELAY(d) ((d) << DWMAC_RXN_VARDELAY_SHIFT)
+
+struct oxnas_dwmac {
+ struct device *dev;
+ struct clk *clk;
+ struct regmap *regmap;
+};
+
+static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
+{
+ unsigned int value;
+ int ret;
+
+ /* Reset HW here before changing the glue configuration */
+ ret = device_reset(dwmac->dev);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(dwmac->clk);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, &value);
+ if (ret < 0)
+ return ret;
+
+ /* Enable GMII_GTXCLK to follow GMII_REFCLK, required for gigabit PHY */
+ value |= BIT(DWMAC_CKEN_GTX) |
+ /* Use simple mux for 25/125 Mhz clock switching */
+ BIT(DWMAC_SIMPLE_MUX) |
+ /* set auto switch tx clock source */
+ BIT(DWMAC_AUTO_TX_SOURCE) |
+ /* enable tx & rx vardelay */
+ BIT(DWMAC_CKEN_TX_OUT) |
+ BIT(DWMAC_CKEN_TXN_OUT) |
+ BIT(DWMAC_CKEN_TX_IN) |
+ BIT(DWMAC_CKEN_RX_OUT) |
+ BIT(DWMAC_CKEN_RXN_OUT) |
+ BIT(DWMAC_CKEN_RX_IN);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, value);
+
+ /* set tx & rx vardelay */
+ value = DWMAC_TX_VARDELAY(4) |
+ DWMAC_TXN_VARDELAY(2) |
+ DWMAC_RX_VARDELAY(10) |
+ DWMAC_RXN_VARDELAY(8);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_DELAY_REGOFFSET, value);
+
+ return 0;
+}
+
+static int oxnas_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct device_node *sysctrl;
+ struct oxnas_dwmac *dwmac;
+ int ret;
+
+ sysctrl = of_parse_phandle(pdev->dev.of_node, "oxsemi,sys-ctrl", 0);
+ if (!sysctrl) {
+ dev_err(&pdev->dev, "failed to get sys-ctrl node\n");
+ return -EINVAL;
+ }
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return -ENOMEM;
+
+ dwmac->dev = &pdev->dev;
+ plat_dat->bsp_priv = dwmac;
+
+ dwmac->regmap = syscon_node_to_regmap(sysctrl);
+ if (IS_ERR(dwmac->regmap)) {
+ dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
+ return PTR_ERR(dwmac->regmap);
+ }
+
+ dwmac->clk = devm_clk_get(&pdev->dev, "gmac");
+ if (IS_ERR(dwmac->clk))
+ return PTR_ERR(dwmac->clk);
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_remove(struct platform_device *pdev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(&pdev->dev);
+ int ret = stmmac_dvr_remove(&pdev->dev);
+
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int oxnas_dwmac_suspend(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = stmmac_suspend(dev);
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_resume(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_resume(dev);
+
+ return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(oxnas_dwmac_pm_ops,
+ oxnas_dwmac_suspend, oxnas_dwmac_resume);
+
+static const struct of_device_id oxnas_dwmac_match[] = {
+ { .compatible = "oxsemi,ox820-dwmac" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, oxnas_dwmac_match);
+
+static struct platform_driver oxnas_dwmac_driver = {
+ .probe = oxnas_dwmac_probe,
+ .remove = oxnas_dwmac_remove,
+ .driver = {
+ .name = "oxnas-dwmac",
+ .pm = &oxnas_dwmac_pm_ops,
+ .of_match_table = oxnas_dwmac_match,
+ },
+};
+module_platform_driver(oxnas_dwmac_driver);
+
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_DESCRIPTION("Oxford Semiconductor OXNAS DWMAC glue layer");
+MODULE_LICENSE("GPL v2");
--
2.7.0
^ permalink raw reply related
* [PATCH v2 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Neil Armstrong @ 2016-10-31 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031105345.16711-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
new file mode 100644
index 0000000..df0534e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
@@ -0,0 +1,39 @@
+* Oxford Semiconductor OXNAS DWMAC Ethernet controller
+
+The device inherits all the properties of the dwmac/stmmac devices
+described in the file stmmac.txt in the current directory with the
+following changes.
+
+Required properties on all platforms:
+
+- compatible: For the OX820 SoC, it should be :
+ - "oxsemi,ox820-dwmac" to select glue
+ - "snps,dwmac-3.512" to select IP version.
+
+- clocks: Should contain phandles to the following clocks
+- clock-names: Should contain the following:
+ - "stmmaceth" for the host clock - see stmmac.txt
+ - "gmac" for the peripheral gate clock
+
+- oxsemi,sys-ctrl: a phandle to the system controller syscon node
+
+Example :
+
+etha: ethernet at 40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset RESET_MAC>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+};
--
2.7.0
^ permalink raw reply related
* [PATCH v2 0/2] net: stmmac: Add OXNAS DWMAC Glue
From: Neil Armstrong @ 2016-10-31 10:53 UTC (permalink / raw)
To: linux-arm-kernel
This patchset add support for the Sysnopsys DWMAC Gigabit Ethernet
controller Glue layer of the Oxford Semiconductor OX820 SoC.
Changes since v1 at https://patchwork.kernel.org/patch/9388231/ :
- Split dt-bindings in a separate patch
- Add IP version in the dt-bindings compatible
- Check return of clk_prepare_enable()
- use get_stmmac_bsp_priv() helper
- hardwire setup values in oxnas_dwmac_init()
Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
- Drop init/exit callbacks
- Implement proper remove and PM callback
- Call init from probe
- Disable/Unprepare clock if stmmac probe fails
Neil Armstrong (2):
net: stmmac: Add OXNAS Glue Driver
dt-bindings: net: Add OXNAS DWMAC Bindings
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 215 +++++++++++++++++++++
4 files changed, 266 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
--
2.7.0
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Sekhar Nori @ 2016-10-31 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJX7SjE1zs926Fn-=jsZhPsOK6ey0hHM8LBhNS1nuSuFFQ@mail.gmail.com>
On Monday 31 October 2016 03:24 PM, Bartosz Golaszewski wrote:
> 2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>> Hi Bartosz,
>>
>> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>>> Create the driver for the da8xx master peripheral priority
>>>>> configuration and implement support for writing to the three
>>>>> Master Priority registers on da850 SoCs.
>>>>>
>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>> ---
>>>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>>>> drivers/bus/Kconfig | 9 +
>>>>> drivers/bus/Makefile | 2 +
>>>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>>>> 4 files changed, 297 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> new file mode 100644
>>>>> index 0000000..225af09
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> @@ -0,0 +1,20 @@
>>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>>> + priority driver
>>>>> +
>>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>>> +peripherals classified as masters.
>>>>> +
>>>>> +Documentation:
>>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>>> +
>>>>> +Required properties:
>>>>> +
>>>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>>>
>>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>>> match.
>>>
>>> Hi Rob,
>>>
>>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>>> fixed the example instead.
>>
>> Why are master priority registers under syscon? This driver should be
>> the only entity touching them. So do we need an MFD driver?
>>
>
> It should, but syscfg0 registers are mapped all over the place. I
Not sure what you mean by this. Yes, the sysconfig module has many
functionalities. But the registers for a given functionality are all
grouped together AFAICS (except CHIPCFGn, see below).
Pinmux registers are part of syscfg module, but don't use syscon.
In the work going on for OHCI support, chipcfg registers are being put
under a syscon node. But that makes sense, I think, because chipcfg
registers are catering to really diverse functionality like PLL and EDMA
related stuff being placed in the same register - CHIPCFG0.
> thought it would be safer to put them under syscon and Kevin agreed.
Before using syscon for the whole syscfg space, I think we need some
analysis as to where the likely races are going to be.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-10-31 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7122001.MSFYYEpnBs@wuerfel>
Hi Arnd,
On Sat, Oct 29, 2016 at 11:27 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday, October 22, 2016 9:44:11 AM CEST Geert Uytterhoeven wrote:
>> On Fri, Oct 21, 2016 at 11:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday, October 21, 2016 8:16:00 PM CEST Geert Uytterhoeven wrote:
>> >> On Wed, Oct 19, 2016 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > On Wednesday, October 19, 2016 10:02:57 AM CEST Geert Uytterhoeven wrote:
>> >> >> On Mon, Oct 10, 2016 at 4:23 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > I'd prefer seeing a separate soc driver for that one.
>> >> >> Some SoCs have only CCCR, others have only PRR, some have both.
>> >> >> On some SoCs one of them can be accessed from the RealTime CPU
>> >> >> core (SH) only.
>> >> >> On some SoCs the register is not documented, but present.
>> >> >> If the PRR exists, it's a better choice, as it contains additional information
>> >> >> in the high order bits (representing the presence of each big (CA15/CA57),
>> >> >> little (CA7/CA53), and RT (CR7) CPU core). Currently we don't use that
>> >> >> information, though.
>> >> >>
>> >> >> Grouping them in some other way means we would loose the family name,
>> >> >> which is exposed through soc_dev_attr->family.
>> >> >> The usefulness of family names is debatable though, as this is more an
>> >> >> issue of marketing business.
>> >> >
>> >> > How about having a table to look up the family name by the value
>> >> > of the PRR or CCCR then?
>> >>
>> >> Unfortunately there exist SoCs from different families using the same
>> >> product ID.
>> >>
>> >> And different SoCs from the same family may have a revision register
>> >> or not (e.g. R-Car H1 has, M1A hasn't).
>> >
>> > Is this something we expect to see more of in the future, or can
>> > we expect future chips to handle this more consistently?
>>
>> I expect to see more of these in the future.
>>
>> Perhaps I just should forget about the product IDs and (marketing) families,
>> and just stick the CCCR/PRR addresses in the of_device_ids?
>> Then we'll have SoC names (e.g. "r8a7791") and (optional) revisions
>> (e.g. "ES1.0") to match on.
>
> I don't think listing the marketing names is a problem if we need a
> full list of all chips in of_device_ids anyway.
I'm removing the marketing names. We don't match them anyway (and probably
shouldn't, as we don't control them anyway, cfr.
https://www.renesas.com/en-us/solutions/automotive/products.html).
> I'm still hoping to be able to limit the need for specifying the
> register addresses in the driver instead.
Adding DT binding...
>> >> > How about this:
>> >> >
>> >> > The driver could report the hardcoded strings for the SoCs it already
>> >> > knows about (you have the table anyway) and not report the revision
>> >> > unless there is a regmap containing the CCCR or the PRR, in which
>> >> > case you use that. Future SoCs will provide the PRR (I assume
>> >> > CCCR is only used on the older ones) through a syscon regmap
>> >> > that we can use to find out the exact revision as well.
>> >> >
>> >> > The existing DT files can gain the syscon device so you can report
>> >> > the revision on those machines as well, unless you use an old DTB.
>> >>
>> >> Hmm... That means that if we have to add a driver quirk to distinguish
>> >> between different revisions of the same SoC, we have to update the
>> >> DTB anyway, to add the CCCR/PRR device node.
>> >> We might as well just change the compatible value in that DTB for the
>> >> device that needs the quirk. Which is what we'd like to avoid in the
>> >> first place.
>> >
>> > Do you have a specific example in mind? If this is only a theoretical
>> > problem, we can worry about it when we get there, and then decide
>> > if we add a hardcoded register after all.
>>
>> For R-Car H3, there are small differences between ES1.0 and ES1.1,
>> and more and larger differences between ES1.x and ES2.0, which
>> need different handling (patches already floating around).
>>
>> For (old) R-Car H1, the SATA driver already handles "renesas,sata-r8a7790-es1",
>> but so far there didn't exist an established process to specify how that
>> compatible value would end up in the DTB (the in-kernel DTS doesn't have it).
>>
>> There may be more differences I'm not aware of.
>
> Ok, so for R-Car H1, I assume we don't need the driver, it would just
> be a way to replace the current workaround with a different one, right?
>
> For R-Car H3, do we just require driver changes to work with ES2.0,
> or also DT changes? If the new chip version already implies a new DT,
> we can require the presence of a device node that has the correct
> register number.
H3 also needs DT changes for some features (e.g. different number of USB
channels, different topology for graphics).
soc_device_match() would mostly (only?) be used to handle limitations and
quirks in early revisions. These are intended to be removed once production
has been ramped up, and there's no longer a need to support them.
However, that also means soc_device_match() would be used to match against
early revisions, not against late revisions. I.e. the early SoCs need the chip
ID registers declared, not the new ones.
Stay tuned for v2...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-10-31 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFvLkMQGVygLb9SQ8o+2Q=bg7vvRjpHypmSyjRyLkdcHypoFHw@mail.gmail.com>
On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
<radoslaw.pietrzyk@gmail.com> wrote:
> Have you defined your sdio node within soc node ?
It is in the SOC node of the DSTI file.
>
> 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com>:
>>
>> Hi Alex,
>>
>> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>> <alexandre.torgue@st.com> wrote:
>> > Hi Bruno,
>> >
>> >
>> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>> >>
>> >> Hi Alex,
>> >>
>> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>> >> <alexandre.torgue@st.com> wrote:
>> >>>
>> >>> Hi Bruno,
>> >>>
>> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>> >>>>
>> >>>>
>> >>>> Hi Alexandre,
>> >>>>
>> >>>>>
>> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM start address
>> >>>>> remapping
>> >>>>> (to @0) to boost performances. A DMA translation through
>> >>>>> "dma-ranges"
>> >>>>> property was needed for other masters than the M4 CPU.
>> >>>>> stm32f429-disco doesn't use remapping so doesn't need this DMA
>> >>>>> translation.
>> >>>>> This patches moves this DMA translation definition from stm32f429
>> >>>>> soc
>> >>>>> file
>> >>>>> to board files.
>> >>>>>
>> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>> >>>>>
>> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> index 13c7cd2..a763c15 100644
>> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> @@ -82,6 +82,10 @@
>> >>>>> };
>> >>>>> };
>> >>>>>
>> >>>>> + soc {
>> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>> + };
>> >>>>> +
>> >>>>> usbotg_hs_phy: usbphy {
>> >>>>> #phy-cells = <0>;
>> >>>>> compatible = "usb-nop-xceiv";
>> >>>>
>> >>>>
>> >>>>
>> >>>> Shouldn't also the peripheral dma-ranges property move to board
>> >>>> specific
>> >>>> too?
>> >>>> I had this patch for while but I didn't had the time to submit:
>> >>>
>> >>>
>> >>>
>> >>> Well spot I forgot it. Actually, discussing with Arnd ysterday on
>> >>> IIRC,
>> >>> empty dma-ranges is not needed. Can you test on your side by removing
>> >>> dma-ranges in usb node please ?
>> >>
>> >> Unfortunately will take a time for me to set up this environment on
>> >> the STM32F4-EVAL board.
>> >> And on the discovery boards we dont have this scenario. That was the
>> >> main reason I did not submit the patch right away.
>> >> My conclusion and I might be wrong but is based on the my tests with
>> >> SDIO device at STM32F469I-DISCO board.
>> >>
>> >> I started this issue as discussion at ST Forum but Maxime gave me the
>> >> hint.
>> >>
>> >>
>> >>
>> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>> >>
>> >>> I will push a v2 by removing empty dma-ranges if tests are ok in your
>> >>> side.
>> >>
>> >>
>> >> From my understating/conclusion is: when empty property(dma-ranges) is
>> >> the device node, the mapping will be taken in consideration when using
>> >> DMA otherwise the mapping is ignored.
>> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>> >> MEM(SDRAM)->DEV. If it is not the case for the devices in question so
>> >> I suppose it can work without the property.
>> >
>> >
>> > For sure translation has to be done but I'm not sure that an empty
>> > "dma-ranges" is needed in device node to activate it. For Ethernet empty
>> > "dma-ranges" is not needed. I will try with usb.
>>
>> In the case of SDIO it is needed. As example this is my working SDIO node:
>>
>> sdio: sdio at 40012c00 {
>> compatible = "arm,pl18x", "arm,primecell";
>> arm,primecell-periphid = <0x00480181>;
>> reg = <0x40012c00 0x400>;
>> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>> dma-names = "rx", "tx";
>> clocks = <&rcc 0 171>;
>> clock-names = "apb_pclk";
>> interrupts = <49>;
>> status = "disabled";
>> };
>>
>> &sdio {
>> status = "okay";
>> vmmc-supply = <&wlan_en>;
>> bus-width = <4>;
>> max-frequency = <24000000>;
>> pinctrl-names = "default";
>> pinctrl-0 = <&sdio_pins>;
>> ti,non-removable;
>> ti,needs-special-hs-handling;
>> dma-ranges;
>> cap-power-off-card;
>> keep-power-in-suspend;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>> wlcore: wlcore at 0 {
>> compatible = "ti,wl1835";
>> reg = <2>;
>> interrupt-parent = <&gpioa>;
>> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>> };
>> };
>>
>> >
>> > alex
>> >
>> >
>> >>
>> >>>
>> >>> Thanks in advance
>> >>> Alex
>> >>>
>> >>>
>> >>>>
>> >>>> Author: Bruno Herrera <bruherrera@gmail.com>
>> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>> >>>>
>> >>>> ARM: DT: STM32: Use dma-ranges property per board not at dtsi
>> >>>> file
>> >>>>
>> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> index 6bfc595..2a22a82 100644
>> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> @@ -52,6 +52,10 @@
>> >>>> model = "STMicroelectronics STM32429i-EVAL board";
>> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
>> >>>>
>> >>>> + soc {
>> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
>> >>>> + };
>> >>>> +
>> >>>> chosen {
>> >>>> bootargs = "root=/dev/ram rdinit=/linuxrc";
>> >>>> stdout-path = "serial0:115200n8";
>> >>>> @@ -96,6 +100,7 @@
>> >>>>
>> >>>> ðernet0 {
>> >>>> status = "okay";
>> >>>> + dma-ranges;
>> >>>> pinctrl-0 = <ðernet0_mii>;
>> >>>> pinctrl-names = "default";
>> >>>> phy-mode = "mii-id";
>> >>>> @@ -116,6 +121,7 @@
>> >>>> };
>> >>>>
>> >>>> &usbotg_hs {
>> >>>> + dma-ranges;
>> >>>> dr_mode = "host";
>> >>>> phys = <&usbotg_hs_phy>;
>> >>>> phy-names = "usb2-phy";
>> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> index 7d624a2..697a133 100644
>> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> @@ -59,7 +59,6 @@
>> >>>> };
>> >>>>
>> >>>> soc {
>> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>
>> >>>> timer2: timer at 40000000 {
>> >>>> compatible = "st,stm32-timer";
>> >>>> @@ -472,13 +471,11 @@
>> >>>> st,syscon = <&syscfg 0x4>;
>> >>>> snps,pbl = <8>;
>> >>>> snps,mixed-burst;
>> >>>> - dma-ranges;
>> >>>> status = "disabled";
>> >>>> };
>> >>>>
>> >>>> usbotg_hs: usb at 40040000 {
>> >>>> compatible = "snps,dwc2";
>> >>>> - dma-ranges;
>> >>>> reg = <0x40040000 0x40000>;
>> >>>> interrupts = <77>;
>> >>>> clocks = <&rcc 0 29>;
>> >>>>
>> >>>>
>> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> index 0596d60..3a1cfdd 100644
>> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> @@ -59,8 +59,6 @@
>> >>>>> };
>> >>>>>
>> >>>>> soc {
>> >>>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>> -
>> >>>>> timer2: timer at 40000000 {
>> >>>>> compatible = "st,stm32-timer";
>> >>>>> reg = <0x40000000 0x400>;
>> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> index 9e73656..c2213c0 100644
>> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> @@ -64,6 +64,10 @@
>> >>>>> aliases {
>> >>>>> serial0 = &usart3;
>> >>>>> };
>> >>>>> +
>> >>>>> + soc {
>> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>> + };
>> >>>>> };
>> >>>>>
>> >>>>> &clk_hse {
>> >>>>> --
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> Br.,
>> >>>> Bruno
>> >>>>
>> >>>
>> >
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-10-31 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9Vxy+boEPV3pvRCAWAWh-Tie31oS0PG7F6ix5_Wf=JHxgg@mail.gmail.com>
On 10/31/2016 11:20 AM, Joachim Eastwood wrote:
> Hi Neil,
>
> On 31 October 2016 at 10:55, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 10/30/2016 09:41 PM, Rob Herring wrote:
>>> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>>>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>>>
>>> It's preferred that bindings are a separate patch.
>>
>> OK
>>
>>>
>>>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>>>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>>>> 4 files changed, 275 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>>>
>>>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>>>> - Drop init/exit callbacks
>>>> - Implement proper remove and PM callback
>>>> - Call init from probe
>>>> - Disable/Unprepare clock if stmmac probe fails
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>>> new file mode 100644
>>>> index 0000000..5d2696c
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>>> @@ -0,0 +1,44 @@
>>>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>>>> +
>>>> +The device inherits all the properties of the dwmac/stmmac devices
>>>> +described in the file stmmac.txt in the current directory with the
>>>> +following changes.
>>>> +
>>>> +Required properties on all platforms:
>>>> +
>>>> +- compatible: Depending on the platform this should be one of:
>>>> + - "oxsemi,ox820-dwmac"
>>>> + Additionally "snps,dwmac" and any applicable more
>>>> + detailed version number described in net/stmmac.txt
>>>> + should be used.
>>>
>>> You should be explicit what version applies to ox820. "snps,dwmac"
>>> should probably be deprecated IMO. There are so many variations of DW
>>> h/w.
>>
>> Well, to be honest I have absolutely no idea ! But I will try to find out...
>
> You can see in the boot log:
>
> From lpc18xx boot:
> [ 3.242253] stmmac - user ID: 0x11, Synopsys ID: 0x36
> [ 3.247653] Ring mode enabled
> [ 3.251491] DMA HW capability register supported
> [ 3.256336] Enhanced/Alternate descriptors
> [ 3.261537] Enabled extended descriptors
> [ 3.265968] RX Checksum Offload Engine supported (type 2)
> [ 3.272249] TX Checksum insertion supported
> [ 3.276874] Wake-Up On Lan supported
> [ 3.283743] Enable RX Mitigation via HW Watchdog Timer
> [ 3.326701] libphy: stmmac: probed
>
> Synopsys ID: 0x36 and user UD: 0x11, gives us DWMAC version 3.611
>
>
> regards,
> Joachim Eastwood
>
OK, thanks !
stmmac - user ID: 0x12, Synopsys ID: 0x35
Neil
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Joachim Eastwood @ 2016-10-31 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04b8ed79-8efa-cc10-a9a3-fdee10e0723c@baylibre.com>
Hi Neil,
On 31 October 2016 at 10:55, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 10/30/2016 09:41 PM, Rob Herring wrote:
>> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>>
>> It's preferred that bindings are a separate patch.
>
> OK
>
>>
>>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>>> 4 files changed, 275 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>>
>>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>>> - Drop init/exit callbacks
>>> - Implement proper remove and PM callback
>>> - Call init from probe
>>> - Disable/Unprepare clock if stmmac probe fails
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> new file mode 100644
>>> index 0000000..5d2696c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> @@ -0,0 +1,44 @@
>>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>>> +
>>> +The device inherits all the properties of the dwmac/stmmac devices
>>> +described in the file stmmac.txt in the current directory with the
>>> +following changes.
>>> +
>>> +Required properties on all platforms:
>>> +
>>> +- compatible: Depending on the platform this should be one of:
>>> + - "oxsemi,ox820-dwmac"
>>> + Additionally "snps,dwmac" and any applicable more
>>> + detailed version number described in net/stmmac.txt
>>> + should be used.
>>
>> You should be explicit what version applies to ox820. "snps,dwmac"
>> should probably be deprecated IMO. There are so many variations of DW
>> h/w.
>
> Well, to be honest I have absolutely no idea ! But I will try to find out...
You can see in the boot log:
>From lpc18xx boot:
[ 3.242253] stmmac - user ID: 0x11, Synopsys ID: 0x36
[ 3.247653] Ring mode enabled
[ 3.251491] DMA HW capability register supported
[ 3.256336] Enhanced/Alternate descriptors
[ 3.261537] Enabled extended descriptors
[ 3.265968] RX Checksum Offload Engine supported (type 2)
[ 3.272249] TX Checksum insertion supported
[ 3.276874] Wake-Up On Lan supported
[ 3.283743] Enable RX Mitigation via HW Watchdog Timer
[ 3.326701] libphy: stmmac: probed
Synopsys ID: 0x36 and user UD: 0x11, gives us DWMAC version 3.611
regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH] ARM: davinci: da850: Fix pwm name matching
From: Sekhar Nori @ 2016-10-31 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418044-24603-1-git-send-email-david@lechnology.com>
On Tuesday 25 October 2016 11:24 PM, David Lechner wrote:
> This fixes pwm name matching for DA850 familiy devices. When using device
> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
> same name, which caused errors when trying to register the devices.
>
> The names for clock matching in da850_clks[] also have to be updated to
> to exactly match in order for the clock lookup to work correctly.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> Tested working on LEGO MINDSTORMS EV3.
>
>
> arch/arm/mach-davinci/da850.c | 10 +++++++---
> arch/arm/mach-davinci/da8xx-dt.c | 10 +++++-----
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index ed3d0e9..6b78a8f 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -510,9 +510,13 @@ static struct clk_lookup da850_clks[] = {
> CLK("vpif", NULL, &vpif_clk),
> CLK("ahci_da850", NULL, &sata_clk),
> CLK("davinci-rproc.0", NULL, &dsp_clk),
> - CLK("ehrpwm", "fck", &ehrpwm_clk),
> - CLK("ehrpwm", "tbclk", &ehrpwm_tbclk),
> - CLK("ecap", "fck", &ecap_clk),
> + CLK("ehrpwm.0", "fck", &ehrpwm_clk),
> + CLK("ehrpwm.0", "tbclk", &ehrpwm_tbclk),
> + CLK("ehrpwm.1", "fck", &ehrpwm_clk),
> + CLK("ehrpwm.1", "tbclk", &ehrpwm_tbclk),
> + CLK("ecap.0", "fck", &ecap_clk),
> + CLK("ecap.1", "fck", &ecap_clk),
> + CLK("ecap.2", "fck", &ecap_clk),
This has exposed a limitation of DaVinci clock framework. The struct clk
are stored as a linked list themselves. So a node repeating in the table
above will create a loop in the linked list. This is easily seen on the
LCDK board. davinci_clk_disable_unused() never returns. PWMs are unused
on that board.
There is no "simple" solution to this AFAICS. One solution is to
separate the iterator from the clock hardware structure and use struct
clk_hw available in struct clk_lookup.
Or move DaVinci to common clock framework. This is of course preferred
but much more involved as all 6 supported SoCs have to be moved together.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH V4 10/10] arm64: KVM: add guest SEA support
From: Russell King - ARM Linux @ 2016-10-31 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477071013-29563-11-git-send-email-tbaicar@codeaurora.org>
The subject line on this patch is misleading - it's not only ARM64
specific...
On Fri, Oct 21, 2016 at 11:30:13AM -0600, Tyler Baicar wrote:
> diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
> index a3d61ad..86e1faa 100644
> --- a/arch/arm/include/asm/system_misc.h
> +++ b/arch/arm/include/asm/system_misc.h
> @@ -24,4 +24,9 @@ extern unsigned int user_debug;
>
> #endif /* !__ASSEMBLY__ */
>
> +inline int handle_guest_sea(unsigned long addr, unsigned int esr)
This needs to be static.
> +{
> + return -1;
> +}
> +
> #endif /* __ASM_ARM_SYSTEM_MISC_H */
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings
From: Neil Armstrong @ 2016-10-31 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021151037.20112-1-narmstrong@baylibre.com>
On 10/21/2016 05:10 PM, Neil Armstrong wrote:
> This patchset updates the ARM DTS for the Oxnas platform by :
> - Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
> - Update the OX810SE to use the dt-bindings includes files introduced in [1] and [2]
> - Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance
>
> This patchset depends on dt-bindings include headers posted at [1] and [2],
> that were accepted/merged in the subsystem trees.
>
> How could I manage this dependency for 4.10 ?
>
> [1] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00008.html
> [2] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00007.html
>
> Neil Armstrong (3):
> ARM: dts: Add support for OX820 and Pogoplug V3
> ARM: dts: OX810: Update with dt-bindings includes
> MAINTAINERS: oxnas: Add new files definitions
>
> Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
> MAINTAINERS | 3 +-
> arch/arm/boot/dts/Makefile | 3 +-
> .../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
> arch/arm/boot/dts/ox810se.dtsi | 10 +-
> arch/arm/boot/dts/ox820.dtsi | 298 +++++++++++++++++++++
> 6 files changed, 407 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
> create mode 100644 arch/arm/boot/dts/ox820.dtsi
>
Hi,
I'm ready to send a pull request for arm-soc-dt, but I need to understand how this dependency
should be worked out.
Should this be sent as a late pull request ?
Thanks,
Neil
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-10-31 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030204110.otvjlanmi7dv7fox@rob-hp-laptop>
On 10/30/2016 09:41 PM, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>
> It's preferred that bindings are a separate patch.
OK
>
>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>> 4 files changed, 275 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>
>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>> - Drop init/exit callbacks
>> - Implement proper remove and PM callback
>> - Call init from probe
>> - Disable/Unprepare clock if stmmac probe fails
>>
>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> new file mode 100644
>> index 0000000..5d2696c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> @@ -0,0 +1,44 @@
>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>> +
>> +The device inherits all the properties of the dwmac/stmmac devices
>> +described in the file stmmac.txt in the current directory with the
>> +following changes.
>> +
>> +Required properties on all platforms:
>> +
>> +- compatible: Depending on the platform this should be one of:
>> + - "oxsemi,ox820-dwmac"
>> + Additionally "snps,dwmac" and any applicable more
>> + detailed version number described in net/stmmac.txt
>> + should be used.
>
> You should be explicit what version applies to ox820. "snps,dwmac"
> should probably be deprecated IMO. There are so many variations of DW
> h/w.
Well, to be honest I have absolutely no idea ! But I will try to find out...
>
>> +
>> +- reg: The first register range should be the one of the DWMAC
>> + controller.
>
> This is worded like there's a 2nd range?
OK, will rephrase.
>
>> +
>> +- clocks: Should contain phandles to the following clocks
>> +- clock-names: Should contain the following:
>> + - "stmmaceth" - see stmmac.txt
>> + - "gmac" - peripheral gate clock
>> +
>> +- oxsemi,sys-ctrl: a phandle to the system controller syscon node
>> +
>> +Example :
>> +
>> +etha: ethernet at 40400000 {
>> + compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
>> + reg = <0x40400000 0x2000>;
>> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "macirq", "eth_wake_irq";
>> + mac-address = [000000000000]; /* Filled in by U-Boot */
>> + phy-mode = "rgmii";
>> +
>> + clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
>> + clock-names = "gmac", "stmmaceth";
>> + resets = <&reset RESET_MAC>;
>> +
>> + /* Regmap for sys registers */
>> + oxsemi,sys-ctrl = <&sys>;
>> +
>> + status = "disabled";
>> +};
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Bartosz Golaszewski @ 2016-10-31 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0cac724d-1aee-dfa7-9b78-8366fd6fceff@ti.com>
2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> Hi Bartosz,
>
> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>> Create the driver for the da8xx master peripheral priority
>>>> configuration and implement support for writing to the three
>>>> Master Priority registers on da850 SoCs.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>>> drivers/bus/Kconfig | 9 +
>>>> drivers/bus/Makefile | 2 +
>>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>>> 4 files changed, 297 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>> new file mode 100644
>>>> index 0000000..225af09
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>> @@ -0,0 +1,20 @@
>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>> + priority driver
>>>> +
>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>> +peripherals classified as masters.
>>>> +
>>>> +Documentation:
>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>>
>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>> match.
>>
>> Hi Rob,
>>
>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>> fixed the example instead.
>
> Why are master priority registers under syscon? This driver should be
> the only entity touching them. So do we need an MFD driver?
>
It should, but syscfg0 registers are mapped all over the place. I
thought it would be safer to put them under syscon and Kevin agreed.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [GIT PULL] ARM: OXNAS SoC updates for 4.10
From: Neil Armstrong @ 2016-10-31 9:52 UTC (permalink / raw)
To: linux-arm-kernel
Dear arm-soc maintainers,
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/OXNAS/linux.git tags/oxnas-arm-soc-for-4.10
for you to fetch changes up to b3cdb3c5ef514687891f03442f2677850340bcfa:
ARM: oxnas: Add OX820 config and makefile entry (2016-10-31 10:41:33 +0100)
----------------------------------------------------------------
- Add SMP support for the Oxford Semiconductor OX820 SoC
from http://lkml.kernel.org/r/20161021085848.1754-1-narmstrong at baylibre.com
----------------------------------------------------------------
Neil Armstrong (2):
ARM: oxnas: Add OX820 SMP support
ARM: oxnas: Add OX820 config and makefile entry
arch/arm/Makefile | 1 +
arch/arm/mach-oxnas/Kconfig | 30 +++++++++++++++++++---------
arch/arm/mach-oxnas/Makefile | 2 ++
arch/arm/mach-oxnas/headsmp.S | 28 ++++++++++++++++++++++++++
arch/arm/mach-oxnas/hotplug.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-oxnas/platsmp.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 267 insertions(+), 9 deletions(-)
create mode 100644 arch/arm/mach-oxnas/Makefile
create mode 100644 arch/arm/mach-oxnas/headsmp.S
create mode 100644 arch/arm/mach-oxnas/hotplug.c
create mode 100644 arch/arm/mach-oxnas/platsmp.c
Thanks,
Neil
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Sekhar Nori @ 2016-10-31 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJW85TQObLdoGW2ApnkM8OiM4d1ZDd=9eyGmeVXXwqByPQ@mail.gmail.com>
Hi Bartosz,
On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>> Create the driver for the da8xx master peripheral priority
>>> configuration and implement support for writing to the three
>>> Master Priority registers on da850 SoCs.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>> ---
>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>> drivers/bus/Kconfig | 9 +
>>> drivers/bus/Makefile | 2 +
>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>> 4 files changed, 297 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>> new file mode 100644
>>> index 0000000..225af09
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>> @@ -0,0 +1,20 @@
>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>> + priority driver
>>> +
>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>> +peripherals classified as masters.
>>> +
>>> +Documentation:
>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>> +
>>> +Required properties:
>>> +
>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>
>> Drop syscon. Doesn't look like it is needed and the example doesn't
>> match.
>
> Hi Rob,
>
> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
> fixed the example instead.
Why are master priority registers under syscon? This driver should be
the only entity touching them. So do we need an MFD driver?
Thanks,
Sekhar
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Neil Armstrong @ 2016-10-31 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ5VG2NGRh5CmYcYzwCp0LYSsgxHogCFa+6W7BDDBXOYg@mail.gmail.com>
On 10/24/2016 03:03 AM, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Add support for the Amlogic Meson GXL SoC, this is a partially complete
>> definition only based on the Amlogic Vendor tree.
>>
>> This definition differs a lot from the GXBB and needs a separate entry.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Looks good to me. Tell me when I may apply it, it looks orthogonal
> to the rest of the patches.
>
> Yours,
> Linus Walleij
>
Hi Linus,
I'm ok to have it applied as soon as possible, but I can send a clean non-rfc patch if needed.
Thanks,
Neil
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Bartosz Golaszewski @ 2016-10-31 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031043015.74ppaship5nqfaqt@rob-hp-laptop>
2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>> Create the driver for the da8xx master peripheral priority
>> configuration and implement support for writing to the three
>> Master Priority registers on da850 SoCs.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>> drivers/bus/Kconfig | 9 +
>> drivers/bus/Makefile | 2 +
>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>> 4 files changed, 297 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>
>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>> new file mode 100644
>> index 0000000..225af09
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>> @@ -0,0 +1,20 @@
>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>> + priority driver
>> +
>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>> +peripherals classified as masters.
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>
> Drop syscon. Doesn't look like it is needed and the example doesn't
> match.
Hi Rob,
it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
fixed the example instead.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [v15, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-10-31 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3386858.dvuMhvkN3m@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, October 28, 2016 6:54 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Jochen Friedrich; Claudiu Manoil;
> devicetree at vger.kernel.org; Rob Herring; Santosh Shilimkar;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org; Leo Li;
> iommu at lists.linux-foundation.org; Kumar Gala; linuxppc-
> dev at lists.ozlabs.org
> Subject: Re: [v15, 0/7] Fix eSDHC host version register bug
>
> On Friday, October 28, 2016 2:50:11 PM CEST Yangbo Lu wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and
> > revision, 10 previous version patchsets had tried many methods but all
> of them were rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method Anrd suggested a
> > soc_device_match method in v10, and this is the only available method
> > left now. This v11 patchset introduces the soc_device_match interface
> > in soc driver.
> >
> > The first five patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
>
> Looks good overall. With patch 3 dropped (or an explanation why it's
> still needed), everything
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
[Lu Yangbo-B47093] Thank you very much:) See my explaination in patch 3 email.
> Arnd
^ permalink raw reply
* [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Y.B. Lu @ 2016-10-31 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2723366.1bJeJ7SKI6@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, October 28, 2016 6:53 PM
> To: linuxppc-dev at lists.ozlabs.org
> Cc: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree at vger.kernel.org;
> Rob Herring; Santosh Shilimkar; linux-arm-kernel at lists.infradead.org;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org; Leo Li;
> iommu at lists.linux-foundation.org; Kumar Gala
> Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
>
> On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote:
> > Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
> > header file. This SVR numberspace is used on some ARM chips as well
> > as PPC, and even to check for a PPC SVR multi-arch drivers would
> > otherwise need to ifdef the header inclusion and all references to the
> SVR symbols.
> >
> >
>
> I don't see any of the contents of this header referenced by the soc
> driver any more. I think you can just drop this patch.
>
[Lu Yangbo-B47093] This header file was included by guts.c.
The guts driver used macro SVR_MAJ/SVR_MIN for calculation.
This header file was for powerpc arch before. And this patch is to made it as common header file for both ARM and PPC.
Sooner or later this is needed.
> Arnd
^ permalink raw reply
* [PATCH v6 2/2] iio: adc: add support for Allwinner SoCs ADC
From: Quentin Schulz @ 2016-10-31 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65ee4ea1-68bf-e516-5ba6-16b06ff7fd8c@kernel.org>
Hi Jonathan and Lee,
On 30/10/2016 17:59, Jonathan Cameron wrote:
> On 15/09/16 13:44, Quentin Schulz wrote:
>> The Allwinner SoCs all have an ADC that can also act as a touchscreen
>> controller and a thermal sensor. This patch adds the ADC driver which is
>> based on the MFD for the same SoCs ADC.
>>
>> This also registers the thermal adc channel in the iio map array so
>> iio_hwmon could use it without modifying the Device Tree. This registers
>> the driver in the thermal framework.
>>
>> This driver probes on three different platform_device_id to take into
>> account slight differences (registers bit and temperature computation)
>> between Allwinner SoCs ADCs.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> Acked-by: Jonathan Cameron <jic23@kernel.org>
> Hi Lee,
>
> As you applied the MFD part of this series, could you pick this up as well?
>
Someone reported some bugs on the CHIP (sun5i-r8). I'm investigating that.
Also, it misses a scale for voltage (not that critical but still).
And also, Thomas Petazzoni just found a deadlock in sun4i_gpadc_read. If
a regmap_write fails after getting the mutex, it is never released.
Is there some sort of deadline you want for a v7 since the mfd patch has
been merged?
Thanks,
Quentin
> Thanks,
>
> Jonathan
>> ---
>>
>> v6:
>> - remove useless member (regs) from sun4i_gpadc_dev structure,
>> - rename sun4i_gpadc_dev structure to sun4i_gpadc_iio,
>> - remove regmap_update_bits used to disable hardware interrupts, it is already
>> handled by devm functions,
>>
>> v5:
>> - correct mail address,
>> - correct several typos,
>> - move from const to static for sunxi_gpadc_chan_select functions,
>> - rename soc_specific struct to gpadc_data,
>> - rename soc_specific field to data in sun4i_gpadc_dev,
>> - return error code from regmap_write in case of failure in read_raws,
>> - share if condition in IIO_CHAN_INFO_RAW case,
>> - add comment on why we use parent device for registering in thermal,
>> - reordering remove function,
>>
>> v4:
>> - rename files and variables from sunxi* to sun4i*,
>> - shorten sunxi_gpadc_soc_specific structure to soc_specific,
>> - factorize sysfs ADC and temp read_raws,
>> - use cached values when read_raw times out (except before a first value
>> is gotten),
>> - remove mutex locks and unlocks from runtime_pm functions,
>> - factorize irq initializations,
>> - initialize temp_data and fifo_data values to -1 (error value),
>> - "impersonate" MFD to register in thermal framework,
>> - deactivate hardware interrupts one by one when probe fails or when
>> removing driver instead of blindly deactivating all hardware interrupts,
>> - selects THERMAL_OF in Kconfig,
>>
>> v3:
>> - correct wrapping,
>> - add comment about thermal sensor inner working,
>> - move defines in mfd header,
>> - use structure to define SoC specific registers or behaviour,
>> - attach this structure to the device according to of_device_id of the
>> platform device,
>> - use new mutex instead of iio_dev mutex,
>> - use atomic flags to avoid race between request_irq and disable_irq in
>> probe,
>> - switch from processed value to raw, offset and scale values for
>> temperature ADC channel,
>> - remove faulty sentinel in iio_chan_spec array,
>> - add pm_runtime support,
>> - register thermal sensor in thermal framework (forgotten since the
>> beginning whereas it is present in current sun4i-ts driver),
>> - remove useless ret variables to store return value of regmap_reads,
>> - move comments on thermal sensor acquisition period in code instead of
>> header,
>> - adding goto label to unregister iio_map_array when failing to register
>> iio_dev,
>>
>> v2:
>> - add SUNXI_GPADC_ prefixes for defines,
>> - correct typo in Kconfig,
>> - reorder alphabetically includes, makefile,
>> - add license header,
>> - fix architecture variations not being handled in interrupt handlers or
>> read raw functions,
>> - fix unability to return negative values from thermal sensor,
>> - add gotos to reduce code repetition,
>> - fix irq variable being unsigned int instead of int,
>> - remove useless dev_err and dev_info,
>> - deactivate all interrupts if probe fails,
>> - fix iio_device_register on NULL variable,
>> - deactivate ADC in the IP when probe fails or when removing driver,
>>
>> drivers/iio/adc/Kconfig | 13 +
>> drivers/iio/adc/Makefile | 1 +
>> drivers/iio/adc/sun4i-gpadc-iio.c | 522 ++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 536 insertions(+)
>> create mode 100644 drivers/iio/adc/sun4i-gpadc-iio.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 25378c5..ea36a4f 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -384,6 +384,19 @@ config ROCKCHIP_SARADC
>> To compile this driver as a module, choose M here: the
>> module will be called rockchip_saradc.
>>
>> +config SUN4I_GPADC
>> + tristate "Support for the Allwinner SoCs GPADC"
>> + depends on IIO
>> + depends on MFD_SUN4I_GPADC
>> + select THERMAL_OF
>> + help
>> + Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
>> + GPADC. This ADC provides 4 channels which can be used as an ADC or as
>> + a touchscreen input and one channel for thermal sensor.
>> +
>> + To compile this driver as a module, choose M here: the module will be
>> + called sun4i-gpadc-iio.
>> +
>> config TI_ADC081C
>> tristate "Texas Instruments ADC081C/ADC101C/ADC121C family"
>> depends on I2C
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 38638d4..204372d 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -37,6 +37,7 @@ obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> +obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>> obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>> obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
>> new file mode 100644
>> index 0000000..e2c5ba8
>> --- /dev/null
>> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
>> @@ -0,0 +1,522 @@
>> +/* ADC driver for sunxi platforms' (A10, A13 and A31) GPADC
>> + *
>> + * Copyright (c) 2016 Quentin Schulz <quentin.schulz@free-electrons.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it under
>> + * the terms of the GNU General Public License version 2 as published by the
>> + * Free Software Foundation.
>> + *
>> + * The Allwinner SoCs all have an ADC that can also act as a touchscreen
>> + * controller and a thermal sensor.
>> + * The thermal sensor works only when the ADC acts as a touchscreen controller
>> + * and is configured to throw an interrupt every fixed periods of time (let say
>> + * every X seconds).
>> + * One would be tempted to disable the IP on the hardware side rather than
>> + * disabling interrupts to save some power but that resets the internal clock of
>> + * the IP, resulting in having to wait X seconds every time we want to read the
>> + * value of the thermal sensor.
>> + * This is also the reason of using autosuspend in pm_runtime. If there was no
>> + * autosuspend, the thermal sensor would need X seconds after every
>> + * pm_runtime_get_sync to get a value from the ADC. The autosuspend allows the
>> + * thermal sensor to be requested again in a certain time span before it gets
>> + * shutdown for not being used.
>> + */
>> +
>> +#include <linux/completion.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> +#include <linux/regmap.h>
>> +#include <linux/thermal.h>
>> +
>> +#include <linux/iio/iio.h>
>> +#include <linux/iio/driver.h>
>> +#include <linux/iio/machine.h>
>> +#include <linux/mfd/sun4i-gpadc.h>
>> +
>> +static unsigned int sun4i_gpadc_chan_select(unsigned int chan)
>> +{
>> + return SUN4I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
>> +}
>> +
>> +static unsigned int sun6i_gpadc_chan_select(unsigned int chan)
>> +{
>> + return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
>> +}
>> +
>> +struct gpadc_data {
>> + int temp_offset;
>> + int temp_scale;
>> + unsigned int tp_mode_en;
>> + unsigned int tp_adc_select;
>> + unsigned int (*adc_chan_select)(unsigned int chan);
>> +};
>> +
>> +static const struct gpadc_data sun4i_gpadc_data = {
>> + .temp_offset = -1932,
>> + .temp_scale = 133,
>> + .tp_mode_en = SUN4I_GPADC_CTRL1_TP_MODE_EN,
>> + .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
>> + .adc_chan_select = &sun4i_gpadc_chan_select,
>> +};
>> +
>> +static const struct gpadc_data sun5i_gpadc_data = {
>> + .temp_offset = -1447,
>> + .temp_scale = 100,
>> + .tp_mode_en = SUN4I_GPADC_CTRL1_TP_MODE_EN,
>> + .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
>> + .adc_chan_select = &sun4i_gpadc_chan_select,
>> +};
>> +
>> +static const struct gpadc_data sun6i_gpadc_data = {
>> + .temp_offset = -1623,
>> + .temp_scale = 167,
>> + .tp_mode_en = SUN6I_GPADC_CTRL1_TP_MODE_EN,
>> + .tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
>> + .adc_chan_select = &sun6i_gpadc_chan_select,
>> +};
>> +
>> +struct sun4i_gpadc_iio {
>> + struct iio_dev *indio_dev;
>> + struct completion completion;
>> + int temp_data;
>> + u32 adc_data;
>> + struct regmap *regmap;
>> + unsigned int fifo_data_irq;
>> + atomic_t ignore_fifo_data_irq;
>> + unsigned int temp_data_irq;
>> + atomic_t ignore_temp_data_irq;
>> + const struct gpadc_data *data;
>> + /* prevents concurrent reads of temperature and ADC */
>> + struct mutex mutex;
>> +};
>> +
>> +#define SUN4I_GPADC_ADC_CHANNEL(_channel, _name) { \
>> + .type = IIO_VOLTAGE, \
>> + .indexed = 1, \
>> + .channel = _channel, \
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> + .datasheet_name = _name, \
>> +}
>> +
>> +static struct iio_map sun4i_gpadc_hwmon_maps[] = {
>> + {
>> + .adc_channel_label = "temp_adc",
>> + .consumer_dev_name = "iio_hwmon.0",
>> + },
>> + { /* sentinel */ },
>> +};
>> +
>> +static const struct iio_chan_spec sun4i_gpadc_channels[] = {
>> + SUN4I_GPADC_ADC_CHANNEL(0, "adc_chan0"),
>> + SUN4I_GPADC_ADC_CHANNEL(1, "adc_chan1"),
>> + SUN4I_GPADC_ADC_CHANNEL(2, "adc_chan2"),
>> + SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
>> + {
>> + .type = IIO_TEMP,
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
>> + BIT(IIO_CHAN_INFO_SCALE) |
>> + BIT(IIO_CHAN_INFO_OFFSET),
>> + .datasheet_name = "temp_adc",
>> + },
>> +};
>> +
>> +static int sun4i_gpadc_read(struct iio_dev *indio_dev, int channel, int *val,
>> + unsigned int irq)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> + int ret = 0;
>> +
>> + pm_runtime_get_sync(indio_dev->dev.parent);
>> + mutex_lock(&info->mutex);
>> +
>> + reinit_completion(&info->completion);
>> +
>> + ret = regmap_write(info->regmap, SUN4I_GPADC_INT_FIFOC,
>> + SUN4I_GPADC_INT_FIFOC_TP_FIFO_TRIG_LEVEL(1) |
>> + SUN4I_GPADC_INT_FIFOC_TP_FIFO_FLUSH);
>> + if (ret)
>> + return ret;
>> +
>> + if (irq == info->fifo_data_irq) {
>> + ret = regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
>> + info->data->tp_mode_en |
>> + info->data->tp_adc_select |
>> + info->data->adc_chan_select(channel));
>> + } else {
>> + /*
>> + * The temperature sensor returns valid data only when the ADC
>> + * operates in touchscreen mode.
>> + */
>> + ret = regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
>> + info->data->tp_mode_en);
>> + }
>> +
>> + if (ret)
>> + return ret;
>> +
>> + enable_irq(irq);
>> +
>> + if (!wait_for_completion_timeout(&info->completion,
>> + msecs_to_jiffies(100))) {
>> + if ((irq == info->fifo_data_irq && info->adc_data == -1) ||
>> + (irq == info->temp_data_irq && info->temp_data == -1)) {
>> + ret = -ETIMEDOUT;
>> + goto out;
>> + }
>> + }
>> +
>> + if (irq == info->fifo_data_irq)
>> + *val = info->adc_data;
>> + else
>> + *val = info->temp_data;
>> +
>> + ret = 0;
>> +
>> +out:
>> + disable_irq(irq);
>> + mutex_unlock(&info->mutex);
>> + pm_runtime_mark_last_busy(indio_dev->dev.parent);
>> + pm_runtime_put_autosuspend(indio_dev->dev.parent);
>> +
>> + return ret;
>> +}
>> +
>> +static int sun4i_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
>> + int *val)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> +
>> + return sun4i_gpadc_read(indio_dev, channel, val, info->fifo_data_irq);
>> +}
>> +
>> +static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> +
>> + return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
>> +}
>> +
>> +static int sun4i_gpadc_temp_offset(struct iio_dev *indio_dev, int *val)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> +
>> + *val = info->data->temp_offset;
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_gpadc_temp_scale(struct iio_dev *indio_dev, int *val)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> +
>> + *val = info->data->temp_scale;
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_gpadc_read_raw(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan, int *val,
>> + int *val2, long mask)
>> +{
>> + int ret;
>> +
>> + switch (mask) {
>> + case IIO_CHAN_INFO_OFFSET:
>> + ret = sun4i_gpadc_temp_offset(indio_dev, val);
>> + if (ret)
>> + return ret;
>> +
>> + return IIO_VAL_INT;
>> + case IIO_CHAN_INFO_RAW:
>> + if (chan->type == IIO_VOLTAGE)
>> + ret = sun4i_gpadc_adc_read(indio_dev, chan->channel,
>> + val);
>> + else
>> + ret = sun4i_gpadc_temp_read(indio_dev, val);
>> +
>> + if (ret)
>> + return ret;
>> +
>> + return IIO_VAL_INT;
>> + case IIO_CHAN_INFO_SCALE:
>> + ret = sun4i_gpadc_temp_scale(indio_dev, val);
>> + if (ret)
>> + return ret;
>> +
>> + return IIO_VAL_INT;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static const struct iio_info sun4i_gpadc_iio_info = {
>> + .read_raw = sun4i_gpadc_read_raw,
>> + .driver_module = THIS_MODULE,
>> +};
>> +
>> +static irqreturn_t sun4i_gpadc_temp_data_irq_handler(int irq, void *dev_id)
>> +{
>> + struct sun4i_gpadc_iio *info = dev_id;
>> +
>> + if (atomic_read(&info->ignore_temp_data_irq))
>> + return IRQ_HANDLED;
>> +
>> + if (!regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, &info->temp_data))
>> + complete(&info->completion);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int irq, void *dev_id)
>> +{
>> + struct sun4i_gpadc_iio *info = dev_id;
>> +
>> + if (atomic_read(&info->ignore_fifo_data_irq))
>> + return IRQ_HANDLED;
>> +
>> + if (!regmap_read(info->regmap, SUN4I_GPADC_DATA, &info->adc_data))
>> + complete(&info->completion);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int sun4i_gpadc_runtime_suspend(struct device *dev)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>> +
>> + /* Disable the ADC on IP */
>> + regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
>> + /* Disable temperature sensor on IP */
>> + regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_gpadc_runtime_resume(struct device *dev)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>> +
>> + /* clkin = 6MHz */
>> + regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
>> + SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
>> + SUN4I_GPADC_CTRL0_FS_DIV(7) |
>> + SUN4I_GPADC_CTRL0_T_ACQ(63));
>> + regmap_write(info->regmap, SUN4I_GPADC_CTRL1, info->data->tp_mode_en);
>> + regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
>> + SUN4I_GPADC_CTRL3_FILTER_EN |
>> + SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
>> + /* period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin; ~1.3s */
>> + regmap_write(info->regmap, SUN4I_GPADC_TPR,
>> + SUN4I_GPADC_TPR_TEMP_ENABLE |
>> + SUN4I_GPADC_TPR_TEMP_PERIOD(1953));
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_gpadc_get_temp(void *data, int *temp)
>> +{
>> + struct sun4i_gpadc_iio *info = (struct sun4i_gpadc_iio *)data;
>> + int val, scale, offset;
>> +
>> + /* If reading temperature times out, take stored previous value. */
>> + if (sun4i_gpadc_temp_read(info->indio_dev, &val))
>> + val = info->temp_data;
>> + sun4i_gpadc_temp_scale(info->indio_dev, &scale);
>> + sun4i_gpadc_temp_offset(info->indio_dev, &offset);
>> +
>> + *temp = (val + offset) * scale;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
>> + .get_temp = &sun4i_gpadc_get_temp,
>> +};
>> +
>> +static const struct dev_pm_ops sun4i_gpadc_pm_ops = {
>> + .runtime_suspend = &sun4i_gpadc_runtime_suspend,
>> + .runtime_resume = &sun4i_gpadc_runtime_resume,
>> +};
>> +
>> +static int sun4i_irq_init(struct platform_device *pdev, const char *name,
>> + irq_handler_t handler, const char *devname,
>> + unsigned int *irq, atomic_t *atomic)
>> +{
>> + int ret;
>> + struct sun4i_gpadc_dev *mfd_dev = dev_get_drvdata(pdev->dev.parent);
>> + struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(&pdev->dev));
>> +
>> + /*
>> + * Once the interrupt is activated, the IP continuously performs
>> + * conversions thus throws interrupts. The interrupt is activated right
>> + * after being requested but we want to control when these interrupts
>> + * occur thus we disable it right after being requested. However, an
>> + * interrupt might occur between these two instructions and we have to
>> + * make sure that does not happen, by using atomic flags. We set the
>> + * flag before requesting the interrupt and unset it right after
>> + * disabling the interrupt. When an interrupt occurs between these two
>> + * instructions, reading the atomic flag will tell us to ignore the
>> + * interrupt.
>> + */
>> + atomic_set(atomic, 1);
>> +
>> + *irq = platform_get_irq_byname(pdev, name);
>> + if (*irq < 0) {
>> + dev_err(&pdev->dev, "no %s interrupt registered\n", name);
>> + return *irq;
>> + }
>> +
>> + *irq = regmap_irq_get_virq(mfd_dev->regmap_irqc, *irq);
>> + ret = devm_request_any_context_irq(&pdev->dev, *irq, handler, 0,
>> + devname, info);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "could not request %s interrupt: %d\n",
>> + name, ret);
>> + return ret;
>> + }
>> +
>> + disable_irq(*irq);
>> + atomic_set(atomic, 0);
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_gpadc_probe(struct platform_device *pdev)
>> +{
>> + struct sun4i_gpadc_iio *info;
>> + struct iio_dev *indio_dev;
>> + int ret;
>> + struct sun4i_gpadc_dev *sun4i_gpadc_dev;
>> + struct thermal_zone_device *tzd;
>> +
>> + sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
>> +
>> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
>> + if (!indio_dev)
>> + return -ENOMEM;
>> +
>> + info = iio_priv(indio_dev);
>> + platform_set_drvdata(pdev, indio_dev);
>> +
>> + mutex_init(&info->mutex);
>> + info->regmap = sun4i_gpadc_dev->regmap;
>> + info->indio_dev = indio_dev;
>> + info->temp_data = -1;
>> + info->adc_data = -1;
>> + init_completion(&info->completion);
>> + indio_dev->name = dev_name(&pdev->dev);
>> + indio_dev->dev.parent = &pdev->dev;
>> + indio_dev->dev.of_node = pdev->dev.of_node;
>> + indio_dev->info = &sun4i_gpadc_iio_info;
>> + indio_dev->modes = INDIO_DIRECT_MODE;
>> + indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
>> + indio_dev->channels = sun4i_gpadc_channels;
>> +
>> + info->data = (struct gpadc_data *)platform_get_device_id(pdev)->driver_data;
>> +
>> + /*
>> + * This driver is a child of an MFD which has a node in the DT but not
>> + * its children. Therefore, the resulting devices of this driver do not
>> + * have an of_node variable.
>> + * However, its parent (the MFD driver) has an of_node variable and
>> + * since devm_thermal_zone_of_sensor_register uses its first argument to
>> + * match the phandle defined in the node of the thermal driver with the
>> + * of_node of the device passed as first argument and the third argument
>> + * to call ops from thermal_zone_of_device_ops, the solution is to use
>> + * the parent device as first argument to match the phandle with its
>> + * of_node, and the device from this driver as third argument to return
>> + * the temperature.
>> + */
>> + tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0, info,
>> + &sun4i_ts_tz_ops);
>> + if (IS_ERR(tzd)) {
>> + dev_err(&pdev->dev, "could not register thermal sensor: %ld\n",
>> + PTR_ERR(tzd));
>> + return PTR_ERR(tzd);
>> + }
>> +
>> + pm_runtime_set_autosuspend_delay(&pdev->dev,
>> + SUN4I_GPADC_AUTOSUSPEND_DELAY);
>> + pm_runtime_use_autosuspend(&pdev->dev);
>> + pm_runtime_set_suspended(&pdev->dev);
>> + pm_runtime_enable(&pdev->dev);
>> +
>> + ret = sun4i_irq_init(pdev, "TEMP_DATA_PENDING",
>> + sun4i_gpadc_temp_data_irq_handler, "temp_data",
>> + &info->temp_data_irq, &info->ignore_temp_data_irq);
>> + if (ret < 0)
>> + goto err;
>> +
>> + ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
>> + sun4i_gpadc_fifo_data_irq_handler, "fifo_data",
>> + &info->fifo_data_irq, &info->ignore_fifo_data_irq);
>> + if (ret < 0)
>> + goto err;
>> +
>> + ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "failed to register iio map array\n");
>> + goto err;
>> + }
>> +
>> + ret = iio_device_register(indio_dev);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "could not register the device\n");
>> + goto err_map;
>> + }
>> +
>> + return 0;
>> +
>> +err_map:
>> + iio_map_array_unregister(indio_dev);
>> +
>> +err:
>> + pm_runtime_put(&pdev->dev);
>> + pm_runtime_disable(&pdev->dev);
>> +
>> + return ret;
>> +}
>> +
>> +static int sun4i_gpadc_remove(struct platform_device *pdev)
>> +{
>> + struct sun4i_gpadc_iio *info;
>> + struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> +
>> + pm_runtime_put(&pdev->dev);
>> + pm_runtime_disable(&pdev->dev);
>> + info = iio_priv(indio_dev);
>> + iio_map_array_unregister(indio_dev);
>> + iio_device_unregister(indio_dev);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct platform_device_id sun4i_gpadc_id[] = {
>> + { "sun4i-a10-gpadc-iio", (kernel_ulong_t)&sun4i_gpadc_data },
>> + { "sun5i-a13-gpadc-iio", (kernel_ulong_t)&sun5i_gpadc_data },
>> + { "sun6i-a31-gpadc-iio", (kernel_ulong_t)&sun6i_gpadc_data },
>> + { /* sentinel */ },
>> +};
>> +
>> +static struct platform_driver sun4i_gpadc_driver = {
>> + .driver = {
>> + .name = "sun4i-gpadc-iio",
>> + .pm = &sun4i_gpadc_pm_ops,
>> + },
>> + .id_table = sun4i_gpadc_id,
>> + .probe = sun4i_gpadc_probe,
>> + .remove = sun4i_gpadc_remove,
>> +};
>> +
>> +module_platform_driver(sun4i_gpadc_driver);
>> +
>> +MODULE_DESCRIPTION("ADC driver for sunxi platforms");
>> +MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
>> +MODULE_LICENSE("GPL v2");
>>
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3] clkdev: Detect errors in clk_hw_register_clkdev() for mass registration
From: Geert Uytterhoeven @ 2016-10-31 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031092223.GW1041@n2100.armlinux.org.uk>
Hi Russell,
On Mon, Oct 31, 2016 at 10:22 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Fri, Oct 21, 2016 at 09:02:38AM +0200, Geert Uytterhoeven wrote:
>> Unlike clk_register_clkdev(), clk_hw_register_clkdev() doesn't check for
>> passed error objects from a previous registration call. Hence the caller
>> of clk_hw_register_*() has to check for errors before calling
>> clk_hw_register_clkdev*().
>>
>> Make clk_hw_register_clkdev() more similar to clk_register_clkdev() by
>> adding this error check, removing the burden from callers that do mass
>> registration.
>>
>> Fixes: e4f1b49bda6d6aa2 ("clkdev: Add clk_hw based registration APIs")
>> Fixes: 944b9a41e004534f ("clk: ls1x: Migrate to clk_hw based OF and registration APIs")
>> Fixes: 44ce9a9ae977736f ("MIPS: TXx9: Convert to Common Clock Framework")
>> Fixes: f48d947a162dfa9d ("clk: clps711x: Migrate to clk_hw based OF and registration APIs")
>> Fixes: b4626a7f489238a5 ("CLK: Add Loongson1C clock support")
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Please put this in the patch system, thanks.
Done. I hope it went through, the "new" README predates git-send-email.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [v15, 6/7] base: soc: introduce soc_device_match() interface
From: Y.B. Lu @ 2016-10-31 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2572890.e6aV4hmMEL@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, October 28, 2016 6:48 PM
> To: linuxppc-dev at lists.ozlabs.org
> Cc: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree at vger.kernel.org;
> Rob Herring; Santosh Shilimkar; linux-arm-kernel at lists.infradead.org;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org; Leo Li;
> iommu at lists.linux-foundation.org; Kumar Gala; Geert Uytterhoeven
> Subject: Re: [v15, 6/7] base: soc: introduce soc_device_match() interface
>
> On Friday, October 28, 2016 2:50:17 PM CEST Yangbo Lu wrote:
> > +
> > +static int soc_device_match_one(struct device *dev, void *arg) {
> > + struct soc_device *soc_dev = container_of(dev, struct
> soc_device, dev);
> > + const struct soc_device_attribute *match = arg;
> > +
> > + if (match->machine &&
> > + !glob_match(match->machine, soc_dev->attr->machine))
> > + return 0;
> > +
> > + if (match->family &&
> > + !glob_match(match->family, soc_dev->attr->family))
> > + return 0;
> > +
> >
>
> Geert found a bug in my code, and submitted a fix at
> https://patchwork.kernel.org/patch/9361395/
>
> I think you should include that one in your series.
>
[Lu Yangbo-B47093] Ok, no problem. Thanks :)
> Arnd
^ 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