[PATCH v6 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173

[Chunfeng Yun]

add xHCI and phy drivers for MT8173-EVB

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi| 44 +
 2 files changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index f433c21..112f3f3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -13,6 +13,7 @@
  */
 
 /dts-v1/;
+#include 
 #include "mt8173.dtsi"
 
 / {
@@ -32,6 +33,15 @@
};
 
chosen { };
+
+   usb_p1_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
 &pwrap {
@@ -211,3 +221,9 @@
 &uart0 {
status = "okay";
 };
+
+&usb30 {
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p1_vbus>;
+   mediatek,wakeup-src = <1>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..f88b2f9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include "mt8173-pinfunc.h"
 
@@ -393,6 +395,48 @@
#size-cells = <0>;
status = "disabled";
};
+
+   usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x4000>,
+ <0 0x1128 0 0x0800>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
+   usb3-lpm-capable;
+   mediatek,syscon-wakeup = <&pericfg>;
+   status = "okay";
+   };
+
+   u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   phy_port0: port@11290800 {
+   reg = <0 0x11290800 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   phy_port1: port@11291000 {
+   reg = <0 0x11291000 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+   };
};
 };
 
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs

[Chunfeng Yun]

support usb3.0 phy of mt65xx SoCs

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/Kconfig   |   9 +
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-mt65xx-usb3.c | 456 ++
 3 files changed, 466 insertions(+)
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c0e6ede..019cf8b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA
help
  Support for SATA PHY on Hisilicon hix5hd2 Soc.
 
+config PHY_MT65XX_USB3
+   tristate "Mediatek USB3.0 PHY Driver"
+   depends on ARCH_MEDIATEK && OF
+   select GENERIC_PHY
+   help
+ Say 'Y' here to add support for Mediatek USB3.0 PHY driver
+ for mt65xx SoCs. it supports two usb2.0 ports and
+ one usb3.0 port.
+
 config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f344e1b..3ceff2a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)+= 
phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
 obj-$(CONFIG_PHY_EXYNOS5250_SATA)  += phy-exynos5250-sata.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
+obj-$(CONFIG_PHY_MT65XX_USB3)  += phy-mt65xx-usb3.o
 obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
 obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
 obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
new file mode 100644
index 000..7510fda
--- /dev/null
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -0,0 +1,456 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Chunfeng Yun 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * for sifslv2 register, but exclude port's;
+ * relative to USB3_SIF2_BASE base address
+ */
+#define SSUSB_SIFSLV_SPLLC 0x
+
+/* offsets of sub-segment in each port registers */
+#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
+#define SSUSB_SIFSLV_U3PHYD_BASE   0x0100
+#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
+#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+
+#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
+#define PA0_RG_U2PLL_FORCE_ON  BIT(15)
+
+#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008)
+#define PA2_RG_SIF_U2PLL_FORCE_EN  BIT(18)
+
+#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define PA5_RG_U2_HSTX_SRCTRL  (0x7 << 12)
+#define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
+#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
+
+#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
+#define PA6_RG_U2_ISO_EN   BIT(31)
+#define PA6_RG_U2_BC11_SW_EN   BIT(23)
+#define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
+
+#define U3P_U2PHYACR4  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
+#define P2C_RG_USB20_GPIO_CTL  BIT(9)
+#define P2C_USB20_GPIO_MODEBIT(8)
+#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
+
+#define U3D_U2PHYDCR0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060)
+#define P2C_RG_SIF_U2PLL_FORCE_ON  BIT(24)
+
+#define U3P_U2PHYDTM0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068)
+#define P2C_FORCE_UART_EN  BIT(26)
+#define P2C_FORCE_DATAIN   BIT(23)
+#define P2C_FORCE_DM_PULLDOWN  BIT(21)
+#define P2C_FORCE_DP_PULLDOWN  BIT(20)
+#define P2C_FORCE_XCVRSEL  BIT(19)
+#define P2C_FORCE_SUSPENDM BIT(18)
+#define P2C_FORCE_TERMSEL  BIT(17)
+#define P2C_RG_DATAIN  (0xf << 10)
+#define P2C_RG_DATAIN_VAL(x)   ((0xf & (x)) << 10)
+#define P2C_RG_DMPULLDOWN  BIT(7)
+#define P2C_RG_DPPULLDOWN  BIT(6)
+#define P2C_RG_XCVRSEL (0x3 << 4)
+#define P2C_RG_XCVRSEL_VAL(x)  ((0x3 & (x)) << 4)
+#define P2C_RG_SUSPENDMBIT(3)
+#define P2C_RG_TERMSEL BIT(2)
+#define P2C_DTM0_PART_MASK \
+   (P2C_FORCE_DATAIN | P2C_FORCE_DM_PULLDOWN | \
+   P2C_FORCE_DP_PULLDOWN | P2C_FORCE_XCVRSEL | \
+   P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \
+   P2C_RG_DPPULLDOWN | P2C_

[PATCH v6 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

[Chunfeng Yun]

add a DT binding documentation of usb3.0 phy for MT65xx
SoCs from Mediatek.

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
new file mode 100644
index 000..5812d20
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -0,0 +1,69 @@
+mt65xx USB3.0 PHY binding
+--
+
+This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+
+Required properties (controller (parent) node):
+ - compatible  : should be "mediatek,mt8173-u3phy"
+ - reg : offset and length of register for phy, exclude port's
+ register.
+ - clocks  : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "u3phya_ref": for reference clock of usb3.0 analog phy.
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology. These nodes are translated
+ by the driver's .xlate() function.
+
+Required properties (port (child) node):
+- reg  : address and length of the register set for the port.
+- #phy-cells   : should be 1 (See second example)
+ cell after port phandle is phy type from:
+   - PHY_TYPE_USB2
+   - PHY_TYPE_USB3
+
+Example:
+
+u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   phy_port0: port@11290800 {
+   reg = <0 0x11290800 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   phy_port1: port@11291000 {
+   reg = <0 0x11291000 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+};
+
+Specifying phy control of devices
+-
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type;
+phy-names for each port are optional.
+
+Example:
+
+#include 
+
+usb30: usb@1127 {
+   ...
+   phys = <&phy_port0 PHY_TYPE_USB3>;
+   phy-names = "usb3-0";
+   ...
+};
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 4/5] xhci: mediatek: support MTK xHCI host controller

[Chunfeng Yun]

MTK xhci host controller defines some extra SW scheduling
parameters for HW to minimize the scheduling effort for
synchronous and interrupt endpoints. The parameters are
put into reseved DWs of slot context and endpoint context

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/Kconfig|   9 +
 drivers/usb/host/Makefile   |   4 +
 drivers/usb/host/xhci-mtk-sch.c | 436 +
 drivers/usb/host/xhci-mtk.c | 831 
 drivers/usb/host/xhci-mtk.h | 133 +++
 drivers/usb/host/xhci-ring.c|  35 +-
 drivers/usb/host/xhci.c |  19 +-
 drivers/usb/host/xhci.h |   1 +
 8 files changed, 1461 insertions(+), 7 deletions(-)
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..358ab6d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -34,6 +34,15 @@ config USB_XHCI_PCI
 config USB_XHCI_PLATFORM
tristate
 
+config USB_XHCI_MTK
+   tristate "xHCI support for Mediatek MT65xx"
+   select MFD_SYSCON
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Mediatek MT65xx SoCs.
+ If unsure, say N.
+
 config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
select USB_XHCI_PLATFORM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 754efaa..00401f9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -13,6 +13,9 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
+ifneq ($(CONFIG_USB_XHCI_MTK), )
+   xhci-hcd-y += xhci-mtk-sch.o
+endif
 
 xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
@@ -30,6 +33,7 @@ endif
 
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
 
 obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
new file mode 100644
index 000..d4b41a6
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,436 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author:
+ *  Zhigang.Wei 
+ *  Chunfeng.Yun 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 
+#include 
+#include 
+
+#include "xhci.h"
+#include "xhci-mtk.h"
+
+#define SS_BW_BOUNDARY 51000
+/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
+#define HS_BW_BOUNDARY 6144
+/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
+#define FS_PAYLOAD_MAX 188
+
+/* mtk scheduler bitmasks */
+#define EP_BPKTS(p)((p) & 0x3f)
+#define EP_BCSCOUNT(p) (((p) & 0x7) << 8)
+#define EP_BBM(p)  ((p) << 11)
+#define EP_BOFFSET(p)  ((p) & 0x3fff)
+#define EP_BREPEAT(p)  (((p) & 0x7fff) << 16)
+
+static int is_fs_or_ls(enum usb_device_speed speed)
+{
+   return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+   struct usb_host_endpoint *ep)
+{
+   int bw_index;
+   int port_id;
+   struct xhci_virt_device *virt_dev;
+
+   virt_dev = xhci->devs[udev->slot_id];
+   port_id = virt_dev->real_port;
+
+   if (udev->speed == USB_SPEED_SUPER) {
+   if (usb_endpoint_dir_out(&ep->desc))
+   bw_index = (port_id - 1) * 2;
+   else
+   bw_index = (port_id - 1) * 2 + 1;
+   } else {
+   bw_index = port_id + xhci->num_usb3_ports - 1;
+   }
+
+   return bw_index;
+}
+
+static void setup_sch_info(struct usb_device *udev,
+   struct xhci_ep_ctx *ep_ctx, struct mu3h_sch_ep_info *sch_ep)
+{
+   u32 ep_type;
+   u32 ep_interval;
+   u32 max_packet_size;
+   u32 max_burst;
+   u32 mult;
+   u32 esit_pkts;
+
+   ep_type = CTX_TO_EP_TYPE(le32_to_cpu(ep_ctx->ep_info2));
+   ep_interval = CTX_TO_EP_INTERVAL(le32_to_cpu(ep_ctx->ep_info));
+   max_packet_size = MAX_PACKET_DECODED(le32_to_cpu(ep_ctx->ep_info2));
+   max_burst = CTX_TO_MAX_BURST(le32_to_cpu(ep_ctx->ep_info2));
+   mult = CTX_TO_EP_MULT(le32_to_cpu(ep_ctx->ep_info));
+
+   sch_ep->ep_type = ep_type;
+   sch

[PATCH v6 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[Chunfeng Yun]

add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..8e6e463
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,52 @@
+mt65XX xHCI
+
+The device node for Mediatek SOC usb3.0 host controller
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   the first one for MAC, the second for IPPC
+ - interrupts : interrupt used by the controller
+ - power-domains : a phandle to USB power domain node to control usb's
+   mtcmos
+ - vusb33-supply : regulator of usb avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain
+   "sys_ck": for clock of xHCI MAC
+   "wakeup_deb_p0": for usb wakeup debounce clock of port0
+   "wakeup_deb_p0": for usb wakeup debounce clock of port1
+
+ - phys : a list of phandle + phy specifier pairs
+ - usb3-lpm-capable : supports USB3 LPM
+ - mediatek,syscon-wakeup : phandle to syscon used to access usb wakeup
+   control register
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
+   mode; others means don't enable wakeup source of usb
+
+Optional properties:
+ - vbus-supply : Reference to the VBUS regulator;
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x4000>,
+ <0 0x1128 0 0x0800>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+   clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <&phy_port0 PHY_TYPE_USB3>,
+  <&phy_port1 PHY_TYPE_USB2>;
+   vusb33-supply = <&mt6397_vusb_reg>;
+   vbus-supply = <&usb_p1_vbus>;
+   usb3-lpm-capable;
+   mediatek,syscon-wakeup = <&pericfg>;
+   mediatek,wakeup-src = <1>;
+   status = "okay";
+};
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mediatek xHCI support

[Chunfeng Yun]

>From 4cab60015fd73f37b7c970ba56c2625fe346fcf3 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Sat, 22 Aug 2015 09:35:14 +0800
Subject: [PATCH v6 0/5] Mediatek xHCI support

The patch supports MediaTek's xHCI controller.

There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.

2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.

3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.

A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.

Change in v6:
1. get register base address of port in probe instead of of_xlate
2. enable clock in phy_init instead of probe

Change in v5:
1. descripte more exactly for each specifiers in xHCI binding
2. make use of new multi-phy feature for phy driver

Change in v4:
1. descripte more exactly for each specifiers in binding file
2. use BIT() to define a bit mask mcro

Change in v3:
1. implement generic phy
2. move opperations for IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue

Change in v2:
1. Rebase to 4.2-rc1
2. Remove probe phy before add usb_hcd patch from this series due to 4.2-rc1
   already fix this issue
3. add xhci mac clocks
4. add suspend/resume
5. support remote wakeup


Chunfeng Yun (5):
  dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
  dt-bindings: Add a binding for Mediatek xHCI host controller
  usb: phy: add usb3.0 phy driver for mt65xx SoCs
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI & usb phy for mt8173

 .../devicetree/bindings/phy/phy-mt65xx-usb.txt |  69 ++
 .../devicetree/bindings/usb/mt8173-xhci.txt|  52 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|  16 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  44 ++
 drivers/phy/Kconfig|   9 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-mt65xx-usb3.c  | 456 +++
 drivers/usb/host/Kconfig   |   9 +
 drivers/usb/host/Makefile  |   4 +
 drivers/usb/host/xhci-mtk-sch.c| 436 +++
 drivers/usb/host/xhci-mtk.c| 831 +
 drivers/usb/host/xhci-mtk.h| 133 
 drivers/usb/host/xhci-ring.c   |  35 +-
 drivers/usb/host/xhci.c|  19 +-
 drivers/usb/host/xhci.h|   1 +
 15 files changed, 2108 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

--
1.8.1.1.dirty


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: shmobile: silk: add SDHI1 DT support

[Sergei Shtylyov]

On 08/21/2015 11:57 PM, Sergei Shtylyov wrote:


Define the SILK board dependent part of the SDHI1 (connected to micro-SD slot)
device nodes along with the necessary voltage regulators.

Based on the original patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
This patch is against 'renesas-devel-20150810-v4.2-rc6' tag of Simon Horman's
'renesas.git' repo plus the R8A7794/SILK QSPI patches just re-posted. It needs
the R8A7794 GPIO patches in order to compile.

Changes in version 2:
- removed not working SDHI0 stuff, renamed the patch;
- replaced SDHI1's "wp-gpios" property with "disable-wp".


I am wondering if you could explain the motivation for the "disable-wp"
update


Please see the comment in mmc_sd_get_ro().


and weather it is appropriate for other r8a779* dts files.


In case of micro-SD slots, yes.


   The MMC binding document says it should only be specified if the 
controller has WP detection logic. We, so far, seem to have been replying on 
the GPIOs despite this logic is present (according to the R-Car gen2 SDHI 
manuals I have). The driver will first call mmc_gpio_get_ro() and when that 
fails due to "wp-gpios" not being specified, it proceeds to reading the 
register but that is forbidden by TMIO_MMC_WRPROTECT_DISABLE flag set for the 
R-Car gen1/2 chips, so 0 is always returned from tmio_mmc_get_ro(). There 
seems to be no point in going that far (and doing the runtime PM dances) --
and MMC_CAP2_NO_WRITE_PROTECT (set when "disable-wp" is specified) prohibits 
doing that...


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: shmobile: silk: add SDHI1 DT support

[Sergei Shtylyov]

On 08/12/2015 04:26 AM, Simon Horman wrote:


Define the SILK board dependent part of the SDHI1 (connected to micro-SD slot)
device nodes along with the necessary voltage regulators.

Based on the original patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
This patch is against 'renesas-devel-20150810-v4.2-rc6' tag of Simon Horman's
'renesas.git' repo plus the R8A7794/SILK QSPI patches just re-posted. It needs
the R8A7794 GPIO patches in order to compile.

Changes in version 2:
- removed not working SDHI0 stuff, renamed the patch;
- replaced SDHI1's "wp-gpios" property with "disable-wp".


I am wondering if you could explain the motivation for the "disable-wp"
update


   Please see the comment in mmc_sd_get_ro().


and weather it is appropriate for other r8a779* dts files.


   In case of micro-SD slots, yes.


Thanks.


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Input: edt-ft5x06 - Switch to newer gpio framework

[Franklin S Cooper Jr]

The current/old gpio framework used doesn't properly listen to
ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
account these flags when setting gpio values.

Also use gpiod_set_value_cansleep since wake and reset pins can be
provided by bus based io expanders.

Signed-off-by: Franklin S Cooper Jr 
---
 .../bindings/input/touchscreen/edt-ft5x06.txt  |   4 +-
 drivers/input/touchscreen/edt-ft5x06.c | 115 +++--
 include/linux/input/edt-ft5x06.h   |   4 +-
 3 files changed, 43 insertions(+), 80 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 76db967..9330d4d 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -50,6 +50,6 @@ Example:
pinctrl-0 = <&edt_ft5x06_pins>;
interrupt-parent = <&gpio2>;
interrupts = <5 0>;
-   reset-gpios = <&gpio2 6 1>;
-   wake-gpios = <&gpio4 9 0>;
+   reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
+   wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
};
diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
b/drivers/input/touchscreen/edt-ft5x06.c
index 394b1de..6b128b3 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
u16 num_x;
u16 num_y;
 
-   int reset_pin;
-   int irq_pin;
-   int wake_pin;
+   struct gpio_desc *reset_pin;
+   struct gpio_desc *wake_pin;
+   struct gpio_desc *irq_pin;
 
 #if defined(CONFIG_DEBUG_FS)
struct dentry *debug_dir;
@@ -755,36 +755,14 @@ edt_ft5x06_ts_teardown_debugfs(struct edt_ft5x06_ts_data 
*tsdata)
 static int edt_ft5x06_ts_reset(struct i2c_client *client,
struct edt_ft5x06_ts_data *tsdata)
 {
-   int error;
-
-   if (gpio_is_valid(tsdata->wake_pin)) {
-   error = devm_gpio_request_one(&client->dev,
-   tsdata->wake_pin, GPIOF_OUT_INIT_LOW,
-   "edt-ft5x06 wake");
-   if (error) {
-   dev_err(&client->dev,
-   "Failed to request GPIO %d as wake pin, error 
%d\n",
-   tsdata->wake_pin, error);
-   return error;
-   }
-
+   if (tsdata->wake_pin) {
msleep(5);
-   gpio_set_value(tsdata->wake_pin, 1);
+   gpiod_set_value_cansleep(tsdata->wake_pin, 1);
}
-   if (gpio_is_valid(tsdata->reset_pin)) {
-   /* this pulls reset down, enabling the low active reset */
-   error = devm_gpio_request_one(&client->dev,
-   tsdata->reset_pin, GPIOF_OUT_INIT_LOW,
-   "edt-ft5x06 reset");
-   if (error) {
-   dev_err(&client->dev,
-   "Failed to request GPIO %d as reset pin, error 
%d\n",
-   tsdata->reset_pin, error);
-   return error;
-   }
 
+   if (tsdata->reset_pin) {
msleep(5);
-   gpio_set_value(tsdata->reset_pin, 1);
+   gpiod_set_value_cansleep(tsdata->reset_pin, 1);
msleep(300);
}
 
@@ -931,30 +909,6 @@ edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data *tsdata)
}
 }
 
-#ifdef CONFIG_OF
-static int edt_ft5x06_i2c_ts_probe_dt(struct device *dev,
-   struct edt_ft5x06_ts_data *tsdata)
-{
-   struct device_node *np = dev->of_node;
-
-   /*
-* irq_pin is not needed for DT setup.
-* irq is associated via 'interrupts' property in DT
-*/
-   tsdata->irq_pin = -EINVAL;
-   tsdata->reset_pin = of_get_named_gpio(np, "reset-gpios", 0);
-   tsdata->wake_pin = of_get_named_gpio(np, "wake-gpios", 0);
-
-   return 0;
-}
-#else
-static inline int edt_ft5x06_i2c_ts_probe_dt(struct device *dev,
-   struct edt_ft5x06_ts_data *tsdata)
-{
-   return -ENODEV;
-}
-#endif
-
 static int edt_ft5x06_ts_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
@@ -964,6 +918,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
struct input_dev *input;
int error;
char fw_version[EDT_NAME_LEN];
+   struct gpio_desc *gpio;
 
dev_dbg(&client->dev, "probing for EDT FT5x06 I2C\n");
 
@@ -973,34 +928,41 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
return -ENOMEM;
}
 
-   if (!pdata) {
-   error = edt_ft5x06_i2c_ts_probe_dt(&client->dev, tsdata)

Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

[Mark Rutland]

On Wed, Aug 19, 2015 at 10:37:35AM +0100, Leo Yan wrote:
> On Hi6220, below memory regions in DDR have specific purpose:
> 
>   0x05e0, - 0x05ef,: For MCU firmware using at runtime;
>   0x0740,f000 - 0x0740,: For MCU firmware's section;
>   0x06df,f000 - 0x06df,: For mailbox message data.
> 
> This patch reserves these memory regions and add device node for
> mailbox in dts.
> 
> Signed-off-by: Leo Yan 
> ---
>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20 +---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  8 
>  2 files changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index e36a539..d5470d3 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -7,9 +7,6 @@
>  
>  /dts-v1/;
>  
> -/*Reserved 1MB memory for MCU*/
> -/memreserve/ 0x05e0 0x0010;
> -
>  #include "hi6220.dtsi"
>  
>  / {
> @@ -28,4 +25,21 @@
>   device_type = "memory";
>   reg = <0x0 0x0 0x0 0x4000>;
>   };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + mcu-buf@05e0 {
> + no-map;
> + reg = <0x0 0x05e0 0x0 0x0010>,  /* MCU firmware 
> buffer */
> +   <0x0 0x0740f000 0x0 0x1000>;  /* MCU firmware 
> section */
> + };
> +
> + mbox-buf@06dff000 {
> + no-map;
> + reg = <0x0 0x06dff000 0x0 0x1000>;  /* Mailbox 
> message buf */
> + };
> + };

As far as I can see, it would be simpler to simply carve these out of the
memory node.

I don't see why you need reserved-memory here, given you're not referring to
these regions by phandle anyway.

Thanks,
Mark.


>  };
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 3f03380..9ff25bc 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -167,5 +167,13 @@
>   clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
>   clock-names = "uartclk", "apb_pclk";
>   };
> +
> + mailbox: mailbox@f751 {
> + #mbox-cells = <1>;
> + compatible = "hisilicon,hi6220-mbox";
> + reg = <0x0 0xf751 0x0 0x1000>, /* IPC_S */
> +   <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
> + interrupts = ;
> + };
>   };
>  };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dts: keystone: Change "ti,davinci-i2c" compatible to "ti,keystone-i2c"

