[PATCH v4 3/4] PCI: st: Provide support for the sti PCIe controller
sti pcie is built around a Synopsis Designware PCIe IP. Signed-off-by: Fabrice Gasnier fabrice.gasn...@st.com Signed-off-by: Gabriel Fernandez gabriel.fernan...@linaro.org --- drivers/pci/host/Kconfig | 9 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pci-st.c | 583 ++ 3 files changed, 593 insertions(+) create mode 100644 drivers/pci/host/pci-st.c diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index c132bdd..db56b8f 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA Say Y here if you want to use the Broadcom iProc PCIe controller through the BCMA bus interface +config PCI_ST + bool ST PCIe controller + depends on ARCH_STI || (ARM COMPILE_TEST) + select PCIE_DW + help + Enable PCIe controller support on ST Socs. This controller is based + on Designware hardware and therefore the driver re-uses the + Designware core functions to implement the driver. + endmenu diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 140d66f..c4024fa 100644 --- a/drivers/pci/host/Makefile +++ b/drivers/pci/host/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o +obj-$(CONFIG_PCI_ST) += pci-st.o diff --git a/drivers/pci/host/pci-st.c b/drivers/pci/host/pci-st.c new file mode 100644 index 000..0e7aaa2 --- /dev/null +++ b/drivers/pci/host/pci-st.c @@ -0,0 +1,583 @@ +/* + * Copyright (C) 2014 STMicroelectronics + * + * STMicroelectronics PCI express Driver for sti SoCs. + * ST PCIe IPs are built around a Synopsys IP Core. + * + * Author: Fabrice Gasnier fabrice.gasn...@st.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2, as + * published by the Free Software Foundation. + * + */ + +#include linux/delay.h +#include linux/interrupt.h +#include linux/mfd/syscon.h +#include linux/module.h +#include linux/of_address.h +#include linux/of_gpio.h +#include linux/of_pci.h +#include linux/of_platform.h +#include linux/phy/phy.h +#include linux/regmap.h +#include linux/reset.h + +#include pcie-designware.h + +#define TRANSLATION_CONTROL0x900 +/* Controls if area is inclusive or exclusive */ +#define RC_PASS_ADDR_RANGE BIT(1) + +/* Base of area reserved for config accesses. Fixed size of 64K. */ +#define CFG_BASE_ADDRESS 0x92c +#define CFG_REGION_SIZE65536 +#define CFG_SPACE1_OFFSET 0x1000 + +/* First 4K of config space has this BDF (bus,device,function) */ +#define FUNC0_BDF_NUM 0x930 + +/* Mem regions */ +#define IN0_MEM_ADDR_START 0x964 +#define IN0_MEM_ADDR_LIMIT 0x968 +#define IN1_MEM_ADDR_START 0x974 +#define IN1_MEM_ADDR_LIMIT 0x978 + +/* This actually contains the LTSSM state machine state */ +#define PORT_LOGIC_DEBUG_REG_0 0x728 + +/* LTSSM state machine values */ +#define DEBUG_REG_0_LTSSM_MASK 0x1f +#define S_DETECT_QUIET 0x00 +#define S_DETECT_ACT 0x01 +#define S_POLL_ACTIVE 0x02 +#define S_POLL_COMPLIANCE 0x03 +#define S_POLL_CONFIG 0x04 +#define S_PRE_DETECT_QUIET 0x05 +#define S_DETECT_WAIT 0x06 +#define S_CFG_LINKWD_START 0x07 +#define S_CFG_LINKWD_ACEPT 0x08 +#define S_CFG_LANENUM_WAIT 0x09 +#define S_CFG_LANENUM_ACEPT0x0A +#define S_CFG_COMPLETE 0x0B +#define S_CFG_IDLE 0x0C +#define S_RCVRY_LOCK 0x0D +#define S_RCVRY_SPEED 0x0E +#define S_RCVRY_RCVRCFG0x0F +#define S_RCVRY_IDLE 0x10 +#define S_L0 0x11 +#define S_L0S 0x12 +#define S_L123_SEND_EIDLE 0x13 +#define S_L1_IDLE 0x14 +#define S_L2_IDLE 0x15 +#define S_L2_WAKE 0x16 +#define S_DISABLED_ENTRY 0x17 +#define S_DISABLED_IDLE0x18 +#define S_DISABLED 0x19 +#define S_LPBK_ENTRY 0x1A +#define S_LPBK_ACTIVE 0x1B +#define S_LPBK_EXIT0x1C +#define S_LPBK_EXIT_TIMEOUT0x1D +#define S_HOT_RESET_ENTRY 0x1E +#define S_HOT_RESET0x1F + +/* syscfg bits */ +#define PCIE_SYS_INT BIT(5) +#define PCIE_APP_REQ_RETRY_EN BIT(3) +#define PCIE_APP_LTSSM_ENABLE BIT(2) +#define PCIE_APP_INIT_RST BIT(1) +#define PCIE_DEVICE_TYPE BIT(0)
[PATCH v4 4/4] MAINTAINERS: Add pci-st.c to ARCH/STI architecture
This patch adds the pci-st.c pci driver found on STMicroelectronics SoC's into the STI arch section of the maintainers file. Signed-off-by: Gabriel Fernandez gabriel.fernan...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8133cef..af5034f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1506,6 +1506,7 @@ F:drivers/clocksource/arm_global_timer.c F: drivers/i2c/busses/i2c-st.c F: drivers/media/rc/st_rc.c F: drivers/mmc/host/sdhci-st.c +F: drivers/pci/host/pci-st.c F: drivers/phy/phy-miphy28lp.c F: drivers/phy/phy-miphy365x.c F: drivers/phy/phy-stih407-usb.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
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri wrote: Hi, On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen peter.c...@freescale.com wrote: On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: Hi, On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan nathan.sulli...@ni.com wrote: The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag, unlike the default platform data. Add platform data specific to the Zynq udc. Based on a patch by the same name from the Xilinx vendor tree. I am that Xilinx guy who sent this patch :). It is in Xilinx tree as temporary fix and I did not debug further why UDC works only when streaming is enabled. Probably this is right time to post my question here. I was expecting like: Streaming disabled - both low bandwidth and high bandwidth systems should work fine Streaming enabled - only for high bandwidth systems but this is not the case, Zynq UDC works only when Streaming is enabled. Please correct me if I am wrong. You are right, stream mode disabled should work at anytime. It is so strange why zynq UDC only works when stream mode is enabled. I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc 2.20a, this is what it says about SDIS (streaming mode disable option) Before activating this mode, the user must check if the TX latency buffers per endpoint are able to accommodate at least one entire maximum size packet. The RX buffer size must, at least, double the TX buffer size per endpoint. To optimize the stream disable performance, system bus burst must be set as high as possible. When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a integer sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the controller will not work properly in stream disable mode. The stream disable mode should just be used in situations where the available system bandwidth is low or the system bus access latency is high, in order to avoid underruns and overruns in the latency buffers. This works for all types of endpoints, except for ISO endpoints. Such a system can't ensure the real time support that the ISO endpoints require, so the ISO endpoints are not supported when the SDIS bit is set. Definitely we need to root cause why disable streaming mode is not working for zynq but from controller spec point of view it is possible that controller not work properly in stream disable mode. Regards, Punnaiah Maybe the burst size isn't set correctly by default? It does say the controller won't work correctly with stream disable set and an invalid burst size. Looks like TX and RX burst both default to 16, per the Zynq manual. With the stream disable bit set, the behvior we see on our hardware is that priming just stops, with an outstanding transfer in memory marked active in the status field by the controller. This happens at random, even when doing single transfers at a time like with g_ether set to have a queue size of 1. With SDIS clear everything works great. Given that the Zynq is not bandwidth constrained, it seems like SDIS clear should be the default. Peter -- 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/5] [media] c8sectpfe: Update binding to reset-gpios
gpio.txt documents that GPIO properties should be named
[name-]gpios, with name being the purpose of this
GPIO for the device.
This change has been done as one atomic commit.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt | 6 +++---
arch/arm/boot/dts/stihxxx-b2120.dtsi | 4 ++--
drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
index d4def76..e70d840 100644
--- a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
+++ b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
@@ -35,7 +35,7 @@ Required properties (tsin (child) node):
- tsin-num : tsin id of the InputBlock (must be between 0 to 6)
- i2c-bus : phandle to the I2C bus DT node which the demodulators
tuners on this tsin channel are connected.
-- rst-gpio : reset gpio for this tsin channel.
+- reset-gpios : reset gpio for this tsin channel.
Optional properties (tsin (child) node):
@@ -75,7 +75,7 @@ Example:
tsin-num= 0;
serial-not-parallel;
i2c-bus = ssc2;
- rst-gpio= pio15 4 0;
+ reset-gpios = pio15 4 GPIO_ACTIVE_HIGH;
dvb-card= STV0367_TDA18212_NIMA_1;
};
@@ -83,7 +83,7 @@ Example:
tsin-num= 3;
serial-not-parallel;
i2c-bus = ssc3;
- rst-gpio= pio15 7 0;
+ reset-gpios = pio15 7 GPIO_ACTIVE_HIGH;
dvb-card= STV0367_TDA18212_NIMB_1;
};
};
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index c014173..f932bfd 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -6,8 +6,8 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-
#include dt-bindings/clock/stih407-clks.h
+#include dt-bindings/gpio/gpio.h
#include dt-bindings/media/c8sectpfe.h
/ {
soc {
@@ -115,7 +115,7 @@
tsin-num= 0;
serial-not-parallel;
i2c-bus = ssc2;
- rst-gpio= pio15 4 0;
+ reset-gpios = pio15 4 GPIO_ACTIVE_HIGH;
dvb-card= STV0367_TDA18212_NIMA_1;
};
};
diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
index 3a91093..c691e13 100644
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -822,7 +822,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
}
of_node_put(i2c_bus);
- tsin-rst_gpio = of_get_named_gpio(child, rst-gpio, 0);
+ tsin-rst_gpio = of_get_named_gpio(child, reset-gpios, 0);
ret = gpio_is_valid(tsin-rst_gpio);
if (!ret) {
--
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/5] ARM: DT: STi: STiH407: Add c8sectpfe LinuxDVB DT node.
This patch adds in the required DT node for the c8sectpfe
Linux DVB demux driver which allows the tsin channels
to be used on an upstream kernel.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
arch/arm/boot/dts/stihxxx-b2120.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 62994ae..c014173 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -6,6 +6,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
+#include dt-bindings/clock/stih407-clks.h
+#include dt-bindings/media/c8sectpfe.h
/ {
soc {
sbc_serial0: serial@953 {
@@ -85,5 +88,36 @@
status = okay;
};
+ demux@08a2 {
+ compatible = st,stih407-c8sectpfe;
+ status = okay;
+ reg = 0x08a2 0x1,
+ 0x08a0 0x4000;
+ reg-names = c8sectpfe, c8sectpfe-ram;
+ interrupts = GIC_SPI 34 IRQ_TYPE_NONE,
+ GIC_SPI 35 IRQ_TYPE_NONE;
+ interrupt-names = c8sectpfe-error-irq,
+ c8sectpfe-idle-irq;
+ pinctrl-names = tsin0-serial,
+ tsin0-parallel,
+ tsin3-serial,
+ tsin4-serial,
+ tsin5-serial;
+ pinctrl-0 = pinctrl_tsin0_serial;
+ pinctrl-1 = pinctrl_tsin0_parallel;
+ pinctrl-2 = pinctrl_tsin3_serial;
+ pinctrl-3 = pinctrl_tsin4_serial_alt3;
+ pinctrl-4 = pinctrl_tsin5_serial_alt1;
+ clock-names = c8sectpfe;
+ clocks = clk_s_c0_flexgen CLK_PROC_STFE;
+ /* tsin0 is TSA on NIMA */
+ tsin0: port@0 {
+ tsin-num= 0;
+ serial-not-parallel;
+ i2c-bus = ssc2;
+ rst-gpio= pio15 4 0;
+ dvb-card= STV0367_TDA18212_NIMA_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 v2 1/5] ARM: DT: STi: stihxxx-b2120: Add pulse-width properties to ssc2 ssc3
Adding these properties makes the I2C bus to the demodulators much
more reliable, and we no longer suffer from I2C errors when tuning.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
arch/arm/boot/dts/stihxxx-b2120.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index f589fe4..62994ae 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -27,12 +27,18 @@
};
};
- i2c@9842000 {
+ ssc2: i2c@9842000 {
status = okay;
+ clock-frequency = 10;
+ st,i2c-min-scl-pulse-width-us = 0;
+ st,i2c-min-sda-pulse-width-us = 5;
};
- i2c@9843000 {
+ ssc3: i2c@9843000 {
status = okay;
+ clock-frequency = 10;
+ st,i2c-min-scl-pulse-width-us = 0;
+ st,i2c-min-sda-pulse-width-us = 5;
};
i2c@9844000 {
--
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: Re: [v4,1/6] mmc: dt: add DT binding for big endian controller
On 27 August 2015 at 15:34, Ulf Hansson ulf.hans...@linaro.org wrote:
[...]
What I had in mind is replacing in_be32() with a esdhc_ops-readl() in this
function. And the esdhc_ops-readl() would be assigned at the beginning
according endian.
static u32 esdhc_readl(struct sdhci_host *host, int reg)
{
u32 ret;
ret = in_be32(host-ioaddr + reg);
/*
* The bit of ADMA flag in eSDHC is not compatible with standard
* SDHC register, so set fake flag SDHCI_CAN_DO_ADMA2 when ADMA is
* supported by eSDHC.
* And for many FSL eSDHC controller, the reset value of field
* SDHCI_CAN_DO_ADMA1 is one, but some of them can't support ADMA,
* only these vendor version is greater than 2.2/0x12 support ADMA.
* For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
* the verdor version number, oxFE is SDHCI_HOST_VERSION.
*/
if ((reg == SDHCI_CAPABILITIES) (ret SDHCI_CAN_DO_ADMA1)) {
u32 tmp = in_be32(host-ioaddr + SDHCI_SLOT_INT_STATUS);
tmp = (tmp SDHCI_VENDOR_VER_MASK)
SDHCI_VENDOR_VER_SHIFT;
if (tmp VENDOR_V_22)
ret |= SDHCI_CAN_DO_ADMA2;
}
return ret;
}
The LE and BE accessors could be defined in sdhci-esdhc.h for
esdhc_ops-readl() as below.
static u32 esdhc_be32bs_readl(struct sdhci_host *host, int reg)
{
return ioread32be(host-ioaddr + reg);
}
static u32 esdhc_le32bs_readl(struct sdhci_host *host, int reg)
{
return ioread32(host-ioaddr + reg);
}
Do you think it is ok for you?
It becomes a bit hacky, but currently I can't think of a better solution.
Or Maybe there is another method, use conditional compilation. The previous
method would delete the MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER to use
accessors defined in sdhci-esdhc.h, and add dependency of ARM. This method
could use 'select accessors if ARCH' to compile LE or BE accessors
according ARCH.
I don't really follow your suggestion.
Isn't the problem that you need the
MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER for configurations and for
some you don't? More precisely, for those where you don't you would
rather just use the regulator ioread* functions since those will
/s/regulator/regular
internally deal with the endianess in runtime?
If you can make these decisions at compile time an depending of the
ARCH - I believe I would be fine with that as well.
[...]
Kind regards
Uffe
--
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: Re: [v4,1/6] mmc: dt: add DT binding for big endian controller
[...]
What I had in mind is replacing in_be32() with a esdhc_ops-readl() in this
function. And the esdhc_ops-readl() would be assigned at the beginning
according endian.
static u32 esdhc_readl(struct sdhci_host *host, int reg)
{
u32 ret;
ret = in_be32(host-ioaddr + reg);
/*
* The bit of ADMA flag in eSDHC is not compatible with standard
* SDHC register, so set fake flag SDHCI_CAN_DO_ADMA2 when ADMA is
* supported by eSDHC.
* And for many FSL eSDHC controller, the reset value of field
* SDHCI_CAN_DO_ADMA1 is one, but some of them can't support ADMA,
* only these vendor version is greater than 2.2/0x12 support ADMA.
* For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
* the verdor version number, oxFE is SDHCI_HOST_VERSION.
*/
if ((reg == SDHCI_CAPABILITIES) (ret SDHCI_CAN_DO_ADMA1)) {
u32 tmp = in_be32(host-ioaddr + SDHCI_SLOT_INT_STATUS);
tmp = (tmp SDHCI_VENDOR_VER_MASK) SDHCI_VENDOR_VER_SHIFT;
if (tmp VENDOR_V_22)
ret |= SDHCI_CAN_DO_ADMA2;
}
return ret;
}
The LE and BE accessors could be defined in sdhci-esdhc.h for
esdhc_ops-readl() as below.
static u32 esdhc_be32bs_readl(struct sdhci_host *host, int reg)
{
return ioread32be(host-ioaddr + reg);
}
static u32 esdhc_le32bs_readl(struct sdhci_host *host, int reg)
{
return ioread32(host-ioaddr + reg);
}
Do you think it is ok for you?
It becomes a bit hacky, but currently I can't think of a better solution.
Or Maybe there is another method, use conditional compilation. The previous
method would delete the MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER to use
accessors defined in sdhci-esdhc.h, and add dependency of ARM. This method
could use 'select accessors if ARCH' to compile LE or BE accessors
according ARCH.
I don't really follow your suggestion.
Isn't the problem that you need the
MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER for configurations and for
some you don't? More precisely, for those where you don't you would
rather just use the regulator ioread* functions since those will
internally deal with the endianess in runtime?
If you can make these decisions at compile time an depending of the
ARCH - I believe I would be fine with that as well.
[...]
Kind regards
Uffe
--
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] spi: mediatek: fix SPI_CMD_PAUSE_IE macro error
enable pause interrupt should use SPI_CMD_PAUSE_IE MACRO, so fix it. Signed-off-by: Leilk Liu leilk@mediatek.com --- drivers/spi/spi-mt65xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c index eaadc7e..d882261 100644 --- a/drivers/spi/spi-mt65xx.c +++ b/drivers/spi/spi-mt65xx.c @@ -158,7 +158,7 @@ static void mtk_spi_config(struct mtk_spi *mdata, #endif /* set finish and pause interrupt always enable */ - reg_val |= SPI_CMD_FINISH_IE | SPI_CMD_PAUSE_EN; + reg_val |= SPI_CMD_FINISH_IE | SPI_CMD_PAUSE_IE; /* disable dma mode */ reg_val = ~(SPI_CMD_TX_DMA | SPI_CMD_RX_DMA); -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c
On 08/27/2015 08:28 PM, Hanjun Guo wrote:
On 08/27/2015 08:08 PM, Thomas Gleixner wrote:
On Thu, 27 Aug 2015, Hanjun Guo wrote:
On 08/26/2015 03:17 AM, Thomas Gleixner wrote:
On Wed, 26 Aug 2015, Fu Wei wrote:
/* Initialize per-processor generic timer */
-static int __init arch_timer_acpi_init(struct acpi_table_header
*table)
+void __init arch_timer_acpi_init(void)
{
And how is that supposed to work when we have next generation CPUs
which implement a different timer? You break multisystem kernels that
way.
Sorry, I think I missed some context here that I don't understand
why the code here will break multisystem kernels? I'm trying to
understand the problem here and update the code :)
yes, you are right, If there is a next generation CPUs which
implement a different timer, (maybe) this driver can not work.
we may need a new timer driver.
But,
(1) for now, aarch64 core always has the arch timer(this timer is
part of aarch64 architecture).
and the existing code make ARM64 kernel select ARM_ARCH_TIMER
(2) GTDT is designed for generic timer, so in this call
arch_timer_acpi_init we parse the gtdt info.
(3) once we have a ARM64 CPUs which implement a different timer, we
may need to select a right timer in the config stage.
and this timer may not be described in GTDT. So we can implement
another arch_timer_acpi_init by that time in new timer driver..
if the new time still uses GTDT(or new version GTDT), we may need to
update gtdt.c for new timer by that time.
That's simply wrong. You want to build kernels which run on both cpus
and the selection of the timer happens at runtime depending on the
ACPI info. We do the same thing with device tree.
I think the code can do that if I understand correctly. The code for
now is that we only support arch timer on ARM64, and this patch set
is adding SBSA watchdog timer support which need same function in
arch timer, so we move that function to common place.
We will load the driver (arch timer, memory mapped timer) when the
ACPI table defines them, which when new timer is coming, that will
defined in the ACPI table and load the driver as needed.
Please correct me if I misse something, thanks.
arch_timer_acpi_init() is called from the architecture boot code. So
how is that supposed to work with different timers?
Are you going to have bla_timer_acpi_init() and foo_timer_acpi_init()
calls as well?
Why not having a something like DT has: DECLARE_
and the arch_timer_acpi_init() using that to figure out which of the
timers to initialize.
Ah, ok, I can fully understand you now, thanks for your patience.
Yes, I agree with you, so this is not a problem for this patch, but
for the code implementation of previous code. Actually we are on the
road to do as you suggested, we introduced something like
#define ACPI_DECLARE(table, name, table_id, subtable, data, fn) [1]
in the GICv3 and GIC self probe patch set, and I said that
infrastructure can be used as clock declare too, we just trying
to not add such dependence on that patch set (it's still on discussion),
[1]: https://lkml.org/lkml/2015/7/29/236
If that is ok with you, we will introduce similar DECLARE_ thing
for clock declare.
Or we can drop this patch from this patch set, and clean up this
patch when the ACPI_DECLARE() infrastructure is ready for upstream.
Thanks
Hanjun
--
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] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
Currently vmmc's property is wrong.
If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
(Card supply power and I/O Line supply Power.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ca7d168..4ddabfd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -461,10 +461,10 @@
mshc_0 {
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
- vmmc-supply = ldo20_reg buck8_reg;
+ vmmc-supply = ldo20_reg;
+ vqmmc-supply = buck8_reg;
Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
so it should be VQMMC?
In the same time I can't find on schematics where BUCK8 goes...
The SDHCI_2 node below looks good.
Best regards,
Krzysztof
mmc-pwrseq = emmc_pwrseq;
status = okay;
-
num-slots = 1;
broken-cd;
card-detect-delay = 200;
@@ -485,7 +485,8 @@
bus-width = 4;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
pinctrl-names = default;
- vmmc-supply = ldo4_reg ldo21_reg;
+ vmmc-supply = ldo21_reg;
+ vqmmc-supply = ldo4_reg;
cd-gpios = gpk2 2 0;
cd-inverted;
status = okay;
--
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 v8 3/6] PCI: designware: Add ARM64 support
Hi Zhou,
You can add my Tested-by: Gabriel Fernandez gabriel.fernan...@st.com
I tested your patchset with a STMicroelectronics PCIe controller.
This controller is based on designware PCIe driver and works on ARM32.
Please find my patchset here:
http://www.spinics.net/lists/kernel/msg2064266.html
Best Regards.
Gabriel.
On 25 August 2015 at 11:58, Zhou Wang wangzh...@hisilicon.com wrote:
This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
move related operations to dw_pcie_host_init.
This patch also try to use of_pci_get_host_bridge_resources for ARM32 and
ARM64
according to the suggestion for Gabriele[1]
Finally this patch reverts commit f4c55c5a3f7f PCI: designware: Program ATU
with untranslated address based on 1/6 in this series. we delete *_mod_base
in
pcie-designware. This was discussed in [2]
I have compiled the driver with multi_v7_defconfig. However, I don't have
ARM32 PCIe related board to do test. It will be appreciated if someone could
help to test it.
Signed-off-by: Zhou Wang wangzh...@hisilicon.com
Signed-off-by: Gabriele Paoloni gabriele.paol...@huawei.com
Signed-off-by: Arnd Bergmann a...@arndb.de
Tested-By: James Morse james.mo...@arm.com
[1] http://www.spinics.net/lists/linux-pci/msg42194.html
[2] http://www.spinics.net/lists/arm-kernel/msg436779.html
---
drivers/pci/host/pci-dra7xx.c | 14 +--
drivers/pci/host/pci-keystone-dw.c | 2 +-
drivers/pci/host/pcie-designware.c | 230
+
drivers/pci/host/pcie-designware.h | 14 +--
4 files changed, 90 insertions(+), 170 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 18ae7ff..ac401be 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
{
dw_pcie_setup_rc(pp);
- if (pp-io_mod_base)
- pp-io_mod_base = CPU_TO_BUS_ADDR;
+ if (pp-io_base)
+ pp-io_base = CPU_TO_BUS_ADDR;
- if (pp-mem_mod_base)
- pp-mem_mod_base = CPU_TO_BUS_ADDR;
+ if (pp-mem_base)
+ pp-mem_base = CPU_TO_BUS_ADDR;
- if (pp-cfg0_mod_base) {
- pp-cfg0_mod_base = CPU_TO_BUS_ADDR;
- pp-cfg1_mod_base = CPU_TO_BUS_ADDR;
+ if (pp-cfg0_base) {
+ pp-cfg0_base = CPU_TO_BUS_ADDR;
+ pp-cfg1_base = CPU_TO_BUS_ADDR;
}
dra7xx_pcie_establish_link(pp);
diff --git a/drivers/pci/host/pci-keystone-dw.c
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..b1e4135 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem
*reg_virt)
void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
{
struct pcie_port *pp = ks_pcie-pp;
- u32 start = pp-mem.start, end = pp-mem.end;
+ u32 start = pp-mem-start, end = pp-mem-end;
int i, tr_size;
/* Disable BARs for inbound access */
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index c5d407c..e2d1898 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -11,6 +11,7 @@
* published by the Free Software Foundation.
*/
+#include linux/hardirq.h
#include linux/irq.h
#include linux/irqdomain.h
#include linux/kernel.h
@@ -69,16 +70,7 @@
#define PCIE_ATU_FUNC(x) (((x) 0x7) 16)
#define PCIE_ATU_UPPER_TARGET 0x91C
-static struct hw_pci dw_pci;
-
-static unsigned long global_io_offset;
-
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
- BUG_ON(!sys-private_data);
-
- return sys-private_data;
-}
+static struct pci_ops dw_pcie_ops;
int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
{
@@ -255,7 +247,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int
irq)
static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
{
int irq, pos0, i;
- struct pcie_port *pp = sys_to_pcie(desc-dev-bus-sysdata);
+ struct pcie_port *pp = desc-dev-bus-sysdata;
pos0 = bitmap_find_free_region(pp-msi_irq_in_use, MAX_MSI_IRQS,
order_base_2(no_irqs));
@@ -298,7 +290,7 @@ static int dw_msi_setup_irq(struct msi_controller *chip,
struct pci_dev *pdev,
{
int irq, pos;
struct msi_msg msg;
- struct pcie_port *pp = sys_to_pcie(pdev-bus-sysdata);
+ struct pcie_port *pp = pdev-bus-sysdata;
if (desc-msi_attrib.is_msix)
return -EINVAL;
@@ -327,7 +319,7 @@ static void dw_msi_teardown_irq(struct msi_controller
*chip, unsigned int irq)
{
struct irq_data *data =
Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c
On 08/27/2015 08:08 PM, Thomas Gleixner wrote:
On Thu, 27 Aug 2015, Hanjun Guo wrote:
On 08/26/2015 03:17 AM, Thomas Gleixner wrote:
On Wed, 26 Aug 2015, Fu Wei wrote:
/* Initialize per-processor generic timer */
-static int __init arch_timer_acpi_init(struct acpi_table_header
*table)
+void __init arch_timer_acpi_init(void)
{
And how is that supposed to work when we have next generation CPUs
which implement a different timer? You break multisystem kernels that
way.
Sorry, I think I missed some context here that I don't understand
why the code here will break multisystem kernels? I'm trying to
understand the problem here and update the code :)
yes, you are right, If there is a next generation CPUs which
implement a different timer, (maybe) this driver can not work.
we may need a new timer driver.
But,
(1) for now, aarch64 core always has the arch timer(this timer is
part of aarch64 architecture).
and the existing code make ARM64 kernel select ARM_ARCH_TIMER
(2) GTDT is designed for generic timer, so in this call
arch_timer_acpi_init we parse the gtdt info.
(3) once we have a ARM64 CPUs which implement a different timer, we
may need to select a right timer in the config stage.
and this timer may not be described in GTDT. So we can implement
another arch_timer_acpi_init by that time in new timer driver..
if the new time still uses GTDT(or new version GTDT), we may need to
update gtdt.c for new timer by that time.
That's simply wrong. You want to build kernels which run on both cpus
and the selection of the timer happens at runtime depending on the
ACPI info. We do the same thing with device tree.
I think the code can do that if I understand correctly. The code for
now is that we only support arch timer on ARM64, and this patch set
is adding SBSA watchdog timer support which need same function in
arch timer, so we move that function to common place.
We will load the driver (arch timer, memory mapped timer) when the
ACPI table defines them, which when new timer is coming, that will
defined in the ACPI table and load the driver as needed.
Please correct me if I misse something, thanks.
arch_timer_acpi_init() is called from the architecture boot code. So
how is that supposed to work with different timers?
Are you going to have bla_timer_acpi_init() and foo_timer_acpi_init()
calls as well?
Why not having a something like DT has: DECLARE_
and the arch_timer_acpi_init() using that to figure out which of the
timers to initialize.
Ah, ok, I can fully understand you now, thanks for your patience.
Yes, I agree with you, so this is not a problem for this patch, but
for the code implementation of previous code. Actually we are on the
road to do as you suggested, we introduced something like
#define ACPI_DECLARE(table, name, table_id, subtable, data, fn) [1]
in the GICv3 and GIC self probe patch set, and I said that
infrastructure can be used as clock declare too, we just trying
to not add such dependence on that patch set (it's still on discussion),
[1]: https://lkml.org/lkml/2015/7/29/236
If that is ok with you, we will introduce similar DECLARE_ thing
for clock declare.
Thanks
Hanjun
--
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/5] [media] c8sectpfe: Various fixups
Hi Mauro, This series includes a couple of fixes for the c8sectpfe Linux dvb driver. One was caused by omitting a patch from the original c8sectpfe series which defined the ssc2 and ssc3 dt nodes, which was then used by the later DT patch. This patch is included, along with the original patch which you reverted. Also Valentin Rothberg spotted LIBELF32 Kconfig symbol I was selecting in the Kconfig, this isn't required upstream and is left over legacy so I've removed it. Sorry for the delay in sending these fixes, I've been on holiday for the last 3 weeks. Changes since v1: - Various formating patches to DT node - Update to reset-gpios - Use GPIO_ACTIVE_HIGH, GIC_SPI and IRQ_TYPE_NONE defines kind regards, Peter. Peter Griffin (5): ARM: DT: STi: stihxxx-b2120: Add pulse-width properties to ssc2 ssc3 ARM: DT: STi: STiH407: Add c8sectpfe LinuxDVB DT node. [media] c8sectpfe: Remove select on undefined LIBELF_32 [media] c8sectpfe: Update binding to reset-gpios [media] c8sectpfe: Update DT binding doc with some minor fixes .../bindings/media/stih407-c8sectpfe.txt | 22 +-- arch/arm/boot/dts/stihxxx-b2120.dtsi | 44 +- drivers/media/platform/sti/c8sectpfe/Kconfig | 1 - .../media/platform/sti/c8sectpfe/c8sectpfe-core.c | 2 +- 4 files changed, 53 insertions(+), 16 deletions(-) -- 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 v4 2/4] PCI: st: Add Device Tree bindings for sti pcie
sti pcie is built around a Synopsis Designware PCIe IP.
Signed-off-by: Fabrice Gasnier fabrice.gasn...@st.com
Signed-off-by: Gabriel Fernandez gabriel.fernan...@linaro.org
---
Documentation/devicetree/bindings/pci/st-pcie.txt | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/st-pcie.txt
b/Documentation/devicetree/bindings/pci/st-pcie.txt
new file mode 100644
index 000..25fcab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st-pcie.txt
@@ -0,0 +1,53 @@
+STMicroelectronics STi PCIe controller
+
+This PCIe host controller is based on the Synopsis Designware PCIe IP
+and thus inherits all the common properties defined in designware-pcie.txt.
+
+Required properties:
+ - compatible: st,stih407-pcie
+ - reg: base address and length of the pcie controller, mem-window address
+ and length available to the controller.
+ - interrupts: A list of interrupt outputs of the controller. Must contain an
+ entry for each entry in the interrupt-names property.
+ - interrupt-names: Should be msi. STi interrupt that is asserted when an
+ MSI is received.
+ - st,syscfg : should be a phandle of the syscfg node. Also contains syscfg
+ offset for IP configuration.
+ - resets, reset-names: the power-down and soft-reset lines of PCIe IP.
+ Associated names must be powerdown and softreset.
+ - phys, phy-names: the phandle for the PHY device.
+ Associated name must be pcie
+
+Optional properties:
+ - reset-gpio: a GPIO spec to define which pin is connected to the bus reset.
+
+Example:
+
+pcie0: pcie@9b0 {
+ compatible = st,pcie, snps,dw-pcie;
+ device_type = pci;
+ reg = 0x09b0 0x4000, /* dbi cntrl registers */
+ 0x2fff 0x0001, /* configuration space */
+ 0x4000 0x8000; /* lmi mem window */
+ reg-names = dbi, config, mem-window;
+ st,syscfg = syscfg_core 0xd8 0xe0;
+ #address-cells = 3;
+ #size-cells = 2;
+ ranges = 0x8200 0 0x2000 0x2000 0 0x0FFF; /*
non-prefetchable memory */
+ num-lanes = 1;
+ interrupts = GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-names = msi;
+ #interrupt-cells = 1;
+ interrupt-map-mask = 0 0 0 7;
+ interrupt-map = 0 0 0 1 intc GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH, /* INT
A */
+ 0 0 0 2 intc GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH, /* INT
B */
+ 0 0 0 3 intc GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH, /* INT
C */
+ 0 0 0 4 intc GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH; /* INT
D */
+
+ resets = powerdown STIH407_PCIE0_POWERDOWN,
+softreset STIH407_PCIE0_SOFTRESET;
+ reset-names = powerdown,
+ softreset;
+ phys = phy_port0 PHY_TYPE_PCIE;
+ phy-names = pcie;
+};
--
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 v4 1/4] ARM: STi: Kconfig update for PCIe support
Update Kconfig: - MIGHT_HAVE_PCI - PCI_DOMAINS Signed-off-by: Fabrice Gasnier fabrice.gasn...@st.com --- arch/arm/mach-sti/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index 125865d..5f99e93 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -9,6 +9,8 @@ menuconfig ARCH_STI select ARCH_HAS_RESET_CONTROLLER select HAVE_ARM_SCU if SMP select ARCH_REQUIRE_GPIOLIB + select PCI_DOMAINS if PCI + select MIGHT_HAVE_PCI select ARM_ERRATA_754322 select ARM_ERRATA_764369 if SMP select ARM_ERRATA_775420 -- 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/5] [media] c8sectpfe: Remove select on undefined LIBELF_32
LIBELF_32 is not defined in Kconfig, and is left over legacy which is not required in the upstream driver, so remove it. Signed-off-by: Peter Griffin peter.grif...@linaro.org Suggested-by: Valentin Rothberg valentinrothb...@gmail.com --- drivers/media/platform/sti/c8sectpfe/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/sti/c8sectpfe/Kconfig b/drivers/media/platform/sti/c8sectpfe/Kconfig index d1bfd4c..b9ec667 100644 --- a/drivers/media/platform/sti/c8sectpfe/Kconfig +++ b/drivers/media/platform/sti/c8sectpfe/Kconfig @@ -1,7 +1,6 @@ config DVB_C8SECTPFE tristate STMicroelectronics C8SECTPFE DVB support depends on DVB_CORE I2C (ARCH_STI || ARCH_MULTIPLATFORM) - select LIBELF_32 select FW_LOADER select FW_LOADER_USER_HELPER_FALLBACK select DEBUG_FS -- 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/5] [media] c8sectpfe: Update DT binding doc with some minor fixes
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
.../devicetree/bindings/media/stih407-c8sectpfe.txt | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
index e70d840..5d6438c 100644
--- a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
+++ b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
@@ -55,21 +55,20 @@ Example:
status = okay;
reg = 0x08a2 0x1, 0x08a0 0x4000;
reg-names = stfe, stfe-ram;
- interrupts = 0 34 0, 0 35 0;
+ interrupts = GIC_SPI 34 IRQ_TYPE_NONE, GIC_SPI 35
IRQ_TYPE_NONE;
interrupt-names = stfe-error-irq, stfe-idle-irq;
-
- pinctrl-names = tsin0-serial, tsin0-parallel,
tsin3-serial,
- tsin4-serial, tsin5-serial;
-
+ pinctrl-names = tsin0-serial,
+ tsin0-parallel,
+ tsin3-serial,
+ tsin4-serial,
+ tsin5-serial;
pinctrl-0 = pinctrl_tsin0_serial;
pinctrl-1 = pinctrl_tsin0_parallel;
pinctrl-2 = pinctrl_tsin3_serial;
pinctrl-3 = pinctrl_tsin4_serial_alt3;
pinctrl-4 = pinctrl_tsin5_serial_alt1;
-
clocks = clk_s_c0_flexgen CLK_PROC_STFE;
- clock-names = stfe;
-
+ clock-names = c8sectpfe;
/* tsin0 is TSA on NIMA */
tsin0: port@0 {
tsin-num= 0;
@@ -78,7 +77,6 @@ Example:
reset-gpios = pio15 4 GPIO_ACTIVE_HIGH;
dvb-card= STV0367_TDA18212_NIMA_1;
};
-
tsin3: port@3 {
tsin-num= 3;
serial-not-parallel;
--
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 v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c
Hi Thomas, Hanjun On 27 August 2015 at 21:40, Thomas Gleixner t...@linutronix.de wrote: On Thu, 27 Aug 2015, Hanjun Guo wrote: [1]: https://lkml.org/lkml/2015/7/29/236 If that is ok with you, we will introduce similar DECLARE_ thing for clock declare. Yes. Thanks Or we can drop this patch from this patch set, and clean up this patch when the ACPI_DECLARE() infrastructure is ready for upstream. Works either way. I just noticed that hard coded init thing and decided to rant about it :) OK, good idea, this patch will be improve by DECLARE_ thing, then upstream. drop this from this patchset. Great thanks for your help Thanks, tglx -- 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 -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- 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 0/4] PCI: st: provide support for dw pcie
This patchset is based on v4.2-rc1 and is based on [PATCH v8 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05 patchset from Zhou Wang. Changes in v4: - Remove pci: designware: remove my pci_common_init_dev() patch and use [PATCH v8 3/6] PCI: designware: Add ARM64 support instead. This patch is a good solution for me to disable IO support. - add __init to st_pcie_probe() and use module_init() instead device_initcall() to prevent the probe function from being deferred and to prevent module unloading. Changes in v3: - Remove power management functions (was not fully tested) - Remove configuration space range from dt binding - Remove pci_common_init_dev() call in pcie-designware.c to avoid default IO space declaration. Changes in v2: - comestic corrections in device tree binding - add pci-st.c into MAINTAINERS - remove st_pcie_ops structure to avoid another level of indirection - remove nasty busy-loop - remove useless test using virt_to_phys() - move disable io support into dw-pcie driver I don't change the st_pcie_abort_handler() function because abort handling is masked during boot. This patch-set introduces a STMicroelectronics PCIe controller. It's based on designware PCIe driver. Gabriel Fernandez (4): ARM: STi: Kconfig update for PCIe support PCI: st: Add Device Tree bindings for sti pcie PCI: st: Provide support for the sti PCIe controller MAINTAINERS: Add pci-st.c to ARCH/STI architecture Documentation/devicetree/bindings/pci/st-pcie.txt | 53 ++ MAINTAINERS | 1 + arch/arm/mach-sti/Kconfig | 2 + drivers/pci/host/Kconfig | 9 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pci-st.c | 583 ++ 6 files changed, 649 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt create mode 100644 drivers/pci/host/pci-st.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
Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c
On Thu, 27 Aug 2015, Hanjun Guo wrote: [1]: https://lkml.org/lkml/2015/7/29/236 If that is ok with you, we will introduce similar DECLARE_ thing for clock declare. Yes. Or we can drop this patch from this patch set, and clean up this patch when the ACPI_DECLARE() infrastructure is ready for upstream. Works either way. I just noticed that hard coded init thing and decided to rant about it :) Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/8] scsi: ufs: make the UFS variant a platform device
On Sun, Aug 23, 2015 at 8:09 AM, Yaniv Gardi yga...@codeaurora.org wrote: This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS a platform device. In order to do so a few additional changes are required: 1. The ufshcd-pltfrm is no longer serves as a platform device. Now it only serves as a group of platform APIs such as PM APIs (runtime suspend/resume, system suspend/resume etc), parsers of clocks, regulators and pm_levels from DT. 2. What used to be the old platform probe is now only a pltfrm_init() routine, that does exactly the same, but only being called by the new probe function of the UFS variant. Signed-off-by: Yaniv Gardi yga...@codeaurora.org --- .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 +- drivers/scsi/ufs/ufs-qcom.c| 78 +- drivers/scsi/ufs/ufshcd-pltfrm.c | 92 ++ drivers/scsi/ufs/ufshcd-pltfrm.h | 41 ++ drivers/scsi/ufs/ufshcd.c | 10 +++ drivers/scsi/ufs/ufshcd.h | 1 + 6 files changed, 152 insertions(+), 72 deletions(-) create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 5357919..b39e765 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -4,7 +4,7 @@ UFSHC nodes are defined to describe on-chip UFS host controllers. Each UFS controller instance should have its own node. Required properties: -- compatible: compatible list, contains jedec,ufs-1.1 +- compatible: compatible list, contains jedec,ufs-1.1 or qcom,ufshc Replying again as I inadvertently dropped everyone. This should also have a more specific compatible string with the SOC name/number in it. It may be the same in all SOCs, but there is always the possibility for bugs/limitations to be found that are specific to an SOC even if all RTL versions are identical (e.g. different max clock speeds). It is about making the dtb future proof, not about what exactly you need today. You can keep qcom,ufshc for driver matching if you want. - interrupts: interrupt mapping for UFS host controller IRQ - reg : registers mapping What about phy properties? No Unipro PHY block that requires setup? 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 V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi,
On 08/21/2015 02:20 AM, Marek Vasut wrote:
From: Graham Moore grmo...@opensource.altera.com
Add binding document for the Cadence QSPI controller.
Signed-off-by: Graham Moore grmo...@opensource.altera.com
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Alan Tull at...@opensource.altera.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Graham Moore grmo...@opensource.altera.com
Cc: Vikas MANOCHA vikas.mano...@st.com
Cc: Yves Vandervennet yvand...@opensource.altera.com
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 56
++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property is-decoded-cs instead of creating a
duplicate, ext-decoder. Timing parameters are in nanoseconds,
not master reference clocks. Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
V7: - Prefix all of the Cadence-specific properties with cdns prefix,
those are in particular cdns,is-decoded-cs, cdns,fifo-depth,
cdns,fifo-width, cdns,trigger-address.
- Drop bogus properties which were not used and were incorrect.
V8: Align lines to 80 chars.
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
new file mode 100644
index 000..f248056
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -0,0 +1,56 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be cdns,qspi-nor.
+- reg : Contains two entries, each of which is a tuple consisting of a
+ physical address and length. The first entry is the address and
+ length of the controller register set. The second entry is the
+ address and length of the QSPI Controller data area.
still hooked up with Controller data area, it is ambiguous.
Use something which is more clear: Nor Flash memory mapped address.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- cdns,fifo-depth : Size of the data FIFO in words.
+- cdns,fifo-width : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+
+Optional properties:
again, is it optional ? can the driver be used without these properties ?
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
again, add info what the decoder is for ?
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with
additional
+custom properties:
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
+ mode chip select outputs are de-asserted between
+ transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
+ de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
+ transaction and deasserting the device chip select
+ (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
+ and first bit transfer.
+
+Example:
+
+ qspi: spi@ff705000 {
+ compatible = cdns,qspi-nor;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0xff705000 0x1000,
+ 0xffa0 0x1000;
+ interrupts = 0 151 4;
+ clocks = qspi_clk;
+ cdns,is-decoded-cs;
flag value ?
Cheers,
Vikas
+ cdns,fifo-depth = 128;
+ cdns,fifo-width = 4;
+ cdns,trigger-address = 0x;
+
+ flash0: n25q00@0 {
+ ...
+ cdns,read-delay = 4;
+ cdns,tshsl-ns = 50;
+ cdns,tsd2d-ns = 50;
+ cdns,tchsh-ns = 4;
+ cdns,tslch-ns = 4;
+ };
+ };
--
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 V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
On Thursday, August 27, 2015 at 07:44:34 PM, vikas wrote:
Hi,
On 08/21/2015 02:20 AM, Marek Vasut wrote:
From: Graham Moore grmo...@opensource.altera.com
Add binding document for the Cadence QSPI controller.
Signed-off-by: Graham Moore grmo...@opensource.altera.com
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Alan Tull at...@opensource.altera.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Graham Moore grmo...@opensource.altera.com
Cc: Vikas MANOCHA vikas.mano...@st.com
Cc: Yves Vandervennet yvand...@opensource.altera.com
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 56
++ 1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property is-decoded-cs instead of creating a
duplicate, ext-decoder. Timing parameters are in nanoseconds,
not master reference clocks. Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
V7: - Prefix all of the Cadence-specific properties with cdns prefix,
those are in particular cdns,is-decoded-cs, cdns,fifo-depth,
cdns,fifo-width, cdns,trigger-address.
- Drop bogus properties which were not used and were incorrect.
V8: Align lines to 80 chars.
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt new file
mode 100644
index 000..f248056
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -0,0 +1,56 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be cdns,qspi-nor.
+- reg : Contains two entries, each of which is a tuple consisting of a
+ physical address and length. The first entry is the address and
+ length of the controller register set. The second entry is the
+ address and length of the QSPI Controller data area.
still hooked up with Controller data area, it is ambiguous.
Use something which is more clear: Nor Flash memory mapped address.
I have to disagree, I will call it whatever it is called in the datasheet
and it is called controller data area.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- cdns,fifo-depth : Size of the data FIFO in words.
+- cdns,fifo-width : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+
+Optional properties:
again, is it optional ? can the driver be used without these properties ?
Why wouldn't it be possible to use the driver with no SPI NOR attached to
it? It's a cornercase, but still a valid one.
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
again, add info what the decoder is for ?
This is something Graham has to clarify. Based on the code (I'm sure you did
check the code), it's a 4:16 demuxer.
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with
additional +custom properties:
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
+ mode chip select outputs are de-asserted between
+ transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
+ de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
+ transaction and deasserting the device chip select
+ (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
+ and first bit transfer.
+
+Example:
+
+ qspi: spi@ff705000 {
+ compatible = cdns,qspi-nor;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0xff705000 0x1000,
+ 0xffa0 0x1000;
+ interrupts = 0 151 4;
+ clocks = qspi_clk;
+ cdns,is-decoded-cs;
flag value ?
Sorry, I don't quite understand the question. If you mean why there is no
value, it's because this is a boolean OF node, which just does't need to
have a value ; it's either present or not.
Best regards,
Marek Vasut
--
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 v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
On Wed, Aug 26, 2015 at 06:10:05PM -0700, Stefan Agner wrote:
On 2015-08-25 13:34, Brian Norris wrote:
One more thing...
On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,645 @@
...
+struct vf610_nfc {
+ struct mtd_info mtd;
+ struct nand_chip chip;
+ struct device *dev;
+ void __iomem *regs;
+ struct completion cmd_done;
+ uint buf_offset;
+ int page_sz;
AFAICT (even with the 2nd patch), you never really use this field. You
just set it/increment it, but don't use it for anything. Kill it?
It is used in the write path, I think I meant to use it for subpage
writes, when I thought it would just mean to transfer only parts of the
page to the controller.
Ah, you're right. Sorry, I missed that. I got mixed up seeing most of
your uses of 'page_sz' were for a local variable of the same name, not
this field.
However, as the subpage discussion basically concluded in not using it
for now on this controller, we can as well transfer the complete page
(page_sz). Or is there another case in which vf610_nfc_write_buf could
be called with less than page_sz?
I'll leave that up to you. I'm perfectly fine leaving it in, now that I
see its proper use. Just in case things change in the future, I think it
does help to clarify the flow of information a little. Although, I might
recommend a change in naming, since it could get confused with the
actual page size -- which is normally constant -- whereas this field
changes dynamically depending on the command-in-flight.
Perhaps the struct could have 'write_len' (to help represent an action)
and the local variable in vf610_nfc_command() could be 'tfr_len' (to
distinguish how it isn't necessarily identical to 'write_len')? Just
throwing (likely bad) ideas out there.
Regards,
Brian
--
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/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation
This documents a device tree binding for exposing the Qualcomm Shared
Memory State Machine as a set of gpio- and interrupt-controllers.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
.../devicetree/bindings/gpio/qcom,smsm.txt | 114 +
drivers/gpio/Kconfig | 8 ++
drivers/gpio/Makefile | 1 +
3 files changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt
diff --git a/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
new file mode 100644
index ..06201ba76594
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
@@ -0,0 +1,114 @@
+Qualcomm Shared Memory State Machine
+
+The Shared Memory State Machine facilitates broadcasting of single bit state
+information between the processors in a Qualcomm SoC. Each processor is
+assigned 32 bits of state that can be modified. A processor can through a
+matrix of bitmaps signal subscription of notifications upon changes to a
+certain bit owned by a certain remote processor.
+
+This document defines the binding for a driver that implements and exposes this
+a GPIO controller and a set of interrupt controllers.
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,smsm
+
+- qcom,ipc-N:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: three entries specifying the outgoing ipc bit used for
+ signaling the N:th remote processor
+ - phandle to a syscon node representing the apcs registers
+ - u32 representing offset to the register within the syscon
+ - u32 representing the ipc bit within the register
+
+- qcom,local-host:
+ Usage: optional
+ Value type: u32
+ Definition: identifier of the local processor in the list of hosts, or
+ in other words specifier of the column in the subscription
+ matrix representing the local processor
+ defaults to host 0
+
+- #address-cells:
+ Usage: required
+ Value type: u32
+ Definition: must be 1
+
+- #size-cells:
+ Usage: required
+ Value type: u32
+ Definition: must be 0
+
+= SUBNODES
+Each processor's state bits are described by a subnode of the smsm device node.
+A node can either be a gpio-controller - denoting the local processors bits -
+or an interrupt-controller - denoting a remote processors state bits. The node
+names are not important.
+
+- reg:
+ Usage: required
+ Value type: u32
+ Definition: specifies the offset, in words, of the first bit for this
+ entry
+
+- gpio-controller:
+ Usage: required for local entry
+ Value type: empty
+ Definition: marks the entry as a gpio-controller and the state bits to
+ belong to the local processor
+
+- #gpio-cells:
+ Usage: required for local entry
+ Value type: u32
+ Definition: must be 2 - denotes bit number and GPIO flags
+
+- interrupt-controller:
+ Usage: required for remote entries
+ Value type: empty
+ Definition: marks the entry as a interrupt-controller and the state bits
+ to belong to a remote processor
+
+- #interrupt-cells:
+ Usage: required for remote entries
+ Value type: u32
+ Definition: must be 2 - denotes bit number and IRQ flags
+
+- interrupts:
+ Usage: required for remote entries
+ Value type: prop-encoded-array
+ Definition: one entry specifying remote IRQ used by the remote processor
+ to signal changes of its state bits
+
+
+= EXAMPLE
+The following example shows the SMEM setup for controlling properties of the
+wireless processor, defined from the 8974 apps processor's point-of-view. It
+encompasses one outbound entry and the outgoing interrupt for the wireless
+processor.
+
+smsm {
+ compatible = qcom,smsm;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ qcom,ipc-3 = apcs 8 19;
+
+ apps_smsm: apps@0 {
+ reg = 0;
+
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ wcnss_smsm: wcnss@7 {
+ reg = 7;
+ interrupts = 0 144 1;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4d24c6..0e57b60faae8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -354,6 +354,14 @@ config GPIO_PXA
help
Say yes here to support the PXA GPIO device
+config GPIO_QCOM_SMSM
+ bool Qualcomm Shared Memory State Machine
+ depends on QCOM_SMEM
+ help
+ Say yes here to support the Qualcomm Shared Memory State Machine.
+
Re: [PATCH] ARM: dts: rockchip: Add support for SD/MMC on MarsBoard-RK3066
Am Montag, 24. August 2015, 19:21:53 schrieb Heiko Stuebner: Am Montag, 24. August 2015, 18:04:41 schrieb Romain Perier: This enables SDMMC0 on the board and gives a basic support for SD cards. Signed-off-by: Romain Perier romain.per...@gmail.com applied to my dts branch, after moving it above the pinctrl node just as notice, this moved down to linux-4.4 material -- 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 1/2] drm/layerscape: Add HDMI support for DCU DRM driver
On Wed, Aug 26, 2015 at 11:19 PM, Jianwei Wang
jianwei.wang@gmail.com wrote:
Some Freescale SoCs, there has an DVI/HDMI controller and a PHY,
attached to one of their display controller unit's LCDC interfaces.
This patch adds a driver for SiI902x. The SiI902x is a HDMI
transmitter It supports resolutions from standard definition
480i/p and 576i/p all the way to high-definition 720p, 1080i,
and 1080p, the highest resolution supported by HDTVs today.
Signed-off-by: Alison Wang b18...@freescale.com
Signed-off-by: Xiubo Li lixi...@cmss.chinamobile.com
Signed-off-by: Jianwei Wang jianwei.wang@gmail.com
---
.../devicetree/bindings/video/SiI902x.txt | 17 +
drivers/gpu/drm/fsl-dcu/Makefile | 1 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c | 639
+
This is a separate chip. It should not be part of the FSL DCU driver.
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 10 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h | 10 +
5 files changed, 677 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/SiI902x.txt
create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
diff --git a/Documentation/devicetree/bindings/video/SiI902x.txt
b/Documentation/devicetree/bindings/video/SiI902x.txt
new file mode 100644
index 000..d304499
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/SiI902x.txt
@@ -0,0 +1,17 @@
+Device-Tree bindings for the SiI902x hdmi transmitter.
+
+Required properties:
+- compatible: Should be sii902x.
This should have the vendor prefix sil. It should also be specific to
which chip number. There is already a binding for the 9022 in
vexpress-v2m.dtsi, so we should use the same binding although it is
not documented. I'm not too sure about the -tpi and -cpi parts of the
binding though. It appears the device has multiple i2c addresses which
is fairly common. I would not do multiple nodes like was done. If the
secondary addresses are known or programmable thru the primary
address, we can just hardcode them in the driver (ADV7511 is an
example). If we don't know the addresses, then we can just put
multiple addresses in the reg property.
Rob
+- reg: The I2C address of the device.
+- interrupts: Interrupt number to the cpu.
+
+Example:
+
+i2c1 {
+ status = okay;
+ hdmi: sii9022a@39 {
+ compatible = sii902x;
+ reg = 0x39;
+ interrupts = GIC_SPI 167 IRQ_TYPE_EDGE_RISING;
+ };
You should be using the OF graph to describe the connection to the DCU output.
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
[PATCH 0/4] Qualcomm Shared Memory State Machines
This series implements the two different mechanisms for propagating single bit state information, used on the various Qualcomm platforms. The system was traditionally used by the modem and application processor to convey information about boot progress, power states, error handling and so on. This was implemented as SMSM, with status bits representing a single local state. As the complexity of the SoC grew the state bits array grew and the need for targeting specific state information at specific remote processors appeared. SMP2P solves this by having separate shared memory regions per processor-pair. This state information is e.g. used to convey progress and status of remote firmware loading. Individual bits maps to various stages of the boot and error states. As some of these states on some platforms are passed as physical signals instead, the two drivers are modelled as gpio- and interrupt-controllers - providing a nice abstraction both in device tree sense and Linux implementation sense. Bjorn Andersson (4): dt-binding: gpio: Add Qualcomm SMSM device tree documentation gpio: qcom-smsm: Add driver for Qualcomm SMSM dt-binding: gpio: Introduce qcom,smp2p binding documentation gpio: qcom-smp2p: Qualcomm Shared Memory Point to Point .../devicetree/bindings/gpio/qcom,smp2p.txt| 112 .../devicetree/bindings/gpio/qcom,smsm.txt | 114 drivers/gpio/Kconfig | 15 + drivers/gpio/Makefile | 2 + drivers/gpio/gpio-qcom-smp2p.c | 601 drivers/gpio/gpio-qcom-smsm.c | 631 + 6 files changed, 1475 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smp2p.txt create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt create mode 100644 drivers/gpio/gpio-qcom-smp2p.c create mode 100644 drivers/gpio/gpio-qcom-smsm.c -- 1.8.2.2 -- 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 3/4] PCI: st: Provide support for the sti PCIe controller
Hi Gabriel,
Looks good to me.
On Thu, Aug 27, 2015 at 6:04 PM, Gabriel Fernandez
gabriel.fernan...@linaro.org wrote:
sti pcie is built around a Synopsis Designware PCIe IP.
Signed-off-by: Fabrice Gasnier fabrice.gasn...@st.com
Signed-off-by: Gabriel Fernandez gabriel.fernan...@linaro.org
+static int st_pcie_link_up(struct pcie_port *pp)
+{
+ u32 status;
+ int link_up;
nit: why not bool
+ int count = 0;
[...]
+static void st_pcie_board_reset(struct pcie_port *pp)
+{
+ struct st_pcie *pcie = to_st_pcie(pp);
+
+ if (!gpio_is_valid(pcie-reset_gpio))
+ return;
+
+ if (gpio_direction_output(pcie-reset_gpio, 0)) {
+ dev_err(pp-dev, Cannot set PERST# (gpio %u) to output\n,
+ pcie-reset_gpio);
+ return;
+ }
+
+ /* From PCIe spec */
+ msleep(2);
+ gpio_direction_output(pcie-reset_gpio, 1);
+
+ /*
+* PCIe specification states that you should not issue any config
+* requests until 100ms after asserting reset, so we enforce that here
+*/
+ msleep(100);
IIRC, specification says to wait after link training completes. So
shouldn't it be after st_pcie_enable_ltssm. Moreover, I wonder why
others do not need it.
Reviewed-by: Pratyush Anand pratyush.an...@gmail.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
Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
On 2015-08-27 09:34, Brian Norris wrote:
On Wed, Aug 26, 2015 at 06:02:31PM -0700, Stefan Agner wrote:
On 2015-08-25 13:16, Brian Norris wrote:
On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..5c8dfe8
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,645 @@
...
+/*
+ * This function supports Vybrid only (MPC5125 would have full RB and
four CS)
+ */
+static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
+{
+#ifdef CONFIG_SOC_VF610
Why the #ifdef? I don't see anything compile-time specific to SOC_VF610.
If this is trying to handle the comment above (This function supports
Vybrid only (MPC5125 would have full RB and four CS)) then that's the
wrong way of doing it, as you need to support multiplatform kernels.
You'll need to have a way to differentiate the different platform
support at runtime, not compile time.
Yes it is trying to handle the comment above. Well, the other two
platforms I am aware of are also different architectures... (PowerPC and
ColdFire). I think we won't have a multi-architecture kernel anytime
soon,
Ha, right. Sorry, I don't really know this particular IP.
hence I think removing the code at compile time is the right thing
todo.
I don't believe that conclusion follows though.
However, probably CONFIG_SOC_VF610 is the wrong symbol then, I could
just use CONFIG_ARM and add a comment that this might be different on
another other ARM SoC than VF610.
Just checked CodingStyle, and I see that IS_ENABLED is the preferred way
for conditional compiling.
So my suggestion:
static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
{
struct vf610_nfc *nfc = mtd_to_nfc(mtd);
u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
if (!IS_ENABLED(CONFIG_ARM))
return;
/*
* This code is only tested on the ARM platform VF610
* PowerPC based MPC5125 would have full RB and four CS
*/
With that the compiler should be able to remove this (currently) ARM
VF610 specific code on the other supported architectures...
What do you think?
The code structure isn't bad, and yes, IS_ENABLED() would be preferable,
as it removes some of the problems with #ifdef, but I still don't think
the processor architecture has much to do with the version of the IP.
Well yes, the processor architecture has probably not much to do with
the IP version.
However, that particular problem, the wiring up of the CS/RB signals, is
probably more SoC (as a whole) specific, and how that is done might have
some relation which architecture is in use...
I do not have a strong opinion on this, so we might as well go with the
run-time distinction using compatible. If there are different IP
variants within one architecture, we anyway would need to do that.
The canonical way of distiguishing per-IP revisions is to key on the
compatible property. So you'd have some kind of enum, which would
currently only have an entry for VF610. i.e.:
/* MPC5125 not yet supported */
if (nfc-revision != NAND_VFC610)
return;
Ok, just checked, I can use the data field of the of table to assign
specific data to a compatible string, similar to how pxa3xx_nand.c does
it.
--
Stefan
--
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/4] dt-binding: gpio: Introduce qcom,smp2p binding documentation
Introduce binding documentation for the Qualcomm Shared Memory Point 2 Point
protocol implemented as gpio and interrupt controllers.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
.../devicetree/bindings/gpio/qcom,smp2p.txt| 112 +
1 file changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
diff --git a/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
b/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
new file mode 100644
index ..532c7d3ce3d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
@@ -0,0 +1,112 @@
+Qualcomm Shared Memory Point 2 Point binding
+
+The Shared Memory Point to Point (SMP2P) protocol facilitates communication of
+a single 32-bit value between two processors. Each value has a single writer
+(the local side) and a single reader (the remote side). Values are uniquely
+identified in the system by the directed edge (local processor ID to remote
+processor ID) and a string identifier. This documents defines the binding for a
+driver that implements and exposes this protocol as a set of GPIO and interrupt
+controllers.
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,smp2p
+
+- interrupts:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: one entry specifying the smp2p notification interrupt
+
+- qcom,ipc:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: three entries specifying the outgoing ipc bit used for
+ signaling the remote end of the smp2p edge:
+ - phandle to a syscon node representing the apcs registers
+ - u32 representing offset to the register within the syscon
+ - u32 representing the ipc bit within the register
+
+- qcom,smem:
+ Usage: required
+ Value type: u32 array
+ Definition: two identifiers of the inbound and outbound smem items used
+ for this edge
+
+- qcom,local-pid:
+ Usage: required
+ Value type: u32
+ Definition: specifies the identfier of the local endpoint of this edge
+
+- qcom,remote-pid:
+ Usage: required
+ Value type: u32
+ Definition: specifies the identfier of the remote endpoint of this edge
+
+= SUBNODES
+Each SMP2P pair contain a set of inbound and outbound entries, these are
+described in subnodes of the smp2p device node. The node names are not
+important.
+
+- qcom,entry-name:
+ Usage: required
+ Value type: string
+ Definition: specifies the name of this entry, for inbound entries this
+ will be used to match against the remotely allocated entry
+ and for outbound entries this name is used for allocating
+ entries
+
+- interrupt-controller:
+ Usage: required for incoming entries
+ Value type: empty
+ Definition: marks the entry as inbound; the node should be specified
+ as a two cell interrupt-controller as defined in
+ ../interrupt-controller/interrupts.txt
+
+- #interrupt-cells:
+ Usage: required for incoming entries
+ Value type: u32
+ Definition: must be 2 - denoting the bit in the entry and IRQ flags
+
+- gpio-controller:
+ Usage: required for outgoing entries
+ Value type: empty
+ Definition: marks the entry as outbound; the node should be specified
+ as a two cell gpio-controller as defined in gpio.txt
+
+- #gpio-cells:
+ Usage: required for outgoing entries
+ Value type: u32
+ Definition: must be 2 - denoting the bit in the entry and GPIO flags
+
+= EXAMPLE
+The following example shows the SMP2P setup with the wireless processor,
+defined from the 8974 apps processor's point-of-view. It encompasses one
+inbound and one outbound entry:
+
+wcnss-smp2p {
+ compatible = qcom,smp2p;
+ qcom,smem = 431, 451;
+
+ interrupts = 0 143 1;
+
+ qcom,ipc = apcs 8 18;
+
+ qcom,local-pid = 0;
+ qcom,remote-pid = 4;
+
+ wcnss_smp2p_out: master-kernel {
+ qcom,entry-name = master-kernel;
+
+ gpio-controller;
+ #gpio-cells = 2;
+ };
+
+ wcnss_smp2p_in: slave-kernel {
+ qcom,entry-name = slave-kernel;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+};
--
1.8.2.2
--
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/4] gpio: qcom-smsm: Add driver for Qualcomm SMSM
This driver exposed the Qualcomm Shared Memory State Machine bits as
GPIOs to the system.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
drivers/gpio/gpio-qcom-smsm.c | 631 ++
1 file changed, 631 insertions(+)
create mode 100644 drivers/gpio/gpio-qcom-smsm.c
diff --git a/drivers/gpio/gpio-qcom-smsm.c b/drivers/gpio/gpio-qcom-smsm.c
new file mode 100644
index ..4b3f28c469b6
--- /dev/null
+++ b/drivers/gpio/gpio-qcom-smsm.c
@@ -0,0 +1,631 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of_irq.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/soc/qcom/smem.h
+
+/*
+ * This driver implements the Qualcomm Shared Memory State Machine, a mechanism
+ * for communicating single bit state information to remote processors.
+ *
+ * The implementation is based on two sections of shared memory; the first
+ * holding the state bits and the second holding a matrix of subscription bits.
+ *
+ * The state bits are structured in entries of 32 bits, each belonging to one
+ * system in the SoC. The entry belonging to the local system is considered
+ * read-write, while the rest should be considered read-only.
+ *
+ * The subscription matrix consists of N bitmaps per entry, denoting interest
+ * in updates of the entry for each of the N hosts. Upon updating a state bit
+ * each host's subscription bitmap should be queried and the remote system
+ * should be interrupted if they request so.
+ *
+ * The subscription matrix is laid out in entry-major order:
+ * entry0: [host0 ... hostN]
+ * .
+ * .
+ * entryM: [host0 ... hostN]
+ *
+ * A third, optional, shared memory region might contain information regarding
+ * the number of entries in the state bitmap as well as number of columns in
+ * the subscription matrix.
+ */
+
+/*
+ * Shared memory identifiers, used to acquire handles to respective memory
+ * region.
+ */
+#define SMEM_SMSM_SHARED_STATE 85
+#define SMEM_SMSM_CPU_INTR_MASK333
+#define SMEM_SMSM_SIZE_INFO419
+
+/*
+ * Default sizes, in case SMEM_SMSM_SIZE_INFO is not found.
+ */
+#define SMSM_DEFAULT_NUM_ENTRIES 8
+#define SMSM_DEFAULT_NUM_HOSTS 3
+
+struct smsm_entry;
+struct smsm_host;
+
+/**
+ * struct qcom_smsm - smsm driver context
+ * @dev: smsm device pointer
+ * @local_host:column in the subscription matrix representing this
system
+ * @num_hosts: number of columns in the subscription matrix
+ * @num_entries: number of entries in the state map and rows in the
subscription
+ * matrix
+ * @local_state: pointer to the local processor's state bits
+ * @subscription: pointer to local processor's row in subscription matrix
+ * @chip: gpio_chip for interfacing the state bits
+ * @entries: context for each of the entries
+ * @hosts: context for each of the hosts
+ */
+struct qcom_smsm {
+ struct device *dev;
+
+ u32 local_host;
+
+ u32 num_hosts;
+ u32 num_entries;
+
+ u32 *local_state;
+ u32 *subscription;
+ struct gpio_chip chip;
+
+ struct smsm_entry *entries;
+ struct smsm_host *hosts;
+};
+
+/**
+ * struct smsm_entry - per remote processor entry context
+ * @smsm: back-reference to driver context
+ * @domain:IRQ domain for this entry, if representing a remote system
+ * @irq_enabled: bitmap of which state bits IRQs are enabled
+ * @irq_rising:bitmap tracking if rising bits should be propagated
+ * @irq_falling: bitmap tracking if falling bits should be propagated
+ * @last_value:snapshot of state bits last time the interrupts where
propagated
+ * @remote_state: pointer to this entry's state bits
+ * @subscription: pointer to a row in the subscription matrix representing this
+ * entry
+ */
+struct smsm_entry {
+ struct qcom_smsm *smsm;
+
+ struct irq_domain *domain;
+ DECLARE_BITMAP(irq_enabled, 32);
+ DECLARE_BITMAP(irq_rising, 32);
+ DECLARE_BITMAP(irq_falling, 32);
+ u32 last_value;
+
+ u32 *remote_state;
+ u32 *subscription;
+};
+
+/**
+ * struct smsm_host - representation of a remote host
+ * @ipc_regmap:regmap for outgoing interrupt
+ * @ipc_offset:offset in @ipc_regmap for outgoing interrupt
[PATCH 4/4] gpio: qcom-smp2p: Qualcomm Shared Memory Point to Point
Introduce the Qualcomm Shard Memory Point to Point driver, exposing bits
from the SMP2P protocol as gpio and interrupt controllers.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-qcom-smp2p.c | 601 +
3 files changed, 609 insertions(+)
create mode 100644 drivers/gpio/gpio-qcom-smp2p.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0e57b60faae8..82c61ce5af8f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -354,6 +354,13 @@ config GPIO_PXA
help
Say yes here to support the PXA GPIO device
+config GPIO_QCOM_SMP2P
+ bool Qualcomm Shared Memory Point to Point support
+ depends on QCOM_SMEM
+ help
+ Say yes here to support the Qualcomm Shared Memory Point to Point
+ protocol, exposed to the system as GPIOs.
+
config GPIO_QCOM_SMSM
bool Qualcomm Shared Memory State Machine
depends on QCOM_SMEM
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0fd213892403..fdab869a7212 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_GPIO_PCF857X)+= gpio-pcf857x.o
obj-$(CONFIG_GPIO_PCH) += gpio-pch.o
obj-$(CONFIG_GPIO_PL061) += gpio-pl061.o
obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
+obj-$(CONFIG_GPIO_QCOM_SMP2P) += gpio-qcom-smp2p.o
obj-$(CONFIG_GPIO_QCOM_SMSM) += gpio-qcom-smsm.o
obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
diff --git a/drivers/gpio/gpio-qcom-smp2p.c b/drivers/gpio/gpio-qcom-smp2p.c
new file mode 100644
index ..f2eb2f095cc0
--- /dev/null
+++ b/drivers/gpio/gpio-qcom-smp2p.c
@@ -0,0 +1,601 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/list.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/soc/qcom/smem.h
+#include linux/spinlock.h
+
+/*
+ * The Shared Memory Point to Point (SMP2P) protocol facilitates communication
+ * of a single 32-bit value between two processors. Each value has a single
+ * writer (the local side) and a single reader (the remote side). Values are
+ * uniquely identified in the system by the directed edge (local processor ID
+ * to remote processor ID) and a string identifier.
+ *
+ * Each processor is responsible for creating the outgoing SMEM items and each
+ * item is writable by the local processor and readable by the remote
+ * processor. By using two separate SMEM items that are single-reader and
+ * single-writer, SMP2P does not require any remote locking mechanisms.
+ *
+ * The driver uses the Linux GPIO and interrupt framework to expose a virtual
+ * GPIO for each outbound entry and a virtual interrupt controller for each
+ * inbound entry.
+ */
+
+#define SMP2P_MAX_ENTRY 16
+#define SMP2P_MAX_ENTRY_NAME 16
+
+#define SMP2P_FEATURE_SSR_ACK 0x1
+
+#define SMP2P_MAGIC 0x504d5324
+
+/**
+ * struct smp2p_smem_item - in memory communication structure
+ * @magic: magic number
+ * @version: version - must be 1
+ * @features: features flag - currently unused
+ * @local_pid: processor id of sending end
+ * @remote_pid:processor id of receiving end
+ * @total_entries: number of entries - always SMP2P_MAX_ENTRY
+ * @valid_entries: number of allocated entries
+ * @flags:
+ * @entries: individual communication entries
+ * @name: name of the entry
+ * @value: content of the entry
+ */
+struct smp2p_smem_item {
+ u32 magic;
+ u8 version;
+ unsigned features:24;
+ u16 local_pid;
+ u16 remote_pid;
+ u16 total_entries;
+ u16 valid_entries;
+ u32 flags;
+
+ struct {
+ u8 name[SMP2P_MAX_ENTRY_NAME];
+ u32 value;
+ } entries[SMP2P_MAX_ENTRY];
+} __packed;
+
+/**
+ * struct smp2p_entry - driver context matching one entry
+ * @node: list entry to keep track of allocated entries
+ * @smp2p: reference to the device driver context
+ * @name: name of the entry, to match against smp2p_smem_item
+ * @value: pointer to smp2p_smem_item entry value
+ * @last_value:last handled value
+ * @domain:
RE: [PATCH v8 3/6] PCI: designware: Add ARM64 support
-Original Message-
From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org]
On Behalf Of Gabriel Fernandez
Sent: 27 August 2015 13:57
To: Wangzhou (B)
Cc: Bjorn Helgaas; jingooh...@gmail.com; pratyush.an...@gmail.com; Arnd
Bergmann; Russell King; thomas.petazz...@free-electrons.com; Gabriele Paoloni;
lorenzo.pieral...@arm.com; james.mo...@arm.com; Liviu Dudau;
ja...@lakedaemon.net; r...@kernel.org; devicetree@vger.kernel.org; linux-
p...@vger.kernel.org; xuwei (O); qiuzhenfa; liudongdong (C); zhangjukuo;
Liguozhu (Kenneth); qiujiang; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH v8 3/6] PCI: designware: Add ARM64 support
Hi Zhou,
You can add my Tested-by: Gabriel Fernandez gabriel.fernan...@st.com
I tested your patchset with a STMicroelectronics PCIe controller.
This controller is based on designware PCIe driver and works on ARM32.
Please find my patchset here:
http://www.spinics.net/lists/kernel/msg2064266.html
Best Regards.
Gabriel.
Many Thanks for this Gabriel
Cheers
Gab
On 25 August 2015 at 11:58, Zhou Wang wangzh...@hisilicon.com wrote:
This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
move related operations to dw_pcie_host_init.
This patch also try to use of_pci_get_host_bridge_resources for ARM32 and
ARM64
according to the suggestion for Gabriele[1]
Finally this patch reverts commit f4c55c5a3f7f PCI: designware: Program ATU
with untranslated address based on 1/6 in this series. we delete *_mod_base
in
pcie-designware. This was discussed in [2]
I have compiled the driver with multi_v7_defconfig. However, I don't have
ARM32 PCIe related board to do test. It will be appreciated if someone could
help to test it.
Signed-off-by: Zhou Wang wangzh...@hisilicon.com
Signed-off-by: Gabriele Paoloni gabriele.paol...@huawei.com
Signed-off-by: Arnd Bergmann a...@arndb.de
Tested-By: James Morse james.mo...@arm.com
[1] http://www.spinics.net/lists/linux-pci/msg42194.html
[2] http://www.spinics.net/lists/arm-kernel/msg436779.html
---
drivers/pci/host/pci-dra7xx.c | 14 +--
drivers/pci/host/pci-keystone-dw.c | 2 +-
drivers/pci/host/pcie-designware.c | 230 +-
---
drivers/pci/host/pcie-designware.h | 14 +--
4 files changed, 90 insertions(+), 170 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 18ae7ff..ac401be 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port
*pp)
{
dw_pcie_setup_rc(pp);
- if (pp-io_mod_base)
- pp-io_mod_base = CPU_TO_BUS_ADDR;
+ if (pp-io_base)
+ pp-io_base = CPU_TO_BUS_ADDR;
- if (pp-mem_mod_base)
- pp-mem_mod_base = CPU_TO_BUS_ADDR;
+ if (pp-mem_base)
+ pp-mem_base = CPU_TO_BUS_ADDR;
- if (pp-cfg0_mod_base) {
- pp-cfg0_mod_base = CPU_TO_BUS_ADDR;
- pp-cfg1_mod_base = CPU_TO_BUS_ADDR;
+ if (pp-cfg0_base) {
+ pp-cfg0_base = CPU_TO_BUS_ADDR;
+ pp-cfg1_base = CPU_TO_BUS_ADDR;
}
dra7xx_pcie_establish_link(pp);
diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-
keystone-dw.c
index f34892e..b1e4135 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem
*reg_virt)
void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
{
struct pcie_port *pp = ks_pcie-pp;
- u32 start = pp-mem.start, end = pp-mem.end;
+ u32 start = pp-mem-start, end = pp-mem-end;
int i, tr_size;
/* Disable BARs for inbound access */
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
designware.c
index c5d407c..e2d1898 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -11,6 +11,7 @@
* published by the Free Software Foundation.
*/
+#include linux/hardirq.h
#include linux/irq.h
#include linux/irqdomain.h
#include linux/kernel.h
@@ -69,16 +70,7 @@
#define PCIE_ATU_FUNC(x) (((x) 0x7) 16)
#define PCIE_ATU_UPPER_TARGET 0x91C
-static struct hw_pci dw_pci;
-
-static unsigned long global_io_offset;
-
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
- BUG_ON(!sys-private_data);
-
- return sys-private_data;
-}
+static struct pci_ops dw_pcie_ops;
int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
{
@@ -255,7 +247,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp,
int irq)
Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
On Wed, Aug 26, 2015 at 06:02:31PM -0700, Stefan Agner wrote:
On 2015-08-25 13:16, Brian Norris wrote:
On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..5c8dfe8
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,645 @@
...
+/*
+ * This function supports Vybrid only (MPC5125 would have full RB and
four CS)
+ */
+static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
+{
+#ifdef CONFIG_SOC_VF610
Why the #ifdef? I don't see anything compile-time specific to SOC_VF610.
If this is trying to handle the comment above (This function supports
Vybrid only (MPC5125 would have full RB and four CS)) then that's the
wrong way of doing it, as you need to support multiplatform kernels.
You'll need to have a way to differentiate the different platform
support at runtime, not compile time.
Yes it is trying to handle the comment above. Well, the other two
platforms I am aware of are also different architectures... (PowerPC and
ColdFire). I think we won't have a multi-architecture kernel anytime
soon,
Ha, right. Sorry, I don't really know this particular IP.
hence I think removing the code at compile time is the right thing
todo.
I don't believe that conclusion follows though.
However, probably CONFIG_SOC_VF610 is the wrong symbol then, I could
just use CONFIG_ARM and add a comment that this might be different on
another other ARM SoC than VF610.
Just checked CodingStyle, and I see that IS_ENABLED is the preferred way
for conditional compiling.
So my suggestion:
static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
{
struct vf610_nfc *nfc = mtd_to_nfc(mtd);
u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
if (!IS_ENABLED(CONFIG_ARM))
return;
/*
* This code is only tested on the ARM platform VF610
* PowerPC based MPC5125 would have full RB and four CS
*/
With that the compiler should be able to remove this (currently) ARM
VF610 specific code on the other supported architectures...
What do you think?
The code structure isn't bad, and yes, IS_ENABLED() would be preferable,
as it removes some of the problems with #ifdef, but I still don't think
the processor architecture has much to do with the version of the IP.
The canonical way of distiguishing per-IP revisions is to key on the
compatible property. So you'd have some kind of enum, which would
currently only have an entry for VF610. i.e.:
/* MPC5125 not yet supported */
if (nfc-revision != NAND_VFC610)
return;
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+ u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
+
+ tmp = ~(ROW_ADDR_CHIP_SEL_RB_MASK | ROW_ADDR_CHIP_SEL_MASK);
+ tmp |= 1 ROW_ADDR_CHIP_SEL_RB_SHIFT;
+
+ if (chip == 0)
+ tmp |= 1 ROW_ADDR_CHIP_SEL_SHIFT;
+ else if (chip == 1)
+ tmp |= 2 ROW_ADDR_CHIP_SEL_SHIFT;
else ... ?
Maybe you can write this as a formulaic pattern (e.g.:
tmp |= (chip + 1) ROW_ADDR_CHIP_SEL_SHIFT;
) and just do the max # of chips checks on a per-platform basis in the
probe(). Then I'm guessing this same function can apply to both
platforms. (I'm not looking at HW datasheets for this, BTW, just
guessing based on the context here.)
It seems that MCP5125 is different than VF610. MCP5125 has 4 chip
selects and 4 R/B signals, whereas VF610 has only 2 chip selects and
just 1 R/B signals...
OK I don't presume to know what the different IP versions look like. And
if you just note they are unsupported/untested, you're fine.
Brian
--
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
[RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST
Enable building all dtb files when COMPILE_TEST is enabled. The dtbs are not really dependent on a platform being enabled or any other kernel config, so for testing coverage it is convenient to build all of the dtbs. This builds all dts files in the tree, not just targets listed. This is simpler for arm64 which has a bunch of sub-dirs. Signed-off-by: Rob Herring r...@kernel.org Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com --- I've had this on my todo list for a while. RFC for now as I want to do the rest of the arches as well. I was originally thinking a new target for this, but thanks to Olof for the COMPILE_TEST suggestion. Rob arch/arm/boot/dts/Makefile | 4 arch/arm64/boot/dts/Makefile | 6 ++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 246473a..4968442a 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -712,5 +712,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \ dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb endif +dtstree:= $(srctree)/$(src) + +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard $(dtstree)/*.dts)) + always := $(dtb-y) clean-files:= *.dtb diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index 38913be..9f19390 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -11,3 +11,9 @@ dts-dirs += sprd dts-dirs += xilinx subdir-y := $(dts-dirs) + +dtstree:= $(srctree)/$(src) + +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts))) + +always := $(dtb-y) -- 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: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
Option 2:
memory@0 {
device_type = memory;
reg = 0x0 0x0 0x0 0x4000;
};
reserved-memory {
#address-cells = 2;
#size-cells = 2;
ranges;
mcu_reserved: mcu_reserved@06dff000 {
no-map;
reg = 0x0 0x06dff000 0x0 0x1000, /* MCU mailbox
buffer */
0x0 0x05e0 0x0 0x0010, /* MCU firmware
buffer */
0x0 0x0740f000 0x0 0x1000; /* MCU firmware
section */
};
};
[...]
mailbox: mailbox@f751 {
#mbox-cells = 1;
compatible = hisilicon,hi6220-mbox;
reg = 0x0 0xf751 0x0 0x1000; /* IPC_S */
memory-region = mcu_reserved; /* Mailbox buffer */
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
};
I prefer the second one. From my view, memory node should only describe
the hardware information of memory.
That doesn't align with the spec. Per ePAPR, in the description of a
memory node:
The client program may access memory not covered by any memory
reservations (see section 8.3) using any storage attributes it
chooses. However, before changing the storage attributes used to
access a real page, the client program is responsible for
performing actions required by the architecture and
implementation, possibly including flushing the real page from
the caches.
Note that in this context, memory reservation applies to /memreserve/.
We can only expect other software to handle /memreserve/, and not
reserved-memory, as the latter was introduced by Linux and has not
existed for anywhere near as long.
Additionally, the OS is permitted to map reserved memory with cacheable
attributes.
So the memory nodes have never been about the raw hardware layout, but
rather the regions that the OS may map. If (outside of the driver
responsible for the region) the OS should not map a region of memory,
that region should not appear in any memory node.
As mentioned in my other reply, for a region that the OS could map but
cannot use, I don't see much point in listing that memory in any memory
node.
Thanks,
Mark
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] dmaengine: vdma: Add 64 bit addressing support to the driver
This VDMA is a soft ip, which can be programmed to support
32 bit addressing or greater than 32 bit addressing.
When the VDMA ip is configured for 32 bit address space the
transfer start address is specified by a single register.
When the VDMA core is configured for an address space greater
than 32 then each start address is specified by a combination
of two registers. The first register specifies the LSB 32 bits
of address, while the next register specifies the MSB 32 bits
of address.For example,5Ch will specify the LSB 32 bits while
60h will specify the MSB 32 bits of the first start address.So
we need to program two registers at a time.
This patch adds the 64 bit addressing support to the vdma driver.
Signed-off-by: Anurag Kumar Vulisha anura...@xilinx.com
---
Changes in v2:
1. Added dma-ranges property in device tree as suggested by Arnd Bergmann.
2. Added device tree property(xlnx,addrwidth) for an identification of whether
the IP block itself is configured in 64-bit or 32-bit mode as suggested by
Laurent Pinchart.
3. Modified the driver code based on the xlnx,addrwidth.
---
.../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |4 +
drivers/dma/Kconfig|2 +-
drivers/dma/xilinx/xilinx_vdma.c | 81 +---
3 files changed, 76 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index e4c4d47..434d380 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,6 +8,8 @@ Required properties:
- #dma-cells: Should be 1, see dmas property below
- reg: Should contain VDMA registers location and length.
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
+- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
+- dma-ranges: Should be as the following dma_addr cpu_addr max_len
- dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
@@ -41,8 +43,10 @@ axi_vdma_0: axivdma@4003 {
compatible = xlnx,axi-vdma-1.00.a;
#dma_cells = 1;
reg = 0x4003 0x1 ;
+ dma-ranges = 0x 0x 0x4000;
xlnx,num-fstores = 0x8;
xlnx,flush-fsync = 0x1;
+ xlnx,addrwidth = 0x20;
dma-channel@4003 {
compatible = xlnx,axi-vdma-mm2s-channel;
interrupts = 0 54 4 ;
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index bda2cb0..a7cd0a8 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -398,7 +398,7 @@ config FSL_EDMA
config XILINX_VDMA
tristate Xilinx AXI VDMA Engine
- depends on (ARCH_ZYNQ || MICROBLAZE)
+ depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
select DMA_ENGINE
help
Enable support for Xilinx AXI VDMA Soft IP.
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index d8434d4..d4eebc9 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -98,6 +98,8 @@
#define XILINX_VDMA_FRMDLY_STRIDE_FRMDLY_SHIFT 24
#define XILINX_VDMA_FRMDLY_STRIDE_STRIDE_SHIFT 0
+#define XILINX_VDMA_REG_START_ADDRESS_64(n)(0x000c + 8 * (n))
+
#define XILINX_VDMA_REG_START_ADDRESS(n) (0x000c + 4 * (n))
/* HW specific definitions */
@@ -143,16 +145,18 @@
* @next_desc: Next Descriptor Pointer @0x00
* @pad1: Reserved @0x04
* @buf_addr: Buffer address @0x08
- * @pad2: Reserved @0x0C
- * @vsize: Vertical Size @0x10
- * @hsize: Horizontal Size @0x14
+ * @buf_addr_msb: Buffer msb address @0x0c
+ * @pad2: Reserved @0x10
+ * @vsize: Vertical Size @0x14
+ * @hsize: Horizontal Size @0x18
* @stride: Number of bytes between the first
- * pixels of each horizontal line @0x18
+ * pixels of each horizontal line @0x1C
*/
struct xilinx_vdma_desc_hw {
u32 next_desc;
u32 pad1;
u32 buf_addr;
+ u32 buf_addr_msb;
u32 pad2;
u32 vsize;
u32 hsize;
@@ -206,6 +210,7 @@ struct xilinx_vdma_tx_descriptor {
* @tasklet: Cleanup work after irq
* @config: Device configuration info
* @flush_on_fsync: Flush on Frame sync
+ * @ext_addr: Indicates 64 bit addressing is supported by dma channel
*/
struct xilinx_vdma_chan {
struct xilinx_vdma_device *xdev;
@@ -229,6 +234,7 @@ struct xilinx_vdma_chan {
struct tasklet_struct tasklet;
struct xilinx_vdma_config config;
bool flush_on_fsync;
+ bool ext_addr;
};
/**
@@ -239,6 +245,7 @@ struct xilinx_vdma_chan {
* @chan: Driver specific VDMA channel
* @has_sg: Specifies whether Scatter-Gather is present or not
* @flush_on_fsync: Flush on frame sync
+ * @ext_addr:
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Wed, Aug 26, 2015 at 07:59:50AM +0100, Leo Yan wrote:
Hi Haojian,
On Wed, Aug 26, 2015 at 09:25:41AM +0800, Haojian Zhuang wrote:
On Wed, 2015-08-26 at 00:00 +0800, Leo Yan wrote:
On Tue, Aug 25, 2015 at 09:43:14PM +0800, Haojian Zhuang wrote:
On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote:
Are you then going to hack GRUB, release a special HiKey version
of
GRUB, not support any other versions, and still can your firmware
UEFI?
I don't need to hack GRUB at all.
Then it is working for you by pure chance alone.
Please listen to the advice you are being given here; we're trying to
ensure that your platform functions (and continues to function) as
best
it can.
Since we discussed a lot on this, let's make a conclusion on it.
1. UEFI could append the reserved buffer in it's memory mapping.
2. These reserved buffer must be declared in DT, since we also need to
support non-UEFI (uboot) at the same time.
3. Mailbox node should reference reserved buffer by phandle in DT. Then
map the buffer as non-cacheable in driver.
4. These reserved buffer must use no-map property since it should be
non-cacheable in driver.
For more specific discussion for DTS, i list two options at here;
- Option 1: just simply reserve memory regions through memory node,
and mailbox node will directly use the buffer through reg ranges;
- Option 2: use reserved-memory and mailbox node will refer phandle
of reserved-memory;
These two options both can work well with UEFI and Uboot, but option 1
is more simple and straightforward; so i personally prefer it. But
look forwarding your guys' suggestion.
Option 1:
memory@0 {
device_type = memory;
reg = 0x 0x 0x 0x05e0,
0x 0x05f0 0x 0x00eff000,
0x 0x06e0 0x 0x0060f000,
0x 0x0741 0x 0x38bf;
};
[...]
mailbox: mailbox@f751 {
#mbox-cells = 1;
compatible = hisilicon,hi6220-mbox;
reg = 0x0 0xf751 0x0 0x1000, /* IPC_S */
0x0 0x06dff800 0x0 0x0800; /* Mailbox buffer */
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
};
Option 2:
memory@0 {
device_type = memory;
reg = 0x0 0x0 0x0 0x4000;
};
reserved-memory {
#address-cells = 2;
#size-cells = 2;
ranges;
mcu_reserved: mcu_reserved@06dff000 {
no-map;
reg = 0x0 0x06dff000 0x0 0x1000, /* MCU mailbox
buffer */
0x0 0x05e0 0x0 0x0010, /* MCU firmware
buffer */
0x0 0x0740f000 0x0 0x1000; /* MCU firmware
section */
};
};
[...]
mailbox: mailbox@f751 {
#mbox-cells = 1;
compatible = hisilicon,hi6220-mbox;
reg = 0x0 0xf751 0x0 0x1000; /* IPC_S */
memory-region = mcu_reserved; /* Mailbox buffer */
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
};
I prefer the second one. From my view, memory node should only describe
the hardware information of memory.
Yes, option 2 will be more simple for memory node.
But option 2 also will introduce complexity for mailbox node, due mailbox
driver need use property reg and memory-region to sepeately depict
the regions for mailbox's ipc and slots. If later mailbox is designed to
use SRAM for both ipc and slots, then it will no matter with DDR anymore,
in this case option 1 will easily switch to support it.
Another question is a general question: for Linux kernel, which is the
best method to reserve memory regions? According to previous discussion,
we can use /memory/ node or /reseved-memory/ node to reserve memory
regions.
If the memory is truly reserved for a purpose and cannot be used for
anything else, I don't think it should be in the memory node at all, and
should be carved out. That aligns with what you'd do in UEFI (either not
listing the region in the memory map, or listing it with attributes such
that it may not be mapped and/or used).
I don't see much of a reason for /memreserve/, as it can cause issues
(by allowing the OS to map the region with cacheable attributes), and is
not as rigorously specified for ARM as it is for Power in ePAPR.
I understand that reserved-memory is for carving out (potentially
reusable) memory pools for devices or other special uses (perhaps a
panic log). Usually such memory may also be used by the kernel for its
own purposes if not presently required by the device.
Having an entry in reserved-memory does not necessitate the region also
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On 26/08/15 02:25, Haojian Zhuang wrote:
Option 1:
memory@0 {
device_type = memory;
reg = 0x 0x 0x 0x05e0,
0x 0x05f0 0x 0x00eff000,
0x 0x06e0 0x 0x0060f000,
0x 0x0741 0x 0x38bf;
};
[snip]
Option 2:
memory@0 {
device_type = memory;
reg = 0x0 0x0 0x0 0x4000;
};
[snip]
I prefer the second one. From my view, memory node should only describe
the hardware information of memory.
Haven't we already established that, to avoid the risk of UEFI
applications accessing inappropriate memory locations, a (correct) UEFI
implementation must use, and pass to the kernel, a memory map that looks
like option 1?
That being the case why would we want u-boot (or any other similar
bootloader) to pass a memory map that is gratuitously different to the
one supplied by UEFI?
Daniel.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST
On Thu, Aug 27, 2015 at 8:56 AM, Rob Herring r...@kernel.org wrote: Enable building all dtb files when COMPILE_TEST is enabled. The dtbs are not really dependent on a platform being enabled or any other kernel config, so for testing coverage it is convenient to build all of the dtbs. This builds all dts files in the tree, not just targets listed. This is simpler for arm64 which has a bunch of sub-dirs. Signed-off-by: Rob Herring r...@kernel.org Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com --- I've had this on my todo list for a while. RFC for now as I want to do the rest of the arches as well. I was originally thinking a new target for this, but thanks to Olof for the COMPILE_TEST suggestion. Rob arch/arm/boot/dts/Makefile | 4 arch/arm64/boot/dts/Makefile | 6 ++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 246473a..4968442a 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -712,5 +712,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \ dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb endif +dtstree:= $(srctree)/$(src) + +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard $(dtstree)/*.dts)) + always := $(dtb-y) clean-files:= *.dtb diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index 38913be..9f19390 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -11,3 +11,9 @@ dts-dirs += sprd dts-dirs += xilinx subdir-y := $(dts-dirs) + +dtstree:= $(srctree)/$(src) + +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts))) I think it would be more appropriate to build dtb-n here instead of _any_ file ending in dts. It would be useful to build all files, but it's not the behavior that COMPILE_TEST usually has. -Olof -- 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 2/4] dt: Add vendor prefix 'holt'
On 23/08/15 23:32, Rob Herring wrote: On Thu, Aug 20, 2015 at 2:38 PM, Vladimir Barinov vladimir.bari...@cogentembedded.com wrote: Add Holt Integrated Circuits, Inc. to the list of device tree vendor prefixes Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com Acked-by: Rob Herring r...@kernel.org Applied to the togreg branch of iio.git. Thanks, Jonathan --- Changes in version 2: - none Changes in version 3: - none Changes in version 4: - none Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d444757..bc64cc9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -99,6 +99,7 @@ himax Himax Technologies, Inc. hisilicon Hisilicon Limited. hitHitachi Ltd. hitex Hitex Development Tools +holt Holt Integrated Circuits, Inc. honeywell Honeywell hp Hewlett Packard i2se I2SE GmbH -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-iio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v3 1/2] mfd: devicetree: bindings: 88pm800: Add DT property for dual phase enable
On Mon, Aug 24, 2015 at 08:24:10PM +0530, Vaibhav Hiremath wrote: Mark, Any comments here before I spin V4. Please just resubmit things, seeing that a change was requested is usually a good indication that a new version is incoming. signature.asc Description: Digital signature
Re: [PATCH 00/16] deps: deterministic driver initialization order
Am 27.08.2015 um 21:01 schrieb Alexander Holler: Am 26.08.2015 um 14:28 schrieb Alexander Holler: The final 2 patches are fixes which should end up in mainline, regardless if this feature is merged or not. Just in case your serial or MTD-NAND partitions don't work, the drivers drivers/tty/serial/8250/8250_core.c and drivers/mtd/ofpart.c need the same trivial fix for their initcall level as found in the last two patches of my series. I'm not going to post these patches now until I've got some feedback for the other stuff. And just in case, I also have an idea how to fix such dependencies for drivers without DT (by adding hard-wired dependencies directly to drivers). That would also be usable for ACPI and x86. But one step after another. Based on my past experiences, I don't even think the stuff I've just posted will ever end up in the kernel. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties
Hi, On Tue, Aug 18, 2015 at 11:19 PM, Heiko Stuebner he...@sntech.de wrote: great, just take into account the deep vs. shallow suspend modes :-) One note: do you think it would make sense to re-implement shallow suspend as standby? I had a proof of concept doing that in https://chromium-review.googlesource.com/#/c/275123/. One nice advantage is that you magically get a second set of regulator states for standby vs mem. If I understand correctly, the distinction between standby and mem is not too clearly defined, so if we wanted to use it for this it wouldn't be terrible? -Doug -- 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 3/4] iio: adc: hi8435: Holt HI-8435 threshold detector
On 20/08/15 20:38, Vladimir Barinov wrote: Add Holt threshold detector driver for HI-8435 chip Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com A few little bits and bobs below but basically there. Jonathan --- Changes in version 2: - Added file sysfs-bus-iio-adc-hi8435 - Changed naming from discrete ADC to threshold detector - Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup - Made *_show and *_store functions static - moved out from iio buffers to iio events - removed hi8436/hi8437 chips from the driver - moved from debounce_soft_delay/enable to debounce_interval via IIO_CHAN_INFO_DEBOUNCE_TIME - added name extention comparator - moved threshold/hysteresis setup via generic iio event sysfs - added software mask/unmask channel events - added programming sensor outputs while in test mode via IIO_CHAN_INFO_RAW - added channels .ext_info for programming sensing mode Changes in version 3: - fixed typos - moved linux/interrupt.h to match alphabetic order - fixed missed */event/* prefix in the ABI description - added missed colon in sysfs-bus-iio-adc-hi8435 file after What - moved in_voltageY_comparator_thresh_either_en and debounce_time to sysfs-bus-iio file - added error checking for hi8435_write[b|w] Changes in version 4: - removed software debounce logic - fixed typo in comment s/threshold/thresholds - removed test_enable sysfs entry - removed *_raw entries - removed extended_name - switched to GPIO descriptor API - added comment describing the need of thresholds initialization - added debugfs_reg_access Documentation/ABI/testing/sysfs-bus-iio| 1 + Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 | 39 ++ drivers/iio/adc/Kconfig| 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/hi8435.c | 535 + 5 files changed, 587 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 create mode 100644 drivers/iio/adc/hi8435.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 42d360f..20312a0 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -581,6 +581,7 @@ What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What:/sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en +What:/sys/.../iio:deviceX/events/in_voltageY_thresh_either_en What:/sys/.../iio:deviceX/events/in_tempY_thresh_rising_en What:/sys/.../iio:deviceX/events/in_tempY_thresh_falling_en KernelVersion: 2.6.37 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 new file mode 100644 index 000..e3f1943 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 @@ -0,0 +1,39 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode +Date:August 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Program sensor type for threshold detector inputs. + Could be either GND-Open or Supply-Open mode. Y is a + threshold detector input channel. Channels 0..7, 8..15, 16..23 + and 24..31 has common sensor types. + +What: /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value +Date:August 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Channel Y low voltage threshold. If sensor input voltage goes lower then + this value then the threshold falling event is pushed. + Depending on in_voltageY_sensing_mode the low voltage threshold + is separately set for GND-Open and Supply-Open modes. + Channels 0..31 have common low threshold values, but could have different + sensing_modes. + The low voltage threshold range is between 2..21V. + Hysteresis between low and high thresholds can not be lower then 2 and + can not be odd. Should note that what happens if it is set to odd. + +What: /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value +Date:August 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Channel Y high voltage threshold. If sensor input voltage goes higher then + this value then the threshold rising event is pushed. + Depending on in_voltageY_sensing_mode the high voltage
Re: [RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST
On Thu, Aug 27, 2015 at 11:08 AM, Olof Johansson o...@lixom.net wrote: On Thu, Aug 27, 2015 at 8:56 AM, Rob Herring r...@kernel.org wrote: Enable building all dtb files when COMPILE_TEST is enabled. The dtbs are not really dependent on a platform being enabled or any other kernel config, so for testing coverage it is convenient to build all of the dtbs. This builds all dts files in the tree, not just targets listed. This is simpler for arm64 which has a bunch of sub-dirs. Signed-off-by: Rob Herring r...@kernel.org Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com --- I've had this on my todo list for a while. RFC for now as I want to do the rest of the arches as well. I was originally thinking a new target for this, but thanks to Olof for the COMPILE_TEST suggestion. Rob arch/arm/boot/dts/Makefile | 4 arch/arm64/boot/dts/Makefile | 6 ++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 246473a..4968442a 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -712,5 +712,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \ dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb endif +dtstree:= $(srctree)/$(src) + +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard $(dtstree)/*.dts)) + always := $(dtb-y) clean-files:= *.dtb diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index 38913be..9f19390 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -11,3 +11,9 @@ dts-dirs += sprd dts-dirs += xilinx subdir-y := $(dts-dirs) + +dtstree:= $(srctree)/$(src) + +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts))) I think it would be more appropriate to build dtb-n here instead of _any_ file ending in dts. The problem is here dtb-n is NULL. We have to add this into every sub-dir. Not a big deal to do, but my concern was remembering to it for new ones. Then again, most people are good at mindlessly copy-pasting so maybe that won't be a problem. :) It would be useful to build all files, but it's not the behavior that COMPILE_TEST usually has. Just changing to dtb-n would be equivalent because there is no other dependency to enable building. Code has other dependencies typically. What dtb do we not want to built in an allyesconfig build? If dtb's have any dependencies, that would be a bug. To really make this equivalent to a driver using COMPILE_TEST, we would need kconfig symbols specifically for each platform's dtbs. Then we would have the 2 stage unhide (setting COMPILE_TEST) then enable the option. I was also thinking that perhaps we don't want to require a kconfig symbol for every platform family. Adding a kconfig entry is the only way to enable building a dtb ATM. I know there are 2 camps to this policy though. 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 4/4] dt: Document Holt HI-8435 bindings
On 20/08/15 20:38, Vladimir Barinov wrote:
These bindings can be used to register Holt HI-8435 threshold detector
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
This is fine and trivial enough that I am not going to need a device tree
ack (not that I'd complain if one showed up :)
Will pick it up with the driver..
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none
Changes in version 4:
- removed debounce_interval property
- removed reset-gpios to use GPIO descriptor API
.../devicetree/bindings/iio/adc/hi8435.txt | 21
+
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..3b0348c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,21 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be holt,hi8435
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - gpios: GPIO used for controlling the reset pin
+
+Example:
+sensor@0 {
+ compatible = holt,hi8435;
+ reg = 0;
+ gpios = gpio6 1 0;
+
+ spi-max-frequency = 100;
+};
--
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 v6 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor
On 20/08/15 11:12, Adriana Reus wrote: Add support for UPISEMI us5182d als and proximity sensor. Supports raw readings. Data sheet for this device can be found here: http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf Signed-off-by: Adriana Reus adriana.r...@intel.com Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it. Thanks, Jonathan --- Changes since v5: * fixed typos (thank you, Peter) drivers/iio/light/Kconfig | 10 + drivers/iio/light/Makefile | 1 + drivers/iio/light/us5182d.c | 507 3 files changed, 518 insertions(+) create mode 100644 drivers/iio/light/us5182d.c diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig index 7ed859a..0442f01 100644 --- a/drivers/iio/light/Kconfig +++ b/drivers/iio/light/Kconfig @@ -287,6 +287,16 @@ config TSL4531 To compile this driver as a module, choose M here: the module will be called tsl4531. +config US5182D + tristate UPISEMI light and proximity sensor + depends on I2C + help + If you say yes here you get support for the UPISEMI US5182D + ambient light and proximity sensor. + + This driver can also be built as a module. If so, the module + will be called us5182d. + config VCNL4000 tristate VCNL4000 combined ALS and proximity sensor depends on I2C diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile index 91c74c0..528cc8f 100644 --- a/drivers/iio/light/Makefile +++ b/drivers/iio/light/Makefile @@ -27,4 +27,5 @@ obj-$(CONFIG_STK3310) += stk3310.o obj-$(CONFIG_TCS3414)+= tcs3414.o obj-$(CONFIG_TCS3472)+= tcs3472.o obj-$(CONFIG_TSL4531)+= tsl4531.o +obj-$(CONFIG_US5182D)+= us5182d.o obj-$(CONFIG_VCNL4000) += vcnl4000.o diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c new file mode 100644 index 000..49dab3c --- /dev/null +++ b/drivers/iio/light/us5182d.c @@ -0,0 +1,507 @@ +/* + * Copyright (c) 2015 Intel Corporation + * + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope 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. + * + * To do: Interrupt support. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/acpi.h +#include linux/delay.h +#include linux/i2c.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h +#include linux/mutex.h + +#define US5182D_REG_CFG0 0x00 +#define US5182D_CFG0_ONESHOT_EN BIT(6) +#define US5182D_CFG0_SHUTDOWN_EN BIT(7) +#define US5182D_CFG0_WORD_ENABLE BIT(0) + +#define US5182D_REG_CFG1 0x01 +#define US5182D_CFG1_ALS_RES16 BIT(4) +#define US5182D_CFG1_AGAIN_DEFAULT 0x00 + +#define US5182D_REG_CFG2 0x02 +#define US5182D_CFG2_PX_RES16BIT(4) +#define US5182D_CFG2_PXGAIN_DEFAULT BIT(2) + +#define US5182D_REG_CFG3 0x03 +#define US5182D_CFG3_LED_CURRENT100 (BIT(4) | BIT(5)) + +#define US5182D_REG_CFG4 0x10 + +/* + * Registers for tuning the auto dark current cancelling feature. + * DARK_TH(reg 0x27,0x28) - threshold (counts) for auto dark cancelling. + * when ALS DARK_TH -- ALS_Code = ALS - Upper(0x2A) * Dark + * when ALS DARK_TH -- ALS_Code = ALS - Lower(0x29) * Dark + */ +#define US5182D_REG_UDARK_TH 0x27 +#define US5182D_REG_DARK_AUTO_EN 0x2b +#define US5182D_REG_AUTO_LDARK_GAIN 0x29 +#define US5182D_REG_AUTO_HDARK_GAIN 0x2a + +#define US5182D_OPMODE_ALS 0x01 +#define US5182D_OPMODE_PX0x02 +#define US5182D_OPMODE_SHIFT 4 + +#define US5182D_REG_DARK_AUTO_EN_DEFAULT 0x80 +#define US5182D_REG_AUTO_LDARK_GAIN_DEFAULT 0x16 +#define US5182D_REG_AUTO_HDARK_GAIN_DEFAULT 0x00 + +#define US5182D_REG_ADL 0x0c +#define US5182D_REG_PDL 0x0e + +#define US5182D_REG_MODE_STORE 0x21 +#define US5182D_STORE_MODE 0x01 + +#define US5182D_REG_CHIPID 0xb2 + +#define US5182D_OPMODE_MASK GENMASK(5, 4) +#define US5182D_AGAIN_MASK
[PATCH] ARM: dts: sun5i: inet98v_rev2 fix regulator for the usb wifi module
The usb-wifi module is not connected to a gpio controller regulator
(as is typical on sunxi boards), instead is it connected to ldo3.
This commit fixes the us_phy usb1_vbus-supply setting thereby making
sure that we power the usb-wifi and that it can be used.
This commit also removes the wrong and now unused bits which refer to
the gpio controlled reg_usb1_vbus.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
b/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
index 6d466a2..6fa54b6 100644
--- a/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
+++ b/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
@@ -201,11 +201,6 @@
status = okay;
};
-reg_usb1_vbus {
- gpio = pio 6 11 GPIO_ACTIVE_HIGH; /* PG11 */
- status = okay;
-};
-
uart1 {
pinctrl-names = default;
pinctrl-0 = uart1_pins_b;
@@ -221,16 +216,12 @@
allwinner,pins = PG12;
};
-usb1_vbus_pin_a {
- allwinner,pins = PG11;
-};
-
usbphy {
pinctrl-names = default;
pinctrl-0 = usb0_id_detect_pin, usb0_vbus_detect_pin;
usb0_id_det-gpio = pio 6 2 GPIO_ACTIVE_HIGH; /* PG2 */
usb0_vbus_det-gpio = pio 6 1 GPIO_ACTIVE_HIGH; /* PG1 */
usb0_vbus-supply = reg_usb0_vbus;
- usb1_vbus-supply = reg_usb1_vbus;
+ usb1_vbus-supply = reg_ldo3;
status = okay;
};
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] ARM: dts: sun5i: inet98v_rev2 fix regulator for the usb wifi
Hi Maxime, Here is a fixup patch for the patch adding a dts for the inet98v_rev2. I'm not sure if you've merged the original patch yet, hence I'm sending this as a follow-up patch. If you've not yet merged the original patch feel free to squash this fix in. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] deps: deterministic driver initialization order
Am 26.08.2015 um 14:28 schrieb Alexander Holler: The final 2 patches are fixes which should end up in mainline, regardless if this feature is merged or not. Just in case your serial or MTD-NAND partitions don't work, the drivers drivers/tty/serial/8250/8250_core.c and drivers/mtd/ofpart.c need the same trivial fix for their initcall level as found in the last two patches of my series. I'm not going to post these patches now until I've got some feedback for the other stuff. Regards, Alexander Holler -- 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 1/4] iio: Support triggered events
On 20/08/15 20:43, Vladimir Barinov wrote:
Verified event and buffer polling works concurrently on the same trigger with
hi-8435.
The buffer interface part for hi-8435 was not sent.
On 20.08.2015 22:37, Vladimir Barinov wrote:
Support triggered events.
This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
Applied with a certain amount of fuzz (the buffers have moved out into
their own directory).
Jonathan
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match GNU Public License v2 or later
Changes in version 4:
- added pollfunc_event to separate triggering buffer and event
interfaces. This allows runnig both from the same trigger
- removed 'currentmode' for triggered buffer since useless
- renamed parameters of iio_triggered_event_setup
drivers/iio/Kconfig| 6 +++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-core.c| 4 +-
drivers/iio/industrialio-trigger.c | 12 +-
drivers/iio/industrialio-triggered-event.c | 68
++
include/linux/iio/iio.h| 3 ++
include/linux/iio/triggered_event.h| 11 +
7 files changed, 101 insertions(+), 4 deletions(-)
create mode 100644 drivers/iio/industrialio-triggered-event.c
create mode 100644 include/linux/iio/triggered_event.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
+config IIO_TRIGGERED_EVENT
+tristate
+select IIO_TRIGGER
+help
+ Provides helper functions for setting up triggered events.
+
source drivers/iio/accel/Kconfig
source drivers/iio/adc/Kconfig
source drivers/iio/amplifiers/Kconfig
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c
b/drivers/iio/industrialio-core.c
index b3fcc2c..2c3b6a1 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -962,7 +962,7 @@ static void iio_device_unregister_sysfs(struct iio_dev
*indio_dev)
static void iio_dev_release(struct device *device)
{
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-if (indio_dev-modes INDIO_BUFFER_TRIGGERED)
+if (indio_dev-modes (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1241,7 +1241,7 @@ int iio_device_register(struct iio_dev *indio_dev)
Failed to register event set\n);
goto error_free_sysfs;
}
-if (indio_dev-modes INDIO_BUFFER_TRIGGERED)
+if (indio_dev-modes (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
if ((indio_dev-modes INDIO_ALL_BUFFER_MODES)
diff --git a/drivers/iio/industrialio-trigger.c
b/drivers/iio/industrialio-trigger.c
index 570606c..ae2806a 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -366,10 +366,18 @@ static ssize_t iio_trigger_write_current(struct device
*dev,
indio_dev-trig = trig;
-if (oldtrig)
+if (oldtrig) {
+if (indio_dev-modes INDIO_EVENT_TRIGGERED)
+iio_trigger_detach_poll_func(oldtrig,
+ indio_dev-pollfunc_event);
iio_trigger_put(oldtrig);
-if (indio_dev-trig)
+}
+if (indio_dev-trig) {
iio_trigger_get(indio_dev-trig);
+if (indio_dev-modes INDIO_EVENT_TRIGGERED)
+iio_trigger_attach_poll_func(indio_dev-trig,
+ indio_dev-pollfunc_event);
+}
return len;
}
diff --git a/drivers/iio/industrialio-triggered-event.c
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..8cc254f
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor
On 20/08/15 11:12, Adriana Reus wrote:
Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
Also added a documentation file for this sensor's properties.
Signed-off-by: Adriana Reus adriana.r...@intel.com
This isn't that trivial so I'd like some device tree maintainer
input if possible.
For now I've backed out the driver from my tree (given timing we have
loads of time to sort this out!)
Anyhow, anyone device tree related able to take a look at this.
Adriana, btw these should be cc'd to the device tree maintainers in
the first place (now added).
Jonathan
---
.../devicetree/bindings/iio/light/us5182d.txt | 23
++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
b/Documentation/devicetree/bindings/iio/light/us5182d.txt
new file mode 100644
index 000..7785c56
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
@@ -0,0 +1,23 @@
+* UPISEMI us5182d I2C ALS and Proximity sensor
+
+Required properties:
+- compatible: must be upisemi,usd5182
+- reg: the I2C address of the device
+
+Optional properties:
+- upisemi,glass-coef: glass attenuation factor
+- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every
scale
+- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light threshold
+- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light threshold
+
+Example:
+
+usd5182@39 {
+compatible = upisemi,usd5182;
+reg = 0x39;
+upisemi,glass-coef = 1000 ;
+upisemi,dark-ths = /bits/ 16 170 200 512 512 800 2000 4000
8000;
+upisemi,upper-dark-gain = /bits/ 8 0x00;
+upisemi,lower-dark-gain = /bits/ 8 0x16;
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..5b40bab 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -211,6 +211,7 @@ toshiba Toshiba Corporation
toumaz Toumaz
tplink TP-LINK Technologies Co., Ltd.
trulyTruly Semiconductors Limited
+upisemi uPI Semiconductor Corp.
usi Universal Scientific Industrial Co., Ltd.
v3 V3 Semiconductor
varisciteVariscite Ltd.
--
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 V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
Hi,
On 08/27/2015 11:12 AM, Marek Vasut wrote:
On Thursday, August 27, 2015 at 07:44:34 PM, vikas wrote:
Hi,
On 08/21/2015 02:20 AM, Marek Vasut wrote:
From: Graham Moore grmo...@opensource.altera.com
Add binding document for the Cadence QSPI controller.
Signed-off-by: Graham Moore grmo...@opensource.altera.com
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Alan Tull at...@opensource.altera.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: David Woodhouse dw...@infradead.org
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Graham Moore grmo...@opensource.altera.com
Cc: Vikas MANOCHA vikas.mano...@st.com
Cc: Yves Vandervennet yvand...@opensource.altera.com
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 56
++ 1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property is-decoded-cs instead of creating a
duplicate, ext-decoder. Timing parameters are in nanoseconds,
not master reference clocks. Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
V7: - Prefix all of the Cadence-specific properties with cdns prefix,
those are in particular cdns,is-decoded-cs, cdns,fifo-depth,
cdns,fifo-width, cdns,trigger-address.
- Drop bogus properties which were not used and were incorrect.
V8: Align lines to 80 chars.
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt new file
mode 100644
index 000..f248056
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -0,0 +1,56 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be cdns,qspi-nor.
+- reg : Contains two entries, each of which is a tuple consisting of a
+ physical address and length. The first entry is the address and
+ length of the controller register set. The second entry is the
+ address and length of the QSPI Controller data area.
still hooked up with Controller data area, it is ambiguous.
Use something which is more clear: Nor Flash memory mapped address.
I have to disagree, I will call it whatever it is called in the datasheet
and it is called controller data area.
It is preferable to use terminology which readers understand that is the
purpose
of explaining it here otherwise we could have just pasted the doc link.
I have to stop here for this point.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- cdns,fifo-depth : Size of the data FIFO in words.
+- cdns,fifo-width : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+
+Optional properties:
again, is it optional ? can the driver be used without these properties ?
Why wouldn't it be possible to use the driver with no SPI NOR attached to
it? It's a cornercase, but still a valid one.
that's not right, this controller is only spi flash controller.
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
again, add info what the decoder is for ?
This is something Graham has to clarify. Based on the code (I'm sure you did
check the code), it's a 4:16 demuxer.
Please clarify if possible add the info for others benefit. This part is not
common in other spi/nor controllers.
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with
additional +custom properties:
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
+ mode chip select outputs are de-asserted between
+ transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
+ de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
+ transaction and deasserting the device chip select
+ (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
+ and first bit transfer.
+
+Example:
+
+ qspi: spi@ff705000 {
+ compatible = cdns,qspi-nor;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0xff705000 0x1000,
+ 0xffa0 0x1000;
+ interrupts = 0 151 4;
+ clocks = qspi_clk;
+ cdns,is-decoded-cs;
flag value ?
Sorry, I don't quite understand the question. If you mean why there is no
value, it's because this is a boolean OF node, which just does't need to
have a value ; it's either present or not.
you are right, thanks.
Cheers,
Vikas
Best regards,
Marek Vasut
.
--
To unsubscribe from this list: send the line
Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties
Am Donnerstag, 27. August 2015, 12:30:51 schrieb Doug Anderson: Hi, On Tue, Aug 18, 2015 at 11:19 PM, Heiko Stuebner he...@sntech.de wrote: great, just take into account the deep vs. shallow suspend modes :-) One note: do you think it would make sense to re-implement shallow suspend as standby? I had a proof of concept doing that in https://chromium-review.googlesource.com/#/c/275123/. One nice advantage is that you magically get a second set of regulator states for standby vs mem. Somewhere I've read something about keeping wifi associated to an ap during suspend which might be a candidate for such a distinction? If I understand correctly, the distinction between standby and mem is not too clearly defined, so if we wanted to use it for this it wouldn't be terrible? From reading Documentation/power/states.txt it looks like the boot-cpu is supposed to retain power in the suspend state. Although we also do not lose operating state in our suspend I guess? So using the shallow suspend as standby sounds interesting, for the time when the deep suspend works too. If there is only one suspend state it automatically becomes the mem-state it seems. Heiko -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: dts: rockchip: add veyron-jaq board
Brian, On Mon, Aug 24, 2015 at 3:58 PM, Brian Norris briannor...@chromium.org wrote: a.k.a. Haier Chromebook 11, and others Signed-off-by: Brian Norris briannor...@chromium.org Cc: Alexandru M Stan ams...@chromium.org Cc: Douglas Anderson diand...@chromium.org Reviewed-by: Javier Martinez Canillas jav...@osg.samsung.com --- v2 - v3: - add and others language - drop other patches from series (picked up already by Heiko) v1 - v2: - add overlooked DT binding doc - fixup regulator suspend state for LDO_REG2 Documentation/devicetree/bindings/arm/rockchip.txt | 7 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-jaq.dts| 176 + 3 files changed, 184 insertions(+) Reviewed-by: Douglas Anderson diand...@chromium.org -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST
Hi Rob,
On Thu, Aug 27, 2015 at 9:07 PM, Rob Herring r...@kernel.org wrote:
It would be useful to build all files, but it's not the behavior that
COMPILE_TEST usually has.
Just changing to dtb-n would be equivalent because there is no other
dependency to enable building. Code has other dependencies typically.
What dtb do we not want to built in an allyesconfig build? If dtb's
have any dependencies, that would be a bug. To really make this
equivalent to a driver using COMPILE_TEST, we would need kconfig
symbols specifically for each platform's dtbs. Then we would have the
2 stage unhide (setting COMPILE_TEST) then enable the option.
I was also thinking that perhaps we don't want to require a kconfig
symbol for every platform family. Adding a kconfig entry is the only
way to enable building a dtb ATM. I know there are 2 camps to this
policy though.
I think it would be good to have a single Kconfig option (depending on
COMPILE_TEST) to build all dtbs.
For drivers, COMPILE_TEST doesn't enable anything by itself, it just
relaxes dependencies. Hence if any driver is broken, I can still
disable that driver in the .config.
If any dtb is broken, I cannot disable it, except by disabling COMPILE_TEST,
which I may not want to do for other reasons (e.g. I'm compile testing my
driver). If there would be an extra Kconfig symbol for building all dtbs,
I can still disable it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties
On Thu, Aug 27, 2015 at 10:51:22PM +0200, Heiko Stuebner wrote:
Am Donnerstag, 27. August 2015, 12:30:51 schrieb Doug Anderson:
If I understand correctly, the distinction between standby and mem
is not too clearly defined, so if we wanted to use it for this it
wouldn't be terrible?
I never understood many clear definitions here either, personally.
From reading Documentation/power/states.txt it looks like the boot-cpu is
supposed to retain power in the suspend state. Although we also do not lose
operating state in our suspend I guess?
So using the shallow suspend as standby sounds interesting, for the time when
the deep suspend works too. If there is only one suspend state it
automatically becomes the mem-state it seems.
It's not really automatic, it's a product of this line:
static const struct platform_suspend_ops rk3288_suspend_ops = {
.enter = rk3288_suspend_enter,
.valid = suspend_valid_only_mem, --- here
.prepare = rk3288_suspend_prepare,
.finish = rk3288_suspend_finish,
};
and the fact that we don't check the 'state' argument in
.enter/.prepare/.finish.
But still, I'm not sure it's productive to rename shallow until we support
deep.
Regards,
Brian
--
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 0/5] Add Broadcom Northstar Plus Support
Patchset all look good. Acked-by: Scott Branden sbran...@broadcom.com On 15-08-26 03:35 PM, Jon Mason wrote: Changes in version 2 incorporate Olof's comments regarding: * the removal of all Reviewed-by lines not occurring on external mailing lists * reordering of s-o-b lines * modification of the device tree file to use labels when enabling * increated description of the modification to the MAINTAINERS entry Also, modifying the to and cc recepients so that everyone is receving all of the patches. -- This patch series adds support for the Broadcom Northstar Plus family of SoCs. NSP is a Cortex A9 based SoC under the Broadcom iProc family. Jon Mason (5): dt-bindings: Create Documentation for NSP DT bindings ARM: NSP: add minimal Northstar Plus device tree ARM: NSP: Add basic support for Broadcom Northstar Plus SoC ARM: multi_v7_defconfig: Add NSP to defconfig MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs .../devicetree/bindings/arm/bcm/brcm,nsp.txt | 34 +++ MAINTAINERS| 12 ++- arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/bcm-nsp.dtsi | 105 + arch/arm/boot/dts/bcm958625k.dts | 57 +++ arch/arm/configs/multi_v7_defconfig| 1 + arch/arm/mach-bcm/Kconfig | 14 +++ arch/arm/mach-bcm/Makefile | 5 +- arch/arm/mach-bcm/bcm_nsp.c| 25 + 9 files changed, 252 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi create mode 100644 arch/arm/boot/dts/bcm958625k.dts create mode 100644 arch/arm/mach-bcm/bcm_nsp.c -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] watchdog: bcm7038: add device tree binding documentation
Add device tree binding documentation for the watchdog hardware block
on bcm7038 and newer SoCs.
Signed-off-by: Justin Chen justinpo...@gmail.com
---
.../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
new file mode 100644
index 000..39e5cf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
@@ -0,0 +1,19 @@
+BCM7038 Watchdog timer
+
+Required properties:
+
+- compatible : should be brcm,bcm7038-wdt
+- reg : Specifies base physical address and size of the registers.
+
+Optional properties:
+
+- clocks: The clock running the watchdog. If no clock is found the
+ driver will default to 2700 HZ.
+
+Example:
+
+watchdog {
+ compatible = brcm,bcm7038-wdt;
+ clocks = upg_fixed;
+ reg = 0xf040a7e8 0x16;
+};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] watchdog: driver for BCM7038 and newer chips.
This driver is for a watchdog block contained in all Broadcom Set-top Box chips since BCM7038. BCM7038 was made public during the 2004 CES, and since then, many chips use this watchdog block including some cable modem chips. Changes since v1: Removed clock-frequency because it brought unnecessary complexity to the driver. Renamed a few variables. Patch 1: watchdog device tree binding documentation Patch 2: watchdog driver Justin Chen (2): watchdog: bcm7038: add device tree binding documentation watchdog: Watchdog driver for Broadcom Set-Top Box .../bindings/watchdog/brcm,bcm7038-wdt.txt | 19 ++ drivers/watchdog/Kconfig | 8 + drivers/watchdog/Makefile | 1 + drivers/watchdog/bcm7038_wdt.c | 235 + 4 files changed, 263 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt create mode 100644 drivers/watchdog/bcm7038_wdt.c -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box
Watchdog driver for Broadcom 7038 and newer chips.
Signed-off-by: Justin Chen justinpo...@gmail.com
---
drivers/watchdog/Kconfig | 8 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm7038_wdt.c | 235 +
3 files changed, 244 insertions(+)
create mode 100644 drivers/watchdog/bcm7038_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 241fafd..4fbe8ab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1291,6 +1291,14 @@ config BCM_KONA_WDT_DEBUG
If in doubt, say 'N'.
+config BCM7038_WDT
+ tristate BCM7038 Watchdog
+ select WATCHDOG_CORE
+ help
+Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
+
+Say 'Y or 'M' here to enable the driver.
+
config IMGPDC_WDT
tristate Imagination Technologies PDC Watchdog Timer
depends on HAS_IOMEM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 59ea9a1..65d4169 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
+obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm7038_wdt.c b/drivers/watchdog/bcm7038_wdt.c
new file mode 100644
index 000..5e54c1b
--- /dev/null
+++ b/drivers/watchdog/bcm7038_wdt.c
@@ -0,0 +1,235 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/init.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pm.h
+#include linux/watchdog.h
+
+#define WDT_START_10xff00
+#define WDT_START_20x00ff
+#define WDT_STOP_1 0xee00
+#define WDT_STOP_2 0x00ee
+
+#define WDT_TIMEOUT_REG0x0
+#define WDT_CMD_REG0x4
+
+#define WDT_MIN_TIMEOUT1 /* seconds */
+#define WDT_DEFAULT_TIMEOUT30 /* seconds */
+#define WDT_DEFAULT_RATE 2700
+
+struct bcm7038_watchdog {
+ void __iomem*base;
+ struct watchdog_device wdd;
+ u32 rate;
+ struct clk *clk;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+static void bcm7038_wdt_set_timeout_reg(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+ u32 timeout;
+
+ timeout = wdt-rate * wdog-timeout;
+
+ writel(timeout, wdt-base + WDT_TIMEOUT_REG);
+}
+
+static int bcm7038_wdt_ping(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+ writel(WDT_START_1, wdt-base + WDT_CMD_REG);
+ writel(WDT_START_2, wdt-base + WDT_CMD_REG);
+
+ return 0;
+}
+
+static int bcm7038_wdt_start(struct watchdog_device *wdog)
+{
+ bcm7038_wdt_set_timeout_reg(wdog);
+ bcm7038_wdt_ping(wdog);
+
+ return 0;
+}
+
+static int bcm7038_wdt_stop(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+ writel(WDT_STOP_1, wdt-base + WDT_CMD_REG);
+ writel(WDT_STOP_2, wdt-base + WDT_CMD_REG);
+
+ return 0;
+}
+
+static int bcm7038_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int t)
+{
+ /* Can't modify timeout value if watchdog timer is running */
+ bcm7038_wdt_stop(wdog);
+ wdog-timeout = t;
+ bcm7038_wdt_start(wdog);
+
+ return 0;
+}
+
+static unsigned int bcm7038_wdt_get_timeleft(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+ u32 time_left;
+
+ time_left = readl(wdt-base + WDT_CMD_REG);
+
+ return time_left / wdt-rate;
+}
+
+static struct watchdog_info bcm7038_wdt_info = {
+ .identity = Broadcom BCM7038 Watchdog Timer,
+ .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+ WDIOF_MAGICCLOSE
+};
+
+static struct watchdog_ops bcm7038_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = bcm7038_wdt_start,
+ .stop = bcm7038_wdt_stop,
+ .set_timeout= bcm7038_wdt_set_timeout,
+ .get_timeleft =
[PATCH v2 0/2] watchdog: driver for BCM7038 and newer chips.
This driver is for a watchdog block contained in all Broadcom Set-top Box chips since BCM7038. BCM7038 was made public during the 2004 CES, and since then, many chips use this watchdog block including some cable modem chips. Changes since v1: Removed clock-frequency because it brought unnecessary complexity to the driver. Renamed a few variables. Patch 1: watchdog device tree binding documentation Patch 2: watchdog driver Justin Chen (2): watchdog: bcm7038: add device tree binding documentation watchdog: Watchdog driver for Broadcom Set-Top Box .../bindings/watchdog/brcm,bcm7038-wdt.txt | 19 ++ drivers/watchdog/Kconfig | 8 + drivers/watchdog/Makefile | 1 + drivers/watchdog/bcm7038_wdt.c | 235 + 4 files changed, 263 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt create mode 100644 drivers/watchdog/bcm7038_wdt.c -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box
Watchdog driver for Broadcom 7038 and newer chips.
Signed-off-by: Justin Chen justinpo...@gmail.com
---
drivers/watchdog/Kconfig | 8 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm7038_wdt.c | 235 +
3 files changed, 244 insertions(+)
create mode 100644 drivers/watchdog/bcm7038_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 241fafd..4fbe8ab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1291,6 +1291,14 @@ config BCM_KONA_WDT_DEBUG
If in doubt, say 'N'.
+config BCM7038_WDT
+ tristate BCM7038 Watchdog
+ select WATCHDOG_CORE
+ help
+Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
+
+Say 'Y or 'M' here to enable the driver.
+
config IMGPDC_WDT
tristate Imagination Technologies PDC Watchdog Timer
depends on HAS_IOMEM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 59ea9a1..65d4169 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
+obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm7038_wdt.c b/drivers/watchdog/bcm7038_wdt.c
new file mode 100644
index 000..5e54c1b
--- /dev/null
+++ b/drivers/watchdog/bcm7038_wdt.c
@@ -0,0 +1,235 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/init.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pm.h
+#include linux/watchdog.h
+
+#define WDT_START_10xff00
+#define WDT_START_20x00ff
+#define WDT_STOP_1 0xee00
+#define WDT_STOP_2 0x00ee
+
+#define WDT_TIMEOUT_REG0x0
+#define WDT_CMD_REG0x4
+
+#define WDT_MIN_TIMEOUT1 /* seconds */
+#define WDT_DEFAULT_TIMEOUT30 /* seconds */
+#define WDT_DEFAULT_RATE 2700
+
+struct bcm7038_watchdog {
+ void __iomem*base;
+ struct watchdog_device wdd;
+ u32 rate;
+ struct clk *clk;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+static void bcm7038_wdt_set_timeout_reg(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+ u32 timeout;
+
+ timeout = wdt-rate * wdog-timeout;
+
+ writel(timeout, wdt-base + WDT_TIMEOUT_REG);
+}
+
+static int bcm7038_wdt_ping(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+ writel(WDT_START_1, wdt-base + WDT_CMD_REG);
+ writel(WDT_START_2, wdt-base + WDT_CMD_REG);
+
+ return 0;
+}
+
+static int bcm7038_wdt_start(struct watchdog_device *wdog)
+{
+ bcm7038_wdt_set_timeout_reg(wdog);
+ bcm7038_wdt_ping(wdog);
+
+ return 0;
+}
+
+static int bcm7038_wdt_stop(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+ writel(WDT_STOP_1, wdt-base + WDT_CMD_REG);
+ writel(WDT_STOP_2, wdt-base + WDT_CMD_REG);
+
+ return 0;
+}
+
+static int bcm7038_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int t)
+{
+ /* Can't modify timeout value if watchdog timer is running */
+ bcm7038_wdt_stop(wdog);
+ wdog-timeout = t;
+ bcm7038_wdt_start(wdog);
+
+ return 0;
+}
+
+static unsigned int bcm7038_wdt_get_timeleft(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+ u32 time_left;
+
+ time_left = readl(wdt-base + WDT_CMD_REG);
+
+ return time_left / wdt-rate;
+}
+
+static struct watchdog_info bcm7038_wdt_info = {
+ .identity = Broadcom BCM7038 Watchdog Timer,
+ .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+ WDIOF_MAGICCLOSE
+};
+
+static struct watchdog_ops bcm7038_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = bcm7038_wdt_start,
+ .stop = bcm7038_wdt_stop,
+ .set_timeout= bcm7038_wdt_set_timeout,
+ .get_timeleft =
[PATCH v2 1/2] watchdog: bcm7038: add device tree binding documentation
Add device tree binding documentation for the watchdog hardware block
on bcm7038 and newer SoCs.
Signed-off-by: Justin Chen justinpo...@gmail.com
---
.../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
new file mode 100644
index 000..39e5cf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
@@ -0,0 +1,19 @@
+BCM7038 Watchdog timer
+
+Required properties:
+
+- compatible : should be brcm,bcm7038-wdt
+- reg : Specifies base physical address and size of the registers.
+
+Optional properties:
+
+- clocks: The clock running the watchdog. If no clock is found the
+ driver will default to 2700 HZ.
+
+Example:
+
+watchdog {
+ compatible = brcm,bcm7038-wdt;
+ clocks = upg_fixed;
+ reg = 0xf040a7e8 0x16;
+};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box
Gah, sorry, my email client did something really weird. Sorry for the duplication, please don't reply to those. -- Gregory-- 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
[RFC PATCH 3/5] Documentation: dt-bindings: add YAML eeprom binding
Convert the eeprom.txt binding to standard YAML DT
binding format.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Documentation/devicetree/bindings/eeprom.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom.yaml
diff --git a/Documentation/devicetree/bindings/eeprom.yaml
b/Documentation/devicetree/bindings/eeprom.yaml
new file mode 100644
index 000..bf1244b
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom.yaml
@@ -0,0 +1,44 @@
+%YAML 1.2
+---
+id: eeprom-i2c
+
+title: EEPROMs (I2C)
+
+compatible:
+ - name: manufacturer,24c00
+ - name: manufacturer,24c01
+ - name: manufacturer,24c02
+ - name: manufacturer,24c04
+ - name: manufacturer,24c08
+ - name: manufacturer,24c16
+ - name: manufacturer,24c32
+ - name: manufacturer,24c64
+ - name: manufacturer,24c128
+ - name: manufacturer,24c256
+ - name: manufacturer,24c512
+ - name: manufacturer,24c1024
+ - name: manufacturer,spd
+
+required:
+ - name: reg
+description: the I2c address of the EEPROM
+
+optional:
+ - name: pagesize
+description:
+ the length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong value
+ may result in data loss! If not specified, a safety value of
+ '1' is used which will be very slow.
+ - name: read-only
+description:
+ this parameterless property disables writes to the eeprom
+
+example:
+ - dts: |
+ eeprom@52 {
+ compatible = atmel,24c32;
+ reg = 0x52;
+ pagesize = 32;
+ };
+...
--
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
[RFC PATCH 0/5] DT binding documents using text markup
During the Device Tree microconference at Linux Plumbers 2015, we had a short discussion about how to improve DT Binding Documentation. A number of issues were raised (again, as these things have been discussed in the past) including: * Inconsistency between binding documents due to prose text format. * Inability to reliably machine read bindings for mass update or search. * Bit rot of bindings as new conventions are agreed upon but only new bindings are changed. Grant Likely probably summed up the issue best with ...as long as bindings are human readable, we'll have issues The context of that comment was, of course, regarding our current documents written in very inconsistent prose style. When the topic of needing the bindings in a rigid format was raised, there was general head nodding that this was needed. It was noted that this has been discussed many times before and nothing has been done. My proposed solution to the problem is to convert all DT bindings a rigid text markup format. In choosing a text markup language my requirements were: 1) Human readable 2) Well documented 3) Easy to translate to other data formats 4) Well supported by tools and libraries After looking at a number of markup options, YAML stood out as the one that meets all of these requirements. The YAML syntax is adopted in many projects specifically because of the high level of readability. A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html. There's a number of tools to convert between YAML and other popular data formats such as JSON and XML. XML was cited by Behan Webster during the microconference as an important data format as the type of developers that may produce comprehensive DTS Binding validation tools will want to use XML. Every major scripting language has a high level binding to the low level libyaml C library to facilitate handling of YAML data files. One caveat with YAML is it does not tolerate tabs. Yes, I said it. No tabs! This can be managed with proper editor modes and also with helper scripts to strip tabs to aid in people passing planned checkpatch.pl checks that would run YAML DT Binding specific tag validators for new bindings. The scope of the initial YAML DT Binding format was specifically limited to supporting *only* the content we have in bindings today. The idea here is to propose and agree on something that will take us just a few steps in the right direction. If we move *all* current binding content to a machine parseable format, additional features can be added with more automation and scripting. As it stands today, because of the inconsistency of the wording of the files, we can't add a lot of new features to the content until we convert what we have today into a standard format. With that said, it should be noted that some new features such as type tags to indicate cell types could be added to support additional DTS validation beyond what the current content supports. Another possibility is adding range type information to validate the legal values for a cell. This series is broken up into three major parts: 1) The documentation defining the YAML DT binding format 2) A skeleton device binding example illustrating use of this format 3) Some real binding conversions (eeprom.txt, phy-bindings.txt, and ti-phy.txt As a proof of concept of what can be done with a proper machine readable DT binding source file, there's a simple markdown document generator at https://github.com/konsulko/dtgendoc. Also, to see actual output from the generator, the generated markdown from those bindings is viewable at https://github.com/konsulko/dtgendoc/wiki There's a lot of other possibilities for validation tools using only the data we have today in the bindings. In addition, Frank Rowand covered some DT debug techniques that would benefit from the binding documentation being 100% reliably searchable. I found it useful to see a side-by-side view of a converted doc versus the original content, so here's a screenshot of eeprom.txt vs. eeprom.yaml: https://github.com/konsulko/dtgendoc/wiki#eepromtxt-vs-eepromyaml When we decide on a text markup format that is acceptable, then the next step is to convert all the bindings. That process would start with the complete set of generic bindings as they will be referenced by the actual device bindings. If the RFC wasn't explicit enough...comments welcome. -Matt Matt Porter (5): Documentation: dt-bindings: add documentation on new DT binding format Documentation: dt-bindings: add example DT binding document Documentation: dt-bindings: add YAML eeprom binding Documentation: dt-bindings: phy: add YAML generic PHY binding Documentation: dt-bindings: phy: add YAML TI PHY binding .../devicetree/bindings/dt-binding-format.txt | 106 + Documentation/devicetree/bindings/eeprom.yaml | 44 ++
[RFC PATCH 5/5] Documentation: dt-bindings: phy: add YAML TI PHY binding
Convert the ti-phy.txt binding to standard YAML DT binding
format. This binding references the YAML generic PHY binding.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Documentation/devicetree/bindings/phy/ti-phy.yaml | 166 ++
1 file changed, 166 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/ti-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.yaml
b/Documentation/devicetree/bindings/phy/ti-phy.yaml
new file mode 100644
index 000..ec93501
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti-phy.yaml
@@ -0,0 +1,166 @@
+%YAML 1.2
+---
+id: omap-control-phy
+
+title: OMAP Control PHY
+
+compatible:
+ - name: ti,control-phy-otghs
+description: if it has otghs_control mailbox register as on OMAP4.
+ - name: ti,control-phy-usb2
+description: if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ - name: ti,control-phy-pipe3
+description: if it has DPLL and individual Rx Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ - name: ti,control-phy-pcie
+description: for pcie to support external clock for pcie and to
+ set PCS delay value. e.g. PCIE PHY in DRA7x
+ - name: ti,control-phy-usb2-dra7
+description: if it has power down register like USB2 PHY on DRA7
+ DRA7 platform.
+ - name: ti,control-phy-usb2-am437
+description: if it has power down register like USB2 PHY on AM437
+ platform.
+required:
+ - name: reg
+description: register ranges as listed in the reg-names property
+ - name: reg-names
+description:
+ otghs_control for control-phy-otghs power,
+ pcie_pcs and control_sma for control-phy-pcie
+ power for all other types
+
+example:
+ - dts: |
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,control-phy-otghs;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
+ };
+...
+
+---
+id: omap-usb2-phy
+
+title: OMAP USB2 PHY
+
+compatible:
+ - name: ti,omap-usb2
+
+required:
+ - name: reg
+description:
+ Address and length of the register set for the device.
+ - name: #phy-cells
+description:
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+ - name: clocks
+description:
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+ - name: clock-names
+description:
+ should include:
+ * wkupclk - wakeup clock.
+ * refclk - reference clock (optional).
+reference: clock-consumer
+
+optional:
+ - name: ctrl-module
+description:
+ phandle of the control module used by PHY driver to
+ power on the PHY.
+
+example:
+ - dts: |
+ usb2phy@4a0ad080 {
+compatible = ti,omap-usb2;
+reg = 0x4a0ad080 0x58;
+ctrl-module = omap_control_usb;
+#phy-cells = 0;
+clocks = usb_phy_cm_clk32k, usb_otg_ss_refclk960m;
+clock-names = wkupclk, refclk;
+ };
+description:
+ This is usually a subnode of ocp2scp to which it is
+ connected.
+...
+
+---
+id: ti-pipe3-phy
+
+title: TI Pipe3 PHY
+
+compatible:
+ - name: ti,phy-usb3
+ - name: ti,phy-pipe3-sata
+ - name: ti,phy-pipe3-pcie
+ - deprecated: ti,omap-usb3
+
+required:
+ - name: reg
+description:
+ Address and length of the register set for the device.
+ - name: reg-names
+description:
+ The names of the register addresses corresponding to
+ the registers filled in reg.
+ - name: #phy-cells
+description:
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+ - name: clocks
+description:
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+ - name: clock-names
+description:
+ should include:
+ * wkupclk - wakeup clock.
+ * sysclk - system clock.
+ * refclk - reference clock.
+ * dpll_ref - external dpll ref clk
+ * dpll_ref_m2 - external dpll ref clk
+ * phy-div - divider for apll
+ * div-clk - apll clock
+reference: clock-consumer
+
+optional:
+ - name: ctrl-module
+description:
+ phandle of the control module used by PHY driver to
+ power on the PHY.
+ - name: id
+description:
+ If there are multiple instance
[RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format
Documentation explaining the syntax and format of the YAML-based DT binding documentation. Signed-off-by: Matt Porter mpor...@konsulko.com --- .../devicetree/bindings/dt-binding-format.txt | 106 + 1 file changed, 106 insertions(+) create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt b/Documentation/devicetree/bindings/dt-binding-format.txt new file mode 100644 index 000..f9acc22 --- /dev/null +++ b/Documentation/devicetree/bindings/dt-binding-format.txt @@ -0,0 +1,106 @@ +-- +Device Tree Binding Format +-- + +Background +-- + +DT bindings historically were written as text in prose format which +led to issues in usability of that source documentation. Some of +these issues include the need to programmatically process binding +source documentation to do DTS validation, perform mass updates to +format/style, and to generate publishable documentation in HTML or +PDF form. + +Overview + + +The DT binding format is based on the YAML text markup language. +Although there are many text markup options available, YAML +fulfills all requirements considered for a DT binding source format +which include: + +1) Must be human readable +2) Must be easily translated to other data formats (XML, JSON, etc). +3) Must have sufficient tools and libraries to enable developers to + build new tools for DT binding processing +4) Must have a complete spec to refer to syntax + +YAML is documentated in the specification found at +http://www.yaml.org/spec/1.2/spec.html + +The required YAML DT binding tag format and syntax are defined in +the following sections. + +YAML DT Binding Syntax +-- + +* Lines starting with # are comments and not part of the binding itself +* %YAML 1.2 starts a file, indicating the version of YAML in use +* --- starts a binding document +* ... ends a binding document +* Multiple binding documents may exist in a single file +* Tabs are not permitted +* Scope is denoted by indentation of two spaces +* Key value pairs are denoted by key: value +* Sequences are denoted by - +* Scalar values may convert newlines to spaces and preserve blank + lines for long description formatting using +* Scalar values may escape all reserved characters and preserve + newlines by using | to denote literal style + +For additional information on YAML syntax, refer to the specification +at http://www.yaml.org/spec/1.2/spec.html + +YAML DT Binding Format +-- + +The following YAML types are supported in the DT binding format: + +* [R] id: unique identifier in property form (e.g. skel-device) + +* [R] title: title of the binding + +* [O] maintainer: sequence of maintainers + [R] name: name and email of maintainer or mailing list in RFC822 +form. + +* [O] description: full description of the binding + +* [O] compatible: sequence of valid compatible descriptors + [R] name: the compatible string surrounded in double quotes + [O] deprecated: a deprecated compatible string surrounded in + double quotes + [O] description: description of the compatible string + +* [O] required: sequence of required properties: + [R] name: name of the property surrounded in double quotes + [R] description: description of the property + [O] reference: optional reference to a binding id + +* [O] optional: sequence of optional properties: + [R] name: name of the property surrounded in double quotes + [R] description: description of the property + [O] reference: optional reference to a binding id + +* [O] deprecated: sequence of deprecated properties: + [R] name: name of the property surrounded in double quotes + [R] description: description of the property + [O] reference: optional reference to a binding id + +* [R] example: sequence of examples: + [R] dts: DT source of example usage. The example text must use + literal style (|) so that it retains indentation and + newlines. + [O] description: description of the example + +Note: [R] and [O] denote required and optional fields, respectively. + +Skeleton Binding + + +The skeleton.yaml binding found in the top of the DT binding tree +is the canonical example of syntax and format to use when writing +a DT binding document. It is maintained with the latest formatting +conventions, making it the best starting point when writing a new DT +binding. -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe devicetree-spec in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/5] DT binding documents using text markup
During the Device Tree microconference at Linux Plumbers 2015, we had a short discussion about how to improve DT Binding Documentation. A number of issues were raised (again, as these things have been discussed in the past) including: * Inconsistency between binding documents due to prose text format. * Inability to reliably machine read bindings for mass update or search. * Bit rot of bindings as new conventions are agreed upon but only new bindings are changed. Grant Likely probably summed up the issue best with ...as long as bindings are human readable, we'll have issues The context of that comment was, of course, regarding our current documents written in very inconsistent prose style. When the topic of needing the bindings in a rigid format was raised, there was general head nodding that this was needed. It was noted that this has been discussed many times before and nothing has been done. My proposed solution to the problem is to convert all DT bindings a rigid text markup format. In choosing a text markup language my requirements were: 1) Human readable 2) Well documented 3) Easy to translate to other data formats 4) Well supported by tools and libraries After looking at a number of markup options, YAML stood out as the one that meets all of these requirements. The YAML syntax is adopted in many projects specifically because of the high level of readability. A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html. There's a number of tools to convert between YAML and other popular data formats such as JSON and XML. XML was cited by Behan Webster during the microconference as an important data format as the type of developers that may produce comprehensive DTS Binding validation tools will want to use XML. Every major scripting language has a high level binding to the low level libyaml C library to facilitate handling of YAML data files. One caveat with YAML is it does not tolerate tabs. Yes, I said it. No tabs! This can be managed with proper editor modes and also with helper scripts to strip tabs to aid in people passing planned checkpatch.pl checks that would run YAML DT Binding specific tag validators for new bindings. The scope of the initial YAML DT Binding format was specifically limited to supporting *only* the content we have in bindings today. The idea here is to propose and agree on something that will take us just a few steps in the right direction. If we move *all* current binding content to a machine parseable format, additional features can be added with more automation and scripting. As it stands today, because of the inconsistency of the wording of the files, we can't add a lot of new features to the content until we convert what we have today into a standard format. With that said, it should be noted that some new features such as type tags to indicate cell types could be added to support additional DTS validation beyond what the current content supports. Another possibility is adding range type information to validate the legal values for a cell. This series is broken up into three major parts: 1) The documentation defining the YAML DT binding format 2) A skeleton device binding example illustrating use of this format 3) Some real binding conversions (eeprom.txt, phy-bindings.txt, and ti-phy.txt As a proof of concept of what can be done with a proper machine readable DT binding source file, there's a simple markdown document generator at https://github.com/konsulko/dtgendoc. Also, to see actual output from the generator, the generated markdown from those bindings is viewable at https://github.com/konsulko/dtgendoc/wiki There's a lot of other possibilities for validation tools using only the data we have today in the bindings. In addition, Frank Rowand covered some DT debug techniques that would benefit from the binding documentation being 100% reliably searchable. I found it useful to see a side-by-side view of a converted doc versus the original content, so here's a screenshot of eeprom.txt vs. eeprom.yaml: https://github.com/konsulko/dtgendoc/wiki#eepromtxt-vs-eepromyaml When we decide on a text markup format that is acceptable, then the next step is to convert all the bindings. That process would start with the complete set of generic bindings as they will be referenced by the actual device bindings. If the RFC wasn't explicit enough...comments welcome. -Matt Matt Porter (5): Documentation: dt-bindings: add documentation on new DT binding format Documentation: dt-bindings: add example DT binding document Documentation: dt-bindings: add YAML eeprom binding Documentation: dt-bindings: phy: add YAML generic PHY binding Documentation: dt-bindings: phy: add YAML TI PHY binding .../devicetree/bindings/dt-binding-format.txt | 106 + Documentation/devicetree/bindings/eeprom.yaml | 44 ++
[RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
Add a skeleton DT binding document that serves as the canonical
example for implementing YAML-based DT bindings documentation.
The skeleton binding illustrates use of all fields and variations
described in the dt-binding-format.txt documentation.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Documentation/devicetree/bindings/skeleton.yaml | 98 +
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
diff --git a/Documentation/devicetree/bindings/skeleton.yaml
b/Documentation/devicetree/bindings/skeleton.yaml
new file mode 100644
index 000..175965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/skeleton.yaml
@@ -0,0 +1,98 @@
+%YAML 1.2
+---
+id: skel-device
+
+title: Skeleton Device
+
+maintainer:
+ - name: Skeleton Person s...@kernel.org
+
+description:
+ The Skeleton Device binding represents the SK11 device produced by
+ the Skeleton Corporation. The binding can also support compatible
+ clones made by second source vendors.
+
+compatible:
+ - name: skel,sk11
+ - name: faux,fx11
+description: A clone of the original sk11 device
+
+required:
+ - name: reg
+description: chip select address of skeleton device
+reference: spi-slave
+ - name: spi-max-frequency
+description:
+ Maximum SPI clocking speed of skeleton device in Hz, must be
+ 100
+reference: spi-slave
+
+optional:
+ - name: spi-cs-high
+description:
+ Set if skeleton device configuration straps are set for chip
+ select polarity high
+reference: spi-slave
+
+deprecated:
+ - name: skel,deprecated1
+description:
+ First of two deprecated properties.
+ - name: skel,deprecated2
+description:
+ Second of two deprecated properties.
+
+example:
+ - dts: |
+ sk11@0 {
+ compatible = skel,sk11;
+ reg = 0;
+ spi-max-frequency = 100;
+ spi-cs-high;
+ };
+...
+
+---
+id: skel-mini
+
+title: Skeleton Mini Device
+
+maintainer:
+ - name: Rogue Developer ro...@gmail.com
+
+description:
+ The Skeleton Mini Device binding represents the SK47x series devices
+ produced by the Skeleton Corporation.
+
+compatible:
+ - name: skel,sk472
+ - name: skel,sk473
+ - name: skel,sk474
+ - deprecated: skel,sk47x
+
+required:
+ - name: reg
+description: offset and length of the registers
+
+optional:
+ - name: skel,sync-mode
+description: Enable synchronous transfer mode
+
+example:
+ - dts: |
+ sk472@beef {
+ compatible = skel,sk472;
+ reg = 0xbeef 0x100;
+ };
+description:
+ Demonstrates an SK472 in normal mode.
+
+ - dts: |
+ sk474@dead {
+ compatible = skel,sk474;
+ reg = 0xdead 0x100;
+ skel,sync-mode;
+ };
+description:
+ Demonstrates an SK474 in synchronous mode.
+...
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe devicetree-spec in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/5] Documentation: dt-bindings: phy: add YAML generic PHY binding
Convert the generic phy-bindings.txt binding to standard YAML
DT binding format.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
.../devicetree/bindings/phy/phy-bindings.yaml | 89 ++
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.yaml
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.yaml
b/Documentation/devicetree/bindings/phy/phy-bindings.yaml
new file mode 100644
index 000..9b164d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.yaml
@@ -0,0 +1,89 @@
+%YAML 1.2
+---
+id: phy-device
+
+title: PHY device
+
+description:
+ This document explains only the device tree data binding. For general
+ information about PHY subsystem refer to Documentation/phy.txt
+
+required:
+ - name: #phy-cells
+description:
+ number of cells in a PHY specifier. The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+optional:
+ - name: phy-supply
+description:
+ phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+example:
+ - dts: |
+ phys: phy {
+ compatible = xxx;
+ reg = ...;
+ .
+ .
+ #phy-cells = 1;
+ .
+ .
+ };
+description:
+ Describes an IP block (PHY provider) that implements 2 different
+ PHYs. In order to differentiate between these 2 PHYs, an
+ additional specifier should be given while trying to get a
+ reference to it.
+...
+
+---
+id: phy-user
+
+title: PHY user
+
+required:
+ - name: phys
+description:
+ the phandle for the PHY device (used by the PHY subsystem)
+ - name: phy-names
+description:
+ the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+example:
+ - dts: |
+ usb1: usb_otg_ss@xxx {
+ compatible = xxx;
+ reg = xxx;
+ .
+ .
+ phys = usb2_phy, usb3_phy;
+ phy-names = usb2phy, usb3phy;
+ .
+ .
+ };
+description:
+ Represents a controller that uses two PHYs, one for usb2 and one
+ for usb3.
+
+ - dts: |
+ usb2: usb_otg_ss@xxx {
+ compatible = xxx;
+ reg = xxx;
+ .
+ .
+ phys = phys 1;
+ phy-names = usbphy;
+ .
+ .
+ };
+description:
+ Represents a controller that uses one of the PHYs of the PHY
+ provider device defined previously. Note that the phy handle
+ has an additional specifier 1 to differentiate between the
+ two PHYs.
+...
--
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
[RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
Add a skeleton DT binding document that serves as the canonical
example for implementing YAML-based DT bindings documentation.
The skeleton binding illustrates use of all fields and variations
described in the dt-binding-format.txt documentation.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Documentation/devicetree/bindings/skeleton.yaml | 98 +
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
diff --git a/Documentation/devicetree/bindings/skeleton.yaml
b/Documentation/devicetree/bindings/skeleton.yaml
new file mode 100644
index 000..175965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/skeleton.yaml
@@ -0,0 +1,98 @@
+%YAML 1.2
+---
+id: skel-device
+
+title: Skeleton Device
+
+maintainer:
+ - name: Skeleton Person s...@kernel.org
+
+description:
+ The Skeleton Device binding represents the SK11 device produced by
+ the Skeleton Corporation. The binding can also support compatible
+ clones made by second source vendors.
+
+compatible:
+ - name: skel,sk11
+ - name: faux,fx11
+description: A clone of the original sk11 device
+
+required:
+ - name: reg
+description: chip select address of skeleton device
+reference: spi-slave
+ - name: spi-max-frequency
+description:
+ Maximum SPI clocking speed of skeleton device in Hz, must be
+ 100
+reference: spi-slave
+
+optional:
+ - name: spi-cs-high
+description:
+ Set if skeleton device configuration straps are set for chip
+ select polarity high
+reference: spi-slave
+
+deprecated:
+ - name: skel,deprecated1
+description:
+ First of two deprecated properties.
+ - name: skel,deprecated2
+description:
+ Second of two deprecated properties.
+
+example:
+ - dts: |
+ sk11@0 {
+ compatible = skel,sk11;
+ reg = 0;
+ spi-max-frequency = 100;
+ spi-cs-high;
+ };
+...
+
+---
+id: skel-mini
+
+title: Skeleton Mini Device
+
+maintainer:
+ - name: Rogue Developer ro...@gmail.com
+
+description:
+ The Skeleton Mini Device binding represents the SK47x series devices
+ produced by the Skeleton Corporation.
+
+compatible:
+ - name: skel,sk472
+ - name: skel,sk473
+ - name: skel,sk474
+ - deprecated: skel,sk47x
+
+required:
+ - name: reg
+description: offset and length of the registers
+
+optional:
+ - name: skel,sync-mode
+description: Enable synchronous transfer mode
+
+example:
+ - dts: |
+ sk472@beef {
+ compatible = skel,sk472;
+ reg = 0xbeef 0x100;
+ };
+description:
+ Demonstrates an SK472 in normal mode.
+
+ - dts: |
+ sk474@dead {
+ compatible = skel,sk474;
+ reg = 0xdead 0x100;
+ skel,sync-mode;
+ };
+description:
+ Demonstrates an SK474 in synchronous mode.
+...
--
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
[RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format
Documentation explaining the syntax and format of the YAML-based DT binding documentation. Signed-off-by: Matt Porter mpor...@konsulko.com --- .../devicetree/bindings/dt-binding-format.txt | 106 + 1 file changed, 106 insertions(+) create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt b/Documentation/devicetree/bindings/dt-binding-format.txt new file mode 100644 index 000..f9acc22 --- /dev/null +++ b/Documentation/devicetree/bindings/dt-binding-format.txt @@ -0,0 +1,106 @@ +-- +Device Tree Binding Format +-- + +Background +-- + +DT bindings historically were written as text in prose format which +led to issues in usability of that source documentation. Some of +these issues include the need to programmatically process binding +source documentation to do DTS validation, perform mass updates to +format/style, and to generate publishable documentation in HTML or +PDF form. + +Overview + + +The DT binding format is based on the YAML text markup language. +Although there are many text markup options available, YAML +fulfills all requirements considered for a DT binding source format +which include: + +1) Must be human readable +2) Must be easily translated to other data formats (XML, JSON, etc). +3) Must have sufficient tools and libraries to enable developers to + build new tools for DT binding processing +4) Must have a complete spec to refer to syntax + +YAML is documentated in the specification found at +http://www.yaml.org/spec/1.2/spec.html + +The required YAML DT binding tag format and syntax are defined in +the following sections. + +YAML DT Binding Syntax +-- + +* Lines starting with # are comments and not part of the binding itself +* %YAML 1.2 starts a file, indicating the version of YAML in use +* --- starts a binding document +* ... ends a binding document +* Multiple binding documents may exist in a single file +* Tabs are not permitted +* Scope is denoted by indentation of two spaces +* Key value pairs are denoted by key: value +* Sequences are denoted by - +* Scalar values may convert newlines to spaces and preserve blank + lines for long description formatting using +* Scalar values may escape all reserved characters and preserve + newlines by using | to denote literal style + +For additional information on YAML syntax, refer to the specification +at http://www.yaml.org/spec/1.2/spec.html + +YAML DT Binding Format +-- + +The following YAML types are supported in the DT binding format: + +* [R] id: unique identifier in property form (e.g. skel-device) + +* [R] title: title of the binding + +* [O] maintainer: sequence of maintainers + [R] name: name and email of maintainer or mailing list in RFC822 +form. + +* [O] description: full description of the binding + +* [O] compatible: sequence of valid compatible descriptors + [R] name: the compatible string surrounded in double quotes + [O] deprecated: a deprecated compatible string surrounded in + double quotes + [O] description: description of the compatible string + +* [O] required: sequence of required properties: + [R] name: name of the property surrounded in double quotes + [R] description: description of the property + [O] reference: optional reference to a binding id + +* [O] optional: sequence of optional properties: + [R] name: name of the property surrounded in double quotes + [R] description: description of the property + [O] reference: optional reference to a binding id + +* [O] deprecated: sequence of deprecated properties: + [R] name: name of the property surrounded in double quotes + [R] description: description of the property + [O] reference: optional reference to a binding id + +* [R] example: sequence of examples: + [R] dts: DT source of example usage. The example text must use + literal style (|) so that it retains indentation and + newlines. + [O] description: description of the example + +Note: [R] and [O] denote required and optional fields, respectively. + +Skeleton Binding + + +The skeleton.yaml binding found in the top of the DT binding tree +is the canonical example of syntax and format to use when writing +a DT binding document. It is maintained with the latest formatting +conventions, making it the best starting point when writing a new DT +binding. -- 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
[RFC PATCH 5/5] Documentation: dt-bindings: phy: add YAML TI PHY binding
Convert the ti-phy.txt binding to standard YAML DT binding
format. This binding references the YAML generic PHY binding.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Documentation/devicetree/bindings/phy/ti-phy.yaml | 166 ++
1 file changed, 166 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/ti-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.yaml
b/Documentation/devicetree/bindings/phy/ti-phy.yaml
new file mode 100644
index 000..ec93501
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti-phy.yaml
@@ -0,0 +1,166 @@
+%YAML 1.2
+---
+id: omap-control-phy
+
+title: OMAP Control PHY
+
+compatible:
+ - name: ti,control-phy-otghs
+description: if it has otghs_control mailbox register as on OMAP4.
+ - name: ti,control-phy-usb2
+description: if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ - name: ti,control-phy-pipe3
+description: if it has DPLL and individual Rx Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ - name: ti,control-phy-pcie
+description: for pcie to support external clock for pcie and to
+ set PCS delay value. e.g. PCIE PHY in DRA7x
+ - name: ti,control-phy-usb2-dra7
+description: if it has power down register like USB2 PHY on DRA7
+ DRA7 platform.
+ - name: ti,control-phy-usb2-am437
+description: if it has power down register like USB2 PHY on AM437
+ platform.
+required:
+ - name: reg
+description: register ranges as listed in the reg-names property
+ - name: reg-names
+description:
+ otghs_control for control-phy-otghs power,
+ pcie_pcs and control_sma for control-phy-pcie
+ power for all other types
+
+example:
+ - dts: |
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,control-phy-otghs;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
+ };
+...
+
+---
+id: omap-usb2-phy
+
+title: OMAP USB2 PHY
+
+compatible:
+ - name: ti,omap-usb2
+
+required:
+ - name: reg
+description:
+ Address and length of the register set for the device.
+ - name: #phy-cells
+description:
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+ - name: clocks
+description:
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+ - name: clock-names
+description:
+ should include:
+ * wkupclk - wakeup clock.
+ * refclk - reference clock (optional).
+reference: clock-consumer
+
+optional:
+ - name: ctrl-module
+description:
+ phandle of the control module used by PHY driver to
+ power on the PHY.
+
+example:
+ - dts: |
+ usb2phy@4a0ad080 {
+compatible = ti,omap-usb2;
+reg = 0x4a0ad080 0x58;
+ctrl-module = omap_control_usb;
+#phy-cells = 0;
+clocks = usb_phy_cm_clk32k, usb_otg_ss_refclk960m;
+clock-names = wkupclk, refclk;
+ };
+description:
+ This is usually a subnode of ocp2scp to which it is
+ connected.
+...
+
+---
+id: ti-pipe3-phy
+
+title: TI Pipe3 PHY
+
+compatible:
+ - name: ti,phy-usb3
+ - name: ti,phy-pipe3-sata
+ - name: ti,phy-pipe3-pcie
+ - deprecated: ti,omap-usb3
+
+required:
+ - name: reg
+description:
+ Address and length of the register set for the device.
+ - name: reg-names
+description:
+ The names of the register addresses corresponding to
+ the registers filled in reg.
+ - name: #phy-cells
+description:
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+ - name: clocks
+description:
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+ - name: clock-names
+description:
+ should include:
+ * wkupclk - wakeup clock.
+ * sysclk - system clock.
+ * refclk - reference clock.
+ * dpll_ref - external dpll ref clk
+ * dpll_ref_m2 - external dpll ref clk
+ * phy-div - divider for apll
+ * div-clk - apll clock
+reference: clock-consumer
+
+optional:
+ - name: ctrl-module
+description:
+ phandle of the control module used by PHY driver to
+ power on the PHY.
+ - name: id
+description:
+ If there are multiple instance
Re: [PATCH] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
Currently vmmc's property is wrong.
If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
(Card supply power and I/O Line supply Power.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ca7d168..4ddabfd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -461,10 +461,10 @@
mshc_0 {
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
-vmmc-supply = ldo20_reg buck8_reg;
+vmmc-supply = ldo20_reg;
+vqmmc-supply = buck8_reg;
Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
so it should be VQMMC?
If my schematics is right thing, buck8 is used LAN card power.
I will send after removing buck8_reg. how about?
Anyway, Thanks for pointing out. :)
I don't know who this regulator applied. I have guessed that it used for eMMC.
Sorry for guessing.
Best Regards,
Jaehoon Chung
In the same time I can't find on schematics where BUCK8 goes...
The SDHCI_2 node below looks good.
Best regards,
Krzysztof
mmc-pwrseq = emmc_pwrseq;
status = okay;
-
num-slots = 1;
broken-cd;
card-detect-delay = 200;
@@ -485,7 +485,8 @@
bus-width = 4;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
pinctrl-names = default;
-vmmc-supply = ldo4_reg ldo21_reg;
+vmmc-supply = ldo21_reg;
+vqmmc-supply = ldo4_reg;
cd-gpios = gpk2 2 0;
cd-inverted;
status = okay;
--
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 v6] arm64: dts: Add spi bus dts
Matthias,
On Mon, Aug 17, 2015 at 12:32 PM, Daniel Kurtz djku...@chromium.org wrote:
On Mon, Aug 17, 2015 at 11:29 AM, Leilk Liu leilk@mediatek.com wrote:
This patch adds MT8173 spi bus controllers into device tree.
Signed-off-by: Leilk Liu leilk@mediatek.com
Reviewed-by: Daniel Kurtz djku...@chromium.org
The other SPI patches have already been picked up in broonie's spi tree.
Can you pick this one into your mediatek tree?
Thanks.
-Dan
---
Change in this patch:
pinctl and pad-select fields are board specific, so move to
mt8173-evb.dtsi, and status = okay.
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12
2 files changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 4be66ca..811cb76 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -387,6 +387,24 @@
};
};
+pio {
+ spi_pins_a: spi0 {
+ pins_spi {
+ pinmux = MT8173_PIN_69_SPI_CK__FUNC_SPI_CK_0_,
+ MT8173_PIN_70_SPI_MI__FUNC_SPI_MI_0_,
+ MT8173_PIN_71_SPI_MO__FUNC_SPI_MO_0_,
+ MT8173_PIN_72_SPI_CS__FUNC_SPI_CS_0_;
+ };
+ };
+};
+
+spi {
+ pinctrl-names = default;
+ pinctrl-0 = spi_pins_a;
+ mediatek,pad-select = 0;
+ status = okay;
+};
+
uart0 {
status = okay;
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..3dfb6ed 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -365,6 +365,18 @@
status = disabled;
};
+ spi: spi@1100a000 {
+ compatible = mediatek,mt8173-spi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0 0x1100a000 0 0x1000;
+ interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_LOW;
+ clocks = topckgen CLK_TOP_SPI_SEL,
+topckgen CLK_TOP_SYSPLL3_D2;
+ clock-names = spi-clk, parent-clk;
+ status = disabled;
+ };
+
i2c3: i2c3@1101 {
compatible = mediatek,mt8173-i2c;
reg = 0 0x1101 0 0x70,
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Linus,
Am 12.08.2015 um 01:20 schrieb NeilBrown n...@brown.name:
On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
linus.wall...@linaro.org wrote:
Hi Neil,
first, this is a *VERY* interesting and much needed patch series,
I intend to look closer at it, and if possible test it with some
(heh) board file device. Would be happy of you put me on CC for these.
On Mon, May 11, 2015 at 3:56 AM, NeilBrown n...@brown.name wrote:
When a device is connected to a UART via RS-232 (or similar), there
is a DTR line that can be used for power management, and other modem
control lines.
On an embedded board, it is very likely that there is no DTR, and
any power management need to be done using some completely separate
mechanism.
So these slaves are really just for devices permanently attached to
UARTs without a full RS-232 (or similar) connection. The driver
does all the extra control beyond Tx/Rx.
What is usually happening (and I have seen it in a few places) is that
the SoC has *one* fully featured RS232 with CTS/RTS and even
DTS,DCD,RI and other esoterica, which is intended to be connected to a
host serial port or so, for example if this SoC is to act as a modem
or a fax machine, or if it is to drive one.
Then they often have a few more UART blocks, usually identical, which
only have RxD+TxD available, so they are just UARTs.
To complicate things further, you may wonder what happened with
the CTS/RTS (etc) signals from the other blocks. Usually they are there
in the silicon but just routed to dead ends.
To complicate it even further, usually all these pins are placed under
pin control multiplexing, so in an actual electronic design, the
system will mux out CTS/RTS (etc) from the fully featured RS232
blocks and only use them as UARTs anyways.
Then there are those who created real simple RxD/TxD-only UARTs
(yeah lets dump this RS232 legacy crap / yeah yeah)
and then realized they want to drive modems (oh crap, it seemed
like a good idea at the time). Then they usually take
two GPIO pins for CTS/RTS and drive them as GPIOs using
software and you have a cheap 4-line modem line. This is what
drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
I've tested this set and it seems to work ... except that something
is sadly broken with bluetooth support in 4.1-rc1 so I've only really
tested the GPS driver. I guess it is time to rebase to -rc3.
You have a hardware taget I see. Which one?
GTA04 (www.gta04.org - openmoko successor).
3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
half of a wifi/bluetooth module, and one to a GPS.
For the GPS, I just want to power on/off when the TTY is opened/closed,
but the power-on sequence is non-trivial as both turn on and
turn-off' toggle the same line, so I need to be able to detect current
state.
For the bluetooth, the power is a (shared) regulator. As well as
power-on when the TTY is opened, I'd like regulator to be turned of
when I hciconfig down - even though the TTY is still open.
I did a patch a while ago which hooked in to hci_uart_{open,close} to
make this work, but it isn't a really good patch.
It would be nice to hide the TTY from user-space in the bluetooth case,
and have the hciattach happen in the kernel, but I think hciattach
does extra initialisation...
NeilBrown
we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.
See:
https://lkml.org/lkml/2015/6/28/91
Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.
BR,
Nikolaus
--
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 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller
On Thu, Aug 27, 2015 at 7:49 PM, Punit Agrawal punit.agra...@arm.com wrote:
[ + device tree folks ]
Hi Sascha,
When introducing a new binding, it is a good idea to get reviews from
the device tree maintainers. I've added a few folks here. Please keep
them in the loop for future postings.
Sascha Hauer s.ha...@pengutronix.de writes:
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Reviewed-by: Daniel Kurtz djku...@chromium.org
Please add a commit log.
---
.../bindings/thermal/mediatek-thermal.txt | 38
++
include/dt-bindings/thermal/mt8173.h | 13
2 files changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
create mode 100644 include/dt-bindings/thermal/mt8173.h
diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
new file mode 100644
index 000..1697375
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
@@ -0,0 +1,38 @@
+* Mediatek Thermal
+
+This describes the device tree binding for the Mediatek thermal controller
+which measures the on-SoC temperatures. This device does not have its own
ADC,
+instead it directly controls the AUXADC via AHB bus accesses. For this
reason
+this device needs phandles to the AUXADC. Also it controls a mux in the
+apmixedsys register space via AHB bus accesses, so a phandle to the
APMIXEDSYS
+is also needed.
+
+Required properties:
+- compatible: mediatek,mt8173-thermal
+- reg: Address range of the thermal controller
+- interrupts: IRQ for the thermal controller
+- clocks, clock-names: Clocks needed for the thermal controller. required
+ clocks are:
+therm: Main clock needed for register access
+auxadc: The AUXADC clock
+- resets: Reference to the reset controller controlling the thermal
controller.
+- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
+- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
See
+ include/dt-bindings/thermal/mt8173.h for valid sensor
+ numbers.
+
+Example:
+
+ thermal: thermal@1100b000 {
+ #thermal-sensor-cells = 1;
+ compatible = mediatek,mt8173-thermal;
+ reg = 0 0x1100b000 0 0x1000;
+ interrupts = 0 70 IRQ_TYPE_LEVEL_LOW;
+ clocks = pericfg CLK_PERI_THERM, pericfg CLK_PERI_AUXADC;
+ clock-names = therm, auxadc;
+ resets = pericfg MT8173_PERI_THERM_SW_RST;
+ reset-names = therm;
+ mediatek,auxadc = auxadc;
+ mediatek,apmixedsys = apmixedsys;
+ };
diff --git a/include/dt-bindings/thermal/mt8173.h
b/include/dt-bindings/thermal/mt8173.h
new file mode 100644
index 000..692e74c
--- /dev/null
+++ b/include/dt-bindings/thermal/mt8173.h
@@ -0,0 +1,13 @@
+/*
+ * This header provides constants for mediatek,mt8173-thermal
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
+#define _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
+
+#define MT8173_THERMAL_ZONE_CA53 0
+#define MT8173_THERMAL_ZONE_CA57 1
+#define MT8173_THERMAL_ZONE_GPU 2
+#define MT8173_THERMAL_ZONE_CORE 3
+
+#endif /* _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H */
The constants in this include are not used in the patchset. Please drop
this hunk and introduce it when you use it.
These constants are part of the devicetree ABI, and I believe they
should be included with the binding.
To make this more concrete, I think these constants could be used as
array indices when initializing the corresponding banks of bank_data
in patch 2 (like you do when initializing scp_domain_data in the
scpsys driver).
-Dan
Thanks,
Punit
--
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 v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer
On 08/27/2015 06:30 PM, Yang, Wenyou wrote: -Original Message- From: Guenter Roeck [mailto:li...@roeck-us.net] Sent: 2015年8月7日 23:26 To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free- electrons.com; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux- watch...@vger.kernel.org Subject: Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer On 08/06/2015 03:16 AM, Wenyou Yang wrote: From SAMA5D4, the watchdog timer is upgrated with a new feature, which is describled as in the datasheet, WDT_MR can be written until a LOCKMR command is issued in WDT_CR. That is to say, as long as the bootstrap and u-boot don't issue a LOCKMR command, WDT_MR can be written more than once in the driver. So the SAMA5D4 watchdog driver's implementation is different from the at91sam9260 watchdog driver implemented in file at91sam9_wdt.c. The user application open the device file to enable the watchdog timer hardware, and close to disable it, and set the watchdog timer timeout by seting WDV and WDD fields of WDT_MR register, and ping the watchdog by issuing WDRSTT command to WDT_CR register with hard-coded key. Signed-off-by: Wenyou Yang wenyou.y...@atmel.com Reviewed-by: Guenter Roeck li...@roeck-us.net Hi Vim, Can this patch series be merged? Could you please? It is included in the pull request I sent to Wim last week. Guenter -- 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] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
On 28.08.2015 10:48, Jaehoon Chung wrote:
On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
Currently vmmc's property is wrong.
If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
(Card supply power and I/O Line supply Power.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ca7d168..4ddabfd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -461,10 +461,10 @@
mshc_0 {
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
- vmmc-supply = ldo20_reg buck8_reg;
+ vmmc-supply = ldo20_reg;
+ vqmmc-supply = buck8_reg;
Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
so it should be VQMMC?
If my schematics is right thing, buck8 is used LAN card power.
I will send after removing buck8_reg. how about?
Anyway, Thanks for pointing out. :)
Removing this regulator from this node would effectively disable it.
That could affect other components like LAN.
Anyway before fixing the order I would prefer to find the right
regulators used by MSHC node.
Best regards,
Krzysztof
I don't know who this regulator applied. I have guessed that it used for eMMC.
Sorry for guessing.
Best Regards,
Jaehoon Chung
In the same time I can't find on schematics where BUCK8 goes...
The SDHCI_2 node below looks good.
Best regards,
Krzysztof
mmc-pwrseq = emmc_pwrseq;
status = okay;
-
num-slots = 1;
broken-cd;
card-detect-delay = 200;
@@ -485,7 +485,8 @@
bus-width = 4;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
pinctrl-names = default;
- vmmc-supply = ldo4_reg ldo21_reg;
+ vmmc-supply = ldo21_reg;
+ vqmmc-supply = ldo4_reg;
cd-gpios = gpk2 2 0;
cd-inverted;
status = okay;
--
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] arm64: dts: mediatek: mt8173 PSCI-1.0 support
From: Fan Chen fan.c...@mediatek.com
This patch adds psci comatible properties to support all mandatory
functions of PSCI-1.0, PSCI-0.2 and PSCI-0.1, and system suspend
can be supported in PSCI-1.0.
Signed-off-by: Fan Chen fan.c...@mediatek.com
---
Because PSCI-1.0 patches hadn't landed on mainline, this patch is
based on three patch sets below:
[0] http://www.spinics.net/lists/arm-kernel/msg425793.html
PSCI: system suspend support
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
psci/unification
[2] http://www.spinics.net/lists/devicetree/msg82017.html
[PATCH 0/6] drivers: firmware: psci: add basic v1.0 support
Before they are merged in, this patch still works fine with psci-0.2
support in current mainline.
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..b9b4205 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -95,7 +95,7 @@
};
psci {
- compatible = arm,psci;
+ compatible = arm,psci-1.0, arm,psci-0.2, arm,psci;
method = smc;
cpu_suspend = 0x8401;
cpu_off = 0x8402;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote: On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri wrote: Hi, On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen peter.c...@freescale.com wrote: On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: Hi, On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan nathan.sulli...@ni.com wrote: The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag, unlike the default platform data. Add platform data specific to the Zynq udc. Based on a patch by the same name from the Xilinx vendor tree. I am that Xilinx guy who sent this patch :). It is in Xilinx tree as temporary fix and I did not debug further why UDC works only when streaming is enabled. Probably this is right time to post my question here. I was expecting like: Streaming disabled - both low bandwidth and high bandwidth systems should work fine Streaming enabled - only for high bandwidth systems but this is not the case, Zynq UDC works only when Streaming is enabled. Please correct me if I am wrong. You are right, stream mode disabled should work at anytime. It is so strange why zynq UDC only works when stream mode is enabled. I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc 2.20a, this is what it says about SDIS (streaming mode disable option) Before activating this mode, the user must check if the TX latency buffers per endpoint are able to accommodate at least one entire maximum size packet. The RX buffer size must, at least, double the TX buffer size per endpoint. To optimize the stream disable performance, system bus burst must be set as high as possible. When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a integer sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the controller will not work properly in stream disable mode. The stream disable mode should just be used in situations where the available system bandwidth is low or the system bus access latency is high, in order to avoid underruns and overruns in the latency buffers. This works for all types of endpoints, except for ISO endpoints. Such a system can't ensure the real time support that the ISO endpoints require, so the ISO endpoints are not supported when the SDIS bit is set. Definitely we need to root cause why disable streaming mode is not working for zynq but from controller spec point of view it is possible that controller not work properly in stream disable mode. Regards, Punnaiah Maybe the burst size isn't set correctly by default? It does say the controller won't work correctly with stream disable set and an invalid burst size. Looks like TX and RX burst both default to 16, per the Zynq manual. With the stream disable bit set, the behvior we see on our hardware is that priming just stops, with an outstanding transfer in memory marked active in the status field by the controller. This happens at random, even when doing single transfers at a time like with g_ether set to have a queue size of 1. With SDIS clear everything works great. Given that the Zynq is not bandwidth constrained, it seems like SDIS clear should be the default. I suspect the possible reason is the tx buffer for each endpoint is small (=512 bytes), so it can't copy one packet (assume max packet size for bulk) to tx buffer, then the prime can't be finished. Would you help to dump the registers HWTXBUF ($BASE + 0x10) and DCCPARAMS ($BASE + 124)? tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) * (DWORD_PER_BYTES) DWORD_PER_BYTES is 4 -- Best Regards, Peter Chen -- 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: [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs
Kevin, On Thu, Aug 27, 2015 at 5:24 PM, Kevin Hilman khil...@kernel.org wrote: That is not really workable: the attach and detach happen in probe/remove path; if you do not have driver for the device you will miss the clocks for it. And in my proposal, I suggested that clocks without drivers are good candidates to list in the domain, with the caveat that the be called out (documented) as being device clocks that are missing a driver, so when a driver shows up they can be moved accordingly, and in a way that actually describes the hardware. What happens if someone disables the driver using the CONFIG subsystem? What happens if this is a device that someone has set to 'status = disabled;' in the device tree? Even if the device is disabled in one of those two ways, we still need the clocks to be turned on. ...so if we turn on/off the VIO domain we need to turn on the EDP clock even if there's no EDP in the current board / config. We might turn on/off VIO for one of the other devices in the VIO domain for one of the other devices in VIO that we are using. -Doug -- 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 v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer
-Original Message- From: Guenter Roeck [mailto:li...@roeck-us.net] Sent: 2015年8月7日 23:26 To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free- electrons.com; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux- watch...@vger.kernel.org Subject: Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer On 08/06/2015 03:16 AM, Wenyou Yang wrote: From SAMA5D4, the watchdog timer is upgrated with a new feature, which is describled as in the datasheet, WDT_MR can be written until a LOCKMR command is issued in WDT_CR. That is to say, as long as the bootstrap and u-boot don't issue a LOCKMR command, WDT_MR can be written more than once in the driver. So the SAMA5D4 watchdog driver's implementation is different from the at91sam9260 watchdog driver implemented in file at91sam9_wdt.c. The user application open the device file to enable the watchdog timer hardware, and close to disable it, and set the watchdog timer timeout by seting WDV and WDD fields of WDT_MR register, and ping the watchdog by issuing WDRSTT command to WDT_CR register with hard-coded key. Signed-off-by: Wenyou Yang wenyou.y...@atmel.com Reviewed-by: Guenter Roeck li...@roeck-us.net Hi Vim, Can this patch series be merged? Could you please? Best Regards, Wenyou Yang
[PATCH v1 3/3] clk: rockchip: add clock controller for rk3036
Add the clock tree definition for the new rk3036 SoC,
but there are some issues to be fixed:
1. soc will crash if gpll run rate_change_remuxed
2. rk3036_clk_suspend and rk3036_clk_resume should be done
in clk-rk3036.c
---
Changes in v1:
Signed-off-by: Xing Zheng zhengx...@rock-chips.com
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-pll.c | 247 ++-
drivers/clk/rockchip/clk-rk3036.c | 539
drivers/clk/rockchip/clk.h | 30 ++
include/dt-bindings/clock/rk3036-cru.h | 247 +++
5 files changed, 1063 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/rockchip/clk-rk3036.c
create mode 100644 include/dt-bindings/clock/rk3036-cru.h
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b27edd6..d599829 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-inverter.o
obj-y += clk-mmc-phase.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
+obj-y += clk-rk3036.o
obj-y += clk-rk3188.o
obj-y += clk-rk3288.o
obj-y += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 96903ae..cf56826 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -2,6 +2,9 @@
* Copyright (c) 2014 MundoReader S.L.
* Author: Heiko Stuebner he...@sntech.de
*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng zhengx...@rock-chips.com
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -48,6 +51,8 @@ struct rockchip_clk_pll {
#define to_rockchip_clk_pll_nb(nb) \
container_of(nb, struct rockchip_clk_pll, clk_nb)
+static int rockchip_rk3036_pll_wait_lock(struct rockchip_clk_pll *pll);
+
static const struct rockchip_pll_rate_table *rockchip_get_pll_settings(
struct rockchip_clk_pll *pll, unsigned long rate)
{
@@ -90,6 +95,11 @@ static int rockchip_pll_wait_lock(struct rockchip_clk_pll
*pll)
unsigned int val;
int delay = 2400, ret;
+ /* the plls of rk3036 wait lock */
+ if (pll-type == pll_rk3036 || pll-lock_offset == -1) {
+ return rockchip_rk3036_pll_wait_lock(pll);
+ }
+
while (delay 0) {
ret = regmap_read(grf, pll-lock_offset, val);
if (ret) {
@@ -305,6 +315,235 @@ static void rockchip_rk3066_pll_init(struct clk_hw *hw)
rockchip_rk3066_pll_set_rate(hw, drate, prate);
}
}
+/**
+ * PLL used in RK3036
+ */
+
+#define RK3036_PLL_RESET_DELAY(nr) ((nr * 500) / 24 + 1)
+
+#define RK3036_PLLCON(i) (i * 0x4)
+#define RK3036_PLLCON0_FBDIV_MASK 0xfff
+#define RK3036_PLLCON0_FBDIV_SHIFT 0
+#define RK3036_PLLCON0_POSTDIV1_MASK 0x7
+#define RK3036_PLLCON0_POSTDIV1_SHIFT 12
+#define RK3036_PLLCON1_REFDIV_MASK 0x3f
+#define RK3036_PLLCON1_REFDIV_SHIFT0
+#define RK3036_PLLCON1_POSTDIV2_MASK 0x7
+#define RK3036_PLLCON1_POSTDIV2_SHIFT 6
+#define RK3036_PLLCON1_DSMPD_MASK 0x1
+#define RK3036_PLLCON1_DSMPD_SHIFT 12
+#define RK3036_PLLCON2_FRAC_MASK 0xff
+#define RK3036_PLLCON2_FRAC_SHIFT 0
+
+#define RK3036_MODECON 0x40
+#define RK3036_MODECON_AWM (1 0) /* apll work mode */
+
+#define RK3036_PLLCON0_BYPASS (1 15)
+#define RK3036_PLLCON1_LOCK_STATUS (1 10)
+#define RK3036_PLLCON1_RESET (1 14)
+
+static int rockchip_rk3036_pll_wait_lock(struct rockchip_clk_pll *pll)
+{
+ u32 pllcon;
+ int delay = 2400;
+
+ /* poll check the lock status in rk3036 xPLLCON1 */
+ while (delay 0) {
+ pllcon = readl_relaxed(pll-reg_base + RK3036_PLLCON(1));
+ if (pllcon RK3036_PLLCON1_LOCK_STATUS)
+ return 0;
+
+ delay--;
+ }
+
+ pr_err(%s: timeout waiting for pll to lock\n, __func__);
+ return -ETIMEDOUT;
+}
+
+static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+ struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
+ unsigned int fbdiv, postdiv1, refdiv, postdiv2, dsmpd, frac;
+ u64 rate64 = prate;
+ u32 pllcon;
+
+ pllcon = readl_relaxed(pll-reg_base + RK3036_PLLCON(0));
+ fbdiv = ((pllcon RK3036_PLLCON0_FBDIV_SHIFT)
RK3036_PLLCON0_FBDIV_MASK);
+ postdiv1 = ((pllcon RK3036_PLLCON0_POSTDIV1_SHIFT)
RK3036_PLLCON0_POSTDIV1_MASK);
+
+ pllcon = readl_relaxed(pll-reg_base + RK3036_PLLCON(1));
+ refdiv =
[PATCH v1 1/3] ARM: dts: rockchip: add core rk3036 dts
Initial release for rk3036, node definitions rk3036 sdk board.
Signed-off-by: Xing Zheng zhengx...@rock-chips.com
---
Changes in v1: None
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/rk3036-sdk.dts | 362 ++
2 files changed, 363 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6d7cec1..7014a3b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -501,6 +501,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
+ rk3036-sdk.dtb \
rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
diff --git a/arch/arm/boot/dts/rk3036-sdk.dts b/arch/arm/boot/dts/rk3036-sdk.dts
new file mode 100644
index 000..0149c9a
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-sdk.dts
@@ -0,0 +1,362 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/pinctrl/rockchip.h
+#include dt-bindings/clock/rk3036-cru.h
+#include skeleton.dtsi
+
+/ {
+ compatible = rockchip,rk3036;
+
+ interrupt-parent = gic;
+
+ aliases {
+ serial0 = uart0;
+ serial1 = uart1;
+ serial2 = uart2;
+ };
+
+ memory {
+ reg = 0x6000 0x4000;
+ };
+
+arm-pmu {
+compatible = arm,cortex-a7-pmu;
+interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
+};
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+ //enable-method = rockchip,rk3066-smp;
+
+ cpu@f00 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0xf00;
+ operating-points =
+ /* KHzuV */
+816000 100
+ ;
+ #cooling-cells = 2; /* min followed by max */
+ clock-latency = 4;
+ clocks = cru ARMCLK;
+ resets = cru SRST_CORE0;
+ };
+ cpu@f01 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0xf01;
+ resets = cru SRST_CORE1;
+ };
+ };
+
+ amba {
+ compatible = arm,amba-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+pdma: pdma@20078000 {
+compatible = arm,pl330, arm,primecell;
+reg = 0x20078000 0x4000;
+interrupts = GIC_SPI 0
[PATCH v1 0/3] Port and support rk3036 SoC platform
Hi, We need to support rk3036 soc platform via upstream, there are 3 parts for the initial release of minimum system: dts, pinctrl, and clock tree for rk3036, startup and run to init processs. Thanks. Changes in v1: Signed-off-by: Xing Zheng zhengx...@rock-chips.com Xing Zheng (3): ARM: dts: rockchip: add core rk3036 dts pinctrl: rockchip: add support for the rk3036 clk: rockchip: add clock controller for rk3036 arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/rk3036-sdk.dts | 362 + drivers/clk/rockchip/Makefile |1 + drivers/clk/rockchip/clk-pll.c | 247 ++- drivers/clk/rockchip/clk-rk3036.c | 539 drivers/clk/rockchip/clk.h | 30 ++ drivers/pinctrl/pinctrl-rockchip.c | 17 + include/dt-bindings/clock/rk3036-cru.h | 247 +++ 8 files changed, 1443 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts create mode 100644 drivers/clk/rockchip/clk-rk3036.c create mode 100644 include/dt-bindings/clock/rk3036-cru.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 答复: [PATCH 1/5] net: add Hisilicon Network Subsystem support (config and documents)
On Fri, Aug 21, 2015 at 04:00:35PM +0200, Arnd Bergmann wrote:
Date: Fri, 21 Aug 2015 16:00:35 +0200
From: Arnd Bergmann a...@arndb.de
To: Liguozhu (Kenneth) liguo...@hisilicon.com
CC: mark.rutl...@arm.com mark.rutl...@arm.com,
devicetree@vger.kernel.org devicetree@vger.kernel.org,
pawel.m...@arm.com pawel.m...@arm.com, ijc+devicet...@hellion.org.uk
ijc+devicet...@hellion.org.uk, catalin.mari...@arm.com
catalin.mari...@arm.com, will.dea...@arm.com will.dea...@arm.com,
linux-ker...@vger.kernel.org linux-ker...@vger.kernel.org, Linuxarm
linux...@huawei.com, paul.gortma...@windriver.com
paul.gortma...@windriver.com, robh...@kernel.org robh...@kernel.org,
ga...@codeaurora.org ga...@codeaurora.org, zhangfei@linaro.org
zhangfei@linaro.org, net...@vger.kernel.org
net...@vger.kernel.org, da...@davemloft.net da...@davemloft.net,
linux-arm-ker...@lists.infradead.org
linux-arm-ker...@lists.infradead.org
Subject: Re: 答复: [PATCH 1/5] net: add Hisilicon Network Subsystem
support (config and documents)
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
Message-ID: 2543796.7JthO5WCfI@wuerfel
On Monday 17 August 2015 01:28:07 Liguozhu wrote:
Thanks, Arnd.
Regarding the ae-name: it is the name of the Acceleration Engine. It is
provided
by the BIOS according to the position and the feature enabled of the IP.
So soc0 means it is on SoC No. 0, while n4 means it is running on
Non-dsaf mode 4. Ideally, we should setup the rule to name it. But as I
said in the patchset, the IP is original designed for a bare metal solution,
it is worthless to export all modes and we are planning to add more mode
for Linux itself in the IP in future version. So I think the better way is
to leave it as a name but add more meaning in the future.
The name property is a bit awkward. The position is normally implied by
the location of the parent device in the DT, so you should not need that
at all and instead derive it elsewhere. You can also add strings to the
compatible property instead of this, to signify differences in the programming
that are based on how the IP block is used.
Regarding the ae-opts: it is the initial value for the AE's runtime options,
Currently, we have only port number (there are 6XGE+2GE port for a DSAF
AE)
as option. But for future version, we will add other options such as enable
Spanning Tree Protocol algorithm) and so on.
I think these can easily be converted into an index property and boolean
flags (present if true, absent otherwise) for additional features.
Should I add these background to somewhere?
The binding document needs to list all supported configurations, if you
have a string property, describe specifically what strings are allowed
and what they mean, but better try to avoid strings altogether.
Arnd
___
linuxarm mailing list
linux...@huawei.com
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
Dear Arnd,
We are working on the new PatchSet. I describe the new design here so in case
you can tell us if we make something wrong.
So now we will keep some attributes in enthernet node like this:
ethernet@0{
compatible = hisilicon,hns-nic;
ae-name = dsaf1;
port-id = 0;
};
ae-name is simply a name referring to the name of dsa_name in SAF node.
port-id is the index of port provided by DSAF (the accelerator). DSAF can
connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. They
are called debug ports.
The remaining 6 PHYs are taken according to the mode of DSAF.
In NIC mode of DSAF, all 6 PHYs are taken as ethernet ports to the CPU. The
port-id can be 2 to 7. Here is the diagram:
+-+---+
|CPU |
+-+-+-+---+-+-+-+-+-+-+
| | | | | | | |
debug service
port port
(0,1) (2-7)
In Switch mode of DSAF, all 6 PHYs are taken as physical ports connect to a
LAN Switch while the CPU side assume itself have one single NIC connect to
this switch. In this case, the port-id will be 2 only.
+-+---+
|CPU |
+-+-+-+---+-+-+-+-+-+-+
| | | service port(2)
debug ++
port| switch |
(0,1) +-+-+-+-+-+-++
| | | | | |
external
port
--
-Kenneth(Hisilicon)
--
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 linux-next v5 1/5] mtd: spi-nor: notify (Q)SPI controller about protocol change
Hi Jonas,
Le 26/08/2015 16:02, Jonas Gorski a écrit :
On Wed, Aug 26, 2015 at 2:30 PM, Cyrille Pitchen
cyrille.pitc...@atmel.com wrote:
Once the Quad SPI mode has been enabled on a Micron flash memory, this
device expects ALL the following commands to use the SPI 4-4-4 protocol.
The (Q)SPI controller needs to be notified about the protocol change so it
can adapt and keep on dialoging with the Micron memory.
Doesn't that mean you need to disable quad mode on removal? Else the
following will break/fail:
insmod atmel-quadspi.ko ~ spi-nor attaches - sees micron - enables quad
mode
rmmod atmel-quadspi.ko ~ spi-nor detaches
insmod atmel-quadspi.ko ~ spi-nor attaches - fails to read the id
because flash is still in quad mode.
Indeed you're right such an issue does exist. So as you said one solution
could be create a new function to clean what have been done by spi_nor_scan()
then call it from remove() function of each driver calling spi_nor_scan() from
its probe().
However we could also enhance the probing of the memory. It is true that Micron
spi nor memories only accept SPI 4-4-4 commands once switched in quad mode but
actually they also provide a new command for this purpose:
Multiple I/O Read ID (0xAF).
Hence we could first try to probe using the regular Read ID (0x9F) command then
change the protocol, for instance to SPI 4-4-4, and try the 0xAF command.
I don't think all combinations for command/protocol need to be tested: for
Micron memories, their datasheets claim the 0x9F command is only supported in
extended spi mode so for the SPI 1-1-1 protocol whereas the 0xAF command
only works in dual or quad modes.
On the other hand Spansion memories still reply to the regular 0x9F command in
SPI 1-1-1 protocol even after their quad mode had been enabled.
For other manufacturers, well... I don't know!
Some of the advantages of the probe solution as compared to the remove one are:
- we don't need to patch all drivers using spi_nor_scan() to call a new
function from their remove().
- it doesn't rely on the assumption that the spi-nor memory starts in
SPI 1-1-1 protocol. As a matter of fact the remove() won't be called for
built-in modules or in many (all ?) cases of reset. Moreover some bootloaders
may have already enabled the quad mode before starting the Linux kernel. This
is what the sama5d2 romcode does when it is configured to boot from a QSPI
memory.
Anyway you're right and the issue need to be addressed but maybe in another
dedicated patch ?
Signed-off-by: Cyrille Pitchen cyrille.pitc...@atmel.com
Acked-by: Marek Vasut ma...@denx.de
Acked-by: Bean Huo bean...@micron.com
---
drivers/mtd/spi-nor/spi-nor.c | 21 +
include/linux/mtd/spi-nor.h | 13 +
2 files changed, 34 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index c27d427fead4..c8810313a752 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -165,6 +165,22 @@ static inline int write_disable(struct spi_nor *nor)
return nor-write_reg(nor, SPINOR_OP_WRDI, NULL, 0, 0);
}
+/*
+ * Let the spi-nor framework notify lower layers, especially the driver of
the
+ * (Q)SPI controller, about the new protocol to be used. Indeed, once the
+ * spi-nor framework has sent manufacturer specific commands to a memory to
+ * enable its Quad SPI mode, it should immediately after tell the QSPI
+ * controller to use the very same Quad SPI protocol as expected by the
memory.
+ */
+static inline int spi_nor_set_protocol(struct spi_nor *nor,
+ enum spi_protocol proto)
+{
+ if (nor-set_protocol)
+ return nor-set_protocol(nor, proto);
+
+ return 0;
Shouldn't the default assumption be that it won't support it? Also it
might make sense to first check if it's supported before enabling it
in the chip, so that we don't enable something just to then find out
we can't back out of it.
I also wonder if we need an extra flag for that as at least SPI has
RX_{DUAL,QUAD} and TX_{DUAL,QUAD} separated, so in theory there could
be a controller that supports quad read, but not quad write, so we
shouldn't be using the quad mode in that case. m25p80 currently sets
SPI_NOR_{DUAL,QUAD} only based on SPI_RX_{DUAL,QUAD}, so that would
then fail.
At least the n25q32 seems to support the boring 1_1_2 and 1_1_4
commands, so these should work in case the spi controller does not
support quad tx, but quad rx.
So maybe an additional flag for the full dual/quad modes would be in order.
My first thought was to return -ENOSYS when the set_protocol() callback is not
implemented but logically none of the already existing drivers implements it.
So I made this new callback optional. This way, micron_quad_enable() works the
exact same way as before for all the existing drivers so no regression or side-
effect should be introduced by this patch.
[PATCH] arm: tegra: dtsi whitespace clean-up for tegra20, tegra30 and tegra124
There were a few cases of eight spaces being used instead of a tab
character plus one case of using two spaces after an equal sign instead
of just one which this patch fixes.
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
---
arch/arm/boot/dts/tegra124.dtsi | 2 +-
arch/arm/boot/dts/tegra20.dtsi | 4 ++--
arch/arm/boot/dts/tegra30.dtsi | 10 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 1e204a6..a5c878e 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -636,7 +636,7 @@
reg = 0x0 0x7003 0x0 0x1;
interrupts = GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH;
clocks = tegra_car TEGRA124_CLK_HDA,
-tegra_car TEGRA124_CLK_HDA2HDMI,
+tegra_car TEGRA124_CLK_HDA2HDMI,
tegra_car TEGRA124_CLK_HDA2CODEC_2X;
clock-names = hda, hda2hdmi, hda2codec_2x;
resets = tegra_car 125, /* hda */
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index e058709..0a8d1a6 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -601,8 +601,8 @@
tegra_car TEGRA20_CLK_PLL_E;
clock-names = pex, afi, pll_e;
resets = tegra_car 70,
-tegra_car 72,
-tegra_car 74;
+tegra_car 72,
+tegra_car 74;
reset-names = pex, afi, pcie_x;
status = disabled;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index fe04fb5..38e1e27 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -42,8 +42,8 @@
tegra_car TEGRA30_CLK_CML0;
clock-names = pex, afi, pll_e, cml;
resets = tegra_car 70,
-tegra_car 72,
-tegra_car 74;
+tegra_car 72,
+tegra_car 74;
reset-names = pex, afi, pcie_x;
status = disabled;
@@ -153,7 +153,7 @@
tegra_car TEGRA30_CLK_GR3D2;
clock-names = 3d, 3d2;
resets = tegra_car 24,
-tegra_car 98;
+tegra_car 98;
reset-names = 3d, 3d2;
};
@@ -455,7 +455,7 @@
};
i2c@7000c000 {
- compatible = nvidia,tegra30-i2c, nvidia,tegra20-i2c;
+ compatible = nvidia,tegra30-i2c, nvidia,tegra20-i2c;
reg = 0x7000c000 0x100;
interrupts = GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH;
#address-cells = 1;
@@ -660,7 +660,7 @@
reg = 0x7003 0x1;
interrupts = GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH;
clocks = tegra_car TEGRA30_CLK_HDA,
-tegra_car TEGRA30_CLK_HDA2HDMI,
+tegra_car TEGRA30_CLK_HDA2HDMI,
tegra_car TEGRA30_CLK_HDA2CODEC_2X;
clock-names = hda, hda2hdmi, hda2codec_2x;
resets = tegra_car 125, /* hda */
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
Hello Jaehoon,
On 08/27/2015 11:29 AM, Jaehoon Chung wrote:
Currently vmmc's property is wrong.
If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
(Card supply power and I/O Line supply Power.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ca7d168..4ddabfd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -461,10 +461,10 @@
mshc_0 {
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
- vmmc-supply = ldo20_reg buck8_reg;
+ vmmc-supply = ldo20_reg;
+ vqmmc-supply = buck8_reg;
mmc-pwrseq = emmc_pwrseq;
status = okay;
-
num-slots = 1;
broken-cd;
card-detect-delay = 200;
@@ -485,7 +485,8 @@
bus-width = 4;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
pinctrl-names = default;
- vmmc-supply = ldo4_reg ldo21_reg;
+ vmmc-supply = ldo21_reg;
+ vqmmc-supply = ldo4_reg;
cd-gpios = gpk2 2 0;
cd-inverted;
status = okay;
I didn't check against the board schematics
but the change makes sense to me.
Reviewed-by: Javier Martinez Canillas jav...@osg.samsung.com
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
[PATCH v15 1/2] arm:dts:ls1021a: Add DCU dts node
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.
Signed-off-by: Alison Wang b18...@freescale.com
Signed-off-by: Xiubo Li lixi...@cmss.chinamobile.com
Signed-off-by: Jianwei Wang jianwei.wang@gmail.com
---
arch/arm/boot/dts/ls1021a.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..6d6e3e2 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -383,6 +383,16 @@
platform_clk 1;
};
+ dcu: dcu@2ce {
+ compatible = fsl,ls1021a-dcu;
+ reg = 0x0 0x2ce 0x0 0x1;
+ interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+ clocks = platform_clk 0;
+ clock-names = dcu;
+ big-endian;
+ status = disabled;
+ };
+
mdio0: mdio@2d24000 {
compatible = gianfar;
device_type = mdio;
--
2.1.0.27.g96db324
--
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 v15 2/2] arm:dts:ls1021a: Add a TFT LCD panel dts node
Add a TFT LCD panel. the TFT LCD panel is WQVGA 480x272,
and the bpp is 24.
Signed-off-by: Alison Wang b18...@freescale.com
Signed-off-by: Xiubo Li lixi...@cmss.chinamobile.com
Signed-off-by: Jianwei Wang jianwei.wang@gmail.com
---
Changed in V15:
Rename compatible string.
arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..99c6aad 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -56,6 +56,17 @@
enet0_sgmii_phy = sgmii_phy2;
enet1_sgmii_phy = sgmii_phy0;
};
+
+ panel: panel {
+ compatible = nec,nl4827hc19-05b;
+ };
+
+};
+
+dcu {
+ fsl,panel = panel;
+ status = okay;
+
};
dspi1 {
--
2.1.0.27.g96db324
--
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] Altera Modular ADC driver support
From: Chee Nouk Phoon cnph...@altera.com
Altera Modular ADC is soft IP that wraps the hardened ADC block in a Max10
device. It can be configured to dual ADC mode that supports two channel
synchronous sampling or independent single ADCs. ADC sampled values will be
written into memory slots in sequence determined by a user configurable
sequencer block.
This patch adds Altera Modular ADC driver support
Signed-off-by: Chee Nouk Phoon cnph...@altera.com
---
drivers/iio/adc/Kconfig | 12 ++
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/alt_modular_adc.c | 307 +
3 files changed, 320 insertions(+), 0 deletions(-)
create mode 100644 drivers/iio/adc/alt_modular_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..b0b1cff 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -117,6 +117,18 @@ config AD799X
i2c analog to digital converters (ADC). Provides direct access
via sysfs.
+config ALT_MODULAR_ADC
+ tristate Altera Modular ADC driver
+ depends on NIOS2
+ select ANON_INODES
+
+ help
+ Say yes here to have support for Altera Modular ADC. The driver
+ supports both Altera Modular ADC and Altera Modular Dual ADC.
+
+ The driver can also be build as a module. If so the module will be
+ called alt_modular_adc.
+
config AT91_ADC
tristate Atmel AT91 ADC
depends on ARCH_AT91
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..d7f10e0 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_VF610_ADC) += vf610_adc.o
obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
xilinx-xadc-y := xilinx-xadc-core.o xilinx-xadc-events.o
obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o
+obj-$(CONFIG_ALT_MODULAR_ADC) += alt_modular_adc.o
diff --git a/drivers/iio/adc/alt_modular_adc.c
b/drivers/iio/adc/alt_modular_adc.c
new file mode 100644
index 000..a5649d7
--- /dev/null
+++ b/drivers/iio/adc/alt_modular_adc.c
@@ -0,0 +1,307 @@
+/*
+ * Copyright (C) 2015 Altera Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include linux/iio/iio.h
+
+/* Constant Definitions */
+#define MODE_MAX_SLOT 64
+#define MODE_MAX_ADC 2
+#define MODE_MAX_CHANNEL 18
+#define MODE_SINGLE_ADC1
+#define MODE_DUAL_ADC 2
+#define MODE_ADC_BITS 12
+#define MODE_ADC_STORE_BITS16
+
+/* Register Definitions */
+#define ADC_CMD_REG0x0
+#define ADC_IER_REG0x100
+#define ADC_ISR_REG0x104
+
+#define ADC_RUN_MSK0x1
+#define ADC_SINGLE_MKS 0x2
+#define ADC_STOP_MSK 0x0
+#define ADC_LOW_MSK0xFFF
+#define ADC_HIGH_MSK 0xFFF
+
+struct altera_adc {
+ void __iomem*seq_regs;
+ void __iomem*sample_regs;
+
+ unsigned intmode;
+ unsigned intslot_count;
+ unsigned intslot_sequence[MODE_MAX_ADC][MODE_MAX_SLOT];
+ unsigned intadc_number;
+
+ u32 value;
+ u32 address;
+};
+
+static int alt_modular_adc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long mask)
+{
+ struct altera_adc *adc = iio_priv(indio_dev);
+ int ret = -EINVAL;
+
+ if (mask != IIO_CHAN_INFO_RAW)
+ return -EINVAL;
+
+ adc-value = readl(adc-sample_regs + (chan-address * 4));
+
+ if (adc-mode == MODE_SINGLE_ADC) {
+ *val = (adc-value ADC_LOW_MSK);
+ ret = IIO_VAL_INT;
+ } else if (adc-mode == MODE_DUAL_ADC) {
+ *val = (adc-value ADC_LOW_MSK);
+ *val2 = ((adc-value ADC_HIGH_MSK) 16);
+ ret = IIO_VAL_INT_MULTIPLE;
+ }
+
+ return ret;
+}
+
+static const struct iio_info adc_iio_info = {
+ .read_raw = alt_modular_adc_read_raw,
+ .driver_module =
Re: [PATCH 2/4] remoteproc: Supply controller driver for ST's Remote Processors
On Wed, 26 Aug 2015, Nathan Lynch wrote:
On 08/26/2015 08:08 AM, Lee Jones wrote:
--- /dev/null
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -0,0 +1,300 @@
+/*
+ * ST's Remote Processor Control Driver
+ *
+ * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
+ *
+ * Author: Ludovic Barre ludovic.ba...@st.com
When submitting code you didn't write, I'd say it's better practice to
clearly indicate its provenance in the commit message. E.g. something
like Driver based on code authored by Ludovic Barre for ST. And
obtain signoffs etc if possible.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
Please review the wording here. It's unclear whether this is intended
to be v2-only or v2 or later.
+static int st_rproc_stop(struct rproc *rproc)
+{
+ struct st_rproc *st_rproc = rproc-priv;
+ int err = 0;
+
+ if (st_rproc-config-sw_reset) {
+ err = reset_control_assert(st_rproc-sw_reset);
+ if (err)
+ dev_warn(rproc-dev, Failed to assert S/W Reset\n);
+ }
+
+ if (st_rproc-config-pwr_reset) {
+ err = reset_control_assert(st_rproc-pwr_reset);
+ if (err)
+ dev_warn(rproc-dev, Failed to assert Power Reset\n);
+ }
+
+ clk_disable(st_rproc-clk);
+
+ return 0;
+}
Seems like st_rproc_stop should propagate errors back to its caller
instead of always returning 0.
Good points, will fix.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs
On Wed, 26 Aug 2015, Nathan Lynch wrote:
On 08/26/2015 08:08 AM, Lee Jones wrote:
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/remoteproc/remoteproc_debugfs.c | 25 +
1 file changed, 25 insertions(+)
The commit message should describe why this is needed...
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index 9d30809..9620962 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -88,8 +88,33 @@ static ssize_t rproc_state_read(struct file *filp, char
__user *userbuf,
return simple_read_from_buffer(userbuf, count, ppos, buf, i);
}
+static ssize_t rproc_state_write(struct file *filp, const char __user
*userbuf,
+size_t count, loff_t *ppos)
+{
+ struct rproc *rproc = filp-private_data;
+ char buf[2];
+ int ret;
+
+ ret = copy_from_user(buf, userbuf, 1);
+ if (ret)
+ return -EFAULT;
+
+ switch (buf[0]) {
+ case '1':
+ ret = rproc_boot(rproc);
+ if (ret)
+ dev_warn(rproc-dev, Boot failed: %d\n, ret);
+ break;
+ default:
+ rproc_shutdown(rproc);
+ }
+
+ return count;
+}
... and I suggest that the user interface be reconsidered. If '1' means
boot and literally anything else means shut down then you can't add
operations in the future without potentially breaking things.
Good points, will fix.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
