[PATCH 2/3] ARM: dts: vf610: fix clock definition for SAI2
So far, only the bus clock has been assigned, but in reality the
SAI IP has for clock inputs. The driver has been updated to
make use of the additional clock inputs by c3ecef21c3f2 ("ASoC:
fsl_sai: add sai master mode support"). Due to a bug in the
clock tree, the audio clock has been enabled none the less by
the specified bus clock (see "ARM: imx: clk-vf610: fix SAI
clock tree"), which made master mode even without the proper
clock assigned working.
This patch completes the clock definition for SAI2. On Vybrid,
only two MCLK out of the four options are available (the first
being the bus clock itself). See chapter 8.10.1.2.3 of the
Vybrid Reference manual ("SAI transmitter and receiver options
for MCLK selection"). Note: The audio clocks are only required
in master mode.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vfxxx.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 6865137..c2a4d1c 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -178,8 +178,10 @@
compatible = "fsl,vf610-sai";
reg = <0x40031000 0x1000>;
interrupts = <86 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks VF610_CLK_SAI2>;
- clock-names = "sai";
+ clocks = <&clks VF610_CLK_SAI2>,
+ <&clks VF610_CLK_SAI2_DIV>,
+ <&clks 0>, <&clks 0>;
+ clock-names = "bus", "mclk1", "mclk2", "mclk3";
dma-names = "tx", "rx";
dmas = <&edma0 0 21>,
<&edma0 0 20>;
--
2.6.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
[PATCH 1/3] ARM: imx: clk-vf610: fix SAI clock tree
The Synchronous Audio Interface (SAI) instances are clocked by
independent clocks: The bus clock and the audio clock (as shown in
Figure 51-1 in the Vybrid Reference Manual). The clock gates in
CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access
tests to the registers with/without gating those clocks have shown.
The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1,
followed by a clock divider (SAIx_DIV). Currently, the parent of
the bus clock gates has been assigned to SAIx_DIV, which is not
involved in the bus clock path for the SAI instances (see chapter
9.10.12, SAI clocking in the Vybrid Reference Manual).
Fix this by define the parent clock of VF610_CLK_SAIx to be the bus
clock.
If the driver needs the audio clock (when used in master mode), a
fixed device tree is required which assign the audio clock properly
to VF610_CLK_SAIx_DIV.
Signed-off-by: Stefan Agner
---
Hi all,
Patch 1 and 2 are actual fixes and should be applied toghether. If
the clock tree changes are applied only, master mode won't work
anymore. With only the device tree changes applied, it probably
will still work but the VF610_CLK_SAIx_DIV will be enabled twice.
Since Patch 3 also uses the fixed clock layout, it should be
applied after the clock tree fix too...
Not sure through which tree these changes should go?
--
Stefan
drivers/clk/imx/clk-vf610.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
index bff45ea..42a7a23 100644
--- a/drivers/clk/imx/clk-vf610.c
+++ b/drivers/clk/imx/clk-vf610.c
@@ -335,22 +335,22 @@ static void __init vf610_clocks_init(struct device_node
*ccm_node)
clk[VF610_CLK_SAI0_SEL] = imx_clk_mux("sai0_sel", CCM_CSCMR1, 0, 2,
sai_sels, 4);
clk[VF610_CLK_SAI0_EN] = imx_clk_gate("sai0_en", "sai0_sel",
CCM_CSCDR1, 16);
clk[VF610_CLK_SAI0_DIV] = imx_clk_divider("sai0_div", "sai0_en",
CCM_CSCDR1, 0, 4);
- clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "sai0_div", CCM_CCGR0,
CCM_CCGRx_CGn(15));
+ clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "ipg_bus", CCM_CCGR0,
CCM_CCGRx_CGn(15));
clk[VF610_CLK_SAI1_SEL] = imx_clk_mux("sai1_sel", CCM_CSCMR1, 2, 2,
sai_sels, 4);
clk[VF610_CLK_SAI1_EN] = imx_clk_gate("sai1_en", "sai1_sel",
CCM_CSCDR1, 17);
clk[VF610_CLK_SAI1_DIV] = imx_clk_divider("sai1_div", "sai1_en",
CCM_CSCDR1, 4, 4);
- clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "sai1_div", CCM_CCGR1,
CCM_CCGRx_CGn(0));
+ clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "ipg_bus", CCM_CCGR1,
CCM_CCGRx_CGn(0));
clk[VF610_CLK_SAI2_SEL] = imx_clk_mux("sai2_sel", CCM_CSCMR1, 4, 2,
sai_sels, 4);
clk[VF610_CLK_SAI2_EN] = imx_clk_gate("sai2_en", "sai2_sel",
CCM_CSCDR1, 18);
clk[VF610_CLK_SAI2_DIV] = imx_clk_divider("sai2_div", "sai2_en",
CCM_CSCDR1, 8, 4);
- clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "sai2_div", CCM_CCGR1,
CCM_CCGRx_CGn(1));
+ clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "ipg_bus", CCM_CCGR1,
CCM_CCGRx_CGn(1));
clk[VF610_CLK_SAI3_SEL] = imx_clk_mux("sai3_sel", CCM_CSCMR1, 6, 2,
sai_sels, 4);
clk[VF610_CLK_SAI3_EN] = imx_clk_gate("sai3_en", "sai3_sel",
CCM_CSCDR1, 19);
clk[VF610_CLK_SAI3_DIV] = imx_clk_divider("sai3_div", "sai3_en",
CCM_CSCDR1, 12, 4);
- clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "sai3_div", CCM_CCGR1,
CCM_CCGRx_CGn(2));
+ clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "ipg_bus", CCM_CCGR1,
CCM_CCGRx_CGn(2));
clk[VF610_CLK_NFC_SEL] = imx_clk_mux("nfc_sel", CCM_CSCMR1, 12, 2,
nfc_sels, 4);
clk[VF610_CLK_NFC_EN] = imx_clk_gate("nfc_en", "nfc_sel", CCM_CSCDR2,
9);
--
2.6.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
[PATCH 3/3] ARM: dts: vf610: add remaining SAI instaces
This adds the remaining SAI instances SAI0, SAI1 and SAI3. All
instances are very similar, except that the DMA channel of SAI3
is available on MUX1 (compared to MUX0 for SAI0-SAI2). Also,
SAI3 has a slightly different memory map due to a deeper FIFO,
however in practice the current driver works for SAI3 fine.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vfxxx.dtsi | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index c2a4d1c..b45bc81 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -174,6 +174,34 @@
status = "disabled";
};
+ sai0: sai@4002f000 {
+ compatible = "fsl,vf610-sai";
+ reg = <0x4002f000 0x1000>;
+ interrupts = <84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_SAI0>,
+ <&clks VF610_CLK_SAI0_DIV>,
+ <&clks 0>, <&clks 0>;
+ clock-names = "bus", "mclk1", "mclk2", "mclk3";
+ dma-names = "tx", "rx";
+ dmas = <&edma0 0 17>,
+ <&edma0 0 16>;
+ status = "disabled";
+ };
+
+ sai1: sai@4003 {
+ compatible = "fsl,vf610-sai";
+ reg = <0x4003 0x1000>;
+ interrupts = <85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_SAI1>,
+ <&clks VF610_CLK_SAI1_DIV>,
+ <&clks 0>, <&clks 0>;
+ clock-names = "bus", "mclk1", "mclk2", "mclk3";
+ dma-names = "tx", "rx";
+ dmas = <&edma0 0 19>,
+ <&edma0 0 18>;
+ status = "disabled";
+ };
+
sai2: sai@40031000 {
compatible = "fsl,vf610-sai";
reg = <0x40031000 0x1000>;
@@ -188,6 +216,20 @@
status = "disabled";
};
+ sai3: sai@40032000 {
+ compatible = "fsl,vf610-sai";
+ reg = <0x40032000 0x1000>;
+ interrupts = <87 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_SAI3>,
+ <&clks VF610_CLK_SAI3_DIV>,
+ <&clks 0>, <&clks 0>;
+ clock-names = "bus", "mclk1", "mclk2", "mclk3";
+ dma-names = "tx", "rx";
+ dmas = <&edma0 1 9>,
+ <&edma0 1 8>;
+ status = "disabled";
+ };
+
pit: pit@40037000 {
compatible = "fsl,vf610-pit";
reg = <0x40037000 0x1000>;
--
2.6.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
[PATCH v10 1/3] dt-bindings: Add a binding for Mediatek xHCI host controller
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| 51 ++
1 file changed, 51 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..3c0ac97
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,51 @@
+MT8173 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.0 LPM
+
+Optional properties:
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
+ mode;
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+ control register, it depends on "mediatek,wakeup-src".
+ - vbus-supply : reference to the VBUS regulator;
+
+Example:
+usb30: usb@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>,
+ <0 0x11280700 0 0x0100>;
+ 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>;
+};
--
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 v10 0/3] Mediatek xHCI support
>From 66e467548861c39c52de1d3d899ddc980c6cb925 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Sun, 18 Oct 2015 11:39:45 +0800 Subject: [PATCH v10 0/3] 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. depend on the patch for TDS calculation: https://patchwork.kernel.org/patch/7140041/ Change in v10: 1. simplify clock stability checks 2. put MTK xHCI configuration from xhci_mtk_probe() to xhci_mtk_setup() Change in v9: 1. fix up issue of FS out-iso when use single-TT hub 2. improve RX sensitivity 3. remove udelay(800) called by phy_instance_power_on/off Change in v8: 1. use struct overlay for ippc register 2. change usb wakeup as optional feature 3. add TDS quirk into unified TDS calculation function Change in v7: 1. remove xHCI timing setting which only for FPGA 2. revise xHCI scheduler algorithms 3. replace "usb" by "USB" in xHCI binding file 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 macro Change in v3: 1. implement generic phy 2. move opperations of 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 (3): dt-bindings: Add a binding for Mediatek xHCI host controller xhci: mediatek: support MTK xHCI host controller arm64: dts: mediatek: add xHCI & usb phy for mt8173 .../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++ arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 16 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 42 ++ drivers/usb/host/Kconfig | 9 + drivers/usb/host/Makefile | 4 + drivers/usb/host/xhci-mtk-sch.c| 415 +++ drivers/usb/host/xhci-mtk.c| 765 + drivers/usb/host/xhci-mtk.h| 162 + drivers/usb/host/xhci-ring.c | 16 +- drivers/usb/host/xhci.c| 19 +- drivers/usb/host/xhci.h| 1 + 11 files changed, 1494 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt 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
[PATCH v10 3/3] arm64: dts: mediatek: add xHCI & usb phy for mt8173
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| 42 +
2 files changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 4be66ca..d039a1c 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;
+ };
};
&i2c1 {
@@ -390,3 +400,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 d18ee42..46f5f50 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include "mt8173-pinfunc.h"
@@ -487,6 +488,47 @@
clock-names = "source", "hclk";
status = "disabled";
};
+
+ usb30: usb@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>,
+ <0 0x11280700 0 0x0100>;
+ 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>;
+ 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 v10 2/3] xhci: mediatek: support MTK xHCI host controller
There some vendor quirks for MTK xhci host controller:
1. It 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.
2. Its IMODI unit for Interrupter Moderation register is
8 times as much as that defined in xHCI spec.
3. Its TDS in Normal TRB defines a number of packets that
remains to be transferred for a TD after processing all
Max packets in all previous TRBs.
Signed-off-by: Chunfeng Yun
Tested-by: Daniel Thompson
Reviewed-by: Daniel Thompson
---
drivers/usb/host/Kconfig| 9 +
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-mtk-sch.c | 415 ++
drivers/usb/host/xhci-mtk.c | 765
drivers/usb/host/xhci-mtk.h | 162 +
drivers/usb/host/xhci-ring.c| 16 +-
drivers/usb/host/xhci.c | 19 +-
drivers/usb/host/xhci.h | 1 +
8 files changed, 1385 insertions(+), 6 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 079991e..4674118 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -41,6 +41,15 @@ config USB_XHCI_PLATFORM
If unsure, say N.
+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..c30de7c
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,415 @@
+/*
+ * 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;
+}
+
+/*
+* get the index of bandwidth domains array which @ep belongs to.
+*
+* the bandwidth domain array is saved to @sch_array of struct xhci_hcd_mtk,
+* each HS root port is treated as a single bandwidth domain,
+* but each SS root port is treated as two bandwidth domains, one for IN eps,
+* one for OUT eps.
+* @real_port value is defined as follow according to xHCI spec:
+* 1 for SSport0, ..., N+1 for SSportN, N+2 for HSport0, N+3 for HSport1, etc
+* so the bandwidth domain array is organized as follow for simplification:
+* SSport0-OUT, SSport0-IN, ..., SSportX-OUT, SSportX-IN, HSport0, ..., HSportY
+*/
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+ struct usb_host_endpoint *ep)
+{
+ struct xhci_virt_device *virt_dev;
+ int bw_index;
+
+ virt_dev = xhci->devs[udev->slot_id];
+
+ if (udev->speed == USB_SPEED_SUPER) {
+ if (usb_endpoint_dir_out(&ep->desc))
+
Re: [PATCH 1/2] dt-bindings: drm/msm: Update bindings for MDP5
On Fri, Oct 16, 2015 at 5:06 AM, Archit Taneja wrote: > MDP5 has a different compatible string (which causes checkpatch warnings > when we try to add MDP5 device nodes). It also has different list of > clocks. > > Update the bindings for MDP5. > > Signed-off-by: Archit Taneja > --- > Documentation/devicetree/bindings/drm/msm/mdp.txt | 23 > --- > 1 file changed, 16 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt > b/Documentation/devicetree/bindings/drm/msm/mdp.txt > index 1a0598e..e926daa 100644 > --- a/Documentation/devicetree/bindings/drm/msm/mdp.txt > +++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt > @@ -3,18 +3,27 @@ Qualcomm adreno/snapdragon display controller > Required properties: > - compatible: >* "qcom,mdp" - mdp4 > + * "qcom,mdss_mdp" - mdp5 Wouldn't it be better to name these "qcom,mdp4" and "qcom,mdp5" so that we don't have to rely on some magic detection mechanism to support future versions? Regards, Bjorn -- 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 v9 4/5] xhci: mediatek: support MTK xHCI host controller
Hi,
On Thu, 2015-10-15 at 17:46 +0300, Mathias Nyman wrote:
> On 29.09.2015 06:01, Chunfeng Yun wrote:
> > There some vendor quirks for MTK xhci host controller:
> > 1. It 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.
> > 2. Its IMODI unit for Interrupter Moderation register is
> >8 times as much as that defined in xHCI spec.
> > 3. Its TDS in Normal TRB defines a number of packets that
> >remains to be transferred for a TD after processing all
> >Max packets in all previous TRBs.
> >
> > Signed-off-by: Chunfeng Yun
>
> Looks good in my opinion, There's one part about how we split the ISOC
> transafers
> across multiple microframes that I don't fully understand:
>
> > + } else if (udev->speed == USB_SPEED_SUPER) {
> > + /* usb3_r1 spec section4.4.7 & 4.4.8 */
> > + sch_ep->cs_count = 0;
> > + esit_pkts = (mult + 1) * (max_burst + 1);
>
> So the device would like the transfers to be esit_pkts packets every esit
> microframe apart.
>
> > + if (ep_type == INT_IN_EP || ep_type == INT_OUT_EP) {
> > + sch_ep->pkts = esit_pkts;
> > + sch_ep->num_budget_microframes = 1;
> > + sch_ep->repeat = 0;
> > + }
> > +
> > + if (ep_type == ISOC_IN_EP || ep_type == ISOC_OUT_EP) {
> > + if (esit_pkts <= sch_ep->esit)
> > + sch_ep->pkts = 1;
> > + else
> > + sch_ep->pkts = roundup_pow_of_two(esit_pkts)
> > + / sch_ep->esit;
>
> sch_ep->pkts now contain a rounded up average value of how many packets per
> microframe
> would be transferred in case we'd transfer packets every microframe instead
> of every esit frame apart.
>
> > +
> > + sch_ep->num_budget_microframes =
> > + DIV_ROUND_UP(esit_pkts, sch_ep->pkts);
>
> sch_ep->num_budget_microframes now contains the number of microframes during
> an esit needed
> to transer all data if each microframe contains the average amount of data.
>
> So basically we are trying to use as many microframes as possible with as few
> packets
> per microframe as possible.
>
> Did I understand this correctly?
Yes, you are right.
> How will devices react if they expect to get 16 packets every 16th microframe,
> but they get one packet every microframe instead?
I think that the synchronous endpoint must specify its period by
bInterval, but can't specify how data should be transfered during the
period by the host, and it just only receives data passively. So the
device can receive data correctly in the case(bInterval is 5).
quote from usb3_r1.0 section4.4.8 Isochronous Transfers:
"The host can request data from the device or send data to the device at
any time during the service interval for a particular endpoint on that
device"
>
> Or is this just theoretical bw calculations for the host and it will in the
> end do
> whatever it wants with the information.
The host will schedule synchronous endpoints in a specific
micro-frame/frame according to this parameters provided by software.
Thanks a lot.
>
> Otherwise, by making the changes Daniel Thompson suggested I think the xhci
> parts looks ready.
>
> -Mathias
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > + } else if (is_fs_or_ls(udev->speed)) {
> > +
> > + /*
> > +* usb_20 spec section11.18.4
> > +* assume worst cases
> > +*/
> > + sch_ep->repeat = 0;
> > + sch_ep->pkts = 1; /* at most one packet for each microframe */
> > + if (ep_type == INT_IN_EP || ep_type == INT_OUT_EP) {
> > + sch_ep->cs_count = 3; /* at most need 3 CS*/
> > + /* one for SS and one for budgeted transaction */
> > + sch_ep->num_budget_microframes = sch_ep->cs_count + 2;
> > + sch_ep->bw_cost_per_microframe = max_packet_size;
> > + }
> > + if (ep_type == ISOC_OUT_EP) {
> > +
> > + /*
> > +* the best case FS budget assumes that 188 FS bytes
> > +* occur in each microframe
> > +*/
> > + sch_ep->num_budget_microframes = DIV_ROUND_UP(
> > + max_packet_size, FS_PAYLOAD_MAX);
> > + sch_ep->bw_cost_per_microframe = FS_PAYLOAD_MAX;
> > + sch_ep->cs_count = sch_ep->num_budget_microframes;
> > + }
> > + if (ep_type == ISOC_IN_EP) {
> > + /* at most need additional two CS. */
> > + sch_ep->cs_count = DIV_ROUND_UP(
> > + max_packet_size, FS_PAYLOAD_MAX) + 2;
> > +
Re: [PATCH v4] rtc: pcf8563: add CLKOUT to common clock framework
On 16/10/2015 at 13:31:29 +0200, Heiko Schocher wrote : > Add the clkout output clk to the common clock framework. > Disable the CLKOUT of the RTC after power-up. > After power-up/reset of the RTC, CLKOUT is enabled by default, > with CLKOUT enabled the RTC chip has 2-3 times higher power > consumption. > > Signed-off-by: Heiko Schocher > --- > > Changes in v4: > - add comments from Alexandre Belloni > - use devm_clk_register() instead of clk_register() > - rework Documentation > > Changes in v3: > - use CONFIG_COMMON_CLK for common clk framework > changes > > Changes in v2: > - add comments from Alexandre Belloni > - remove the DT property, instead > register for the CLKOUT a clk in the common > clk framework. The clk is disabled by default. > > Documentation/devicetree/bindings/rtc/pcf8563.txt | 25 > drivers/rtc/rtc-pcf8563.c | 170 > +- > 2 files changed, 194 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/rtc/pcf8563.txt > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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] ARM: dts: sun7i: Enable USB DRC on pcDuino v3 Nano
The OTG arrangement on the LinkSprite pcDuino v3 Nano is the same as the
pcDuino 1/2/3: the OTG port's 5V line is connected directly to the 5V
bus (it's not switchable), and the OTG port's ID pin is connected to PH4
on the A20.
Tested successfully in both host and device modes.
Signed-off-by: Adam Sampson
---
arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
index beac431..1757a6a 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
@@ -142,6 +142,10 @@
status = "okay";
};
+&otg_sram {
+ status = "okay";
+};
+
&pio {
ahci_pwr_pin_pcduino3_nano: ahci_pwr_pin@0 {
allwinner,pins = "PH2";
@@ -157,6 +161,13 @@
allwinner,pull = ;
};
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = "PH4";
+ allwinner,function = "gpio_in";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+
usb1_vbus_pin_pcduino3_nano: usb1_vbus_pin@0 {
allwinner,pins = "PD2";
allwinner,function = "gpio_out";
@@ -211,7 +222,15 @@
status = "okay";
};
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
&usbphy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_id_detect_pin>;
+ usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
usb1_vbus-supply = <®_usb1_vbus>;
usb2_vbus-supply = <®_usb1_vbus>;
status = "okay";
--
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 v3 7/8] arm: dts: lpc32xx: add device nodes for standard timers
NXP LPC32xx SoCs have 6 standard timers, add device nodes to describe
them.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v2 to v3:
- corrected email address in "from" field
Changes from v1 to v2:
- none, new change
arch/arm/boot/dts/lpc32xx.dtsi | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index a595a4b..ba91b20 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -271,11 +271,31 @@
#gpio-cells = <3>; /* bank, pin, flags */
};
+ timer4: timer@4002C000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4002C000 0x1000>;
+ interrupts = <0x3 0>;
+ status = "disabled";
+ };
+
+ timer5: timer@4003 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4003 0x1000>;
+ interrupts = <0x4 0>;
+ status = "disabled";
+ };
+
watchdog: watchdog@4003C000 {
compatible = "nxp,pnx4008-wdt";
reg = <0x4003C000 0x1000>;
};
+ timer0: timer@40044000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x40044000 0x1000>;
+ interrupts = <0x10 0>;
+ };
+
/*
* TSC vs. ADC: Since those two share the same
* hardware, you need to choose from one of the
@@ -297,6 +317,12 @@
status = "disabled";
};
+ timer1: timer@4004C000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4004C000 0x1000>;
+ interrupts = <0x11 0>;
+ };
+
key: key@4005 {
compatible = "nxp,lpc3220-key";
reg = <0x4005 0x1000>;
@@ -304,6 +330,13 @@
status = "disabled";
};
+ timer2: timer@40058000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x40058000 0x1000>;
+ interrupts = <0x12 0>;
+ status = "disabled";
+ };
+
pwm1: pwm@4005C000 {
compatible = "nxp,lpc3220-pwm";
reg = <0x4005C000 0x4>;
@@ -315,6 +348,13 @@
reg = <0x4005C004 0x4>;
status = "disabled";
};
+
+ timer3: timer@4006 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4006 0x1000>;
+ interrupts = <0x13 0>;
+ status = "disabled";
+ };
};
};
};
--
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 v2 8/8] arm: dts: lpc32xx: move USB controller subdevices into own device node
NXP LPC32xx SoC has one USB OTG controller, which is supposed to work
with an external phy (default is NXP ISP1301).
Practically the USB controller contains 5 subdevices:
- host controller 0x3102 -- 0x3102 00FF
- OTG controller0x3102 0100 -- 0x3102 01FF
- device controller 0x3102 0200 -- 0x3102 02FF
- I2C controller0x3102 0300 -- 0x3102 03FF
- clock controller 0x3102 0F00 -- 0x3102 0FFF
The USB controller can be considered as a "bus", because the
subdevices above are relatively independent, for example I2C
controller is the same as other two general purpose I2C controllers
found on SoC.
The change is not intended to modify any logic, but it rearranges
existing device nodes, in future it is planned to add a USB clock
controller device node into the same group.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- none, new change
arch/arm/boot/dts/ea3250.dts | 37 -
arch/arm/boot/dts/lpc32xx.dtsi | 53 --
arch/arm/boot/dts/phy3250.dts | 37 -
3 files changed, 60 insertions(+), 67 deletions(-)
diff --git a/arch/arm/boot/dts/ea3250.dts b/arch/arm/boot/dts/ea3250.dts
index 392430b..a4a281f 100644
--- a/arch/arm/boot/dts/ea3250.dts
+++ b/arch/arm/boot/dts/ea3250.dts
@@ -31,19 +31,6 @@
use-iram;
};
- /* Here, choose exactly one from: ohci, usbd */
- ohci@3102 {
- transceiver = <&isp1301>;
- status = "okay";
- };
-
-/*
- usbd@3102 {
- transceiver = <&isp1301>;
- status = "okay";
- };
-*/
-
/* 128MB Flash via SLC NAND controller */
slc: flash@2002 {
status = "okay";
@@ -130,15 +117,6 @@
clock-frequency = <10>;
};
- i2cusb: i2c@31020300 {
- clock-frequency = <10>;
-
- isp1301: usb-transceiver@2d {
- compatible = "nxp,isp1301";
- reg = <0x2d>;
- };
- };
-
sd@20098000 {
wp-gpios = <&pca9532 5 0>;
cd-gpios = <&pca9532 4 0>;
@@ -279,3 +257,18 @@
};
};
};
+
+/* Here, choose exactly one from: ohci, usbd */
+&ohci /* &usbd */ {
+ transceiver = <&isp1301>;
+ status = "okay";
+};
+
+&i2cusb {
+ clock-frequency = <10>;
+
+ isp1301: usb-transceiver@2d {
+ compatible = "nxp,isp1301";
+ reg = <0x2d>;
+ };
+};
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index ba91b20..c85cf97 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -57,21 +57,37 @@
interrupts = <0x1c 0>;
};
- /*
-* Enable either ohci or usbd (gadget)!
-*/
- ohci: ohci@3102 {
- compatible = "nxp,ohci-nxp", "usb-ohci";
- reg = <0x3102 0x300>;
- interrupts = <0x3b 0>;
- status = "disabled";
- };
+ usb {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0x0 0x3102 0x1000>;
- usbd: usbd@3102 {
- compatible = "nxp,lpc3220-udc";
- reg = <0x3102 0x300>;
- interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
- status = "disabled";
+ /*
+* Enable either ohci or usbd (gadget)!
+*/
+ ohci: ohci@0 {
+ compatible = "nxp,ohci-nxp", "usb-ohci";
+ reg = <0x0 0x300>;
+ interrupts = <0x3b 0>;
+ status = "disabled";
+ };
+
+ usbd: usbd@0 {
+ compatible = "nxp,lpc3220-udc";
+ reg = <0x0 0x300>;
+ interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>,
<0x3a 0>;
+ status = "disabled";
+ };
+
+ i2cusb: i2c@300 {
+ compatible = "nxp,pnx-i2c";
+ reg = <0x300 0x100>;
+ interrupts = <0x3f 0>;
+ #address-cells = <1>;
[PATCH v2 7/8] arm: dts: lpc32xx: add device nodes for standard timers
From: Vladimir Zapolskiy
NXP LPC32xx SoCs have 6 standard timers, add device nodes to describe
them.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- none, new change
arch/arm/boot/dts/lpc32xx.dtsi | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index a595a4b..ba91b20 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -271,11 +271,31 @@
#gpio-cells = <3>; /* bank, pin, flags */
};
+ timer4: timer@4002C000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4002C000 0x1000>;
+ interrupts = <0x3 0>;
+ status = "disabled";
+ };
+
+ timer5: timer@4003 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4003 0x1000>;
+ interrupts = <0x4 0>;
+ status = "disabled";
+ };
+
watchdog: watchdog@4003C000 {
compatible = "nxp,pnx4008-wdt";
reg = <0x4003C000 0x1000>;
};
+ timer0: timer@40044000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x40044000 0x1000>;
+ interrupts = <0x10 0>;
+ };
+
/*
* TSC vs. ADC: Since those two share the same
* hardware, you need to choose from one of the
@@ -297,6 +317,12 @@
status = "disabled";
};
+ timer1: timer@4004C000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4004C000 0x1000>;
+ interrupts = <0x11 0>;
+ };
+
key: key@4005 {
compatible = "nxp,lpc3220-key";
reg = <0x4005 0x1000>;
@@ -304,6 +330,13 @@
status = "disabled";
};
+ timer2: timer@40058000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x40058000 0x1000>;
+ interrupts = <0x12 0>;
+ status = "disabled";
+ };
+
pwm1: pwm@4005C000 {
compatible = "nxp,lpc3220-pwm";
reg = <0x4005C000 0x4>;
@@ -315,6 +348,13 @@
reg = <0x4005C004 0x4>;
status = "disabled";
};
+
+ timer3: timer@4006 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4006 0x1000>;
+ interrupts = <0x13 0>;
+ status = "disabled";
+ };
};
};
};
--
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 v2 0/8] arm: dts: lpc32xx: updates to LPC32xx SoC and boards
The change improves description of NXP LPC32xx hardware, among important changes it adds standard timers and external memory controller nodes, splits PWM device node into two, Changes from v1 to v2: - removed v1 2/5 "arm: dts: lpc32xx: fix improper usage of ranges property" - v1 4/5 "arm: dts: lpc32xx: remove unneeded cell settings from cpus" is replaced by v2 3/8 "arm: dts: lpc32xx: add reg property to cpu device node" - new change, sets physical memory offset for EA3250 and PHY3250 v5/8 - new change, added EMC device node v2 6/8 - new change, added standard timer nodes v2 7/8 - new change, grouped USB subdevices together v2 8/8 Link to the obsolete patch series: - http://www.spinics.net/lists/arm-kernel/msg451745.html Vladimir Zapolskiy (8): arm: dts: lpc32xx: change include syntax to be C preprocessor friendly arm: dts: lpc32xx: add labels to all defined peripheral nodes arm: dts: lpc32xx: add reg property to cpu device node arm: dts: lpc32xx: add device node for the second pwm controller arm: dts: ea3250/phy3250: specify phys memory offset for lpc32xx boards arm: dts: lpc32xx: add external memory controller device node arm: dts: lpc32xx: add device nodes for standard timers arm: dts: lpc32xx: move USB controller subdevices into own device node arch/arm/boot/dts/ea3250.dts | 41 +--- arch/arm/boot/dts/lpc32xx.dtsi | 142 ++--- arch/arm/boot/dts/phy3250.dts | 41 +--- 3 files changed, 139 insertions(+), 85 deletions(-) -- 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 v2 6/8] arm: dts: lpc32xx: add external memory controller device node
The change adds a description of ARM PrimeCell PL175 memory
controller, which is found on NXP LPC32xx SoCs.
The controller supports up to 4 static memory devices mapped to
0xE000 - 0xE3FF physical memory area.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- none, new change
arch/arm/boot/dts/lpc32xx.dtsi | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index be82992..a595a4b 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -32,7 +32,8 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
- ranges = <0x2000 0x2000 0x3000>;
+ ranges = <0x2000 0x2000 0x3000>,
+<0xe000 0xe000 0x0400>;
/*
* Enable either SLC or MLC
@@ -86,6 +87,19 @@
interrupts = <0x1d 0>;
};
+ emc: memory-controller@3108 {
+ compatible = "arm,pl175", "arm,primecell";
+ reg = <0x3108 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0 0xe000 0x0100>,
+<1 0xe100 0x0100>,
+<2 0xe200 0x0100>,
+<3 0xe300 0x0100>;
+ status = "disabled";
+ };
+
apb {
#address-cells = <1>;
#size-cells = <1>;
--
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 v2 5/8] arm: dts: ea3250/phy3250: specify phys memory offset for lpc32xx boards
In case if SDRAM memory region is not populated by a bootloader,
provide this value in device trees for EA3250 and PHY3250 boards.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- none, new change
arch/arm/boot/dts/ea3250.dts | 2 +-
arch/arm/boot/dts/phy3250.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ea3250.dts b/arch/arm/boot/dts/ea3250.dts
index 121d032..392430b 100644
--- a/arch/arm/boot/dts/ea3250.dts
+++ b/arch/arm/boot/dts/ea3250.dts
@@ -22,7 +22,7 @@
memory {
device_type = "memory";
- reg = <0 0x400>;
+ reg = <0x8000 0x400>;
};
ahb {
diff --git a/arch/arm/boot/dts/phy3250.dts b/arch/arm/boot/dts/phy3250.dts
index 2a2d2cf..79a20f7 100644
--- a/arch/arm/boot/dts/phy3250.dts
+++ b/arch/arm/boot/dts/phy3250.dts
@@ -22,7 +22,7 @@
memory {
device_type = "memory";
- reg = <0 0x400>;
+ reg = <0x8000 0x400>;
};
ahb {
--
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 v2 4/8] arm: dts: lpc32xx: add device node for the second pwm controller
LPC32xx SoCs have two independent PWM controllers, they have different
clock parents, clock gates and even slightly different controls,
each of these two PWM controllers has one output channel. Due to
almost similar controls arranged in a row it is incorrectly assumed
that there is one PWM controller with two channels, fix this problem
in lpc32xx.dtsi, which at the moment prevents separate configuration
of different clock parents and gates for both PWM controllers.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- none
arch/arm/boot/dts/lpc32xx.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index fb0e9ae..be82992 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -290,9 +290,15 @@
status = "disabled";
};
- pwm: pwm@4005C000 {
+ pwm1: pwm@4005C000 {
compatible = "nxp,lpc3220-pwm";
- reg = <0x4005C000 0x8>;
+ reg = <0x4005C000 0x4>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@4005C004 {
+ compatible = "nxp,lpc3220-pwm";
+ reg = <0x4005C004 0x4>;
status = "disabled";
};
};
--
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 v2 1/8] arm: dts: lpc32xx: change include syntax to be C preprocessor friendly
The change replaces /include/ to #include in lpc32xx.dtsi and
derivatives, it is required, if C preprocessor is intended to be used
over dtsi/dts files, otherwise errors like one below are generated:
Error: ea3250.dts:15.1-9 syntax error
FATAL ERROR: Unable to parse input tree
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- none
arch/arm/boot/dts/ea3250.dts | 2 +-
arch/arm/boot/dts/lpc32xx.dtsi | 2 +-
arch/arm/boot/dts/phy3250.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/ea3250.dts b/arch/arm/boot/dts/ea3250.dts
index a4ba31b..121d032 100644
--- a/arch/arm/boot/dts/ea3250.dts
+++ b/arch/arm/boot/dts/ea3250.dts
@@ -12,7 +12,7 @@
*/
/dts-v1/;
-/include/ "lpc32xx.dtsi"
+#include "lpc32xx.dtsi"
/ {
model = "Embedded Artists LPC3250 board based on NXP LPC3250";
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 3abebb7..f35e982 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -11,7 +11,7 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
/ {
compatible = "nxp,lpc3220";
diff --git a/arch/arm/boot/dts/phy3250.dts b/arch/arm/boot/dts/phy3250.dts
index 90fdbd7..2a2d2cf 100644
--- a/arch/arm/boot/dts/phy3250.dts
+++ b/arch/arm/boot/dts/phy3250.dts
@@ -12,7 +12,7 @@
*/
/dts-v1/;
-/include/ "lpc32xx.dtsi"
+#include "lpc32xx.dtsi"
/ {
model = "PHYTEC phyCORE-LPC3250 board based on NXP LPC3250";
--
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 v2 2/8] arm: dts: lpc32xx: add labels to all defined peripheral nodes
To simplify writing of dts files for all lpc32xx.dtsi users who adjust
device node properties, add labels to all defined peripheral device
nodes in lpc32xx.dtsi.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- none
arch/arm/boot/dts/lpc32xx.dtsi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index f35e982..00570b3 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -49,7 +49,7 @@
status = "disabled";
};
- dma@3100 {
+ dma: dma@3100 {
compatible = "arm,pl080", "arm,primecell";
reg = <0x3100 0x1000>;
interrupts = <0x1c 0>;
@@ -58,21 +58,21 @@
/*
* Enable either ohci or usbd (gadget)!
*/
- ohci@3102 {
+ ohci: ohci@3102 {
compatible = "nxp,ohci-nxp", "usb-ohci";
reg = <0x3102 0x300>;
interrupts = <0x3b 0>;
status = "disabled";
};
- usbd@3102 {
+ usbd: usbd@3102 {
compatible = "nxp,lpc3220-udc";
reg = <0x3102 0x300>;
interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
status = "disabled";
};
- clcd@3104 {
+ clcd: clcd@3104 {
compatible = "arm,pl110", "arm,primecell";
reg = <0x3104 0x1000>;
interrupts = <0x0e 0>;
@@ -118,7 +118,7 @@
reg = <0x20094000 0x1000>;
};
- sd@20098000 {
+ sd: sd@20098000 {
compatible = "arm,pl18x", "arm,primecell";
reg = <0x20098000 0x1000>;
interrupts = <0x0f 0>, <0x0d 0>;
@@ -243,7 +243,7 @@
status = "disabled";
};
- rtc@40024000 {
+ rtc: rtc@40024000 {
compatible = "nxp,lpc3220-rtc";
reg = <0x40024000 0x1000>;
interrupts = <0x34 0>;
@@ -256,7 +256,7 @@
#gpio-cells = <3>; /* bank, pin, flags */
};
- watchdog@4003C000 {
+ watchdog: watchdog@4003C000 {
compatible = "nxp,pnx4008-wdt";
reg = <0x4003C000 0x1000>;
};
@@ -268,21 +268,21 @@
* them
*/
- adc@40048000 {
+ adc: adc@40048000 {
compatible = "nxp,lpc3220-adc";
reg = <0x40048000 0x1000>;
interrupts = <0x27 0>;
status = "disabled";
};
- tsc@40048000 {
+ tsc: tsc@40048000 {
compatible = "nxp,lpc3220-tsc";
reg = <0x40048000 0x1000>;
interrupts = <0x27 0>;
status = "disabled";
};
- key@4005 {
+ key: key@4005 {
compatible = "nxp,lpc3220-key";
reg = <0x4005 0x1000>;
interrupts = <54 0>;
--
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 v2 3/8] arm: dts: lpc32xx: add reg property to cpu device node
According to device tree bindings for ARM cpus cpu node must contain a
reg property for enumeration scheme.
The change adds reg = <0x0> indicating that the processor does not
have CPU identification register and updates cell settings.
Signed-off-by: Vladimir Zapolskiy
---
Changes from v1 to v2:
- new change, replaced v1 4/5 "arm: dts: lpc32xx: remove unneeded cell settings
from cpus"
arch/arm/boot/dts/lpc32xx.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 00570b3..fb0e9ae 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -18,12 +18,13 @@
interrupt-parent = <&mic>;
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu@0 {
compatible = "arm,arm926ej-s";
device_type = "cpu";
+ reg = <0x0>;
};
};
--
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
Re: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote: > On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman > wrote: > > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote: > >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman > >> wrote: > >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: > >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman > >> >> wrote: > >> >> >> I'm guessing the time is a matter of probing and undoing the probes > >> >> >> rather than slow h/w. We could maybe improve things by making sure > >> >> >> drivers move what they defer on to the beginning of probe, but that > >> >> >> seems like a horrible, fragile hack. > >> >> > > >> >> > How can calling probe and failing cause 2 seconds? How many different > >> >> > probe calls are failing here? Again, a boot log graph would be great > >> >> > to > >> >> > see as it will show the root cause, not just guessing at this. > >> >> > >> >> > >> >> just fwiw, but when you have a driver that depends on several other > >> >> drivers (which in turn depend on other drivers and so on), the amount > >> >> of probe-defer we end up seeing is pretty comical. Yeah, there > >> >> probably is some room to optimize by juggling around order drivers do > >> >> things in probe. But that doesn't solve the fundamental problem with > >> >> the current state, about probe order having no clue about > >> >> dependencies.. > >> > > >> > I can imagine it is a lot of iterations, but how long does it really > >> > take? How many different devices are involved that it takes multiple > >> > loops in order to finally work out the correct order? Where is the time > >> > delays here, just calling probe() and having it instantly return > >> > shouldn't take all that long. > >> > >> offhand, I think the dependencies go at *least* three levels deep.. > >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to > >> get all the way through requesting it's various different > >> regulators/clks/gpios. > > > > And how long does that really take? Numbers please :) > > > >> I hadn't really paid attention to how many > >> tries the drivers I depend on go through. (Of those, I take clks from > >> two different clk drivers (which have dependency on a 3rd clk driver), > >> and regulators and gpio's come from at least two places, which in turn > >> have dependencies on clks, etc.) I don't have really good hard > >> numbers handy (since my observations of this are w/ console over uart > >> which effects timings, and so I see it taking much longer than 2sec).. > >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to > >> me. > >> > >> I can try to get better #'s... I should have my kernel hat on at least > >> some of the time next week.. but the 2sec figure didn't seem > >> unrealistic to me. > > > > Based on the time it takes a modern laptop to boot, 2 seconds is > > forever, there has to be something else going on here other than just > > calling probe() a bunch of times. Please use the tools we have to > > determine this before trying to change the driver core. > > yes, I am aware of the tools.. although so far I spend most of my time > just trying to get things working in the first place ;-) And that's where most people stop, if you want to make it fast, you have to put in more effort, sorry. Don't expect the driver core to work around driver bugs for you. > All I was trying to point out was that Tomeu's figures didn't really > seem unrealistic. I mean, given that the average SoC driver probably > depends on at least one clock and at least one regulator, having to > probe each driver at least twice seems plausible. And that having a > noticeable effect on boot time doesn't seem surprising. I'm not sure > that saying 'modern laptop can boot in 2sec' adds much to the > discussion since I don't think you have quite so much interdependency > between devices vs random probe order. I have seen arm devices boot > to UI in similar times, but that was pre-devicetree days. 2 extra probes add a second to the boot time? Those sound like really broken drivers to me :) thanks, greg k-h -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes wrote: > > Den 17.10.2015 20:45, skrev Rob Clark: >> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman >> wrote: >>> >>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman wrote: >> >> I'm guessing the time is a matter of probing and undoing the probes >> rather than slow h/w. We could maybe improve things by making sure >> drivers move what they defer on to the beginning of probe, but that >> seems like a horrible, fragile hack. > > How can calling probe and failing cause 2 seconds? How many different > probe calls are failing here? Again, a boot log graph would be great > to > see as it will show the root cause, not just guessing at this. just fwiw, but when you have a driver that depends on several other drivers (which in turn depend on other drivers and so on), the amount of probe-defer we end up seeing is pretty comical. Yeah, there probably is some room to optimize by juggling around order drivers do things in probe. But that doesn't solve the fundamental problem with the current state, about probe order having no clue about dependencies.. >>> >>> I can imagine it is a lot of iterations, but how long does it really >>> take? How many different devices are involved that it takes multiple >>> loops in order to finally work out the correct order? Where is the time >>> delays here, just calling probe() and having it instantly return >>> shouldn't take all that long. >> >> offhand, I think the dependencies go at *least* three levels deep.. >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to >> get all the way through requesting it's various different >> regulators/clks/gpios. I hadn't really paid attention to how many >> tries the drivers I depend on go through. (Of those, I take clks from >> two different clk drivers (which have dependency on a 3rd clk driver), >> and regulators and gpio's come from at least two places, which in turn >> have dependencies on clks, etc.) I don't have really good hard >> numbers handy (since my observations of this are w/ console over uart >> which effects timings, and so I see it taking much longer than 2sec).. >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to >> me. >> >> I can try to get better #'s... I should have my kernel hat on at least >> some of the time next week.. but the 2sec figure didn't seem >> unrealistic to me. > > > Are you saying that the total boot time is increased by 2 sec due to > deferred probing, or that display initialization is happening 2 sec > after it's first try? > The 2sec figure was from Tomeu, but I guess display should be probed in first pass through list of devices (and ofc deferring the first time), I'll say "probably both".. BR, -R -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman wrote: > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote: >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman >> wrote: >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman >> >> wrote: >> >> >> I'm guessing the time is a matter of probing and undoing the probes >> >> >> rather than slow h/w. We could maybe improve things by making sure >> >> >> drivers move what they defer on to the beginning of probe, but that >> >> >> seems like a horrible, fragile hack. >> >> > >> >> > How can calling probe and failing cause 2 seconds? How many different >> >> > probe calls are failing here? Again, a boot log graph would be great to >> >> > see as it will show the root cause, not just guessing at this. >> >> >> >> >> >> just fwiw, but when you have a driver that depends on several other >> >> drivers (which in turn depend on other drivers and so on), the amount >> >> of probe-defer we end up seeing is pretty comical. Yeah, there >> >> probably is some room to optimize by juggling around order drivers do >> >> things in probe. But that doesn't solve the fundamental problem with >> >> the current state, about probe order having no clue about >> >> dependencies.. >> > >> > I can imagine it is a lot of iterations, but how long does it really >> > take? How many different devices are involved that it takes multiple >> > loops in order to finally work out the correct order? Where is the time >> > delays here, just calling probe() and having it instantly return >> > shouldn't take all that long. >> >> offhand, I think the dependencies go at *least* three levels deep.. >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to >> get all the way through requesting it's various different >> regulators/clks/gpios. > > And how long does that really take? Numbers please :) > >> I hadn't really paid attention to how many >> tries the drivers I depend on go through. (Of those, I take clks from >> two different clk drivers (which have dependency on a 3rd clk driver), >> and regulators and gpio's come from at least two places, which in turn >> have dependencies on clks, etc.) I don't have really good hard >> numbers handy (since my observations of this are w/ console over uart >> which effects timings, and so I see it taking much longer than 2sec).. >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to >> me. >> >> I can try to get better #'s... I should have my kernel hat on at least >> some of the time next week.. but the 2sec figure didn't seem >> unrealistic to me. > > Based on the time it takes a modern laptop to boot, 2 seconds is > forever, there has to be something else going on here other than just > calling probe() a bunch of times. Please use the tools we have to > determine this before trying to change the driver core. yes, I am aware of the tools.. although so far I spend most of my time just trying to get things working in the first place ;-) All I was trying to point out was that Tomeu's figures didn't really seem unrealistic. I mean, given that the average SoC driver probably depends on at least one clock and at least one regulator, having to probe each driver at least twice seems plausible. And that having a noticeable effect on boot time doesn't seem surprising. I'm not sure that saying 'modern laptop can boot in 2sec' adds much to the discussion since I don't think you have quite so much interdependency between devices vs random probe order. I have seen arm devices boot to UI in similar times, but that was pre-devicetree days. I expect Tomeu has some better number.. if not I can collect some. >> Just as an aside, the amount of probe-defer adds quite a lot of noise >> when you are trying to debug why some driver doesn't probe >> successfully. Which itself would be a nice reason to do something >> more clever.. > > People seem to not like the noise, so let's turn off those messages, > that should speed things up :) heh, except for when you are trying to debug what is missing preventing the driver you depend on from probing ;-) BR, -R -- 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: [GIT PULL] On-demand device probing
Den 17.10.2015 20:45, skrev Rob Clark: On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman wrote: On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman wrote: I'm guessing the time is a matter of probing and undoing the probes rather than slow h/w. We could maybe improve things by making sure drivers move what they defer on to the beginning of probe, but that seems like a horrible, fragile hack. How can calling probe and failing cause 2 seconds? How many different probe calls are failing here? Again, a boot log graph would be great to see as it will show the root cause, not just guessing at this. just fwiw, but when you have a driver that depends on several other drivers (which in turn depend on other drivers and so on), the amount of probe-defer we end up seeing is pretty comical. Yeah, there probably is some room to optimize by juggling around order drivers do things in probe. But that doesn't solve the fundamental problem with the current state, about probe order having no clue about dependencies.. I can imagine it is a lot of iterations, but how long does it really take? How many different devices are involved that it takes multiple loops in order to finally work out the correct order? Where is the time delays here, just calling probe() and having it instantly return shouldn't take all that long. offhand, I think the dependencies go at *least* three levels deep.. I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to get all the way through requesting it's various different regulators/clks/gpios. I hadn't really paid attention to how many tries the drivers I depend on go through. (Of those, I take clks from two different clk drivers (which have dependency on a 3rd clk driver), and regulators and gpio's come from at least two places, which in turn have dependencies on clks, etc.) I don't have really good hard numbers handy (since my observations of this are w/ console over uart which effects timings, and so I see it taking much longer than 2sec).. but the 2sec figure that Tomeu mentioned seemed pretty plausible to me. I can try to get better #'s... I should have my kernel hat on at least some of the time next week.. but the 2sec figure didn't seem unrealistic to me. Are you saying that the total boot time is increased by 2 sec due to deferred probing, or that display initialization is happening 2 sec after it's first try? -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote: > On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman > wrote: > > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: > >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman > >> wrote: > >> >> I'm guessing the time is a matter of probing and undoing the probes > >> >> rather than slow h/w. We could maybe improve things by making sure > >> >> drivers move what they defer on to the beginning of probe, but that > >> >> seems like a horrible, fragile hack. > >> > > >> > How can calling probe and failing cause 2 seconds? How many different > >> > probe calls are failing here? Again, a boot log graph would be great to > >> > see as it will show the root cause, not just guessing at this. > >> > >> > >> just fwiw, but when you have a driver that depends on several other > >> drivers (which in turn depend on other drivers and so on), the amount > >> of probe-defer we end up seeing is pretty comical. Yeah, there > >> probably is some room to optimize by juggling around order drivers do > >> things in probe. But that doesn't solve the fundamental problem with > >> the current state, about probe order having no clue about > >> dependencies.. > > > > I can imagine it is a lot of iterations, but how long does it really > > take? How many different devices are involved that it takes multiple > > loops in order to finally work out the correct order? Where is the time > > delays here, just calling probe() and having it instantly return > > shouldn't take all that long. > > offhand, I think the dependencies go at *least* three levels deep.. > I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to > get all the way through requesting it's various different > regulators/clks/gpios. And how long does that really take? Numbers please :) > I hadn't really paid attention to how many > tries the drivers I depend on go through. (Of those, I take clks from > two different clk drivers (which have dependency on a 3rd clk driver), > and regulators and gpio's come from at least two places, which in turn > have dependencies on clks, etc.) I don't have really good hard > numbers handy (since my observations of this are w/ console over uart > which effects timings, and so I see it taking much longer than 2sec).. > but the 2sec figure that Tomeu mentioned seemed pretty plausible to > me. > > I can try to get better #'s... I should have my kernel hat on at least > some of the time next week.. but the 2sec figure didn't seem > unrealistic to me. Based on the time it takes a modern laptop to boot, 2 seconds is forever, there has to be something else going on here other than just calling probe() a bunch of times. Please use the tools we have to determine this before trying to change the driver core. > Just as an aside, the amount of probe-defer adds quite a lot of noise > when you are trying to debug why some driver doesn't probe > successfully. Which itself would be a nice reason to do something > more clever.. People seem to not like the noise, so let's turn off those messages, that should speed things up :) thanks, greg k-h -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman wrote: > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman >> wrote: >> >> I'm guessing the time is a matter of probing and undoing the probes >> >> rather than slow h/w. We could maybe improve things by making sure >> >> drivers move what they defer on to the beginning of probe, but that >> >> seems like a horrible, fragile hack. >> > >> > How can calling probe and failing cause 2 seconds? How many different >> > probe calls are failing here? Again, a boot log graph would be great to >> > see as it will show the root cause, not just guessing at this. >> >> >> just fwiw, but when you have a driver that depends on several other >> drivers (which in turn depend on other drivers and so on), the amount >> of probe-defer we end up seeing is pretty comical. Yeah, there >> probably is some room to optimize by juggling around order drivers do >> things in probe. But that doesn't solve the fundamental problem with >> the current state, about probe order having no clue about >> dependencies.. > > I can imagine it is a lot of iterations, but how long does it really > take? How many different devices are involved that it takes multiple > loops in order to finally work out the correct order? Where is the time > delays here, just calling probe() and having it instantly return > shouldn't take all that long. offhand, I think the dependencies go at *least* three levels deep.. I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to get all the way through requesting it's various different regulators/clks/gpios. I hadn't really paid attention to how many tries the drivers I depend on go through. (Of those, I take clks from two different clk drivers (which have dependency on a 3rd clk driver), and regulators and gpio's come from at least two places, which in turn have dependencies on clks, etc.) I don't have really good hard numbers handy (since my observations of this are w/ console over uart which effects timings, and so I see it taking much longer than 2sec).. but the 2sec figure that Tomeu mentioned seemed pretty plausible to me. I can try to get better #'s... I should have my kernel hat on at least some of the time next week.. but the 2sec figure didn't seem unrealistic to me. Just as an aside, the amount of probe-defer adds quite a lot of noise when you are trying to debug why some driver doesn't probe successfully. Which itself would be a nice reason to do something more clever.. BR, -R > thanks, > > greg k-h -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: > On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman > wrote: > >> I'm guessing the time is a matter of probing and undoing the probes > >> rather than slow h/w. We could maybe improve things by making sure > >> drivers move what they defer on to the beginning of probe, but that > >> seems like a horrible, fragile hack. > > > > How can calling probe and failing cause 2 seconds? How many different > > probe calls are failing here? Again, a boot log graph would be great to > > see as it will show the root cause, not just guessing at this. > > > just fwiw, but when you have a driver that depends on several other > drivers (which in turn depend on other drivers and so on), the amount > of probe-defer we end up seeing is pretty comical. Yeah, there > probably is some room to optimize by juggling around order drivers do > things in probe. But that doesn't solve the fundamental problem with > the current state, about probe order having no clue about > dependencies.. I can imagine it is a lot of iterations, but how long does it really take? How many different devices are involved that it takes multiple loops in order to finally work out the correct order? Where is the time delays here, just calling probe() and having it instantly return shouldn't take all that long. thanks, greg k-h -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman wrote: >> I'm guessing the time is a matter of probing and undoing the probes >> rather than slow h/w. We could maybe improve things by making sure >> drivers move what they defer on to the beginning of probe, but that >> seems like a horrible, fragile hack. > > How can calling probe and failing cause 2 seconds? How many different > probe calls are failing here? Again, a boot log graph would be great to > see as it will show the root cause, not just guessing at this. just fwiw, but when you have a driver that depends on several other drivers (which in turn depend on other drivers and so on), the amount of probe-defer we end up seeing is pretty comical. Yeah, there probably is some room to optimize by juggling around order drivers do things in probe. But that doesn't solve the fundamental problem with the current state, about probe order having no clue about dependencies.. BR, -R -- 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/9] ARM: Kconfig: Introduce MACH_STM32F429 flag
This patch introduces the MACH_STM32F429 to make possible to only select STM32F429 pinctrl driver. By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig. Signed-off-by: Maxime Coquelin --- arch/arm/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 72ad724..bf94e54 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -988,6 +988,11 @@ config ARCH_STM32 help Support for STMicroelectronics STM32 processors. +config MACH_STM32F429 + bool "STMicrolectronics STM32F429" + depends on ARCH_STM32 + default y + # Definitions to make life easier config ARCH_ACORN bool -- 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
[PATCH v2 7/9] ARM: dts: Add USART1 pin config to STM32F429 boards
This patch selects USART1 pin configuration on PA9/PA10 pins
for both Eval and Disco boards.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stm32429i-eval.dts | 2 ++
arch/arm/boot/dts/stm32f429-disco.dts | 2 ++
arch/arm/boot/dts/stm32f429.dtsi | 13 +
3 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 6964fc9..71fe17a 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -71,5 +71,7 @@
};
&usart1 {
+ pinctrl-0 = <&usart1_pins_a>;
+ pinctrl-names = "default";
status = "okay";
};
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
b/arch/arm/boot/dts/stm32f429-disco.dts
index f0b731d..e3ce796 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -71,5 +71,7 @@
};
&usart1 {
+ pinctrl-0 = <&usart1_pins_a>;
+ pinctrl-names = "default";
status = "okay";
};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 9e6e75c..eb3580e 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -263,6 +263,19 @@
clocks = <&rcc 0 266>;
st,bank-name = "GPIOK";
};
+
+ usart1_pins_a: usart1@0 {
+ pins1 {
+ pinmux = ;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux =
;
+ bias-disable;
+ };
+ };
};
rcc: rcc@40023810 {
--
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
[PATCH v2 5/9] ARM: mach-stm32: Select pinctrl
Signed-off-by: Maxime Coquelin --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index bf94e54..8a764ba 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -984,6 +984,7 @@ config ARCH_STM32 select ARCH_HAS_RESET_CONTROLLER select ARMV7M_SYSTICK select CLKSRC_STM32 + select PINCTRL select RESET_CONTROLLER help Support for STMicroelectronics STM32 processors. -- 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
[PATCH v2 2/9] Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings
Signed-off-by: Maxime Coquelin
---
.../bindings/pinctrl/st,stm32-pinctrl.txt | 126 +
1 file changed, 126 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
new file mode 100644
index 000..7b4800c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
@@ -0,0 +1,126 @@
+* STM32 GPIO and Pin Mux/Config controller
+
+STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware
+controller. It controls the input/output settings on the available pins and
+also provides ability to multiplex and configure the output of various on-chip
+controllers onto these pads.
+
+Pin controller node:
+Required properies:
+ - compatible: value should be one of the following:
+ (a) "st,stm32f429-pinctrl"
+ - #address-cells: The value of this property must be 1
+ - #size-cells : The value of this property must be 1
+ - ranges : defines mapping between pin controller node (parent) to
+ gpio-bank node (children).
+ - pins-are-numbered: Specify the subnodes are using numbered pinmux to
+ specify pins.
+
+GPIO controller/bank node:
+Required properties:
+ - gpio-controller : Indicates this device is a GPIO controller
+ - #gpio-cells : Should be two.
+ The first cell is the pin number
+ The second one is the polarity:
+ - 0 for active high
+ - 1 for active low
+ - reg : The gpio address range, relative to the pinctrl range
+ - clocks: clock that drives this bank
+ - st,bank-name : Should be a name string for this bank as specified
in
+ the datasheet
+
+Optional properties:
+ - reset:: Reference to the reset controller
+
+Example:
+#include
+...
+
+ pin-controller {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,stm32f429-pinctrl";
+ ranges = <0 0x4002 0x3000>;
+ pins-are-numbered;
+
+ gpioa: gpio@4002 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x0 0x400>;
+ resets = <&reset_ahb1 0>;
+ st,bank-name = "GPIOA";
+ };
+ ...
+ pin-functions nodes follow...
+ };
+
+Contents of function subnode node:
+--
+Subnode format
+A pinctrl node should contain at least one subnode representing the
+pinctrl group available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, pullups, drive, output high/low and output speed.
+
+node {
+ pinmux = ;
+ GENERIC_PINCONFIG;
+};
+
+Required properties:
+- pinmux: integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are defined in
+ dt-bindings/pinctrl/-pinfunc.h directly.
+ These defines are calculated as:
+((port * 16 + line) << 8) | function
+ With:
+- port: The gpio port index (PA = 0, PB = 1, ..., PK = 11)
+- line: The line offset within the port (PA0 = 0, PA1 = 1, ..., PA15 = 15)
+- function: The function number, can be:
+ * 0 : GPIO
+ * 1 : Alternate Function 0
+ * 2 : Alternate Function 1
+ * 3 : Alternate Function 2
+ * ...
+ * 16 : Alternate Function 15
+ * 17 : Analog
+
+Optional properties:
+- GENERIC_PINCONFIG: is the generic pinconfig options to use.
+ Available options are:
+ - bias-disable,
+ - bias-pull-down,
+ - bias-pull-up,
+ - drive-push-pull,
+ - drive-open-drain,
+ - output-low
+ - output-high
+ - slew-rate = , with x being:
+ < 0 > : Low speed
+ < 1 > : Medium speed
+ < 2 > : Fast speed
+ < 3 > : High speed
+
+Example:
+
+pin-controller {
+...
+ usart1_pins_a: usart1@0 {
+ pins1 {
+ pinmux = ;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = ;
+ bias-disable;
+ };
+ };
+};
+
+&usart1 {
+ pinctrl-0 = <&usart1_pins_a>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
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
[PATCH v2 6/9] ARM: dts: Add pinctrl node to STM32F429
The STM32F429 MCU has 11 GPIO banks, with 16 pins per bank.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stm32f429.dtsi | 97
1 file changed, 97 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index d78a481..9e6e75c 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -46,6 +46,7 @@
*/
#include "armv7-m.dtsi"
+#include
/ {
clocks {
@@ -168,6 +169,102 @@
status = "disabled";
};
+ pin-controller {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,stm32f429-pinctrl";
+ ranges = <0 0x4002 0x3000>;
+ pins-are-numbered;
+
+ gpioa: gpio@4002 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x0 0x400>;
+ clocks = <&rcc 0 256>;
+ st,bank-name = "GPIOA";
+ };
+
+ gpiob: gpio@40020400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x400 0x400>;
+ clocks = <&rcc 0 257>;
+ st,bank-name = "GPIOB";
+ };
+
+ gpioc: gpio@40020800 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x800 0x400>;
+ clocks = <&rcc 0 258>;
+ st,bank-name = "GPIOC";
+ };
+
+ gpiod: gpio@40020c00 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0xc00 0x400>;
+ clocks = <&rcc 0 259>;
+ st,bank-name = "GPIOD";
+ };
+
+ gpioe: gpio@40021000 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x1000 0x400>;
+ clocks = <&rcc 0 260>;
+ st,bank-name = "GPIOE";
+ };
+
+ gpiof: gpio@40021400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x1400 0x400>;
+ clocks = <&rcc 0 261>;
+ st,bank-name = "GPIOF";
+ };
+
+ gpiog: gpio@40021800 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x1800 0x400>;
+ clocks = <&rcc 0 262>;
+ st,bank-name = "GPIOG";
+ };
+
+ gpioh: gpio@40021c00 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x1c00 0x400>;
+ clocks = <&rcc 0 263>;
+ st,bank-name = "GPIOH";
+ };
+
+ gpioi: gpio@40022000 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x2000 0x400>;
+ clocks = <&rcc 0 264>;
+ st,bank-name = "GPIOI";
+ };
+
+ gpioj: gpio@40022400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x2400 0x400>;
+ clocks = <&rcc 0 265>;
+ st,bank-name = "GPIOJ";
+ };
+
+ gpiok: gpio@40022800 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x2800 0x400>;
+ clocks = <&rcc 0 266>;
+ st,bank-name = "GPIOK";
+ };
+ };
+
rcc: rcc@40023810 {
#clock-cells = <2>;
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
--
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
[PATCH v2 4/9] pinctrl: Add support STM32 MCUs
This patch adds pinctrl and GPIO support to STMicroelectronic's STM32
family of MCUs.
While it only supports STM32F429 for now, it has been designed to enable
support of other MCUs of the family (e.g. STM32F746).
Signed-off-by: Maxime Coquelin
---
drivers/pinctrl/Kconfig |1 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/stm32/Kconfig | 16 +
drivers/pinctrl/stm32/Makefile|5 +
drivers/pinctrl/stm32/pinctrl-stm32.c | 856 +++
drivers/pinctrl/stm32/pinctrl-stm32.h | 43 +
drivers/pinctrl/stm32/pinctrl-stm32f429.c | 1598 +
7 files changed, 2520 insertions(+)
create mode 100644 drivers/pinctrl/stm32/Kconfig
create mode 100644 drivers/pinctrl/stm32/Makefile
create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c
create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h
create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 84dd2ed..5749cc4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -249,6 +249,7 @@ source "drivers/pinctrl/sunxi/Kconfig"
source "drivers/pinctrl/uniphier/Kconfig"
source "drivers/pinctrl/vt8500/Kconfig"
source "drivers/pinctrl/mediatek/Kconfig"
+source "drivers/pinctrl/stm32/Kconfig"
config PINCTRL_XWAY
bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index cad077c..1fffcda 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-$(CONFIG_ARCH_UNIPHIER)+= uniphier/
obj-$(CONFIG_ARCH_VT8500) += vt8500/
obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
+obj-$(CONFIG_ARCH_STM32) += stm32/
diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
new file mode 100644
index 000..0f28841
--- /dev/null
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -0,0 +1,16 @@
+if ARCH_STM32 || COMPILE_TEST
+
+config PINCTRL_STM32
+ bool
+ depends on OF
+ select PINMUX
+ select GENERIC_PINCONF
+ select GPIOLIB
+
+config PINCTRL_STM32F429
+ bool "STMicroelectronics STM32F429 pin control" if COMPILE_TEST &&
!MACH_STM32F429
+ depends on OF
+ default MACH_STM32F429
+ select PINCTRL_STM32
+
+endif
diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
new file mode 100644
index 000..fc17d42
--- /dev/null
+++ b/drivers/pinctrl/stm32/Makefile
@@ -0,0 +1,5 @@
+# Core
+obj-$(CONFIG_PINCTRL_STM32) += pinctrl-stm32.o
+
+# SoC Drivers
+obj-$(CONFIG_PINCTRL_STM32F429)+= pinctrl-stm32f429.o
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c
b/drivers/pinctrl/stm32/pinctrl-stm32.c
new file mode 100644
index 000..4ebceaa
--- /dev/null
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -0,0 +1,856 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Heavily based on Mediatek's pinctrl driver
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "../core.h"
+#include "../pinconf.h"
+#include "../pinctrl-utils.h"
+#include "pinctrl-stm32.h"
+
+#define STM32_GPIO_MODER 0x00
+#define STM32_GPIO_TYPER 0x04
+#define STM32_GPIO_SPEEDR 0x08
+#define STM32_GPIO_PUPDR 0x0c
+#define STM32_GPIO_IDR 0x10
+#define STM32_GPIO_ODR 0x14
+#define STM32_GPIO_BSRR0x18
+#define STM32_GPIO_LCKR0x1c
+#define STM32_GPIO_AFRL0x20
+#define STM32_GPIO_AFRH0x24
+
+#define STM32_GPIO_PINS_PER_BANK 16
+
+#define gpio_range_to_bank(chip) \
+ container_of(chip, struct stm32_gpio_bank, range)
+
+#define gpio_chip_to_bank(chip) \
+ container_of(chip, struct stm32_gpio_bank, gpio_chip)
+
+static const char * const stm32_gpio_functions[] = {
+ "gpio", "af0", "af1",
+ "af2", "af3", "af4",
+ "af5", "af6", "af7",
+ "af8", "af9", "af10",
+ "af11", "af12", "af13",
+ "af14", "af15", "analog",
+};
+
+struct stm32_pinctrl_group {
+ const char *name;
+ unsigned long config;
+ unsigned pin;
+};
+
+struct stm32_gpio_bank {
+ void __iomem *base;
+ struct clk *clk;
+ spinlock_t lock;
+ struct gpio_chip gpio_chip;
+ struct pinctrl_gpio_range range;
+};
+
+struct stm32_pinctrl {
+ struct device *dev;
+ struct pinctrl_dev *pctl_dev;
+ struct pinctrl_desc pctl_desc;
+ struct stm32_pinctrl_group *groups;
+ unsigned ngroups;
+ const char **grp_names;
+ struct stm32_gpio_bank *banks;
+ unsigned nbanks;
+ const struct stm32_pinctrl_match_data *match_data;
+};
+
+static inline int stm32_gpio_pin(int gpio)
+{
+ retu
[PATCH v6 0/2] ARM: sunxi: Add Reduced Serial Bus (RSB) controller support
Hi everyone,
This is v6 of the Allwinner Reduced Serial Bus driver. This version puts
the driver under drivers/bus instead of drivers/soc/sunxi. There are no
changes to the binding or the driver itself.
The series is based on v4.3-rc1.
Changes since v5:
.../bindings/{soc/sunxi/rsb.txt => bus/sunxi-rsb.txt} | 0
drivers/bus/Kconfig | 11 +++
drivers/bus/Makefile | 1 +
drivers/{soc/sunxi/sunxi_rsb.c => bus/sunxi-rsb.c}| 2 +-
drivers/soc/sunxi/Kconfig | 10 --
drivers/soc/sunxi/Makefile| 1 -
include/linux/{soc/sunxi/sunxi_rsb.h => sunxi-rsb.h} | 0
7 files changed, 13 insertions(+), 12 deletions(-)
The Kconfig entry has been updated with a proper entry description, making
it selectable. Both the entry and help text have been edited to make it
clear this is an Allwinner specific driver. A dependency on ARCH_SUNXI is
also added.
Regards
ChenYu
Chen-Yu Tsai (2):
bus: sunxi-rsb: Add Allwinner Reduced Serial Bus (RSB) controller
bindings
bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus
.../devicetree/bindings/bus/sunxi-rsb.txt | 47 ++
drivers/bus/Kconfig| 11 +
drivers/bus/Makefile | 1 +
drivers/bus/sunxi-rsb.c| 783 +
include/linux/sunxi-rsb.h | 105 +++
5 files changed, 947 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/sunxi-rsb.txt
create mode 100644 drivers/bus/sunxi-rsb.c
create mode 100644 include/linux/sunxi-rsb.h
--
2.6.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
[PATCH v6 2/2] bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus
Reduced Serial Bus (RSB) is an Allwinner proprietery interface used to communicate with PMICs and other peripheral ICs. RSB is a two-wire push-pull serial bus that supports 1 master device and up to 15 active slave devices. Signed-off-by: Chen-Yu Tsai Reviewed-by: Mark Brown Signed-off-by: Maxime Ripard --- drivers/bus/Kconfig | 11 + drivers/bus/Makefile | 1 + drivers/bus/sunxi-rsb.c | 783 ++ include/linux/sunxi-rsb.h | 105 +++ 4 files changed, 900 insertions(+) create mode 100644 drivers/bus/sunxi-rsb.c create mode 100644 include/linux/sunxi-rsb.h diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 1a82f3a17681..e921b8c72f8c 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -121,6 +121,17 @@ config SIMPLE_PM_BUS Controller (BSC, sometimes called "LBSC within Bus Bridge", or "External Bus Interface") as found on several Renesas ARM SoCs. +config SUNXI_RSB + bool "Allwinner sunXi Reduced Serial Bus Driver" + default MACH_SUN8I || MACH_SUN9I + depends on ARCH_SUNXI + select REGMAP + help + Say y here to enable support for Allwinner's Reduced Serial Bus + (RSB) support. This controller is responsible for communicating + with various RSB based devices, such as AXP223, AXP8XX PMICs, + and AC100/AC200 ICs. + config VEXPRESS_CONFIG bool "Versatile Express configuration bus" default y if ARCH_VEXPRESS diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 790e7b933fb2..fcb9f9794a1f 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -15,5 +15,6 @@ obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o obj-$(CONFIG_OMAP_INTERCONNECT)+= omap_l3_smx.o omap_l3_noc.o obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o +obj-$(CONFIG_SUNXI_RSB)+= sunxi-rsb.o obj-$(CONFIG_SIMPLE_PM_BUS)+= simple-pm-bus.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c new file mode 100644 index ..846bc29c157d --- /dev/null +++ b/drivers/bus/sunxi-rsb.c @@ -0,0 +1,783 @@ +/* + * RSB (Reduced Serial Bus) driver. + * + * Author: Chen-Yu Tsai + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + * + * The RSB controller looks like an SMBus controller which only supports + * byte and word data transfers. But, it differs from standard SMBus + * protocol on several aspects: + * - it uses addresses set at runtime to address slaves. Runtime addresses + * are sent to slaves using their 12bit hardware addresses. Up to 15 + * runtime addresses are available. + * - it adds a parity bit every 8bits of data and address for read and + * write accesses; this replaces the ack bit + * - only one read access is required to read a byte (instead of a write + * followed by a read access in standard SMBus protocol) + * - there's no Ack bit after each read access + * + * This means this bus cannot be used to interface with standard SMBus + * devices. Devices known to support this interface include the AXP223, + * AXP809, and AXP806 PMICs, and the AC100 audio codec, all from X-Powers. + * + * A description of the operation and wire protocol can be found in the + * RSB section of Allwinner's A80 user manual, which can be found at + * + * https://github.com/allwinner-zh/documents/tree/master/A80 + * + * This document is officially released by Allwinner. + * + * This driver is based on i2c-sun6i-p2wi.c, the P2WI bus driver. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* RSB registers */ +#define RSB_CTRL 0x0 /* Global control */ +#define RSB_CCR0x4 /* Clock control */ +#define RSB_INTE 0x8 /* Interrupt controls */ +#define RSB_INTS 0xc /* Interrupt status */ +#define RSB_ADDR 0x10/* Address to send with read/write command */ +#define RSB_DATA 0x1c/* Data to read/write */ +#define RSB_LCR0x24/* Line control */ +#define RSB_DMCR 0x28/* Device mode (init) control */ +#define RSB_CMD0x2c/* RSB Command */ +#define RSB_DAR0x30/* Device address / runtime address */ + +/* CTRL fields */ +#define RSB_CTRL_START_TRANS BIT(7) +#define RSB_CTRL_ABORT_TRANS BIT(6) +#define RSB_CTRL_GLOBAL_INT_ENBBIT(1) +#define RSB_CTRL_SOFT_RST BIT(0) + +/* CLK CTRL fields */ +#define RSB_CCR_SDA_OUT_DELAY(v) (((v) & 0x7) << 8) +#define RSB_CCR_MAX_CLK_DIV0xff +#define RSB_CCR_CLK_DIV(v) ((v) & RSB_CCR_MAX_CLK_DIV) + +/* STATUS fields */ +#define RSB_INTS_TRANS_E
[PATCH v6 1/2] bus: sunxi-rsb: Add Allwinner Reduced Serial Bus (RSB) controller bindings
Reduced Serial Bus is a proprietary 2-line push-pull serial bus supporting
multiple slave devices. It was developed by Allwinner, Inc. and used by
Allwinner and X-Powers, Inc. for their line of PMICs and other peripheral
ICs.
Recent Allwinner SoCs, starting with the A23, have an RSB controller. This
is used to talk to the PMIC, and later with the A80 and A83 platform, the
audio codec IC.
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/bus/sunxi-rsb.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/sunxi-rsb.txt
diff --git a/Documentation/devicetree/bindings/bus/sunxi-rsb.txt
b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt
new file mode 100644
index ..3dd28343b6ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt
@@ -0,0 +1,47 @@
+Allwinner Reduced Serial Bus (RSB) controller
+
+The RSB controller found on later Allwinner SoCs is an SMBus like 2 wire
+serial bus with 1 master and up to 15 slaves. It is represented by a node
+for the controller itself, and child nodes representing the slave devices.
+
+Required properties :
+
+ - reg : Offset and length of the register set for the controller.
+ - compatible : Shall be "allwinner,sun8i-a23-rsb".
+ - interrupts : The interrupt line associated to the RSB controller.
+ - clocks : The gate clk associated to the RSB controller.
+ - resets : The reset line associated to the RSB controller.
+ - #address-cells : shall be 1
+ - #size-cells : shall be 0
+
+Optional properties :
+
+ - clock-frequency : Desired RSB bus clock frequency in Hz. Maximum is 20MHz.
+If not set this defaults to 3MHz.
+
+Child nodes:
+
+An RSB controller node can contain zero or more child nodes representing
+slave devices on the bus. Child 'reg' properties should contain the slave
+device's hardware address. The hardware address is hardwired in the device,
+which can normally be found in the datasheet.
+
+Example:
+
+ rsb@01f03400 {
+ compatible = "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = <0 39 4>;
+ clocks = <&apb0_gates 3>;
+ clock-frequency = <300>;
+ resets = <&apb0_rst 3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3e3 {
+ compatible = "...";
+ reg = <0x3e3>;
+
+ /* ... */
+ };
+ };
--
2.6.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
[PATCH v2 8/9] ARM: dts: Add leds support to STM32F429 Discovery board
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stm32f429-disco.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
b/arch/arm/boot/dts/stm32f429-disco.dts
index e3ce796..532c499 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -64,6 +64,16 @@
aliases {
serial0 = &usart1;
};
+
+ leds {
+ compatible = "gpio-leds";
+ red {
+ gpios = <&gpiog 14 0>;
+ };
+ green {
+ gpios = <&gpiog 13 0>;
+ };
+ };
};
&clk_hse {
--
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
[PATCH v2 3/9] includes: dt-bindings: Add STM32F429 pinctrl DT bindings
Signed-off-by: Maxime Coquelin --- include/dt-bindings/pinctrl/pinctrl-stm32.h | 12 + include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1241 +++ 2 files changed, 1253 insertions(+) create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h diff --git a/include/dt-bindings/pinctrl/pinctrl-stm32.h b/include/dt-bindings/pinctrl/pinctrl-stm32.h new file mode 100644 index 000..a2e7222 --- /dev/null +++ b/include/dt-bindings/pinctrl/pinctrl-stm32.h @@ -0,0 +1,12 @@ +#ifndef _DT_BINDINGS_PINCTRL_STM32_H +#define _DT_BINDINGS_PINCTRL_STM32_H + +#define STM32_PIN_NO(x) ((x) << 8) +#define STM32_GET_PIN_NO(x) ((x) >> 8) +#define STM32_GET_PIN_FUNC(x) ((x) & 0xff) + +#define STM32_PIN_GPIO 0 +#define STM32_PIN_AF(x)((x) + 1) +#define STM32_PIN_ANALOG (STM32_PIN_AF(15) + 1) + +#endif /* _DT_BINDINGS_PINCTRL_STM32_H */ diff --git a/include/dt-bindings/pinctrl/stm32f429-pinfunc.h b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h new file mode 100644 index 000..9dd5fd0 --- /dev/null +++ b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h @@ -0,0 +1,1241 @@ +#ifndef _DT_BINDINGS_STM32F429_PINFUNC_H +#define _DT_BINDINGS_STM32F429_PINFUNC_H + +#include + +#define STM32F429_PA0_FUNC_GPIO 0x0 +#define STM32F429_PA0_FUNC_TIM2_CH1_TIM2_ETR 0x2 +#define STM32F429_PA0_FUNC_TIM5_CH1 0x3 +#define STM32F429_PA0_FUNC_TIM8_ETR 0x4 +#define STM32F429_PA0_FUNC_USART2_CTS 0x8 +#define STM32F429_PA0_FUNC_UART4_TX 0x9 +#define STM32F429_PA0_FUNC_ETH_MII_CRS 0xc +#define STM32F429_PA0_FUNC_EVENTOUT 0x10 +#define STM32F429_PA0_FUNC_ANALOG 0x11 + +#define STM32F429_PA1_FUNC_GPIO 0x100 +#define STM32F429_PA1_FUNC_TIM2_CH2 0x102 +#define STM32F429_PA1_FUNC_TIM5_CH2 0x103 +#define STM32F429_PA1_FUNC_USART2_RTS 0x108 +#define STM32F429_PA1_FUNC_UART4_RX 0x109 +#define STM32F429_PA1_FUNC_ETH_MII_RX_CLK_ETH_RMII_REF_CLK 0x10c +#define STM32F429_PA1_FUNC_EVENTOUT 0x110 +#define STM32F429_PA1_FUNC_ANALOG 0x111 + +#define STM32F429_PA2_FUNC_GPIO 0x200 +#define STM32F429_PA2_FUNC_TIM2_CH3 0x202 +#define STM32F429_PA2_FUNC_TIM5_CH3 0x203 +#define STM32F429_PA2_FUNC_TIM9_CH1 0x204 +#define STM32F429_PA2_FUNC_USART2_TX 0x208 +#define STM32F429_PA2_FUNC_ETH_MDIO 0x20c +#define STM32F429_PA2_FUNC_EVENTOUT 0x210 +#define STM32F429_PA2_FUNC_ANALOG 0x211 + +#define STM32F429_PA3_FUNC_GPIO 0x300 +#define STM32F429_PA3_FUNC_TIM2_CH4 0x302 +#define STM32F429_PA3_FUNC_TIM5_CH4 0x303 +#define STM32F429_PA3_FUNC_TIM9_CH2 0x304 +#define STM32F429_PA3_FUNC_USART2_RX 0x308 +#define STM32F429_PA3_FUNC_OTG_HS_ULPI_D0 0x30b +#define STM32F429_PA3_FUNC_ETH_MII_COL 0x30c +#define STM32F429_PA3_FUNC_LCD_B5 0x30f +#define STM32F429_PA3_FUNC_EVENTOUT 0x310 +#define STM32F429_PA3_FUNC_ANALOG 0x311 + +#define STM32F429_PA4_FUNC_GPIO 0x400 +#define STM32F429_PA4_FUNC_SPI1_NSS 0x406 +#define STM32F429_PA4_FUNC_SPI3_NSS_I2S3_WS 0x407 +#define STM32F429_PA4_FUNC_USART2_CK 0x408 +#define STM32F429_PA4_FUNC_OTG_HS_SOF 0x40d +#define STM32F429_PA4_FUNC_DCMI_HSYNC 0x40e +#define STM32F429_PA4_FUNC_LCD_VSYNC 0x40f +#define STM32F429_PA4_FUNC_EVENTOUT 0x410 +#define STM32F429_PA4_FUNC_ANALOG 0x411 + +#define STM32F429_PA5_FUNC_GPIO 0x500 +#define STM32F429_PA5_FUNC_TIM2_CH1_TIM2_ETR 0x502 +#define STM32F429_PA5_FUNC_TIM8_CH1N 0x504 +#define STM32F429_PA5_FUNC_SPI1_SCK 0x506 +#define STM32F429_PA5_FUNC_OTG_HS_ULPI_CK 0x50b +#define STM32F429_PA5_FUNC_EVENTOUT 0x510 +#define STM32F429_PA5_FUNC_ANALOG 0x511 + +#define STM32F429_PA6_FUNC_GPIO 0x600 +#define STM32F429_PA6_FUNC_TIM1_BKIN 0x602 +#define STM32F429_PA6_FUNC_TIM3_CH1 0x603 +#define STM32F429_PA6_FUNC_TIM8_BKIN 0x604 +#define STM32F429_PA6_FUNC_SPI1_MISO 0x606 +#define STM32F429_PA6_FUNC_TIM13_CH1 0x60a +#define STM32F429_PA6_FUNC_DCMI_PIXCLK 0x60e +#define STM32F429_PA6_FUNC_LCD_G2 0x60f +#define STM32F429_PA6_FUNC_EVENTOUT 0x610 +#define STM32F429_PA6_FUNC_ANALOG 0x611 + +#define STM32F429_PA7_FUNC_GPIO 0x700 +#define STM32F429_PA7_FUNC_TIM1_CH1N 0x702 +#define STM32F429_PA7_FUNC_TIM3_CH2 0x703 +#define STM32F429_PA7_FUNC_TIM8_CH1N 0x704 +#define STM32F429_PA7_FUNC_SPI1_MOSI 0x706 +#define STM32F429_PA7_FUNC_TIM14_CH1 0x70a +#define STM32F429_PA7_FUNC_ETH_MII_RX_DV_ETH_RMII_CRS_DV 0x70c +#define STM32F429_PA7_FUNC_EVENTOUT 0x710 +#define STM32F429_PA7_FUNC_ANALOG 0x711 + +#define STM32F429_PA8_FUNC_GPIO 0x800 +#define STM32F429_PA8_FUNC_MCO1 0x801 +#define STM32F429_PA8_FUNC_TIM1_CH1 0x802 +#define STM32F429_PA8_FUNC_I2C3_SCL 0x805 +#define STM32F429_PA8_FUNC_USART1_CK 0x808 +#define STM32F429_PA8_FUNC_OTG_FS_SOF 0x80b +#define STM32F429_PA8_FUNC_LCD_R6 0x80f +#define STM32F429_PA8_FUNC_EVENTOUT 0x810 +#define STM32F429_PA8_FUNC_ANALOG 0x811 + +#define STM32F429_PA9_FUNC_GPIO 0x900 +#define STM32F429_PA9_FUNC_TIM1_CH2 0x902 +#define STM32F429_PA9_FUNC_I2C3_SMBA 0x905 +#define STM32F429_PA9_FUNC_USART1_TX 0x908 +#define STM32F429_PA9_FUNC_DCMI_D0 0x90e +#define STM32F429_PA9_FUNC_EVENTOUT 0
[PATCH 1/9] Documentation: dt-bindings: Document STM32 EXTI controller bindings
Signed-off-by: Maxime Coquelin
---
.../bindings/interrupt-controller/st,stm32-exti.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
new file mode 100644
index 000..6e7703d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
@@ -0,0 +1,20 @@
+STM32 External Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "st,stm32-exti"
+- reg: Specifies base physical address and size of the registers
+- interrupt-controller: Indentifies the node as an interrupt controller
+- #interrupt-cells: Specifies the number of cells to encode an interrupt
+ specifier, shall be 2
+- interrupts: interrupts references to primary interrupt controller
+
+Example:
+
+exti: interrupt-controller@40013c00 {
+ compatible = "st,stm32-exti";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x40013C00 0x400>;
+ interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>,
<42>, <62>, <76>;
+};
--
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
[PATCH v2 9/9] ARM: config: Enable GPIO Led driver in stm32_defconfig
Signed-off-by: Maxime Coquelin --- arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index 4725fab..92ade2e 100644 --- a/arch/arm/configs/stm32_defconfig +++ b/arch/arm/configs/stm32_defconfig @@ -52,6 +52,7 @@ CONFIG_SERIAL_STM32_CONSOLE=y # CONFIG_USB_SUPPORT is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y # CONFIG_FILE_LOCKING is not set -- 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
[PATCH 3/9] ARM: STM32: Select external interrupts controller
Signed-off-by: Maxime Coquelin --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 8a764ba..8ca5b2b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -986,6 +986,7 @@ config ARCH_STM32 select CLKSRC_STM32 select PINCTRL select RESET_CONTROLLER + select STM32_EXTI help Support for STMicroelectronics STM32 processors. -- 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
[PATCH 7/9] ARM: dts: Add GPIO irq support to STM2F429
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stm32f429.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index a2c3aaa..bc84e8b 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -169,6 +169,11 @@
status = "disabled";
};
+ syscfg: system-config@40013800 {
+ compatible = "syscon";
+ reg = <0x40013800 0x400>;
+ };
+
exti: interrupt-controller@40013c00 {
compatible = "st,stm32-exti";
interrupt-controller;
@@ -182,6 +187,8 @@
#size-cells = <1>;
compatible = "st,stm32f429-pinctrl";
ranges = <0 0x4002 0x3000>;
+ interrupt-parent = <&exti>;
+ st,syscfg = <&syscfg 0x8>;
pins-are-numbered;
gpioa: gpio@4002 {
--
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
[PATCH 5/9] Documentation: dt-bindings: Add IRQ related properties of STM32 pinctrl
Signed-off-by: Maxime Coquelin --- Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt index 7b4800c..dd95bec 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt @@ -13,6 +13,9 @@ Required properies: - #size-cells : The value of this property must be 1 - ranges : defines mapping between pin controller node (parent) to gpio-bank node (children). + - interrupt-parent: phandle of the interrupt parent to which the external + GPIO interrupts are forwarded to. + - st,syscfg: phandle of the syscfg node used for IRQ mux selection. - pins-are-numbered: Specify the subnodes are using numbered pinmux to specify pins. -- 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
[PATCH 0/9] Add STM32 EXTI interrupt controller support
This series adds support to EXTI interrupt controller and GPIO IRQ support in STM32 pinctrl driver. The STM32 external interrupt controller consists of edge detectors that generate interrupts requests or wake-up events. Each line can be independently configured as interrupt or wake-up source, and triggers either on rising, fallin or both edges. Each line can also be masked independently. This series applies on top of STM32 pinctrl v2 series. Regards, Maxime Maxime Coquelin (9): Documentation: dt-bindings: Document STM32 EXTI controller bindings drivers: irqchip: Add STM32 external interrupts support ARM: STM32: Select external interrupts controller ARM: dts: Add EXTI controller node to stm32f429 Documentation: dt-bindings: Add IRQ related properties of STM32 pinctrl pinctrl: Add IRQ support to STM32 gpios ARM: dts: Add GPIO irq support to STM2F429 ARM: dts: Declare push button as GPIO key on stm32f429 Disco board ARM: config: Enable GPIO Key driver in stm32_defconfig .../interrupt-controller/st,stm32-exti.txt | 20 +++ .../bindings/pinctrl/st,stm32-pinctrl.txt | 3 + arch/arm/Kconfig | 1 + arch/arm/boot/dts/stm32429i-eval.dts | 19 +++ arch/arm/boot/dts/stm32f429-disco.dts | 13 ++ arch/arm/boot/dts/stm32f429.dtsi | 15 ++ arch/arm/configs/stm32_defconfig | 6 +- drivers/irqchip/Kconfig| 4 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-stm32-exti.c | 169 + drivers/pinctrl/stm32/Kconfig | 1 + drivers/pinctrl/stm32/pinctrl-stm32.c | 68 + 12 files changed, 319 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt create mode 100644 drivers/irqchip/irq-stm32-exti.c -- 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
[PATCH 6/9] pinctrl: Add IRQ support to STM32 gpios
This patch adds IRQ support to STM32 gpios.
The EXTI controller has 16 lines dedicated to GPIOs.
EXTI line n can be connected to only line n of one of the GPIO ports, for
example EXTI0 can be connected to either PA0, or PB0, or PC0...
This port selection is done by specifying the port number into System
Config registers.
Signed-off-by: Maxime Coquelin
---
drivers/pinctrl/stm32/Kconfig | 1 +
drivers/pinctrl/stm32/pinctrl-stm32.c | 68 +++
2 files changed, 69 insertions(+)
diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
index 0f28841..b5cac5b 100644
--- a/drivers/pinctrl/stm32/Kconfig
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -6,6 +6,7 @@ config PINCTRL_STM32
select PINMUX
select GENERIC_PINCONF
select GPIOLIB
+ select MFD_SYSCON
config PINCTRL_STM32F429
bool "STMicroelectronics STM32F429 pin control" if COMPILE_TEST &&
!MACH_STM32F429
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c
b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 4ebceaa..954b596 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -20,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -82,6 +85,9 @@ struct stm32_pinctrl {
struct stm32_gpio_bank *banks;
unsigned nbanks;
const struct stm32_pinctrl_match_data *match_data;
+ struct irq_domain *domain;
+ struct regmap *regmap;
+ struct regmap_field *irqmux[STM32_GPIO_PINS_PER_BANK];
};
static inline int stm32_gpio_pin(int gpio)
@@ -179,6 +185,22 @@ static int stm32_gpio_direction_output(struct gpio_chip
*chip,
return 0;
}
+
+static int stm32_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+{
+ struct stm32_pinctrl *pctl = dev_get_drvdata(chip->dev);
+ struct stm32_gpio_bank *bank = gpio_chip_to_bank(chip);
+ unsigned int virq;
+
+ regmap_field_write(pctl->irqmux[offset], bank->range.id);
+
+ virq = irq_create_mapping(pctl->domain, offset);
+ if (!virq)
+ return -ENXIO;
+
+ return virq;
+}
+
static struct gpio_chip stm32_gpio_template = {
.request= stm32_gpio_request,
.free = stm32_gpio_free,
@@ -186,6 +208,7 @@ static struct gpio_chip stm32_gpio_template = {
.set= stm32_gpio_set,
.direction_input= stm32_gpio_direction_input,
.direction_output = stm32_gpio_direction_output,
+ .to_irq = stm32_gpio_to_irq,
};
/* Pinctrl functions */
@@ -731,6 +754,47 @@ static int stm32_gpiolib_register_bank(struct
stm32_pinctrl *pctl,
return 0;
}
+static int stm32_pctrl_dt_setup_irq(struct platform_device *pdev,
+ struct stm32_pinctrl *pctl)
+{
+ struct device_node *np = pdev->dev.of_node, *parent;
+ struct device *dev = &pdev->dev;
+ struct regmap *rm;
+ int offset, ret, i;
+
+ parent = of_irq_find_parent(np);
+ if (!parent)
+ return -ENXIO;
+
+ pctl->domain = irq_find_host(parent);
+ if (!pctl->domain)
+ return -ENXIO;
+
+ pctl->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+ if (IS_ERR(pctl->regmap))
+ return PTR_ERR(pctl->regmap);
+
+ rm = pctl->regmap;
+
+ ret = of_property_read_u32_index(np, "st,syscfg", 1, &offset);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < STM32_GPIO_PINS_PER_BANK; i++) {
+ struct reg_field mux;
+
+ mux.reg = offset + (i / 4) * 4;
+ mux.lsb = (i % 4) * 4;
+ mux.msb = mux.lsb + 3;
+
+ pctl->irqmux[i] = devm_regmap_field_alloc(dev, rm, mux);
+ if (IS_ERR(pctl->irqmux[i]))
+ return PTR_ERR(pctl->irqmux[i]);
+ }
+
+ return 0;
+}
+
static int stm32_pctrl_build_state(struct platform_device *pdev)
{
struct stm32_pinctrl *pctl = platform_get_drvdata(pdev);
@@ -823,6 +887,10 @@ int stm32_pctl_probe(struct platform_device *pdev)
}
}
+ ret = stm32_pctrl_dt_setup_irq(pdev, pctl);
+ if (ret)
+ return ret;
+
pins = devm_kcalloc(&pdev->dev, pctl->match_data->npins, sizeof(*pins),
GFP_KERNEL);
if (!pins)
--
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
[PATCH 4/9] ARM: dts: Add EXTI controller node to stm32f429
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stm32f429.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index eb3580e..a2c3aaa 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -169,6 +169,14 @@
status = "disabled";
};
+ exti: interrupt-controller@40013c00 {
+ compatible = "st,stm32-exti";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x40013C00 0x400>;
+ interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>,
<23>, <40>, <41>, <42>, <62>, <76>;
+ };
+
pin-controller {
#address-cells = <1>;
#size-cells = <1>;
--
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
[PATCH 9/9] ARM: config: Enable GPIO Key driver in stm32_defconfig
Signed-off-by: Maxime Coquelin --- arch/arm/configs/stm32_defconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index 92ade2e..31894ef 100644 --- a/arch/arm/configs/stm32_defconfig +++ b/arch/arm/configs/stm32_defconfig @@ -38,7 +38,11 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_FW_LOADER is not set # CONFIG_BLK_DEV is not set CONFIG_EEPROM_93CX6=y -# CONFIG_INPUT is not set +# CONFIG_INPUT_LEDS is not set +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_KEYBOARD_ATKBD is not set +CONFIG_KEYBOARD_GPIO=y +# CONFIG_INPUT_MOUSE is not set # CONFIG_SERIO is not set # CONFIG_VT is not set # CONFIG_UNIX98_PTYS is not set -- 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
[PATCH 8/9] ARM: dts: Declare push button as GPIO key on stm32f429 Disco board
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stm32429i-eval.dts | 19 +++
arch/arm/boot/dts/stm32f429-disco.dts | 13 +
2 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 71fe17a..be21931 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -47,6 +47,7 @@
/dts-v1/;
#include "stm32f429.dtsi"
+#include
/ {
model = "STMicroelectronics STM32429i-EVAL board";
@@ -64,6 +65,24 @@
aliases {
serial0 = &usart1;
};
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+ button@0 {
+ label = "Wake up";
+ linux,code = ;
+ gpios = <&gpioa 0 0>;
+ };
+ button@1 {
+ label = "Tamper";
+ linux,code = ;
+ gpios = <&gpioc 13 0>;
+ };
+
+ };
};
&clk_hse {
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
b/arch/arm/boot/dts/stm32f429-disco.dts
index 532c499..2cb4c9e 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -47,6 +47,7 @@
/dts-v1/;
#include "stm32f429.dtsi"
+#include
/ {
model = "STMicroelectronics STM32F429i-DISCO board";
@@ -74,6 +75,18 @@
gpios = <&gpiog 13 0>;
};
};
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+ button@0 {
+ label = "User";
+ linux,code = ;
+ gpios = <&gpioa 0 0>;
+ };
+ };
};
&clk_hse {
--
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
[PATCH 2/9] drivers: irqchip: Add STM32 external interrupts support
The STM32 external interrupt controller consists of edge detectors that
generate interrupts requests or wake-up events.
Each line can be independently configured as interrupt or wake-up source,
and triggers either on rising, fallin or both edges. Each line can also
be masked independently.
Signed-off-by: Maxime Coquelin
---
drivers/irqchip/Kconfig | 4 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-stm32-exti.c | 169 +++
3 files changed, 174 insertions(+)
create mode 100644 drivers/irqchip/irq-stm32-exti.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 27b52c8..5bd8df5 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -187,3 +187,7 @@ config IMX_GPCV2
select IRQ_DOMAIN
help
Enables the wakeup IRQs for IMX platforms with GPCv2 block
+
+config STM32_EXTI
+ bool
+ select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index bb3048f..cabe2f4 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_RENESAS_H8S_INTC)+=
irq-renesas-h8s.o
obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
+obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
new file mode 100644
index 000..02bfa80
--- /dev/null
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EXTI_IMR 0x0
+#define EXTI_EMR 0x4
+#define EXTI_RTSR 0x8
+#define EXTI_FTSR 0xc
+#define EXTI_SWIER 0x10
+#define EXTI_PR0x14
+
+static void stm32_irq_handler(struct irq_desc *desc)
+{
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip_generic *gc = domain->gc->gc[0];
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long pending;
+ int n;
+
+ chained_irq_enter(chip, desc);
+
+ pending = irq_reg_readl(gc, EXTI_PR);
+ for_each_set_bit(n, &pending, BITS_PER_LONG) {
+ generic_handle_irq(irq_find_mapping(domain, n));
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static int stm32_irq_set_type(struct irq_data *data, unsigned int type)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ u32 rtsr, ftsr;
+ int pin = data->hwirq;
+
+ irq_gc_lock(gc);
+
+ rtsr = irq_reg_readl(gc, EXTI_RTSR);
+ ftsr = irq_reg_readl(gc, EXTI_FTSR);
+
+ switch (type) {
+ case IRQ_TYPE_EDGE_RISING:
+ rtsr |= BIT(pin);
+ ftsr &= ~BIT(pin);
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ rtsr &= ~BIT(pin);
+ ftsr |= BIT(pin);
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ rtsr |= BIT(pin);
+ ftsr |= BIT(pin);
+ break;
+ default:
+ irq_gc_unlock(gc);
+ return -EINVAL;
+ }
+
+ irq_reg_writel(gc, rtsr, EXTI_RTSR);
+ irq_reg_writel(gc, ftsr, EXTI_FTSR);
+
+ irq_gc_unlock(gc);
+
+ return 0;
+}
+
+static int stm32_irq_set_wake(struct irq_data *data, unsigned int on)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ int pin = data->hwirq;
+ u32 emr;
+
+ irq_gc_lock(gc);
+
+ emr = irq_reg_readl(gc, EXTI_EMR);
+ if (on)
+ emr |= BIT(pin);
+ else
+ emr &= ~BIT(pin);
+ irq_reg_writel(gc, emr, EXTI_EMR);
+
+ irq_gc_unlock(gc);
+
+ return 0;
+}
+
+static int __init stm32_exti_init(struct device_node *node,
+ struct device_node *parent)
+{
+ int nr_irqs, nr_exti, ret, i;
+ unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
+ struct irq_domain *domain;
+ struct irq_chip_generic *gc;
+ void *base;
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ pr_err("%s: Unable to map registers\n", node->full_name);
+ return -ENOMEM;
+ }
+
+ /* Determine number of irqs supported */
+ writel_relaxed(~0UL, base + EXTI_RTSR);
+ nr_exti = fls(readl_relaxed(base + EXTI_RTSR));
+ writel_relaxed(0, base + EXTI_RTSR);
+
+ pr_info("%s: %d External IRQs detected\n", node->full_name, nr_exti);
+
+ domain = irq_domain_add_linear(node, nr_exti,
+ &irq_generic_chip_ops, NULL);
+ if (!domain) {
+ pr_err("%s: Could not r
[PATCH v2 0/9] Add STM32 pinctrl/GPIO driver
Hi Linus, all, This is the second round of STM32 pinctrl series, which improves DT bindings declaration and documentation, and also fixes some commit fixup issues. The series also contains two more patches, adding GPIO LEDs support as a user of this driver. The STM32 family has 16 pins per GPIO bank, and the number of bank varies depending on the model. Pins can be multiplexed either in GPIO mode, alternate function (up to 15 functions per pin) or analog (for ADC/DAC). Changes since v1: - - Add GPIO LEDs support in DT and defconfig - Changes pinmux DT bindings from macros to raw values (Daniel) - Improve DT bindings documentation (Daniel) - Fix some commit fixup and rebase issues. Kind regards, Maxime Maxime Coquelin (9): ARM: Kconfig: Introduce MACH_STM32F429 flag Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings includes: dt-bindings: Add STM32F429 pinctrl DT bindings pinctrl: Add support STM32 MCUs ARM: mach-stm32: Select pinctrl ARM: dts: Add pinctrl node to STM32F429 ARM: dts: Add USART1 pin config to STM32F429 boards ARM: dts: Add leds support to STM32F429 Discovery board ARM: config: Enable GPIO Led driver in stm32_defconfig .../bindings/pinctrl/st,stm32-pinctrl.txt | 126 ++ arch/arm/Kconfig |6 + arch/arm/boot/dts/stm32429i-eval.dts |2 + arch/arm/boot/dts/stm32f429-disco.dts | 12 + arch/arm/boot/dts/stm32f429.dtsi | 110 ++ arch/arm/configs/stm32_defconfig |1 + drivers/pinctrl/Kconfig|1 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/stm32/Kconfig | 16 + drivers/pinctrl/stm32/Makefile |5 + drivers/pinctrl/stm32/pinctrl-stm32.c | 856 +++ drivers/pinctrl/stm32/pinctrl-stm32.h | 43 + drivers/pinctrl/stm32/pinctrl-stm32f429.c | 1598 include/dt-bindings/pinctrl/pinctrl-stm32.h| 12 + include/dt-bindings/pinctrl/stm32f429-pinfunc.h| 1241 +++ 15 files changed, 4030 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt create mode 100644 drivers/pinctrl/stm32/Kconfig create mode 100644 drivers/pinctrl/stm32/Makefile create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.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] mmc: core: Allow specifying current consumption
On Fri 16 Oct 05:55 PDT 2015, Ulf Hansson wrote: > On 13 October 2015 at 03:00, Bjorn Andersson > wrote: > > This allows us to specify expected current consumption of the vmmc and > > vqmmc regulators. This is needed to bring the supplying regulators out > > of their low-power-mode while accessing the mmc. > > This indeed makes sense, still I need to think a bit more on this. > Thanks. We can currently work around this by using "regulator-system-load" on the vmmc regulator, but a proper fix would be nice. > For example, can we allow these regulators to enter low power again at > some times? If so, when and what should that current value be. > The regulator framework recalculates the total load on a regulator upon enable/disable, but currently it doesn't depend on the state of the regulator. I talked to Mark about this a while back and he was positive to us correcting this, so disabled regulators wouldn't count towards the total load of a regulator. (So that still is on my todo) The second option would be to do what is done in the Qualcomm codeaurora kernels, where the regulators are never disabled and there's a smaller current specified for the suspend case. This would require bigger changes to the mmc core I presume, but the naming of the dt properties support such future adaption. > Moreover, wouldn't vmmc|vqmmc-active-current be depending what eMMC/SD > card that is attached? > I would say so, I do however not know how to acquire or encode that information. Any suggestions here are welcome. Regards, Bjorn -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 11:28:29AM -0500, Rob Herring wrote: > On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman > wrote: > > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: > >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman > >> wrote: > >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > >> >> Hi Rob, > >> >> > >> >> here is the pull request you asked for, with no changes from the version > >> >> that I posted last to the list. > >> >> > >> >> The following changes since commit > >> >> 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > >> >> > >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > >> >> > >> >> are available in the git repository at: > >> >> > >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > >> >> on-demand-probes-for-next > >> > > >> > That's not a signed tag :( > >> > > >> > Anyway, I REALLY don't like this series (sorry for the delay in > >> > reviewing them, normally I trust Rob's judgement...) > >> > >> We've seen a lot of attempts here. This is really the best solution so > >> far in that it is simple, uses existing data from DT, and was low risk > >> for breaking platforms (at least I thought it would be). Anyway, > >> getting more exposure is why I've put it into -next. > > > > Exposure is good, now we know it breaks some builds, which was useful :) > > Now that I've looked at them, they are somewhat questionable failures. > They do show the fragile nature of probe ordering and the implicit > dependencies we have. > > >> > I can't see adding calls like this all over the tree just to solve a > >> > bus-specific problem, you are adding of_* calls where they aren't > >> > needed, or wanted, at all. > >> > >> I think Linus W, Mark B, and I all said a similar thing initially in > >> that dependencies should be handled in the driver core. We went down > >> the path of making this not firmware (aka bus) specific and an earlier > >> version had just that (with fwnode_* calls). That turned out to be > >> pointless as the calling locations were almost always in DT specific > >> code anyway. If you notice, the calls are next to other DT specific > >> calls generally (usually a "get"). So yes, I'd prefer not to have to > >> touch every subsystem, but we had to do that anyway to add DT support. > > > > If they are "next" to a call like that, why not put it in that call? I > > really object to having to "sprinkle" this all over the kernel, for no > > obvious reason why that is happening at all (look at the USB patch for > > one such example.) > > Looking at it again, they are in DT specific code already. The USB one > is in devm_usb_get_phy_by_node() which is a DT specific call. But that's not very obvious, right? Especially given that you now have to add a new .h file, which implies that suddenly this file is now touching a new subsystem. > >> We've generally split the DT code into the core (in drivers/of) and > >> the binding specific (in subsystems). Extracting dependency > >> information the DT is going to require binding specific knowledge, so > >> subsystem changes are probably unavoidable. > >> > >> The alternative is we put binding specific knowledge into the core DT > >> code to parse dependencies. > >> > >> > What is the root-problem of your delay in device probing? I read your > >> > last patch series and I can't seem to figure out what the issue is that > >> > this is solving in any "better" way from the existing deferred probing. > >> > >> It saves 2 seconds in the boot time as re-probing takes time. That > >> alone seems compelling to me. > > > > 2 seconds is _forever_, and really seems like some other driver is > > sleeping and causing this problem. What does the bootlog time-chart say > > is really causing this long delay? There's no way we are stuck in some > > sort of logic loop for that long (i.e. having to walk the list of > > devices somehow.) This sounds like a driver-specific problem that is > > being worked around by having to touch all subsystems, which isn't nice. > > I don't think it is one driver as the improvement is seen on multiple > platforms. I'll let Tomeu comment further on where the time was spent. That would be good to know, as 2 seconds is forever (my whole machine boots to a gnome login faster than that.) > > Hint, we didn't have to do this type of thing to solve boot delays on > > x86 when we had hardware that was slow to initialize, why should DT be > > special? :) > > x86 did not need deferred probe either (though we probably can find > some initcall ordering hacks). This is an embedded problem, not a DT > problem. x86 is embedded :) > I'm guessing the time is a matter of probing and undoing the probes > rather than slow h/w. We could maybe improve things by making sure > drivers move what they defer on to the beginning of probe, but that > seems like a horrible, fragile hack. How can calling probe and failing cause 2 seconds? How many different probe calls are failing here? Again, a boot
Re: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman wrote: > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman >> wrote: >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: >> >> Hi Rob, >> >> >> >> here is the pull request you asked for, with no changes from the version >> >> that I posted last to the list. >> >> >> >> The following changes since commit >> >> 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: >> >> >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) >> >> >> >> are available in the git repository at: >> >> >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git >> >> on-demand-probes-for-next >> > >> > That's not a signed tag :( >> > >> > Anyway, I REALLY don't like this series (sorry for the delay in >> > reviewing them, normally I trust Rob's judgement...) >> >> We've seen a lot of attempts here. This is really the best solution so >> far in that it is simple, uses existing data from DT, and was low risk >> for breaking platforms (at least I thought it would be). Anyway, >> getting more exposure is why I've put it into -next. > > Exposure is good, now we know it breaks some builds, which was useful :) Now that I've looked at them, they are somewhat questionable failures. They do show the fragile nature of probe ordering and the implicit dependencies we have. >> > I can't see adding calls like this all over the tree just to solve a >> > bus-specific problem, you are adding of_* calls where they aren't >> > needed, or wanted, at all. >> >> I think Linus W, Mark B, and I all said a similar thing initially in >> that dependencies should be handled in the driver core. We went down >> the path of making this not firmware (aka bus) specific and an earlier >> version had just that (with fwnode_* calls). That turned out to be >> pointless as the calling locations were almost always in DT specific >> code anyway. If you notice, the calls are next to other DT specific >> calls generally (usually a "get"). So yes, I'd prefer not to have to >> touch every subsystem, but we had to do that anyway to add DT support. > > If they are "next" to a call like that, why not put it in that call? I > really object to having to "sprinkle" this all over the kernel, for no > obvious reason why that is happening at all (look at the USB patch for > one such example.) Looking at it again, they are in DT specific code already. The USB one is in devm_usb_get_phy_by_node() which is a DT specific call. >> We've generally split the DT code into the core (in drivers/of) and >> the binding specific (in subsystems). Extracting dependency >> information the DT is going to require binding specific knowledge, so >> subsystem changes are probably unavoidable. >> >> The alternative is we put binding specific knowledge into the core DT >> code to parse dependencies. >> >> > What is the root-problem of your delay in device probing? I read your >> > last patch series and I can't seem to figure out what the issue is that >> > this is solving in any "better" way from the existing deferred probing. >> >> It saves 2 seconds in the boot time as re-probing takes time. That >> alone seems compelling to me. > > 2 seconds is _forever_, and really seems like some other driver is > sleeping and causing this problem. What does the bootlog time-chart say > is really causing this long delay? There's no way we are stuck in some > sort of logic loop for that long (i.e. having to walk the list of > devices somehow.) This sounds like a driver-specific problem that is > being worked around by having to touch all subsystems, which isn't nice. I don't think it is one driver as the improvement is seen on multiple platforms. I'll let Tomeu comment further on where the time was spent. > Hint, we didn't have to do this type of thing to solve boot delays on > x86 when we had hardware that was slow to initialize, why should DT be > special? :) x86 did not need deferred probe either (though we probably can find some initcall ordering hacks). This is an embedded problem, not a DT problem. I'm guessing the time is a matter of probing and undoing the probes rather than slow h/w. We could maybe improve things by making sure drivers move what they defer on to the beginning of probe, but that seems like a horrible, fragile hack. >> Another downside to deferred probing is you have to touch every driver >> and subsystem to support it. This contains the problem to the >> subsystems. > > But we have deferred probing already, only those drivers that need/want > it have to do anything, why create yet-another model here? Yes, the only ones needing it are drivers dependent on clocks, gpio, regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This is a side benefit and wouldn't take this series for that reason alone. I've used the deferred probing is good enough argument myself on previous attempts. The boot time improvements convinced me it is not good enough except for
Re: [PATCH 3/3] ARM: dts: sun6i: Add a dts file for the Sinovoip BPI-M2 board
On Thu, Oct 15, 2015 at 04:28:47PM +0200, Hans de Goede wrote: > The Sinovoip BPI-M2 is a SBC board based on the A31s SoC it features > 1G RAM, a microsd slot, Gbit ethernet, 4 usb-a USB-2 ports, ir receiver, > stereo headphone jack and hdmi video output. > > Signed-off-by: Hans de Goede Applied the three patches, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: > On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman > wrote: > > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > >> Hi Rob, > >> > >> here is the pull request you asked for, with no changes from the version > >> that I posted last to the list. > >> > >> The following changes since commit > >> 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > >> > >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > >> > >> are available in the git repository at: > >> > >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > >> on-demand-probes-for-next > > > > That's not a signed tag :( > > > > Anyway, I REALLY don't like this series (sorry for the delay in > > reviewing them, normally I trust Rob's judgement...) > > We've seen a lot of attempts here. This is really the best solution so > far in that it is simple, uses existing data from DT, and was low risk > for breaking platforms (at least I thought it would be). Anyway, > getting more exposure is why I've put it into -next. Exposure is good, now we know it breaks some builds, which was useful :) > > I can't see adding calls like this all over the tree just to solve a > > bus-specific problem, you are adding of_* calls where they aren't > > needed, or wanted, at all. > > I think Linus W, Mark B, and I all said a similar thing initially in > that dependencies should be handled in the driver core. We went down > the path of making this not firmware (aka bus) specific and an earlier > version had just that (with fwnode_* calls). That turned out to be > pointless as the calling locations were almost always in DT specific > code anyway. If you notice, the calls are next to other DT specific > calls generally (usually a "get"). So yes, I'd prefer not to have to > touch every subsystem, but we had to do that anyway to add DT support. If they are "next" to a call like that, why not put it in that call? I really object to having to "sprinkle" this all over the kernel, for no obvious reason why that is happening at all (look at the USB patch for one such example.) > We've generally split the DT code into the core (in drivers/of) and > the binding specific (in subsystems). Extracting dependency > information the DT is going to require binding specific knowledge, so > subsystem changes are probably unavoidable. > > The alternative is we put binding specific knowledge into the core DT > code to parse dependencies. > > > What is the root-problem of your delay in device probing? I read your > > last patch series and I can't seem to figure out what the issue is that > > this is solving in any "better" way from the existing deferred probing. > > It saves 2 seconds in the boot time as re-probing takes time. That > alone seems compelling to me. 2 seconds is _forever_, and really seems like some other driver is sleeping and causing this problem. What does the bootlog time-chart say is really causing this long delay? There's no way we are stuck in some sort of logic loop for that long (i.e. having to walk the list of devices somehow.) This sounds like a driver-specific problem that is being worked around by having to touch all subsystems, which isn't nice. Hint, we didn't have to do this type of thing to solve boot delays on x86 when we had hardware that was slow to initialize, why should DT be special? :) > Another downside to deferred probing is you have to touch every driver > and subsystem to support it. This contains the problem to the > subsystems. But we have deferred probing already, only those drivers that need/want it have to do anything, why create yet-another model here? thanks, greg k-h -- 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: [GIT PULL] On-demand device probing
On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson wrote: > Hi, > > I've bisected boot failures in next-20151016 down to patches in this branch: > > On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso > wrote: >> Tomeu Vizoso (20): >> driver core: handle -EPROBE_DEFER from bus_type.match() > > The machine it happened on was OMAP5UEVM: > > http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html So this one is because the MMC node numbering changed. I don't know how to fix that other than with aliases, but that doesn't solve backwards compatibility. > But I've also seen it on tegra2, that one bisected down to: > >> regulator: core: Probe regulators on demand > > http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html This one you need a rootwait I think. The MMC scanning is not guaranteed to be done before the rootfs mounting AFAIK. There may be other problems, but we can't see them since it panics. Rob -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman wrote: > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: >> Hi Rob, >> >> here is the pull request you asked for, with no changes from the version >> that I posted last to the list. >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) >> >> are available in the git repository at: >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git >> on-demand-probes-for-next > > That's not a signed tag :( > > Anyway, I REALLY don't like this series (sorry for the delay in > reviewing them, normally I trust Rob's judgement...) We've seen a lot of attempts here. This is really the best solution so far in that it is simple, uses existing data from DT, and was low risk for breaking platforms (at least I thought it would be). Anyway, getting more exposure is why I've put it into -next. > I can't see adding calls like this all over the tree just to solve a > bus-specific problem, you are adding of_* calls where they aren't > needed, or wanted, at all. I think Linus W, Mark B, and I all said a similar thing initially in that dependencies should be handled in the driver core. We went down the path of making this not firmware (aka bus) specific and an earlier version had just that (with fwnode_* calls). That turned out to be pointless as the calling locations were almost always in DT specific code anyway. If you notice, the calls are next to other DT specific calls generally (usually a "get"). So yes, I'd prefer not to have to touch every subsystem, but we had to do that anyway to add DT support. We've generally split the DT code into the core (in drivers/of) and the binding specific (in subsystems). Extracting dependency information the DT is going to require binding specific knowledge, so subsystem changes are probably unavoidable. The alternative is we put binding specific knowledge into the core DT code to parse dependencies. > What is the root-problem of your delay in device probing? I read your > last patch series and I can't seem to figure out what the issue is that > this is solving in any "better" way from the existing deferred probing. It saves 2 seconds in the boot time as re-probing takes time. That alone seems compelling to me. Another downside to deferred probing is you have to touch every driver and subsystem to support it. This contains the problem to the subsystems. Rob -- 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] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
On Saturday 17 October 2015 12:52:18 Bharat Kumar Gogada wrote:
> + "msi_1, msi_0": interrupt asserted when msi is recieved
Better avoid underscores in DT, use "msi0" instead of "msi_0".
> +- interrupt-map-mask and interrupt-map: standard PCI properties to define the
> + mapping of the PCI interface to interrupt numbers.
> +- ranges: ranges for the PCI memory regions (I/O space region is not
> + supported by hardware)
> + Please refer to the standard PCI bus binding document for a more
> + detailed explanation
> +- msi-controller: indicates that this is MSI controller node
> +- msi-parent: MSI parent of the root complex itself
> +- pcie_intc: Interrupt controller device node for Legacy interrupts
> + - interrupt-controller: identifies the node as an interrupt controller
> + - #interrupt-cells: should be set to 1
> + - #address-cells: specifies the number of cells needed to encode an
> + address. The value must be 0.
The name doesn't match: below, the name is "legacy-interrupt-controller",
not "pcie_intc". I suppose it should really be "interrupt-controller"
anyway.
> +
> +Example:
> +
> +
> +nwl_pcie: pcie@fd0e {
> + #address-cells = >;
> + #size-cells = <2>;
> + compatible = "xlnx,nwl-pcie-2.11";
> + #interrupt-cells = <1>;
> + msi-controller;
> + device_type = "pci";
> + interrupt-parent = <&gic>;
> + interrupts = < 0 118 4
> + 0 116 4
> + 0 115 4 // MSI_1 [63...32]
> + 0 114 4 >; // MSI_0 [31...0]
Better write these as tuples:
interrupts = <0 118 4>, <0 116 4>, <0 115 4>, <0 114 4>;
And maybe reverse the order? It looks that might be what the
soc integration person had in mind.
Also, what is interrupt <0 117 4>? Is that connected here as well?
Better list it as well then, even if you don't use it.
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1
> +0x0 0x0 0x0 0x2 &pcie_intc 0x2
> +0x0 0x0 0x0 0x3 &pcie_intc 0x3
> +0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
> + msi-parent = <&nwl_pcie>;
> + reg = <0x0 0xfd0e 0x1000
> + 0x0 0xfd48 0x1000
> + 0x0 0xE000 0x100>;
Same grouping for reg and interrupt-map as above for interrupts.
> + reg-names = "breg", "pcireg", "cfg";
> + ranges = <0x0200 0x 0xE100 0x 0xE100 0
> 0x0F00>;
No I/O space or prefetcheable memory?
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 v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks
2015-10-17 18:55 GMT+09:00 Javier Martinez Canillas :
> Hello Krzysztof,
>
> On 10/17/2015 10:53 AM, Krzysztof Kozlowski wrote:
>> 2015-10-17 8:41 GMT+09:00 Kukjin Kim :
>
> [snip]
>
>>> So...how can I take 2nd patch of this series in samsung(arm-soc) tree?
>>> And this series shouldn't be for fixes for 4.3?...Mike how do you think?
>>
>> Stephen acked it so I thought everything will go through samsung-soc.
>>
>> Dear Kukjin,
>> Indeed this can go as fix for current cycle... but in the same time
>> this does not fix any specific regression. Tomeu did not describe when
>> issue happened for the first time so I assumed it was like that
>> always. It's up to you.
>>
>
> Sorry for not answering about this series before but I've been in contact
> with Tomeu over IRC before he posted it and since you already added your
> Reviewed-by tag, I didn't feel the need do to it.
>
> This is a regression for 4.3 since S2R was working correctly for 4.2 in
> Snow, I tested after fixing resume with commit 6fd4899a54a5 ("irqchip:
> exynos-combiner: Save IRQ enable set on suspend") and the display was
> always enabled on resume.
Hmmm, that means the patchset indeed should go as fixes.
Thanks for details,
Krzysztof
--
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/2] clk: samsung: exynos5250: Add DISP1 clocks
Hello Krzysztof,
On 10/17/2015 10:53 AM, Krzysztof Kozlowski wrote:
> 2015-10-17 8:41 GMT+09:00 Kukjin Kim :
[snip]
>>>
>> So...how can I take 2nd patch of this series in samsung(arm-soc) tree?
>> And this series shouldn't be for fixes for 4.3?...Mike how do you think?
>
> Stephen acked it so I thought everything will go through samsung-soc.
>
> Dear Kukjin,
> Indeed this can go as fix for current cycle... but in the same time
> this does not fix any specific regression. Tomeu did not describe when
> issue happened for the first time so I assumed it was like that
> always. It's up to you.
>
Sorry for not answering about this series before but I've been in contact
with Tomeu over IRC before he posted it and since you already added your
Reviewed-by tag, I didn't feel the need do to it.
This is a regression for 4.3 since S2R was working correctly for 4.2 in
Snow, I tested after fixing resume with commit 6fd4899a54a5 ("irqchip:
exynos-combiner: Save IRQ enable set on suspend") and the display was
always enabled on resume.
I don't have access to a Snow anymore to bisect but I think the regression
was introduced by some of the changes in 4.3 to migrate the Exynos DRM to
Atomic Mode Settings. But probably that just exposed a latent bug and it
was working out of luck since I had the same issue than Tomeu in Exynos5420
and was fixed in the same way with commits:
885601002998 ("clk: exynos5420: Add IDs for clocks used in DISP1 power domain")
ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")
> Both patches (with Stephen's ack) are in my recent pull request but as
> usual feel free to cherry pick. I'll drop them from next branch then.
>
> Best regards,
> Krzysztof
> --
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/2] clk: samsung: exynos5250: Add DISP1 clocks
2015-10-17 8:41 GMT+09:00 Kukjin Kim : > On 10/17/15 03:56, Tomeu Vizoso wrote: >> On 16 October 2015 at 19:26, Stephen Boyd wrote: >>> On 10/16, Michael Turquette wrote: Quoting Krzysztof Kozlowski (2015-10-15 16:46:27) > On 15.10.2015 19:31, Tomeu Vizoso wrote: >> When the DISP1 power domain is powered off, there's two clocks that need >> to be temporarily reparented to OSC, and back to their original parents >> when the domain is powered on again. >> >> We expose these two clocks in the DT bindings so that the DT node of the >> power domain can reference them. >> >> Signed-off-by: Tomeu Vizoso >> Acked-by: Stephen Boyd >> --- >> >> Changes in v2: >> - Reuse mout_aclk200_p >> - Rename div_aclk300 as div_aclk300_disp >> >> drivers/clk/samsung/clk-exynos5250.c | 14 +- >> include/dt-bindings/clock/exynos5250.h | 4 +++- >> 2 files changed, 16 insertions(+), 2 deletions(-) >> > > Reviewed-by: Krzysztof Kozlowski Applied to clk-next. >>> >>> I think Tomeu wanted to take this through arm-soc? Otherwise >>> we'll need to provide a stable branch for the dt header. >> >> Hi, Stephen is right, the second patch depends on this one. >> > So...how can I take 2nd patch of this series in samsung(arm-soc) tree? > And this series shouldn't be for fixes for 4.3?...Mike how do you think? Stephen acked it so I thought everything will go through samsung-soc. Dear Kukjin, Indeed this can go as fix for current cycle... but in the same time this does not fix any specific regression. Tomeu did not describe when issue happened for the first time so I assumed it was like that always. It's up to you. Both patches (with Stephen's ack) are in my recent pull request but as usual feel free to cherry pick. I'll drop them from next branch then. Best regards, Krzysztof -- 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] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
Signed-off-by: Bharat Kumar Gogada
Signed-off-by: Ravi Kiran Gummaluri
---
Added MSI domain implementation for handling MSI interrupts
Added implementation for chained irq handlers
Added legacy domain for handling legacy interrupts
Added child node for handling legacy interrupt
---
.../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 71 ++
drivers/pci/host/Kconfig |9 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xilinx-nwl.c | 1066
4 files changed, 1147 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..d64fc97
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,71 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+ configuration sapce, and length
+- reg-names: Must include the following entries:
+ "breg": bridge registers
+ "pcireg": PCIe controller registers
+ "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+ "misc": interrupt asserted when miscellaneous is recieved
+ "intx": interrupt that is asserted when an legacy interrupt is received
+ "msi_1, msi_0": interrupt asserted when msi is recieved
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+ mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+ supported by hardware)
+ Please refer to the standard PCI bus binding document for a more
+ detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent: MSI parent of the root complex itself
+- pcie_intc: Interrupt controller device node for Legacy interrupts
+ - interrupt-controller: identifies the node as an interrupt controller
+ - #interrupt-cells: should be set to 1
+ - #address-cells: specifies the number of cells needed to encode an
+ address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "xlnx,nwl-pcie-2.11";
+ #interrupt-cells = <1>;
+ msi-controller;
+ device_type = "pci";
+ interrupt-parent = <&gic>;
+ interrupts = < 0 118 4
+ 0 116 4
+ 0 115 4 // MSI_1 [63...32]
+ 0 114 4 >; // MSI_0 [31...0]
+ interrupt-names = "misc", "intx", "msi_1", "msi_0";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1
+0x0 0x0 0x0 0x2 &pcie_intc 0x2
+0x0 0x0 0x0 0x3 &pcie_intc 0x3
+0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+
+ msi-parent = <&nwl_pcie>;
+ reg = <0x0 0xfd0e 0x1000
+ 0x0 0xfd48 0x1000
+ 0x0 0xE000 0x100>;
+ reg-names = "breg", "pcireg", "cfg";
+ ranges = <0x0200 0x 0xE100 0x 0xE100 0
0x0F00>;
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c132bdd..33bbddb 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,15 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
+config PCIE_XILINX_NWL
+ bool "NWL PCIe Core"
+ depends on ARCH_ZYNQMP
+ help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
config PCIE_DW
bool
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$