[Mark Rutland]

On Fri, Aug 21, 2015 at 10:47:06AM +0100, Alexander Sverdlin wrote:
> Now as "i2c-davinci" driver has special handling for Keystone it's time to 
> switch
> the device tree to use new "compatible" property.
> 
> Signed-off-by: Alexander Sverdlin 
> ---
>  arch/arm/boot/dts/keystone.dtsi |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
> index 72816d6..a846597 100644
> --- a/arch/arm/boot/dts/keystone.dtsi
> +++ b/arch/arm/boot/dts/keystone.dtsi
> @@ -106,7 +106,7 @@
>   };
>  
>   i2c0: i2c@253 {
> - compatible = "ti,davinci-i2c";
> + compatible = "ti,keystone-i2c";

>From what I understand of the previous patch, this is effectively an
optimisation, and things worked to some extent with the "ti,davinci-i2c"
string.

So could you leave that as a fallback, i.e. have:

compatible = "ti,keystone-i2c", "ti,davinci-i2c";

That way an old kernel still functions with this DT, which among other things
makes debugging and bisecting far easier.

Or are things actually broken with the "ti,davinci-i2c" string?

Thanks,
Mark
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 43/52] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

[Yinghai Lu]

On Fri, Aug 21, 2015 at 11:18 AM, Rob Herring  wrote:
> On Fri, Aug 21, 2015 at 1:20 AM, Yinghai Lu  wrote:
>> For device resource PREF bit setting under bridge 64-bit pref resource,
>> we need to make sure only set PREF for 64bit resource, so set
>> IORESOUCE_MEM_64 for 64bit resource during OF device resource flags
>> parsing.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
>> Signed-off-by: Yinghai Lu 
>> Cc: Grant Likely 
>> Cc: Rob Herring 
>> Cc: devicetree@vger.kernel.org
>
> My comment from v1[1] is not addressed still.
>
>
> [1] https://lkml.org/lkml/2015/7/10/736

| As the BZ says, we have several identical functions. Can we fix the
| drivers/of/address.c version and remove the Sparc versions. The only
| diff is the generic version converts from be32. I think that should be
| a nop for Sparc.

That would be better to let guys with Sparc or other OF arch to do the
unification.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 43/52] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

[Rob Herring]

On Fri, Aug 21, 2015 at 1:20 AM, Yinghai Lu  wrote:
> For device resource PREF bit setting under bridge 64-bit pref resource,
> we need to make sure only set PREF for 64bit resource, so set
> IORESOUCE_MEM_64 for 64bit resource during OF device resource flags
> parsing.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
> Signed-off-by: Yinghai Lu 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: devicetree@vger.kernel.org

My comment from v1[1] is not addressed still.

Rob

[1] https://lkml.org/lkml/2015/7/10/736

> ---
>  drivers/of/address.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..073125f 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -128,9 +128,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 
> *addr)
> flags |= IORESOURCE_IO;
> break;
> case 0x02: /* 32 bits */
> -   case 0x03: /* 64 bits */
> flags |= IORESOURCE_MEM;
> break;
> +   case 0x03: /* 64 bits */
> +   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
> +   break;
> }
> if (w & 0x4000)
> flags |= IORESOURCE_PREFETCH;
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCv3] arm64: dts: Add base stratix 10 dtsi

[dinguyen]

From: Dinh Nguyen 

Add the base DTS for Altera's SoCFPGA Stratix 10 platform.

Signed-off-by: Dinh Nguyen 
---
v3: change #address-cells and #size-cells to <2>
change the GIC address to 0xfffc1000
update the GIC virtual CPU reg length to 0x2000
v2: use interrupt-affinity for pmu node
---
 arch/arm64/Kconfig |   5 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/altera/Makefile|   5 +
 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  | 358 +
 .../boot/dts/altera/socfpga_stratix10_socdk.dts|  38 +++
 arch/arm64/configs/defconfig   |   1 +
 6 files changed, 408 insertions(+)
 create mode 100644 arch/arm64/boot/dts/altera/Makefile
 create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
 create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 318175f..0f8ab2b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -207,6 +207,11 @@ config ARCH_SEATTLE
help
  This enables support for AMD Seattle SOC Family
 
+config ARCH_STRATIX10
+   bool "Altera's Stratix 10 SoCFPGA Family"
+   help
+ This enables support for Altera's Stratix 10 SoCFPGA Family
+
 config ARCH_TEGRA
bool "NVIDIA Tegra SoC Family"
select ARCH_HAS_RESET_CONTROLLER
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 38913be..7fb421a 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
 dts-dirs += arm
diff --git a/arch/arm64/boot/dts/altera/Makefile 
b/arch/arm64/boot/dts/altera/Makefile
new file mode 100644
index 000..d7a6416
--- /dev/null
+++ b/arch/arm64/boot/dts/altera/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_STRATIX10) += socfpga_stratix10_socdk.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
new file mode 100644
index 000..d5f51a5
--- /dev/null
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -0,0 +1,358 @@
+/*
+ * Copyright Altera Corporation (C) 2015. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/dts-v1/;
+
+/ {
+   compatible = "altr,socfpga-stratix10";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x0>;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x1>;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x2>;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x3>;
+   };
+   };
+
+   pmu {
+   compatible = "arm,armv8-pmuv3";
+   interrupts = <0 120 8>,
+<0 121 8>,
+<0 122 8>,
+<0 123 8>;
+   interrupt-affinity = <&cpu0>,
+<&cpu1>,
+<&cpu2>,
+<&cpu3>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   intc: intc@fffc1000 {
+   compatible = "arm,gic-400", "arm,cortex-a15-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x0 0xfffc1000 0x1000>,
+ <0x0 0xfffc2000 0x2000>,
+ 

Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation

[Moritz Fischer]

Hi all,

sorry for HTML mail spam last night ... couple of nits below

On Wed, Aug 5, 2015 at 8:19 PM, Punnaiah Choudary Kalluri
 wrote:
> Device-tree binding documentation for Xilinx zynqmp dma engine used in
> Zynq UltraScale+ MPSoC.
>
> Signed-off-by: Punnaiah Choudary Kalluri 
> ---
> Changes in v4:
> - None
> Changes in v3:
> - None
> Changes in v2:
> - None
> ---
>  .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  |   61 
> 
>  1 files changed, 61 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt 
> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> new file mode 100644
> index 000..e4f92b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> @@ -0,0 +1,61 @@
> +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
> +memory to device and device to memory transfers. It also has flow
> +control and rate control support for slave/peripheral dma access.

How about: The Xilinx ZynqMP DMA engine does support memory to memory transfers,
memory to device and device to memory transfers. It also has flow
control and rate control
support for slave / peripheral DMA access.
> +
> +Required properties:
> +- compatible: Should be "xlnx,zynqmp-dma-1.0"
> +- #dma-cells: Should be <1>, a single cell holding a line request number
> +- reg: Memory map for module access
> +- interrupt-parent: Interrupt controller the interrupt is routed through
> +- interrupts: Should contain DMA channel interrupt
> +- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
> +
> +Optional properties:
> +- xlnx,include-sg: Indicates the controller to operate in simple or scatter
> +  gather dma mode
s/dma/DMA
> +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
> +source AXI transaction
> +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data
(Maybe) s/Tells/Determines/
> +- xlnx,src-issue: Number of AXI outstanding transactions on source side
> +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
> +   descriptor read are marked Non-coherent
(Maybe) s/Tells/Determines/
> +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
> +   source descriptor payload are marked Non-coherent
same
> +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
> +   dst descriptor payload are marked Non-coherent
> +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
> +- xlnx,src-axi-qos: AXI QOS bits to be used for data read
> +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
> +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
> +- xlnx,desc-axi-cache: AXI cache bits to be used for data read
> +- xlnx,desc-axi-cache: AXI cache bits to be used for data write
> +- xlnx,src-burst-len: AXI length for data read. Support only power of 2 
> values
> + i.e 1,2,4,8 and 16
> +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 
> values
> + i.e 1,2,4,8 and 16
> +
> +Example:
> +
> +fpd_dma_chan1: dma@FD50 {
> +   compatible = "xlnx,zynqmp-dma-1.0";
> +   reg = <0x0 0xFD50 0x1000>;
> +   #dma_cells = <1>;
#dma-cells = <1>;
> +   interrupt-parent = <&gic>;
> +   interrupts = <0 117 4>;
> +   xlnx,bus-width = <128>;
> +   xlnx,include-sg;
> +   xlnx,overfetch;
> +   xlnx,ratectrl = <0>;
> +   xlnx,src-issue = <16>;
> +   xlnx,desc-axi-cohrnt;
> +   xlnx,src-axi-cohrnt;
> +   xlnx,dst-axi-cohrnt;
> +   xlnx,desc-axi-qos = <0>;
> +   xlnx,desc-axi-cache = <0>;
> +   xlnx,src-axi-qos = <0>;
> +   xlnx,src-axi-cache = <2>;
> +   xlnx,dst-axi-qos = <0>;
> +   xlnx,dst-axi-cache = <2>;
> +   xlnx,src-burst-len = <4>;
> +   xlnx,dst-burst-len = <4>;
> +};
> --
> 1.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Cheers,

Moritz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] doc: dt: Add interrupt parent to Xilinx AXI DMA instantation example.

[Moritz Fischer]

This patch adds 'interrupt-parent' properties to the instantation example in
the docs for the devicetree bindings of the Xilinx AXI DMA driver.

Signed-off-by: Moritz Fischer 
---
 Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index 2291c40..7c956e9 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -19,6 +19,7 @@ Required child node properties:
 - compatible: It should be either "xlnx,axi-dma-mm2s-channel" or
"xlnx,axi-dma-s2mm-channel".
 - interrupts: Should contain per channel DMA interrupts.
+- interrupt-parent: Should contain interrupt parent.
 - xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
 
@@ -36,11 +37,13 @@ axi_dma_0: axidma@4040 {
dma-channel@4040 {
compatible = "xlnx,axi-dma-mm2s-channel";
interrupts = < 0 59 4 >;
+   interrupt-parent = <&intc>;
xlnx,datawidth = <0x40>;
} ;
dma-channel@40400030 {
compatible = "xlnx,axi-dma-s2mm-channel";
interrupts = < 0 58 4 >;
+   interrupt-parent = <&intc>;
xlnx,datawidth = <0x40>;
} ;
 } ;
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC

[Bjorn Andersson]

On Fri 21 Aug 03:32 PDT 2015, Varadarajan Narayanan wrote:

> Add initial dts files and SoC support for IPQ40XX
> 
> Signed-off-by: Varadarajan Narayanan 
> ---
> Changes in v2:
>   - Added devicetree bindings documentation
> 
>  .../devicetree/bindings/clock/qca,gcnt.txt | 14 
>  Documentation/devicetree/bindings/ipq.txt  | 16 
>  arch/arm/boot/dts/Makefile |  3 +-
>  arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts| 33 +
>  arch/arm/boot/dts/qcom-ipq40xx.dtsi| 86 
> ++
>  arch/arm/configs/ipq_defconfig |  1 +
>  arch/arm/mach-qcom/Kconfig |  4 +
>  arch/arm/mach-qcom/board.c |  1 +
>  8 files changed, 157 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/qca,gcnt.txt
>  create mode 100644 Documentation/devicetree/bindings/ipq.txt
>  create mode 100644 arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
>  create mode 100644 arch/arm/boot/dts/qcom-ipq40xx.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/clock/qca,gcnt.txt 
> b/Documentation/devicetree/bindings/clock/qca,gcnt.txt
> new file mode 100644
> index 000..dd0d71e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qca,gcnt.txt
> @@ -0,0 +1,14 @@
> +QCA Global Counter

I don't think I've seen the "global counter" blocks before, what is it?
What does it do? Do you have a upcoming driver for it? (Have I just
missed it?)

You add it to the dts below, but don't seem to reference it. What is
its purpose?

Also, you should split this definition into its own patch.

> +
> +
> +Required properties :
> +- compatible : "qcom,qca-gcnt"
> +
> +- reg : shall contain base register location and length
> +
> +Example:
> +
> + counter {
> + compatible = "qcom,qca-gcnt";
> + reg = <0x004a1000 0x4>;

Most of the time when there's a device consuming one register it turns
out to be part of some larger hw block and down the road things get
complicated from the fact that we mapped 4 bytes in the middle.

Is this part of a larger block? Can we better implement that as a
simple-mfd or syscon?

> + };
> diff --git a/Documentation/devicetree/bindings/ipq.txt 
> b/Documentation/devicetree/bindings/ipq.txt
> new file mode 100644
> index 000..7d56bd0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ipq.txt

This doesn't really follow the general pattern of this directory. There
are some files like this, but then you should probably name it
qualcomm.txt.

> @@ -0,0 +1,16 @@
> +Qualcomm IPQ device tree bindings
> +-
> +
> +System on Chip
> +
> +Device tree must specify which SoC it uses, with one of the
> +following compatible strings
> +
> +   "qcom,ipq40xx"
> +
> +Platform
> +
> +Device tree must specify which Platform it uses, with one of the
> +following compatible strings
> +
> +   "qcom,ipq40xx-r3pc"

I would expect an "ipq.txt" to contain "qcom,ipq8064-ap148" and
"qcom,ipq8064" as well.

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 246473a..6b4caee 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -477,7 +477,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>   qcom-ipq8064-ap148.dtb \
>   qcom-msm8660-surf.dtb \
>   qcom-msm8960-cdp.dtb \
> - qcom-msm8974-sony-xperia-honami.dtb
> + qcom-msm8974-sony-xperia-honami.dtb \
> + qcom-ipq40xx-r3pc.dtb

Please insert your entry alphabetically.

>  dtb-$(CONFIG_ARCH_REALVIEW) += \
>   arm-realview-pb1176.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> diff --git a/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts 
> b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
> new file mode 100644
> index 000..7e4e629
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
> @@ -0,0 +1,33 @@
> +/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "qcom-ipq40xx.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. IPQ40XX R3PC";
> + compatible = "qcom,ipq40xx-r3pc", "qcom,ipq40xx";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512MB */
> + };
> +
> + chosen {
> + bootargs = "root=/dev/ram rw init=/init 
> console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246";
> + };
> +
> + soc {
> + serial@78b {
> +  

Re: [PATCH v2 1/5] clocksource: mediatek: do not enable GPT_CLK_EVT when setup

[Yingjoe Chen]

On Thu, 2015-08-20 at 16:28 +0200, Daniel Lezcano wrote:
> On 08/17/2015 04:10 PM, Yingjoe Chen wrote:
> > On Thu, 2015-08-13 at 10:35 +0200, Daniel Lezcano wrote:
> >> On 07/22/2015 10:14 AM, Yingjoe Chen wrote:
> >>> Spurious mtk timer interrupt is noticed at boot and cause kernel
> >>> crash. It seems if GPT is enabled, it will latch irq status even
> >>> when its IRQ is disabled.
> 
> It "seems" ?

Hi,

Datasheet doesn't mention detail. So I did some experiments, playing
around with registers. Based on my observation, I think this is what
happens:

For each GPT timer, it has ENABLE, IRQ_EN, IRQ status, IRQ_ACK, counter
& compare.

When mtk_timer_init calls mtk_timer_setup to setup GPT_CLK_EVT, it
enable the timer but didn't set counter or compare. Both counter &
compare is zero on reset, so GPT immediately raise IRQ status. IRQ_EN is
still disabled now, so it didn't trigger interrupt right away.

At end of mtk_timer_init, it calls mtk_timer_enable_irq to enable irq.
Since IRQ status is 1 now, GPT trigger interrupt immediately. The
interrupt is serviced by mtk_timer_interrupt. Since this is not an
expected event, evt->dev.event_handler will be NULL and system crashed
in the handler.

> >>> When irq is enabled afterward, we see
> >>> spurious interrupt.
> 
> Doesn't have the firmware something to do with that ?

We have 6 GPT on mt8173, mtk timer use 2 of them. The spurious interrupt
only happens on GPT_CLK_EVT (GPT1). Our firmware didn't touch that one,
so it is in reset default when mtk timer driver try to enable it.

> I have a mtk 8173 board I can use next week. How do you reproduce the 
> issue ?
>
> >>> Change init flow to only enable GPT_CLK_SRC at mtk_timer_init.
> >>>
> >>> Acked-by: Matthias Brugger 
> >>> Reviewed-by: Daniel Kurtz 
> >>> Signed-off-by: Yingjoe Chen 
> >>> ---
> >>>
> >>> Update to my patch [1], added __init as Daniel suggest. This is the
> >>> only patch that need to change in that series, so I only sent this one.
> >>>
> >>> http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001545.html
> >>>
> >>>drivers/clocksource/mtk_timer.c | 16 ++--
> >>>1 file changed, 10 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/clocksource/mtk_timer.c 
> >>> b/drivers/clocksource/mtk_timer.c
> >>> index 68ab423..2ba5b66 100644
> >>> --- a/drivers/clocksource/mtk_timer.c
> >>> +++ b/drivers/clocksource/mtk_timer.c
> >>> @@ -156,9 +156,11 @@ static void mtk_timer_global_reset(struct 
> >>> mtk_clock_event_device *evt)
> >>>   writel(0x3f, evt->gpt_base + GPT_IRQ_ACK_REG);
> >>>}
> >>>
> >>> -static void
> >>> -mtk_timer_setup(struct mtk_clock_event_device *evt, u8 timer, u8 option)
> >>> +static void __init mtk_timer_setup(struct mtk_clock_event_device *evt,
> >>> +u8 timer, u8 option, bool enable)
> >>>{
> >>> + u32 val;
> >>> +
> >>>   writel(TIMER_CTRL_CLEAR | TIMER_CTRL_DISABLE,
> >>>   evt->gpt_base + TIMER_CTRL_REG(timer));
> >>>
> >>> @@ -167,8 +169,10 @@ mtk_timer_setup(struct mtk_clock_event_device *evt, 
> >>> u8 timer, u8 option)
> >>>
> >>>   writel(0x0, evt->gpt_base + TIMER_CMP_REG(timer));
> >>>
> >>> - writel(TIMER_CTRL_OP(option) | TIMER_CTRL_ENABLE,
> >>> - evt->gpt_base + TIMER_CTRL_REG(timer));
> >>> + val = TIMER_CTRL_OP(option);
> >>> + if (enable)
> >>> + val |= TIMER_CTRL_ENABLE;
> >>> + writel(val, evt->gpt_base + TIMER_CTRL_REG(timer));
> >>
> >> Instead of the 'enable' new option, I prefer a test with 'timer' with a
> >> comment:
> >>
> >>/*
> >> * the timer hw is broken in that way ... bla bla, so we only
> >> * enable the clocksource ...
> >> */
> >>if (timer == GPT_CLK_SRC)
> >>val |= TIMER_CTRL_ENABLE;
> >
> > Hi Daniel,
> >
> > Thanks for your review.
> > Since this bug happens to anyone using interrupt,
> 
> Can you elaborate ? I don't get the point.
> 
> > I'm not sure checking
> > timer and only enable it for GPT_CLK_SRC is easier to read. Anyway, I'll
> > change to this in next version.
> >> That said, can you have a look at commit 1096be08 ?
> >> "clockevents: sun5i: Fix setup_irq init sequence"
> >>
> >> first and check if moving the interrupt request after the
> >> clockevents_config_and_register could fix your issue.
> >
> > I've tested this before, see:
> >
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000539.html
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000551.html
> 
> I could take or ack this patch trusting it fixes the issue but there are 
> some points that need clarifications.
> 
>   - Does the spurious interrupt occurs *every* time ? at each boot ?

Yes. If you applied this series to enable mtk timer without this fix on
mt8173 or mt8135 you can reproduce it. It occurs for every boot.

It crash before uart driver is ready, so you'll have to use earlycon to
see the crash log.

> The previous patches were supposed to fix the issue but 

RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support

[Gabriele Paoloni]

Hi Liviu

Many Thanks for reviewing

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Liviu Dudau
> Sent: Friday, August 21, 2015 2:43 PM
> To: Gabriele Paoloni
> Cc: Lucas Stach; Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com;
> Pratyush Anand; Arnd Bergmann; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; Lorenzo Pieralisi; James Morse;
> ja...@lakedaemon.net; r...@kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> 
> On Thu, Aug 20, 2015 at 12:10:24PM +0100, Gabriele Paoloni wrote:
> > Hi Lucas
> >
> > Again many thanks for explaining and for your time.
> >
> > I got your point now and I have dug a bit better in the PCI_DOMAINS
> code.
> >
> > However I have a question...see inline below
> >
> > > -Original Message-
> > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > Sent: Thursday, August 20, 2015 9:27 AM
> > > To: Gabriele Paoloni
> > > Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> Anand;
> > > Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> > > electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> > > liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> > > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> > > Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> > >
> > > Hi Gab,
> > >
> > > Am Mittwoch, den 19.08.2015, 16:34 + schrieb Gabriele Paoloni:
> > > > Hi Lucas
> > > >
> > > > First of all many thanks for the quick reply, really appreciated
> > > >
> > > > > -Original Message-
> > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > > > Sent: Wednesday, August 19, 2015 4:37 PM
> > > > > To: Gabriele Paoloni
> > > > > Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> > > Anand;
> > > > > Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> > > > > electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> > > > > liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org;
> linux-
> > > > > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > > > qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu
> (Kenneth)
> > > > > Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> > > > >
> > > > > Hi Gab,
> > > > >
> > > > > Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele
> Paoloni:
> > > > > > Hi Lucas
> > > > > >
> > > > > > I have rewritten the patch to take into account multiple
> > > controllers.
> > > > > >
> > > > > > As you can see now there is a static var in
> dw_pcie_host_init()
> > > that
> > > > > tracks
> > > > > > the bus numbers used.
> > > > >
> > > > > This is wrong. The DT specifies the valid bus number range. You
> can
> > > not
> > > > > just assign the next free bus number to the root bus.
> > > >
> > > > I think this is what is being done in
> > > > http://lxr.free-
> electrons.com/source/arch/arm/kernel/bios32.c#L495
> > > > and currently designware assigns the root bus number in
> > > > http://lxr.free-electrons.com/source/drivers/pci/host/pcie-
> > > designware.c#L730
> > > >
> > > You found the right spot. It works a bit different than I remember,
> but
> > > is less broken than your current code. :)
> > >
> > > It actually assigns the next instance a root bus number behind the
> > > current instances bus range. Please note the difference to your
> code
> > > which assigns the next free bus number, which may still lay within
> the
> > > current instances bus range.
> 
> Hi Gabriele,
> 
> >
> > Mmmm here I have done a mistake: in the current designware the number
> of hw
> > controllers is always 1
> > http://lxr.free-electrons.com/source/drivers/pci/host/pcie-
> designware.c#L510
> > So the loop in bios32.c does not work on multiple PCIe ports...
> 
> Bios32.c is broken for multiple PCIe hosts for multiple reasons, this
> is just
> one of them. Hence the effort to get rid of it for maintained drivers.

As you can see we're pushing hard for this :)

> 
> > However your comment about PCI_DOMAINS enlightened my mind and now I
> see
> > that when CONFIG_PCI_DOMAINS is defined we have the domains numbers
> > (tracked by __domain_nr).
> 
> CONFIG_PCI_DOMAINS in itself doesn't do much without adding code to
> your driver.
> You could request a new domain for each controller with a special
> property to
> disable that behaviour in the dts, or you could enable
> CONFIG_PCI_DOMAINS_GENERIC
> which will give you a new domain automatically.

So far I see th

Re: 答复: [PATCH 1/5] net: add Hisilicon Network Subsystem support (config and documents)

[Arnd Bergmann]

On Monday 17 August 2015 01:28:07 Liguozhu wrote:
> Thanks, Arnd. 
> 
> Regarding the ae-name: it is the name of the Acceleration Engine. It is 
> provided
> by the BIOS according to the position and the feature enabled of the IP.
> So "soc0" means it is on SoC No. 0, while "n4" means it is running on 
>"Non-dsaf mode 4". Ideally, we should setup the rule to name it. But as I
> said in the patchset, the IP is original designed for a bare metal solution,
> it is worthless to export all modes and we are planning to add more mode
> for Linux itself in the IP in future version. So I think the better way is
> to leave it as a "name" but add more meaning in the future.

The name property is a bit awkward. The position is normally implied by
the location of the parent device in the DT, so you should not need that
at all and instead derive it elsewhere. You can also add strings to the
compatible property instead of this, to signify differences in the programming
that are based on how the IP block is used.
 
> Regarding the ae-opts: it is the initial value for the AE's runtime options,
> Currently, we have only "port number" (there are 6XGE+2GE port for a DSAF AE)
> as option. But for future version, we will add other options such as "enable
> Spanning Tree Protocol algorithm)" and so on. 

