RE: [PATCH v4 05/14] dmaengine: edma: Add TI EDMA device tree binding
On Fri, Jan 11, 2013 at 11:18:41, Porter, Matt wrote:
> The binding definition is based on the generic DMA controller
> binding.
>
> Signed-off-by: Matt Porter
> ---
> Documentation/devicetree/bindings/dma/ti-edma.txt | 51
> +
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> new file mode 100644
> index 000..3344345
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -0,0 +1,51 @@
> +TI EDMA
> +
> +Required properties:
> +- compatible : "ti,edma3"
> +- ti,hwmods: Name of the hwmods associated to the EDMA
> +- ti,edma-regions: Number of regions
> +- ti,edma-slots: Number of slots
> +- ti,edma-queue-tc-map: List of transfer control to queue mappings
> +- ti,edma-queue-priority-map: List of queue priority mappings
> +- ti,edma-default-queue: Default queue value
> +
> +Optional properties:
> +- ti,edma-reserved-channels: List of reserved channel regions
> +- ti,edma-reserved-slots: List of reserved slot regions
> +- ti,edma-xbar-event-map: Crossbar event to channel map
> +
> +Example:
> +
> +edma: edma@4900 {
> + #address-cells = <1>;
> + #size-cells = <0>;
address-cells & size-cells are only required when current node is a parent
node & it has sibling/child nodes (that too if the child node uses "reg"
property).
> + reg = <0x4900 0x1>;
> + interrupt-parent = <&intc>;
> + interrupts = <12 13 14>;
> + compatible = "ti,edma3";
> + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> + #dma-cells = <1>;
> + dma-channels = <64>;
> + ti,edma-regions = <4>;
> + ti,edma-slots = <256>;
> + ti,edma-reserved-channels = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8>;
> + ti,edma-reserved-slots = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8
> + 64 127>;
> + ti,edma-queue-tc-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-queue-priority-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-default-queue = <0>;
> + ti,edma-xbar-event-map = <1 12
> + 2 13>;
> +};
> --
> 1.7.9.5
>
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
Regards,
Gururaja
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch] tg3: missing break statement in tg3_get_5720_nvram_info()
From: Dan Carpenter Date: Fri, 11 Jan 2013 09:57:33 +0300 > There is a missing break statement so FLASH_5762_EEPROM_HD gets treated > like FLASH_5762_EEPROM_LD. > > Signed-off-by: Dan Carpenter Applied, thanks Dan. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v4 01/14] ARM: davinci: move private EDMA API to arm/common
On Fri, Jan 11, 2013 at 11:18:37, Porter, Matt wrote:
> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx) as well. This just moves the
> private EDMA API and enables it to build on OMAP.
>
> Signed-off-by: Matt Porter
> ---
> arch/arm/Kconfig |1 +
> arch/arm/common/Kconfig|3 +
> arch/arm/common/Makefile |1 +
> arch/arm/{mach-davinci/dma.c => common/edma.c} |2 +-
> arch/arm/mach-davinci/Makefile |2 +-
> arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
> arch/arm/mach-davinci/davinci.h|2 +-
> arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
> arch/arm/mach-davinci/devices.c|7 +-
> arch/arm/mach-davinci/dm355.c |2 +-
> arch/arm/mach-davinci/dm365.c |2 +-
> arch/arm/mach-davinci/dm644x.c |2 +-
> arch/arm/mach-davinci/dm646x.c |2 +-
> arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
> arch/arm/mach-davinci/include/mach/edma.h | 267
>
> arch/arm/plat-omap/Kconfig |1 +
> drivers/dma/edma.c |2 +-
> drivers/mmc/host/davinci_mmc.c |1 +
> include/linux/mfd/davinci_voicecodec.h |3 +-
> include/linux/platform_data/edma.h | 182
Headers file are just moved here. So "git mv file1 flie2; and the git
format-patch -C" on commit should just generate few lines of patch.
> include/linux/platform_data/spi-davinci.h |2 +-
> sound/soc/davinci/davinci-evm.c|1 +
> sound/soc/davinci/davinci-pcm.c|1 +
> sound/soc/davinci/davinci-pcm.h|2 +-
> sound/soc/davinci/davinci-sffsdr.c |6 +-
> 25 files changed, 212 insertions(+), 288 deletions(-)
> rename arch/arm/{mach-davinci/dma.c => common/edma.c} (99%)
> delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h
> create mode 100644 include/linux/platform_data/edma.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 67874b8..7637d31 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -932,6 +932,7 @@ config ARCH_DAVINCI
> select GENERIC_IRQ_CHIP
> select HAVE_IDE
> select NEED_MACH_GPIO_H
> + select TI_PRIV_EDMA
> select USE_OF
> select ZONE_DMA
> help
> diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
> index 45ceeb0..9e32d0d 100644
> --- a/arch/arm/common/Kconfig
> +++ b/arch/arm/common/Kconfig
> @@ -40,3 +40,6 @@ config SHARP_PARAM
>
> config SHARP_SCOOP
> bool
> +
> +config TI_PRIV_EDMA
> + bool
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index e8a4e58..d09a39b 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
> obj-$(CONFIG_SHARP_SCOOP)+= scoop.o
> obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
> obj-$(CONFIG_ARM_TIMER_SP804)+= timer-sp.o
> +obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
> similarity index 99%
> rename from arch/arm/mach-davinci/dma.c
> rename to arch/arm/common/edma.c
> index a685e97..4411087 100644
> --- a/arch/arm/mach-davinci/dma.c
> +++ b/arch/arm/common/edma.c
> @@ -25,7 +25,7 @@
> #include
> #include
>
> -#include
> +#include
>
> /* Offsets matching "struct edmacc_param" */
> #define PARM_OPT 0x00
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index fb5c1aa..493a36b 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -5,7 +5,7 @@
>
> # Common objects
> obj-y:= time.o clock.o serial.o psc.o \
> -dma.o usb.o common.o sram.o aemif.o
> +usb.o common.o sram.o aemif.o
>
> obj-$(CONFIG_DAVINCI_MUX)+= mux.o
>
> diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
> b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> index be30997..86f55ba 100644
> --- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
> +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
> @@ -26,12 +26,12 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
>
> #include
> -#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
> index 12d544b..d26a6bc 100644
> --- a/arch/arm/mach-davinci/davinci.h
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -23,9 +23,9 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> -#include
>
> #include
> #include
> diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c
> b/arch/arm/mach-davinci/devices-tnetv107x.c
> inde
[PATCH v4 14/14] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 278b75d..8fd3648 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -356,6 +356,11 @@ interrupt = <65>; ti,spi-num-cs = <2>; ti,hwmods = "spi0"; + dmas = <&edma 16 + &edma 17 + &edma 18 + &edma 19>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; @@ -367,6 +372,11 @@ interrupt = <125>; ti,spi-num-cs = <2>; ti,hwmods = "spi1"; + dmas = <&edma 42 + &edma 43 + &edma 44 + &edma 45>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 13/14] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..3bd8eed 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+ pairs. One tx and one rx pair is required for each chip
+ select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the ordered pairs in dmas. The string naming is
+ to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -20,3 +31,18 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
+
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 12/14] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(&spi->dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA TX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+ mcspi->dma_channels[i].dma_tx_sync_dev =
+ dma_res->start;
+
[PATCH v4 11/14] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk..
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
@@ -136,3 +138,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&ldo3_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
&cpsw_emac1 {
phy_id = <&davinci_mdio>, <1>;
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&vmmc_reg>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e711ffb..278b75d 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -235,6 +235,34 @@
status = "disabled";
};
+ mmc1: mmc@4806 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc2";
+ ti,needs-special-reset;
+ dmas = <&edma 2
+ &edma 3>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ mmc3: mmc@4781 {
+ compatible = "ti,omap3-hsmmc";
+ ti,hwmods = "mmc3";
+ ti,needs-special-reset;
+ status = "disabled";
+ };
+
wdt2: wdt@44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 10/14] mmc: omap_hsmmc: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..826cc51 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,28 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be "rx" and the
+TX request must be "tx".
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ bus-width = <4>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
@@ -30,4 +50,7 @@ Example:
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 09/14] mmc: omap_hsmmc: set max_segs based on dma engine limitations
The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. The DMA Engine API reports the maximum number of segments a channel can support via the optional dma_get_channel_caps() API. If the nr_segs capability is present, the value is used to configure mmc->max_segs appropriately. Signed-off-by: Matt Porter --- drivers/mmc/host/omap_hsmmc.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e79b12d..f74bd69 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1769,6 +1769,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev) const struct of_device_id *match; dma_cap_mask_t mask; unsigned tx_req, rx_req; + struct dmaengine_chan_caps *dma_chan_caps; struct pinctrl *pinctrl; match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev); @@ -1935,6 +1936,11 @@ static int omap_hsmmc_probe(struct platform_device *pdev) goto err_irq; } + /* Some DMA Engines only handle a limited number of SG segments */ + dma_chan_caps = dma_get_channel_caps(host->rx_chan, DMA_DEV_TO_MEM); + if (dma_chan_caps && dma_chan_caps->seg_nr) + mmc->max_segs = dma_chan_caps->seg_nr; + /* Request IRQ for MMC operations */ ret = request_irq(host->irq, omap_hsmmc_irq, 0, mmc_hostname(mmc), host); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 08/14] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..e79b12d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1915,14 +1915,20 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
+ host->rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&rx_req, &pdev->dev, "rx");
+
if (!host->rx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine
channel %u\n", rx_req);
ret = -ENXIO;
goto err_irq;
}
- host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
+ host->tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&tx_req, &pdev->dev, "tx");
+
if (!host->tx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine
channel %u\n", tx_req);
ret = -ENXIO;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 07/14] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren
Signed-off-by: Matt Porter
---
include/linux/dmaengine.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9fd0c5b..64f9f69 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev->of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 06/14] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ };
+
gpio1: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 05/14] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 51 +
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..3344345
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,51 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4900 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+14 2
+26 6
+48 4
+56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 04/14] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index d4c1218..20ef955 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -221,7 +221,7 @@ config SIRF_DMA config TI_EDMA tristate "TI EDMA support" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 03/14] ARM: edma: add AM33XX support to the private EDMA API
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data. Enables runtime PM support to
initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
support.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 314 ++--
include/linux/platform_data/edma.h |1 +
2 files changed, 306 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a3d189d..1951d63 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot >= 0)
slot = EDMA_CHAN_SLOT(slot);
@@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(&res));
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-xbar-event-map",
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] >> 2;
+ offset <<= 2;
+ mux = readl((void *)((u32)xbar + offset));
+ mux &= ~(0xff << shift);
+ mux |= xbar_chans[i][0] << shift;
+ writel(mux, (void *)((u32)xbar + offset));
+ }
+
+ pdata->xbar_chans = xbar_chans;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ const s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, "dma-channels", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_channel = value;
+
+ ret = of_property_read_u32(node, "ti,edma-regions", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_region = value;
+
+ ret = of_property_read_u32(node, "ti,edma-slots", &value);
+ if (ret < 0)
+
[PATCH v4 02/14] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 4411087..a3d189d 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc0err_handler\n");
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc1err_handler\n");
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int __init edma_probe(struct platform_device
*pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- "edma_tc0", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d failed --> %d\n",
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- "edma_tc1", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d --> %d\n",
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 01/14] ARM: davinci: move private EDMA API to arm/common
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API and enables it to build on OMAP.
Signed-off-by: Matt Porter
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} |2 +-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|7 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
arch/arm/mach-davinci/include/mach/edma.h | 267
arch/arm/plat-omap/Kconfig |1 +
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
include/linux/platform_data/edma.h | 182
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |6 +-
25 files changed, 212 insertions(+), 288 deletions(-)
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (99%)
delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h
create mode 100644 include/linux/platform_data/edma.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..4411087 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
/* Offsets matching "struct edmacc_param" */
#define PARM_OPT 0x00
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o psc.o \
- dma.o usb.o common.o sram.o aemif.o
+ usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c
b/arch/arm/mach-davinci/devices-tnetv107x.c
index 773ab07..ba37760 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -18,10 +18,10 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include "clock.h"
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 4c48a36..3bdf9f7 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -19,
[PATCH v4 00/14] DMA Engine support for AM33XX
Changes since v3: - Rebased on 3.8-rc3 - No longer an RFC - Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia - Restored all the Davinci pdata to const - Removed max_segs hack in favor of using dma_get_channel_caps() - Fixed extra parens, __raw_* accessors and, ioremap error checks in xbar handling - Removed excess license info in platform_data/edma.h - Removed unneeded reserved channels data for AM33xx - Removed test-specific pinmuxing from dts files - Adjusted mmc1 node to be disabled by default in the dtsi Changes since v2: - Rebased on 3.7-rc1 - Fixed bug in DT/pdata parsing first found by Gururaja that turned out to be masked by some toolchains - Dropped unused mach-omap2/devices.c hsmmc patch - Added AM33XX crossbar DMA event mux support - Added am335x-evm support Changes since v1: - Rebased on top of mainline from 12250d8 - Dropped the feature removal schedule patch - Implemented dma_request_slave_channel_compat() and converted the mmc and spi drivers to use it - Dropped unneeded #address-cells and #size-cells from EDMA DT support - Moved private EDMA header to linux/platform_data/ and removed some unneeded definitions - Fixed parsing of optional properties This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. The series applies on top of 3.8-rc3 and the following patches: - TPS65910 REGMAP_IRQ build fix: https://patchwork.kernel.org/patch/1857701/ - dmaengine DT support from Vinod's dmaengine_dt branch in git://git.infradead.org/users/vkoul/slave-dma.git since 027478851791df751176398be02a3b1c5f6aa824 - edma dmaengine driver fix: https://patchwork.kernel.org/patch/1961521/ - dmaengine dma_get_channel_caps v2: https://patchwork.kernel.org/patch/1961601/ - dmaengine edma driver channel caps support v2: https://patchwork.kernel.org/patch/1961591/ The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. With this series both BeagleBone and the AM335x EVM have working MMC and SPI support. This is tested on BeagleBone with a SPI framebuffer driver and MMC rootfs. A trivial gpio DMA event misc driver was used to test the crossbar DMA event support. It is also tested on the AM335x EVM with the onboard SPI flash and MMC rootfs. The branch at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4 has the complete series, dependencies, and some test drivers/defconfigs. Regression testing was done on AM180x-EVM (which also makes use of the EDMA dmaengine driver and the EDMA private API) using SD, SPI flash, and the onboard audio supported by the ASoC Davinci driver. Regression testing was also done on a BeagleBoard xM booting from the legacy board file using MMC rootfs. Matt Porter (14): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add AM33XX support to the private EDMA API dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support dmaengine: add dma_request_slave_channel_compat() mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: set max_segs based on dma engine limitations mmc: omap_hsmmc: add generic DMA request support to the DT binding ARM: dts: add AM33XX MMC support spi: omap2-mcspi: convert to dma_request_slave_channel_compat() spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add AM33XX SPI DMA support Documentation/devicetree/bindings/dma/ti-edma.txt | 51 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 28 +- arch/arm/Kconfig |1 + arch/arm/boot/dts/am335x-bone.dts |7 + arch/arm/boot/dts/am335x-evm.dts |7 + arch/arm/boot/dts/am335x-evmsk.dts |7 + arch/arm/boot/dts/am33xx.dtsi | 58 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile
Re: [PATCH V4 0/4] input: keyboard: tegra: cleanups and DT supports
On Thursday 10 January 2013 11:14 PM, Dmitry Torokhov wrote: Hi Laxman, On Thu, Jan 10, 2013 at 12:01:23PM +0530, Laxman Dewangan wrote: Hi Dmitry, On Monday 07 January 2013 10:22 PM, Stephen Warren wrote: On 01/06/2013 04:14 AM, Laxman Dewangan wrote: This patch series: - fix build warning, - use devm_* for allocation, - make column/rows configuration through DT and - remove the rarely used key mapping table. The series, Reviewed-by: Stephen Warren If you are fine with this series then can it be apply please? I can handle if there is any comment on this series to close this. The patches are applied with minor edits to the 3rd and 4th (there was no point in having a separate keymap setup function anymore). Thanks for taking care. I looked the final change from your git and the changes are fine. Thanks, Laxman ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 12/14] ARM: tegra: tec: Add PCIe support
On Thu, Jan 10, 2013 at 05:22:30PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > Enable the first PCIe root port which is connected to an FPGA on the
> > Tamonten Evaluation Carrier and add device nodes for each of the PCI
> > endpoints available in the standard configuration.
>
> > diff --git a/arch/arm/boot/dts/tegra20-tec.dts
> > b/arch/arm/boot/dts/tegra20-tec.dts
>
> > + pcie-controller {
> > + vdd-supply = <&pci_vdd_reg>;
> > + pex-clk-supply = <&pci_clk_reg>;
> > + status = "okay";
>
> Sorry this is also really picky. I'd prefer properties that exist in
> /include/d files and are overidden here to appear first, followed by new
> properties. In other words, move the status property to be first. I
> believe/hope all the other (Tegra) .dts files follow this convention.
Okay, I'll fix that.
> > + pci@1,0 {
> > + bus-range = <0x01 0x0a>;
> > + status = "okay";
> > +
> > + pci@0,0 {
> > + reg = <0x01 0 0 0 0>;
>
> Hmm. The unit address in that node name doesn't match the address in the
> reg property, although I suppose there's nothing we can do about it
> since those formats are both defined by the standard PCI binding?
That's the standard encoding for unit addresses for PCI devices. The
first cell in the reg property encodes bus/device/function (amongst
other things) and the node name is supposed to be pci@,.
> What do the numbers "0,0" represent here; device/function? Is the same
> true for the "0,0" in the child nodes?
Yes, exactly.
> > + bus-range = <0x02 0x0a>;
> > +
> > + compatible = "plda,pcie";
>
> Are there DT binding documents for all these devices; plda,pcie,
> ad,pcie, ad,pcie-test, etc.?
No. To be honest I don't quite know how to handle this. For the PLDA
things aren't so bad since it has a proper PCI ID, but the other cores
don't since they are custom IP or taken from opencores.org and made
available via PCIe. We're still in the process of obtaining our own PCI
vendor ID so that these can be properly assigned.
Also, as you have guessed, most of these are not required. I just wanted
to include them here for completeness (and maybe reference in case
somebody else, myself included, needs a working example to base other
work on).
> > + pci@4,0 {
> > + reg = <0x022000 0 0 0 0>;
> > + bus-range = <0x07 0x07>;
> > +
> > + compatible = "ad,pcie";
> > + device_type = "pci";
> > +
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > +
> > + pci@0,0 {
> > + compatible = "opencores,uart";
> > + reg = <0x07 0 0 0 0>;
> > + };
> > + };
>
> Do you need to include a node for the UART; I can see you need to for
> the SPI/I2C controllers so you can instantiate the appropriate devices
> on non-probe-able buses, but I think you can just let regular PCI device
> probing find the UART, Ethernet MAC, etc., can't you?
Yes, that's correct. Only SPI and I2C actually require these nodes. I'm
not sure if the PCI binding requires all nodes to be present or not.
Other examples I've seen (e.g. arch/x86/platform/ce4100/falconfalls.dts)
contain nodes for everything, most of which don't seem to be necessary
for things to work.
One other thing that I've seen is the usage of the more standard pci*
values for the compatible property. None of them are very descriptive
which is why I used a vendor,device type of value instead.
Going over the PCI binding again, however, it looks like there's no
requirement to make the node name pci@dev,fn and pci can be anything.
Making it uart@0,0 and then adjusting the compatible value to be as the
binding requires could be an option. In that case I suppose even the
bindings documentation shouldn't be necessary.
That doesn't cover the nodes where non-standard properties are needed
(I2C and SPI), which do need binding documents. I wouldn't know how to
name them, though. I'm not sure going with the current convention would
be any good since it'll be hard to find the right document if you have
to look it up by matching vendor and device IDs or PCI class.
Thierry
pgpFXYVu6kufU.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 09/14] ARM: tegra: Move pmc.h to include/mach
On Thu, Jan 10, 2013 at 05:15:07PM -0700, Stephen Warren wrote: > On 01/09/2013 01:43 PM, Thierry Reding wrote: > > In preparation for moving the PCIe driver into the drivers/pci/host > > directory, this header, which contains prototypes that are required by > > the PCIe driver, needs to be moved to a globally visible location. > > > > Signed-off-by: Thierry Reding > > --- > > Note that eventually the code in pmc.c and powergate.c should probably > > be split out into a separate driver. The PMC registers are also directly > > accessed from tegra20_clocks.c and tegra30_clocks.c, so that it might be > > required to provide that functionality through the new driver as well. > > --- > > arch/arm/mach-tegra/common.c | 2 +- > > arch/arm/mach-tegra/include/mach/pmc.h | 24 > > arch/arm/mach-tegra/pmc.h | 24 > > On IRC, we'd talked about putting the public functionality in > include/linux/tegra-pmc.h so that we wouldn't add to include/mach, which > would make it harder to make Tegra support ARM multi-platform. Perhaps > that IRC discussion happened after you posted this series? I'm not sure, it's equally possible that I just forgot. Will fix it up. Thierry pgpYYQdeC5h9_.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 02/14] of/pci: Add of_pci_get_devfn() function
On Thu, Jan 10, 2013 at 05:09:43PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > This function can be used to parse the device and function number from a
> > standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
> > the returned value obtain the device and function numbers respectively.
>
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>
> > static inline int __of_pci_pci_compare(struct device_node *node,
> >unsigned int devfn)
> > {
> > + int err;
> >
> > + err = of_pci_get_devfn(node);
> > + if (err < 0)
> > return 0;
> > +
> > + return devfn == err;
>
> I know this is really picky, but calling that "err" when it's hopefully
> not an error but rather a PCI device/function ID seems a little obscure.
> Perhaps node_devfn? I assume that fact that devfn is unsigned and err is
> signed won't be an issue.
Maybe renaming the devfn parameter to data and using devfn for the local
variable would be more obvious.
The signedness shouldn't be problematic. devfn is an 8-bit unsigned
integer and sign mismatch is excluded by the error return already.
Thierry
pgpWFcUZmiqAq.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/14] of/pci: Provide support for parsing PCI DT ranges property
On Thu, Jan 10, 2013 at 05:06:48PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > From: Andrew Murray
> >
> > DT bindings for PCI host bridges often use the ranges property to describe
> > memory and IO ranges - this binding tends to be the same across
> > architectures
> > yet several parsing implementations exist, e.g. arch/mips/pci/pci.c,
> > arch/powerpc/kernel/pci-common.c, arch/sparc/kernel/pci.c and
> > arch/microblaze/pci/pci-common.c (clone of PPC). Some of these duplicate
> > functionality provided by drivers/of/address.c.
> >
> > This patch provides a common iterator-based parser for the ranges property,
> > it
> > is hoped this will reduce DT representation differences between
> > architectures
> > and that architectures will migrate in part to this new parser.
> ...
>
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
>
> > +const __be32 *of_pci_process_ranges(struct device_node *node,
>
> > + while (from + np <= end) {
> > + u64 cpu_addr, size;
> > +
> > + cpu_addr = of_translate_address(node, from + na);
> > + size = of_read_number(from + na + pna, ns);
> > + res->flags = bus->get_flags(from);
> > + from += np;
> > +
> > + if (cpu_addr == OF_BAD_ADDR || size == 0)
> > + continue;
>
> Hmmm. That seems to just ignore bad entries in the ranges property. Is
> that really the right thing to do? At least printing a diagnostic might
> be a good idea, even if the code does just soldier on in the hope
> everything still works.
That's true. However, erroring out here wouln't be useful either since a
NULL return value is used to mark the end of the iteration and the
caller would have to assume that no more ranges are present. Maybe
that's better than continuing anyway, even if a message is printed.
Alternatively, the of_pci_process_ranges() could be changed to return an
ERR_PTR() encoded errno. This is one case where it makes a lot of sense.
I have a feeling that Grant won't like that very much, though.
Another possibility would be to change away from an iterator-based
approach and return an integer for the number of ranges and negative
error code on failure while returning an allocated array of resources
through an output parameter.
Thierry
pgpQtbqeonNRe.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Thu, Jan 10, 2013 at 05:48:46PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> > directory. The motivation is to collect various host controller drivers
> > in the same location in order to facilitate refactoring.
> >
> > The Tegra PCIe driver has been largely rewritten, both in order to turn
> > it into a proper platform driver and to add MSI (based on code by
> > Krishna Kishore ) as well as device tree support.
>
> > diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
> > b/arch/arm/mach-tegra/board-dt-tegra20.c
>
> > static void __init trimslice_init(void)
> > {
> > #ifdef CONFIG_TEGRA_PCI
> > - int ret;
> > -
> > - ret = tegra_pcie_init(true, true);
> > - if (ret)
> > - pr_err("tegra_pci_init() failed: %d\n", ret);
> > + platform_device_register(&tegra_pcie_device);
>
> That struct doesn't actually exist anywhere; only an extern definition
> is added (and that extern definition isn't removed by patch 14 either).
Right, this shouldn't be there. In fact TEGRA_PCI is removed by this
patch, so I should go over the code more carefully again.
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>
> > +config PCI_TEGRA
> > + bool "NVIDIA Tegra PCIe controller"
> > + depends on ARCH_TEGRA_2x_SOC
>
> Perhaps depend on ARCH_TEGRA; that will save churn once this is ported
> to Tegra30, and shouldn't cause any problems before then.
Okay, I can do that.
> > diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
>
> > +#define AFI_INTR_CODE 0xb8
> > +#define AFI_INTR_CODE_MASK0xf
> > +#define AFI_INTR_MASTER_ABORT 4
> > +#define AFI_INTR_LEGACY 6
>
> Adding defines for at least some other codes here, would help further
> below ...
>
> > +static irqreturn_t tegra_pcie_isr(int irq, void *arg)
>
> > + if (code == AFI_INTR_MASTER_ABORT) {
> > + dev_dbg(pcie->dev, "%s, signature: %08x\n", err_msg[code],
> > + signature);
> > + } else
> > + dev_err(pcie->dev, "%s, signature: %08x\n", err_msg[code],
> > + signature);
> > +
> > + if (code == 3 || code == 4 || code == 7) {
>
> ... i.e. here.
Will do.
>
> > + u32 fpci = afi_readl(pcie, AFI_UPPER_FPCI_ADDRESS) & 0xff;
> > + u64 address = (u64)fpci << 32 | (signature & 0xfffc);
> > + dev_dbg(pcie->dev, " FPCI address: %10llx\n", address);
>
> I'd suggest making that dev_err(), or at least something higher than
> debug, since the message indicating the error happened is dev_err(), so
> the complete details may as well be available since they're small.
I can make it conditional on !AFI_INTR_MASTER_ABORT to match the
previous output. Or rather move it into the branches above.
> > +static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
> > +{
> > + unsigned int timeout;
> > + unsigned long value;
> > +
> > + /* enable dual controller and both ports */
> > + value = afi_readl(pcie, AFI_PCIE_CONFIG);
> > + value &= ~(AFI_PCIE_CONFIG_PCIEC0_DISABLE_DEVICE |
> > + AFI_PCIE_CONFIG_PCIEC1_DISABLE_DEVICE |
> > + AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK);
> > + value |= AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
> > + afi_writel(pcie, value, AFI_PCIE_CONFIG);
>
> Eventually, we should probably derive the port enables from the state of
> the root port DT nodes, so that we can disable some and presumably save
> a little power. Also, I notice that the nvidia,num-lanes property isn't
> implemented yet. Still, we can probably take care of this later.
Yes, the plan was to eventually derive the disable bits from the port
status and setup the XBAR_CONFIG field based on the combination of
nvidia,num-lanes properties.
I assume we should simply fail if the configuration specified by
nvidia,num-lanes is invalid?
> > +static void tegra_pcie_power_off(struct tegra_pcie *pcie)
>
> > + if (!IS_ERR_OR_NULL(pcie->pex_clk_supply)) {
>
> Hmm. I think we should make supplies mandatory; it doesn't make sense
> for regulator support to be disabled on Tegra, and where a specific
> board doesn't actually have a regulator, you're supposed to provide a
> dummy fixed regulator so the driver doesn't have to care.
>
> The same comment obviously applies to tegra_pcie_power_on() and wherever
> regulator_get() happens.
Okay, I'll fix that.
> > +static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
>
> > + pcie->vdd_supply = devm_regulator_get(pcie->dev, "vdd");
> > + if (IS_ERR(pcie->vdd_supply))
> > + return PTR_ERR(pcie->vdd_supply);
> > +
> > + pcie->pex_clk_supply = devm_regulator_get(pcie->dev, "pex-clk");
> > + if (IS_ERR(pcie->pex_clk_supply))
> > + return PTR_ERR(pcie->pex_clk_supply);
>
> Oh, I guess the regulator_get() calls are already strict.
Yeah, I think they can't return NULL, right? In that case I can
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Thu, Jan 10, 2013 at 04:54:30PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> > directory. The motivation is to collect various host controller drivers
> > in the same location in order to facilitate refactoring.
> >
> > The Tegra PCIe driver has been largely rewritten, both in order to turn
> > it into a proper platform driver and to add MSI (based on code by
> > Krishna Kishore ) as well as device tree support.
>
> This driver doesn't compile unless CONFIG_PCI_MSI is also enabled.
> Should it select that, or contain a few ifdefs?
>
> drivers/pci/host/pci-tegra.c:900: undefined reference to `write_msi_msg'
Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
select PCI_MSI unconditionally. Once this is merged I was going to post
a patch that enables PCI_MSI in tegra_defconfig anyway. But it might be
better to keep it optional anyway since the remainder of the code copes
with it properly.
Thierry
pgpWbIsfKJRKt.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] ARM: dts: mxs-phy: Change mxs phy clock usage
On Thu, Jan 10, 2013 at 04:35:51PM +0800, Peter Chen wrote: > For mxs-phy user i.mx6q, the PHY's clock is controlled by > hardware automatically, the software only needs to enable it > at probe, this clock should be used like below: > > - Enable at mxs-phy's probe, and disable at mxs-phy's remove, so > The clk framework doesn't need to know it. But other mxs-phy user > mx28/mx23 may need it, so we give mxs-phy a dummy clock for imx6q. > - During the runtime, we don't need to control it. > Turning it into a dummy clock, you will have no way to maintain the use count. It could possibly cause parent clock be turned off while usbphy is in use. Let's try to find some other way. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/5] Input: Add ChromeOS EC keyboard driver
Hi Grant, On Wed, Dec 19, 2012 at 12:42 PM, Grant Likely wrote: > On Wed, Dec 19, 2012 at 8:20 PM, Simon Glass wrote: >> On Wed, Dec 19, 2012 at 10:16 AM, Dmitry Torokhov >> wrote: >>> >>> On Wed, Dec 19, 2012 at 12:57:22PM +, Grant Likely wrote: >>> > On Fri, 14 Dec 2012 17:43:31 -0800, Dmitry Torokhov >>> > wrote: >>> > > On Saturday, December 15, 2012 01:13:45 AM Grant Likely wrote: >>> > > > > +Required properties: >>> > > > > +- compatible: "google,cros-ec-keyb" >>> > > > > +- google,key-rows: Number of keyboard rows (must be <= 8) >>> > > > > +- google,key-columns: Number of keyboard columns (must be <= 13) >>> > > > > +- google,repeat-delay-ms: Key repeat delay in milliseconds >>> > > > > +- google,repeat-rate-ms: Key repeat rate in milliseconds >>> > > > >>> > > > Hmmm, these should probably be in a common binding. Take a look at >>> > > > the other input bindings and make a proposal for properties to add >>> > > > to >>> > > > matrix-keymap.txt. >>> > > >>> > > Actually these are not essentia for bringup and can be set from >>> > > userspace, >>> > > so I'd say simply drop them. >>> > >>> > Aren't they needed for a working keyboard? If so, I would really think >>> > they should be set correctly without userspace intervention. >>> >>> I am sorry if I was unclear, but I was actually talking about the last >>> 2: repeat-delay-ms and repeat-rate-ms. Input core has I believe sane >>> defaults (250 msec delay, 33 cps autorepeat) and user can adjust if >>> other rate is preferred. >> >> >> I seems like I should remove these two, then. >> >> It would be nice if we could keep these parameters so that the keyboard >> doesn't require user-space set up to work, but I understand and agree they >> are not essential. Regarding Grant's request to come up with a common >> binding, if I remove these then that is not needed, right? > > I have no problem keeping the properties, but it does look like > something applicable to all users, not just this driver. I dropped keyboard repeat from the common binding and resent. If that goes in then I can try again later when Dmitry is on holiday :-), or I can put it just in our own driver. I don't mind either way, so someone should let me know which is best. > > g. Regards, Simon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] input: Extend matrix-keypad device tree binding
Some matrix keypad drivers can support different numbers of rows and
columns. Add a generic binding for these.
Implementation note:
In order to implement this binding in the kernel, we will need to modify
matrix_keypad_() to look up the number of rows and cols in
the keymap. Perhaps this could be done by passing 0 for these parameters?
Many of the parameters can already be set to NULL. Ick.
Signed-off-by: Simon Glass
---
Changes in v2:
- Remove repeat rate parameters
- Update TI OMAP, tca8418 and lpc32xx bindings to use this one
.../devicetree/bindings/input/lpc32xx-key.txt |9 ++---
.../devicetree/bindings/input/matrix-keymap.txt|8
.../devicetree/bindings/input/omap-keypad.txt | 13 +
.../devicetree/bindings/input/tca8418_keypad.txt |6 --
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt
b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
index 31afd50..bcf62f8 100644
--- a/Documentation/devicetree/bindings/input/lpc32xx-key.txt
+++ b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
@@ -1,19 +1,22 @@
NXP LPC32xx Key Scan Interface
+This binding is based on the matrix-keymap binding with the following
+changes:
+
Required Properties:
- compatible: Should be "nxp,lpc3220-key"
- reg: Physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
-- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
-- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
- supports square matrices
- nxp,debounce-delay-ms: Debounce delay in ms
- nxp,scan-delay-ms: Repeated scan period in ms
- linux,keymap: the key-code to be reported when the key is pressed
and released, see also
Documentation/devicetree/bindings/input/matrix-keymap.txt
+Note: keypad,num-rows and keypad,num-columns are required, and must be equal
+since LPC32xx only supports square matrices
+
Example:
key@4005 {
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt
b/Documentation/devicetree/bindings/input/matrix-keymap.txt
index 3cd8b98..c54919f 100644
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
@@ -9,6 +9,12 @@ Required properties:
row << 24 | column << 16 | key-code
Optional properties:
+Properties for the number of rows and columns are optional because some
+drivers will use fixed values for these.
+- keypad,num-rows: Number of row lines connected to the keypad controller.
+- keypad,num-columns: Number of column lines connected to the keypad
+ controller.
+
Some users of this binding might choose to specify secondary keymaps for
cases where there is a modifier key such as a Fn key. Proposed names
for said properties are "linux,fn-keymap" or with another descriptive
@@ -17,3 +23,5 @@ word for the modifier other from "Fn".
Example:
linux,keymap = < 0x00030012
0x0102003a >;
+ keypad,num-rows = <2>;
+ keypad,num-columns = <8>;
diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt
b/Documentation/devicetree/bindings/input/omap-keypad.txt
index f2fa5e1..34ed1c6 100644
--- a/Documentation/devicetree/bindings/input/omap-keypad.txt
+++ b/Documentation/devicetree/bindings/input/omap-keypad.txt
@@ -6,19 +6,16 @@ A key can be placed at each intersection of a unique row and
a unique column.
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
+
Required SoC Specific Properties:
- compatible: should be one of the following
- "ti,omap4-keypad": For controllers compatible with omap4 keypad
controller.
-Required Board Specific Properties, in addition to those specified by
-the shared matrix-keyboard bindings:
-- keypad,num-rows: Number of row lines connected to the keypad
- controller.
-
-- keypad,num-columns: Number of column lines connected to the
- keypad controller.
-
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
index 2a1538f..2551850 100644
--- a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
+++ b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
@@ -1,8 +1,10 @@
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
Required properties:
- compatible: "ti,tca8418"
- reg: the I2C address
- interrupts: IRQ line number, should trigger on falling edge
-- keypad,num-rows: The number of rows
-- keypad,num-colu
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> directory. The motivation is to collect various host controller drivers
> in the same location in order to facilitate refactoring.
>
> The Tegra PCIe driver has been largely rewritten, both in order to turn
> it into a proper platform driver and to add MSI (based on code by
> Krishna Kishore ) as well as device tree support.
> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
> b/arch/arm/mach-tegra/board-dt-tegra20.c
> static void __init trimslice_init(void)
> {
> #ifdef CONFIG_TEGRA_PCI
> - int ret;
> -
> - ret = tegra_pcie_init(true, true);
> - if (ret)
> - pr_err("tegra_pci_init() failed: %d\n", ret);
> + platform_device_register(&tegra_pcie_device);
That struct doesn't actually exist anywhere; only an extern definition
is added (and that extern definition isn't removed by patch 14 either).
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> +config PCI_TEGRA
> + bool "NVIDIA Tegra PCIe controller"
> + depends on ARCH_TEGRA_2x_SOC
Perhaps depend on ARCH_TEGRA; that will save churn once this is ported
to Tegra30, and shouldn't cause any problems before then.
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> +#define AFI_INTR_CODE0xb8
> +#define AFI_INTR_CODE_MASK 0xf
> +#define AFI_INTR_MASTER_ABORT 4
> +#define AFI_INTR_LEGACY 6
Adding defines for at least some other codes here, would help further
below ...
> +static irqreturn_t tegra_pcie_isr(int irq, void *arg)
> + if (code == AFI_INTR_MASTER_ABORT) {
> + dev_dbg(pcie->dev, "%s, signature: %08x\n", err_msg[code],
> + signature);
> + } else
> + dev_err(pcie->dev, "%s, signature: %08x\n", err_msg[code],
> + signature);
> +
> + if (code == 3 || code == 4 || code == 7) {
... i.e. here.
> + u32 fpci = afi_readl(pcie, AFI_UPPER_FPCI_ADDRESS) & 0xff;
> + u64 address = (u64)fpci << 32 | (signature & 0xfffc);
> + dev_dbg(pcie->dev, " FPCI address: %10llx\n", address);
I'd suggest making that dev_err(), or at least something higher than
debug, since the message indicating the error happened is dev_err(), so
the complete details may as well be available since they're small.
> +static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
> +{
> + unsigned int timeout;
> + unsigned long value;
> +
> + /* enable dual controller and both ports */
> + value = afi_readl(pcie, AFI_PCIE_CONFIG);
> + value &= ~(AFI_PCIE_CONFIG_PCIEC0_DISABLE_DEVICE |
> +AFI_PCIE_CONFIG_PCIEC1_DISABLE_DEVICE |
> +AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK);
> + value |= AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
> + afi_writel(pcie, value, AFI_PCIE_CONFIG);
Eventually, we should probably derive the port enables from the state of
the root port DT nodes, so that we can disable some and presumably save
a little power. Also, I notice that the nvidia,num-lanes property isn't
implemented yet. Still, we can probably take care of this later.
> +static void tegra_pcie_power_off(struct tegra_pcie *pcie)
> + if (!IS_ERR_OR_NULL(pcie->pex_clk_supply)) {
Hmm. I think we should make supplies mandatory; it doesn't make sense
for regulator support to be disabled on Tegra, and where a specific
board doesn't actually have a regulator, you're supposed to provide a
dummy fixed regulator so the driver doesn't have to care.
The same comment obviously applies to tegra_pcie_power_on() and wherever
regulator_get() happens.
> +static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
> + pcie->vdd_supply = devm_regulator_get(pcie->dev, "vdd");
> + if (IS_ERR(pcie->vdd_supply))
> + return PTR_ERR(pcie->vdd_supply);
> +
> + pcie->pex_clk_supply = devm_regulator_get(pcie->dev, "pex-clk");
> + if (IS_ERR(pcie->pex_clk_supply))
> + return PTR_ERR(pcie->pex_clk_supply);
Oh, I guess the regulator_get() calls are already strict.
> +static int tegra_pcie_add_port(struct tegra_pcie *pcie, struct device_node
> *np)
> + port = devm_kzalloc(pcie->dev, sizeof(*port), GFP_KERNEL);
> + if (!port)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&port->list);
> + port->index = index;
> + port->pcie = pcie;
> +
> + port->base = devm_request_and_ioremap(pcie->dev, ®s);
> + if (!port->base)
> + return -EADDRNOTAVAIL;
> +
> + if (!tegra_pcie_port_check_link(port)) {
> + dev_info(pcie->dev, "link %u down, ignoring\n", port->index);
Perhaps devm_kfree(port)? Not a big leak, but equally if you don't, it's
an unreferenced memory block.
> + return -ENODEV;
> + }
> +
> + list_add_tail(&port->list, &pcie->ports);
> +
> + return 0;
> +}
___
Re: [PATCH 12/14] ARM: tegra: tec: Add PCIe support
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> Enable the first PCIe root port which is connected to an FPGA on the
> Tamonten Evaluation Carrier and add device nodes for each of the PCI
> endpoints available in the standard configuration.
> diff --git a/arch/arm/boot/dts/tegra20-tec.dts
> b/arch/arm/boot/dts/tegra20-tec.dts
> + pcie-controller {
> + vdd-supply = <&pci_vdd_reg>;
> + pex-clk-supply = <&pci_clk_reg>;
> + status = "okay";
Sorry this is also really picky. I'd prefer properties that exist in
/include/d files and are overidden here to appear first, followed by new
properties. In other words, move the status property to be first. I
believe/hope all the other (Tegra) .dts files follow this convention.
> + pci@1,0 {
> + bus-range = <0x01 0x0a>;
> + status = "okay";
> +
> + pci@0,0 {
> + reg = <0x01 0 0 0 0>;
Hmm. The unit address in that node name doesn't match the address in the
reg property, although I suppose there's nothing we can do about it
since those formats are both defined by the standard PCI binding?
What do the numbers "0,0" represent here; device/function? Is the same
true for the "0,0" in the child nodes?
> + bus-range = <0x02 0x0a>;
> +
> + compatible = "plda,pcie";
Are there DT binding documents for all these devices; plda,pcie,
ad,pcie, ad,pcie-test, etc.?
> + pci@4,0 {
> + reg = <0x022000 0 0 0 0>;
> + bus-range = <0x07 0x07>;
> +
> + compatible = "ad,pcie";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + pci@0,0 {
> + compatible = "opencores,uart";
> + reg = <0x07 0 0 0 0>;
> + };
> + };
Do you need to include a node for the UART; I can see you need to for
the SPI/I2C controllers so you can instantiate the appropriate devices
on non-probe-able buses, but I think you can just let regular PCI device
probing find the UART, Ethernet MAC, etc., can't you?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 09/14] ARM: tegra: Move pmc.h to include/mach
On 01/09/2013 01:43 PM, Thierry Reding wrote: > In preparation for moving the PCIe driver into the drivers/pci/host > directory, this header, which contains prototypes that are required by > the PCIe driver, needs to be moved to a globally visible location. > > Signed-off-by: Thierry Reding > --- > Note that eventually the code in pmc.c and powergate.c should probably > be split out into a separate driver. The PMC registers are also directly > accessed from tegra20_clocks.c and tegra30_clocks.c, so that it might be > required to provide that functionality through the new driver as well. > --- > arch/arm/mach-tegra/common.c | 2 +- > arch/arm/mach-tegra/include/mach/pmc.h | 24 > arch/arm/mach-tegra/pmc.h | 24 On IRC, we'd talked about putting the public functionality in include/linux/tegra-pmc.h so that we wouldn't add to include/mach, which would make it harder to make Tegra support ARM multi-platform. Perhaps that IRC discussion happened after you posted this series? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 02/14] of/pci: Add of_pci_get_devfn() function
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> This function can be used to parse the device and function number from a
> standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
> the returned value obtain the device and function numbers respectively.
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> static inline int __of_pci_pci_compare(struct device_node *node,
> unsigned int devfn)
> {
> + int err;
>
> + err = of_pci_get_devfn(node);
> + if (err < 0)
> return 0;
> +
> + return devfn == err;
I know this is really picky, but calling that "err" when it's hopefully
not an error but rather a PCI device/function ID seems a little obscure.
Perhaps node_devfn? I assume that fact that devfn is unsigned and err is
signed won't be an issue.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/14] of/pci: Provide support for parsing PCI DT ranges property
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> From: Andrew Murray
>
> DT bindings for PCI host bridges often use the ranges property to describe
> memory and IO ranges - this binding tends to be the same across architectures
> yet several parsing implementations exist, e.g. arch/mips/pci/pci.c,
> arch/powerpc/kernel/pci-common.c, arch/sparc/kernel/pci.c and
> arch/microblaze/pci/pci-common.c (clone of PPC). Some of these duplicate
> functionality provided by drivers/of/address.c.
>
> This patch provides a common iterator-based parser for the ranges property, it
> is hoped this will reduce DT representation differences between architectures
> and that architectures will migrate in part to this new parser.
...
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> +const __be32 *of_pci_process_ranges(struct device_node *node,
> + while (from + np <= end) {
> + u64 cpu_addr, size;
> +
> + cpu_addr = of_translate_address(node, from + na);
> + size = of_read_number(from + na + pna, ns);
> + res->flags = bus->get_flags(from);
> + from += np;
> +
> + if (cpu_addr == OF_BAD_ADDR || size == 0)
> + continue;
Hmmm. That seems to just ignore bad entries in the ranges property. Is
that really the right thing to do? At least printing a diagnostic might
be a good idea, even if the code does just soldier on in the hope
everything still works.
> + res->name = node->full_name;
> + res->start = cpu_addr;
> + res->end = res->start + size - 1;
> + res->parent = res->child = res->sibling = NULL;
> + return from;
> + }
> +
> + return NULL;
> +}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [REPOST PATCH v3 1/4] mmc: dw_mmc: Add "disable-wp" device tree property
Hi, A followup as I did more investigation here... On Thu, Jan 10, 2013 at 3:23 PM, Doug Anderson wrote: > Olof, > > Thanks for your comments. > > On Thu, Jan 10, 2013 at 3:01 PM, Olof Johansson wrote: >> >> The previous code used the controller-common quirk field to set a >> per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT. Is there really need to >> do this per-slot? And if so, please explain in the commit message why >> there is need for a brand new quirk for the same functionality. > > I'm happy to move back to using a per-controller quirk here--it > simplifies the code quite a bit since it can use all of the > preexisting quirks code. I originally coded it up as per-slot since > generally each slot needs its own write-protect line. Without ever > seeing any hardware using multiple slots per controller I can't say > how common this would be, so it may be overkill to handle that > situation. Actually, it looks like the per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT was added at the same time as the code using it was added to 'drivers/mmc/host/dw_mmc-exynos.c'. Since this patch series removes the code from dw_mmc-exynos.c I can also remove the controller-level quirk. ...I'll plan to spin a new rev tomorrow that leaves the 'no write protect' quirk at the slot level but removes the old controller-level quirk. :) -Doug ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 13/14] ARM: tegra: harmony: Initialize PCIe from DT
On 01/09/2013 01:43 PM, Thierry Reding wrote: > With the device tree support in place, probe the PCIe controller from > the device tree and remove the corresponding workaround in the board > file. For some reason, the ports on Harmony fail to initialize correctly with this driver, although they do with plain next-20130109: > [2.698922] tegra-pcie 80003000.pcie-controller: link 0 down, retrying > [2.925722] tegra-pcie 80003000.pcie-controller: link 0 down, retrying > [3.155411] tegra-pcie 80003000.pcie-controller: link 0 down, retrying > [3.178428] tegra-pcie 80003000.pcie-controller: link 0 down, ignoring > [3.199713] tegra-pcie 80003000.pcie-controller: failed to add port pci: > -19 ^^^ There's definitely something plugged into this port, and it's enumerated OK with the old driver. > [3.433551] tegra-pcie 80003000.pcie-controller: link 1 down, retrying > [3.667624] tegra-pcie 80003000.pcie-controller: link 1 down, retrying ... > [3.901493] tegra-pcie 80003000.pcie-controller: link 1 down, retrying > [3.902589] tegra-pcie 80003000.pcie-controller: link 1 down, ignoring > [3.902615] tegra-pcie 80003000.pcie-controller: failed to add port pci: > -19 > [3.903780] tegra-pcie 80003000.pcie-controller: PCI host bridge to bus > :00 > [3.903815] pci_bus :00: root bus resource [io 0x8200-0x8200] > [3.903844] pci_bus :00: root bus resource [mem 0xa000-0xafff] > [3.903871] pci_bus :00: root bus resource [mem 0xb000-0xbfff > pref] > [3.903901] pci_bus :00: root bus resource [bus 00-ff] ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 14/14] ARM: tegra: trimslice: Initialize PCIe from DT
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> With the device tree support in place, probe the PCIe controller from
> the device tree and remove the corresponding workaround in the board
> file.
Thierry, there are a couple things missing from this patch; I include a
fixup for you to squash in, but also see beyond that for a problem.
> arch/arm/boot/dts/tegra20-trimslice.dts | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts
> b/arch/arm/boot/dts/tegra20-trimslice.dts
> index ebb4c17..41fc45b 100644
> --- a/arch/arm/boot/dts/tegra20-trimslice.dts
> +++ b/arch/arm/boot/dts/tegra20-trimslice.dts
> @@ -303,12 +303,10 @@
>
> pcie-controller {
> status = "okay";
> + pex-clk-supply = <&pci_clk_reg>;
> + vdd-supply = <&pci_vdd_reg>;
>
> - pci@0 {
> - status = "okay";
> - };
> -
> - pci@1 {
> + pci@1,0 {
> status = "okay";
> };
> };
> @@ -366,6 +364,24 @@
> regulator-max-microvolt = <180>;
> regulator-always-on;
> };
> +
> + pci_clk_reg: regulator@2 {
> + compatible = "regulator-fixed";
> + reg = <2>;
> + regulator-name = "pci_clk";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + pci_vdd_reg: regulator@3 {
> + compatible = "regulator-fixed";
> + reg = <3>;
> + regulator-name = "pci_vdd";
> + regulator-min-microvolt = <105>;
> + regulator-max-microvolt = <105>;
> + regulator-always-on;
> + };
> };
>
> sound {
> --
> 1.7.10.4
However, PCIe still doesn't work on TrimSlice; the device enumeration
fails. The log is below:
> [0.790425] tegra-pcie 80003000.pcie-controller: link 0 down, retrying
> [0.801351] tegra-pcie 80003000.pcie-controller: PCI host bridge to bus
> :00
> [0.808945] pci_bus :00: root bus resource [io 0x8200-0x8200]
> [0.816109] pci_bus :00: root bus resource [mem 0xa000-0xafff]
> [0.823303] pci_bus :00: root bus resource [mem 0xb000-0xbfff
> pref]
> [0.830893] pci_bus :00: root bus resource [bus 00-ff]
> [0.836728] pci :00:01.0: [10de:0bf0] type 01 class 0x06
> [0.843097] pci :00:01.0: PME# supported from D0 D1 D2 D3hot D3cold
> [0.850047] PCI: bus0: Fast back to back transfers disabled
> [0.855853] pci :00:01.0: bridge configuration invalid ([bus 00-00]),
> reconfiguring
> [0.864308] tegra-pcie 80003000.pcie-controller: AXI response decoding
> error, signature: 10010001
> [0.873489] tegra-pcie 80003000.pcie-controller: FPCI address: fe1001
^^^ For some reason, the config register access fails.
> [0.880760] PCI: bus1: Fast back to back transfers enabled
> [0.886482] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
> [0.893381] pci :00:01.0: PCI bridge to [bus 01]
> [0.898577] PCI: enabling device :00:01.0 (0140 -> 0143)
> [0.904535] pci :00:01.0: nv_msi_ht_cap_quirk didn't locate host bridge
With plain next-20130109, the device enumeration succeeds.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On 01/09/2013 01:43 PM, Thierry Reding wrote: > Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host > directory. The motivation is to collect various host controller drivers > in the same location in order to facilitate refactoring. > > The Tegra PCIe driver has been largely rewritten, both in order to turn > it into a proper platform driver and to add MSI (based on code by > Krishna Kishore ) as well as device tree support. This driver doesn't compile unless CONFIG_PCI_MSI is also enabled. Should it select that, or contain a few ifdefs? drivers/pci/host/pci-tegra.c:900: undefined reference to `write_msi_msg' ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 02/16] ARM: davinci: move private EDMA API to arm/common
On Sun, Oct 28, 2012 at 01:47:09PM +0530, Sekhar Nori wrote:
> On 10/18/2012 6:56 PM, Matt Porter wrote:
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx) as well. This just moves the
> > private EDMA API but does not support OMAP.
> >
> > Signed-off-by: Matt Porter
> > ---
>
> > diff --git a/arch/arm/mach-davinci/devices.c
> > b/arch/arm/mach-davinci/devices.c
> > index 4c48a36..f45d591 100644
> > --- a/arch/arm/mach-davinci/devices.c
> > +++ b/arch/arm/mach-davinci/devices.c
> > @@ -19,9 +19,10 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > +#include
>
> Can you please introduce a patch to clean this mixture of linux/ and
> mach/ includes?
Yeah, are you ok with a follow on series to clean all these files? I
don't want to make this series longer with something not dma related
that's purely cleanup from the great header reorg of 2012.
> > +
> >
> > #include "davinci.h"
> > #include "clock.h"
> > @@ -141,10 +142,10 @@ static struct resource mmcsd0_resources[] = {
> > },
> > /* DMA channels: RX, then TX */
> > {
> > - .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
> > + .start = EDMA_CTLR_CHAN(0, 26),
>
> Instead of just replacing the event #defines with plain numbers, can you
> introduce a mach-davinci local edma.h which can then be included in the
> davinci platform files which refer to edma channel numbers?
Ok, so when I removed the old edma.h it was full of unused defines and
we are left with just this one. If I introduced something like that it
would be used in just one place here. and only for these two values.
How about we just add a comment?
>
> > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> > index 7cd56ed..153fab8 100644
> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -28,6 +28,7 @@ config ARCH_OMAP2PLUS
> > select OMAP_DM_TIMER
> > select PROC_DEVICETREE if PROC_FS
> > select SPARSE_IRQ
> > + select TI_PRIV_EDMA
>
> This hunk does not seem to belong to subject of this patch.
Let me reword the subject/description. The idea of this logical
chunk was to put everything in place to make it build on OMAP,
with the expectation that the build fails without the next patch
in the series.
> > select USE_OF
> > help
> > "Systems based on OMAP2, OMAP3, OMAP4 or OMAP5"
>
> > diff --git a/include/linux/platform_data/edma.h
> > b/include/linux/platform_data/edma.h
> > new file mode 100644
> > index 000..7396f0b3
> > --- /dev/null
> > +++ b/include/linux/platform_data/edma.h
> > @@ -0,0 +1,198 @@
> > +/*
> > + * TI DAVINCI dma definitions
> > + *
> > + * Copyright (C) 2006-2009 Texas Instruments.
> > + *
> > + * 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> > + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> > OF
> > + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> > IN
> > + * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT,
> > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> > BUT
> > + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> > OF
> > + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> > ON
> > + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> > TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> > OF
> > + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> > + * You should have received a copy of the GNU General Public License
> > along
> > + * with this program; if not, write to the Free Software Foundation,
> > Inc.,
> > + * 675 Mass Ave, Cambridge, MA 02139, USA.
>
> This part can be dropped, I suppose ;-)
Indeed :)
-Matt
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [REPOST PATCH v3 1/4] mmc: dw_mmc: Add "disable-wp" device tree property
Olof, Thanks for your comments. On Thu, Jan 10, 2013 at 3:01 PM, Olof Johansson wrote: > > The previous code used the controller-common quirk field to set a > per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT. Is there really need to > do this per-slot? And if so, please explain in the commit message why > there is need for a brand new quirk for the same functionality. I'm happy to move back to using a per-controller quirk here--it simplifies the code quite a bit since it can use all of the preexisting quirks code. I originally coded it up as per-slot since generally each slot needs its own write-protect line. Without ever seeing any hardware using multiple slots per controller I can't say how common this would be, so it may be overkill to handle that situation. Note that I think of the new code as being the device-tree equivalent of the non-device-tree "brd->get_ro(slot_id)" function. That function is per-slot. I will wait a day or two to see if others have feedback. If I hear no feedback I'll send up a patch that moves this to be at the controller level. Thanks! -Doug ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [REPOST PATCH v3 1/4] mmc: dw_mmc: Add "disable-wp" device tree property
On Thu, Jan 10, 2013 at 10:24:26AM -0800, Doug Anderson wrote: > The "disable-wp" property is used to specify that a given SD card slot > doesn't have a concept of write protect. This eliminates the need for > special case code for SD slots that should never be write protected > (like a micro SD slot or a dev board). > > The dw_mmc driver is special in needing to specify "disable-wp" > because the lack of a "wp-gpios" property means to use the special > purpose write protect line. On some other mmc devices the lack of > "wp-gpios" means that write protect should be disabled. Hi, The previous code used the controller-common quirk field to set a per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT. Is there really need to do this per-slot? And if so, please explain in the commit message why there is need for a brand new quirk for the same functionality. It's even uncertain if there are any systems out there that uses the multi-slot functionality of this driver to date, most seem to map one slot per controller in the first place... -Olof ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 05/16] ARM: edma: add AM33XX crossbar event support
On Sun, Oct 28, 2012 at 04:41:24PM +0530, Sekhar Nori wrote:
> On 10/18/2012 6:56 PM, Matt Porter wrote:
> > Adds support for the per-EDMA channel event mux. This is required
> > for any peripherals using DMA crossbar mapped events.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/common/edma.c | 63
> > +++-
> > include/linux/platform_data/edma.h |1 +
> > 2 files changed, 63 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> > index 6d2a590..b761b7a 100644
> > --- a/arch/arm/common/edma.c
> > +++ b/arch/arm/common/edma.c
> > @@ -1425,6 +1425,53 @@ static int edma_of_read_u32_to_s16_array(const
> > struct device_node *np,
> > return 0;
> > }
> >
> > +static int edma_xbar_event_map(struct device *dev,
> > + struct device_node *node,
> > + struct edma_soc_info *pdata, int len)
> > +{
> > + int ret = 0;
> > + int i;
> > + struct resource res;
> > + void *xbar;
> > + s16 (*xbar_chans)[2];
> > + u32 shift, offset, mux;
> > +
> > + xbar_chans = devm_kzalloc(dev,
> > + len/sizeof(s16) + 2*sizeof(s16),
> > + GFP_KERNEL);
> > + if (!xbar_chans)
> > + return -ENOMEM;
> > +
> > + ret = of_address_to_resource(node, 1, &res);
> > + if (IS_ERR_VALUE(ret))
> > + return -EIO;
> > +
> > + xbar = devm_ioremap(dev, res.start, resource_size(&res));
> > + if (!xbar)
> > + return -EIO;
>
> -ENOMEM is more appropiate for ioremap failures.
Fixed in v4.
>
> > +
> > + ret = edma_of_read_u32_to_s16_array(node,
> > + "ti,edma-xbar-event-map",
> > + (s16 *)xbar_chans,
> > + len/sizeof(u32));
> > + if (IS_ERR_VALUE(ret))
> > + return -EIO;
> > +
> > + for (i = 0; xbar_chans[i][0] != -1; i++) {
> > + shift = (xbar_chans[i][1] % 4) * 8;
> > + offset = xbar_chans[i][1] >> 2;
> > + offset <<= 2;
> > + mux = __raw_readl((void *)((u32)xbar + offset));
>
> Dont use __raw* variants of io accessors. There will be ordering issues
> on ARMv7.
Fixed in v4.
>
> > + mux &= (~(0xff << shift));
> > + mux |= (xbar_chans[i][0] << shift);
>
> Unnecessary parens above.
Fixed in v4.
>
> > + __raw_writel(mux, (void *)((u32)xbar + offset));
> > + }
> > +
> > + pdata->xbar_chans = xbar_chans;
> > +
> > + return 0;
> > +}
> > +
> > static int edma_of_parse_dt(struct device *dev,
> > struct device_node *node,
> > struct edma_soc_info *pdata)
> > @@ -1453,7 +1500,6 @@ static int edma_of_parse_dt(struct device *dev,
> > pdata->n_slot = value;
> >
> > pdata->n_cc = 1;
> > - /* This is unused */
>
> The comment should have not been part of 4/16?
Correct. I moved the change to the correct patch in v4.
>
> Thanks,
> Sekhar
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 09:20:07PM +0100, Thierry Reding wrote: > > Arnd's version is good too, but you would be restricted to aligned > > powers of two for the bus number range in the DT, which is probably > > not that big a deal either? > > Stephen suggested on IRC that we could try to keep a bit of dynamicity > in the allocation scheme if we create the bus mapping when the first > device on the bus is probed and discard the mapping if no devices are > found. You probably don't need to mess around with 'discard on empty' the kernel should only access bus numbers that are in the range of the subordinate busses of the bridges. So if you establish a mapping on a bus-by-bus basis at first access, it should be fine and very close to minimal.. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On 15:49-20130110, Matt Porter wrote: > On Thu, Jan 10, 2013 at 01:46:53PM -0600, Nishanth Menon wrote: > > On 14:35-20130110, Matt Porter wrote: > > > On Sun, Oct 28, 2012 at 05:01:29PM +0530, Sekhar Nori wrote: > > > > On 10/18/2012 6:56 PM, Matt Porter wrote: [...] > > > > > > + 0x19c 0x13 /* > > > > > mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */ > > > > > + >; > > > > > > > > Is there a single pinmux setting that provides SPI functionality on the > > > > bone headers? Or this is specific to a cape you tested with? > > > > > > No, there are two usable settings for spi1 and one setting for spi0. > > > I'm dropping this from the series since it's specific to how I wired up > > > the homebrew cape I use for spi testing on the Bone. I publish the > > > branch where all these extra "test-specific" patches (that aren't intended > > > to be merged) are at in the cover letter. Anybody that needs context of > > > how/what worked and was tested can grab them there. > > Possibly dumb question: > > Cant we have pre-usable spi configurations? Like spi1_configuration1_pins, > > spi2_configuration1_pins, spi0_configuration1_pins? If documented with > > P9 pin names in the bone dts, it saves a bit of effort in looking up > > pad offset when dealing with capes. > > Yes, let's introduce these things separately. I plan to reintroduce > patches to fix the incorrect 1-based numbering on many of the AM33xx as > previous ones were dropped...and I think this makes sense on top of > that. sounds good to me. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On Thu, Jan 10, 2013 at 01:46:53PM -0600, Nishanth Menon wrote:
> On 14:35-20130110, Matt Porter wrote:
> > On Sun, Oct 28, 2012 at 05:01:29PM +0530, Sekhar Nori wrote:
> > > On 10/18/2012 6:56 PM, Matt Porter wrote:
> > > > Adds AM33XX SPI support for am335x-bone and am335x-evm.
> > > >
> > > > Signed-off-by: Matt Porter
> > > > ---
> > > > arch/arm/boot/dts/am335x-bone.dts | 17 +++
> > > > arch/arm/boot/dts/am335x-evm.dts |9
> > > > arch/arm/boot/dts/am33xx.dtsi | 43
> > > > +
> > > > 3 files changed, 69 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > > > b/arch/arm/boot/dts/am335x-bone.dts
> > > > index 5510979..23edfd8 100644
> > > > --- a/arch/arm/boot/dts/am335x-bone.dts
> > > > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > > > @@ -18,6 +18,17 @@
> > > > reg = <0x8000 0x1000>; /* 256 MB */
> > > > };
> > > >
> > > > + am3358_pinmux: pinmux@44e10800 {
> > > > + spi1_pins: pinmux_spi1_pins {
> > > > + pinctrl-single,pins = <
> > > > + 0x190 0x13 /*
> > > > mcasp0_aclkx.spi1_sclk, OUTPUT_PULLUP | MODE3 */
> > > > + 0x194 0x33 /* mcasp0_fsx.spi1_d0,
> > > > INPUT_PULLUP | MODE3 */
> > > > + 0x198 0x13 /* mcasp0_axr0.spi1_d1,
> > > > OUTPUT_PULLUP | MODE3 */
> minor comment:
> doing as a 0x33 is better for both d1, d0 as D0,D1 can be switched between
> SDI and SDO
> as needed with ti,pindir-d0-out-d1-in
Yes, thanks. Forgot about the new property and feature even though I
told somebody about it yesterday. :)
> > > > + 0x19c 0x13 /*
> > > > mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
> > > > + >;
> > >
> > > Is there a single pinmux setting that provides SPI functionality on the
> > > bone headers? Or this is specific to a cape you tested with?
> >
> > No, there are two usable settings for spi1 and one setting for spi0.
> > I'm dropping this from the series since it's specific to how I wired up
> > the homebrew cape I use for spi testing on the Bone. I publish the
> > branch where all these extra "test-specific" patches (that aren't intended
> > to be merged) are at in the cover letter. Anybody that needs context of
> > how/what worked and was tested can grab them there.
> Possibly dumb question:
> Cant we have pre-usable spi configurations? Like spi1_configuration1_pins,
> spi2_configuration1_pins, spi0_configuration1_pins? If documented with
> P9 pin names in the bone dts, it saves a bit of effort in looking up
> pad offset when dealing with capes.
Yes, let's introduce these things separately. I plan to reintroduce
patches to fix the incorrect 1-based numbering on many of the AM33xx as
previous ones were dropped...and I think this makes sense on top of
that.
-Matt
> --
> Regards,
> Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
* Andreas Fenkart [121220 14:15]:
> Without functional clock the omap_hsmmc module can't forward
> SDIO IRQs to the system. This patch reconfigures dat1 line
> as a gpio while the fclk is off. And uses SDIO IRQ detection of
> the module, while fclk is present.
Looks pretty good to me, however I could not figure out what
to apply this on for testing. It fails to apply at least against
current linux next, can you please update against that?
> +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
> +{
> + struct omap_hsmmc_host *host = mmc_priv(mmc);
> + u32 irq_mask;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->irq_lock, flags);
> +
> + host->sdio_irq_en = (enable != 0) ? true : false;
> +
> + if (host->active_pinmux) {
> + irq_mask = OMAP_HSMMC_READ(host->base, ISE);
> + if (enable)
> + irq_mask |= CIRQ_ENABLE;
> + else
> + irq_mask &= ~CIRQ_ENABLE;
> + OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
> +
> + if (!host->req_in_progress)
> + OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
> +
> +#if 0
> + OMAP_HSMMC_READ(host->base, IE); /* flush posted write */
> +#endif
Maybe just replace #if 0 with just a comment in case it turns out to be
needed for some cases?
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 13/16] ARM: dts: add AM33XX MMC support
On Tue, Oct 30, 2012 at 05:33:40AM +, AnilKumar wrote:
> On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
> > Adds AM33XX MMC support for am335x-bone and am335x-evm.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/am335x-bone.dts |6 ++
> > arch/arm/boot/dts/am335x-evm.dts |6 ++
> > arch/arm/boot/dts/am33xx.dtsi | 27 +++
> > 3 files changed, 39 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > b/arch/arm/boot/dts/am335x-bone.dts
> > index c634f87..5510979 100644
> > --- a/arch/arm/boot/dts/am335x-bone.dts
> > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > @@ -70,6 +70,8 @@
> > };
> >
> > ldo3_reg: regulator@5 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <330>;
>
> I think these min & max limits are regulator limits. Are these fields
> required? Add details of these additions. AFAIK fine-tuned (board
> specific) min/max limits should be add here(like mpu and core
> regulator nodes)
This is required as the mmc driver builds the ocr mask from the
regulator range..and won't run without it. However, with the additional
updates since 3.7-rc1 to the am33xx release dts support, this is already
there so you won't see this hunk in v4.
> > regulator-always-on;
> > };
> >
> > @@ -78,3 +80,7 @@
> > };
> > };
> > };
> > +
> > +&mmc1 {
> > + vmmc-supply = <&ldo3_reg>;
> > +};
> > diff --git a/arch/arm/boot/dts/am335x-evm.dts
> > b/arch/arm/boot/dts/am335x-evm.dts
> > index 185d632..d63fce8 100644
> > --- a/arch/arm/boot/dts/am335x-evm.dts
> > +++ b/arch/arm/boot/dts/am335x-evm.dts
> > @@ -114,7 +114,13 @@
> > };
> >
> > vmmc_reg: regulator@12 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <330>;
>
> =same=
as above.
>
> > regulator-always-on;
> > };
> > };
> > };
> > +
> > +&mmc1 {
> > + vmmc-supply = <&vmmc_reg>;
> > +};
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index ab9c78f..26a6af7 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -234,6 +234,33 @@
> > status = "disabled";
> > };
> >
> > + mmc1: mmc@4806 {
> > + compatible = "ti,omap3-hsmmc";
> > + ti,hwmods = "mmc1";
> > + ti,dual-volt;
> > + ti,needs-special-reset;
> > + dmas = <&edma 24
> > + &edma 25>;
> > + dma-names = "tx", "rx";
>
> Add status = "disabled" here and "okay" in corresponding
> .dts file
yeah, I originally decided to avoid fixing non-dma related items, but
I'll fix this up in v4 while I'm there...to match the other mmc nodes.
> > + };
> > +
> > + mmc2: mmc@481d8000 {
> > + compatible = "ti,omap3-hsmmc";
> > + ti,hwmods = "mmc2";
> > + ti,needs-special-reset;
> > + dmas = <&edma 2
> > + &edma 3>;
> > + dma-names = "tx", "rx";
> > + status = "disabled";
> > + };
> > +
> > + mmc3: mmc@4781 {
> > + compatible = "ti,omap3-hsmmc";
> > + ti,hwmods = "mmc3";
> > + ti,needs-special-reset;
>
> What about DMA resources for mmc3?
DMA resources for mmc3 are "special" in that mmc3 (actually MMC2 due
to the hwmod fortran style numbering) is on the crossbar. Since
dmaengine has no concept of a mux in front of dmac channels, we handle
our mux with h/w specific properties. What this means is that we can't
hardcode DMA resources for mmc3 (MMC2) or any other peripheral that sits
on the crossbar as they aren't a fixed EDMA channel.
Since the only peripheral sitting on mmc3 (or any crossbar based DMA
event) on one of the am33xx boards in wl12xx, I can't provide an example
of how this is done within this series...as wl12xx has no DT support and
can't be used.
However, for testing, I did a simple gpio event driver using a GPIO
instance on the crossbar. This purely an out-of-tree testing thing wired
op on the BeagleBone but it looks like this:
&edma {
ti,edma-xbar-event-map = <32 12>;
};
gpevt {
compatible = "gpevt";
dmas = <&edma 12>;
dma-names = "gpioevt";
gpio-evt = <&gpio3 2 0>;
};
The first node adds a crossbar event mapping (application-specific)
which maps GPIOEVT2 to EDMA channel 12 (an open channel with no fixed
peripheral use.
The gpevt device node then configures the board specific dma resources.
I don't see any reason to configure board specific dma resources fo
Re: [PATCH 11/14] ARM: tegra: tamonten: Add PCIe support
On Wed, Jan 09, 2013 at 09:23:37PM +, Arnd Bergmann wrote: > On Wednesday 09 January 2013, Thierry Reding wrote: > > Signed-off-by: Thierry Reding > > --- > > arch/arm/boot/dts/tegra20-tamonten.dtsi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > It's not clear how this one-line patch adds PCIe support to the > platform. Are you missing the actual change here? This is really just required to associate a name with the regulator, but I think I can achieve the same by adding an alias to the TEC DTSI. Thierry pgpgETYzGh9JD.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 12:24:17PM -0700, Jason Gunthorpe wrote: > On Thu, Jan 10, 2013 at 08:03:27PM +0100, Thierry Reding wrote: > > > > > You'd piece a mapping together, each bus requires 16 64k mappings, a > > > > simple 2d array of busnr*16 of pointers would do the trick. A more > > > > clever solution would be to allocate contiguous virtual memory and > > > > split that up.. > > > > Oh, I see. I'm not very familiar with the internals of remapping, so > > > I'll need to do some more reading. Thanks for the hints. > > > > I forgot to ask. What's the advantage of having a contiguous virtual > > memory area and splitting it up versus remapping each chunk separately? > > Not alot, really, but it saves you from the pointer array and > associated overhead. IIRC it is fairly easy to do in the kernel. I've been investigating this a bit, and one problem is that it will prevent the driver from ever building as a module because the necessary functions aren't exported and I'm not sure exporting them would be acceptable. Currently PCI host controller drivers with MSI support can't be built as modules because the MSI infrastructure requires it, but I briefly discussed this with Bjorn at some point and it should be easy to remove that requirement. > Arnd's version is good too, but you would be restricted to aligned > powers of two for the bus number range in the DT, which is probably > not that big a deal either? Stephen suggested on IRC that we could try to keep a bit of dynamicity in the allocation scheme if we create the bus mapping when the first device on the bus is probed and discard the mapping if no devices are found. Sounds like a good plan to me. Does anybody see any potential pitfalls? Thierry pgp9CxDWcSfcZ.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Added device tree binding for TDM and TDM phy
On 01/10/2013 03:24:21 AM, Singh Sandeep-B37400 wrote: > > > +- compatible > > > +Value type: > > > +Definition: Should contain generic compatibility like > > "tdm-phy-slic" > > > or > > > +"tdm-phy-e1" or "tdm-phy-t1". > > Does this "generic" string (plus the other properties) tell you all you > need to know about the device? If there are other possible "generic" > compatibles, they should be listed or else different people will make up > different strings for the same thing. This property will describe the type of device, and will help TDM framework to know if it is E1/T1/SLIC device. Further details can be extracted from other compatible strings. There are only three generic compatibles field types, which are already mentioned in definition. Do I need to make this thing more clear. The word "like" suggests that there are other possibilites. It would be clearer as: Definition: One of "tdm-phy-slic", "tdm-phy-e1", or "tdm-phy-t1". -Scott ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On 14:35-20130110, Matt Porter wrote:
> On Sun, Oct 28, 2012 at 05:01:29PM +0530, Sekhar Nori wrote:
> > On 10/18/2012 6:56 PM, Matt Porter wrote:
> > > Adds AM33XX SPI support for am335x-bone and am335x-evm.
> > >
> > > Signed-off-by: Matt Porter
> > > ---
> > > arch/arm/boot/dts/am335x-bone.dts | 17 +++
> > > arch/arm/boot/dts/am335x-evm.dts |9
> > > arch/arm/boot/dts/am33xx.dtsi | 43
> > > +
> > > 3 files changed, 69 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > > b/arch/arm/boot/dts/am335x-bone.dts
> > > index 5510979..23edfd8 100644
> > > --- a/arch/arm/boot/dts/am335x-bone.dts
> > > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > > @@ -18,6 +18,17 @@
> > > reg = <0x8000 0x1000>; /* 256 MB */
> > > };
> > >
> > > + am3358_pinmux: pinmux@44e10800 {
> > > + spi1_pins: pinmux_spi1_pins {
> > > + pinctrl-single,pins = <
> > > + 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
> > > OUTPUT_PULLUP | MODE3 */
> > > + 0x194 0x33 /* mcasp0_fsx.spi1_d0,
> > > INPUT_PULLUP | MODE3 */
> > > + 0x198 0x13 /* mcasp0_axr0.spi1_d1,
> > > OUTPUT_PULLUP | MODE3 */
minor comment:
doing as a 0x33 is better for both d1, d0 as D0,D1 can be switched between SDI
and SDO
as needed with ti,pindir-d0-out-d1-in
> > > + 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
> > > OUTPUT_PULLUP | MODE3 */
> > > + >;
> >
> > Is there a single pinmux setting that provides SPI functionality on the
> > bone headers? Or this is specific to a cape you tested with?
>
> No, there are two usable settings for spi1 and one setting for spi0.
> I'm dropping this from the series since it's specific to how I wired up
> the homebrew cape I use for spi testing on the Bone. I publish the
> branch where all these extra "test-specific" patches (that aren't intended
> to be merged) are at in the cover letter. Anybody that needs context of
> how/what worked and was tested can grab them there.
Possibly dumb question:
Cant we have pre-usable spi configurations? Like spi1_configuration1_pins,
spi2_configuration1_pins, spi0_configuration1_pins? If documented with
P9 pin names in the bone dts, it saves a bit of effort in looking up
pad offset when dealing with capes.
--
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On Sun, Oct 28, 2012 at 05:01:29PM +0530, Sekhar Nori wrote:
> On 10/18/2012 6:56 PM, Matt Porter wrote:
> > Adds AM33XX SPI support for am335x-bone and am335x-evm.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/am335x-bone.dts | 17 +++
> > arch/arm/boot/dts/am335x-evm.dts |9
> > arch/arm/boot/dts/am33xx.dtsi | 43
> > +
> > 3 files changed, 69 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > b/arch/arm/boot/dts/am335x-bone.dts
> > index 5510979..23edfd8 100644
> > --- a/arch/arm/boot/dts/am335x-bone.dts
> > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > @@ -18,6 +18,17 @@
> > reg = <0x8000 0x1000>; /* 256 MB */
> > };
> >
> > + am3358_pinmux: pinmux@44e10800 {
> > + spi1_pins: pinmux_spi1_pins {
> > + pinctrl-single,pins = <
> > + 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
> > OUTPUT_PULLUP | MODE3 */
> > + 0x194 0x33 /* mcasp0_fsx.spi1_d0,
> > INPUT_PULLUP | MODE3 */
> > + 0x198 0x13 /* mcasp0_axr0.spi1_d1,
> > OUTPUT_PULLUP | MODE3 */
> > + 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
> > OUTPUT_PULLUP | MODE3 */
> > + >;
>
> Is there a single pinmux setting that provides SPI functionality on the
> bone headers? Or this is specific to a cape you tested with?
No, there are two usable settings for spi1 and one setting for spi0.
I'm dropping this from the series since it's specific to how I wired up
the homebrew cape I use for spi testing on the Bone. I publish the
branch where all these extra "test-specific" patches (that aren't intended
to be merged) are at in the cover letter. Anybody that needs context of
how/what worked and was tested can grab them there.
-Matt
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 11/16] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On Mon, Oct 29, 2012 at 01:48:46PM +0530, Sekhar Nori wrote: > On 10/18/2012 6:56 PM, Matt Porter wrote: > > The EDMA DMAC has a hardware limitation that prevents supporting > > scatter gather lists with any number of segments. Since the EDMA > > DMA Engine driver sets the maximum segments to 16, we do the > > same. > > > > TODO: this will be replaced once the DMA Engine API supports an > > API to query the DMAC's segment size limit. > > > > Signed-off-by: Matt Porter > > --- > > drivers/mmc/host/omap_hsmmc.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c > > index b327cd0..52bab01 100644 > > --- a/drivers/mmc/host/omap_hsmmc.c > > +++ b/drivers/mmc/host/omap_hsmmc.c > > @@ -1828,6 +1828,16 @@ static int __devinit omap_hsmmc_probe(struct > > platform_device *pdev) > > * as we want. */ > > mmc->max_segs = 1024; > > > > + /* Eventually we should get our max_segs limitation for EDMA by > > +* querying the dmaengine API */ > > Nit picking: This is not as per multi-line comment style in > Documentation/CodingStyle. Thanks :). This is dropped from v4 anyway, as I now use a call to dma_get_channel_caps() to determine the SG limits. -Matt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 08:03:27PM +0100, Thierry Reding wrote: > > > You'd piece a mapping together, each bus requires 16 64k mappings, a > > > simple 2d array of busnr*16 of pointers would do the trick. A more > > > clever solution would be to allocate contiguous virtual memory and > > > split that up.. > > Oh, I see. I'm not very familiar with the internals of remapping, so > > I'll need to do some more reading. Thanks for the hints. > > I forgot to ask. What's the advantage of having a contiguous virtual > memory area and splitting it up versus remapping each chunk separately? Not alot, really, but it saves you from the pointer array and associated overhead. IIRC it is fairly easy to do in the kernel. Arnd's version is good too, but you would be restricted to aligned powers of two for the bus number range in the DT, which is probably not that big a deal either? Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 08/16] ARM: dts: add AM33XX EDMA support
On Sun, Oct 28, 2012 at 04:46:36PM +0530, Sekhar Nori wrote:
> On 10/18/2012 6:56 PM, Matt Porter wrote:
> > Adds AM33XX EDMA support to the am33xx.dtsi as documented in
> > Documentation/devicetree/bindings/dma/ti-edma.txt
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/am33xx.dtsi | 31 +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index bb31bff..ab9c78f 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -62,6 +62,37 @@
> > reg = <0x4820 0x1000>;
> > };
> >
> > + edma: edma@4900 {
> > + compatible = "ti,edma3";
> > + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > + reg = <0x4900 0x1>,
> > + <0x44e10f90 0x10>;
> > + interrupt-parent = <&intc>;
> > + interrupts = <12 13 14>;
> > + #dma-cells = <1>;
> > + dma-channels = <64>;
> > + ti,edma-regions = <4>;
> > + ti,edma-slots = <256>;
> > + ti,edma-reserved-channels = <0 2
> > +14 2
> > +26 6
> > +48 4
> > +56 8>;
> > + ti,edma-reserved-slots = <0 2
> > + 14 2
> > + 26 6
> > + 48 4
> > + 56 8
> > + 64 127>;
>
> No need to reserve any channels or slots on AM335x, I think. This is
> used on DaVinci devices to share channels with DSP. I am not sure the
> cortex-M3 or PRU on the AM335x need to (or even can) have EDMA access.
I agree. I'm dropping this from the .dtsi in v4 as it is board/application
specific. The PRU, at least, can use the EDMA and I've seen examples as
such, but we can't hardcode this. The feature is there and documented in
the binding if somebody needs to reserve channels in their .dts.
-Matt
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 04/16] ARM: edma: add DT and runtime PM support for AM33XX
On Sun, Oct 28, 2012 at 04:33:39PM +0530, Sekhar Nori wrote:
> On 10/18/2012 6:56 PM, Matt Porter wrote:
> > Adds support for parsing the TI EDMA DT data into the required
> > EDMA private API platform data.
> >
> > Calls runtime PM API only in the DT case in order to unidle the
> > associated hwmods on AM33XX.
>
> Runtime PM is supported on DaVinci now, so if that was the reason for
> this choice, then it doesn't need to be that way.
Thanks, fixed this for v4.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/common/edma.c | 255
> > +--
> > arch/arm/mach-davinci/board-da830-evm.c |4 +-
> > arch/arm/mach-davinci/board-da850-evm.c |8 +-
> > arch/arm/mach-davinci/board-dm646x-evm.c|4 +-
> > arch/arm/mach-davinci/board-omapl138-hawk.c |8 +-
> > arch/arm/mach-davinci/devices-da8xx.c |8 +-
> > arch/arm/mach-davinci/devices-tnetv107x.c |4 +-
> > arch/arm/mach-davinci/dm355.c |4 +-
> > arch/arm/mach-davinci/dm365.c |4 +-
> > arch/arm/mach-davinci/dm644x.c |4 +-
> > arch/arm/mach-davinci/dm646x.c |4 +-
> > include/linux/platform_data/edma.h |8 +-
> > 12 files changed, 272 insertions(+), 43 deletions(-)
> >
> > diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> > index a3d189d..6d2a590 100644
> > --- a/arch/arm/common/edma.c
> > +++ b/arch/arm/common/edma.c
> > @@ -24,6 +24,13 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > #include
> >
> > @@ -1366,31 +1373,237 @@ void edma_clear_event(unsigned channel)
> > EXPORT_SYMBOL(edma_clear_event);
> >
> > /*---*/
> > +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> > +const char *propname, s8 *out_values,
> > +size_t sz)
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
> > +
> > +static int edma_of_read_u32_to_s16_array(const struct device_node *np,
> > +const char *propname, s16 *out_values,
> > +size_t sz)
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
>
> I think these helper functions will have some general use beyond EDMA
> and can be kept in drivers/of/base.c. Grant/Rob need to agree though.
I expect these to go away before too long as I expect to rewrite all of
these data structures when the private edma api code is folded into
drivers/dma/edma.c. When that happens, I would like to use some data
structures that lend themselves to the DT property value. Given that,
let's wait until there is another user to move these helpers to
drivers/of/.
> > diff --git a/arch/arm/mach-davinci/board-da830-evm.c
> > b/arch/arm/mach-davinci/board-da830-evm.c
> > index 95b5e10..ffcbec1 100644
> > --- a/arch/arm/mach-davinci/board-da830-evm.c
> > +++ b/arch/arm/mach-davinci/board-da830-evm.c
> > @@ -512,7 +512,7 @@ static struct davinci_i2c_platform_data
> > da830_evm_i2c_0_pdata = {
> > * example: Timer, GPIO, UART events etc) on da830/omap-l137 EVM, hence
> > * they are being reserved for codecs on the DSP side.
> > */
> > -static const s16 da830_dma_rsv_chans[][2] = {
> > +static s16 da830_dma_rsv_chans[][2] = {
>
> I wonder why you had to remove const here and in other places. You seem
> to be allocating new memory for DT case anyway. Its also not a good idea
> to modify the passed platform data.
Good catch. Although I was never modifying pdata itself, at one point
the DT parsing code was modifying pointers that were const and I removed
the const. I've since fixed that issue since we'd like them to be const
as you point out. As a result, I've removed all these changes from v4 so
all those files aren't touched.
-Matt
___
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 07:55:05PM +0100, Thierry Reding wrote: > On Thu, Jan 10, 2013 at 11:20:07AM -0700, Jason Gunthorpe wrote: > > On Thu, Jan 10, 2013 at 11:25:44AM +0100, Thierry Reding wrote: > > > On Thu, Jan 10, 2013 at 09:17:19AM +, Arnd Bergmann wrote: > > > > On Thursday 10 January 2013, Thierry Reding wrote: > > > > > On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote: > > > > > > On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote: > > > > > > You could decrease the size of the mapping to only span the bus > > > > > > numbers that are configured for use via DT. > > > > > > > > > > That won't work, unfortunately. The mapping is such that the bus > > > > > number > > > > > is not encoded in the uppermost bits, the extended register number is. > > > > > So the only thing that we could do is decrease the size of the > > > > > extended > > > > > register space for *all* devices. > > > > > > > > But you could still a method to map 16 separate areas per bus, each > > > > 65536 > > > > bytes long, which results in 1MB per bus. That is probably ok, since > > > > very few systems have more than a handful of buses in practice. > > > > > > > > In theory, doing static mappings on a per-page base would let you > > > > do 16 devices at a time, but it's probably worth doing at this fine > > > > granularity. > > > > > > I don't understand how this would help. The encoding is like this: > > > > > > [27:24] extended register number > > > [23:16] bus number > > > [15:11] device number > > > [10: 8] function number > > > [ 7: 0] register number > > > > > > So it doesn't matter whether I use separate areas per bus or not. As > > > soon as the whole extended configuration space needs to be accessed a > > > whopping 28 bits (256 MiB) are required. > > > > You'd piece a mapping together, each bus requires 16 64k mappings, a > > simple 2d array of busnr*16 of pointers would do the trick. A more > > clever solution would be to allocate contiguous virtual memory and > > split that up.. > > Oh, I see. I'm not very familiar with the internals of remapping, so > I'll need to do some more reading. Thanks for the hints. I forgot to ask. What's the advantage of having a contiguous virtual memory area and splitting it up versus remapping each chunk separately? Thierry pgpE8dpmOq_to.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 06:26:55PM +, Arnd Bergmann wrote:
> On Thursday 10 January 2013, Thierry Reding wrote:
> > I don't understand how this would help. The encoding is like this:
> >
> > [27:24] extended register number
> > [23:16] bus number
> > [15:11] device number
> > [10: 8] function number
> > [ 7: 0] register number
> >
> > So it doesn't matter whether I use separate areas per bus or not. As
> > soon as the whole extended configuration space needs to be accessed a
> > whopping 28 bits (256 MiB) are required.
> >
> > What you propose would work if only regular configuration space is
> > supported. I'm not sure if that's an option.
>
> I mean something like:
>
> struct tegra_bus_private {
> ...
> void __iomem *config_space[16];
> };
>
>
> void tegra_scan_bus(struct pci_bus *bus)
> {
> int i;
> struct tegra_bus_private *priv = bus->dev->private;
>
> for (i=0; i<16; i++)
> priv->config_space[i] = ioremap(config_space_phys +
>65536 * bus->primary + i * SZ_1M, 65536);
>
> ...
> }
Okay, I see. It's a bit kludgy, but I guess so was the I/O map cache.
It'll take some more time to work this out and test, but I'll give it
a shot.
Thierry
pgpU0Hy7sWZil.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 11:20:07AM -0700, Jason Gunthorpe wrote: > On Thu, Jan 10, 2013 at 11:25:44AM +0100, Thierry Reding wrote: > > On Thu, Jan 10, 2013 at 09:17:19AM +, Arnd Bergmann wrote: > > > On Thursday 10 January 2013, Thierry Reding wrote: > > > > On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote: > > > > > On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote: > > > > > You could decrease the size of the mapping to only span the bus > > > > > numbers that are configured for use via DT. > > > > > > > > That won't work, unfortunately. The mapping is such that the bus number > > > > is not encoded in the uppermost bits, the extended register number is. > > > > So the only thing that we could do is decrease the size of the extended > > > > register space for *all* devices. > > > > > > But you could still a method to map 16 separate areas per bus, each 65536 > > > bytes long, which results in 1MB per bus. That is probably ok, since > > > very few systems have more than a handful of buses in practice. > > > > > > In theory, doing static mappings on a per-page base would let you > > > do 16 devices at a time, but it's probably worth doing at this fine > > > granularity. > > > > I don't understand how this would help. The encoding is like this: > > > > [27:24] extended register number > > [23:16] bus number > > [15:11] device number > > [10: 8] function number > > [ 7: 0] register number > > > > So it doesn't matter whether I use separate areas per bus or not. As > > soon as the whole extended configuration space needs to be accessed a > > whopping 28 bits (256 MiB) are required. > > You'd piece a mapping together, each bus requires 16 64k mappings, a > simple 2d array of busnr*16 of pointers would do the trick. A more > clever solution would be to allocate contiguous virtual memory and > split that up.. Oh, I see. I'm not very familiar with the internals of remapping, so I'll need to do some more reading. Thanks for the hints. > > > Actually, AER probably needs this, and I believe some broken devices > > > need to mask interrupts using the PCI command word in the config space, > > > it it can happen. > > > > Ugh... that would kill any such dynamic mapping approach. Perhaps if we > > could mark a device as requiring a static mapping we could pin that > > cache entry. But that doesn't sound very encouraging. > > AER applies to pretty much every PCI-E device these days. So given there's no way around a segmented static mapping as you suggested, right? Thierry pgpPPQKi7BiVK.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: omap: Add omap-usb2 dt data
* Felipe Balbi [130110 04:49]: > On Thu, Jan 10, 2013 at 03:46:55PM +0530, kishon wrote: > > On Thursday 10 January 2013 03:34 PM, Benoit Cousson wrote: > > > > > >Rob and I did not agree to use that temp hack in the case of DT, so you > > >were supposed to repost with a proper driver for the SCM part that > > >control the USB. > > > > Ok. Missed that. Will work on that. > > Didn't Tony say we should access SCM directly since it's a one time > thing ? > > Tony ? The SCM parts should be a separate driver that eventually will be a child of the minimal SCM core driver. The reason why it should be separate is because the SCM registers are in a different block as pointed out by Paul. There's a good chance that we'll be able to eventually handle the USB SCM registers directly via pinctrl-single.c using pinconf-bits + generic pinconf binding. That is pending the changes from Haojian to implement generic pinconf for pinctrl-single.c. As the USB SCM registers can get quite complex, I suggest creating a minimal driver to handle that, and then eventually that driver might just use the generic pinconf API for setting the SCM registers for things like bias voltage, pulls and comparators. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thursday 10 January 2013, Thierry Reding wrote:
> I don't understand how this would help. The encoding is like this:
>
> [27:24] extended register number
> [23:16] bus number
> [15:11] device number
> [10: 8] function number
> [ 7: 0] register number
>
> So it doesn't matter whether I use separate areas per bus or not. As
> soon as the whole extended configuration space needs to be accessed a
> whopping 28 bits (256 MiB) are required.
>
> What you propose would work if only regular configuration space is
> supported. I'm not sure if that's an option.
I mean something like:
struct tegra_bus_private {
...
void __iomem *config_space[16];
};
void tegra_scan_bus(struct pci_bus *bus)
{
int i;
struct tegra_bus_private *priv = bus->dev->private;
for (i=0; i<16; i++)
priv->config_space[i] = ioremap(config_space_phys +
65536 * bus->primary + i * SZ_1M, 65536);
...
}
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[REPOST PATCH v3 1/4] mmc: dw_mmc: Add "disable-wp" device tree property
The "disable-wp" property is used to specify that a given SD card slot
doesn't have a concept of write protect. This eliminates the need for
special case code for SD slots that should never be write protected
(like a micro SD slot or a dev board).
The dw_mmc driver is special in needing to specify "disable-wp"
because the lack of a "wp-gpios" property means to use the special
purpose write protect line. On some other mmc devices the lack of
"wp-gpios" means that write protect should be disabled.
Signed-off-by: Doug Anderson
Acked-by: Seungwon Jeon
---
Changes in v3:
- New for this version of the patch series. Chose "disable-wp" rather
than the discussed "broken-internal-wp" since it mapped more cleanly
to an existing quirk (and the only reason to specify that the
internal wp is broken is if you're disabling the write protect
anyway).
- Reposted series 3 with Seungwon's ack, since it hasn't been picked
up by anyone.
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 12 +-
drivers/mmc/host/dw_mmc.c | 36 +++-
include/linux/mmc/dw_mmc.h |4 ++
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08..726fd21 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,8 +26,16 @@ Required Properties:
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
- gpio specifier depends on the gpio controller. If the write-protect
- line is not available, this property is optional.
+ gpio specifier depends on the gpio controller. If a GPIO is not used
+ for write-protect, this property is optional.
+
+ * disable-wp: If the wp-gpios property isn't present then (by default)
+ we'd assume that the write protect is hooked up directly to the
+ controller's special purpose write protect line (accessible via
+ the WRTPRT register). However, it's possible that we simply don't
+ want write protect. In that case specify 'disable-wp'.
+ NOTE: This property is not required for slots known to always
+ connect to eMMC or SDIO cards.
Optional properties:
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 323c502..bc0b030 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -74,6 +74,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +89,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int quirks;
+
u32 ctype;
struct mmc_request *mrq;
@@ -825,7 +828,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
struct dw_mci_board *brd = slot->host->pdata;
/* Use platform get_ro function, else try on board write protect */
- if (brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT)
+ if ((brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT) ||
+ (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (brd->get_ro)
read_only = brd->get_ro(slot->id);
@@ -1785,6 +1789,30 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
return NULL;
}
+static struct dw_mci_of_slot_quirks {
+ char *quirk;
+ int id;
+} of_slot_quirks[] = {
+ {
+ .quirk = "disable-wp",
+ .id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ },
+};
+
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int quirks = 0;
+ int idx;
+
+ /* get quirks */
+ for (idx = 0; idx < ARRAY_SIZE(of_slot_quirks); idx++)
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ quirks |= of_slot_quirks[idx].id;
+
+ return quirks;
+}
+
/* find out bus-width for a given slot */
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
@@ -1800,6 +1828,10 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8
slot)
return bus_wd;
}
#else /* CONFIG_OF */
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ return 0;
+}
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
return 1;
@@ -1828,6 +1860,8 @@ static int dw_mci_init_slot(s
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 11:25:44AM +0100, Thierry Reding wrote: > On Thu, Jan 10, 2013 at 09:17:19AM +, Arnd Bergmann wrote: > > On Thursday 10 January 2013, Thierry Reding wrote: > > > On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote: > > > > On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote: > > > > You could decrease the size of the mapping to only span the bus > > > > numbers that are configured for use via DT. > > > > > > That won't work, unfortunately. The mapping is such that the bus number > > > is not encoded in the uppermost bits, the extended register number is. > > > So the only thing that we could do is decrease the size of the extended > > > register space for *all* devices. > > > > But you could still a method to map 16 separate areas per bus, each 65536 > > bytes long, which results in 1MB per bus. That is probably ok, since > > very few systems have more than a handful of buses in practice. > > > > In theory, doing static mappings on a per-page base would let you > > do 16 devices at a time, but it's probably worth doing at this fine > > granularity. > > I don't understand how this would help. The encoding is like this: > > [27:24] extended register number > [23:16] bus number > [15:11] device number > [10: 8] function number > [ 7: 0] register number > > So it doesn't matter whether I use separate areas per bus or not. As > soon as the whole extended configuration space needs to be accessed a > whopping 28 bits (256 MiB) are required. You'd piece a mapping together, each bus requires 16 64k mappings, a simple 2d array of busnr*16 of pointers would do the trick. A more clever solution would be to allocate contiguous virtual memory and split that up.. > > Actually, AER probably needs this, and I believe some broken devices > > need to mask interrupts using the PCI command word in the config space, > > it it can happen. > > Ugh... that would kill any such dynamic mapping approach. Perhaps if we > could mark a device as requiring a static mapping we could pin that > cache entry. But that doesn't sound very encouraging. AER applies to pretty much every PCI-E device these days. Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/5] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to system reset controller
On 01/10/2013 06:51 AM, Philipp Zabel wrote: > Hi Stephen, > > Am Mittwoch, den 09.01.2013, 11:15 -0700 schrieb Stephen Warren: >> On 01/09/2013 10:17 AM, Philipp Zabel wrote: >>> Signed-off-by: Philipp Zabel >>> --- >>> .../devicetree/bindings/reset/fsl,imx-src.txt | 45 >>> >> >> I proposed something very similar a while back; it may be useful to look >> at the previous discussion there: >> >> http://www.spinics.net/lists/arm-kernel/msg202451.html > > Thanks, I had started playing around with some "reset subsystem" > patches, but so far shied away from what feels like a whole lot of code > for little effect. I came to the same conclusion that replacing gpio > resets would probably be overkill, but I was only peripherally aware of > the tegra reset controller. > So a simple common struct and some oftree parsing code in drivers/reset > that can replace both the proposed imx patch and what > tegra_periph_reset_* do would be considered useful? Yes, I didn't really imagine the "reset subsystem" would do more than parsing the DT property that represented the reset and look up the registered reset controller and reset ID. Plus, provide some central function to pass the parsed reset ID to the reset controller driver. Of course, if it expanded to cover non-DT cases it might get more complex, but that can always be added later. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 0/4] input: keyboard: tegra: cleanups and DT supports
Hi Laxman, On Thu, Jan 10, 2013 at 12:01:23PM +0530, Laxman Dewangan wrote: > Hi Dmitry, > > On Monday 07 January 2013 10:22 PM, Stephen Warren wrote: > >On 01/06/2013 04:14 AM, Laxman Dewangan wrote: > >>This patch series: > >> - fix build warning, > >> - use devm_* for allocation, > >> - make column/rows configuration through DT and > >> - remove the rarely used key mapping table. > >The series, > >Reviewed-by: Stephen Warren > > > > If you are fine with this series then can it be apply please? I can > handle if there is any comment on this series to close this. > The patches are applied with minor edits to the 3rd and 4th (there was no point in having a separate keymap setup function anymore). Thanks. -- Dmitry ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On 01/10/2013 05:48 AM, Lorenzo Pieralisi wrote:
> Since the introduction of /cpu nodes bindings for ARM and the
> corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
> and the number of possible CPUs are set according to the DT /cpu
> nodes entries. Currently most of the existing ARM SMP platforms detect the
> number of cores through HW probing in their .smp_init_cpus functions and set
> the possible CPU mask accordingly.
> This method should be upgraded so that the CPU counting mechanism will be
> based on DT, keeping legacy HW probing mechanism as a fall back solution.
>
> In order to implement this fall back solution mechanism, the ARM DT code
> should provide a helper function to platforms to check if the cpu map
> has been properly initialized through DT. If the check fails the
> platform will resort to legacy HW based cores counting mechanism.
>
> This patch implements a trivial flag and a helper function that platform
> can call to check whether DT based cpu map initialization and cores count
> were completed successfully.
>
> Signed-off-by: Lorenzo Pieralisi
> ---
> arch/arm/include/asm/prom.h | 10 ++
> arch/arm/kernel/devtree.c | 5 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> index a219227..487614a 100644
> --- a/arch/arm/include/asm/prom.h
> +++ b/arch/arm/include/asm/prom.h
> @@ -18,6 +18,15 @@
> extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> extern void arm_dt_memblock_reserve(void);
> extern void __init arm_dt_init_cpu_maps(void);
> +/*
> + * Return true if cpu map initialization has been
> + * carried out correctly from DT
> + */
> +static inline bool __init arm_dt_cpu_map_valid(void)
> +{
> + extern bool valid_dt_cpu_map;
> + return valid_dt_cpu_map;
> +}
>
> #else /* CONFIG_OF */
>
> @@ -28,6 +37,7 @@ static inline struct machine_desc
> *setup_machine_fdt(unsigned int dt_phys)
>
> static inline void arm_dt_memblock_reserve(void) { }
> static inline void arm_dt_init_cpu_maps(void) { }
> +static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
>
> #endif /* CONFIG_OF */
> #endif /* ASMARM_PROM_H */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 70f1bde..c82af3b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -62,6 +62,10 @@ void __init arm_dt_memblock_reserve(void)
> memblock_reserve(base, size);
> }
> }
> +/*
> + * Export DT cpu map validity flag to platforms
> + */
> +bool valid_dt_cpu_map __initdata;
>
> /*
> * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
> @@ -158,6 +162,7 @@ void __init arm_dt_init_cpu_maps(void)
>* a reg property, the DT CPU list can be considered valid and the
>* logical map created in smp_setup_processor_id() can be overridden
>*/
> + valid_dt_cpu_map = true;
> for (i = 0; i < cpuidx; i++) {
> set_cpu_possible(i, true);
I don't see why we need another variable. Doesn't cpu_possible mask
being set here imply that the DT map is valid.
We should start requiring valid /cpus nodes and the legacy fall-back
should be temporary.
Rob
> cpu_logical_map(i) = tmp_map[i];
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On Thu, 10 Jan 2013, Lorenzo Pieralisi wrote:
> On Thu, Jan 10, 2013 at 12:15:14PM +, Dave Martin wrote:
> > On Thu, Jan 10, 2013 at 11:48:27AM +, Lorenzo Pieralisi wrote:
> > > Since the introduction of /cpu nodes bindings for ARM and the
> > > corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
> > > and the number of possible CPUs are set according to the DT /cpu
> > > nodes entries. Currently most of the existing ARM SMP platforms detect the
> > > number of cores through HW probing in their .smp_init_cpus functions and
> > > set
> > > the possible CPU mask accordingly.
> > > This method should be upgraded so that the CPU counting mechanism will be
> > > based on DT, keeping legacy HW probing mechanism as a fall back solution.
> > >
> > > In order to implement this fall back solution mechanism, the ARM DT code
> > > should provide a helper function to platforms to check if the cpu map
> > > has been properly initialized through DT. If the check fails the
> > > platform will resort to legacy HW based cores counting mechanism.
> > >
> > > This patch implements a trivial flag and a helper function that platform
> > > can call to check whether DT based cpu map initialization and cores count
> > > were completed successfully.
> > >
> > > Signed-off-by: Lorenzo Pieralisi
> > > ---
> > > arch/arm/include/asm/prom.h | 10 ++
> > > arch/arm/kernel/devtree.c | 5 +
> > > 2 files changed, 15 insertions(+)
> > >
> > > diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> > > index a219227..487614a 100644
> > > --- a/arch/arm/include/asm/prom.h
> > > +++ b/arch/arm/include/asm/prom.h
> > > @@ -18,6 +18,15 @@
> > > extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> > > extern void arm_dt_memblock_reserve(void);
> > > extern void __init arm_dt_init_cpu_maps(void);
> > > +/*
> > > + * Return true if cpu map initialization has been
> > > + * carried out correctly from DT
> > > + */
> > > +static inline bool __init arm_dt_cpu_map_valid(void)
> > > +{
> > > + extern bool valid_dt_cpu_map;
> > > + return valid_dt_cpu_map;
> > > +}
> > >
> > > #else /* CONFIG_OF */
> > >
> > > @@ -28,6 +37,7 @@ static inline struct machine_desc
> > > *setup_machine_fdt(unsigned int dt_phys)
> > >
> > > static inline void arm_dt_memblock_reserve(void) { }
> > > static inline void arm_dt_init_cpu_maps(void) { }
> > > +static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
> > >
> > > #endif /* CONFIG_OF */
> > > #endif /* ASMARM_PROM_H */
> > > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > > index 70f1bde..c82af3b 100644
> > > --- a/arch/arm/kernel/devtree.c
> > > +++ b/arch/arm/kernel/devtree.c
> > > @@ -62,6 +62,10 @@ void __init arm_dt_memblock_reserve(void)
> > > memblock_reserve(base, size);
> > > }
> > > }
> > > +/*
> > > + * Export DT cpu map validity flag to platforms
> > > + */
> > > +bool valid_dt_cpu_map __initdata;
> >
> > Is there any possibility of this being useful after boot?
> > Hopefully not, but maybe there's something I haven't considered.
>
> I do not think so, at least for the use cases I have envisaged at the moment,
> but it is certainly something I should consider.
Let's simply adjust the code in the future if that ever becomes the
case.
Nicolas
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RFC: Static memory controller node description
Hi guys,
we want to add static memory controller driver for xilinx zynq to the
linux kernel. (It will go to drivers/memory/ folder)
Just need to clear dts fragment which describe it.
It is compatible with pl353 with 2 interfaces when only one interface
can be used.
Nand, nor and sram memories are supported. Driver will do additional
setup for NAND and power management.
I am using extended compatible property based on
Documentation/devicetree/bindings/arm/primecell.txt. Is it correct?
Nand case (we have special driver for nand) - interrupts are used only
in connection with nand.
smc@0xe000e000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,ps7-smc", "arm,pl353", "arm,primecell";
reg = <0xe000e000 0x1000>;
interrupts = <0 18 4>;
interrupt-parent = <&ps7_scugic_0>;
ranges;
nand@e100 {
compatible = "xlnx,ps7-nand-1.00.a";
reg = <0xe100 0x100>;
xlnx,nand-width = <16>;
}
}
or this one for NOR
smc@0xe000e000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,ps7-smc", "arm,pl353", "arm,primecell";
reg = <0xe000e000 0x1000>;
ranges;
nor: nor@e200 {
compatible = "cfi-flash";
reg = <0xE200 0x200>;
bank-width = <1>;
}
}
Can you see any problem with these dts fragments?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 24/44] metag: Internal and external irqchips
Meta core internal interrupts (from HWSTATMETA and friends) are vectored
onto the TR1 core trigger for the current thread. This is demultiplexed
in irq-meta.c to individual Linux IRQs for each internal interrupt.
External SoC interrupts (from HWSTATEXT and friends) are vectored onto
the TR2 core trigger for the current thread. This is demultiplexed in
irq-meta-ext.c to individual Linux IRQs for each external SoC interrupt.
The external irqchip has devicetree bindings for configuring the number
of irq banks and the type of masking available.
Signed-off-by: James Hogan
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Dom Cobley
Cc: Simon Arlott
Cc: Viresh Kumar
Cc: Maxime Ripard
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
.../devicetree/bindings/metag/meta-intc.txt| 82 ++
arch/metag/kernel/irq.c|5 +
drivers/irqchip/Makefile |2 +
drivers/irqchip/irq-meta-ext.c | 868
drivers/irqchip/irq-meta.c | 343
include/linux/irqchip/meta-ext.h | 33 +
include/linux/irqchip/meta.h | 24 +
7 files changed, 1357 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/metag/meta-intc.txt
create mode 100644 drivers/irqchip/irq-meta-ext.c
create mode 100644 drivers/irqchip/irq-meta.c
create mode 100644 include/linux/irqchip/meta-ext.h
create mode 100644 include/linux/irqchip/meta.h
diff --git a/Documentation/devicetree/bindings/metag/meta-intc.txt
b/Documentation/devicetree/bindings/metag/meta-intc.txt
new file mode 100644
index 000..8c47dcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/metag/meta-intc.txt
@@ -0,0 +1,82 @@
+* Meta External Trigger Controller Binding
+
+This binding specifies what properties must be available in the device tree
+representation of a Meta external trigger controller.
+
+Required properties:
+
+- compatible: Specifies the compatibility list for the interrupt
controller.
+ The type shall be and the value shall include "img,meta-intc".
+
+- num-banks: Specifies the number of interrupt banks (each of which can
+ handle 32 interrupt sources).
+
+- interrupt-controller: The presence of this property identifies the node
+ as an interupt controller. No property value shall be defined.
+
+- #interrupt-cells: Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a and the value shall be 2.
+
+- #address-cells: Specifies the number of cells needed to encode an
+ address. The type shall be and the value shall be 0. As such,
+ 'interrupt-map' nodes do not have to specify a parent unit address.
+
+Optional properties:
+
+- no-mask: The controller doesn't have any mask registers.
+
+* Interrupt Specifier Definition
+
+ Interrupt specifiers consists of 2 cells encoded as follows:
+
+- <1st-cell>: The interrupt-number that identifies the interrupt source.
+
+- <2nd-cell>: The Linux interrupt flags containing level-sense information,
+ encoded as follows:
+1 = edge triggered
+4 = level-sensitive
+
+* Examples
+
+Example 1:
+
+ /*
+* Meta external trigger block
+*/
+ intc: intc {
+ // This is an interrupt controller node.
+ interrupt-controller;
+
+ // No address cells so that 'interrupt-map' nodes which
+ // reference this interrupt controller node do not need a parent
+ // address specifier.
+ #address-cells = <0>;
+
+ // Two cells to encode interrupt sources.
+ #interrupt-cells = <2>;
+
+ // Number of interrupt banks
+ num-banks = <2>;
+
+ // No HWMASKEXT is available (specify on Chorus2 and Comet ES1)
+ no-mask;
+
+ // Compatible with Meta hardware trigger block.
+ compatible = "img,meta-intc";
+ };
+
+Example 2:
+
+ /*
+* An interrupt generating device that is wired to a Meta external
+* trigger block.
+*/
+ uart1: uart@0x02004c00 {
+ // Interrupt source '5' that is level-sensitive.
+ // Note that there are only two cells as specified in the
+ // interrupt parent's '#interrupt-cells' property.
+ interrupts = <5 4 /* level */>;
+
+ // The interrupt controller that this device is wired to.
+ interrupt-parent = <&intc>;
+ };
diff --git a/arch/metag/kernel/irq.c b/arch/metag/kernel/irq.c
index 769bd74..f8d1291 100644
--- a/arch/metag/kernel/irq.c
+++ b/arch/metag/kernel/irq.c
@@ -6,6 +6,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -257,6 +259,9 @@ void __init init_IRQ(
Re: [RFC PATCH 0/5] Use SRC to reset IP modules on i.MX5 and i.MX6
Am Mittwoch, den 09.01.2013, 15:57 -0200 schrieb Fabio Estevam: > On Wed, Jan 9, 2013 at 3:53 PM, Fabio Estevam wrote: > > On Wed, Jan 9, 2013 at 3:40 PM, Philipp Zabel > > wrote: > > > >> I rebased them onto next-20130109 (with this base compile-tested only). > > > > Just tested it, but unfortunately I still get the crash. > > Ok, since I am on mx51 I just added a: > > diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi > index 1f5d45e..8380b14 100644 > --- a/arch/arm/boot/dts/imx51.dtsi > +++ b/arch/arm/boot/dts/imx51.dtsi > @@ -67,6 +67,7 @@ > compatible = "fsl,imx51-ipu"; > reg = <0x4000 0x2000>; > interrupts = <11 10>; > + reset = <&src 2>; > }; > > and now it works fine. Thanks, sorry for missing the essential part for i.MX51. So it seems hooking up the SRC to a common peripheral device reset call is the way to go. regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/5] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to system reset controller
Am Donnerstag, den 10.01.2013, 14:56 +0800 schrieb Shawn Guo: > Hi Philipp, > > On Wed, Jan 09, 2013 at 06:17:15PM +0100, Philipp Zabel wrote: > > Signed-off-by: Philipp Zabel > > --- > > .../devicetree/bindings/reset/fsl,imx-src.txt | 45 > > > > arch/arm/mach-imx/src.c| 41 > > ++ > > include/linux/imx-src.h|6 +++ > > 3 files changed, 92 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/reset/fsl,imx-src.txt > > create mode 100644 include/linux/imx-src.h > > I'm with Stephen that we should try to create a common API for this. > Instead of ask device drivers to call IMX specific imx_src_reset(), > we should have them call some type of common API with struct device > as the argument. Agreed. At least for devices with a single dedicated reset line this would be a much better API. regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/5] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to system reset controller
Hi Stephen, Am Mittwoch, den 09.01.2013, 11:15 -0700 schrieb Stephen Warren: > On 01/09/2013 10:17 AM, Philipp Zabel wrote: > > Signed-off-by: Philipp Zabel > > --- > > .../devicetree/bindings/reset/fsl,imx-src.txt | 45 > > > > I proposed something very similar a while back; it may be useful to look > at the previous discussion there: > > http://www.spinics.net/lists/arm-kernel/msg202451.html Thanks, I had started playing around with some "reset subsystem" patches, but so far shied away from what feels like a whole lot of code for little effect. I came to the same conclusion that replacing gpio resets would probably be overkill, but I was only peripherally aware of the tegra reset controller. So a simple common struct and some oftree parsing code in drivers/reset that can replace both the proposed imx patch and what tegra_periph_reset_* do would be considered useful? > Unfortunately, I haven't had time to follow up on the proposal. regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
PMU node location
Hi Rob, Mark, Grant and others, I want to check with you the location of ARM pmu node I see that 1) highbank and dbx5x0 have it in soc node 2) vexpress and tegra have no main bus and pmu is in root like all others devices. (Any reason no to have main bus? Does it mean that there is no bus or that all devices are accessible?) 3) omap2/omap3 have added pmu node to root node(mailing list) 4) Just for completeness no platform has it in the bus. That's why I have obvious question what it is proper location for pmu node? Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mfd: stmpe: Pull IRQ GPIO number from DT during DT-based probe
On Thu, 10 Jan 2013, Linus Walleij wrote:
> On Tue, Jan 8, 2013 at 12:14 PM, Viresh Kumar wrote:
> > On 8 January 2013 16:41, Lee Jones wrote:
> >>> Hmm.. I tried a bit, but couldn't find any such call :(
> >>> Probably an assumption is taken here. GPIO pins which are going to be
> >>> used as
> >>> interrupt lines, wouldn't be getting set in output mode at all. So,
> >>> once they are put
> >>> in input mode in beginning, nobody would change it ever.
> >>>
> >>> Much of gpio controllers configure gpio pins in input mode in their
> >>> probe().
> >>>
> >>> Maybe, there is something else :)
> >>
> >> Pinctrl?
> >
> > I don't think pinctrl is playing with it. I searched for
> > "direction_input" string and
> > pinctrl routine also had similar name. I couldn't fine use of
> > direction_input anywhere
> > in kernel, for setting them as irqs for OF cases.
>
> pinctrl has pinctrl_gpio_direction_input() and
> pinctrl_gpio_direction_output() which are supposed to
> be called *only* by GPIOlib frontends using pinctrl
> as backend to control the pins.
>
> But if it's a pinctrl driver using standard pinconfig from
> include/linux/pinctrl/pinconf-generic.h
> I'm all for adding a PIN_CONFIG_INPUT_ENABLE
> to these definintions so it can be set up as input
> at boot from the device tree using hogs or something,
> that make things easy when using GPIOs as IRQ
> providers only.
>
> So the alternative is to just set up the IRQ using the
> gpiolib functions for this: of_get_gpio() if you need the
> number from DT, then gpio_request() and
> gpio_direction_input() as on any GPIO. This can be
> done in the device driver or board code depending
> on use case.
>
> In the Nomadik I did this (maybe ugly) hack for a
> similar case:
>
> +/*
> + * The SMSC911x IRQ is connected to a GPIO pin, but the driver expects
> + * to simply request an IRQ passed as a resource. So the GPIO pin needs
> + * to be requested by this hog and set as input.
> + */
> +static int __init cpu8815_eth_init(void)
> +{
> + struct device_node *eth;
> + int gpio, irq, err;
> +
> + eth = of_find_node_by_path("/external-bus@3400/ethernet@300");
> + if (!eth) {
> + pr_info("could not find any ethernet controller\n");
> + return 0;
> + }
> + gpio = of_get_gpio(eth, 0);
> + err = gpio_request(gpio, "eth_irq");
> + if (err) {
> + pr_info("failed to request ethernet GPIO\n");
> + return -ENODEV;
> + }
> + err = gpio_direction_input(gpio);
> + if (err) {
> + pr_info("failed to set ehernet GPIO as input\n");
> + return -ENODEV;
> + }
> + irq = gpio_to_irq(gpio);
> + pr_info("enabled ethernet GPIO %d, IRQ %d\n", gpio, irq);
> + return 0;
> +}
> +device_initcall(cpu8815_eth_init);
Yep, that looks pretty gross!
> I haven't read review comments on that patch.
>
> Maybe it's not such a good idea to add the GPIO to the device itself
> when it's being hogged by board code like this. It's a bit of a grey area
> so I'm a bit confused here.
>
> Maybe the GPIO lib actually needs a "hog" mechanism that can
> request and set GPIO pins as input/output on boot and then
> forget about them.
>
> Yours,
> Linus Walleij
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: omap: Add omap-usb2 dt data
On Thu, Jan 10, 2013 at 03:46:55PM +0530, kishon wrote:
> Hi,
>
> On Thursday 10 January 2013 03:34 PM, Benoit Cousson wrote:
> >On 01/10/2013 10:31 AM, kishon wrote:
> >>Hi Benoit,
> >>
> >>On Wednesday 19 September 2012 04:02 PM, Kishon Vijay Abraham I wrote:
> >>>Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
> >>>connected to ocp2scp, omap-usb2 dt data is added as a child node
> >>>of ocp2scp.
> >>>
> >>>Acked-by: Felipe Balbi
> >>>Signed-off-by: Kishon Vijay Abraham I
> >>
> >>This patch is also missing in mainline :-(
> >
> >Well, in that case this was done on purpose :-)
> >
> >>
> >>Thanks
> >>Kishon
> >>
> >>>---
> >>> arch/arm/boot/dts/omap4.dtsi |5 +
> >>> 1 file changed, 5 insertions(+)
> >>>
> >>>diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> >>>index 4fbb9dc..28eaddc 100644
> >>>--- a/arch/arm/boot/dts/omap4.dtsi
> >>>+++ b/arch/arm/boot/dts/omap4.dtsi
> >>>@@ -303,6 +303,11 @@
> >>> #size-cells = <1>;
> >>> ranges;
> >>> ti,hwmods = "ocp2scp_usb_phy";
> >>>+usb2phy@4a0ad080 {
> >>>+compatible = "ti,omap-usb2";
> >>>+reg = <0x4a0ad080 0x58>,
> >>>+ <0x4a002300 0x4>; /* TO BE REMOVED: SCM */
> >
> >Rob and I did not agree to use that temp hack in the case of DT, so you
> >were supposed to repost with a proper driver for the SCM part that
> >control the USB.
>
> Ok. Missed that. Will work on that.
Didn't Tony say we should access SCM directly since it's a one time
thing ?
Tony ?
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On Thu, Jan 10, 2013 at 12:15:14PM +, Dave Martin wrote:
> On Thu, Jan 10, 2013 at 11:48:27AM +, Lorenzo Pieralisi wrote:
> > Since the introduction of /cpu nodes bindings for ARM and the
> > corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
> > and the number of possible CPUs are set according to the DT /cpu
> > nodes entries. Currently most of the existing ARM SMP platforms detect the
> > number of cores through HW probing in their .smp_init_cpus functions and set
> > the possible CPU mask accordingly.
> > This method should be upgraded so that the CPU counting mechanism will be
> > based on DT, keeping legacy HW probing mechanism as a fall back solution.
> >
> > In order to implement this fall back solution mechanism, the ARM DT code
> > should provide a helper function to platforms to check if the cpu map
> > has been properly initialized through DT. If the check fails the
> > platform will resort to legacy HW based cores counting mechanism.
> >
> > This patch implements a trivial flag and a helper function that platform
> > can call to check whether DT based cpu map initialization and cores count
> > were completed successfully.
> >
> > Signed-off-by: Lorenzo Pieralisi
> > ---
> > arch/arm/include/asm/prom.h | 10 ++
> > arch/arm/kernel/devtree.c | 5 +
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> > index a219227..487614a 100644
> > --- a/arch/arm/include/asm/prom.h
> > +++ b/arch/arm/include/asm/prom.h
> > @@ -18,6 +18,15 @@
> > extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> > extern void arm_dt_memblock_reserve(void);
> > extern void __init arm_dt_init_cpu_maps(void);
> > +/*
> > + * Return true if cpu map initialization has been
> > + * carried out correctly from DT
> > + */
> > +static inline bool __init arm_dt_cpu_map_valid(void)
> > +{
> > + extern bool valid_dt_cpu_map;
> > + return valid_dt_cpu_map;
> > +}
> >
> > #else /* CONFIG_OF */
> >
> > @@ -28,6 +37,7 @@ static inline struct machine_desc
> > *setup_machine_fdt(unsigned int dt_phys)
> >
> > static inline void arm_dt_memblock_reserve(void) { }
> > static inline void arm_dt_init_cpu_maps(void) { }
> > +static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
> >
> > #endif /* CONFIG_OF */
> > #endif /* ASMARM_PROM_H */
> > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > index 70f1bde..c82af3b 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -62,6 +62,10 @@ void __init arm_dt_memblock_reserve(void)
> > memblock_reserve(base, size);
> > }
> > }
> > +/*
> > + * Export DT cpu map validity flag to platforms
> > + */
> > +bool valid_dt_cpu_map __initdata;
>
> Is there any possibility of this being useful after boot?
> Hopefully not, but maybe there's something I haven't considered.
I do not think so, at least for the use cases I have envisaged at the moment,
but it is certainly something I should consider.
Thanks,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: kernel: DT cpu map validity check helper function
On Thu, Jan 10, 2013 at 11:48:27AM +, Lorenzo Pieralisi wrote:
> Since the introduction of /cpu nodes bindings for ARM and the
> corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
> and the number of possible CPUs are set according to the DT /cpu
> nodes entries. Currently most of the existing ARM SMP platforms detect the
> number of cores through HW probing in their .smp_init_cpus functions and set
> the possible CPU mask accordingly.
> This method should be upgraded so that the CPU counting mechanism will be
> based on DT, keeping legacy HW probing mechanism as a fall back solution.
>
> In order to implement this fall back solution mechanism, the ARM DT code
> should provide a helper function to platforms to check if the cpu map
> has been properly initialized through DT. If the check fails the
> platform will resort to legacy HW based cores counting mechanism.
>
> This patch implements a trivial flag and a helper function that platform
> can call to check whether DT based cpu map initialization and cores count
> were completed successfully.
>
> Signed-off-by: Lorenzo Pieralisi
> ---
> arch/arm/include/asm/prom.h | 10 ++
> arch/arm/kernel/devtree.c | 5 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> index a219227..487614a 100644
> --- a/arch/arm/include/asm/prom.h
> +++ b/arch/arm/include/asm/prom.h
> @@ -18,6 +18,15 @@
> extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> extern void arm_dt_memblock_reserve(void);
> extern void __init arm_dt_init_cpu_maps(void);
> +/*
> + * Return true if cpu map initialization has been
> + * carried out correctly from DT
> + */
> +static inline bool __init arm_dt_cpu_map_valid(void)
> +{
> + extern bool valid_dt_cpu_map;
> + return valid_dt_cpu_map;
> +}
>
> #else /* CONFIG_OF */
>
> @@ -28,6 +37,7 @@ static inline struct machine_desc
> *setup_machine_fdt(unsigned int dt_phys)
>
> static inline void arm_dt_memblock_reserve(void) { }
> static inline void arm_dt_init_cpu_maps(void) { }
> +static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
>
> #endif /* CONFIG_OF */
> #endif /* ASMARM_PROM_H */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 70f1bde..c82af3b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -62,6 +62,10 @@ void __init arm_dt_memblock_reserve(void)
> memblock_reserve(base, size);
> }
> }
> +/*
> + * Export DT cpu map validity flag to platforms
> + */
> +bool valid_dt_cpu_map __initdata;
Is there any possibility of this being useful after boot?
Hopefully not, but maybe there's something I haven't considered.
Cheers
---Dave
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: kernel: DT cpu map validity check helper function
Since the introduction of /cpu nodes bindings for ARM and the
corresponding parse function arm_dt_init_cpu_maps(), the cpu_logical_map
and the number of possible CPUs are set according to the DT /cpu
nodes entries. Currently most of the existing ARM SMP platforms detect the
number of cores through HW probing in their .smp_init_cpus functions and set
the possible CPU mask accordingly.
This method should be upgraded so that the CPU counting mechanism will be
based on DT, keeping legacy HW probing mechanism as a fall back solution.
In order to implement this fall back solution mechanism, the ARM DT code
should provide a helper function to platforms to check if the cpu map
has been properly initialized through DT. If the check fails the
platform will resort to legacy HW based cores counting mechanism.
This patch implements a trivial flag and a helper function that platform
can call to check whether DT based cpu map initialization and cores count
were completed successfully.
Signed-off-by: Lorenzo Pieralisi
---
arch/arm/include/asm/prom.h | 10 ++
arch/arm/kernel/devtree.c | 5 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index a219227..487614a 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -18,6 +18,15 @@
extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+/*
+ * Return true if cpu map initialization has been
+ * carried out correctly from DT
+ */
+static inline bool __init arm_dt_cpu_map_valid(void)
+{
+ extern bool valid_dt_cpu_map;
+ return valid_dt_cpu_map;
+}
#else /* CONFIG_OF */
@@ -28,6 +37,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned
int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline bool __init arm_dt_cpu_map_valid(void) { return false; }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..c82af3b 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -62,6 +62,10 @@ void __init arm_dt_memblock_reserve(void)
memblock_reserve(base, size);
}
}
+/*
+ * Export DT cpu map validity flag to platforms
+ */
+bool valid_dt_cpu_map __initdata;
/*
* arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
@@ -158,6 +162,7 @@ void __init arm_dt_init_cpu_maps(void)
* a reg property, the DT CPU list can be considered valid and the
* logical map created in smp_setup_processor_id() can be overridden
*/
+ valid_dt_cpu_map = true;
for (i = 0; i < cpuidx; i++) {
set_cpu_possible(i, true);
cpu_logical_map(i) = tmp_map[i];
--
1.7.12
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mfd: stmpe: Pull IRQ GPIO number from DT during DT-based probe
On Tue, Jan 8, 2013 at 12:14 PM, Viresh Kumar wrote:
> On 8 January 2013 16:41, Lee Jones wrote:
>>> Hmm.. I tried a bit, but couldn't find any such call :(
>>> Probably an assumption is taken here. GPIO pins which are going to be used
>>> as
>>> interrupt lines, wouldn't be getting set in output mode at all. So,
>>> once they are put
>>> in input mode in beginning, nobody would change it ever.
>>>
>>> Much of gpio controllers configure gpio pins in input mode in their probe().
>>>
>>> Maybe, there is something else :)
>>
>> Pinctrl?
>
> I don't think pinctrl is playing with it. I searched for
> "direction_input" string and
> pinctrl routine also had similar name. I couldn't fine use of
> direction_input anywhere
> in kernel, for setting them as irqs for OF cases.
pinctrl has pinctrl_gpio_direction_input() and
pinctrl_gpio_direction_output() which are supposed to
be called *only* by GPIOlib frontends using pinctrl
as backend to control the pins.
But if it's a pinctrl driver using standard pinconfig from
include/linux/pinctrl/pinconf-generic.h
I'm all for adding a PIN_CONFIG_INPUT_ENABLE
to these definintions so it can be set up as input
at boot from the device tree using hogs or something,
that make things easy when using GPIOs as IRQ
providers only.
So the alternative is to just set up the IRQ using the
gpiolib functions for this: of_get_gpio() if you need the
number from DT, then gpio_request() and
gpio_direction_input() as on any GPIO. This can be
done in the device driver or board code depending
on use case.
In the Nomadik I did this (maybe ugly) hack for a
similar case:
+/*
+ * The SMSC911x IRQ is connected to a GPIO pin, but the driver expects
+ * to simply request an IRQ passed as a resource. So the GPIO pin needs
+ * to be requested by this hog and set as input.
+ */
+static int __init cpu8815_eth_init(void)
+{
+ struct device_node *eth;
+ int gpio, irq, err;
+
+ eth = of_find_node_by_path("/external-bus@3400/ethernet@300");
+ if (!eth) {
+ pr_info("could not find any ethernet controller\n");
+ return 0;
+ }
+ gpio = of_get_gpio(eth, 0);
+ err = gpio_request(gpio, "eth_irq");
+ if (err) {
+ pr_info("failed to request ethernet GPIO\n");
+ return -ENODEV;
+ }
+ err = gpio_direction_input(gpio);
+ if (err) {
+ pr_info("failed to set ehernet GPIO as input\n");
+ return -ENODEV;
+ }
+ irq = gpio_to_irq(gpio);
+ pr_info("enabled ethernet GPIO %d, IRQ %d\n", gpio, irq);
+ return 0;
+}
+device_initcall(cpu8815_eth_init);
I haven't read review comments on that patch.
Maybe it's not such a good idea to add the GPIO to the device itself
when it's being hogged by board code like this. It's a bit of a grey area
so I'm a bit confused here.
Maybe the GPIO lib actually needs a "hog" mechanism that can
request and set GPIO pins as input/output on boot and then
forget about them.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/7] ARM: common: vic: Parse interrupt and resume masks from device tree
On Thu, Jan 10, 2013 at 12:10:38PM +0100, Tomasz Figa wrote: > This is not the runtime interrupt/wakeup mask, but a global mask of > available interrupt/wakeup lines on particular platform, which still have > to be configured and enabled appropriately by user. Ah, OK. Reviewed-by: Mark Brown signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 3/7] ARM: s3c64xx: Add support for OF-based VIC initialization
On Thu, Jan 10, 2013 at 12:41:45AM +0100, Tomasz Figa wrote: > This patch modifies IRQ initialization code of S3C64xx to support > Device Tree-based initialization of VICs. Reviewed-by: Mark Brown signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/7] ARM: common: vic: Parse interrupt and resume masks from device tree
On Thursday 10 of January 2013 11:03:14 Mark Brown wrote: > On Thu, Jan 10, 2013 at 12:41:43AM +0100, Tomasz Figa wrote: > > +- interrupt-mask : Bit mask of valid interrupt sources (defaults to > > all valid) +- wakeup-mask : Bit mask of interrupt sources that can > > wake up the system + (defaults to all allowed) > > Should this really be configured in the VIC itself? It seems like > something that might change at runtime (for example, due to the user > configuring wakes in sysfs). This is not the runtime interrupt/wakeup mask, but a global mask of available interrupt/wakeup lines on particular platform, which still have to be configured and enabled appropriately by user. Best regards, Tomasz Figa ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
On Fri, Jan 4, 2013 at 5:45 PM, Maxime Ripard
wrote:
> The IP responsible for the muxing on the Allwinner SoCs are also
> handling the GPIOs on the system. This patch adds the needed driver that
> relies on the pinctrl driver for most of its operations.
>
> The number of pins available for GPIOs operations are already declared
> in the pinctrl driver, we only need to probe a generic driver to handle
> the banks available for each SoC.
>
> This driver has been tested on a A13-Olinuxino.
>
> Signed-off-by: Maxime Ripard
Looking mostly good!
> +static int __devinit
> +sunxi_pinctrl_register_gpio_ranges(struct sunxi_pinctrl *pctl)
> +{
> + int id = 0, base = 0, npins = 1, i, prev_pin = -1;
> + struct pinctrl_gpio_range *range;
> +
> + for (i = 0; i < pctl->desc->npins; i++) {
> + const struct sunxi_desc_pin *pin = pctl->desc->pins + i;
> + unsigned pin_num = pin->pin.number;
> +
> + if (prev_pin < 0) {
> + prev_pin = pin_num;
> + base = pin_num;
> + } else if (prev_pin + 1 != pin_num) {
> + range = devm_kzalloc(pctl->dev,
> + sizeof(*range),
> + GFP_KERNEL);
> + if (!range)
> + return -ENOMEM;
> +
> + range->name = "sunxi";
> + range->id = id;
> + range->base = base;
> + range->pin_base = base;
> + range->npins = npins;
> +
> + pinctrl_add_gpio_range(pctl->pctl_dev, range);
> +
> + id++;
> + npins = 1;
> + prev_pin = pin_num;
> + base = prev_pin;
> + } else {
> + prev_pin++;
> + npins++;
> + }
> + }
> +
> + range = devm_kzalloc(pctl->dev, sizeof(*range),
> + GFP_KERNEL);
> + if (!range)
> + return -ENOMEM;
> +
> + range->name = "sunxi";
> + range->id = id;
> + range->base = base;
> + range->pin_base = base;
> + range->npins = npins;
> +
> + pinctrl_add_gpio_range(pctl->pctl_dev, range);
> +
> + return 0;
> +}
Really hairy way to add ranges right?
Registering ranges from the pinctrl side is deprecated and discouraged.
Instead register the ranges from the GPIO driver.
Use gpiochip_add_pin_range() from the GPIO driver.
An example is provided in
drivers/pinctrl/pinctrl-coh901.c
After you have done this, you can probably get rid of this as well:
+static int __init sunxi_gpio_init(void)
+{
+ return platform_driver_register(&sunxi_gpio_driver);
+}
+postcore_initcall(sunxi_gpio_init);
This will become a simple module_init() if you are handling
deferred probe correctly.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/7] ARM: common: vic: Parse interrupt and resume masks from device tree
On Thu, Jan 10, 2013 at 12:41:43AM +0100, Tomasz Figa wrote: > +- interrupt-mask : Bit mask of valid interrupt sources (defaults to all > valid) > +- wakeup-mask : Bit mask of interrupt sources that can wake up the system > + (defaults to all allowed) Should this really be configured in the VIC itself? It seems like something that might change at runtime (for example, due to the user configuring wakes in sysfs). signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM i.MX53: dts: add oftree for MBa53 baseboard
On Thu, Jan 10, 2013 at 11:27:27AM +0100, Steffen Trumtrar wrote: > The MBa53 is a baseboard for the TQMA53 embedded module. This enables/adds > only > supported devices, i.e. it is not feature complete, because of missing drivers > in mainline linux. > > Signed-off-by: Steffen Trumtrar Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 5/7] ARM: s3c64xx: Add board file for boot using Device Tree
Hi Mark, On Thursday 10 of January 2013 10:52:22 Mark Brown wrote: > On Thu, Jan 10, 2013 at 12:41:47AM +0100, Tomasz Figa wrote: > > + * The following lookup table is used to override device names when > > devices + * are registered from device tree. This is temporarily > > added to enable + * device tree support addition for the Exynos4 > > architecture. > Cut'n'paste. Oh my, you got me. ;) I will correct it in next version. Thanks for spotting this. Best regards, Tomasz Figa ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
Hi, On Thursday 10 January 2013 03:28 PM, Benoit Cousson wrote: Hi Kishon, On 01/10/2013 07:19 AM, kishon wrote: On Friday 28 December 2012 12:05 AM, Aaro Koskinen wrote: Hi, On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include "ARM: dts:" * Added reg property and interrupt property for "usb_otg_hs". Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data Thanks for the update. I've just pulled the series for 3.7. I wonder what happened to the patch #3 (Add usb_otg and glue data) of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. I don't remember the context, can you repost it rebased on 3.8-rc2? Did it generate some discussion at that time? That patch also has SCM register. It might be rejected because of that. Will work on the that. Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 5/7] ARM: s3c64xx: Add board file for boot using Device Tree
On Thu, Jan 10, 2013 at 12:41:47AM +0100, Tomasz Figa wrote: > + * The following lookup table is used to override device names when devices > + * are registered from device tree. This is temporarily added to enable > + * device tree support addition for the Exynos4 architecture. Cut'n'paste. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] ARM i.MX53: dts: add oftree for MBa53 baseboard
The MBa53 is a baseboard for the TQMA53 embedded module. This enables/adds only
supported devices, i.e. it is not feature complete, because of missing drivers
in mainline linux.
Signed-off-by: Steffen Trumtrar
---
arch/arm/boot/dts/Makefile|1 +
arch/arm/boot/dts/imx53-mba53.dts | 130 +
2 files changed, 131 insertions(+)
create mode 100644 arch/arm/boot/dts/imx53-mba53.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..8ad484e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -82,6 +82,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
+ imx53-mba53.dtb \
imx53-qsb.dtb \
imx53-smd.dtb \
imx6q-arm2.dtb \
diff --git a/arch/arm/boot/dts/imx53-mba53.dts
b/arch/arm/boot/dts/imx53-mba53.dts
new file mode 100644
index 000..e54fffd
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-mba53.dts
@@ -0,0 +1,130 @@
+/*
+ * Copyright 2012 Sascha Hauer , Pengutronix
+ * Copyright 2012 Steffen Trumtrar , Pengutronix
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "imx53-tqma53.dtsi"
+
+/ {
+ model = "TQ MBa53 starter kit";
+ compatible = "tq,mba53", "tq,tqma53", "fsl,imx53";
+};
+
+&iomuxc {
+ lvds1 {
+ pinctrl_lvds1_1: lvds1-grp1 {
+ fsl,pins = <730 0x1 /* LVDS0_TX3 */
+ 732 0x1 /* LVDS0_CLK */
+ 734 0x1 /* LVDS0_TX2 */
+ 736 0x1 /* LVDS0_TX1 */
+ 738 0x1>; /* LVDS0_TX0 */
+ };
+
+ pinctrl_lvds1_2: lvds1-grp2 {
+ fsl,pins = <720 0x1 /* LVDS1_TX3 */
+ 722 0x1 /* LVDS1_TX2 */
+ 724 0x1 /* LVDS1_CLK */
+ 726 0x1 /* LVDS1_TX1 */
+ 728 0x1>; /* LVDS1_TX0 */
+ };
+ };
+
+ disp1 {
+ pinctrl_disp1_1: disp1-grp1 {
+ fsl,pins = <689 0x1 /* DISP1_DRDY */
+ 482 0x1 /* DISP1_HSYNC */
+ 489 0x1 /* DISP1_VSYNC */
+ 684 0x1 /* DISP1_DAT_0 */
+ 515 0x1 /* DISP1_DAT_22 */
+ 523 0x1 /* DISP1_DAT_23 */
+ 543 0x1 /* DISP1_DAT_21 */
+ 553 0x1 /* DISP1_DAT_20 */
+ 558 0x1 /* DISP1_DAT_19 */
+ 564 0x1 /* DISP1_DAT_18 */
+ 570 0x1 /* DISP1_DAT_17 */
+ 575 0x1 /* DISP1_DAT_16 */
+ 580 0x1 /* DISP1_DAT_15 */
+ 585 0x1 /* DISP1_DAT_14 */
+ 590 0x1 /* DISP1_DAT_13 */
+ 595 0x1 /* DISP1_DAT_12 */
+ 628 0x1 /* DISP1_DAT_11 */
+ 634 0x1 /* DISP1_DAT_10 */
+ 639 0x1 /* DISP1_DAT_9 */
+ 644 0x1 /* DISP1_DAT_8 */
+ 649 0x1 /* DISP1_DAT_7 */
+ 654 0x1 /* DISP1_DAT_6 */
+ 659 0x1 /* DISP1_DAT_5 */
+ 664 0x1 /* DISP1_DAT_4 */
+ 669 0x1 /* DISP1_DAT_3 */
+ 674 0x1 /* DISP1_DAT_2 */
+ 679 0x1 /* DISP1_DAT_1 */
+ 684 0x1>; /* DISP1_DAT_0 */
+ };
+ };
+};
+
+&cspi {
+ status = "okay";
+};
+
+&i2c2 {
+ codec: sgtl5000@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ };
+
+ expander: pca9554@20 {
+ compatible = "pca9554";
+ reg = <0x20>;
+ interrupts = <
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thu, Jan 10, 2013 at 09:17:19AM +, Arnd Bergmann wrote: > On Thursday 10 January 2013, Thierry Reding wrote: > > On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote: > > > On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote: > > > You could decrease the size of the mapping to only span the bus > > > numbers that are configured for use via DT. > > > > That won't work, unfortunately. The mapping is such that the bus number > > is not encoded in the uppermost bits, the extended register number is. > > So the only thing that we could do is decrease the size of the extended > > register space for *all* devices. > > But you could still a method to map 16 separate areas per bus, each 65536 > bytes long, which results in 1MB per bus. That is probably ok, since > very few systems have more than a handful of buses in practice. > > In theory, doing static mappings on a per-page base would let you > do 16 devices at a time, but it's probably worth doing at this fine > granularity. I don't understand how this would help. The encoding is like this: [27:24] extended register number [23:16] bus number [15:11] device number [10: 8] function number [ 7: 0] register number So it doesn't matter whether I use separate areas per bus or not. As soon as the whole extended configuration space needs to be accessed a whopping 28 bits (256 MiB) are required. What you propose would work if only regular configuration space is supported. I'm not sure if that's an option. > > > Are there any concerns about these config registers being accessed > > > from a context where a new mapping can't be made? Interrupt? Machine > > > Check? PCI-E Advanced Error Reporting? > > > > I haven't checked but I would expect configuration space accesses to not > > happen in interrupt context. Usually they are limited to enumeration and > > driver probe. > > Actually, AER probably needs this, and I believe some broken devices > need to mask interrupts using the PCI command word in the config space, > it it can happen. Ugh... that would kill any such dynamic mapping approach. Perhaps if we could mark a device as requiring a static mapping we could pin that cache entry. But that doesn't sound very encouraging. Thierry pgpCjrsItd8XX.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: omap: Add omap-usb2 dt data
Hi,
On Thursday 10 January 2013 03:34 PM, Benoit Cousson wrote:
On 01/10/2013 10:31 AM, kishon wrote:
Hi Benoit,
On Wednesday 19 September 2012 04:02 PM, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
This patch is also missing in mainline :-(
Well, in that case this was done on purpose :-)
Thanks
Kishon
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4fbb9dc..28eaddc 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -303,6 +303,11 @@
#size-cells = <1>;
ranges;
ti,hwmods = "ocp2scp_usb_phy";
+usb2phy@4a0ad080 {
+compatible = "ti,omap-usb2";
+reg = <0x4a0ad080 0x58>,
+ <0x4a002300 0x4>; /* TO BE REMOVED: SCM */
Rob and I did not agree to use that temp hack in the case of DT, so you
were supposed to repost with a proper driver for the SCM part that
control the USB.
Ok. Missed that. Will work on that.
Thanks
Kishon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] gpio: introduce descriptor-based interface
On Thursday 10 January 2013, Alex Courbot wrote: > On Wednesday 09 January 2013 18:46:12 Arnd Bergmann wrote: > > > > Only legacy users did this. Initially there was only the header file, > > with the API declared but several different implementations of it. > > gpiolib was introduced later to reduce code duplication and allow having > > multiple implementations in the same kernel. > > Does the following sound reasonable? > 1) Make sure every target that uses GENERIC_GPIO also implements its drivers > using gpiolib, convert the (hopefully) few ones that don't to use gpiolib > 2) Make GENERIC_GPIO require GPIOLIB or just merge both options into a single > one > 3) Turn gpio into a full subsystem (like pinctrl) > > This should make things less blurry and easier to maintain (less header > files, > only one interface, etc.) GPIO controllers would also be better integrated > into the driver model. Yes, I think that would be good. I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. > > Regarding the integration of pinctrl with gpio, > > I was thinking in the past that we could make pinctrl provide everything > > that gpiolib does, and have a generic gpiolib driver on top of pinctrl > > so that platforms don't need to implement both interfaces but only need > > to provide a pure pinctrl driver. Not sure if this makes any sense. > > That would work if all GPIOs were connected to a ball, but how about GPIO > expanders that are external to the chip? They have no use for pinctrl AFAICT. > On the other hand, maybe we can have one pinctrl-gpio driver for those chips > where pinctrl alone can emulate all the functionality of a GPIO controller. > Maybe such a driver exists already? I don't think we have that yet, but it would be another option: rather than putting a generic gpiolib driver on top of pinctrl, we could have pinctrl support for all gpios that go through gpiolib, and move device drivers over to use pinctrl as the way to manage gpios rather than the classic gpio drivers. That would be a larger change though, and require that we pull in the pinctrl subsystem on a lot of machines that don't need it today. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: omap: Add omap-usb2 dt data
On 01/10/2013 10:31 AM, kishon wrote:
> Hi Benoit,
>
> On Wednesday 19 September 2012 04:02 PM, Kishon Vijay Abraham I wrote:
>> Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
>> connected to ocp2scp, omap-usb2 dt data is added as a child node
>> of ocp2scp.
>>
>> Acked-by: Felipe Balbi
>> Signed-off-by: Kishon Vijay Abraham I
>
> This patch is also missing in mainline :-(
Well, in that case this was done on purpose :-)
>
> Thanks
> Kishon
>
>> ---
>> arch/arm/boot/dts/omap4.dtsi |5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 4fbb9dc..28eaddc 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -303,6 +303,11 @@
>> #size-cells = <1>;
>> ranges;
>> ti,hwmods = "ocp2scp_usb_phy";
>> +usb2phy@4a0ad080 {
>> +compatible = "ti,omap-usb2";
>> +reg = <0x4a0ad080 0x58>,
>> + <0x4a002300 0x4>; /* TO BE REMOVED: SCM */
Rob and I did not agree to use that temp hack in the case of DT, so you
were supposed to repost with a proper driver for the SCM part that
control the USB.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
Hi Kishon, On 01/10/2013 07:19 AM, kishon wrote: > On Friday 28 December 2012 12:05 AM, Aaro Koskinen wrote: >> Hi, >> >> On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: >>> On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include "ARM: dts:" * Added reg property and interrupt property for "usb_otg_hs". Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data >>> >>> Thanks for the update. I've just pulled the series for 3.7. >> >> I wonder what happened to the patch #3 (Add usb_otg and glue data) >> of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. I don't remember the context, can you repost it rebased on 3.8-rc2? Did it generate some discussion at that time? Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: omap: Add omap-usb2 dt data
Hi Benoit,
On Wednesday 19 September 2012 04:02 PM, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
This patch is also missing in mainline :-(
Thanks
Kishon
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4fbb9dc..28eaddc 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -303,6 +303,11 @@
#size-cells = <1>;
ranges;
ti,hwmods = "ocp2scp_usb_phy";
+ usb2phy@4a0ad080 {
+ compatible = "ti,omap-usb2";
+ reg = <0x4a0ad080 0x58>,
+ <0x4a002300 0x4>; /* TO BE REMOVED: SCM */
+ };
};
};
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/14] lib: Add I/O map cache implementation
On Thursday 10 January 2013, Thierry Reding wrote: > On Wed, Jan 09, 2013 at 04:17:58PM -0700, Jason Gunthorpe wrote: > > On Wed, Jan 09, 2013 at 04:12:31PM -0700, Stephen Warren wrote: > > You could decrease the size of the mapping to only span the bus > > numbers that are configured for use via DT. > > That won't work, unfortunately. The mapping is such that the bus number > is not encoded in the uppermost bits, the extended register number is. > So the only thing that we could do is decrease the size of the extended > register space for *all* devices. But you could still a method to map 16 separate areas per bus, each 65536 bytes long, which results in 1MB per bus. That is probably ok, since very few systems have more than a handful of buses in practice. In theory, doing static mappings on a per-page base would let you do 16 devices at a time, but it's probably worth doing at this fine granularity. > > Are there any concerns about these config registers being accessed > > from a context where a new mapping can't be made? Interrupt? Machine > > Check? PCI-E Advanced Error Reporting? > > I haven't checked but I would expect configuration space accesses to not > happen in interrupt context. Usually they are limited to enumeration and > driver probe. Actually, AER probably needs this, and I believe some broken devices need to mask interrupts using the PCI command word in the config space, it it can happen. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] usb: phy: samsung: Add support to set pmu isolation
Hi Sylwester,
On Thu, Jan 10, 2013 at 3:12 AM, Sylwester Nawrocki
wrote:
> Hi,
>
>
> On 12/28/2012 10:13 AM, Vivek Gautam wrote:
>>
>> Adding support to parse device node data in order to get
>> required properties to set pmu isolation for usb-phy.
>>
>> Signed-off-by: Vivek Gautam
>
> ...
>
>> --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> @@ -9,3 +9,38 @@ Required properties:
>> - compatible : should be "samsung,exynos4210-usbphy"
>> - reg : base physical address of the phy registers and length of memory
>> mapped
>> region.
>> +
>> +Optional properties:
>> +- #address-cells: should be '1' when usbphy node has a child node with
>> 'reg'
>> + property.
>> +- #size-cells: should be '1' when usbphy node has a child node with 'reg'
>> + property.
>> +- ranges: allows valid translation between child's address space and
>> parent's
>> + address space.
>> +
>> +- The child node 'usbphy-sys' to the node 'usbphy' is for the system
>> controller
>> + interface for usb-phy. It should provide the following information
>> required by
>> + usb-phy controller to control phy.
>> + - reg : base physical address of PHY control register in PMU which
>> + enables/disables the phy controller.
>
>
> On some SoCs USB_PHY_CONTROL registers don't belong to PMU. So maybe you
> should
> drop references to PMU, or list all SoC entities where USB_PHY_CONTROL
> appears:
> PMU, "MISC REGISTER", etc.
>
On S3C64XX "USB_SIG_MASK" bit is in "OTHERS" register, which is actually part of
system controller register map (clock controller + PM controller), and
then S5P64XX onward
this falls under PM controller's memory map. So, i thought of using
reference to PMU.
May be i am missing something here ?
Will change this if you suggest.
> I would just rephrase this to:
>
> - reg : base physical address of PHY_CONTROL registers
>
> "phy controller" might be confusing, since PHY CONTROLLER is an entity
> separate
> from PHY 0 and PHY 1 ?
>
Ok, will change this as suggested.
>
>> + The size of this register is the total sum of size of all
>> phy-control
>
>
> And what about using PHY_CONTROL name as per the User Manuals ? That would
> perhaps make it a bit easier to follow.
>
Sure this is better. We can use PHY_CONTROL to align with user manuals and avoid
any confusions.
>
>> + registers that the SoC has. For example, the size will be
>> + '0x4' in case we have only one phy-control register (like in
>> S3C64XX) or
>> + '0x8' in case we have two phy-control registers (like in
>> Exynos4210)
>> + and so on.
>> +
>> +Example:
>> + - Exynos4210
>> +
>> + usbphy@125B {
>> + #address-cells =<1>;
>> + #size-cells =<1>;
>> + compatible = "samsung,exynos4210-usbphy";
>> + reg =<0x125B 0x100>;
>> + ranges;
>> +
>> + usbphy-sys {
>> + /* USB device and host PHY_CONTROL registers */
>> + reg =<0x10020704 0x8>;
>> + };
>> + };
>
> ...
>
>> /*
>> + * struct samsung_usbphy_drvdata - driver data for various SoC variants
>> + * @cpu_type: machine identifier
>> + * @devphy_en_mask: device phy enable mask for PHY CONTROL register
>> + * @pmureg_devphy_offset: offset to DEVICE PHY CONTROL register from
>> + * mapped address of system controller.
>> + *
>> + * Here we have a separate mask for device type phy.
>> + * Having different masks for host and device type phy helps
>> + * in setting independent masks in case of SoCs like S5PV210,
>> + * in which PHY0 and PHY1 enable bits belong to same register
>> + * placed at position 0 and 1 respectively.
>> + * Although for newer SoCs like exynos these bits belong to
>> + * different registers altogether placed at position 0.
>> + */
>> +struct samsung_usbphy_drvdata {
>> + int cpu_type;
>> + int devphy_en_mask;
>> + u32 pmureg_devphy_offset;
>
>
> Perhaps just "devphy_reg_offset" would do ?
>
Sure, will amend this as suggested.
>
>> +};
>> +
>> +/*
>>* struct samsung_usbphy - transceiver driver state
>>* @phy: transceiver structure
>>* @plat: platform data
>>* @dev: The parent device supplied to the probe function
>>* @clk: usb phy clock
>>* @regs: usb phy register memory base
>
>
> Is this more precisely:
>
> * @regs: usb phy controller registers memory base
>
> ?
this had been a part of Praveen's work submitted for initial
samsung-usbphy driver,
so didn't change anything in that. ;-)
Will amend this as suggested.
>>
>> + * @pmureg: usb device phy-control pmu register memory base
>
>
> Maybe something like this would be more clear:
>
> @pmureg: USB device PHY_CONTROL registers memory region base
>
Sure, will amend this.
> Note, that not on all SoCs USB_PHY_CONTROL registers belong to PMU.
> Haven't you considered changing "pmureg" to ctrl_regs or something
> else more generic ?
>
Same as mentioned in above comment in this context for PMU register.
Thought this could be self-explanatory for pmu interface to con
Re: [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface
On Wed, Jan 09, 2013 at 11:10:55AM +, Russell King - ARM Linux wrote:
[...]
> err = gpio_request(en_vdd_1v05, "EN_VDD_1V05");
> if (err) {
> pr_err("%s: gpio_request failed: %d\n", __func__, err);
> return err;
> }
>
> gpio_direction_output(en_vdd_1v05, 1);
>
> regulator = regulator_get(NULL, "vdd_ldo0,vddio_pex_clk");
> if (IS_ERR_OR_NULL(regulator)) {
> pr_err("%s: regulator_get failed: %d\n", __func__,
>(int)PTR_ERR(regulator));
> goto err_reg;
> }
> ...
> err_reg:
> gpio_free(en_vdd_1v05);
>
> return err;
> }
>
> So 'err' here is never set. when IS_ERR_OR_NULL evaluates true.
> Setting 'err' to PTR_ERR(regulator) is not correct because a NULL return
> sets 'err' to zero.
FWIW, this one is fixed in the Tegra PCIe series I posted yesterday.
Thierry
pgp1KO2lbMFjw.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/4] usb: chipidea: imx: Add system suspend/resume API
During the system suspend/resume procedure, the USB also
needs to go suspend/resume procedure, this patch adds
related APIs. It is tested at i.mx6q sabrelite. Meanwhile,
it fixes the bug that the USB will out of work after
system suspend/resume.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/bits.h|1 +
drivers/usb/chipidea/ci13xxx_imx.c | 61
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index ba9c6ef..d1467bb 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -47,6 +47,7 @@
#define PORTSC_FPRBIT(6)
#define PORTSC_SUSP BIT(7)
#define PORTSC_HSPBIT(9)
+#define PORTSC_PHCD BIT(23) /* phy suspend mode */
#define PORTSC_PTC(0x0FUL << 16)
/* DEVLC */
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 342eab0..dd257b1 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -25,6 +25,7 @@
#include
#include "ci.h"
+#include "bits.h"
#include "ci13xxx_imx.h"
#define pdev_to_phy(pdev) \
@@ -321,6 +322,63 @@ static int ci13xxx_imx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int ci13xxx_imx_suspend(struct device *dev)
+{
+ struct ci13xxx_imx_data *data =
+ platform_get_drvdata(to_platform_device(dev));
+ struct platform_device *plat_ci;
+ struct ci13xxx *ci;
+
+ plat_ci = data->ci_pdev;
+ ci = platform_get_drvdata(plat_ci);
+
+ hw_write(ci, OP_PORTSC, PORTSC_PHCD, 1);
+
+ if (data->phy)
+ usb_phy_set_suspend(data->phy, 1);
+
+ clk_disable_unprepare(data->clk);
+
+ return 0;
+}
+
+static int ci13xxx_imx_resume(struct device *dev)
+{
+ int ret;
+ struct ci13xxx_imx_data *data =
+ platform_get_drvdata(to_platform_device(dev));
+ struct platform_device *plat_ci;
+ struct ci13xxx *ci;
+
+ plat_ci = data->ci_pdev;
+ ci = platform_get_drvdata(plat_ci);
+
+ ret = clk_prepare_enable(data->clk);
+ if (ret) {
+ dev_err(dev,
+ "Failed to prepare or enable clock, err=%d\n", ret);
+ return ret;
+ }
+
+ if (hw_read(ci, OP_PORTSC, PORTSC_PHCD)) {
+ hw_write(ci, OP_PORTSC, PORTSC_PHCD, 0);
+ /* Some clks sync between Controller and USB PHY */
+ mdelay(1);
+ }
+
+ if (data->phy)
+ usb_phy_set_suspend(data->phy, 0);
+
+ return ret;
+}
+
+static const struct dev_pm_ops ci13xxx_imx_pm_ops = {
+ .suspend= ci13xxx_imx_suspend,
+ .resume = ci13xxx_imx_resume,
+};
+#endif
+
static const struct of_device_id ci13xxx_imx_dt_ids[] = {
{ .compatible = "fsl,imx27-usb", },
{ /* sentinel */ }
@@ -334,6 +392,9 @@ static struct platform_driver ci13xxx_imx_driver = {
.name = "imx_usb",
.owner = THIS_MODULE,
.of_match_table = ci13xxx_imx_dt_ids,
+#ifdef CONFIG_PM
+ .pm = &ci13xxx_imx_pm_ops,
+#endif
},
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/4] usb: mxs-phy: add set_suspend API
It needs to call set_suspend during USB suspend/resume
Signed-off-by: Peter Chen
---
drivers/usb/otg/mxs-phy.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index 7dca384..40643c9 100644
--- a/drivers/usb/otg/mxs-phy.c
+++ b/drivers/usb/otg/mxs-phy.c
@@ -79,6 +79,25 @@ static void mxs_phy_shutdown(struct usb_phy *phy)
clk_disable_unprepare(mxs_phy->clk);
}
+static int mxs_phy_suspend(struct usb_phy *x, int suspend)
+{
+ struct mxs_phy *mxs_phy = to_mxs_phy(x);
+
+ if (suspend) {
+ writel_relaxed(0x, x->io_priv + HW_USBPHY_PWD);
+ writel_relaxed(BM_USBPHY_CTRL_CLKGATE,
+ x->io_priv + HW_USBPHY_CTRL_SET);
+ clk_disable_unprepare(mxs_phy->clk);
+ } else {
+ clk_prepare_enable(mxs_phy->clk);
+ writel_relaxed(BM_USBPHY_CTRL_CLKGATE,
+ x->io_priv + HW_USBPHY_CTRL_CLR);
+ writel_relaxed(0, x->io_priv + HW_USBPHY_PWD);
+ }
+
+ return 0;
+}
+
static int mxs_phy_on_connect(struct usb_phy *phy,
enum usb_device_speed speed)
{
@@ -141,6 +160,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
mxs_phy->phy.label = DRIVER_NAME;
mxs_phy->phy.init = mxs_phy_init;
mxs_phy->phy.shutdown = mxs_phy_shutdown;
+ mxs_phy->phy.set_suspend= mxs_phy_suspend;
mxs_phy->phy.notify_connect = mxs_phy_on_connect;
mxs_phy->phy.notify_disconnect = mxs_phy_on_disconnect;
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/4] usb: mxs-phy: Change mxs phy clock usage
As we mark mxs-phy as dummy clock for i.mx6q, we only need to
enable it at probe, this clock doesn't need to be managed
by clock framework.
Signed-off-by: Peter Chen
---
drivers/usb/otg/mxs-phy.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index 7630272..7dca384 100644
--- a/drivers/usb/otg/mxs-phy.c
+++ b/drivers/usb/otg/mxs-phy.c
@@ -20,6 +20,9 @@
#include
#include
#include
+#include
+#include
+#include
#define DRIVER_NAME "mxs_phy"
@@ -108,6 +111,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
void __iomem *base;
struct clk *clk;
struct mxs_phy *mxs_phy;
+ struct regmap *anatop;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -146,6 +150,46 @@ static int mxs_phy_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, &mxs_phy->phy);
+ /*
+* At mx6x, USB PHY PLL and its output gate is controlled by hardware.
+* It just needs to open at init, if the usb device is
+* in suspend, it will close related PLL automatically.
+*/
+
+ anatop = syscon_regmap_lookup_by_compatible("fsl,imx6q-anatop");
+
+#define CTRL_SET 0x4
+#define CTRL_CLR 0x8
+
+#define BM_ANADIG_USB_PLL_480_CTRL_BYPASS (1 << 16)
+#define BM_ANADIG_USB_PLL_480_CTRL_ENABLE (1 << 13)
+#define BM_ANADIG_USB_PLL_480_CTRL_POWER (1 << 12)
+#define BM_ANADIG_USB_PLL_480_CTRL_EN_USB_CLKS (1 << 6)
+
+ if (!IS_ERR(anatop)) {
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ u32 phy_reg_offset;
+ int ret;
+
+ ret = of_property_read_u32(np, "anatop-phy-reg-offset",
+ &phy_reg_offset);
+ if (ret) {
+ dev_err(dev, "no anatop-phy-reg-offset property set\n");
+ return -EINVAL;
+ }
+
+ regmap_write(anatop, phy_reg_offset + 0x8,
+ BM_ANADIG_USB_PLL_480_CTRL_BYPASS);
+ regmap_write(anatop, phy_reg_offset + 0x4,
+ BM_ANADIG_USB_PLL_480_CTRL_ENABLE
+ | BM_ANADIG_USB_PLL_480_CTRL_POWER
+ | BM_ANADIG_USB_PLL_480_CTRL_EN_USB_CLKS);
+
+ } else {
+ pr_warn("failed to find fsl,imx6q-anatop regmap\n");
+ }
+
return 0;
}
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
