* [PATCH v4 07/18] arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
In-Reply-To: <20170412111400.2296-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000
speed.
This patch enable the dwmac-sun8i on Allwinner H3/H5 SoC Device-tree.
SoC H3/H5 have an internal PHY, so optionals syscon and ephy are set.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 78d1d61..34ec227 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -285,6 +285,14 @@
interrupt-controller;
#interrupt-cells = <3>;
+ emac_rgmii_pins: emac0@0 {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+ "PD5", "PD7", "PD8", "PD9", "PD10",
+ "PD12", "PD13", "PD15", "PD16", "PD17";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
i2c0_pins: i2c0 {
pins = "PA11", "PA12";
function = "i2c0";
@@ -381,6 +389,32 @@
clocks = <&osc24M>;
};
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+
spi0: spi@01c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH v4 06/18] arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
In-Reply-To: <20170412111400.2296-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch add the dt node for the syscon register present on the
Allwinner H3/H5
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock..
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 1aeeacb..78d1d61 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -83,6 +83,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon@01c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH v4 05/18] net-next: stmmac: Add dwmac-sun8i
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
In-Reply-To: <20170412111400.2296-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The dwmac-sun8i is a heavy hacked version of stmmac hardware by
allwinner.
In fact the only common part is the descriptor management and the first
register function.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 960 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 25 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 1 +
6 files changed, 1005 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cfbe363..85c0e41 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -145,6 +145,17 @@ config DWMAC_SUNXI
This selects Allwinner SoC glue layer support for the
stmmac device driver. This driver is used for A20/A31
GMAC ethernet controller.
+
+config DWMAC_SUN8I
+ tristate "Allwinner sun8i GMAC support"
+ default ARCH_SUNXI
+ depends on OF && (ARCH_SUNXI || COMPILE_TEST)
+ ---help---
+ Support for Allwinner H3 A83T A64 EMAC ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for H3/A83T/A64
+ EMAC ethernet controller.
endif
config STMMAC_PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 700c603..fd4937a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
obj-$(CONFIG_DWMAC_STM32) += dwmac-stm32.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
+obj-$(CONFIG_DWMAC_SUN8I) += dwmac-sun8i.o
obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
obj-$(CONFIG_DWMAC_GENERIC) += dwmac-generic.o
stmmac-platform-objs:= stmmac_platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
new file mode 100644
index 0000000..0637ca3
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -0,0 +1,960 @@
+/*
+ * dwmac-sun8i.c - Allwinner sun8i DWMAC specific glue layer
+ *
+ * Copyright (C) 2017 Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@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.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/regmap.h>
+#include <linux/stmmac.h>
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+/* General notes on dwmac-sun8i:
+ * Locking: no locking is necessary in this file because all necessary locking
+ * is done in the "stmmac files"
+ */
+
+/* struct emac_variant - Descrive dwmac-sun8i hardware variant
+ * @default_syscon_value: The default value of the EMAC register in syscon
+ * This value is used for disabling properly EMAC
+ * and used as a good starting value in case of the
+ * boot process(uboot) leave some stuff.
+ * @internal_phy: Does the MAC embed an internal PHY
+ * @support_mii: Does the MAC handle MII
+ * @support_rmii: Does the MAC handle RMII
+ * @support_rgmii: Does the MAC handle RGMII
+ */
+struct emac_variant {
+ u32 default_syscon_value;
+ int internal_phy;
+ bool support_mii;
+ bool support_rmii;
+ bool support_rgmii;
+};
+
+/* struct sunxi_priv_data - hold all sunxi private data
+ * @tx_clk: reference to MAC TX clock
+ * @ephy_clk: reference to the optional EPHY clock for the internal PHY
+ * @regulator: reference to the optional regulator
+ * @rst_ephy: reference to the optional EPHY reset for the internal PHY
+ * @variant: reference to the current board variant
+ * @regmap: regmap for using the syscon
+ * @use_internal_phy: Does the current PHY choice imply using the internal PHY
+ */
+struct sunxi_priv_data {
+ struct clk *tx_clk;
+ struct clk *ephy_clk;
+ struct regulator *regulator;
+ struct reset_control *rst_ephy;
+ const struct emac_variant *variant;
+ struct regmap *regmap;
+ bool use_internal_phy;
+};
+
+static const struct emac_variant emac_variant_h3 = {
+ .default_syscon_value = 0x58000,
+ .internal_phy = PHY_INTERFACE_MODE_MII,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a83t = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a64 = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+#define EMAC_BASIC_CTL0 0x00
+#define EMAC_BASIC_CTL1 0x04
+#define EMAC_INT_STA 0x08
+#define EMAC_INT_EN 0x0C
+#define EMAC_TX_CTL0 0x10
+#define EMAC_TX_CTL1 0x14
+#define EMAC_TX_FLOW_CTL 0x1C
+#define EMAC_TX_DESC_LIST 0x20
+#define EMAC_RX_CTL0 0x24
+#define EMAC_RX_CTL1 0x28
+#define EMAC_RX_DESC_LIST 0x34
+#define EMAC_RX_FRM_FLT 0x38
+#define EMAC_MDIO_CMD 0x48
+#define EMAC_MDIO_DATA 0x4C
+#define EMAC_MACADDR_HI(reg) (0x50 + (reg) * 8)
+#define EMAC_MACADDR_LO(reg) (0x54 + (reg) * 8)
+#define EMAC_TX_DMA_STA 0xB0
+#define EMAC_TX_CUR_DESC 0xB4
+#define EMAC_TX_CUR_BUF 0xB8
+#define EMAC_RX_DMA_STA 0xC0
+#define EMAC_RX_CUR_DESC 0xC4
+#define EMAC_RX_CUR_BUF 0xC8
+
+/* Use in EMAC_BASIC_CTL1 */
+#define EMAC_BURSTLEN_SHIFT 24
+
+/* Used in EMAC_RX_FRM_FLT */
+#define EMAC_FRM_FLT_RXALL BIT(0)
+#define EMAC_FRM_FLT_CTL BIT(13)
+#define EMAC_FRM_FLT_MULTICAST BIT(16)
+
+/* Used in RX_CTL1*/
+#define EMAC_RX_MD BIT(1)
+#define EMAC_RX_TH_MASK GENMASK(4, 5)
+#define EMAC_RX_TH_32 0
+#define EMAC_RX_TH_64 (0x1 << 4)
+#define EMAC_RX_TH_96 (0x2 << 4)
+#define EMAC_RX_TH_128 (0x3 << 4)
+#define EMAC_RX_DMA_EN BIT(30)
+#define EMAC_RX_DMA_START BIT(31)
+
+/* Used in TX_CTL1*/
+#define EMAC_TX_MD BIT(1)
+#define EMAC_TX_NEXT_FRM BIT(2)
+#define EMAC_TX_TH_MASK GENMASK(8, 10)
+#define EMAC_TX_TH_64 0
+#define EMAC_TX_TH_128 (0x1 << 8)
+#define EMAC_TX_TH_192 (0x2 << 8)
+#define EMAC_TX_TH_256 (0x3 << 8)
+#define EMAC_TX_DMA_EN BIT(30)
+#define EMAC_TX_DMA_START BIT(31)
+
+/* Used in RX_CTL0 */
+#define EMAC_RX_RECEIVER_EN BIT(31)
+#define EMAC_RX_DO_CRC BIT(27)
+#define EMAC_RX_FLOW_CTL_EN BIT(16)
+
+/* Used in TX_CTL0 */
+#define EMAC_TX_TRANSMITTER_EN BIT(31)
+
+/* Used in EMAC_TX_FLOW_CTL */
+#define EMAC_TX_FLOW_CTL_EN BIT(0)
+
+/* Used in EMAC_INT_STA */
+#define EMAC_TX_INT BIT(0)
+#define EMAC_TX_DMA_STOP_INT BIT(1)
+#define EMAC_TX_BUF_UA_INT BIT(2)
+#define EMAC_TX_TIMEOUT_INT BIT(3)
+#define EMAC_TX_UNDERFLOW_INT BIT(4)
+#define EMAC_TX_EARLY_INT BIT(5)
+#define EMAC_RX_INT BIT(8)
+#define EMAC_RX_BUF_UA_INT BIT(9)
+#define EMAC_RX_DMA_STOP_INT BIT(10)
+#define EMAC_RX_TIMEOUT_INT BIT(11)
+#define EMAC_RX_OVERFLOW_INT BIT(12)
+#define EMAC_RX_EARLY_INT BIT(13)
+#define EMAC_RGMII_STA_INT BIT(16)
+
+#define MAC_ADDR_TYPE_DST BIT(31)
+
+/* H3 specific bits for EPHY */
+#define H3_EPHY_ADDR_SHIFT 20
+#define H3_EPHY_LED_POL BIT(17) /* 1: active low, 0: active high */
+#define H3_EPHY_SHUTDOWN BIT(16) /* 1: shutdown, 0: power up */
+#define H3_EPHY_SELECT BIT(15) /* 1: internal PHY, 0: external PHY */
+
+/* H3/A64 specific bits */
+#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
+
+/* Generic system control EMAC_CLK bits */
+#define SYSCON_ETXDC_MASK GENMASK(2, 0)
+#define SYSCON_ETXDC_SHIFT 10
+#define SYSCON_ERXDC_MASK GENMASK(4, 0)
+#define SYSCON_ERXDC_SHIFT 5
+/* EMAC PHY Interface Type */
+#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
+#define SYSCON_ETCS_MASK GENMASK(1, 0)
+#define SYSCON_ETCS_MII 0x0
+#define SYSCON_ETCS_EXT_GMII 0x1
+#define SYSCON_ETCS_INT_GMII 0x2
+#define SYSCON_EMAC_REG 0x30
+
+/* sun8i_dwmac_dma_reset() - reset the EMAC
+ * Called from stmmac via stmmac_dma_ops->reset
+ */
+static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
+{
+ writel(0, ioaddr + EMAC_RX_CTL1);
+ writel(0, ioaddr + EMAC_TX_CTL1);
+ writel(0, ioaddr + EMAC_RX_FRM_FLT);
+ writel(0, ioaddr + EMAC_RX_DESC_LIST);
+ writel(0, ioaddr + EMAC_TX_DESC_LIST);
+ writel(0, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+ return 0;
+}
+
+/* sun8i_dwmac_dma_init() - initialize the EMAC
+ * Called from stmmac via stmmac_dma_ops->init
+ */
+static void sun8i_dwmac_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
+{
+ /* Write TX and RX descriptors address */
+ writel(dma_rx, ioaddr + EMAC_RX_DESC_LIST);
+ writel(dma_tx, ioaddr + EMAC_TX_DESC_LIST);
+
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+}
+
+/* sun8i_dwmac_dump_regs() - Dump EMAC address space
+ * Called from stmmac_dma_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_regs(void __iomem *ioaddr, u32 *reg_space)
+{
+ int i;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+/* sun8i_dwmac_dump_mac_regs() - Dump EMAC address space
+ * Called from stmmac_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_mac_regs(struct mac_device_info *hw,
+ u32 *reg_space)
+{
+ int i;
+ void __iomem *ioaddr = hw->pcsr;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+static void sun8i_dwmac_enable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(0, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v &= ~EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v |= EMAC_RX_DMA_START;
+ v |= EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v &= ~EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
+ struct stmmac_extra_stats *x, u32 chan)
+{
+ u32 v;
+ int ret = 0;
+
+ v = readl(ioaddr + EMAC_INT_STA);
+
+ if (v & EMAC_TX_INT) {
+ ret |= handle_tx;
+ x->tx_normal_irq_n++;
+ }
+
+ if (v & EMAC_TX_DMA_STOP_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_BUF_UA_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_TX_UNDERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->tx_undeflow_irq++;
+ }
+
+ if (v & EMAC_TX_EARLY_INT)
+ x->tx_early_irq++;
+
+ if (v & EMAC_RX_INT) {
+ ret |= handle_rx;
+ x->rx_normal_irq_n++;
+ }
+
+ if (v & EMAC_RX_BUF_UA_INT)
+ x->rx_buf_unav_irq++;
+
+ if (v & EMAC_RX_DMA_STOP_INT)
+ x->rx_process_stopped_irq++;
+
+ if (v & EMAC_RX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_RX_OVERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->rx_overflow_irq++;
+ }
+
+ if (v & EMAC_RX_EARLY_INT)
+ x->rx_early_irq++;
+
+ if (v & EMAC_RGMII_STA_INT)
+ x->irq_rgmii_n++;
+
+ writel(v, ioaddr + EMAC_INT_STA);
+
+ return ret;
+}
+
+static void sun8i_dwmac_dma_operation_mode(void __iomem *ioaddr, int txmode,
+ int rxmode, int rxfifosz)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ if (txmode == SF_DMA_MODE) {
+ v |= EMAC_TX_MD;
+ /* Undocumented bit (called TX_NEXT_FRM in BSP), the original
+ * comment is
+ * "Operating on second frame increase the performance
+ * especially when transmit store-and-forward is used."
+ */
+ v |= EMAC_TX_NEXT_FRM;
+ } else {
+ v &= ~EMAC_TX_MD;
+ v &= ~EMAC_TX_TH_MASK;
+ if (txmode < 64)
+ v |= EMAC_TX_TH_64;
+ else if (txmode < 128)
+ v |= EMAC_TX_TH_128;
+ else if (txmode < 192)
+ v |= EMAC_TX_TH_192;
+ else if (txmode < 256)
+ v |= EMAC_TX_TH_256;
+ }
+ writel(v, ioaddr + EMAC_TX_CTL1);
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ if (rxmode == SF_DMA_MODE) {
+ v |= EMAC_RX_MD;
+ } else {
+ v &= ~EMAC_RX_MD;
+ v &= ~EMAC_RX_TH_MASK;
+ if (rxmode < 32)
+ v |= EMAC_RX_TH_32;
+ else if (rxmode < 64)
+ v |= EMAC_RX_TH_64;
+ else if (rxmode < 96)
+ v |= EMAC_RX_TH_96;
+ else if (rxmode < 128)
+ v |= EMAC_RX_TH_128;
+ }
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static const struct stmmac_dma_ops sun8i_dwmac_dma_ops = {
+ .reset = sun8i_dwmac_dma_reset,
+ .init = sun8i_dwmac_dma_init,
+ .dump_regs = sun8i_dwmac_dump_regs,
+ .dma_mode = sun8i_dwmac_dma_operation_mode,
+ .enable_dma_transmission = sun8i_dwmac_enable_dma_transmission,
+ .enable_dma_irq = sun8i_dwmac_enable_dma_irq,
+ .disable_dma_irq = sun8i_dwmac_disable_dma_irq,
+ .start_tx = sun8i_dwmac_dma_start_tx,
+ .stop_tx = sun8i_dwmac_dma_stop_tx,
+ .start_rx = sun8i_dwmac_dma_start_rx,
+ .stop_rx = sun8i_dwmac_dma_stop_rx,
+ .dma_interrupt = sun8i_dwmac_dma_interrupt,
+};
+
+static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+ int ret;
+
+ if (gmac->regulator) {
+ ret = regulator_enable(gmac->regulator);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable regulator\n");
+ return ret;
+ }
+ }
+
+ ret = clk_prepare_enable(gmac->tx_clk);
+ if (ret) {
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+ dev_err(&pdev->dev, "Could not enable AHB clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = (8 << EMAC_BURSTLEN_SHIFT); /* burst len */
+ writel(v, ioaddr + EMAC_BASIC_CTL1);
+}
+
+static void sun8i_dwmac_set_mac(void __iomem *ioaddr, bool enable)
+{
+ u32 t, r;
+
+ t = readl(ioaddr + EMAC_TX_CTL0);
+ r = readl(ioaddr + EMAC_RX_CTL0);
+ if (enable) {
+ t |= EMAC_TX_TRANSMITTER_EN;
+ r |= EMAC_RX_RECEIVER_EN;
+ } else {
+ t &= ~EMAC_TX_TRANSMITTER_EN;
+ r &= ~EMAC_RX_RECEIVER_EN;
+ }
+ writel(t, ioaddr + EMAC_TX_CTL0);
+ writel(r, ioaddr + EMAC_RX_CTL0);
+}
+
+static void sun8i_dwmac_set_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ stmmac_set_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+ if (reg_n > 0) {
+ v = readl(ioaddr + EMAC_MACADDR_HI(reg_n));
+ v |= MAC_ADDR_TYPE_DST;
+ writel(v, ioaddr + EMAC_MACADDR_HI(reg_n));
+ }
+}
+
+static void sun8i_dwmac_get_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ stmmac_get_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+}
+
+/* caution this function must return non 0 to work */
+static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ v |= EMAC_RX_DO_CRC;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ return 1;
+}
+
+static void sun8i_dwmac_set_filter(struct mac_device_info *hw,
+ struct net_device *dev)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+ int i = 0;
+ struct netdev_hw_addr *ha;
+
+ v = readl(ioaddr + EMAC_RX_FRM_FLT);
+
+ v |= EMAC_FRM_FLT_CTL;
+
+ if (dev->flags & IFF_PROMISC) {
+ v = EMAC_FRM_FLT_RXALL;
+ } else if (dev->flags & IFF_ALLMULTI) {
+ v = EMAC_FRM_FLT_MULTICAST;
+ } else if (!netdev_mc_empty(dev)) {
+ netdev_for_each_mc_addr(ha, dev) {
+ i++;
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ }
+ }
+
+ if (netdev_uc_count(dev) + i > hw->unicast_filter_entries) {
+ netdev_info(dev, "Too many address, switching to promiscuous\n");
+ v = EMAC_FRM_FLT_RXALL;
+ } else {
+ netdev_for_each_uc_addr(ha, dev) {
+ i++;
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ }
+ }
+ writel(v, ioaddr + EMAC_RX_FRM_FLT);
+}
+
+static void sun8i_dwmac_flow_ctrl(struct mac_device_info *hw,
+ unsigned int duplex, unsigned int fc,
+ unsigned int pause_time, u32 tx_cnt)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_RX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_RX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ v = readl(ioaddr + EMAC_TX_FLOW_CTL);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_TX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_TX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+}
+
+static int sun8i_dwmac_reset(struct stmmac_priv *priv)
+{
+ u32 v;
+ int err;
+
+ v = readl(priv->ioaddr + EMAC_BASIC_CTL1);
+ writel(v | 0x01, priv->ioaddr + EMAC_BASIC_CTL1);
+
+ err = readl_poll_timeout(priv->ioaddr + EMAC_BASIC_CTL1, v,
+ !(v & 0x01), 100, 10000);
+
+ if (err) {
+ dev_err(priv->device, "EMAC reset timeout\n");
+ return -EFAULT;
+ }
+ return 0;
+}
+
+static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ struct device_node *node = priv->device->of_node;
+ int ret;
+ u32 reg, val;
+
+ regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+ reg = gmac->variant->default_syscon_value;
+ if (reg != val)
+ dev_warn(priv->device,
+ "Current syscon value is not the default %x (expect %x)\n",
+ val, reg);
+
+ if (gmac->variant->internal_phy) {
+ if (!gmac->use_internal_phy) {
+ /* switch to external PHY interface */
+ reg &= ~H3_EPHY_SELECT;
+ } else {
+ reg |= H3_EPHY_SELECT;
+ reg &= ~H3_EPHY_SHUTDOWN;
+ dev_dbg(priv->device, "Select internal_phy %x\n", reg);
+
+ if (of_property_read_bool(priv->plat->phy_node,
+ "allwinner,leds-active-low"))
+ reg |= H3_EPHY_LED_POL;
+ else
+ reg &= ~H3_EPHY_LED_POL;
+
+ ret = of_mdio_parse_addr(priv->device,
+ priv->plat->phy_node);
+ if (ret < 0) {
+ dev_err(priv->device, "Could not parse MDIO addr\n");
+ return ret;
+ }
+ /* of_mdio_parse_addr returns a valid (0 ~ 31) PHY
+ * address. No need to mask it again.
+ */
+ reg |= ret << H3_EPHY_ADDR_SHIFT;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,tx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "tx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set tx-delay to %x\n", val);
+ if (val <= SYSCON_ETXDC_MASK) {
+ reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+ reg |= (val << SYSCON_ETXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid TX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,rx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "rx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set rx-delay to %x\n", val);
+ if (val <= SYSCON_ERXDC_MASK) {
+ reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+ reg |= (val << SYSCON_ERXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid RX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ /* Clear interface mode bits */
+ reg &= ~(SYSCON_ETCS_MASK | SYSCON_EPIT);
+ if (gmac->variant->support_rmii)
+ reg &= ~SYSCON_RMII_EN;
+
+ switch (priv->plat->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ /* default */
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ reg |= SYSCON_RMII_EN | SYSCON_ETCS_EXT_GMII;
+ break;
+ default:
+ dev_err(priv->device, "Unsupported interface mode: %s",
+ phy_modes(priv->plat->interface));
+ return -EINVAL;
+ }
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+
+ return 0;
+}
+
+static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
+{
+ u32 reg = gmac->variant->default_syscon_value;
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+}
+
+static int sun8i_dwmac_power_internal_phy(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ int ret;
+
+ if (gmac->ephy_clk) {
+ ret = clk_prepare_enable(gmac->ephy_clk);
+ if (ret) {
+ dev_err(priv->device, "Cannot enable ephy\n");
+ return ret;
+ }
+ }
+
+ if (gmac->rst_ephy) {
+ ret = reset_control_deassert(gmac->rst_ephy);
+ if (ret) {
+ dev_err(priv->device, "Cannot deassert ephy\n");
+ clk_disable_unprepare(gmac->ephy_clk);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
+{
+ if (gmac->ephy_clk)
+ clk_disable_unprepare(gmac->ephy_clk);
+ if (gmac->rst_ephy)
+ reset_control_assert(gmac->rst_ephy);
+ return 0;
+}
+
+static int sun8i_power_phy(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ int ret;
+
+ ret = sun8i_dwmac_power_internal_phy(priv);
+ if (ret)
+ return ret;
+
+ ret = sun8i_dwmac_set_syscon(priv);
+ if (ret)
+ goto error_phy;
+
+ ret = sun8i_dwmac_reset(priv);
+ if (ret)
+ goto error_phy;
+ return 0;
+
+error_phy:
+ sun8i_dwmac_unset_syscon(gmac);
+ sun8i_dwmac_unpower_internal_phy(gmac);
+ return ret;
+}
+
+static void sun8i_unpower_phy(struct sunxi_priv_data *gmac)
+{
+ sun8i_dwmac_unset_syscon(gmac);
+ sun8i_dwmac_unpower_internal_phy(gmac);
+}
+
+static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+
+ sun8i_unpower_phy(gmac);
+
+ clk_disable_unprepare(gmac->tx_clk);
+
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+}
+
+static const struct stmmac_ops sun8i_dwmac_ops = {
+ .core_init = sun8i_dwmac_core_init,
+ .set_mac = sun8i_dwmac_set_mac,
+ .dump_regs = sun8i_dwmac_dump_mac_regs,
+ .rx_ipc = sun8i_dwmac_rx_ipc_enable,
+ .set_filter = sun8i_dwmac_set_filter,
+ .flow_ctrl = sun8i_dwmac_flow_ctrl,
+ .set_umac_addr = sun8i_dwmac_set_umac_addr,
+ .get_umac_addr = sun8i_dwmac_get_umac_addr,
+};
+
+static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
+{
+ struct mac_device_info *mac;
+ struct stmmac_priv *priv = ppriv;
+ int ret;
+
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
+ if (!mac)
+ return NULL;
+
+ ret = sun8i_power_phy(priv);
+ if (ret)
+ return NULL;
+
+ mac->pcsr = priv->ioaddr;
+ mac->mac = &sun8i_dwmac_ops;
+ mac->dma = &sun8i_dwmac_dma_ops;
+
+ mac->link.port = 0;
+ mac->link.duplex = BIT(0);
+ mac->link.speed = 1;
+ mac->mii.addr = EMAC_MDIO_CMD;
+ mac->mii.data = EMAC_MDIO_DATA;
+ mac->mii.reg_shift = 4;
+ mac->mii.reg_mask = GENMASK(8, 4);
+ mac->mii.addr_shift = 12;
+ mac->mii.addr_mask = GENMASK(16, 12);
+ mac->mii.clk_csr_shift = 20;
+ mac->mii.clk_csr_mask = GENMASK(22, 20);
+ mac->unicast_filter_entries = 8;
+
+ /* Synopsys Id is not available */
+ priv->synopsys_id = 0;
+
+ return mac;
+}
+
+static int sun8i_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct sunxi_priv_data *gmac;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ 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);
+
+ gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
+ if (!gmac)
+ return -ENOMEM;
+
+ gmac->variant = of_device_get_match_data(&pdev->dev);
+ if (!gmac->variant) {
+ dev_err(&pdev->dev, "Missing sun8i-emac variant\n");
+ return -EINVAL;
+ }
+
+ gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
+ if (IS_ERR(gmac->tx_clk)) {
+ dev_err(dev, "could not get tx clock\n");
+ return PTR_ERR(gmac->tx_clk);
+ }
+
+ /* Optional regulator for PHY */
+ gmac->regulator = devm_regulator_get_optional(dev, "phy");
+ if (IS_ERR(gmac->regulator)) {
+ if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_info(dev, "no regulator found\n");
+ gmac->regulator = NULL;
+ }
+
+ gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "syscon");
+ if (IS_ERR(gmac->regmap)) {
+ ret = PTR_ERR(gmac->regmap);
+ dev_err(&pdev->dev, "unable to map SYSCON:%d\n", ret);
+ return ret;
+ }
+
+ plat_dat->interface = of_get_phy_mode(dev->of_node);
+ if (plat_dat->interface == gmac->variant->internal_phy) {
+ dev_info(&pdev->dev, "Will use internal PHY\n");
+ gmac->use_internal_phy = true;
+ gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
+ if (IS_ERR(gmac->ephy_clk)) {
+ ret = PTR_ERR(gmac->ephy_clk);
+ dev_err(&pdev->dev, "Cannot get EPHY clock err=%d\n",
+ ret);
+ return -EINVAL;
+ }
+
+ gmac->rst_ephy = of_reset_control_get(plat_dat->phy_node, NULL);
+ if (IS_ERR(gmac->rst_ephy)) {
+ ret = PTR_ERR(gmac->rst_ephy);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ dev_err(&pdev->dev, "No EPHY reset control found %d\n",
+ ret);
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&pdev->dev, "Will use external PHY\n");
+ gmac->use_internal_phy = false;
+ }
+
+ /* platform data specifying hardware features and callbacks.
+ * hardware features were copied from Allwinner drivers.
+ */
+ plat_dat->rx_coe = STMMAC_RX_COE_TYPE2;
+ plat_dat->tx_coe = 1;
+ plat_dat->has_sun8i = true;
+ plat_dat->bsp_priv = gmac;
+ plat_dat->init = sun8i_dwmac_init;
+ plat_dat->exit = sun8i_dwmac_exit;
+ plat_dat->setup = sun8i_dwmac_setup;
+
+ ret = sun8i_dwmac_init(pdev, plat_dat->bsp_priv);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
+
+ return ret;
+}
+
+static const struct of_device_id sun8i_dwmac_match[] = {
+ { .compatible = "allwinner,sun8i-h3-emac",
+ .data = &emac_variant_h3 },
+ { .compatible = "allwinner,sun8i-a83t-emac",
+ .data = &emac_variant_a83t },
+ { .compatible = "allwinner,sun50i-a64-emac",
+ .data = &emac_variant_a64 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
+
+static struct platform_driver sun8i_dwmac_driver = {
+ .probe = sun8i_dwmac_probe,
+ .remove = stmmac_pltfr_remove,
+ .driver = {
+ .name = "sun8i-dwmac",
+ .pm = &stmmac_pltfr_pm_ops,
+ .of_match_table = sun8i_dwmac_match,
+ },
+};
+module_platform_driver(sun8i_dwmac_driver);
+
+MODULE_AUTHOR("Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
+MODULE_DESCRIPTION("Allwinner sun8i DWMAC specific glue layer");
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 72d371d..f9301f0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -235,6 +235,17 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
priv->clk_csr = STMMAC_CSR_250_300M;
}
+
+ if (priv->plat->has_sun8i) {
+ if (clk_rate > 160000000)
+ priv->clk_csr = 0x03;
+ else if (clk_rate > 80000000)
+ priv->clk_csr = 0x02;
+ else if (clk_rate > 40000000)
+ priv->clk_csr = 0x01;
+ else
+ priv->clk_csr = 0;
+ }
}
static void print_pkt(unsigned char *buf, int len)
@@ -784,6 +795,10 @@ static void stmmac_adjust_link(struct net_device *dev)
if (phydev->link) {
u32 ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
+ /* disable loopback */
+ if (priv->plat->has_sun8i)
+ ctrl &= ~BIT(1);
+
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
@@ -800,6 +815,8 @@ static void stmmac_adjust_link(struct net_device *dev)
if (phydev->speed != priv->speed) {
new_state = 1;
+ if (priv->plat->has_sun8i)
+ ctrl &= ~GENMASK(3, 2);
switch (phydev->speed) {
case 1000:
if (priv->plat->has_gmac ||
@@ -811,6 +828,8 @@ static void stmmac_adjust_link(struct net_device *dev)
priv->plat->has_gmac4) {
ctrl |= priv->hw->link.port;
ctrl |= priv->hw->link.speed;
+ } else if (priv->plat->has_sun8i) {
+ ctrl |= 3 << 2;
} else {
ctrl &= ~priv->hw->link.port;
}
@@ -820,6 +839,8 @@ static void stmmac_adjust_link(struct net_device *dev)
priv->plat->has_gmac4) {
ctrl |= priv->hw->link.port;
ctrl &= ~(priv->hw->link.speed);
+ } else if (priv->plat->has_sun8i) {
+ ctrl |= 2 << 2;
} else {
ctrl &= ~priv->hw->link.port;
}
@@ -3968,6 +3989,10 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->hw = mac;
+ /* dwmac-sun8i only work in chain mode */
+ if (priv->plat->has_sun8i)
+ chain_mode = 1;
+
/* To use the chained or ring mode */
if (priv->synopsys_id >= DWMAC_CORE_4_00) {
priv->hw->mode = &dwmac4_ring_mode_ops;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 7fc3a1e..3840529 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -309,6 +309,12 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
struct device_node *np, struct device *dev)
{
bool mdio = true;
+ static const struct of_device_id need_mdio_ids[] = {
+ { .compatible = "snps,dwc-qos-ethernet-4.10" },
+ { .compatible = "allwinner,sun8i-a83t-emac" },
+ { .compatible = "allwinner,sun8i-h3-emac" },
+ { .compatible = "allwinner,sun50i-a64-emac" },
+ };
/* If phy-handle property is passed from DT, use it as the PHY */
plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
@@ -325,8 +331,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
mdio = false;
}
- /* exception for dwmac-dwc-qos-eth glue logic */
- if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
+ if (of_match_node(need_mdio_ids, np)) {
plat->mdio_node = of_get_child_by_name(np, "mdio");
} else {
/**
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 8bb550b..108739f 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -186,6 +186,7 @@ struct plat_stmmacenet_data {
struct reset_control *stmmac_rst;
struct stmmac_axi *axi;
int has_gmac4;
+ bool has_sun8i;
bool tso_en;
int mac_port_sel_speed;
bool en_tx_lpi_clockgating;
--
2.10.2
^ permalink raw reply related
* [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
In-Reply-To: <20170412111400.2296-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch adds documentation for Device-Tree bindings for the
syscon present in allwinner devices.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
new file mode 100644
index 0000000..c056c5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
@@ -0,0 +1,19 @@
+* Allwinner sun8i system controller
+
+This file describes the bindings for the system controller present in
+Allwinner SoC H3, A83T and A64.
+The principal function of this syscon is to control EMAC PHY choice and
+config.
+
+Required properties for the system controller:
+- reg: address and length of the register for the device.
+- compatible: should be "syscon" and one of the following string:
+ "allwinner,sun8i-h3-system-controller"
+ "allwinner,sun8i-a64-system-controller"
+ "allwinner,sun8i-a83t-system-controller"
+
+Example:
+syscon: syscon@01c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+ reg = <0x01c00000 0x1000>;
+};
--
2.10.2
^ permalink raw reply related
* [PATCH v4 03/18] dt-bindings: net: Add DT bindings documentation for Allwinner dwmac-sun8i
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
In-Reply-To: <20170412111400.2296-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/net/dwmac-sun8i.txt | 77 ++++++++++++++++++++++
1 file changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index 0000000..a0dca0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,77 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+ "allwinner,sun8i-a83t-emac"
+ "allwinner,sun8i-h3-emac"
+ "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+ - allwinner,sun8i-h3-system-controller
+ - allwinner,sun8i-a64-system-controller
+ - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
+Both delay properties need to be a multiple of 100.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet@1c0b000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c0b000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+};
--
2.10.2
^ permalink raw reply related
* [PATCH v4 02/18] net: stmmac: add optional setup function
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
In-Reply-To: <20170412111400.2296-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Instead of adding more ifthen logic for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
include/linux/stmmac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a89f76b..72d371d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3946,7 +3946,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
struct mac_device_info *mac;
/* Identify the MAC HW device */
- if (priv->plat->has_gmac) {
+ if (priv->plat->setup) {
+ mac = priv->plat->setup(priv);
+ } else if (priv->plat->has_gmac) {
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3921cb9..8bb550b 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -177,6 +177,7 @@ struct plat_stmmacenet_data {
void (*fix_mac_speed)(void *priv, unsigned int speed);
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
+ struct mac_device_info *(*setup)(void *priv);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
--
2.10.2
^ permalink raw reply related
* [PATCH v4 01/18] net: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
In-Reply-To: <20170412111400.2296-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 38f9430..67af0bd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -248,6 +248,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
data = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
writel(data, ioaddr + low);
}
+EXPORT_SYMBOL_GPL(stmmac_set_mac_addr);
/* Enable disable MAC RX/TX */
void stmmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -279,4 +280,4 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
addr[4] = hi_addr & 0xff;
addr[5] = (hi_addr >> 8) & 0xff;
}
-
+EXPORT_SYMBOL_GPL(stmmac_get_mac_addr);
--
2.10.2
^ permalink raw reply related
* [PATCH v4 00/18] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-04-12 11:13 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Corentin Labbe
Hello
This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
present on Allwinner H3/H5/A83T/A64 SoCs.
This driver is the continuation of the sun8i-emac driver.
During the development, it appeared that in fact the hardware was a modified
version of some dwmac.
So the driver is now written as a glue driver for stmmac.
It supports 10/100/1000 Mbit/s speed with half/full duplex.
It can use an internal PHY (MII 10/100) or an external PHY
via RGMII/RMII.
This patch series enable the driver only for the H3/A64/H5 SoC since A83T
doesn't have the necessary clocks present in mainline.
The driver have been tested on the following boards:
- H3 Orange PI PC, BananaPI-M2+
- A64 Pine64, BananaPi-M64
- A83T BananaPI-M3
The first two patchs are some mandatory changes for letting dwmac-sun8i be used.
The following three patchs add the driver and its documentation.
The remaining are DT patch enabling it.
Regards
Corentin Labbe
Changes since v3:
- Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps
- fix syscon compatible example
- Changed parameter type for setup() function
- Dropped some DT patchs for boards which I could not test further
Changes since v2:
- corrected order of syscon compatible
- added compatible = "ethernet-phy-ieee802.3-c22 to PHY
- added set_mac function
Changes since v1:
- added TX/RX delay units
- splitted syscon documentation in its own patch
- regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error
- Fixed a memory leak on mac_device_info
- Use now generic pin config for all DT stuff
- CONFIG_DWMAC_SUN8I is now set to y in defconfigs
Corentin Labbe (18):
net: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
net: stmmac: add optional setup function
dt-bindings: net: Add DT bindings documentation for Allwinner
dwmac-sun8i
dt-bindings: syscon: Add DT bindings documentation for Allwinner
syscon
net: stmmac: Add dwmac-sun8i
arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
arm: sun8i: orangepi-pc: Enable dwmac-sun8i
arm: sun8i: orangepi-2: Enable dwmac-sun8i
arm: sun8i: orangepi-one: Enable dwmac-sun8i
arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
arm64: allwinner: sun50i-a64: Add dt node for the syscon control
module
arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
arm: allwinner: pine64: Enable dwmac-sun8i
arm: allwinner: pine64-plus: Enable dwmac-sun8i
arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +
.../devicetree/bindings/net/dwmac-sun8i.txt | 77 ++
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 40 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 +-
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 43 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 960 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 29 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 2 +
20 files changed, 1268 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
--
2.10.2
^ permalink raw reply
* Re: [PATCH v4 5/7] dt-bindings: display/panel: Add common rotation property
From: Noralf Trønnes @ 2017-04-12 11:01 UTC (permalink / raw)
To: Laurent Pinchart, dri-devel; +Cc: thomas.petazzoni, devicetree, linux-kernel
In-Reply-To: <1802283.9kerWUhyh6@avalon>
Den 11.04.2017 07.29, skrev Laurent Pinchart:
> Hi Noralf,
>
> On Saturday 11 Feb 2017 19:48:56 Noralf Trønnes wrote:
>> Display panels can be oriented many ways, especially in the embedded
>> world. The rotation property is a way to describe this orientation.
>> The counter clockwise direction is chosen because that's what fbdev
>> and drm use.
>>
>> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
>> Acked-by: Thierry Reding <treding@nvidia.com>
>> ---
>>
>> Changes since version 3:
>> - Changed display/display.txt -> display/panel/panel.txt
>>
>> Documentation/devicetree/bindings/display/panel/panel.txt | 4 ++++
> We now have both Documentation/devicetree/bindings/display/panel/panel.txt and
> Documentation/devicetree/bindings/display/panel/panel-common.txt as they have
> been merged concurrently without being aware of each other. Would you mind if
> I moved this property to panel-common.txt ?
Not at all, please do.
> I would also like to document the property in a bit more details to avoid
> confusion about the rotation direction, as "display rotation" could be
> interpreted as the angle by which the display output has to be rotated to
> obtain an upside-up image. What would you think of the following, am I
> overdoing it, or is it even more confusing ?
I was more confused at least :-)
It's not important to me what the actual wording is, but I see that I
have used the word 'Display' which should have been 'Panel'.
Noralf.
> - rotation: Panels are commonly mounted rotated, with their native orientation
> not aligned with the device's orientation. The rotation property specifies the
> angle in degrees between the panel's orientation and the device's orientation
> (corresponding to a counter-clockwise rotation of the panel). Valid values are
> 0, 90, 180 and 270.
>
>
>> 1 file changed, 4 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/panel.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt
>> b/Documentation/devicetree/bindings/display/panel/panel.txt new file mode
>> 100644
>> index 0000000..e2e6867
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/panel.txt
>> @@ -0,0 +1,4 @@
>> +Common display properties
>> +-------------------------
>> +
>> +- rotation: Display rotation in degrees counter clockwise (0,90,180,270)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] PCI: hisi: Fix DT binding (hisi-pcie-almost-ecam)
From: Dongdong Liu @ 2017-04-12 10:24 UTC (permalink / raw)
To: helgaas, mark.rutland
Cc: linux-pci, devicetree, wangzhou1, gabriele.paoloni, linuxarm
In-Reply-To: <1490275097-39349-1-git-send-email-liudongdong3@huawei.com>
Hi Bjorn
This is a fixup for v4.11, and needs to go
through ASAP so as to avoid a release with the broken binding.
Please help to look at the patch.
Thanks,
Dongdong
在 2017/3/23 21:18, Dongdong Liu 写道:
> The "hisilicon,pcie-almost-ecam", which goes against the usual DT
> conventions, and is non-sensical in that it describes the IP based on
> what it isn't. Fix the DT binding with "hisilicon,hip06-pcie-ecam"
> and "hisilicon,hip07-pcie-ecam".
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
> Documentation/devicetree/bindings/pci/hisilicon-pcie.txt | 10 ++++++++--
> drivers/pci/dwc/pcie-hisi.c | 6 +++++-
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> index b7fa3b9..a339dbb 100644
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -44,13 +44,19 @@ Hip05 Example (note that Hip06 is the same except compatible):
> };
>
> HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description.
> +
> +Some BIOSes place the host controller in a mode where it is ECAM
> +compliant for all devices other than the root complex. In such cases,
> +the host controller should be described as below.
> +
> The properties and their meanings are identical to those described in
> host-generic-pci.txt except as listed below.
>
> Properties of the host controller node that differ from
> host-generic-pci.txt:
>
> -- compatible : Must be "hisilicon,pcie-almost-ecam"
> +- compatible : Must be "hisilicon,hip06-pcie-ecam", or
> + "hisilicon,hip07-pcie-ecam"
>
> - reg : Two entries: First the ECAM configuration space for any
> other bus underneath the root bus. Second, the base
> @@ -59,7 +65,7 @@ host-generic-pci.txt:
>
> Example:
> pcie0: pcie@a0090000 {
> - compatible = "hisilicon,pcie-almost-ecam";
> + compatible = "hisilicon,hip06-pcie-ecam";
> reg = <0 0xb0000000 0 0x2000000>, /* ECAM configuration space */
> <0 0xa0090000 0 0x10000>; /* host bridge registers */
> bus-range = <0 31>;
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index fd66a31..cf9d6a9 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -380,9 +380,13 @@ struct pci_ecam_ops hisi_pcie_platform_ops = {
>
> static const struct of_device_id hisi_pcie_almost_ecam_of_match[] = {
> {
> - .compatible = "hisilicon,pcie-almost-ecam",
> + .compatible = "hisilicon,hip06-pcie-ecam",
> .data = (void *) &hisi_pcie_platform_ops,
> },
> + {
> + .compatible = "hisilicon,hip07-pcie-ecam",
> + .data = (void *) &hisi_pcie_platform_ops,
> + },
> {},
> };
>
>
^ permalink raw reply
* [PATCH v2 2/2] regulator: tps65132: add device-tree binding
From: Venkat Reddy Talla @ 2017-04-12 10:15 UTC (permalink / raw)
To: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: vreddytalla-DDmLM1+adcrQT0dZR+AlfA,
ldewangan-DDmLM1+adcrQT0dZR+AlfA
Add tps65132 regulator device-tree binding documentation
Signed-off-by: Venkat Reddy Talla <vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes for v2:
- change dts property names
- add reg dts property
---
.../bindings/regulator/tps65132-regulator.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65132-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt b/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt
new file mode 100644
index 0000000..3a35055
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt
@@ -0,0 +1,46 @@
+TPS65132 regulators
+
+Required properties:
+- compatible: "ti,tps65132"
+- reg: I2C slave address
+
+Optional Subnode:
+Device supports two regulators OUTP and OUTN. A sub node within the
+ device node describe the properties of these regulators. The sub-node
+ names must be as follows:
+ -For regulator outp, the sub node name should be "outp".
+ -For regulator outn, the sub node name should be "outn".
+
+-enable-gpios:(active high, output) Regulators are controlled by the input pins.
+ If it is connected to GPIO through host system then provide the
+ gpio number as per gpio.txt.
+-active-discharge-gpios: (active high, output) Some configurations use delay mechanisms
+ on the enable pin, to keep the regulator enabled for some time after
+ the enable signal goes low. This GPIO is used to actively discharge
+ the delay mechanism. Requires specification of ti,active-discharge-time-us
+-ti,active-discharge-time-us: how long the active discharge gpio should be
+ asserted for during active discharge, in microseconds.
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps65132@3e {
+ compatible = "ti,tps65132";
+ reg = <0x3e>;
+
+ outp {
+ regulator-name = "outp";
+ regulator-boot-on;
+ regulator-always-on;
+ enable-gpios = <&gpio 23 0>;
+ };
+
+ outn {
+ regulator-name = "outn";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-active-discharge = <0>;
+ enable-gpios = <&gpio 40 0>;
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* 4.11-rc6 and OF_DYNAMIC
From: Tim Sander @ 2017-04-12 9:54 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi
I have been testing the 4.11-rc6 kernel on Intel(ex Altera) Arm SOC Cyclone
with dynamic Firmware loading. As i didn't know how to trigger dynamic
loading from userspace i also applied the following patch:
OF: DT-Overlay configfs interface
https://github.com/raspberrypi/linux/commit/8f1079750ce2fce4c4c2b4f8759ea57c8fb167d3
Now i got the loading of the devicetree overlay working :-)... but only if i enable
OF_UNITTEST. I find this a little strange especially as it slows boot time.
I also tried adding:
select OF_DYNAMIC
to my OF_CONFIGFS patch but this didn't help. Also patching away "if OF_UNITTEST"
config OF_DYNAMIC
- bool "Support for dynamic device trees" if OF_UNITTEST
+ bool "Support for dynamic device trees"
didn't help?
Besides these nitpicks i am really happy to see this in mainline as it really makes working with
dynamic fpga based hardware much cleaner!
Best regards
Tim
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-12 9:36 UTC (permalink / raw)
To: Neil Armstrong, Heiko Stübner
Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Sjoerd Simons, Wookey, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, John Reitan,
Enric Balletbo i Serra,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <e8ff3ab8-3bf8-d731-a987-3bb8442cfc0a-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Neil,
On 12/04/17 09:48, Neil Armstrong wrote:
> Hi Guillaume,
>
> On 04/12/2017 10:25 AM, Guillaume Tucker wrote:
>> Hi Heiko,
>>
>> On 11/04/17 21:52, Heiko Stübner wrote:
>>> Hi Guillaume,
>>>
>>> Am Dienstag, 11. April 2017, 18:40:37 CEST schrieb Guillaume Tucker:
>>>> On 03/04/17 09:12, Neil Armstrong wrote:
>>>>> On 04/02/2017 09:59 AM, Guillaume Tucker wrote:
>>>>>> +Optional:
>>>>>> +
>>>>>> +- clocks : Phandle to clock for the Mali Midgard device.
>>>>>> +- clock-names : Shall be "clk_mali".
>>>>>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>>>>>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>>>>>> +- operating-points : Refer to
>>>>>> Documentation/devicetree/bindings/power/opp.txt + for details.
>>>>>
>>>>> Please add :
>>>>> * Must be one of the following:
>>>>> "arm,mali-t820"
>>>>>
>>>>> * And, optionally, one of the vendor specific compatible:
>>>>> "amlogic,meson-gxm-mali"
>>>>>
>>>>> with my Ack for the amlogic platform.
>>>>
>>>> It seems to me that as long as the GPU architecture hasn't been
>>>> modified (I don't think I've ever encountered such a case) then
>>>> it has to be a standard ARM Mali type regardless of the SoC
>>>> vendor. So unless a Mali-T820 in the Amlogic S912 SoC is not the
>>>> same as a T820 in a different SoC, please forgive me but I don't
>>>> understand why a vendor compatible string is needed. My main
>>>> concern is that it's going to be very hard to keep that list
>>>> up-to-date with all existing Midgard SoC variants. If do we need
>>>> to add vendor compatible strings to correctly describe the
>>>> hardware then I'm happy to add the amlogic one in my patch v3; I
>>>> would just like to understand why that's necessary.
>>>
>>> SoC vendors in most cases hook ip blocks into their socs in different
>>> and often strange ways. After all it's not some discrete ic you solder
>>> onto a board, but instead a part of the soc itself.
>>
>> Thanks for your explanation. I see, it's really about special
>> things that are not supported by the standard Midgard kernel
>> driver.
>>
>>> So in most cases you will have some hooks outside the actual gpu iospace
>>> that can be used to tune different things about how the gpu interacts with
>>> the system. Which is probably also the reason the midgard kernel driver
>>> has this ugly "platform" subdirectory for compile-time platform selection.
>>
>> I see the "platform" directory approach as an old and deprecated
>> way of supporting platforms, upstreaming the dt bindings goes in
>> the direction of using solely the device tree to describe the GPU
>> hardware (i.e. CONFIG_MALI_PLATFORM_DEVICETREE). If something
>> quirky is needed in the platform, it should be possible to
>> support it outside the GPU driver (platform devfreq etc...).
>
> If this was so simple...
>
> This is why the "vendor" compatible is optional.
>
> And on another side, the binding were written by ARM, are may not be
> compatible with how the mainline Linux handles these uses-cases.
>
> ARM added some tweaks to handle some weird integration using DT properties,
> but this should definitely go in platform specific code instead.
OK, sorry I was approaching the issue from a completely different
and somewhat more idealistic angle. My impression is that if the
driver was in mainline then it would be maintained in such a way
that vendor compatible strings would not be required, but this is
all hypothetical.
So in practice, I think I now better understand why vendor
compatible strings may still be needed. And they're optional, so
harmless to other platforms, so it's all fine with me :)
>> Back to the original intent of enabling distros to make Mali GPU
>> driver packages, when using the device tree you can have a single
>> kernel driver package for all Midgard platforms. When using the
>> third-party platform sources approach, you need to make an extra
>> package for each one of them.
>
> Well, if the midgard driver was maintained in community-driven way, all vendor
> could actually push their platform code, but it's not the case and somehow
> never will.
>
>>
>> So if there is value in supporting platforms that absolutely
>> require something special due to their hardware GPU integration,
>> then yes I see why vendor dt bindings might be useful. However
>> it seems to me that this should really be an exception and
>> avoided whenever possible.
>
> I understand you would avoid changing the (horrible) way the midgard
> driver handles the DT...
>
> But ultimately, if we consider the eventual integration of the midgard
> driver in mainline kernel (because why not ?), the driver would need
> a complete re-write to conform the actual driver coding structure,
> and so would also need to conform to the DT mainline rules.
Yes, it's hard to have a discussion without a mainline driver to
back things up. So I understand the pragmatic approach here.
>>> On my rk3288 for example we have [0] in the chromeos tree, that handles
>>> the oddities of the midgard on the rk3288 used in a lot of Chromebooks.
>>> There are soc-specific oddities of frequencies, frequency-scaling and
>>> whatnot. And there are also more gpu-specific setting in syscon areas
>>> of the soc (pmu and grf) that can also influence the gpus performance
>>> and might need tweaking at some point.
>>
>> For the rk3288, this is purely a software implementation issue on
>> the chromeos-3.14 branch. With mainline kernel, you can use
>> devfreq and no platform files at all (that's how I tested these
>> dt bindings). So as far as I know, there's no need for a vendor
>> compatible string on rk3288.
>>
>>> That doesn't even take into account that there may even be differences
>>> on how things are synthesized that we don't know about. See all the
>>> variants of the dw_hdmi ip block (imx, rockchip, meson [more?]) .
>>
>> I'm not too familiar with that driver, just had a quick look and
>> it seems to be a different issue as there's a kernel config for
>> each platform to build separate driver modules. And it looks
>> like they are actually needed to cope with variants of the
>> hardware inside the display processor block, unlike with the Mali
>> GPU which in principle should always be the same. I've run this
>> Midgard driver without any platform files and using devfreq at
>> least on rk3288 Firefly, Exynos 5422 ODROID-XU3 and Juno and they
>> all have a vanilla Mali GPU hw block. It's just wired
>> differently in each SoC.
>
> Please, do not consider the "driver" in dt-bindings discussion, the
> way it's implemented is irrelevant here, but the way the IP is
> integrated is crucial.
> And trust me, HW designers and integrators are very very creative
> guys, and we *need* some platform code to handle integration corner
> cases not handled by the "IP" driver.
Sure, I know this happens... I can't help but think that if
something quirky is done in the SoC around the GPU then it
shouldn't need to be fixed in the GPU driver. But that's talking
about the "driver" again, so not relevant.
> In the case of "dw-hdmi", the "driver" acts like a "library" that
> can be used differently among the various platforms.
>
> I can talk about the "meson" Amlogic integration, in this particular
> case Amlogic used their owm PHY and wrapped all the stuff in a way
> we need to handle the PHY+HDMI+Wrapper in a single block and then
> connect it to the Video pipeline.
>
> For the midgard integration made by Amlogic, the vendor platform code
> uses tweaks to start the IP and initialize the clocks.
> And this code is part of the "amlogic,meson-gxm-mali" HW, not the
> "arm,midgard".
Can't this be done in the clock driver or some other early init
stage of the SoC? But again, that code is not in mainline so
it's a non-issue.
>>> So we really want to have the special compatibles in place, to be prepared
>>> for the future per-soc oddities that always appear :-) .
>>
>> How about aiming for the ideal case where vendor-specific things
>> are not needed and add them if and when they really become
>> inevitable and worth the cost?
>
> Trust me, an amlogic compatible is needed ;-)
Fair enough, will add the optional vendor compatible string in my
patch v3 :) Glad this was discussed though, thank you.
Guillaume
>>> [0] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/gpu/arm/midgard/platform/rk/
--
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 v5 0/4] gpio: mvebu: Add PWM fan support
From: Gregory CLEMENT @ 2017-04-12 9:11 UTC (permalink / raw)
To: Thierry Reding, Linus Walleij, Alexandre Courbot, Rob Herring,
Mark Rutland, Ralph Sennhauser
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Russell King,
linux-pwm, linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170409180931.4884-1-ralph.sennhauser@gmail.com>
Hi all,
On dim., avril 09 2017, Ralph Sennhauser <ralph.sennhauser@gmail.com> 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.
If the other maintainer agree I can apply the arm-soc related patch (2,
3 and 4) to my mvebu branches. Actually even if the gpio driver is not
merged yet, these patches won't hurt. The only things I would like to
check is that the binding won't change.
Thanks,
Gregory
>
> 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
> description of the situation. The only downside is some "wasted"
> space.
>
> About the new compatible string:
> Orion was chosen for the SoC variant for the same reason as in
> commit 5f79c651e81e ("arm: mvebu: use global interrupts for GPIOs on
> Armada XP").
> The "pwm" property remains optional for the new compatible string so
> the compatiple string "marvell,armada-370-xp-gpio" can be used by
> all and not just the first two GPIO chips. A property to select "Set
> A" / "Set B" registers could be invented though.
>
> ---
>
> Pending:
> * Needs ACK from Thierry Reding to be merged via linux-gpio tree by Linus
> Walleij. (fine with the general approach, requested changes which
> should have been taken care of now)
>
> ---
>
> Changes v4->v5:
> All
> * add Tested-by: Andrew Lunn <andrew@lunn.ch>, thanks
> Patch 2/4 mvebu: xp: Add PWM properties to .dtsi files
> * keep the old compatible stings, we don't have to drop them,
> therefore keep them (suggested by Gregory CLEMENT)
> * subject starts with ARM: dts: mvebu: (suggested by Gregory CLEMENT)
> Patch 4/4 mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
> * subject starts with ARM: dts: armada-xp: (suggested by Gregory CLEMENT)
>
> Changes v3->v4:
> Patch 1/4 gpio: mvebu: Add limited PWM support:
> * braces for both branches in if statement if one needs it. (suggested
> by Andrew Lunn)
> * introduce compatible string marvell,armada-370-xp-gpio (suggest by
> Rob Herring)
> * fix mvebu_pwmreg_blink_on_duration -> mvebu_pwmreg_blink_off_duration
> for period callculation in mvebu_pwm_get_state()
> Patch 4/4 mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
> * Drop flags from pwms for Mamba, as no longer used (suggested by
> Andrew Lunn)
> * Use again #pwm-cell = 2, the second cell is actually the period.
>
> Changes v2->v3:
> Patch 1/4 gpio: mvebu: Add limited PWM support:
> * drop pin from mvebu_pwn, can be infered (suggested by Thierry Reding)
> * rename pwm to mvpwm so pwm can be used for pwm_device as in the API,
> avoids some mental gymnastic.
> * drop id from struct mvebu_gpio_chip, select blink counter in
> mvebu_pwm_probe for all lines instead. We do not care about the
> unused ones. I think a clear improvement in readability.
> Makes coming up with a good comment simple as well.
> * Switch to new atomic PWM API (suggested by Thierry Reding)
> * rename use mvebu_gpioreg_blink_select to
> mvebu_gpioreg_blink_counter_select.
> * mark *_suspend() / *_resume() as __maybe_unused (suggested by Linus
> Walleij)
> * document #pwm-cells = 1 (suggested by Thierry Reding)
> Patch 2/4 mvebu: xp: Add PWM properties to .dtsi files
> * add missing reg-names / #pwm-cell properties to
> armada-xp-mv78260.dtsi gpio1 node
> * set pwm-cells = 1 (suggested by Thierry Reding)
> All:
> * always uppercase GPIO/PWM in prose (suggested by Thierry Reding)
>
> Changes v1 -> v2:
> Patch 1/4 gpio: mvebu: Add limited PWM support:
> * use BIT macro (suggested by Linus Walleij)
> * move id from struct mvebu_pwm to struct mvebu_gpio_chip, implement
> blink select as if else and comment on the chip id for code clarity
> (to accommodate Linus Walleijs request for a code clarification /
> comment. If you can word it better I'm all ears.)
> * Move function comment mvebu_pwm_probe into the function itself.
>
> ---
>
> Andrew Lunn (4):
> gpio: mvebu: Add limited PWM support
> ARM: dts: mvebu: Add PWM properties to .dtsi files
> ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
> ARM: dts: armada-xp: Use pwm-fan rather than gpio-fan
>
> .../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
> MAINTAINERS | 2 +
> arch/arm/boot/dts/armada-370.dtsi | 19 +-
> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 +-
> arch/arm/boot/dts/armada-xp-mv78230.dtsi | 16 +-
> arch/arm/boot/dts/armada-xp-mv78260.dtsi | 19 +-
> arch/arm/boot/dts/armada-xp-mv78460.dtsi | 19 +-
> arch/arm/configs/mvebu_v7_defconfig | 2 +
> drivers/gpio/gpio-mvebu.c | 324 ++++++++++++++++++++-
> 9 files changed, 405 insertions(+), 36 deletions(-)
>
> --
> 2.10.2
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
From: Sakari Ailus @ 2017-04-12 9:09 UTC (permalink / raw)
To: Steve Longerbeam
Cc: 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, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
nick-gcszYUEDH4VrovVCs/uTlw, markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
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-me
In-Reply-To: <e7368555-1644-4e8f-f355-6b07dc020f90-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Steve,
On Tue, Apr 11, 2017 at 05:50:58PM -0700, Steve Longerbeam wrote:
>
>
> On 04/04/2017 05:47 AM, Sakari Ailus wrote:
> >Hi Steve, Philipp and Pavel,
> >
> >On Mon, Mar 27, 2017 at 05:40:34PM -0700, Steve Longerbeam wrote:
> >>From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >>
> >>This driver can handle SoC internal and external video bus multiplexers,
> >>controlled either by register bit fields or by a GPIO. The subdevice
> >>passes through frame interval and mbus configuration of the active input
> >>to the output side.
> >
> >The MUX framework is already in linux-next. Could you use that instead of
> >adding new driver + bindings that are not compliant with the MUX framework?
> >I don't think it'd be much of a change in terms of code, using the MUX
> >framework appears quite simple.
>
> I would prefer to wait on this, and get what we have merged now so I can
> unload all these patches first.
The DT bindings will be different for this one and if you were using a MUX,
won't they? And you can't remove support for the existing bindings either,
you have to continue to support them going forward.
>
> Also this is Philipp's driver, so again I would prefer to get this
> merged as-is and then Philipp can address these issues in a future
> patch. But I will add my comments below...
I bet there will be more issues to handle if you were to do the changes
later than now.
...
> >>+static int vidsw_s_stream(struct v4l2_subdev *sd, int enable)
> >>+{
> >>+ struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> >>+ struct v4l2_subdev *upstream_sd;
> >>+ struct media_pad *pad;
> >>+
> >>+ if (vidsw->active == -1) {
> >>+ dev_err(sd->dev, "Can not start streaming on inactive mux\n");
> >>+ return -EINVAL;
> >>+ }
> >>+
> >>+ pad = media_entity_remote_pad(&sd->entity.pads[vidsw->active]);
> >>+ if (!pad) {
> >>+ dev_err(sd->dev, "Failed to find remote source pad\n");
> >>+ return -ENOLINK;
> >>+ }
> >>+
> >>+ if (!is_media_entity_v4l2_subdev(pad->entity)) {
> >>+ dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
> >>+ return -ENODEV;
> >>+ }
> >>+
> >>+ upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
> >>+
> >>+ return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
> >
> >Now that we'll have more than two drivers involved in the same pipeline it
> >becomes necessary to define the behaviour of s_stream() throughout the
> >pipeline --- i.e. whose responsibility is it to call s_stream() on the
> >sub-devices in the pipeline?
>
> In the case of imx-media, the capture device calls set stream on the
> whole pipeline in the start_streaming() callback. This subdev call is
> actually a NOOP for imx-media, because the upstream entity has already
> started streaming. Again I think this should be removed. It also
> enforces a stream order that some MC drivers may have a problem with.
What I want to say here is that the order in which the different devices in
the pipeline need to be started may not be known in a driver for a
particular part of the pipeline.
In order to avoid trying to have a single point of decision making, the
s_stream() op implemented in sub-device drivers should serve the purpose.
I'll cc you for the documentation patch.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: armada-38x: label USB and SATA nodes
From: Gregory CLEMENT @ 2017-04-12 9:01 UTC (permalink / raw)
To: Ralph Sennhauser
Cc: linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel
In-Reply-To: <20170408101626.14032-1-ralph.sennhauser@gmail.com>
Hi Ralph,
On sam., avril 08 2017, Ralph Sennhauser <ralph.sennhauser@gmail.com> wrote:
> Recently most nodes got labels to make them referenceable. The USB 3.0
> nodes as well as the nodes for the SATA controllers were left out,
> rectify the omission.
>
> The labels "sataX" are already used by some boards for the SATA ports,
> therefore use "ahciX" to label the SATA controller nodes.
>
> To avoid potential confusion by labeling an USB3.0 controller "usb2" use
> usb3_X as labels. This also coincides with the node names themselves
> (usb@xxxxx vs usb3@xxxxx).
>
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Applied on mvebu/dt
Thanks,
Gregory
> ---
>
> Hi everybody,
>
> Using satacX for controllers with satacXpY for ports might have been a
> possiblity, since ahciX is already used similarly (to avoid a conflict
> with current use of sataX) ahciX seems the better choice. Works well me
> thinks.
>
> The usb3_X labels still seem the best choice even though they aren't
> perfectly consitent, however, I don't see an alternative which would fit
> this requirement either.
>
> Regards
> Ralph
>
> ---
>
> Changes v1 -> v2:
> * use ahciX instead of satacX for the SATA controller nodes (suggested
> by Andrew Lunn)
>
>
> arch/arm/boot/dts/armada-38x.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
> index ba27ec1..8b165c3 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -530,7 +530,7 @@
> interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> - sata@a8000 {
> + ahci0: sata@a8000 {
> compatible = "marvell,armada-380-ahci";
> reg = <0xa8000 0x2000>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> @@ -546,7 +546,7 @@
> status = "disabled";
> };
>
> - sata@e0000 {
> + ahci1: sata@e0000 {
> compatible = "marvell,armada-380-ahci";
> reg = <0xe0000 0x2000>;
> interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> @@ -590,7 +590,7 @@
> status = "disabled";
> };
>
> - usb3@f0000 {
> + usb3_0: usb3@f0000 {
> compatible = "marvell,armada-380-xhci";
> reg = <0xf0000 0x4000>,<0xf4000 0x4000>;
> interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> @@ -598,7 +598,7 @@
> status = "disabled";
> };
>
> - usb3@f8000 {
> + usb3_1: usb3@f8000 {
> compatible = "marvell,armada-380-xhci";
> reg = <0xf8000 0x4000>,<0xfc000 0x4000>;
> interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> --
> 2.10.2
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Neil Armstrong @ 2017-04-12 8:48 UTC (permalink / raw)
To: Guillaume Tucker, Heiko Stübner
Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Sjoerd Simons, Wookey, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, John Reitan,
Enric Balletbo i Serra,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <7a875b2d-f288-8136-de04-11e744f0118b-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Hi Guillaume,
On 04/12/2017 10:25 AM, Guillaume Tucker wrote:
> Hi Heiko,
>
> On 11/04/17 21:52, Heiko Stübner wrote:
>> Hi Guillaume,
>>
>> Am Dienstag, 11. April 2017, 18:40:37 CEST schrieb Guillaume Tucker:
>>> On 03/04/17 09:12, Neil Armstrong wrote:
>>>> On 04/02/2017 09:59 AM, Guillaume Tucker wrote:
>>>>> +Optional:
>>>>> +
>>>>> +- clocks : Phandle to clock for the Mali Midgard device.
>>>>> +- clock-names : Shall be "clk_mali".
>>>>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>>>>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>>>>> +- operating-points : Refer to
>>>>> Documentation/devicetree/bindings/power/opp.txt + for details.
>>>>
>>>> Please add :
>>>> * Must be one of the following:
>>>> "arm,mali-t820"
>>>>
>>>> * And, optionally, one of the vendor specific compatible:
>>>> "amlogic,meson-gxm-mali"
>>>>
>>>> with my Ack for the amlogic platform.
>>>
>>> It seems to me that as long as the GPU architecture hasn't been
>>> modified (I don't think I've ever encountered such a case) then
>>> it has to be a standard ARM Mali type regardless of the SoC
>>> vendor. So unless a Mali-T820 in the Amlogic S912 SoC is not the
>>> same as a T820 in a different SoC, please forgive me but I don't
>>> understand why a vendor compatible string is needed. My main
>>> concern is that it's going to be very hard to keep that list
>>> up-to-date with all existing Midgard SoC variants. If do we need
>>> to add vendor compatible strings to correctly describe the
>>> hardware then I'm happy to add the amlogic one in my patch v3; I
>>> would just like to understand why that's necessary.
>>
>> SoC vendors in most cases hook ip blocks into their socs in different
>> and often strange ways. After all it's not some discrete ic you solder
>> onto a board, but instead a part of the soc itself.
>
> Thanks for your explanation. I see, it's really about special
> things that are not supported by the standard Midgard kernel
> driver.
>
>> So in most cases you will have some hooks outside the actual gpu iospace
>> that can be used to tune different things about how the gpu interacts with
>> the system. Which is probably also the reason the midgard kernel driver
>> has this ugly "platform" subdirectory for compile-time platform selection.
>
> I see the "platform" directory approach as an old and deprecated
> way of supporting platforms, upstreaming the dt bindings goes in
> the direction of using solely the device tree to describe the GPU
> hardware (i.e. CONFIG_MALI_PLATFORM_DEVICETREE). If something
> quirky is needed in the platform, it should be possible to
> support it outside the GPU driver (platform devfreq etc...).
If this was so simple...
This is why the "vendor" compatible is optional.
And on another side, the binding were written by ARM, are may not be
compatible with how the mainline Linux handles these uses-cases.
ARM added some tweaks to handle some weird integration using DT properties,
but this should definitely go in platform specific code instead.
>
> Back to the original intent of enabling distros to make Mali GPU
> driver packages, when using the device tree you can have a single
> kernel driver package for all Midgard platforms. When using the
> third-party platform sources approach, you need to make an extra
> package for each one of them.
Well, if the midgard driver was maintained in community-driven way, all vendor
could actually push their platform code, but it's not the case and somehow
never will.
>
> So if there is value in supporting platforms that absolutely
> require something special due to their hardware GPU integration,
> then yes I see why vendor dt bindings might be useful. However
> it seems to me that this should really be an exception and
> avoided whenever possible.
I understand you would avoid changing the (horrible) way the midgard
driver handles the DT...
But ultimately, if we consider the eventual integration of the midgard
driver in mainline kernel (because why not ?), the driver would need
a complete re-write to conform the actual driver coding structure,
and so would also need to conform to the DT mainline rules.
>
>> On my rk3288 for example we have [0] in the chromeos tree, that handles
>> the oddities of the midgard on the rk3288 used in a lot of Chromebooks.
>> There are soc-specific oddities of frequencies, frequency-scaling and
>> whatnot. And there are also more gpu-specific setting in syscon areas
>> of the soc (pmu and grf) that can also influence the gpus performance
>> and might need tweaking at some point.
>
> For the rk3288, this is purely a software implementation issue on
> the chromeos-3.14 branch. With mainline kernel, you can use
> devfreq and no platform files at all (that's how I tested these
> dt bindings). So as far as I know, there's no need for a vendor
> compatible string on rk3288.
>
>> That doesn't even take into account that there may even be differences
>> on how things are synthesized that we don't know about. See all the
>> variants of the dw_hdmi ip block (imx, rockchip, meson [more?]) .
>
> I'm not too familiar with that driver, just had a quick look and
> it seems to be a different issue as there's a kernel config for
> each platform to build separate driver modules. And it looks
> like they are actually needed to cope with variants of the
> hardware inside the display processor block, unlike with the Mali
> GPU which in principle should always be the same. I've run this
> Midgard driver without any platform files and using devfreq at
> least on rk3288 Firefly, Exynos 5422 ODROID-XU3 and Juno and they
> all have a vanilla Mali GPU hw block. It's just wired
> differently in each SoC.
Please, do not consider the "driver" in dt-bindings discussion, the
way it's implemented is irrelevant here, but the way the IP is
integrated is crucial.
And trust me, HW designers and integrators are very very creative
guys, and we *need* some platform code to handle integration corner
cases not handled by the "IP" driver.
In the case of "dw-hdmi", the "driver" acts like a "library" that
can be used differently among the various platforms.
I can talk about the "meson" Amlogic integration, in this particular
case Amlogic used their owm PHY and wrapped all the stuff in a way
we need to handle the PHY+HDMI+Wrapper in a single block and then
connect it to the Video pipeline.
For the midgard integration made by Amlogic, the vendor platform code
uses tweaks to start the IP and initialize the clocks.
And this code is part of the "amlogic,meson-gxm-mali" HW, not the
"arm,midgard".
>
>> So we really want to have the special compatibles in place, to be prepared
>> for the future per-soc oddities that always appear :-) .
>
> How about aiming for the ideal case where vendor-specific things
> are not needed and add them if and when they really become
> inevitable and worth the cost?
Trust me, an amlogic compatible is needed ;-)
Neil
>
> Thanks,
> Guillaume
>
>> [0] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/gpu/arm/midgard/platform/rk/
>
--
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-12 8:30 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,
linux-arm-kernel@lists.infradead.org, Benjamin GAIGNARD
In-Reply-To: <20170411211040.htrcedus3c57fbed@sirena.org.uk>
Hello Mark,
On 04/11/2017 11:10 PM, Mark Brown wrote:
> On Tue, Apr 11, 2017 at 03:44:52PM +0000, Olivier MOYSAN wrote:
>
>> However, regarding STM32 I2S driver, I'm wondering if selecting DAI
>> is the best way to configure interface as tx, rx or fd.
>
> Why do you even need to configure this?
>
The IP provides two data wires, SD in and SD out. So it can be
configured either as capture or playback only, or full-duplex.
This corresponds to a mode selection through a register configuration.
>> Maybe, it is more relevant to configure DAI according to DMA
>> configuration from I2S node.
>> This would moreover avoid to allocate 2 dmas channels when not
>> necessary (tx or rx only).
>> If you agree with this, I will implement this change in a v2.
>
> That sounds wrong, I'd expect this wiring to be done statically as part
> of the .dtsi for the SoC (or just grabbed as needed at runtime if
> things are flexbile enough) rather than being a configuration thing done
> per board... I had thought that this was configuration reflecting
> different ways of taping out the IP with different feature sets, is that
> not the case?
>
This configuration is board dependent. The IP may be used as rx, tx or
fd depending on board. So I think it can make sense to have a DMA
configuration linked to board, and to set IP mode accordingly.
BRs
olivier
^ permalink raw reply
* Re: [PATCH v5 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Linus Walleij @ 2017-04-12 8:26 UTC (permalink / raw)
To: Michael Hennerich
Cc: Wolfram Sang, Peter Rosin, Rob Herring, Mark Rutland,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491912976-8396-2-git-send-email-michael.hennerich@analog.com>
On Tue, Apr 11, 2017 at 2:16 PM, <michael.hennerich@analog.com> wrote:
> From: Michael Hennerich <michael.hennerich@analog.com>
>
> This patch adds support for the Analog Devices / Linear Technology
> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
> The LTC4306 optionally provides two general purpose input/output pins
> (GPIOs) that can be configured as logic inputs, opendrain outputs or
> push-pull outputs via the generic GPIOLIB framework.
>
> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
(...)
> Changes since v4:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Please go ahead and merge to the i2c tree if you like.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-12 8:25 UTC (permalink / raw)
To: Heiko Stübner
Cc: Neil Armstrong, Rob Herring, Mark Rutland, devicetree,
Sjoerd Simons, Wookey, linux-kernel, linux-rockchip, John Reitan,
Enric Balletbo i Serra, linux-arm-kernel
In-Reply-To: <8676554.1IW2xieEGM@diego>
Hi Heiko,
On 11/04/17 21:52, Heiko Stübner wrote:
> Hi Guillaume,
>
> Am Dienstag, 11. April 2017, 18:40:37 CEST schrieb Guillaume Tucker:
>> On 03/04/17 09:12, Neil Armstrong wrote:
>>> On 04/02/2017 09:59 AM, Guillaume Tucker wrote:
>>>> +Optional:
>>>> +
>>>> +- clocks : Phandle to clock for the Mali Midgard device.
>>>> +- clock-names : Shall be "clk_mali".
>>>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>>>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>>>> +- operating-points : Refer to
>>>> Documentation/devicetree/bindings/power/opp.txt + for details.
>>>
>>> Please add :
>>> * Must be one of the following:
>>> "arm,mali-t820"
>>>
>>> * And, optionally, one of the vendor specific compatible:
>>> "amlogic,meson-gxm-mali"
>>>
>>> with my Ack for the amlogic platform.
>>
>> It seems to me that as long as the GPU architecture hasn't been
>> modified (I don't think I've ever encountered such a case) then
>> it has to be a standard ARM Mali type regardless of the SoC
>> vendor. So unless a Mali-T820 in the Amlogic S912 SoC is not the
>> same as a T820 in a different SoC, please forgive me but I don't
>> understand why a vendor compatible string is needed. My main
>> concern is that it's going to be very hard to keep that list
>> up-to-date with all existing Midgard SoC variants. If do we need
>> to add vendor compatible strings to correctly describe the
>> hardware then I'm happy to add the amlogic one in my patch v3; I
>> would just like to understand why that's necessary.
>
> SoC vendors in most cases hook ip blocks into their socs in different
> and often strange ways. After all it's not some discrete ic you solder
> onto a board, but instead a part of the soc itself.
Thanks for your explanation. I see, it's really about special
things that are not supported by the standard Midgard kernel
driver.
> So in most cases you will have some hooks outside the actual gpu iospace
> that can be used to tune different things about how the gpu interacts with
> the system. Which is probably also the reason the midgard kernel driver
> has this ugly "platform" subdirectory for compile-time platform selection.
I see the "platform" directory approach as an old and deprecated
way of supporting platforms, upstreaming the dt bindings goes in
the direction of using solely the device tree to describe the GPU
hardware (i.e. CONFIG_MALI_PLATFORM_DEVICETREE). If something
quirky is needed in the platform, it should be possible to
support it outside the GPU driver (platform devfreq etc...).
Back to the original intent of enabling distros to make Mali GPU
driver packages, when using the device tree you can have a single
kernel driver package for all Midgard platforms. When using the
third-party platform sources approach, you need to make an extra
package for each one of them.
So if there is value in supporting platforms that absolutely
require something special due to their hardware GPU integration,
then yes I see why vendor dt bindings might be useful. However
it seems to me that this should really be an exception and
avoided whenever possible.
> On my rk3288 for example we have [0] in the chromeos tree, that handles
> the oddities of the midgard on the rk3288 used in a lot of Chromebooks.
> There are soc-specific oddities of frequencies, frequency-scaling and
> whatnot. And there are also more gpu-specific setting in syscon areas
> of the soc (pmu and grf) that can also influence the gpus performance
> and might need tweaking at some point.
For the rk3288, this is purely a software implementation issue on
the chromeos-3.14 branch. With mainline kernel, you can use
devfreq and no platform files at all (that's how I tested these
dt bindings). So as far as I know, there's no need for a vendor
compatible string on rk3288.
> That doesn't even take into account that there may even be differences
> on how things are synthesized that we don't know about. See all the
> variants of the dw_hdmi ip block (imx, rockchip, meson [more?]) .
I'm not too familiar with that driver, just had a quick look and
it seems to be a different issue as there's a kernel config for
each platform to build separate driver modules. And it looks
like they are actually needed to cope with variants of the
hardware inside the display processor block, unlike with the Mali
GPU which in principle should always be the same. I've run this
Midgard driver without any platform files and using devfreq at
least on rk3288 Firefly, Exynos 5422 ODROID-XU3 and Juno and they
all have a vanilla Mali GPU hw block. It's just wired
differently in each SoC.
> So we really want to have the special compatibles in place, to be prepared
> for the future per-soc oddities that always appear :-) .
How about aiming for the ideal case where vendor-specific things
are not needed and add them if and when they really become
inevitable and worth the cost?
Thanks,
Guillaume
> [0] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/gpu/arm/midgard/platform/rk/
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v2 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Lee Jones @ 2017-04-12 8:06 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel, linux-sunxi, Rob Herring, linux-kernel,
Liam Girdwood, devicetree, Maxime Ripard, Chen-Yu Tsai
In-Reply-To: <20170411180844.9176B125521-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
On Wed, 12 Apr 2017, Icenowy Zheng wrote:
>
> 2017年4月12日 上午12:29于 Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>写道：
> >
> > On Tue, 11 Apr 2017, Chen-Yu Tsai wrote:
> >
> > > Hi,
> > >
> > > On Tue, Apr 11, 2017 at 11:00 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> > > >
> > > >
> > > > On Tue, 11 Apr 2017, Lee Jones wrote:
> > > >
> > > >> On Sat, 08 Apr 2017, Icenowy Zheng wrote:
> > > >>
> > > >>> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> > > >>> bus.
> > > >>>
> > > >>> Add a compatible for it.
> > > >>>
> > > >>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > > >>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> > > >>> ---
> > > >>> Changes in v2:
> > > >>> - Place AXP803 before AXP806/809.
> > > >>> - Added Chen-Yu's ACK.
> > > >>>
> > > >>> Documentation/devicetree/bindings/mfd/axp20x.txt | 5 +++--
> > > >>> 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >>
> > > >>
> > > >> For my own reference:
> > > >> Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > >
> > > >
> > > > Excuse me... Who will apply this patch?
> >
> > Excuse you? Are you trying to be polite, or rude?
> >
> > I'm guessing due to the lagging '...', that it's the latter?
>
> Oh sorry, I mean the former...
Okay, no problem then.
> > > > I think this patch should be applied by you as it's in bindings/mfd
> > > > directory, however, if I'm wrong, please point out ;-)
> > >
> > > We need the DT maintainers to ack it first. :)
> >
> > We don't really need the DT Maintainers to get involved here.
> >
> > What I do need is either clear direction as to how this
> > patch-set should be applied, or an indication of which patches are
> > dependant on others and which are orthogonal and can be applied
> > independently.
>
> This patch is independent, although the regulator binding patch
> depends on it.
>
> The real driver patches will need the binding patches to be merged
> first.
Right, so Acking and not applying wasn't such a strange practice
after all then. =;-)
> And the dt patches depend on also the binding patches.
The issue I have now is; because your email client replies as a new
mail i.e. non-threaded, now I have no reference to the patch-set.
Since time is a valuable resource, I will not be dredging though my
inbox looking for all your replies.
Please fix your client before replying to another mail.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Lee Jones @ 2017-04-12 8:00 UTC (permalink / raw)
To: Daniel Lezcano
Cc: sboyd, mturquette, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <20170411211936.GT2078@mai>
On Tue, 11 Apr 2017, Daniel Lezcano wrote:
> On Tue, Apr 11, 2017 at 03:06:13PM +0100, Lee Jones wrote:
> > On Sat, 08 Apr 2017, Daniel Lezcano wrote:
> >
> > > The hi655x multi function device is a PMIC providing regulators.
> > >
> > > The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> > > this clock in order to add it in the hi655x MFD and allow proper wireless
> > > initialization.
> > >
> > > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > > ---
> > >
> > > Changelog:
> > >
> > > V2:
> > > - Added COMPILE_TEST option, compiled on x86
> > > - Removed useless parenthesis
> > > - Used of_clk_hw_simple_get() instead of deref dance
> > > - Do bailout if the clock-names is not specified
> > > - Rollback on error
> > > - Folded mfd line change and binding
> >
> > Why did you do that?
>
> I thought as the V1 had comments you would have waited for the V2 and as it was
> trivial enough, it could be folded and picked up via the clk tree via with your
> acked-by.
It's *always* a good idea to keep patches subsystem orthogonal if
at all possible.
> I realize it was not a good idea.
>
> Do you want to drop it from your tree or shall I resubmit a V3 without the mfd
> change?
The latter please.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 1/3] mfd: max8998: Remove CONFIG_OF around max8998_dt_match
From: Lee Jones @ 2017-04-12 7:59 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Nicolas Ferre,
Rob Herring, Frank Rowand, open list:NETWORKING DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
In-Reply-To: <20170412044156.17351-2-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, 11 Apr 2017, Florian Fainelli wrote:
> A subsequent patch is going to make of_match_node() an inline stub when
> CONFIG_OF is disabled which will properly take care of having the compiler
> eliminate the variable. To avoid more #ifdef/#else, just always make the match
> table available.
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/mfd/max8998.c | 2 --
> 1 file changed, 2 deletions(-)
If it works, great!
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c
> index 4c33b8063bc3..372f681ec1bb 100644
> --- a/drivers/mfd/max8998.c
> +++ b/drivers/mfd/max8998.c
> @@ -129,14 +129,12 @@ int max8998_update_reg(struct i2c_client *i2c, u8 reg, u8 val, u8 mask)
> }
> EXPORT_SYMBOL(max8998_update_reg);
>
> -#ifdef CONFIG_OF
> static const struct of_device_id max8998_dt_match[] = {
> { .compatible = "maxim,max8998", .data = (void *)TYPE_MAX8998 },
> { .compatible = "national,lp3974", .data = (void *)TYPE_LP3974 },
> { .compatible = "ti,lp3974", .data = (void *)TYPE_LP3974 },
> {},
> };
> -#endif
>
> /*
> * Only the common platform data elements for max8998 are parsed here from the
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 01/20] net: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
From: Corentin Labbe @ 2017-04-12 7:42 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <9514c077-1738-ea49-ca18-fbc46bac6144-qxv4g6HH51o@public.gmane.org>
On Mon, Apr 03, 2017 at 02:39:03PM +0200, Giuseppe CAVALLARO wrote:
> Hello Alex
>
> do you can check if this has to be done for ST platforms?
> I do not remember that it was necessary when build as module so
> I cannot expect this should be only for dwmac-sun8i.
>
> Regards
> peppe
>
dwmac-sun8i is simply the first "user" of stmmac_[sg]et_mac_addr outside of stmmac-objs
Regards
--
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 v5 3/3] DT nodes for Broadcom Northstar2 USB DRD Phy
From: Raviteja Garimella @ 2017-04-12 7:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kishon Vijay Abraham I, Ray Jui,
Scott Branden, Jon Mason, Catalin Marinas, Will Deacon
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1491981125-6859-1-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
This patch adds device tree nodes for USB Dual Role Device Phy for
Broadcom's Northstar2 SoC.
Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index bcb03fc..c71f330 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -436,6 +436,20 @@
};
};
+ usbdrd_phy: phy@66000960 {
+ #phy-cells = <0>;
+ compatible = "brcm,ns2-drd-phy";
+ reg = <0x66000960 0x24>,
+ <0x67012800 0x4>,
+ <0x6501d148 0x4>,
+ <0x664d0700 0x4>;
+ reg-names = "icfg", "rst-ctrl",
+ "crmu-ctrl", "usb2-strap";
+ id-gpios = <&gpio_g 30 0>;
+ vbus-gpios = <&gpio_g 31 0>;
+ status = "disabled";
+ };
+
pwm: pwm@66010000 {
compatible = "brcm,iproc-pwm";
reg = <0x66010000 0x28>;
--
2.1.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
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