I think these can easily be converted into an index property and boolean
flags (present if true, absent otherwise) for additional features.
 
> Should I add these background to somewhere?

The binding document needs to list all supported configurations, if you
have a string property, describe specifically what strings are allowed
and what they mean, but better try to avoid strings altogether.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] net: add Hisilicon Network Subsystem MDIO support

[Arnd Bergmann]

On Monday 17 August 2015 17:17:50 Kenneth Lee wrote:
> Thanks, Arnd, 
> 
> You are right. This is the same IP as hip04_mdio.c. We just mis-understand the
> hardware design. We will merge them and re-submit the patches.

Ok, great!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support

[Liviu Dudau]

On Thu, Aug 20, 2015 at 12:10:24PM +0100, Gabriele Paoloni wrote:
> Hi Lucas
> 
> Again many thanks for explaining and for your time.
> 
> I got your point now and I have dug a bit better in the PCI_DOMAINS code.
> 
> However I have a question...see inline below
> 
> > -Original Message-
> > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > Sent: Thursday, August 20, 2015 9:27 AM
> > To: Gabriele Paoloni
> > Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush Anand;
> > Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> > electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> > liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> > Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> > 
> > Hi Gab,
> > 
> > Am Mittwoch, den 19.08.2015, 16:34 + schrieb Gabriele Paoloni:
> > > Hi Lucas
> > >
> > > First of all many thanks for the quick reply, really appreciated
> > >
> > > > -Original Message-
> > > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > > Sent: Wednesday, August 19, 2015 4:37 PM
> > > > To: Gabriele Paoloni
> > > > Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> > Anand;
> > > > Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> > > > electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> > > > liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> > > > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > > qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> > > > Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> > > >
> > > > Hi Gab,
> > > >
> > > > Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele Paoloni:
> > > > > Hi Lucas
> > > > >
> > > > > I have rewritten the patch to take into account multiple
> > controllers.
> > > > >
> > > > > As you can see now there is a static var in dw_pcie_host_init()
> > that
> > > > tracks
> > > > > the bus numbers used.
> > > >
> > > > This is wrong. The DT specifies the valid bus number range. You can
> > not
> > > > just assign the next free bus number to the root bus.
> > >
> > > I think this is what is being done in
> > > http://lxr.free-electrons.com/source/arch/arm/kernel/bios32.c#L495
> > > and currently designware assigns the root bus number in
> > > http://lxr.free-electrons.com/source/drivers/pci/host/pcie-
> > designware.c#L730
> > >
> > You found the right spot. It works a bit different than I remember, but
> > is less broken than your current code. :)
> > 
> > It actually assigns the next instance a root bus number behind the
> > current instances bus range. Please note the difference to your code
> > which assigns the next free bus number, which may still lay within the
> > current instances bus range.

Hi Gabriele,

> 
> Mmmm here I have done a mistake: in the current designware the number of hw
> controllers is always 1
> http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L510
> So the loop in bios32.c does not work on multiple PCIe ports...

Bios32.c is broken for multiple PCIe hosts for multiple reasons, this is just
one of them. Hence the effort to get rid of it for maintained drivers.

> However your comment about PCI_DOMAINS enlightened my mind and now I see
> that when CONFIG_PCI_DOMAINS is defined we have the domains numbers
> (tracked by __domain_nr).

CONFIG_PCI_DOMAINS in itself doesn't do much without adding code to your driver.
You could request a new domain for each controller with a special property to
disable that behaviour in the dts, or you could enable 
CONFIG_PCI_DOMAINS_GENERIC
which will give you a new domain automatically.

> So (correct me if I am wrong) if we have 2 PCIe ports that do not specify
> the "bus-range" property, both root ports will enumerate starting from 
> root_bus_nr = 0 and everything will still work ok.

Correct.

Best regards,
Liviu

> 
> So if my assumption is correct, I do not see why the orginal patch from Wang 
> Zhou is wrong. 
> The only point can be that assigning pp->root_bus_nr = 0 is not required 
> as pp memory is kzalloc'ed (an therefore init to zero).
> 
> 
> > 
> > >
> > > In general I agree with you but if you look at all the current
> > drivers
> > > based on designware none of them define the "bus-range" dtb property.
> > > Therefore doing as you say would break the current driver when we
> > have
> > > multiple controllers...am I right?
> > >
> > The current _code_ works fine for multiple controllers. It's just that
> > you must define the bus range property in the DTB if you want to enable
> > multiple instances of one controller and support a kernel without PCI
> > domains support. As all c

[PATCH v4 0/3] Add support for touchscreen on Colibri VF50

[Sanchayan Maity]

Hello,

The patchset adds support for 4 wire touchscreen on Toradex Colibri
VF50 modules.

Thanks Dmitry for your feedback.

Changes since v3:
1. Add a #define for the average readings measurement.
2. Instead of configuring gpios every open, configure them on request.
3. Use a memory barrier and synchronize irq call to make sure IRQ is
not running past close.
4. Drop inline for vf50_ts_get_gpiod
5. Convert "ret" to "error"
6. Use devm_add_action to add a function for releasing iio channels and
drop remove completely.
7. Kill __set_bits()
8. Instead of requesting for pen irq as gpio and then irq, use the
interrupts property for DT and let it be handled automatically. Anyways
we never read it's state.
9. Just use IRQF_ONESHOT here, rely on the platform/OF to read and set up
the trigger properly (via "interrupts" property).

Changes since v2:
1. Fix pin multiplexing for pins in idle state. Configuration of the
pen detect pull up viz. PTA19__GPIO_9 resulted in generation of pen
irq's on a continuous basis.
2. Fix pinmux of the ADC pins as per the recommended pinmux in TRM.
3. Use a threaded irq handler instead of a irq handler plus workqueue
approach.
4. Use a low level trigger with oneshot flag specifier instead of the
previous falling edge triggered irq's. This coupled with the fix in
point 1 fixes the previous continuous spurious irq generation bug.
5. Change/fix the TS measurement logic to account for the fact that
iio_channel_read_raw might actually return an error. To be more
specific use break instead of continue and take care to close the
FET's in case of channel read error.
6. Drop the first patch "Add io-channel-cells property for ADC node"
as it has already been applied.
7. Move the iio channel get call again at the start. Having it in
the end resulted in crashes sometimes when iio was not probed and
the ts device got probed and opened earlier.

Changes since v1:
1. Fix/drop comments
2. Use an inline function for multiple gpiod_get calls in probe
3. Remove the pull up in the pinmux specified in DT for touchctrl_gpios
4. Add the io-channel-cells property before status property.
5. Add GPIOLIB as dependency in the Kconfig file

Version 3 of the patchset can be found here
https://lkml.org/lkml/2015/8/5/173

Version 2 of the patchset can be found here
https://www.mail-archive.com/linux-input@vger.kernel.org/msg18090.html

Version 1 of the patchset can be found here
https://lkml.org/lkml/2015/6/30/103

Thank you very much for the feedback till now.

Regards,
Sanchayan.

Sanchayan Maity (3):
  ARM: dts: vf500-colibri: Add device tree node for touchscreen support
  input: Add DT binding documentation for Colibri VF50 touchscreen
  touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

 .../bindings/input/touchscreen/colibri-vf50-ts.txt |  36 ++
 arch/arm/boot/dts/vf500-colibri-eval-v3.dts|   4 +
 arch/arm/boot/dts/vf500-colibri.dtsi   |  47 +++
 drivers/input/touchscreen/Kconfig  |  12 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/colibri-vf50-ts.c| 370 +
 6 files changed, 470 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
 create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[Sanchayan Maity]

The Colibri Vybrid VF50 module supports 4-wire touchscreens using
FETs and ADC inputs. This driver uses the IIO consumer interface
and relies on the vf610_adc driver based on the IIO framework.

Signed-off-by: Sanchayan Maity 
---
 drivers/input/touchscreen/Kconfig   |  12 +
 drivers/input/touchscreen/Makefile  |   1 +
 drivers/input/touchscreen/colibri-vf50-ts.c | 370 
 3 files changed, 383 insertions(+)
 create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 80f6386..28948ca 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
  To compile this driver as a module, choose M here: the
  module will be called zforce_ts.
 
+config TOUCHSCREEN_COLIBRI_VF50
+   tristate "Toradex Colibri on board touchscreen driver"
+   depends on GPIOLIB && IIO && VF610_ADC
+   help
+ Say Y here if you have a Colibri VF50 and plan to use
+ the on-board provided 4-wire touchscreen driver.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called colibri_vf50_ts.
+
 endif
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 44deea7..93746a0 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
 obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
 obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
 obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
+obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
b/drivers/input/touchscreen/colibri-vf50-ts.c
new file mode 100644
index 000..0793fdc
--- /dev/null
+++ b/drivers/input/touchscreen/colibri-vf50-ts.c
@@ -0,0 +1,370 @@
+/* Copyright 2015 Toradex AG
+ *
+ * Toradex Colibri VF50 Touchscreen driver
+ *
+ * Originally authored by Stefan Agner for 3.0 kernel
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "colibri-vf50-ts"
+#define DRV_VERSION "1.0"
+
+#define VF_ADC_MAX ((1 << 12) - 1)
+
+#define COLI_TOUCH_MIN_DELAY_US 1000
+#define COLI_TOUCH_MAX_DELAY_US 2000
+#define COLI_TOUCH_NO_OF_AVGS  5
+
+struct vf50_touch_device {
+   struct platform_device  *pdev;
+   struct input_dev*ts_input;
+   struct iio_channel  *channels;
+   struct gpio_desc *gpio_xp;
+   struct gpio_desc *gpio_xm;
+   struct gpio_desc *gpio_yp;
+   struct gpio_desc *gpio_ym;
+   struct gpio_desc *gpio_pen_detect;
+   int pen_irq;
+   int min_pressure;
+   bool stop_touchscreen;
+};
+
+/*
+ * Enables given plates and measures touch parameters using ADC
+ */
+static int adc_ts_measure(struct iio_channel *channel,
+ struct gpio_desc *plate_p, struct gpio_desc *plate_m)
+{
+   int i, value = 0, val = 0;
+   int ret;
+
+   gpiod_set_value(plate_p, 1);
+   gpiod_set_value(plate_m, 1);
+
+   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
+
+   for (i = 0; i < COLI_TOUCH_NO_OF_AVGS; i++) {
+   ret = iio_read_channel_raw(channel, &val);
+   if (ret < 0) {
+   value = ret;
+   goto error_iio_read;
+   }
+
+   value += val;
+   }
+
+   value /= COLI_TOUCH_NO_OF_AVGS;
+
+error_iio_read:
+   gpiod_set_value(plate_p, 0);
+   gpiod_set_value(plate_m, 0);
+
+   return value;
+}
+
+/*
+ * Enable touch detection using falling edge detection on XM
+ */
+static void vf50_ts_enable_touch_detection(struct vf50_touch_device *vf50_ts)
+{
+   /* Enable plate YM (needs to be strong GND, high active) */
+   gpiod_set_value(vf50_ts->gpio_ym, 1);
+
+   /*
+* Let the platform mux to idle state in order to enable
+* Pull-Up on GPIO
+*/
+   pinctrl_pm_select_idle_state(&vf50_ts->pdev->dev);
+}
+
+/*
+ * ADC touch screen sampling bottom half irq handler
+ */
+static irqreturn_t vf50_ts_irq_bh(int irq, void *private)
+{
+   struct vf50_touch_device *vf50_ts = (struct vf50_touch_device *)private;
+   struct device *dev = &vf50_ts->pdev->dev;
+   int val_x, val_y, val_z1, val_z2, val_p = 0;
+   bool discard_val_on_start = true;
+
+   /* Disable the touch detection plates */
+   gpiod_set_value(vf50_ts->gpio_ym, 0);
+
+   /* Let the platfo

[PATCH v4 2/3] input: Add DT binding documentation for Colibri VF50 touchscreen

[Sanchayan Maity]

This adds device tree binding documentation for the Colibri VF50
touchscreen driver.

Signed-off-by: Sanchayan Maity 
---
 .../bindings/input/touchscreen/colibri-vf50-ts.txt | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt 
b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
new file mode 100644
index 000..e615aa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
@@ -0,0 +1,36 @@
+* Toradex Colibri VF50 Touchscreen driver
+
+Required Properties:
+- compatible must be toradex,vf50-touchscreen
+- io-channels: adc channels being used by the Colibri VF50 module
+- xp-gpios: FET gate driver for input of X+
+- xm-gpios: FET gate driver for input of X-
+- yp-gpios: FET gate driver for input of Y+
+- ym-gpios: FET gate driver for input of Y-
+- interrupt-parent: phandle for the interrupt controller
+- interrupts: pen irq interrupt for touch detection
+- pinctrl-names: "idle", "default", "gpios"
+- pinctrl-0: pinctrl node for idle state gpio pinmux
+- pinctrl-1: pinctrl node for touch detection state pinmux
+- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
+- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y values
+
+Example:
+
+   touchctrl: vf50_touchctrl {
+   compatible = "toradex,vf50-touchscreen";
+   io-channels = <&adc1 0>,<&adc0 0>,
+   <&adc0 1>,<&adc1 2>;
+   xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+   xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
+   yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+   ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+   interrupt-parent = <&gpio0>;
+   interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "idle","default","gpios";
+   pinctrl-0 = <&pinctrl_touchctrl_idle>;
+   pinctrl-1 = <&pinctrl_touchctrl_default>;
+   pinctrl-2 = <&pinctrl_touchctrl_gpios>;
+   vf50-ts-min-pressure = <200>;
+   status = "disabled";
+   };
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[Sanchayan Maity]

Add device tree node for touchscreen support on Colibri VF50. The
touchscreen functionality on VF50 uses the ADC channels of Vybrid
and some GPIOs. Also add pinctrl nodes for proper pinmux.

Signed-off-by: Sanchayan Maity 
---
 arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  4 +++
 arch/arm/boot/dts/vf500-colibri.dtsi| 47 +
 2 files changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts 
b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
index 7fc782c..14c0b00 100644
--- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
@@ -15,3 +15,7 @@
model = "Toradex Colibri VF50 on Colibri Evaluation Board";
compatible = "toradex,vf500-colibri_vf50-on-eval", 
"toradex,vf500-colibri_vf50", "fsl,vf500";
 };
+
+&touchscreen {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi 
b/arch/arm/boot/dts/vf500-colibri.dtsi
index cee34a3..84f091d 100644
--- a/arch/arm/boot/dts/vf500-colibri.dtsi
+++ b/arch/arm/boot/dts/vf500-colibri.dtsi
@@ -17,4 +17,51 @@
memory {
reg = <0x8000 0x800>;
};
+
+   touchscreen: vf50-touchscreen {
+   compatible = "toradex,vf50-touchscreen";
+   io-channels = <&adc1 0>,<&adc0 0>,
+   <&adc0 1>,<&adc1 2>;
+   xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+   xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
+   yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+   ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+   interrupt-parent = <&gpio0>;
+   interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "idle","default","gpios";
+   pinctrl-0 = <&pinctrl_touchctrl_idle>;
+   pinctrl-1 = <&pinctrl_touchctrl_default>;
+   pinctrl-2 = <&pinctrl_touchctrl_gpios>;
+   vf50-ts-min-pressure = <200>;
+   status = "disabled";
+   };
+};
+
+&iomuxc {
+   vf610-colibri {
+   pinctrl_touchctrl_idle: touchctrl_idle {
+   fsl,pins = <
+   VF610_PAD_PTA18__GPIO_8 0x006d
+   VF610_PAD_PTA19__GPIO_9 0x006c
+   >;
+   };
+
+   pinctrl_touchctrl_default: touchctrl_default {
+   fsl,pins = <
+   VF610_PAD_PTA18__ADC0_SE0   0x0040
+   VF610_PAD_PTA19__ADC0_SE1   0x0040
+   VF610_PAD_PTA16__ADC1_SE0   0x0040
+   VF610_PAD_PTB2__ADC1_SE20x0040
+   >;
+   };
+
+   pinctrl_touchctrl_gpios: touchctrl_gpios {
+   fsl,pins = <
+   VF610_PAD_PTA23__GPIO_130x22e9
+   VF610_PAD_PTB23__GPIO_930x22e9
+   VF610_PAD_PTA22__GPIO_120x22e9
+   VF610_PAD_PTA11__GPIO_4 0x22e9
+   >;
+   };
+   };
 };
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/16] omap_hsmmc: regulator usage cleanup and fixes

[Kishon Vijay Abraham I]

Hi Tony,

On Friday 21 August 2015 01:11 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [150820 05:39]:
>> Hi,
>>
>> On Monday 03 August 2015 05:56 PM, Kishon Vijay Abraham I wrote:
>>> Changes from v1:
>>> *) return on -EPROBE_DEFER and other fatal errors. (Don't return only
>>>if the return value is -ENODEV)
>>> *) Remove the beagle x15 dts patch. It can be part of a different
>>>series.
>>> *) Avoid using regulator_is_enabled for vqmmc since if the regulator
>>>is shared and the other users are not using regulator_is_enabled
>>>then there can be unbalanced regulator_enable/regulator_disable
>>>
>>> This patch series does the following
>>> *) Uses devm_regulator_get_optional() for vmmc and then removes the
>>>CONFIG_REGULATOR check altogether.
>>> *) return on -EPROBE_DEFER and any other fatal errors
>>> *) enable/disable vmmc_aux regulator based on prior state
>>>
>>> I've pushed this patch series to
>>> git://git.ti.com/linux-phy/linux-phy.git mmc_regulator_cleanup_fixes_v2
>>>
>>> Please note the branch also has the pbias fixes [1] & [2].
>>> [1] -> https://lkml.org/lkml/2015/7/27/358
>>> [2] -> https://lkml.org/lkml/2015/7/27/391
>>>
>>> This series is in preparation for implementing the voltage switch
>>> sequence so that UHS cards can be supported.
>>>
>>> Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM,
>>> Beaglebone black, OMAP5 uEVM and OMAP4 PANDA.
>>
>> I have now done read/write test in omap3 beagle-xm with this series!
> 
> Great thanks for doing that. Also gave this series a try here
> with my off idle MMC SDIO WLAN card test and things still work
> for me. That's not really testing the PBIAS regulator though,
> but a good torture test for saving and restoring context. So
> FWIW:
> 
> Tested-by: Tony Lindgren 
> 
> If you need a PM torture test for PBIAS regulator, you could try
> to do the following on your beagle xm MMC card with
> oamp2plus_defconfig:
> 
> 1. Make sure EHCI modules are not loaded and OTG USB cable is
>not connected
> 
> 2. Enable UART timeouts and off idle with something like:
> 
> !/bin/bash
> 
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
> echo 3000 > $uart/autosuspend_delay_ms 2>&1
> done
> 
> modprobe leds-gpio
> modprobe ledtrig-default-on
> 
> uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> for uart in $uarts; do
> echo enabled > $uart/wakeup 2>&1
> echo auto > $uart/control 2>&1
> done
> 
> echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
> 
> 3. Make sure you start seeing core_pwrdm OFF count increasing
>with cat /sys/kernel/debug/pm_debug/count
> 
> MMC should keep on working when hitting idle, if not, something
> is not saved or restored properly. And SDIO WLAN cards should
> wake up the system and respond to ping if the wakeirq is
> configured in the dts file for the MMC controller. At least
> mwifiex_sdio cards work for this :)

Thanks for the detailed explanation. Sure will add those tests.

Cheers
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

[Thierry Reding]

On Fri, Aug 21, 2015 at 08:24:16PM +0900, Jingoo Han wrote:
> On 2015. 8. 21., at PM 7:01, Yakir Yang  wrote:
> > 
> > Hi Jingoo,
> > 
> >> 在 2015/8/21 16:20, Jingoo Han 写道:
> >>> On 2015. 8. 19., at PM 11:48, Yakir Yang  wrote:
> >> 
> >> .
> >> 
> >>> .../bindings/video/analogix_dp-rockchip.txt|   83 ++
> >>> .../devicetree/bindings/video/exynos_dp.txt|   51 +-
> >>> arch/arm/boot/dts/exynos5250-arndale.dts   |   10 +-
> >>> arch/arm/boot/dts/exynos5250-smdk5250.dts  |   10 +-
> >>> arch/arm/boot/dts/exynos5250-snow.dts  |   12 +-
> >>> arch/arm/boot/dts/exynos5250-spring.dts|   12 +-
> >>> arch/arm/boot/dts/exynos5420-peach-pit.dts |   12 +-
> >>> arch/arm/boot/dts/exynos5420-smdk5420.dts  |   10 +-
> >>> arch/arm/boot/dts/exynos5800-peach-pi.dts  |   12 +-
> >>> drivers/gpu/drm/bridge/Kconfig |5 +
> >>> drivers/gpu/drm/bridge/Makefile|1 +
> >>> drivers/gpu/drm/bridge/analogix_dp_core.c  | 1382 
> >>> +++
> >>> drivers/gpu/drm/bridge/analogix_dp_core.h  |  286 
> >>> drivers/gpu/drm/bridge/analogix_dp_reg.c   | 1294 
> >>> ++
> >>> .../exynos_dp_reg.h => bridge/analogix_dp_reg.h}   |  270 ++--
> >>> drivers/gpu/drm/exynos/Kconfig |5 +-
> >>> drivers/gpu/drm/exynos/Makefile|2 +-
> >>> drivers/gpu/drm/exynos/analogix_dp-exynos.c|  347 +
> >> Would you change this file name to "exynos_dp.c"?
> > 
> > Sorry, I don't think so  ;(
> > 
> > I think IP_name+Soc_name would be better in this re-use case.
> 
> So? Is there the naming rule such as "IP_name+SoC_name"?
> 
> > Beside I see
> > there are lots of driver named with this format in kernel, such as dw_hdmi 
> > & dw_mmc
> 
> Please look at other dw cases.
> For example, look at dw_pcie.
> 
> drivers/pci/host/
> pcie-designware.c
> pci-spear13xx.c
> pci-exynos.c
> 
> In this case, pci-spear13xx.c and pci-exynos.c do not use "IP_name+SoC_name", 
> even though these are dw IPs.
> 
> Also, naming consistency is more important.
> Now, Exynos DRM files are using "exynos_drm_" prefix.
> 
> drivers/gpu/drm/exynos/
> exynos_drm_buf.c
> exynos_drm_core.c
> 
> 
> However, "analogix_dp-exynos.c" looks very inconsistent.
> 
> If there is no strict naming rule, please use "exynos_dp.c"
> or "exynos_drm_dp.c". 

Exynos DRM maintainers get to pick their filenames, so Yakir, please
rename as Jingoo suggested.

Even if you didn't the first thing that would go into the Exynos DRM
driver tree after this is merged is a rename patch anyway.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

[maitysanchayan]

Ping?

- Sanchayan.

On 15-08-06 21:28:22, Sanchayan Maity wrote:
> Add iio_hwmon node to expose the temperature channel on Vybrid
> as hardware monitor device using the iio_hwmon driver.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 39173bb..0993d66 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -597,5 +597,10 @@
>   status = "disabled";
>   };
>   };
> +
> + iio_hwmon {
> + compatible = "iio-hwmon";
> + io-channels = <&adc0 16>;
> + };
>   };
>  };
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] input: ti_am335x_tsc: Add open delay parameter

[Vignesh R]

On 08/21/2015 03:47 AM, Michael Welling wrote:
> On Thu, Aug 20, 2015 at 05:41:30PM +0530, Vignesh R wrote:
>>
>>
>> On 08/19/2015 11:38 PM, Michael Welling wrote:
>>> On Wed, Aug 12, 2015 at 01:44:22PM -0500, Michael Welling wrote:
 On Wed, Aug 12, 2015 at 11:56:36AM +0530, Vignesh R wrote:
> Hi Michael,
>
> + Dmitry
>
> On 08/12/2015 12:15 AM, Michael Welling wrote:
>> Adds a device tree parameter to set the open delay on the touchscreen
>> conversion steps. Increasing this parameter helps the touch accuracy on
>> some screens.
>>
>> Signed-off-by: Michael Welling 
>> ---
>>  .../bindings/input/touchscreen/ti-tsc-adc.txt  |  5 +
>>  drivers/input/touchscreen/ti_am335x_tsc.c  | 18 
>> ++
>>  2 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt 
>> b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
>> index b1163bf..cb11fda 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
>> @@ -41,6 +41,11 @@ Optional properties:
>>   charge step, so this does in fact function as a
>>   hardware knob for adjusting the amount of 
>> "settling
>>   time".
>> +ti,open-delay: Open delay applied to all touchscreen conversion 
>> steps.
>> +The value corresponds to the number of ADC clock
>> +cycles to wait after applying the step 
>> configuration
>> +registers and before sending the start of ADC
>> +conversion. Maximum value is 0x3.
>>  
>
> Since open-delay is per step, is it not better to allow specifying
> open-delay per step like ti,chan-step-opendelay of adc? This will help
> control open-delay for all the four wires.

 Do you see any reason why you would want a different delay for each step of
 the conversion on the same touchscreen?
>>
>>
>> Sorry for the delay,
>>
>> I haven't seen different delays being used for different channels on
>> 4-wire TSC ( not sure of 5-wire or 8 wire designs). Since this is DT
>> change, I just wanted to make sure more flexibility is provided.
>>

 The user would need to know the number of steps what each of the steps do.

>>
>>
>> What I was thinking was making open-delay configurable per channel (one
>> entry for X+, X-, Y+, Y-).
>>
>> For example, for a 4-wire TSC:
>> ti,chan-open-delay = <0x30 0x100 0x20 0x10>; /* for X+, X-, Y+, Y- */
>>
> 
> What about the readings for the pressure?

Sorry, I was confused with channels and co-ordinate readouts.

Each of X, Y and pressure(Z) readouts will correspond to certain tscadc
steps. So, what I have in mind is:

ti,open-delay = <0x30 0x100 0x20>; /* for X, Y, Z */

For Steps that represents X co-ordinate readouts set opendelay = 0x30.
For Steps that correspond to Y co-ordinate readouts set opendelay =
0x100 and similarly for 0x20 for Z.

This is will provide flexibility to configure open-delay independently
for X, Y and Z


-- 
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/5] arm/arm64: add smccc ARCH32

[Jens Wiklander]

On Fri, Aug 21, 2015 at 10:24:30AM +0100, Will Deacon wrote:
> On Thu, Aug 20, 2015 at 12:37:29PM +0100, Jens Wiklander wrote:
> > On Wed, Aug 19, 2015 at 05:50:09PM +0100, Will Deacon wrote:
> > > On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote:
> > > > Adds helpers to do SMC based on ARM SMC Calling Convention.
> > > > CONFIG_HAVE_SMCCC is enabled for architectures that may support
> > > > the SMC instruction. It's the responsibility of the caller to
> > > > know if the SMC instruction is supported by the platform.
> > > 
> > > [...]
> > > > diff --git a/arch/arm64/kernel/smccc-call.S 
> > > > b/arch/arm64/kernel/smccc-call.S
> > > > new file mode 100644
> > > > index 000..3ce7fe8
> > > > --- /dev/null
> > > > +++ b/arch/arm64/kernel/smccc-call.S
> > > > @@ -0,0 +1,34 @@
> > > > +/*
> > > > + * Copyright (c) 2015, Linaro Limited
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or modify
> > > > + * it under the terms of the GNU General Public License Version 2 as
> > > > + * published by the Free Software Foundation.
> > > > + *
> > > > + * This program is distributed in the hope that it will be useful,
> > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > > + * GNU General Public License for more details.
> > > > + *
> > > > + */
> > > > +#include 
> > > > +
> > > > +#define SMC_PARAM_W0_OFFS  0
> > > > +#define SMC_PARAM_W2_OFFS  8
> > > > +#define SMC_PARAM_W4_OFFS  16
> > > > +#define SMC_PARAM_W6_OFFS  24
> > > > +
> > > > +/* void smccc_call32(struct smccc_param32 *param) */
> > > > +ENTRY(smccc_call32)
> > > > +   stp x28, x30, [sp, #-16]!
> > > 
> > > Why are you saving lr?
> > 
> > Agree, no point in saving lr, but I still need to decrease sp with 16 to
> > maintain correct alignment. I'll do it with an str instruction instead.
> 
> That or pad out with xzr
> 
> > > 
> > > > +   mov x28, x0
> > > > +   ldp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > > +   ldp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > > +   ldp w4, w5, [x28, #SMC_PARAM_W4_OFFS]
> > > > +   ldp w6, w7, [x28, #SMC_PARAM_W6_OFFS]
> > > > +   smc #0
> > > > +   stp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > > +   stp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > > +   ldp x28, x30, [sp], #16
> > > > +   ret
> > > > +ENDPROC(smccc_call32)
> > > 
> > > Could we deal with this like we do for PSCI instead? (see
> > > __invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S
> > > and stick this in there too.
> > 
> > I assume you're referring to when to use "hvc" and "smc".
> 
> No, I mean use a C prototype to avoid marshalling the parameters in assembly
> like this. As Rutland pointed out, the return value is a bit messy, but
> the arguments align nicely with the PCS afaict.

If possible I'd like the function to have the same prototype for both
arm and arm64. For arm it's not possible to supply more than 4
parameters. To fully support SMC Calling Convention we need to be able
to pass 8 parameters and have 4 return values. The OP-TEE driver in this
patch set depends on this. I don't see how we can avoid the marshalling
here.

We could have two versions of the SMCCC functions, one simplified which
only uses registers and one complete like this one with marshalling.

Thanks,
Jens
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC

[Varadarajan Narayanan]

Add initial dts files and SoC support for IPQ40XX

Signed-off-by: Varadarajan Narayanan 
---
Changes in v2:
  - Added devicetree bindings documentation

 .../devicetree/bindings/clock/qca,gcnt.txt | 14 
 Documentation/devicetree/bindings/ipq.txt  | 16 
 arch/arm/boot/dts/Makefile |  3 +-
 arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts| 33 +
 arch/arm/boot/dts/qcom-ipq40xx.dtsi| 86 ++
 arch/arm/configs/ipq_defconfig |  1 +
 arch/arm/mach-qcom/Kconfig |  4 +
 arch/arm/mach-qcom/board.c |  1 +
 8 files changed, 157 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/qca,gcnt.txt
 create mode 100644 Documentation/devicetree/bindings/ipq.txt
 create mode 100644 arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq40xx.dtsi

diff --git a/Documentation/devicetree/bindings/clock/qca,gcnt.txt 
b/Documentation/devicetree/bindings/clock/qca,gcnt.txt
new file mode 100644
index 000..dd0d71e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qca,gcnt.txt
@@ -0,0 +1,14 @@
+QCA Global Counter
+
+
+Required properties :
+- compatible : "qcom,qca-gcnt"
+
+- reg : shall contain base register location and length
+
+Example:
+
+   counter {
+   compatible = "qcom,qca-gcnt";
+   reg = <0x004a1000 0x4>;
+   };
diff --git a/Documentation/devicetree/bindings/ipq.txt 
b/Documentation/devicetree/bindings/ipq.txt
new file mode 100644
index 000..7d56bd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/ipq.txt
@@ -0,0 +1,16 @@
+Qualcomm IPQ device tree bindings
+-
+
+System on Chip
+
+Device tree must specify which SoC it uses, with one of the
+following compatible strings
+
+   "qcom,ipq40xx"
+
+Platform
+
+Device tree must specify which Platform it uses, with one of the
+following compatible strings
+
+   "qcom,ipq40xx-r3pc"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 246473a..6b4caee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -477,7 +477,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
-   qcom-msm8974-sony-xperia-honami.dtb
+   qcom-msm8974-sony-xperia-honami.dtb \
+   qcom-ipq40xx-r3pc.dtb
 dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
diff --git a/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts 
b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
new file mode 100644
index 000..7e4e629
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
@@ -0,0 +1,33 @@
+/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "qcom-ipq40xx.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40XX R3PC";
+   compatible = "qcom,ipq40xx-r3pc", "qcom,ipq40xx";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512MB */
+   };
+
+   chosen {
+   bootargs = "root=/dev/ram rw init=/init 
console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246";
+   };
+
+   soc {
+   serial@78b {
+   status = "ok";
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/qcom-ipq40xx.dtsi 
b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
new file mode 100644
index 000..76c55a3
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
@@ -0,0 +1,86 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+#include "skeleton.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40XX";
+   compatible = "qcom,ipq40xx";
+   interrupt-parent = <&intc>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu@0 {
+   

Re: [PATCH] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC

[Varadarajan Narayanan]

On Fri, Aug 21, 2015 at 02:50:35PM +0530, Varadarajan Narayanan wrote:
> Add initial dts files and SoC support for IPQ40XX

Please ignore this. Missed the Devicetree bindings documentation.
Will post a revised patch.

Thanks
Varada

> Signed-off-by: Varadarajan Narayanan 
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 246473a..6b4caee 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -477,7 +477,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>   qcom-ipq8064-ap148.dtb \
>   qcom-msm8660-surf.dtb \
>   qcom-msm8960-cdp.dtb \
> - qcom-msm8974-sony-xperia-honami.dtb
> + qcom-msm8974-sony-xperia-honami.dtb \
> + qcom-ipq40xx-r3pc.dtb
>  dtb-$(CONFIG_ARCH_REALVIEW) += \
>   arm-realview-pb1176.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> diff --git a/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts 
> b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
> new file mode 100644
> index 000..7e4e629
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
> @@ -0,0 +1,33 @@
> +/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "qcom-ipq40xx.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. IPQ40XX R3PC";
> + compatible = "qcom,ipq40xx-r3pc", "qcom,ipq40xx";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512MB */
> + };
> +
> + chosen {
> + bootargs = "root=/dev/ram rw init=/init 
> console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246";
> + };
> +
> + soc {
> + serial@78b {
> + status = "ok";
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/qcom-ipq40xx.dtsi 
> b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
> new file mode 100644
> index 000..f572f38
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
> @@ -0,0 +1,81 @@
> +/*
> + * Copyright (c) 2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. IPQ40XX";
> + compatible = "qcom,ipq40xx";
> + interrupt-parent = <&intc>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x0>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x1>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x2>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x3>;
> + };
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "simple-bus";
> +
> + intc: interrupt-controller@b00 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0x0b00 0x1000>,
> + <0x0b002000 0x1000>;
> + };
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <1 2 0xf08>,
> +  <1 3 0xf08>,
> +  <1 4 0xf08>,
> +  <1 1 0xf08>;
> + clock-frequency = <2083>;
> + };
> +
> + serial@78b {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0x78b 0x200>;
> +

Re: [PATCH v2] dmaengine: xgene-dma: Fix the lock to allow client for further submission of requests

[Vinod Koul]

On Fri, Aug 21, 2015 at 02:33:34PM +0530, Rameshwar Prasad Sahu wrote:
> This patch provides the fix in the cleanup routing such that client can 
> perform
> further submission by releasing the lock before calling client's callback 
> function.

Applied, thanks

-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] dts: keystone: Change "ti,davinci-i2c" compatible to "ti,keystone-i2c"

[Alexander Sverdlin]

Now as "i2c-davinci" driver has special handling for Keystone it's time to 
switch
the device tree to use new "compatible" property.

Signed-off-by: Alexander Sverdlin 
---
 arch/arm/boot/dts/keystone.dtsi |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 72816d6..a846597 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -106,7 +106,7 @@
};
 
i2c0: i2c@253 {
-   compatible = "ti,davinci-i2c";
+   compatible = "ti,keystone-i2c";
reg = <0x0253 0x400>;
clock-frequency = <10>;
clocks = <&clki2c>;
@@ -116,7 +116,7 @@
};
 
i2c1: i2c@2530400 {
-   compatible = "ti,davinci-i2c";
+   compatible = "ti,keystone-i2c";
reg = <0x02530400 0x400>;
clock-frequency = <10>;
clocks = <&clki2c>;
@@ -126,7 +126,7 @@
};
 
i2c2: i2c@2530800 {
-   compatible = "ti,davinci-i2c";
+   compatible = "ti,keystone-i2c";
reg = <0x02530800 0x400>;
clock-frequency = <10>;
clocks = <&clki2c>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] i2c: davinci: Optimize clock generation on Keystone SoC

[Alexander Sverdlin]

According to "KeyStone Architecture Inter-IC Control Bus User Guide", fixed
additive part of frequency divisors (referred as "d" in the code and datasheet)
always equals to 6, independent of module clock prescaler.

 module clock frequency
master clock frequency = --
 (ICCL + 6) + (ICCH + 6)

It was not the case with original Davinci IP. Introduce new compatible property
"ti,keystone-i2c", which triggers special handling in the driver.

Without this change Keystone-based systems (having 204.8MHz input clock) choose
prescaler 29 (PSC=28). Using d=5 in this case leads to bus bitrate ~353kHz
instead of requested 400kHz. After correction, assuming d=6 bus rate is ~392kHz.
This gives ~11% transfer rate increase.

Signed-off-by: Alexander Sverdlin 
Tested-by: Hemanth Guruva Reddy 
Tested-by: Lukasz Gemborowski 
---
 .../devicetree/bindings/i2c/i2c-davinci.txt|6 +++---
 drivers/i2c/busses/i2c-davinci.c   |8 
 2 files changed, 11 insertions(+), 3 deletions(-)

Changes in v2:
- Introducing new "compatible" property "ti,keystone-i2c" instead of guessing
  silicon revision from ID registers

diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt 
b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
index a4e1cbc..5b123e0 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
@@ -1,10 +1,10 @@
-* Texas Instruments Davinci I2C
+* Texas Instruments Davinci/Keystone I2C
 
 This file provides information, what the device node for the
-davinci i2c interface contain.
+davinci/keystone i2c interface contains.
 
 Required properties:
-- compatible: "ti,davinci-i2c";
+- compatible: "ti,davinci-i2c" or "ti,keystone-i2c";
 - reg : Offset and length of the register set for the device
 
 Recommended properties :
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 3fbb9a0..c5628a4 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -181,6 +181,7 @@ static void i2c_davinci_calc_clk_dividers(struct 
davinci_i2c_dev *dev)
u32 clkh;
u32 clkl;
u32 input_clock = clk_get_rate(dev->clk);
+   struct device_node *of_node = dev->dev->of_node;
 
/* NOTE: I2C Clock divider programming info
 * As per I2C specs the following formulas provide prescaler
@@ -196,6 +197,9 @@ static void i2c_davinci_calc_clk_dividers(struct 
davinci_i2c_dev *dev)
 * where if PSC == 0, d = 7,
 *   if PSC == 1, d = 6
 *   if PSC > 1 , d = 5
+*
+* Note:
+* d is always 6 on Keystone I2C controller
 */
 
/* get minimum of 7 MHz clock, but max of 12 MHz */
@@ -204,6 +208,9 @@ static void i2c_davinci_calc_clk_dividers(struct 
davinci_i2c_dev *dev)
psc++;  /* better to run under spec than over */
d = (psc >= 2) ? 5 : 7 - psc;
 
+   if (of_node && of_device_is_compatible(of_node, "ti,keystone-i2c"))
+   d = 6;
+
clk = ((input_clock / (psc + 1)) / (pdata->bus_freq * 1000));
/* Avoid driving the bus too fast because of rounding errors above */
if (input_clock / (psc + 1) / clk > pdata->bus_freq * 1000)
@@ -726,6 +733,7 @@ static struct i2c_algorithm i2c_davinci_algo = {
 
 static const struct of_device_id davinci_i2c_of_match[] = {
{.compatible = "ti,davinci-i2c", },
+   {.compatible = "ti,keystone-i2c", },
{},
 };
 MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] Documentation: Detail permitted DT properties for the imx6ul_tsc

[Markus Pargmann]

On Fri, Aug 21, 2015 at 08:30:16AM +, Chen Bough wrote:
> Hi Markus,
> 
> > -Original Message-
> > From: Markus Pargmann [mailto:m...@pengutronix.de]
> > Sent: Wednesday, August 19, 2015 1:55 PM
> > To: Chen Haibo-B51421
> > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; shawn...@kernel.org;
> > ker...@pengutronix.de; li...@arm.linux.org.uk; dmitry.torok...@gmail.com;
> > devicetree@vger.kernel.org; sbran...@broadcom.com; a...@arndb.de;
> > mche...@osg.samsung.com; christian.gmei...@gmail.com;
> > scott@emc.com.tw; linux-ker...@vger.kernel.org; hdego...@redhat.com;
> > jonat...@broadcom.com; benjamin.tissoi...@redhat.com;
> > hans.verk...@cisco.com; had...@hadess.net; linux-in...@vger.kernel.org;
> > ge...@linux-m68k.org; sebastien.szyman...@armadeus.com;
> > mamli...@gmail.com; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [PATCH v2 2/5] Documentation: Detail permitted DT properties
> > for the imx6ul_tsc
> > 
> > Hi,
> > 
> > On Tue, Jul 28, 2015 at 05:58:38PM +0800, Haibo Chen wrote:
> > > Here we apply required documentation for the imx6ul touch screen
> > > controller driver which describe available properties and how to use
> > > them.
> > >
> > > Signed-off-by: Haibo Chen 
> > > ---
> > >  .../bindings/input/touchscreen/imx6ul_tsc.txt  | 36
> > ++
> > >  1 file changed, 36 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> > > b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> > > new file mode 100644
> > > index 000..ac41c32
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.t
> > > +++ xt
> > > @@ -0,0 +1,36 @@
> > > +* Freescale i.MX6UL Touch Controller
> > > +
> > > +Required properties:
> > > +- compatible: must be "fsl,imx6ul-tsc".
> > > +- reg: this touch controller address and the ADC2 address.
> > 
> > This suggests that this driver is using a unit ADC2. Which also means
> > that there are more than one ADC which are probably identical?
> > 
> > Shouldn't these ADCs be properly described by their own device nodes
> > instead of these two register ranges, two interrupts and two clocks?
> > 
> > Is 'ADC2' usable without tsc? Then ADC1/ADC2 should perhaps get a proper
> > IIO driver.
> 
> For i.MX6UL, there are two ADC. ADC1 is a normal ADC, and ADC2 can only works 
> for
> TSC, the channels of ADC2 are connected to TSC directly. TSC and ADC2 should 
> work
> together as a touch screen controller. 

But as I understand these are two different units. Wouldn't it be better
to abstract it that way in the DT?

Best regards,

Markus

> 
> For ADC1, it share the driver vf610_adc.c (drivers/iio/adc/vf610_adc.c). 
> 
> Best Regards
> 
> Haibo 
>  
> > 
> > Unfortunately I don't have the reference manual to have a look how this
> > all works.
> > 
> > Best regards,
> > 
> > Markus
> > 
> > > +- interrupts: the interrupt of this touch controller and ADC2.
> > > +- clocks: the root clock of touch controller and ADC2.
> > > +- clock-names; must be "tsc" and "adc".
> > > +- xnur-gpio: the X- gpio this controller connect to.
> > > +  This xnur-gpio returns to high once the finger leave the touch
> > > +screen (The
> > > +  last touch event the touch controller capture).
> > > +
> > > +Optional properties:
> > > +- measure-delay-time: the value of measure delay time.
> > > +  Before X-axis or Y-axis measurement, the screen need some time
> > > +before
> > > +  even potential distribution ready.
> > > +  This value depends on the touch screen.
> > > +- pre-charge-time: the touch screen need some time to precharge.
> > > +  This value depends on the touch screen.
> > > +
> > > +Example:
> > > + tsc: tsc@0204 {
> > > + compatible = "fsl,imx6ul-tsc";
> > > + reg = <0x0204 0x4000>, <0x0219c000 0x4000>;
> > > + interrupts = ,
> > > +  ;
> > > + clocks = <&clks IMX6UL_CLK_IPG>,
> > > +  <&clks IMX6UL_CLK_ADC2>;
> > > + clock-names = "tsc", "adc";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&pinctrl_tsc>;
> > > + xnur-gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
> > > + measure-delay-time = <0xfff>;
> > > + pre-charge-time = <0x>;
> > > + status = "okay";
> > > + };
> > > --
> > > 1.9.1
> > >
> > >
> > >
> > 
> > --
> > Pengutronix e.K.   |
> > |
> > Industrial Linux Solutions | http://www.pengutronix.de/
> > |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> > |
> > Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917-
> > |

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions |

Re: [PATCH v2 1/5] input: touchscreen: add imx6ul_tsc driver support

[Markus Pargmann]

On Tue, Jul 28, 2015 at 05:58:37PM +0800, Haibo Chen wrote:
> Freescale i.MX6UL contains a internal touchscreen controller,
> this patch add a driver to support this controller.
> 
> Signed-off-by: Haibo Chen 
> ---
>  drivers/input/touchscreen/Kconfig  |  12 +
>  drivers/input/touchscreen/Makefile |   1 +
>  drivers/input/touchscreen/imx6ul_tsc.c | 504 
> +
>  3 files changed, 517 insertions(+)
>  create mode 100644 drivers/input/touchscreen/imx6ul_tsc.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 5b272ba..32c300d 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -479,6 +479,18 @@ config TOUCHSCREEN_MTOUCH
> To compile this driver as a module, choose M here: the
> module will be called mtouch.
>  
> +config TOUCHSCREEN_IMX6UL_TSC
> + tristate "Freescale i.MX6UL touchscreen controller"
> + depends on OF
> + help
> +   Say Y here if you have a Freescale i.MX6UL, and want to
> +   use the internal touchscreen controller.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   moduel will be called imx6ul_tsc.
> +
>  config TOUCHSCREEN_INEXIO
>   tristate "iNexio serial touchscreens"
>   select SERIO
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index c85aae2..9379b32 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX)+= egalax_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_FUJITSU)+= fujitsu_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix.o
>  obj-$(CONFIG_TOUCHSCREEN_ILI210X)+= ili210x.o
> +obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC) += imx6ul_tsc.o
>  obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
>  obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)  += intel-mid-touch.o
>  obj-$(CONFIG_TOUCHSCREEN_IPROC)  += bcm_iproc_tsc.o
> diff --git a/drivers/input/touchscreen/imx6ul_tsc.c 
> b/drivers/input/touchscreen/imx6ul_tsc.c
> new file mode 100644
> index 000..807f1db
> --- /dev/null
> +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> @@ -0,0 +1,504 @@
> +/*
> + * Freescale i.MX6UL touchscreen controller driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* ADC configuration registers field define */
> +#define ADC_AIEN (0x1 << 7)
> +#define ADC_CONV_DISABLE 0x1F
> +#define ADC_CAL  (0x1 << 7)
> +#define ADC_CALF 0x2
> +#define ADC_12BIT_MODE   (0x2 << 2)
> +#define ADC_IPG_CLK  0x00
> +#define ADC_CLK_DIV_8(0x03 << 5)
> +#define ADC_SHORT_SAMPLE_MODE(0x0 << 4)
> +#define ADC_HARDWARE_TRIGGER (0x1 << 13)
> +#define SELECT_CHANNEL_4 0x04
> +#define SELECT_CHANNEL_1 0x01
> +#define DISABLE_CONVERSION_INT   (0x0 << 7)
> +
> +/* ADC registers */
> +#define REG_ADC_HC0  0x00
> +#define REG_ADC_HC1  0x04
> +#define REG_ADC_HC2  0x08
> +#define REG_ADC_HC3  0x0C
> +#define REG_ADC_HC4  0x10
> +#define REG_ADC_HS   0x14
> +#define REG_ADC_R0   0x18
> +#define REG_ADC_CFG  0x2C
> +#define REG_ADC_GC   0x30
> +#define REG_ADC_GS   0x34
> +
> +#define ADC_TIMEOUT  msecs_to_jiffies(100)

These defines are in two drivers. Here and in
drivers/iio/adc/vf610_adc.c

> +
> +/* TSC registers */
> +#define REG_TSC_BASIC_SETING 0x00
> +#define REG_TSC_PRE_CHARGE_TIME  0x10
> +#define REG_TSC_FLOW_CONTROL 0x20
> +#define REG_TSC_MEASURE_VALUE0x30
> +#define REG_TSC_INT_EN   0x40
> +#define REG_TSC_INT_SIG_EN   0x50
> +#define REG_TSC_INT_STATUS   0x60
> +#define REG_TSC_DEBUG_MODE   0x70
> +#define REG_TSC_DEBUG_MODE2  0x80
> +
> +/* TSC configuration registers field define */
> +#define DETECT_4_WIRE_MODE   (0x0 << 4)
> +#define AUTO_MEASURE 0x1
> +#define MEASURE_SIGNAL   0x1
> +#define DETECT_SIGNAL(0x1 << 4)
> +#define VALID_SIGNAL (0x1 << 8)
> +#define MEASURE_INT_EN   0x1
> +#define MEASURE_SIG_EN   0x1
> +#define VALID_SIG_EN (0x1 << 8)
> +#define DE_GLITCH_2  (0x2 << 29)
> +#define START_SENSE  (0x1 << 12)
> +#define TSC_DISABLE  (0x1 << 16)
> +#define DETECT_MODE  0x2
> +
> +struct imx6ul_tsc {
> + struct device *dev;
> + struct input_dev *input;
> + void __iomem *tsc_regs;
> + voi

Re: [PATCH v5 1/5] arm/arm64: add smccc ARCH32

[Will Deacon]

On Thu, Aug 20, 2015 at 12:37:29PM +0100, Jens Wiklander wrote:
> On Wed, Aug 19, 2015 at 05:50:09PM +0100, Will Deacon wrote:
> > On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote:
> > > Adds helpers to do SMC based on ARM SMC Calling Convention.
> > > CONFIG_HAVE_SMCCC is enabled for architectures that may support
> > > the SMC instruction. It's the responsibility of the caller to
> > > know if the SMC instruction is supported by the platform.
> > 
> > [...]
> > > diff --git a/arch/arm64/kernel/smccc-call.S 
> > > b/arch/arm64/kernel/smccc-call.S
> > > new file mode 100644
> > > index 000..3ce7fe8
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/smccc-call.S
> > > @@ -0,0 +1,34 @@
> > > +/*
> > > + * Copyright (c) 2015, Linaro Limited
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License Version 2 as
> > > + * published by the Free Software Foundation.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + */
> > > +#include 
> > > +
> > > +#define SMC_PARAM_W0_OFFS  0
> > > +#define SMC_PARAM_W2_OFFS  8
> > > +#define SMC_PARAM_W4_OFFS  16
> > > +#define SMC_PARAM_W6_OFFS  24
> > > +
> > > +/* void smccc_call32(struct smccc_param32 *param) */
> > > +ENTRY(smccc_call32)
> > > +   stp x28, x30, [sp, #-16]!
> > 
> > Why are you saving lr?
> 
> Agree, no point in saving lr, but I still need to decrease sp with 16 to
> maintain correct alignment. I'll do it with an str instruction instead.

That or pad out with xzr

> > 
> > > +   mov x28, x0
> > > +   ldp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > +   ldp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > +   ldp w4, w5, [x28, #SMC_PARAM_W4_OFFS]
> > > +   ldp w6, w7, [x28, #SMC_PARAM_W6_OFFS]
> > > +   smc #0
> > > +   stp w0, w1, [x28, #SMC_PARAM_W0_OFFS]
> > > +   stp w2, w3, [x28, #SMC_PARAM_W2_OFFS]
> > > +   ldp x28, x30, [sp], #16
> > > +   ret
> > > +ENDPROC(smccc_call32)
> > 
> > Could we deal with this like we do for PSCI instead? (see
> > __invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S
> > and stick this in there too.
> 
> I assume you're referring to when to use "hvc" and "smc".

No, I mean use a C prototype to avoid marshalling the parameters in assembly
like this. As Rutland pointed out, the return value is a bit messy, but
the arguments align nicely with the PCS afaict.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC

[Varadarajan Narayanan]

Add initial dts files and SoC support for IPQ40XX

Signed-off-by: Varadarajan Narayanan 

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 246473a..6b4caee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -477,7 +477,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
-   qcom-msm8974-sony-xperia-honami.dtb
+   qcom-msm8974-sony-xperia-honami.dtb \
+   qcom-ipq40xx-r3pc.dtb
 dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
diff --git a/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts 
b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
new file mode 100644
index 000..7e4e629
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
@@ -0,0 +1,33 @@
+/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "qcom-ipq40xx.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40XX R3PC";
+   compatible = "qcom,ipq40xx-r3pc", "qcom,ipq40xx";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512MB */
+   };
+
+   chosen {
+   bootargs = "root=/dev/ram rw init=/init 
console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246";
+   };
+
+   soc {
+   serial@78b {
+   status = "ok";
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/qcom-ipq40xx.dtsi 
b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
new file mode 100644
index 000..f572f38
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
@@ -0,0 +1,81 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+#include "skeleton.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40XX";
+   compatible = "qcom,ipq40xx";
+   interrupt-parent = <&intc>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   };
+
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   };
+
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x3>;
+   };
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   compatible = "simple-bus";
+
+   intc: interrupt-controller@b00 {
+   compatible = "qcom,msm-qgic2";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   reg = <0x0b00 0x1000>,
+   <0x0b002000 0x1000>;
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = <1 2 0xf08>,
+<1 3 0xf08>,
+<1 4 0xf08>,
+<1 1 0xf08>;
+   clock-frequency = <2083>;
+   };
+
+   serial@78b {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78b 0x200>;
+   interrupts = <0 108 0>;
+   status = "disabled";
+   };
+   };
+};
diff --git a/arch/arm/configs/ipq_defconfig b/arch/arm/configs/ipq_defconfig
index 1cabd8b..054a159 100644
--- a/arch/arm/configs/ipq_defconfig
+++ b/arch/arm/configs/ipq_defconfig
@@ -22,6 +22,7 @@ CONFI

[PATCH V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[Marek Vasut]

From: Graham Moore 

Add binding document for the Cadence QSPI controller.

Signed-off-by: Graham Moore 
Signed-off-by: Marek Vasut 
Cc: Alan Tull 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Dinh Nguyen 
Cc: Graham Moore 
Cc: Vikas MANOCHA 
Cc: Yves Vandervennet 
Cc: devicetree@vger.kernel.org
---
 .../devicetree/bindings/mtd/cadence-quadspi.txt| 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt

V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property "is-decoded-cs" instead of creating a
duplicate, "ext-decoder". Timing parameters are in nanoseconds,
not master reference clocks. Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
V7: - Prefix all of the Cadence-specific properties with cdns prefix,
  those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth",
  "cdns,fifo-width", "cdns,trigger-address".
- Drop bogus properties which were not used and were incorrect.
V8: Align lines to 80 chars.

diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
new file mode 100644
index 000..f248056
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -0,0 +1,56 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be "cdns,qspi-nor".
+- reg : Contains two entries, each of which is a tuple consisting of a
+   physical address and length. The first entry is the address and
+   length of the controller register set. The second entry is the
+   address and length of the QSPI Controller data area.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- cdns,fifo-depth : Size of the data FIFO in words.
+- cdns,fifo-width : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+
+Optional properties:
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
+custom properties:
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
+  mode chip select outputs are de-asserted between
+ transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
+  de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
+  transaction and deasserting the device chip select
+ (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
+  and first bit transfer.
+
+Example:
+
+   qspi: spi@ff705000 {
+   compatible = "cdns,qspi-nor";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xff705000 0x1000>,
+ <0xffa0 0x1000>;
+   interrupts = <0 151 4>;
+   clocks = <&qspi_clk>;
+   cdns,is-decoded-cs;
+   cdns,fifo-depth = <128>;
+   cdns,fifo-width = <4>;
+   cdns,trigger-address = <0x>;
+
+   flash0: n25q00@0 {
+   ...
+   cdns,read-delay = <4>;
+   cdns,tshsl-ns = <50>;
+   cdns,tsd2d-ns = <50>;
+   cdns,tchsh-ns = <4>;
+   cdns,tslch-ns = <4>;
+   };
+   };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[Marek Vasut]

From: Graham Moore 

Add support for the Cadence QSPI controller. This controller is
present in the Altera SoCFPGA SoCs and this driver has been tested
on the Cyclone V SoC.

Signed-off-by: Graham Moore 
Signed-off-by: Marek Vasut 
Cc: Alan Tull 
Cc: Brian Norris 
Cc: David Woodhouse 
Cc: Dinh Nguyen 
Cc: Graham Moore 
Cc: Vikas MANOCHA 
Cc: Yves Vandervennet 
Cc: devicetree@vger.kernel.org
---
 drivers/mtd/spi-nor/Kconfig   |   11 +
 drivers/mtd/spi-nor/Makefile  |1 +
 drivers/mtd/spi-nor/cadence-quadspi.c | 1260 +
 3 files changed, 1272 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c

V2: use NULL instead of modalias in spi_nor_scan call
V3: Use existing property is-decoded-cs instead of creating duplicate.
V4: Support Micron quad mode by snooping command stream for EVCR command
and subsequently configuring Cadence controller for quad mode.
V5: Clean up sparse and smatch complaints.  Remove snooping of Micron
quad mode.  Add comment on XIP mode bit and dummy clock cycles.  Set
up SRAM partition at 1:1 during init.
V6: Remove dts patch that was included by mistake.  Incorporate Vikas's
comments regarding fifo width, SRAM partition setting, and trigger
address.  Trigger address was added as an unsigned int, as it is not
an IO resource per se, and does not need to be mapped. Also add
Marek Vasut's workaround for picking up OF properties on subnodes.
V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*()
  macros and replace them with functions. Get rid of unused variables.
- Implement support for nor->set_protocol() to handle Quad-command,
  this patch now depends on the following patch:
  mtd: spi-nor: notify (Q)SPI controller about protocol change
- Replace that cqspi_fifo_read() disaster with plain old readsl()
  and cqspi_fifo_write() tentacle horror with pretty writesl().
- Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken.
- Get rid of cqspi_find_chipselect() mess, instead just place the
  struct cqspi_st and chipselect number into struct cqspi_flash_pdata
  and set nor->priv to the struct cqspi_flash_pdata of that particular
  chip.
- Replace the odd math in calculate_ticks_for_ns() with DIV_ROUND_UP().
- Make variables const where applicable.
V8: - Implement a function to wait for bit being set/unset for a given
  period of time and use it to replace the ad-hoc bits of code.
- Configure the write underflow watermark to be 1/8 if FIFO size.
- Extract out the SPI NOR flash probing code into separate function
  to clearly mark what will soon be considered a boilerplate code.
- Repair the handling of mode bits, which caused instability in V7.
- Clean up the interrupt handling
- Fix Kconfig help text and make the patch depend on OF and COMPILE_TEST.

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89bf4c1..ed253a2 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -40,4 +40,15 @@ config SPI_NXP_SPIFI
  Flash. Enable this option if you have a device with a SPIFI
  controller and want to access the Flash as a mtd device.
 
+config SPI_CADENCE_QUADSPI
+   tristate "Cadence Quad SPI controller"
+   depends on OF && COMPILE_TEST
+   help
+ Enable support for the Cadence Quad SPI Flash controller.
+
+ Cadence QSPI is a specialized controller for connecting an SPI
+ Flash over 1/2/4-bit wide bus. Enable this option if you have a
+ device with a Cadence QSPI controller and want to access the
+ Flash as an MTD device.
+
 endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index e5e..446c6b9 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI)  += cadence-quadspi.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
 obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
new file mode 100644
index 000..8e024b8
--- /dev/null
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -0,0 +1,1260 @@
+/*
+ * Driver for Cadence QSPI Controller
+ *
+ * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this progra

[PATCH v2] dmaengine: xgene-dma: Fix the lock to allow client for further submission of requests

[Rameshwar Prasad Sahu]

This patch provides the fix in the cleanup routing such that client can perform
further submission by releasing the lock before calling client's callback 
function.

Signed-off-by: Rameshwar Prasad Sahu 
---
 drivers/dma/xgene-dma.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index d1c8809..0b82bc0 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -763,12 +763,17 @@ static void xgene_dma_cleanup_descriptors(struct 
xgene_dma_chan *chan)
struct xgene_dma_ring *ring = &chan->rx_ring;
struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
struct xgene_dma_desc_hw *desc_hw;
+   struct list_head ld_completed;
u8 status;

+   INIT_LIST_HEAD(&ld_completed);
+
+   spin_lock_bh(&chan->lock);
+
/* Clean already completed and acked descriptors */
xgene_dma_clean_completed_descriptor(chan);

-   /* Run the callback for each descriptor, in order */
+   /* Move all completed descriptors to ld completed queue, in order */
list_for_each_entry_safe(desc_sw, _desc_sw, &chan->ld_running, node) {
/* Get subsequent hw descriptor from DMA rx ring */
desc_hw = &ring->desc_hw[ring->head];
@@ -811,15 +816,17 @@ static void xgene_dma_cleanup_descriptors(struct 
xgene_dma_chan *chan)
/* Mark this hw descriptor as processed */
desc_hw->m0 = cpu_to_le64(XGENE_DMA_DESC_EMPTY_SIGNATURE);

-   xgene_dma_run_tx_complete_actions(chan, desc_sw);
-
-   xgene_dma_clean_running_descriptor(chan, desc_sw);
-
/*
 * Decrement the pending transaction count
 * as we have processed one
 */
chan->pending--;
+
+   /*
+* Delete this node from ld running queue and append it to
+* ld completed queue for further processing
+*/
+   list_move_tail(&desc_sw->node, &ld_completed);
}

/*
@@ -828,6 +835,14 @@ static void xgene_dma_cleanup_descriptors(struct 
xgene_dma_chan *chan)
 * ahead and free the descriptors below.
 */
xgene_chan_xfer_ld_pending(chan);
+
+   spin_unlock_bh(&chan->lock);
+
+   /* Run the callback for each descriptor, in order */
+   list_for_each_entry_safe(desc_sw, _desc_sw, &ld_completed, node) {
+   xgene_dma_run_tx_complete_actions(chan, desc_sw);
+   xgene_dma_clean_running_descriptor(chan, desc_sw);
+   }
 }

 static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
@@ -876,11 +891,11 @@ static void xgene_dma_free_chan_resources(struct dma_chan 
*dchan)
if (!chan->desc_pool)
return;

-   spin_lock_bh(&chan->lock);
-
/* Process all running descriptor */
xgene_dma_cleanup_descriptors(chan);

+   spin_lock_bh(&chan->lock);
+
/* Clean all link descriptor queues */
xgene_dma_free_desc_list(chan, &chan->ld_pending);
xgene_dma_free_desc_list(chan, &chan->ld_running);
@@ -1200,15 +1215,11 @@ static void xgene_dma_tasklet_cb(unsigned long data)
 {
struct xgene_dma_chan *chan = (struct xgene_dma_chan *)data;

-   spin_lock_bh(&chan->lock);
-
/* Run all cleanup for descriptors which have been completed */
xgene_dma_cleanup_descriptors(chan);

/* Re-enable DMA channel IRQ */
enable_irq(chan->rx_irq);
-
-   spin_unlock_bh(&chan->lock);
 }

 static irqreturn_t xgene_dma_chan_ring_isr(int irq, void *id)
--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Rameshwar Sahu]

On Fri, Aug 21, 2015 at 2:21 PM, Vinod Koul  wrote:
> On Fri, Aug 21, 2015 at 02:15:08PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Fri, Aug 21, 2015 at 2:09 PM, Vinod Koul  wrote:
>> > On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
>> >> This patch fixes the an locking issue where client callback performs
>> > 
>> > ??
>> >
>> >> further submission.
>> > Do you men you are preventing that or fixing for this to be allowed?
>>
>> Fixing lock to allow client to submit further request in there
>> callback routine if they would like.
>
> Okay please fix the changelog to make it clear :)

Okay Vinod

>
> --
> ~Vinod
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Vinod Koul]

On Fri, Aug 21, 2015 at 02:15:08PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
> 
> On Fri, Aug 21, 2015 at 2:09 PM, Vinod Koul  wrote:
> > On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
> >> This patch fixes the an locking issue where client callback performs
> > 
> > ??
> >
> >> further submission.
> > Do you men you are preventing that or fixing for this to be allowed?
> 
> Fixing lock to allow client to submit further request in there
> callback routine if they would like.

Okay please fix the changelog to make it clear :)

-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Rameshwar Sahu]

Hi Vinod,

On Fri, Aug 21, 2015 at 2:09 PM, Vinod Koul  wrote:
> On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
>> This patch fixes the an locking issue where client callback performs
> 
> ??
>
>> further submission.
> Do you men you are preventing that or fixing for this to be allowed?

Fixing lock to allow client to submit further request in there
callback routine if they would like.
>
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c | 33 ++---
>>  1 file changed, 22 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index d1c8809..0b82bc0 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -763,12 +763,17 @@ static void xgene_dma_cleanup_descriptors(struct 
>> xgene_dma_chan *chan)
>>   struct xgene_dma_ring *ring = &chan->rx_ring;
>>   struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
>>   struct xgene_dma_desc_hw *desc_hw;
>> + struct list_head ld_completed;
>>   u8 status;
>>
>> + INIT_LIST_HEAD(&ld_completed);
>> +
>> + spin_lock_bh(&chan->lock);
>> +
>>   /* Clean already completed and acked descriptors */
>>   xgene_dma_clean_completed_descriptor(chan);
>>
>> - /* Run the callback for each descriptor, in order */
>> + /* Move all completed descriptors to ld completed queue, in order */
>>   list_for_each_entry_safe(desc_sw, _desc_sw, &chan->ld_running, node) {
>>   /* Get subsequent hw descriptor from DMA rx ring */
>>   desc_hw = &ring->desc_hw[ring->head];
>> @@ -811,15 +816,17 @@ static void xgene_dma_cleanup_descriptors(struct 
>> xgene_dma_chan *chan)
>>   /* Mark this hw descriptor as processed */
>>   desc_hw->m0 = cpu_to_le64(XGENE_DMA_DESC_EMPTY_SIGNATURE);
>>
>> - xgene_dma_run_tx_complete_actions(chan, desc_sw);
>> -
>> - xgene_dma_clean_running_descriptor(chan, desc_sw);
>> -
>>   /*
>>* Decrement the pending transaction count
>>* as we have processed one
>>*/
>>   chan->pending--;
>> +
>> + /*
>> +  * Delete this node from ld running queue and append it to
>> +  * ld completed queue for further processing
>> +  */
>> + list_move_tail(&desc_sw->node, &ld_completed);
>>   }
>>
>>   /*
>> @@ -828,6 +835,14 @@ static void xgene_dma_cleanup_descriptors(struct 
>> xgene_dma_chan *chan)
>>* ahead and free the descriptors below.
>>*/
>>   xgene_chan_xfer_ld_pending(chan);
>> +
>> + spin_unlock_bh(&chan->lock);
>> +
>> + /* Run the callback for each descriptor, in order */
>> + list_for_each_entry_safe(desc_sw, _desc_sw, &ld_completed, node) {
>> + xgene_dma_run_tx_complete_actions(chan, desc_sw);
>> + xgene_dma_clean_running_descriptor(chan, desc_sw);
>> + }
>>  }
>>
>>  static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
>> @@ -876,11 +891,11 @@ static void xgene_dma_free_chan_resources(struct 
>> dma_chan *dchan)
>>   if (!chan->desc_pool)
>>   return;
>>
>> - spin_lock_bh(&chan->lock);
>> -
>>   /* Process all running descriptor */
>>   xgene_dma_cleanup_descriptors(chan);
>>
>> + spin_lock_bh(&chan->lock);
>> +
>>   /* Clean all link descriptor queues */
>>   xgene_dma_free_desc_list(chan, &chan->ld_pending);
>>   xgene_dma_free_desc_list(chan, &chan->ld_running);
>> @@ -1200,15 +1215,11 @@ static void xgene_dma_tasklet_cb(unsigned long data)
>>  {
>>   struct xgene_dma_chan *chan = (struct xgene_dma_chan *)data;
>>
>> - spin_lock_bh(&chan->lock);
>> -
>>   /* Run all cleanup for descriptors which have been completed */
>>   xgene_dma_cleanup_descriptors(chan);
>>
>>   /* Re-enable DMA channel IRQ */
>>   enable_irq(chan->rx_irq);
>> -
>> - spin_unlock_bh(&chan->lock);
>>  }
>>
>>  static irqreturn_t xgene_dma_chan_ring_isr(int irq, void *id)
>> --
>> 1.8.2.1
>>
>
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: xgene-dma: Fix holding lock while calling tx callback in cleanup path

[Vinod Koul]

On Thu, Aug 20, 2015 at 04:00:56PM +0530, Rameshwar Prasad Sahu wrote:
> This patch fixes the an locking issue where client callback performs

??

> further submission.
Do you men you are preventing that or fixing for this to be allowed?

> 
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c | 33 ++---
>  1 file changed, 22 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index d1c8809..0b82bc0 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -763,12 +763,17 @@ static void xgene_dma_cleanup_descriptors(struct 
> xgene_dma_chan *chan)
>   struct xgene_dma_ring *ring = &chan->rx_ring;
>   struct xgene_dma_desc_sw *desc_sw, *_desc_sw;
>   struct xgene_dma_desc_hw *desc_hw;
> + struct list_head ld_completed;
>   u8 status;
> 
> + INIT_LIST_HEAD(&ld_completed);
> +
> + spin_lock_bh(&chan->lock);
> +
>   /* Clean already completed and acked descriptors */
>   xgene_dma_clean_completed_descriptor(chan);
> 
> - /* Run the callback for each descriptor, in order */
> + /* Move all completed descriptors to ld completed queue, in order */
>   list_for_each_entry_safe(desc_sw, _desc_sw, &chan->ld_running, node) {
>   /* Get subsequent hw descriptor from DMA rx ring */
>   desc_hw = &ring->desc_hw[ring->head];
> @@ -811,15 +816,17 @@ static void xgene_dma_cleanup_descriptors(struct 
> xgene_dma_chan *chan)
>   /* Mark this hw descriptor as processed */
>   desc_hw->m0 = cpu_to_le64(XGENE_DMA_DESC_EMPTY_SIGNATURE);
> 
> - xgene_dma_run_tx_complete_actions(chan, desc_sw);
> -
> - xgene_dma_clean_running_descriptor(chan, desc_sw);
> -
>   /*
>* Decrement the pending transaction count
>* as we have processed one
>*/
>   chan->pending--;
> +
> + /*
> +  * Delete this node from ld running queue and append it to
> +  * ld completed queue for further processing
> +  */
> + list_move_tail(&desc_sw->node, &ld_completed);
>   }
> 
>   /*
> @@ -828,6 +835,14 @@ static void xgene_dma_cleanup_descriptors(struct 
> xgene_dma_chan *chan)
>* ahead and free the descriptors below.
>*/
>   xgene_chan_xfer_ld_pending(chan);
> +
> + spin_unlock_bh(&chan->lock);
> +
> + /* Run the callback for each descriptor, in order */
> + list_for_each_entry_safe(desc_sw, _desc_sw, &ld_completed, node) {
> + xgene_dma_run_tx_complete_actions(chan, desc_sw);
> + xgene_dma_clean_running_descriptor(chan, desc_sw);
> + }
>  }
> 
>  static int xgene_dma_alloc_chan_resources(struct dma_chan *dchan)
> @@ -876,11 +891,11 @@ static void xgene_dma_free_chan_resources(struct 
> dma_chan *dchan)
>   if (!chan->desc_pool)
>   return;
> 
> - spin_lock_bh(&chan->lock);
> -
>   /* Process all running descriptor */
>   xgene_dma_cleanup_descriptors(chan);
> 
> + spin_lock_bh(&chan->lock);
> +
>   /* Clean all link descriptor queues */
>   xgene_dma_free_desc_list(chan, &chan->ld_pending);
>   xgene_dma_free_desc_list(chan, &chan->ld_running);
> @@ -1200,15 +1215,11 @@ static void xgene_dma_tasklet_cb(unsigned long data)
>  {
>   struct xgene_dma_chan *chan = (struct xgene_dma_chan *)data;
> 
> - spin_lock_bh(&chan->lock);
> -
>   /* Run all cleanup for descriptors which have been completed */
>   xgene_dma_cleanup_descriptors(chan);
> 
>   /* Re-enable DMA channel IRQ */
>   enable_irq(chan->rx_irq);
> -
> - spin_unlock_bh(&chan->lock);
>  }
> 
>  static irqreturn_t xgene_dma_chan_ring_isr(int irq, void *id)
> --
> 1.8.2.1
> 

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 2/5] Documentation: Detail permitted DT properties for the imx6ul_tsc

[Chen Bough]

Hi Markus,

> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: Wednesday, August 19, 2015 1:55 PM
> To: Chen Haibo-B51421
> Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; shawn...@kernel.org;
> ker...@pengutronix.de; li...@arm.linux.org.uk; dmitry.torok...@gmail.com;
> devicetree@vger.kernel.org; sbran...@broadcom.com; a...@arndb.de;
> mche...@osg.samsung.com; christian.gmei...@gmail.com;
> scott@emc.com.tw; linux-ker...@vger.kernel.org; hdego...@redhat.com;
> jonat...@broadcom.com; benjamin.tissoi...@redhat.com;
> hans.verk...@cisco.com; had...@hadess.net; linux-in...@vger.kernel.org;
> ge...@linux-m68k.org; sebastien.szyman...@armadeus.com;
> mamli...@gmail.com; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 2/5] Documentation: Detail permitted DT properties
> for the imx6ul_tsc
> 
> Hi,
> 
> On Tue, Jul 28, 2015 at 05:58:38PM +0800, Haibo Chen wrote:
> > Here we apply required documentation for the imx6ul touch screen
> > controller driver which describe available properties and how to use
> > them.
> >
> > Signed-off-by: Haibo Chen 
> > ---
> >  .../bindings/input/touchscreen/imx6ul_tsc.txt  | 36
> ++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> > b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> > new file mode 100644
> > index 000..ac41c32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.t
> > +++ xt
> > @@ -0,0 +1,36 @@
> > +* Freescale i.MX6UL Touch Controller
> > +
> > +Required properties:
> > +- compatible: must be "fsl,imx6ul-tsc".
> > +- reg: this touch controller address and the ADC2 address.
> 
> This suggests that this driver is using a unit ADC2. Which also means
> that there are more than one ADC which are probably identical?
> 
> Shouldn't these ADCs be properly described by their own device nodes
> instead of these two register ranges, two interrupts and two clocks?
> 
> Is 'ADC2' usable without tsc? Then ADC1/ADC2 should perhaps get a proper
> IIO driver.

For i.MX6UL, there are two ADC. ADC1 is a normal ADC, and ADC2 can only works 
for
TSC, the channels of ADC2 are connected to TSC directly. TSC and ADC2 should 
work
together as a touch screen controller. 

For ADC1, it share the driver vf610_adc.c (drivers/iio/adc/vf610_adc.c). 

Best Regards

Haibo 
 
> 
> Unfortunately I don't have the reference manual to have a look how this
> all works.
> 
> Best regards,
> 
> Markus
> 
> > +- interrupts: the interrupt of this touch controller and ADC2.
> > +- clocks: the root clock of touch controller and ADC2.
> > +- clock-names; must be "tsc" and "adc".
> > +- xnur-gpio: the X- gpio this controller connect to.
> > +  This xnur-gpio returns to high once the finger leave the touch
> > +screen (The
> > +  last touch event the touch controller capture).
> > +
> > +Optional properties:
> > +- measure-delay-time: the value of measure delay time.
> > +  Before X-axis or Y-axis measurement, the screen need some time
> > +before
> > +  even potential distribution ready.
> > +  This value depends on the touch screen.
> > +- pre-charge-time: the touch screen need some time to precharge.
> > +  This value depends on the touch screen.
> > +
> > +Example:
> > +   tsc: tsc@0204 {
> > +   compatible = "fsl,imx6ul-tsc";
> > +   reg = <0x0204 0x4000>, <0x0219c000 0x4000>;
> > +   interrupts = ,
> > +;
> > +   clocks = <&clks IMX6UL_CLK_IPG>,
> > +<&clks IMX6UL_CLK_ADC2>;
> > +   clock-names = "tsc", "adc";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_tsc>;
> > +   xnur-gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
> > +   measure-delay-time = <0xfff>;
> > +   pre-charge-time = <0x>;
> > +   status = "okay";
> > +   };
> > --
> > 1.9.1
> >
> >
> >
> 
> --
> Pengutronix e.K.   |
> |
> Industrial Linux Solutions | http://www.pengutronix.de/
> |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917-
> |
N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

[Jingoo Han]

On 2015. 8. 19., at PM 11:48, Yakir Yang  wrote:
> 
> 

.

> .../bindings/video/analogix_dp-rockchip.txt|   83 ++
> .../devicetree/bindings/video/exynos_dp.txt|   51 +-
> arch/arm/boot/dts/exynos5250-arndale.dts   |   10 +-
> arch/arm/boot/dts/exynos5250-smdk5250.dts  |   10 +-
> arch/arm/boot/dts/exynos5250-snow.dts  |   12 +-
> arch/arm/boot/dts/exynos5250-spring.dts|   12 +-
> arch/arm/boot/dts/exynos5420-peach-pit.dts |   12 +-
> arch/arm/boot/dts/exynos5420-smdk5420.dts  |   10 +-
> arch/arm/boot/dts/exynos5800-peach-pi.dts  |   12 +-
> drivers/gpu/drm/bridge/Kconfig |5 +
> drivers/gpu/drm/bridge/Makefile|1 +
> drivers/gpu/drm/bridge/analogix_dp_core.c  | 1382 +++
> drivers/gpu/drm/bridge/analogix_dp_core.h  |  286 
> drivers/gpu/drm/bridge/analogix_dp_reg.c   | 1294 ++
> .../exynos_dp_reg.h => bridge/analogix_dp_reg.h}   |  270 ++--
> drivers/gpu/drm/exynos/Kconfig |5 +-
> drivers/gpu/drm/exynos/Makefile|2 +-
> drivers/gpu/drm/exynos/analogix_dp-exynos.c|  347 +

Would you change this file name to "exynos_dp.c"?

Best regards,
Jingoo Han

> drivers/gpu/drm/exynos/exynos_dp_core.c| 1416 
> drivers/gpu/drm/exynos/exynos_dp_core.h|  282 
> drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263 -
> drivers/gpu/drm/rockchip/Kconfig   |9 +
> drivers/gpu/drm/rockchip/Makefile  |1 +
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  390 ++
> drivers/phy/Kconfig|7 +
> drivers/phy/Makefile   |1 +
> drivers/phy/phy-rockchip-dp.c  |  185 +++
> include/drm/bridge/analogix_dp.h   |   40 +
> 30 files changed, 4325 insertions(+), 3172 deletions(-)
> create mode 100644 
> Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> create mode 100644 
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> create mode 100644 drivers/gpu/drm/bridge/analogix_dp_core.c
> create mode 100644 drivers/gpu/drm/bridge/analogix_dp_core.h
> create mode 100644 drivers/gpu/drm/bridge/analogix_dp_reg.c
> rename drivers/gpu/drm/{exynos/exynos_dp_reg.h => bridge/analogix_dp_reg.h} 
> (62%)
> create mode 100644 drivers/gpu/drm/exynos/analogix_dp-exynos.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
> create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> create mode 100644 drivers/phy/phy-rockchip-dp.c
> create mode 100644 include/drm/bridge/analogix_dp.h
> 
> -- 
> 1.9.1
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 1/5] input: touchscreen: add imx6ul_tsc driver support

[Chen Bough]

Hi Dmitry,

Thanks for your patient review, especially for the patch you attached.

I test your patch these days, with below change, touch can work normally.
(also change the xnur to active low in dts)

In probe function:

> - tsc->xnur_gpio = of_get_named_gpio(np, "xnur-gpio", 0);
> - err = gpio_request_one(tsc->xnur_gpio, GPIOF_IN, "tsc_X-");
> - if (err) {
> - dev_err(&pdev->dev, "failed to request GPIO tsc_X-\n");
> + input_set_drvdata(input_dev, tsc);
> +
> + tsc->dev = &pdev->dev;
> + tsc->input = input_dev;
> + init_completion(&tsc->completion);
> +
> + tsc->xnur_gpio = devm_gpiod_get(&pdev->dev, "xnur-gpio", GPIOD_IN);  

Here, we need to change "xnur-gpio" to "xnur", otherwise the gpio request will 
be failed.
This is because gpiod common code already add suffix '-gpio' or 'gpios'.  



For others, your patch seems normal and rational. I will add your patch and 
send patch-V3.

Thanks again!


Best Regards
Haibo Chen



> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: Wednesday, August 19, 2015 1:12 PM
> To: Chen Haibo-B51421
> Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; shawn...@kernel.org;
> ker...@pengutronix.de; li...@arm.linux.org.uk; hans.verk...@cisco.com;
> had...@hadess.net; mche...@osg.samsung.com; mamli...@gmail.com;
> a...@arndb.de; jonat...@broadcom.com; hdego...@redhat.com;
> christian.gmei...@gmail.com; scott@emc.com.tw; ge...@linux-m68k.org;
> benjamin.tissoi...@redhat.com; sebastien.szyman...@armadeus.com;
> sbran...@broadcom.com; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> in...@vger.kernel.org
> Subject: Re: [PATCH v2 1/5] input: touchscreen: add imx6ul_tsc driver
> support
> 
> Hi Haibo,
> 
> On Tue, Jul 28, 2015 at 05:58:37PM +0800, Haibo Chen wrote:
> > Freescale i.MX6UL contains a internal touchscreen controller, this
> > patch add a driver to support this controller.
> >
> 
> This looks pretty reasonable; just a few comments below.
> 
> > Signed-off-by: Haibo Chen 
> > ---
> >  drivers/input/touchscreen/Kconfig  |  12 +
> >  drivers/input/touchscreen/Makefile |   1 +
> >  drivers/input/touchscreen/imx6ul_tsc.c | 504
> > +
> >  3 files changed, 517 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/imx6ul_tsc.c
> >
> > diff --git a/drivers/input/touchscreen/Kconfig
> > b/drivers/input/touchscreen/Kconfig
> > index 5b272ba..32c300d 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -479,6 +479,18 @@ config TOUCHSCREEN_MTOUCH
> >   To compile this driver as a module, choose M here: the
> >   module will be called mtouch.
> >
> > +config TOUCHSCREEN_IMX6UL_TSC
> > +   tristate "Freescale i.MX6UL touchscreen controller"
> > +   depends on OF
> > +   help
> > + Say Y here if you have a Freescale i.MX6UL, and want to
> > + use the internal touchscreen controller.
> > +
> > + If unsure, say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + moduel will be called imx6ul_tsc.
> > +
> >  config TOUCHSCREEN_INEXIO
> > tristate "iNexio serial touchscreens"
> > select SERIO
> > diff --git a/drivers/input/touchscreen/Makefile
> > b/drivers/input/touchscreen/Makefile
> > index c85aae2..9379b32 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX)  += egalax_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_FUJITSU)  += fujitsu_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_GOODIX)   += goodix.o
> >  obj-$(CONFIG_TOUCHSCREEN_ILI210X)  += ili210x.o
> > +obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC)   += imx6ul_tsc.o
> >  obj-$(CONFIG_TOUCHSCREEN_INEXIO)   += inexio.o
> >  obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)+= intel-mid-touch.o
> >  obj-$(CONFIG_TOUCHSCREEN_IPROC)+= bcm_iproc_tsc.o
> > diff --git a/drivers/input/touchscreen/imx6ul_tsc.c
> > b/drivers/input/touchscreen/imx6ul_tsc.c
> > new file mode 100644
> > index 000..807f1db
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> > @@ -0,0 +1,504 @@
> > +/*
> > + * Freescale i.MX6UL touchscreen controller driver
> > + *
> > + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> I do not think you need of_irq and of_device.
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* ADC configuration registers field define *

Re: [PATCH] of: add vendor prefix for Socionext Inc.

[Masahiro Yamada]

Hi Grant,

I guess this patch should go in thru the devicetree subsystem.
(or ARM-SOC?)

It is really trivial, so could you apply it for 4.3-rc1, please?


2015-07-29 18:45 GMT+09:00 Masahiro Yamada :
> Signed-off-by: Masahiro Yamada 
> ---
>
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index d444757..5ab8f6b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -192,6 +192,7 @@ sitronixSitronix Technology Corporation
>  skyworks   Skyworks Solutions, Inc.
>  smsc   Standard Microsystems Corporation
>  snps   Synopsys, Inc.
> +socionext  Socionext Inc.
>  solidrun   SolidRun
>  solomonSolomon Systech Limited
>  sony   Sony Corporation
> --
> 1.9.1
>


-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re-using sun5i-a13.dtsi for the r8 ?

[Hans de Goede]

Hi Maxime,

I just realized that I never answered your question about the need
for a tvencoder simplefb node in sun5i-a13.dtsi, like the one from
the "ARM: dts: sun5i: Add simplefb node for tvencoder output"

I think the real question is do we want to use sun5i-a13.dtsi for
the r8 ?

I would expect us to use a sun5i-r8.dtsi, this one could then
include sun5i-a13.dtsi, and have the extra simplefb node for
the tvencoder. Putting the simplefb node for the tvencoder
in sun5i-a13.dtsi feels wrong because the A13 package does
not have a tvout pin.

Does that sound like a good solution to you ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v6 1/9] mmc: dw_mmc: Add external dma interface support

[Shawn Lin]

On 2015/8/21 15:38, Jaehoon Chung wrote:

On 08/21/2015 04:27 PM, Shawn Lin wrote:

On 2015/8/21 14:35, Jaehoon Chung wrote:

On 08/21/2015 03:30 PM, Shawn Lin wrote:

On 2015/8/21 14:27, Jaehoon Chung wrote:

Hi, Shawn.

Is this based on Ulf's repository?



no, it's based on "https://github.com/jh80chung/dw-mmc.git 
tags/dw-mmc-for-ulf-v4.2" ：）


Oh..I will rebase to Ulf's next branch on this weekend.
Then could you rebase this patch? And i added more comments at below.. :)



Okay, I will rebase to Ulf's next.


Best Regards,
Jaehoon Chung





[...]


index ec6dbcd..7e1d13b 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,6 +59,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
host->pdata = pdev->dev.platform_data;

regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+/* Get registers' physical base address */
+host->phy_regs = (void *)(regs->start);
host->regs = devm_ioremap_resource(&pdev->dev, regs);
if (IS_ERR(host->regs))
return PTR_ERR(host->regs);


Is this board specific code? If so, separate the patch.


It's might not board specific code.
dmaengine need dw_mmc's *physical* fifo address for data transfer, so I get 
controller physical address  here in order to calculate physical fifo address.

regs is from dt-bindings, for instance:
  dwmmc0@1220 {
  compatible = "snps,dw-mshc";
   clocks = <&clock 351>, <&clock 132>;
  clock-names = "biu", "ciu";
  reg = <0x1220 0x1000>;
  interrupts = <0 75 0>;
  #address-cells = <1>;
  #size-cells = <0>;
  };

so, host->phy_regs will be 0x1220 .

[...]


+static void dw_mci_dmac_complete_dma(void *arg)
{
+struct dw_mci *host = arg;
struct mmc_data *data = host->data;

dev_vdbg(host->dev, "DMA complete\n");

+if (host->use_dma == TRANS_MODE_EDMAC)
+if (data && (data->flags & MMC_DATA_READ))


Combine one condition.


okay.

[...]


+u32 fifo_offset = host->fifo_reg - host->regs;
+int ret = 0;
+
+/* Set external dma config: burst size, burst width */
+cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);


host->phy_regs is not assigned?


we got it at dw_mci_pltfm_register. See comments above. :)

[...]


mmc->max_blk_count = mmc->max_req_size / 512;
+} else if (host->use_dma == TRANS_MODE_EDMAC) {
+mmc->max_segs = 64;
+mmc->max_blk_size = 65536;
+mmc->max_blk_count = 65535;
+mmc->max_req_size =
+mmc->max_blk_size * mmc->max_blk_count;
+mmc->max_seg_size = mmc->max_req_size;


Fix the indention


Hmm..I check it attentively but can't find the indention . Might it's because 
you apply it against Ulf's repo?





[...]



-/* Alloc memory for sg translation */
-host->sg_cpu = dmam_alloc_coherent(host->dev, PAGE_SIZE,
-  &host->sg_dma, GFP_KERNEL);
-if (!host->sg_cpu) {
-dev_err(host->dev, "%s: could not alloc DMA memory\n",
-__func__);
+/* Check tansfer mode */
+trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
+if (trans_mode == 0) {
+trans_mode = TRANS_MODE_IDMAC;
+} else if (trans_mode == 1 || trans_mode == 2) {
+trans_mode = TRANS_MODE_EDMAC;
+} else {
+trans_mode = TRANS_MODE_PIO;


what are trans_mode "0, 1, 2"?
(00 - none) is NO-DMA interface, isn't? is it IDMAC mode?



No, I guess the databook's ambiguous description confuse everybody.

I got double comfirm from my ASCI team as well as Synoposys
2b'00: NO-DMA interface -->  It support IDMAC actually
2b'01 & 2b'02: DW_DMA & GENERIC_DMA --> Support 2 types of external dma.
2b'02: NON-DW-DMA --> only support PIO


Then Could you add the comment about this?
Use definition instead of "0, 1, 2". Developer don't know meaning that is 0, 1, 
2.



Okay. :)))


Best Regards,
Jaehoon Chung



refer to the description below:
Parameter Name: DMA_INTERFACE
Legal Values: 0-3
Default Value: 0
Description:
  0- No DMA Interface
  1- DesignWare DMA Interface
  2- Generic DMA Interface
  3- Non DW DMA Interface
In DesignWare DMA mode, request/acknowledge protocol meets DW_ahb_dmac
controller protocol. In this mode, host data bus is also used for DMA 
transfers.Generic DMA-type interface has simpler request/acknowledge handshake 
and has dedicated read/write data bus for DMA transfers. Non DW DMAC interface 
uses dw_dma_single interface in addition to the existing interface and uses 
host data bus for DMA transfers. This is configurable only if INTERNAL_DMAC=0.


goto no_dma;
}



+dev_info(host->dev, "Using external DMA controller.\n");
+}

if (!host->dma_ops)
goto no_dma;
@@ -2562,12 +2720,12 @@ static void dw_mci_init_dma(struct dw_mci *host)
goto no_dma;

Re: [linux-sunxi][PATCH] ARM: sun7i: dt: Add new Olimex A20 EVB device

[Hans de Goede]

Hi,

On 21-08-15 09:42, Hans de Goede wrote:

Hi,

On 21-08-15 07:36, Code Kipper wrote:

On 20 August 2015 at 17:45, Maxime Ripard 
wrote:


Hi,

On Wed, Aug 19, 2015 at 06:43:16PM +0200, codekip...@gmail.com wrote:

From: Marcus Cooper 

The A20-SOM-EVB is a reference design of a 2-layer board for the
A20-SOM.
It expands the features of A20-SOM by adding VGA connector, HDMI
connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
Ethernet, SATA, USB-OTG and 2 USB hosts.

This patch adds basic support for the device
https://www.olimex.com/Products/SOM/A20/A20-SOM-EVB/

More information on the SOM can be found here
http://linux-sunxi.org/Olimex_A20-SOM.

Signed-off-by: Marcus Cooper 


Is there any other SOM planned that could work with that baseboard? Or
any other baseboard for that SOM?


I've seen neither. We could always create a som.dtsi later is one emerges.




---
  arch/arm/boot/dts/Makefile|   1 +
  arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts | 233

++

  2 files changed, 234 insertions(+)
  create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts



Relooking at their website I can see that the device does not come under
the olinuxino brand so maybe I should rename the dts to
sun7i-a20-olimex-som-evb.dts


Ack for renaming / +1

Regards,

Hans


p.s.

Can you please also send a v2 of the u-boot patch taking the renaming into
account ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi][PATCH] ARM: sun7i: dt: Add new Olimex A20 EVB device

[Hans de Goede]

Hi,

On 21-08-15 07:36, Code Kipper wrote:

On 20 August 2015 at 17:45, Maxime Ripard 
wrote:


Hi,

On Wed, Aug 19, 2015 at 06:43:16PM +0200, codekip...@gmail.com wrote:

From: Marcus Cooper 

The A20-SOM-EVB is a reference design of a 2-layer board for the
A20-SOM.
It expands the features of A20-SOM by adding VGA connector, HDMI
connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
Ethernet, SATA, USB-OTG and 2 USB hosts.

This patch adds basic support for the device
https://www.olimex.com/Products/SOM/A20/A20-SOM-EVB/

More information on the SOM can be found here
http://linux-sunxi.org/Olimex_A20-SOM.

Signed-off-by: Marcus Cooper 


Is there any other SOM planned that could work with that baseboard? Or
any other baseboard for that SOM?


I've seen neither. We could always create a som.dtsi later is one emerges.




---
  arch/arm/boot/dts/Makefile|   1 +
  arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts | 233

++

  2 files changed, 234 insertions(+)
  create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts



Relooking at their website I can see that the device does not come under
the olinuxino brand so maybe I should rename the dts to
sun7i-a20-olimex-som-evb.dts


Ack for renaming / +1

Regards,

Hans





diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6d7cec1..fdbda9b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -613,6 +613,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
   sun7i-a20-olinuxino-lime.dtb \
   sun7i-a20-olinuxino-lime2.dtb \
   sun7i-a20-olinuxino-micro.dtb \
+ sun7i-a20-olinuxino-evb.dtb \
   sun7i-a20-orangepi.dtb \
   sun7i-a20-orangepi-mini.dtb \
   sun7i-a20-pcduino3.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts

b/arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts

new file mode 100644
index 000..a0071fa
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts
@@ -0,0 +1,233 @@
+/*
+ * Copyright 2015 - Marcus Cooper 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of

the

+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+ model = "Olimex A20-OLinuXino-EVB";
+ compatible = "olimex,a20-olinuxino-evb", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins_olinuxinoevb>;
+
+ green {
+ label = "a20-olinuxino-evb:green:usr";
+ gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ reg_axp_ipsout: axp_ipsout {
+ compatible = "regulator-fixed";
+ regulator-name = "axp-ipsout";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-a

Re: [PATCH v2 00/16] omap_hsmmc: regulator usage cleanup and fixes

[Tony Lindgren]

* Kishon Vijay Abraham I  [150820 05:39]:
> Hi,
> 
> On Monday 03 August 2015 05:56 PM, Kishon Vijay Abraham I wrote:
> > Changes from v1:
> > *) return on -EPROBE_DEFER and other fatal errors. (Don't return only
> >if the return value is -ENODEV)
> > *) Remove the beagle x15 dts patch. It can be part of a different
> >series.
> > *) Avoid using regulator_is_enabled for vqmmc since if the regulator
> >is shared and the other users are not using regulator_is_enabled
> >then there can be unbalanced regulator_enable/regulator_disable
> > 
> > This patch series does the following
> > *) Uses devm_regulator_get_optional() for vmmc and then removes the
> >CONFIG_REGULATOR check altogether.
> > *) return on -EPROBE_DEFER and any other fatal errors
> > *) enable/disable vmmc_aux regulator based on prior state
> > 
> > I've pushed this patch series to
> > git://git.ti.com/linux-phy/linux-phy.git mmc_regulator_cleanup_fixes_v2
> > 
> > Please note the branch also has the pbias fixes [1] & [2].
> > [1] -> https://lkml.org/lkml/2015/7/27/358
> > [2] -> https://lkml.org/lkml/2015/7/27/391
> > 
> > This series is in preparation for implementing the voltage switch
> > sequence so that UHS cards can be supported.
> > 
> > Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM,
> > Beaglebone black, OMAP5 uEVM and OMAP4 PANDA.
> 
> I have now done read/write test in omap3 beagle-xm with this series!

Great thanks for doing that. Also gave this series a try here
with my off idle MMC SDIO WLAN card test and things still work
for me. That's not really testing the PBIAS regulator though,
but a good torture test for saving and restoring context. So
FWIW:

Tested-by: Tony Lindgren 

If you need a PM torture test for PBIAS regulator, you could try
to do the following on your beagle xm MMC card with
oamp2plus_defconfig:

1. Make sure EHCI modules are not loaded and OTG USB cable is
   not connected

2. Enable UART timeouts and off idle with something like:

!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

modprobe leds-gpio
modprobe ledtrig-default-on

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
echo enabled > $uart/wakeup 2>&1
echo auto > $uart/control 2>&1
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode

3. Make sure you start seeing core_pwrdm OFF count increasing
   with cat /sys/kernel/debug/pm_debug/count

MMC should keep on working when hitting idle, if not, something
is not saved or restored properly. And SDIO WLAN cards should
wake up the system and respond to ping if the wakeirq is
configured in the dts file for the MMC controller. At least
mwifiex_sdio cards work for this :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v6 1/9] mmc: dw_mmc: Add external dma interface support

[Jaehoon Chung]

On 08/21/2015 04:27 PM, Shawn Lin wrote:
> On 2015/8/21 14:35, Jaehoon Chung wrote:
>> On 08/21/2015 03:30 PM, Shawn Lin wrote:
>>> On 2015/8/21 14:27, Jaehoon Chung wrote:
 Hi, Shawn.

 Is this based on Ulf's repository?
>>>
>>>
>>> no, it's based on "https://github.com/jh80chung/dw-mmc.git 
>>> tags/dw-mmc-for-ulf-v4.2" ：）
>>
>> Oh..I will rebase to Ulf's next branch on this weekend.
>> Then could you rebase this patch? And i added more comments at below.. :)
>>
> 
> Okay, I will rebase to Ulf's next.
> 
>> Best Regards,
>> Jaehoon Chung
>>
>>>
> 
> [...]
> 
> index ec6dbcd..7e1d13b 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -59,6 +59,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
>host->pdata = pdev->dev.platform_data;
>
>regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +/* Get registers' physical base address */
> +host->phy_regs = (void *)(regs->start);
>host->regs = devm_ioremap_resource(&pdev->dev, regs);
>if (IS_ERR(host->regs))
>return PTR_ERR(host->regs);

 Is this board specific code? If so, separate the patch.
> 
> It's might not board specific code.
> dmaengine need dw_mmc's *physical* fifo address for data transfer, so I get 
> controller physical address  here in order to calculate physical fifo address.
> 
> regs is from dt-bindings, for instance:
>  dwmmc0@1220 {
>  compatible = "snps,dw-mshc";
>   clocks = <&clock 351>, <&clock 132>;
>  clock-names = "biu", "ciu";
>  reg = <0x1220 0x1000>;
>  interrupts = <0 75 0>;
>  #address-cells = <1>;
>  #size-cells = <0>;
>  };
> 
> so, host->phy_regs will be 0x1220 .
> 
> [...]
> 
> +static void dw_mci_dmac_complete_dma(void *arg)
>{
> +struct dw_mci *host = arg;
>struct mmc_data *data = host->data;
>
>dev_vdbg(host->dev, "DMA complete\n");
>
> +if (host->use_dma == TRANS_MODE_EDMAC)
> +if (data && (data->flags & MMC_DATA_READ))

 Combine one condition.
> 
> okay.
> 
> [...]
> 
> +u32 fifo_offset = host->fifo_reg - host->regs;
> +int ret = 0;
> +
> +/* Set external dma config: burst size, burst width */
> +cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);

 host->phy_regs is not assigned?
> 
> we got it at dw_mci_pltfm_register. See comments above. :)
> 
> [...]
> 
>mmc->max_blk_count = mmc->max_req_size / 512;
> +} else if (host->use_dma == TRANS_MODE_EDMAC) {
> +mmc->max_segs = 64;
> +mmc->max_blk_size = 65536;
> +mmc->max_blk_count = 65535;
> +mmc->max_req_size =
> +mmc->max_blk_size * mmc->max_blk_count;
> +mmc->max_seg_size = mmc->max_req_size;

 Fix the indention
> 
> Hmm..I check it attentively but can't find the indention . Might it's because 
> you apply it against Ulf's repo?
> 

> 
> [...]
> 
>
> -/* Alloc memory for sg translation */
> -host->sg_cpu = dmam_alloc_coherent(host->dev, PAGE_SIZE,
> -  &host->sg_dma, GFP_KERNEL);
> -if (!host->sg_cpu) {
> -dev_err(host->dev, "%s: could not alloc DMA memory\n",
> -__func__);
> +/* Check tansfer mode */
> +trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
> +if (trans_mode == 0) {
> +trans_mode = TRANS_MODE_IDMAC;
> +} else if (trans_mode == 1 || trans_mode == 2) {
> +trans_mode = TRANS_MODE_EDMAC;
> +} else {
> +trans_mode = TRANS_MODE_PIO;

 what are trans_mode "0, 1, 2"?
 (00 - none) is NO-DMA interface, isn't? is it IDMAC mode?

> 
> No, I guess the databook's ambiguous description confuse everybody.
> 
> I got double comfirm from my ASCI team as well as Synoposys
> 2b'00: NO-DMA interface -->  It support IDMAC actually
> 2b'01 & 2b'02: DW_DMA & GENERIC_DMA --> Support 2 types of external dma.
> 2b'02: NON-DW-DMA --> only support PIO

Then Could you add the comment about this?
Use definition instead of "0, 1, 2". Developer don't know meaning that is 0, 1, 
2.

Best Regards,
Jaehoon Chung

> 
> refer to the description below:
> Parameter Name: DMA_INTERFACE
> Legal Values: 0-3
> Default Value: 0
> Description:
>  0- No DMA Interface
>  1- DesignWare DMA Interface
>  2- Generic DMA Interface
>  3- Non DW DMA Interface
> In DesignWare DMA mode, request/acknowledge protocol meets DW_ahb_dmac
> controller protocol. In this mode, host data bus is also used for DMA 
> transfers.Generic DMA-type interface has simpler request/acknowledge 
> handshake and has dedicated read/write data bus for DMA transfers. Non DW 
> DMAC interfac

Re: [RFC PATCH v6 1/9] mmc: dw_mmc: Add external dma interface support

[Shawn Lin]

On 2015/8/21 14:35, Jaehoon Chung wrote:

On 08/21/2015 03:30 PM, Shawn Lin wrote:

On 2015/8/21 14:27, Jaehoon Chung wrote:

Hi, Shawn.

Is this based on Ulf's repository?



no, it's based on "https://github.com/jh80chung/dw-mmc.git 
tags/dw-mmc-for-ulf-v4.2" ：）


Oh..I will rebase to Ulf's next branch on this weekend.
Then could you rebase this patch? And i added more comments at below.. :)



Okay, I will rebase to Ulf's next.


Best Regards,
Jaehoon Chung





[...]


index ec6dbcd..7e1d13b 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,6 +59,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
   host->pdata = pdev->dev.platform_data;

   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+/* Get registers' physical base address */
+host->phy_regs = (void *)(regs->start);
   host->regs = devm_ioremap_resource(&pdev->dev, regs);
   if (IS_ERR(host->regs))
   return PTR_ERR(host->regs);


Is this board specific code? If so, separate the patch.


It's might not board specific code.
dmaengine need dw_mmc's *physical* fifo address for data transfer, so I 
get controller physical address  here in order to calculate physical 
fifo address.


regs is from dt-bindings, for instance:
 dwmmc0@1220 {
 compatible = "snps,dw-mshc";
  clocks = <&clock 351>, <&clock 132>;
 clock-names = "biu", "ciu";
 reg = <0x1220 0x1000>;
 interrupts = <0 75 0>;
 #address-cells = <1>;
 #size-cells = <0>;
 };

so, host->phy_regs will be 0x1220 .

[...]


+static void dw_mci_dmac_complete_dma(void *arg)
   {
+struct dw_mci *host = arg;
   struct mmc_data *data = host->data;

   dev_vdbg(host->dev, "DMA complete\n");

+if (host->use_dma == TRANS_MODE_EDMAC)
+if (data && (data->flags & MMC_DATA_READ))


Combine one condition.


okay.

[...]


+u32 fifo_offset = host->fifo_reg - host->regs;
+int ret = 0;
+
+/* Set external dma config: burst size, burst width */
+cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);


host->phy_regs is not assigned?


we got it at dw_mci_pltfm_register. See comments above. :)

[...]


   mmc->max_blk_count = mmc->max_req_size / 512;
+} else if (host->use_dma == TRANS_MODE_EDMAC) {
+mmc->max_segs = 64;
+mmc->max_blk_size = 65536;
+mmc->max_blk_count = 65535;
+mmc->max_req_size =
+mmc->max_blk_size * mmc->max_blk_count;
+mmc->max_seg_size = mmc->max_req_size;


Fix the indention


Hmm..I check it attentively but can't find the indention . Might it's 
because you apply it against Ulf's repo?






[...]



-/* Alloc memory for sg translation */
-host->sg_cpu = dmam_alloc_coherent(host->dev, PAGE_SIZE,
-  &host->sg_dma, GFP_KERNEL);
-if (!host->sg_cpu) {
-dev_err(host->dev, "%s: could not alloc DMA memory\n",
-__func__);
+/* Check tansfer mode */
+trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
+if (trans_mode == 0) {
+trans_mode = TRANS_MODE_IDMAC;
+} else if (trans_mode == 1 || trans_mode == 2) {
+trans_mode = TRANS_MODE_EDMAC;
+} else {
+trans_mode = TRANS_MODE_PIO;


what are trans_mode "0, 1, 2"?
(00 - none) is NO-DMA interface, isn't? is it IDMAC mode?



No, I guess the databook's ambiguous description confuse everybody.

I got double comfirm from my ASCI team as well as Synoposys
2b'00: NO-DMA interface -->  It support IDMAC actually
2b'01 & 2b'02: DW_DMA & GENERIC_DMA --> Support 2 types of external dma.
2b'02: NON-DW-DMA --> only support PIO

refer to the description below:
Parameter Name: DMA_INTERFACE
Legal Values: 0-3
Default Value: 0
Description:
 0- No DMA Interface
 1- DesignWare DMA Interface
 2- Generic DMA Interface
 3- Non DW DMA Interface
In DesignWare DMA mode, request/acknowledge protocol meets DW_ahb_dmac
controller protocol. In this mode, host data bus is also used for DMA 
transfers.Generic DMA-type interface has simpler request/acknowledge 
handshake and has dedicated read/write data bus for DMA transfers. Non 
DW DMAC interface uses dw_dma_single interface in addition to the 
existing interface and uses host data bus for DMA transfers. This is 
configurable only if INTERNAL_DMAC=0.



   goto no_dma;
   }



+dev_info(host->dev, "Using external DMA controller.\n");
+}

   if (!host->dma_ops)
   goto no_dma;
@@ -2562,12 +2720,12 @@ static void dw_mci_init_dma(struct dw_mci *host)
   goto no_dma;
   }

-host->use_dma = 1;
+host->use_dma = trans_mode;


Also confuse, if trans_mode is assigned host->use_dma, can mode value be directly 
assigned to host->use_dma?



Good idea, I will do it.  :)


trans_mode = TRAMS_MODE_PIO;
host->use_dma = trans_mode;



[...]



@@ 

Re: [PATCH V7 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[Vikas MANOCHA]

Hi,



> On Aug 20, 2015, at 10:20 PM, Marek Vasut  wrote:
> 
>> On Tuesday, August 18, 2015 at 04:34:53 AM, vikas wrote:
>> Hi Marek,
> 
> Hi,
> 
> [...]
> 
>>> +#define CQSPI_POLL_IDLE_RETRY  3
>>> +
>>> +#define CQSPI_REG_SRAM_RESV_WORDS  2
>>> +#define CQSPI_REG_SRAM_PARTITION_WR1
>> 
>> remove unused macros.
>> 
>>> +#define CQSPI_REG_SRAM_THRESHOLD_BYTES 50
>> 
>> the macro is used only for write sram watermark, something like
>> ...WR_THRESH_BYTES would be better. Infact instead of magic number like
>> 50, it should be based on sram_depth similar to read watermark
>> configuration.
> 
> I suppose if the fifo falls below 1/8, that might be a sensible time to
> trigger an underflow interrupt.
> 
>>> +
>>> +/* Instruction type */
>>> +#define CQSPI_INST_TYPE_SINGLE 0
>>> +#define CQSPI_INST_TYPE_DUAL   1
>>> +#define CQSPI_INST_TYPE_QUAD   2
>>> +
>>> +#define CQSPI_DUMMY_CLKS_MAX   31
>>> +
>>> +#define CQSPI_STIG_DATA_LEN_MAX8
>>> +
>>> +/* Register map */
>>> +#define CQSPI_REG_CONFIG   0x00
>>> +#define CQSPI_REG_CONFIG_ENABLE_MASK   BIT(0)
>>> +#define CQSPI_REG_CONFIG_DECODE_MASK   BIT(9)
>>> +#define CQSPI_REG_CONFIG_CHIPSELECT_LSB10
>>> +#define CQSPI_REG_CONFIG_DMA_MASK  BIT(15)
>>> +#define CQSPI_REG_CONFIG_BAUD_LSB  19
>>> +#define CQSPI_REG_CONFIG_IDLE_LSB  31
>> 
>> To be consistent, it would be good to use BIT(nr) for all bit positions.
> 
> You don't use BIT() macro for bitfields and the above are bitfields.
> Thus, this is not applicable.
> 
>>> +#define CQSPI_REG_CONFIG_CHIPSELECT_MASK   0xF
>>> +#define CQSPI_REG_CONFIG_BAUD_MASK 0xF
> 
> [...]
> 
>>> +#define CQSPI_REG_CMDADDRESS   0x94
>>> +#define CQSPI_REG_CMDREADDATALOWER 0xA0
>>> +#define CQSPI_REG_CMDREADDATAUPPER 0xA4
>>> +#define CQSPI_REG_CMDWRITEDATALOWER0xA8
>>> +#define CQSPI_REG_CMDWRITEDATAUPPER0xAC
>> 
>> I am not sure if there is any recommended way but instread of register
>> macros with offset, isn't it better to use something like struct cdns_qspi
>> {
>>u32 config,
>>u32 rd_instn,
>>
>>};
>> & then configuring the pointer to this structure to the peripheral's (qspi
>> controller in this case) base address.
> 
> U-Boot is slowly abolishing this practice as it turned out to be a horrible
> mistake, which is annoying to deal with . No, I will not do this.
> 
>> It helps in debugging also as you can have all registers under one
>> structure, easy/clean access of register like cdsn_qspi_ptr->config
>> instead of adding offset for every access & also clean picture of all
>> peripheral registers.
> 
> Once you have three similar controllers with only one register mapped
> elsewhere, you'd need three such structures. This approach does look
> nice at first, but certainly does not scale.
> 
>>> +
>>> +/* Interrupt status bits */
>>> +#define CQSPI_REG_IRQ_MODE_ERR BIT(0)
>>> +#define CQSPI_REG_IRQ_UNDERFLOW BIT(1)
>>> +#define CQSPI_REG_IRQ_IND_COMP BIT(2)
>>> +#define CQSPI_REG_IRQ_IND_RD_REJECTBIT(3)
>>> +#define CQSPI_REG_IRQ_WR_PROTECTED_ERR BIT(4)
>>> +#define CQSPI_REG_IRQ_ILLEGAL_AHB_ERR  BIT(5)
>>> +#define CQSPI_REG_IRQ_WATERMARKBIT(6)
>>> +#define CQSPI_REG_IRQ_IND_RD_OVERFLOW  BIT(12)
> 
> [...]
> 
>>> +
>>> +static unsigned int cqspi_check_timeout(const unsigned long timeout)
>>> +{
>>> +   return time_before(jiffies, timeout);
>>> +}
>> 
>> try to replace using blocking jiffies check using kernel timeout function.
> 
> What function do you refer to ?
> 
> [...]
> 
>>> +static int cqspi_indirect_read_execute(struct spi_nor *nor,
>>> +  u8 *rxbuf, const unsigned n_rx)
>>> +{
>>> +   struct cqspi_flash_pdata *f_pdata = nor->priv;
>>> +   struct cqspi_st *cqspi = f_pdata->cqspi;
>>> +   void __iomem *reg_base = cqspi->iobase;
>>> +   void __iomem *ahb_base = cqspi->ahb_base;
>>> +   unsigned int remaining = n_rx;
>>> +   unsigned int reg = 0;
>>> +   unsigned int bytes_to_read = 0;
>>> +   unsigned int timeout;
>>> +   int ret = 0;
>>> +
>>> +   writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
>>> +
>>> +   /* Clear all interrupts. */
>>> +   writel(CQSPI_IRQ_STATUS_MASK, reg_base + CQSPI_REG_IRQSTATUS);
>>> +
>>> +   cqspi->irq_mask = CQSPI_IRQ_MASK_RD;
>>> +   writel(cqspi->irq_mask, reg_base + CQSPI_REG_IRQMASK);
>> 
>> here interrupt mask is being configured for every read, better would be to
>> move it in init.
> 
> It certainly would not, it is configured differently for READ and WRITE.

And what is blocking to configure read and write mas

Re: [PATCH V7 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[Vikas MANOCHA]

Hi,



> On Aug 20, 2015, at 10:20 PM, Marek Vasut  wrote:
> 
>> On Thursday, August 20, 2015 at 06:06:49 PM, vikas wrote:
>> Hi,
> 
> Hi!
> 
> [...]
> 
> It's the location of the SRAM fifo.  Also direct mode location I think,
> if that were ever used.
 
 Hmm...It is the base address of NOR flash. SRAM is not memory mapped.
>>> 
>>> Huh ? I am inclined to trust Graham more -- I have seen memory mapped
>>> SRAM, but I have yet to see memory mapped SPI NOR.
>> 
>> Well, SPI NOR flash in SOCs normally is memory mapped.
> 
> I'm afraid you have some very disturbed views of how SPI NORs are operated
> most of the time.

Just wondering what should I say, hoping you will sit back and try to correct 
your views.

> No, SPI NOR is most often hanging off of some sort of SPI
> controller just like any other SPI device. It is definitelly not common for
> a SPI NOR to be memory mapped.

Definitely ? And what made you think like this ? Do you even know the spi 
peripheral you are sending patch for has memory mapped nor flash ?

> 
>> To give some mainline examples, all Spear family SOCs (spear300, 320, 1310,
>> 1340).
> 
> That's an exception, not a rule :)

And there are many such exceptions starting from this cadence qspi :-)

> 
>>> Also, the driver code clearly
>>> uses that area in a way one would use a memory mapped SRAM with FIFO on
>>> the other side. I think the above description is pretty much OK.
>> 
>> that is the purpose of making NOR flash memory mapped.
> 
> I'm not sure if you agree with me or not anymore. I am pretty sure the 
> discussion went quite far for such a trivial matter though.

I definitely disagree with you.
I stop here now.

Cheers,
Vikas

> 
> The size is determined by a configuration parameter during system
> design.  On Altera Cyclone5 the size is really big compared to SRAM
> fifo.  I don't know why, maybe some hw engineer thought it would be
> better to have a large size in case direct mode was used.
 
 my comment is about second parameter of property "reg" which is NOR
 flash address, so above explanation does not make sense for it.
 Also in direct mode, sram does not come into play.
>>> 
>>> This is absolutelly not a SPI NOR address.
>> 
>> Then i can only suggest to check out the controller literature.
>> 
>> Think like this : what is the purpose of SRAM in all this flash access
>> business, It can work without SRAM also, the only purpose of sram (& in
>> fact indirect mode) is to access data from flash memory without AHB access
>> to trigger it. Once the data is available in SRAM(in case of read), AHB
>> Master can access it with low letency. Same is true for writes. SRAM is
>> integral internal part of state machine in case of indirect mode, there is
>> no need for it to memory mapped. If the controller does not support
>> indirect mode, there is no need of sram in the system.
>> 
>> Hope it is little bit more clear.
> 
> It is, I understand what you're trying to convey now.
> 
> Yes, this register area can be used in certain modes of the controller in
> such a way that it presents a window of the SPI NOR, which can be directly
> accessed.
> 
> This register area can also be used as a FIFO, which is the way we used this
> area in the driver . We read/write the first four bytes when communicating
> with the flash.
> 
> So I don't really see a problem with calling the second register a "Controller
> data area", that's what the IP documentation also calls it.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register

[Tony Lindgren]

* Kishon Vijay Abraham I  [150819 23:38]:
> Hi,
> 
> On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote:
> > * Kishon Vijay Abraham I  [150805 07:10]:
> >> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote:
> >>>
> >>> We don't have syscon-otghs and to me it seems we need a PHY driver
> >>> as I pointed out at:
> >>
> >> If *syscon-otghs* is not present, then it'll fall-back to using the 
> >> *ctrl-module*.
> > 
> > OK great.
> > 
> >>>
> >>> https://lkml.org/lkml/2015/6/24/231
> >>
> >> Maybe I should have explained this in the previous thread. The *otghs* 
> >> register
> >> that we are trying to access here does _not_ belong to the PHY. It acts as
> >> mailbox register from MUSB glue (TI integration layer) to MUSB core. 
> >> That's why
> >> it's programmed in the TI glue layer (omap2430.c).
> >>
> >> Even when we were using the older API [omap_control_usb_set_mode()], we 
> >> first
> >> call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c,
> >> phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the
> >> control module instead of PHY drivers directly calling 
> >> omap_control_usb_set_mode().
> > 
> > Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention
> > "transceiver" for quite a few bitfields :) Probably what that register does
> > is control a PHY over ULPI.
> 
> OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too.

So can't we make the phy-omap-usb2.c driver the onlly user of this
register then and get rid of the mailbox stuff? I think the phy
framework can handle everything now?

> > So from Linux kernel point of view we're best off treating it as a PHY.
> > It seems it should have a minimal PHY driver similar to what we have for
> > dm816x control module in drivers/phy/phy-dm816x-usb.c.
> 
> hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and
> should be programmed in omap2430.c. It's better to get the opinion of Felipe
> here. Felipe?
> > 
> > For reference, here is the register bitfields pasted from 4460 TRM:
> > 
> > Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972
> > Physical Address 0x4A00 233C
> > 
> > BIT NAMEDESCIPTION
> > 8   DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ...
> > 7   CHRGVBUS... OTG transceiver does (not) charge VBUS ...
> > 6   IDPULLUP... OTG transceiver does (not) drive VBUS ...
> > 4   IDDIG   ... OTG transceiver does (not) apply a pullup to ID ...
> > 3   SESSEND ... VBUS voltage is above/below VB_SESS_END ... 
> > 2   VBUSVALID   ... VBUS is above the threshold ...
> > 1   BVALID  ... VBUS voltage is above/below VB_SESS_VLD ...
> > 0   AVALID  ... BUS voltage is above/below VA_SESS_VLD ...
> > 
> > So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing
> > drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us
> > to completely get rid of the custom mailbox stuff for MUSB 2430 support?
> 
> Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 
> based
> boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed
> for OMAP3 also.

Hmm I don't think omap3 uses that register? There's no ti,control-phy
anything in the omap3 dts files?  And no USBOTGHS_CONTROL in the TRM?
Or am I missing something here?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html