Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Tue, Jul 28, 2015 at 10:47:28AM +0200, Teresa Remmet wrote:
Hello Igor,
Am Dienstag, den 28.07.2015, 11:29 +0300 schrieb Igor Grinberg:
Hi Matt,
On 07/27/15 17:34, Matt Porter wrote:
On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
phyCORE-AM335x is a SoM (System on Module) containing
a AM335x SOC. The module can be connected to different
carrier boards.
Some hardware parts are configurable on the phyCORE-AM335x.
So they are disabled on default in this som dtsi file.
They will be enabled in the board dts files, when populated.
* RAM up to 1GiB
* PMIC
* NAND flash up to 1GiB
* Eth PHY on SOM: 1x RMII
* SPI NOR flash 8MiB (optional)
* i2c RTC (optional)
* i2c EEPROM 4kiB (optional)
Signed-off-by: Teresa Remmet t.rem...@phytec.de
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
++
1 file changed, 368 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
new file mode 100644
index 000..4d28fc3
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
[...]
+#include am33xx.dtsi
+
+/ {
+model = Phytec AM335x phyCORE;
+compatible = phytec,am335x-phycore-som, ti,am33xx;
One minor thing here...wildcards in compatible strings aren't permitted.
However, family compatibles like ti,am33xx that came in before this
was enforced are grandfathered. Ideally, the newly introced board/som
specific strings should not propagate that wildcard. i.e. something
like phytec,am3352-phycore-som or whatever is the base family part
on these SOMs.
I'm not sure this is wild card.
I tend to think that it is the real name of the som [1], no?
http://phytec.com/products/system-on-modules/phycore/am335x/
Yes, your right. This is the name of the SoM. The phyCORE may have
different am335x versions mounted. So there is not the one am3352 or
am3359 always used.
Ok, great. Disregard then.
-Matt
--
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
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
phyCORE-AM335x is a SoM (System on Module) containing
a AM335x SOC. The module can be connected to different
carrier boards.
Some hardware parts are configurable on the phyCORE-AM335x.
So they are disabled on default in this som dtsi file.
They will be enabled in the board dts files, when populated.
* RAM up to 1GiB
* PMIC
* NAND flash up to 1GiB
* Eth PHY on SOM: 1x RMII
* SPI NOR flash 8MiB (optional)
* i2c RTC (optional)
* i2c EEPROM 4kiB (optional)
Signed-off-by: Teresa Remmet t.rem...@phytec.de
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
++
1 file changed, 368 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
new file mode 100644
index 000..4d28fc3
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -0,0 +1,368 @@
+/*
+ * Copyright (C) 2015 Phytec Messtechnik GmbH
+ * Author: Teresa Remmet t.rem...@phytec.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include am33xx.dtsi
+
+/ {
+ model = Phytec AM335x phyCORE;
+ compatible = phytec,am335x-phycore-som, ti,am33xx;
One minor thing here...wildcards in compatible strings aren't permitted.
However, family compatibles like ti,am33xx that came in before this
was enforced are grandfathered. Ideally, the newly introced board/som
specific strings should not propagate that wildcard. i.e. something
like phytec,am3352-phycore-som or whatever is the base family part
on these SOMs.
-Matt
+
+ aliases {
+ rtc0 = i2c_rtc;
+ rtc1 = rtc;
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ };
+};
+
+/* Crypto Module */
+aes {
+ status = okay;
+};
+
+sham {
+ status = okay;
+};
+
+/* Ethernet */
+am33xx_pinmux {
+ ethernet0_pins: pinmux_ethernet0 {
+ pinctrl-single,pins =
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_crs.rmii1_crs_dv */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxerr.rmii1_rxerr */
+ 0x114 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txen.rmii1_txen */
+ 0x124 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd1.rmii1_txd1 */
+ 0x128 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd0.rmii1_txd0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd1.rmii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd0.rmii1_rxd0 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
rmii1_refclk.rmii1_refclk */
+ ;
+ };
+
+ mdio_pins: pinmux_mdio {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ ;
+ };
+};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 0;
+ phy-mode = rmii;
+ dual_emac_res_vlan = 1;
+};
+
+davinci_mdio {
+ pinctrl-names = default;
+ pinctrl-0 = mdio_pins;
+ status = okay;
+};
+
+mac {
+ slaves = 1;
+ pinctrl-names = default;
+ pinctrl-0 = ethernet0_pins;
+ status = okay;
+};
+
+phy_sel {
+ rmii-clock-ext;
+};
+
+/* I2C Busses */
+am33xx_pinmux {
+ i2c0_pins: pinmux_i2c0 {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT | MUX_MODE0) /* i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT | MUX_MODE0) /* i2c0_scl.i2c0_scl */
+ ;
+ };
+};
+
+i2c0 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+ status = okay;
+
+ tps: pmic@2d {
+ reg = 0x2d;
+ };
+
+ i2c_eeprom: eeprom@52 {
+ compatible = atmel,24c32;
+ pagesize = 32;
+ reg = 0x52;
+ status = disabled;
+ };
+
+ i2c_rtc: rtc@68 {
+ compatible = rv4162;
+ reg = 0x68;
+ status = disabled;
+ };
+};
+
+/* NAND memory */
+am33xx_pinmux {
+ nandflash_pins: pinmux_nandflash {
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
+
[PATCH RESEND] serial: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be ti,omap2-uart for OMAP2 controllers
- compatible : should be ti,omap3-uart for OMAP3 controllers
- compatible : should be ti,omap4-uart for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be uartn, n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : rx for receive channel, tx for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = ti,omap3-uart;
+reg = 0x49042000 0x400;
+interrupts = 80;
+dmas = sdma 81 sdma 82;
+dma-names = tx, rx;
+ti,hwmods = uart4;
+clock-frequency = 4800;
+};
--
1.8.4
--
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
[PATCH] Documentation: DT: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be ti,omap2-uart for OMAP2 controllers
- compatible : should be ti,omap3-uart for OMAP3 controllers
- compatible : should be ti,omap4-uart for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be uartn, n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : rx for receive channel, tx for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = ti,omap3-uart;
+reg = 0x49042000 0x400;
+interrupts = 80;
+dmas = sdma 81 sdma 82;
+dma-names = tx, rx;
+ti,hwmods = uart4;
+clock-frequency = 4800;
+};
--
1.8.4
--
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
[PATCH] ARM: dts: am335x-boneblack: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = okay;
};
+sham {
+ status = okay;
+};
+
+aes {
+ status = okay;
+};
+
am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins =
--
1.8.4
--
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
Re: [PATCH] ARM: dts: am335x-boneblack: enable aes and sham
On Wed, Feb 25, 2015 at 12:36:11PM -0600, Robert Nelson wrote:
On Wed, Feb 25, 2015 at 11:07 AM, Matt Porter mpor...@konsulko.com wrote:
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = okay;
};
+sham {
+ status = okay;
+};
+
+aes {
+ status = okay;
+};
+
am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins =
--
1.8.4
Shouldn't we just move these to: am335x-bone-common.dtsi ?
(and then nuke the 6 lines in the am335x-bone.dts )
Good idea, v2 on the way.
-Matt
--
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
[PATCH v2] ARM: dts: am335x-bone-common: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes
in the am335x-bone-common.dtsi. With this change, enabling the
nodes in am335x-bone.dts is no longer required so remove them.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8
arch/arm/boot/dts/am335x-bone.dts | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6cc25ed..12cdb2b 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -300,3 +300,11 @@
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
cd-inverted;
};
+
+aes {
+ status = okay;
+};
+
+sham {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 83d40f7..6b849372 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,11 +24,3 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
-
-sham {
- status = okay;
-};
-
-aes {
- status = okay;
-};
--
1.8.4
--
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
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote: On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote: Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote: I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Here's the most obvious question in the world on this topic. Are capes hot-pluggable? Looking at the posts on google+ from David Anders, they're using pin headers for connectivity, with no additional protection against hot- plugging, and no sequencing of pin connection. In other words, they are not hot-pluggable. So, why do we need to add a load of infrastructure to the kernel to allow the device tree to be modified at run time? At present, the way the entire DT infrastructure works is that it assumes the DT remains static and never changes - this applies not only to the core DT code, but also to all the drivers which have been converted. So, you're asking for a feature which is impossible to really make use of on the hardware which you want to use it. Why should kernel developers go to the extent of adding support for DT modification at runtime when the platform you want this for doesn't even support hotplugging of these capes? It's important to note that Jason's use case is not the real one driving runtime DT modification. You'll have to go back to threads like https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all hashed out. The clearest use cases are the FPGA folks that are loading their bitstream from userspace and due to DT-everywhere also need to initiate runtime modification of the live DT tree from userspace. There's a lot of discussion over many threads where this has been debated. -Matt -- 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
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 02:15:22PM +0100, Russell King wrote: On Tue, Jun 17, 2014 at 08:58:31AM -0400, Matt Porter wrote: On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote: Why should kernel developers go to the extent of adding support for DT modification at runtime when the platform you want this for doesn't even support hotplugging of these capes? It's important to note that Jason's use case is not the real one driving runtime DT modification. You'll have to go back to threads like https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all hashed out. The clearest use cases are the FPGA folks that are loading their bitstream from userspace and due to DT-everywhere also need to initiate runtime modification of the live DT tree from userspace. There's a lot of discussion over many threads where this has been debated. Okay, so it was debated, and the outcome of that debate has been... no change. That's probably because it is an incredible amount of work to achieve it, and none of the overloaded DT maintainers (who don't have enough time to review new bindings) have any intention of putting their precious resources towards it. I don't believe this is completely true. Pantelis and Grant are working together on getting DT overlays upstream. It's pretty far along. It doesn't mean there aren't serious issues with the way the DT core code was implement assuming it would be static. From my rudimentary understanding of the OF code, it seems to mean that the way devices are created from the parsed OF tree structures (the device_node structures) needs to change such that when an OF tree node is removed, its corresponding device is also removed. This probably needs a struct device pointer in the device_node struct. Then there needs to be support to modify the parsed OF tree (not only to add nodes but also to remove nodes) and do the right thing when a node is added and/or removed. However, there's harder cases to solve. There's several instances where device nodes do not correspond with a struct device, and these nodes are parsed by the driver. Such things as the of_graph stuff, which describes the inter-connectivity of a display subsystem or v4l2 subsystem. The nodes may be specified, but the target device for one of the links may be disabled at original probe time, but later becomes enabled via modification - this is one of the difficult cases since it needs the driver to cooperate with the change, and there's no existing way to notify it of that change. As with any kernel change, it needs people to write code. If no one writes code, no change happens. Endlessly discussing it on mailing lists does not result in code being written. Yes, I suppose you missed the active work on the DT overlay series. As I mentioned, there's active development on these things. There's also active discussion on some of the challenges. However, going back to the original stated platform - none of this complexity is required there. Once power is applied, the platform hardware configuration is fixed (unless you want to yank a board off and risk destroying the hardware in doing so.) So, if Jason's interest is in the capes, then the simplest and easiest approach is to have the boot loader deal with it. If it's about FPGAs and dynamically loading bitstreams into them, then maybe a dynamic device tree is the answer - but /someone/ then has to create patches to achieve that. If no one is willing to create those patches, then forget the idea of a dynamic device tree, because it won't happen on its own. https://lkml.org/lkml/2014/5/28/280 -Matt -- 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
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
-Matt
--
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
Re: [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
On Wed, Feb 05, 2014 at 08:09:16AM -0600, Nishanth Menon wrote:
On 02/05/2014 07:48 AM, Jack Mitchell wrote:
From: Jack Mitchell j...@embed.me.uk
Devicetree include file for setting up the am335x mcasp bus, i2c-2
bus, and audio codec required for a functioning BeagleBone Audio Cape.
Signed-off-by: Jack Mitchell j...@embed.me.uk
Signed-off-by: Matt Porter mpor...@linaro.org
---
arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124
+
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
2 files changed, 138 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
new file mode 100644
index 000..b8ec3dc
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2014 Jack Mitchell j...@embed.me.uk
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * In order to enable the BeagleBone Audio Cape this dtsi must be
+ * incuded in the top level dts. On BeagleBone Black hardware the
+ * status of the HDMI dts node must also be set to disabled.
+ *
+ * --- a/arch/arm/boot/dts/am335x-bone.dts
+ * +++ b/arch/arm/boot/dts/am335x-bone.dts
+ * @@ -9,6 +9,7 @@
+ *
+ * #include am33xx.dtsi
+ * #include am335x-bone-common.dtsi
+ * +#include am335x-bone-audio-cape-reva.dtsi
+ *
+ * ldo3_reg {
+ * regulator-min-microvolt = 180;
+ *
+ * On BeagleBone Black hardware the status of the HDMI dts node must
+ * also be set to disabled
+ *
+ * --- a/arch/arm/boot/dts/am335x-boneblack.dts
+ * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
+ * @@ -73,6 +74,6 @@
+ * pinctrl-names = default, off;
+ * pinctrl-0 = nxp_hdmi_bonelt_pins;
+ * pinctrl-1 = nxp_hdmi_bonelt_off_pins;
+ * - status = okay;
+ * + status = disabled;
+ * };
+ * };
+ */
+
how about making the audio-cape-reva.dts which includes and overrides
parameters of boneblack.dts?
Yeah, that might be a little cleaner. Black makes things unfortunately
messy for these capes that were really intended for BBW :(
Further, I see a bunch of capes in
http://elinux.org/Beagleboard:BeagleBone_Capes
Assuming that we dont want to discuss capebus all over again, is this
the approach we'd like to consider in the interim?
I think that's a fair assumption...I'll note that there is work slowly
in progress on a very minimal implementation DT overlays upstream. But
that doesn't exist. We are simply interested in a sane way to use the
hardware we own in mainline and this approach makes it possible to build
a kernel+dtb from mainline that works for this configuration. If
there's a better way to support this hardware *today* let's discuss it.
One of the big benefits to having this upstream is that it's no longer
out of sight out of mind. It should be managed alongside all the other
am335x dts data.
Incidentally, I'm hoping to contribute a similar patch for the DVI cape
I have here.
-Matt
--
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
Re: [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
On Wed, Feb 05, 2014 at 08:56:34AM -0600, Nishanth Menon wrote: On 02/05/2014 08:38 AM, Matt Porter wrote: On Wed, Feb 05, 2014 at 08:09:16AM -0600, Nishanth Menon wrote: On 02/05/2014 07:48 AM, Jack Mitchell wrote: [...] + * --- a/arch/arm/boot/dts/am335x-boneblack.dts + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts + * @@ -73,6 +74,6 @@ + * pinctrl-names = default, off; + * pinctrl-0 = nxp_hdmi_bonelt_pins; + * pinctrl-1 = nxp_hdmi_bonelt_off_pins; + * - status = okay; + * + status = disabled; + * }; + * }; + */ + how about making the audio-cape-reva.dts which includes and overrides parameters of boneblack.dts? Yeah, that might be a little cleaner. Black makes things unfortunately messy for these capes that were really intended for BBW :( yes indeed - we might have to live with more dts in such a case. Further, I see a bunch of capes in http://elinux.org/Beagleboard:BeagleBone_Capes Assuming that we dont want to discuss capebus all over again, is this the approach we'd like to consider in the interim? I think that's a fair assumption...I'll note that there is work slowly in progress on a very minimal implementation DT overlays upstream. But that doesn't exist. We are simply interested in a sane way to use the hardware we own in mainline and this approach makes it possible to build a kernel+dtb from mainline that works for this configuration. If there's a better way to support this hardware *today* let's discuss it. One of the big benefits to having this upstream is that it's no longer out of sight out of mind. It should be managed alongside all the other am335x dts data. Incidentally, I'm hoping to contribute a similar patch for the DVI cape I have here. If I am not mistaken, the capes are stackable (within reason), and are not exactly hotpluggable.. question pops up as to how do we handle multiple cape descriptions on the same board without having the user to create custom dts which includes each relevant cape dts he has on his/her bone? I wonder(without proper research, just thinking aloud) if u-boot can do some sort of merge of dtbs - assuming ofcourse eeprom data is used to detect the capes plugged on board? Well covered in the original discussion. gcl summarizes options in https://lkml.org/lkml/2012/11/5/615 Since then, the basic overlay support for the kernel is pretty much a done deal. It has a wide variety of users (FPGA folks) beyond this board specific case. The problem you describe about resource management and conflicts would probably need to be built on top of that. Pantelis had a PoC implementation with capebus/not-a-capebus but that's not part of what is being upstreamed. I'm not sure if there's anybody with enough time out of the Beagleboard community to upstream a resource manager on top of the basic overlay support that's in progress. However, it might make a nice GSoC2014 project. :) -Matt -- 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
[PATCH v3 0/6] IIO pulse capture support for TI ECAP
Changes since v2: - Remove various unneeded field initialization - Call iio_triggered_buffer_cleanup() on remove Changes since v1: - Rebased to 3.14-rc1 - Renamed in_pulse_polarity to pulse_polarity - Added ABI entries for pulse devices and TI ECAP This series adds support for PWM capture devices within IIO and adds a TI ECAP IIO driver. PWM capture devices are supported using a new IIO pulse channel type. The IIO ECAP driver implements interrupt driven triggered buffer capture only as raw sample reads are not applicable to this hardware. Initially, the driver supports a single pulse width measurement with configurable polarity. The ECAP hardware can support measurement of a complete period and duty cycle but this is not yet implemented. Matt Porter (6): iio: add support for pulse width capture devices iio: pulse: add TI ECAP driver iio: enable selection and build of pulse drivers iio: Add ABI docs for pulse capture devices pwm: enable TI PWMSS if the IIO tiecap driver is selected ARM: dts: AM33XX: Add ecap interrupt properties Documentation/ABI/testing/sysfs-bus-iio| 18 + .../ABI/testing/sysfs-bus-iio-pulse-tiecap | 9 + arch/arm/boot/dts/am33xx.dtsi | 6 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/industrialio-core.c| 1 + drivers/iio/pulse/Kconfig | 20 + drivers/iio/pulse/Makefile | 6 + drivers/iio/pulse/tiecap.c | 491 + drivers/pwm/Kconfig| 2 +- include/linux/iio/types.h | 1 + 11 files changed, 555 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap create mode 100644 drivers/iio/pulse/Kconfig create mode 100644 drivers/iio/pulse/Makefile create mode 100644 drivers/iio/pulse/tiecap.c -- 1.8.4 -- 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
[PATCH v3 3/6] iio: enable selection and build of pulse drivers
Add the pulse driver subdirectory when configuring and building IIO. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 5dd0e12..286acc3 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -74,6 +74,7 @@ if IIO_TRIGGER source drivers/iio/trigger/Kconfig endif #IIO_TRIGGER source drivers/iio/pressure/Kconfig +source drivers/iio/pulse/Kconfig source drivers/iio/temperature/Kconfig endif # IIO diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile index 887d390..9a953c9 100644 --- a/drivers/iio/Makefile +++ b/drivers/iio/Makefile @@ -24,5 +24,6 @@ obj-y += light/ obj-y += magnetometer/ obj-y += orientation/ obj-y += pressure/ +obj-y += pulse/ obj-y += temperature/ obj-y += trigger/ -- 1.8.4 -- 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
[PATCH v3 5/6] pwm: enable TI PWMSS if the IIO tiecap driver is selected
The IIO TI ECAP driver depends on the TI PWMSS management driver in this subsystem. Enable PWMSS when the IIO TI ECAP driver is selected. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/pwm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 22f2f28..bd3cc65 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -219,7 +219,7 @@ config PWM_TIEHRPWM config PWM_TIPWMSS bool - default y if SOC_AM33XX (PWM_TIECAP || PWM_TIEHRPWM) + default y if SOC_AM33XX (IIO_TIECAP || PWM_TIECAP || PWM_TIEHRPWM) help PWM Subsystem driver support for AM33xx SOC. -- 1.8.4 -- 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
[PATCH v3 2/6] iio: pulse: add TI ECAP driver
Adds support for capturing PWM signals using the TI ECAP peripheral.
This driver supports triggered buffer capture of pulses on multiple
ECAP instances. In addition, the driver supports configurable polarity
of the signal to be captured.
Signed-off-by: Matt Porter mpor...@linaro.org
---
drivers/iio/pulse/Kconfig | 20 ++
drivers/iio/pulse/Makefile | 6 +
drivers/iio/pulse/tiecap.c | 491 +
3 files changed, 517 insertions(+)
create mode 100644 drivers/iio/pulse/Kconfig
create mode 100644 drivers/iio/pulse/Makefile
create mode 100644 drivers/iio/pulse/tiecap.c
diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
new file mode 100644
index 000..9864d4b
--- /dev/null
+++ b/drivers/iio/pulse/Kconfig
@@ -0,0 +1,20 @@
+#
+# Pulse Capture Devices
+#
+# When adding new entries keep the list in alphabetical order
+
+menu Pulse Capture Devices
+
+config IIO_TIECAP
+ tristate TI ECAP Pulse Capture
+ depends on SOC_AM33XX
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+If you say yes here you get support for the TI ECAP peripheral
+in pulse capture mode.
+
+This driver can also be built as a module. If so, the module
+will be called tiecap
+
+endmenu
diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
new file mode 100644
index 000..94d4b00
--- /dev/null
+++ b/drivers/iio/pulse/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO PWM Capture Devices
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_TIECAP) += tiecap.o
diff --git a/drivers/iio/pulse/tiecap.c b/drivers/iio/pulse/tiecap.c
new file mode 100644
index 000..fd96745
--- /dev/null
+++ b/drivers/iio/pulse/tiecap.c
@@ -0,0 +1,491 @@
+/*
+ * ECAP IIO pulse capture driver
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: Matt Porter mpor...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/iio/buffer.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/trigger.h
+#include linux/iio/trigger_consumer.h
+#include linux/iio/triggered_buffer.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+
+#include ../../pwm/pwm-tipwmss.h
+
+/* ECAP regs and bits */
+#define CAP1 0x08
+#define CAP2 0x0c
+#define ECCTL1 0x28
+#define ECCTL1_RUN_FREEBIT(15)
+#define ECCTL1_CAPLDEN BIT(8)
+#define ECCTL1_CAP2POL BIT(2)
+#define ECCTL1_CTRRST1 BIT(1)
+#define ECCTL1_CAP1POL BIT(0)
+#define ECCTL2 0x2a
+#define ECCTL2_SYNCO_SEL_DIS BIT(7)
+#define ECCTL2_TSCTR_FREERUN BIT(4)
+#define ECCTL2_REARM BIT(3)
+#define ECCTL2_STOP_WRAP_2 BIT(1)
+#define ECEINT 0x2c
+#define ECFLG 0x2e
+#define ECCLR 0x30
+#define ECINT_CTRCMP BIT(7)
+#define ECINT_CTRPRD BIT(6)
+#define ECINT_CTROVF BIT(5)
+#define ECINT_CEVT4BIT(4)
+#define ECINT_CEVT3BIT(3)
+#define ECINT_CEVT2BIT(2)
+#define ECINT_CEVT1BIT(1)
+#define ECINT_ALL (ECINT_CTRCMP | \
+ ECINT_CTRPRD | \
+ ECINT_CTROVF | \
+ ECINT_CEVT4 | \
+ ECINT_CEVT3 | \
+ ECINT_CEVT2 | \
+ ECINT_CEVT1)
+
+/* ECAP driver flags */
+#define ECAP_POLARITY_HIGH BIT(1)
+#define ECAP_ENABLED BIT(0)
+
+struct ecap_context {
+ u32 cap1;
+ u32 cap2;
+ u16 ecctl1;
+ u16 ecctl2;
+ u16 eceint;
+};
+
+struct ecap_state {
+ unsigned long flags;
+ unsigned intclk_rate;
+ void __iomem*regs;
+ u32 *buf;
+ struct ecap_context ctx;
+};
+
+#define dev_to_ecap_state(d) iio_priv(dev_to_iio_dev(d))
+
+static const struct iio_chan_spec ecap_channels[] = {
+ {
+ .type = IIO_PULSE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 32,
+ .storagebits= 32,
+ .endianness = IIO_LE
[PATCH v3 6/6] ARM: dts: AM33XX: Add ecap interrupt properties
Add missing interrupt properties to the ecap0, ecap1, and ecap2 nodes. Signed-off-by: Matt Porter mpor...@linaro.org --- arch/arm/boot/dts/am33xx.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 6d95d3d..b4139ba 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -582,6 +582,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48300100 0x80; + interrupts = 31; + interrupt-names = ecap0; ti,hwmods = ecap0; status = disabled; }; @@ -610,6 +612,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48302100 0x80; + interrupts = 47; + interrupt-names = ecap1; ti,hwmods = ecap1; status = disabled; }; @@ -638,6 +642,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48304100 0x80; + interrupts = 61; + interrupt-names = ecap2; ti,hwmods = ecap2; status = disabled; }; -- 1.8.4 -- 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
[PATCH v3 4/6] iio: Add ABI docs for pulse capture devices
Add standard ABI entries for pulse capture devices. Also add a separate ABI entry for the TI ECAP driver polarity option. Signed-off-by: Matt Porter mpor...@linaro.org --- Documentation/ABI/testing/sysfs-bus-iio | 18 ++ Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap | 9 + 2 files changed, 27 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6e02c50..918a201 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -210,6 +210,14 @@ Contact: linux-...@vger.kernel.org Description: Scaled humidity measurement in milli percent. +What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_raw +What: /sys/bus/iio/devices/iio:deviceX/in_pulse_raw +KernelVersion: 3.15 +Contact: linux-...@vger.kernel.org +Description: + Raw pulse measurement from channel Y. Units after + application of scale and offset are nanoseconds. + What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset @@ -220,6 +228,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset +What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_offset +What: /sys/bus/iio/devices/iio:deviceX/in_pulse_offset KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org Description: @@ -251,6 +261,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale +What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_scale +What: /sys/bus/iio/devices/iio:deviceX/in_pulse_scale KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org Description: @@ -784,6 +796,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en What: /sys/.../iio:deviceX/scan_elements/in_pressure_en +What: /sys/.../iio:deviceX/scan_elements/in_pulseY_en +What: /sys/.../iio:deviceX/scan_elements/in_pulse_en KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: @@ -799,6 +813,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type What: /sys/.../iio:deviceX/scan_elements/in_pressure_type +What: /sys/.../iio:deviceX/scan_elements/in_pulseY_type +What: /sys/.../iio:deviceX/scan_elements/in_pulse_type KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: @@ -845,6 +861,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index What: /sys/.../iio:deviceX/scan_elements/in_pressure_index +What: /sys/.../iio:deviceX/scan_elements/in_pulseY_index +What: /sys/.../iio:deviceX/scan_elements/in_pulse_index KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: diff --git a/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap b/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap new file mode 100644 index 000..a9e4a9f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap @@ -0,0 +1,9 @@ +What: /sys/bus/iio/devices/iio:deviceX/pulse_polarityY +What: /sys/bus/iio/devices/iio:deviceX/pulse_polarity +Date: January 2014 +KernelVersion: 3.15 +Contact: Matt Porter mpor...@linaro.org +Description: + Get and set the polarity of the pulse signal to be captured + for channel Y. 1 indicates a high pulse signal and 0 + indicates a low pulse signal. -- 1.8.4 -- 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
[PATCH v3 1/6] iio: add support for pulse width capture devices
Add a channel type to support pulse width capture devices.
These devices capture the timing of a PWM signal based on a
configurable trigger
Signed-off-by: Matt Porter mpor...@linaro.org
---
drivers/iio/industrialio-core.c | 1 +
include/linux/iio/types.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index acc911a..6ea0cf8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -70,6 +70,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CCT] = cct,
[IIO_PRESSURE] = pressure,
[IIO_HUMIDITYRELATIVE] = humidityrelative,
+ [IIO_PULSE] = pulse,
};
static const char * const iio_modifier_names[] = {
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 084d882..4fa8840 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -30,6 +30,7 @@ enum iio_chan_type {
IIO_CCT,
IIO_PRESSURE,
IIO_HUMIDITYRELATIVE,
+ IIO_PULSE,
};
enum iio_modifier {
--
1.8.4
--
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
[PATCH v2 0/6] IIO pulse capture support for TI ECAP
Changes since v1: - Rebased to 3.14-rc1 - Renamed in_pulse_polarity to pulse_polarity - Added ABI entries for pulse devices and TI ECAP This series adds support for PWM capture devices within IIO and adds a TI ECAP IIO driver. PWM capture devices are supported using a new IIO pulse channel type. The IIO ECAP driver implements interrupt driven triggered buffer capture only as raw sample reads are not applicable to this hardware. Initially, the driver supports a single pulse width measurement with configurable polarity. The ECAP hardware can support measurement of a complete period and duty cycle but this is not yet implemented. Matt Porter (6): iio: add support for pulse width capture devices iio: pulse: add TI ECAP driver iio: enable selection and build of pulse drivers iio: Add ABI docs for pulse capture devices pwm: enable TI PWMSS if the IIO tiecap driver is selected ARM: dts: AM33XX: Add ecap interrupt properties Documentation/ABI/testing/sysfs-bus-iio| 18 + .../ABI/testing/sysfs-bus-iio-pulse-tiecap | 9 + arch/arm/boot/dts/am33xx.dtsi | 6 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/industrialio-core.c| 1 + drivers/iio/pulse/Kconfig | 20 + drivers/iio/pulse/Makefile | 6 + drivers/iio/pulse/tiecap.c | 493 + drivers/pwm/Kconfig| 2 +- include/linux/iio/types.h | 1 + 11 files changed, 557 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap create mode 100644 drivers/iio/pulse/Kconfig create mode 100644 drivers/iio/pulse/Makefile create mode 100644 drivers/iio/pulse/tiecap.c -- 1.8.4 -- 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
[PATCH v2 6/6] ARM: dts: AM33XX: Add ecap interrupt properties
Add missing interrupt properties to the ecap0, ecap1, and ecap2 nodes. Signed-off-by: Matt Porter mpor...@linaro.org --- arch/arm/boot/dts/am33xx.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 6d95d3d..b4139ba 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -582,6 +582,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48300100 0x80; + interrupts = 31; + interrupt-names = ecap0; ti,hwmods = ecap0; status = disabled; }; @@ -610,6 +612,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48302100 0x80; + interrupts = 47; + interrupt-names = ecap1; ti,hwmods = ecap1; status = disabled; }; @@ -638,6 +642,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48304100 0x80; + interrupts = 61; + interrupt-names = ecap2; ti,hwmods = ecap2; status = disabled; }; -- 1.8.4 -- 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
[PATCH v2 5/6] pwm: enable TI PWMSS if the IIO tiecap driver is selected
The IIO TI ECAP driver depends on the TI PWMSS management driver in this subsystem. Enable PWMSS when the IIO TI ECAP driver is selected. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/pwm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 22f2f28..bd3cc65 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -219,7 +219,7 @@ config PWM_TIEHRPWM config PWM_TIPWMSS bool - default y if SOC_AM33XX (PWM_TIECAP || PWM_TIEHRPWM) + default y if SOC_AM33XX (IIO_TIECAP || PWM_TIECAP || PWM_TIEHRPWM) help PWM Subsystem driver support for AM33xx SOC. -- 1.8.4 -- 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
[PATCH v2 4/6] iio: Add ABI docs for pulse capture devices
Add standard ABI entries for pulse capture devices. Also add a separate ABI entry for the TI ECAP driver polarity option. Signed-off-by: Matt Porter mpor...@linaro.org --- Documentation/ABI/testing/sysfs-bus-iio | 18 ++ Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap | 9 + 2 files changed, 27 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6e02c50..918a201 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -210,6 +210,14 @@ Contact: linux-...@vger.kernel.org Description: Scaled humidity measurement in milli percent. +What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_raw +What: /sys/bus/iio/devices/iio:deviceX/in_pulse_raw +KernelVersion: 3.15 +Contact: linux-...@vger.kernel.org +Description: + Raw pulse measurement from channel Y. Units after + application of scale and offset are nanoseconds. + What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset @@ -220,6 +228,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset +What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_offset +What: /sys/bus/iio/devices/iio:deviceX/in_pulse_offset KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org Description: @@ -251,6 +261,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale +What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_scale +What: /sys/bus/iio/devices/iio:deviceX/in_pulse_scale KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org Description: @@ -784,6 +796,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en What: /sys/.../iio:deviceX/scan_elements/in_pressure_en +What: /sys/.../iio:deviceX/scan_elements/in_pulseY_en +What: /sys/.../iio:deviceX/scan_elements/in_pulse_en KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: @@ -799,6 +813,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type What: /sys/.../iio:deviceX/scan_elements/in_pressure_type +What: /sys/.../iio:deviceX/scan_elements/in_pulseY_type +What: /sys/.../iio:deviceX/scan_elements/in_pulse_type KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: @@ -845,6 +861,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index What: /sys/.../iio:deviceX/scan_elements/in_pressure_index +What: /sys/.../iio:deviceX/scan_elements/in_pulseY_index +What: /sys/.../iio:deviceX/scan_elements/in_pulse_index KernelVersion: 2.6.37 Contact: linux-...@vger.kernel.org Description: diff --git a/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap b/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap new file mode 100644 index 000..a9e4a9f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap @@ -0,0 +1,9 @@ +What: /sys/bus/iio/devices/iio:deviceX/pulse_polarityY +What: /sys/bus/iio/devices/iio:deviceX/pulse_polarity +Date: January 2014 +KernelVersion: 3.15 +Contact: Matt Porter mpor...@linaro.org +Description: + Get and set the polarity of the pulse signal to be captured + for channel Y. 1 indicates a high pulse signal and 0 + indicates a low pulse signal. -- 1.8.4 -- 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
[PATCH v2 1/6] iio: add support for pulse width capture devices
Add a channel type to support pulse width capture devices.
These devices capture the timing of a PWM signal based on a
configurable trigger
Signed-off-by: Matt Porter mpor...@linaro.org
---
drivers/iio/industrialio-core.c | 1 +
include/linux/iio/types.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index acc911a..6ea0cf8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -70,6 +70,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CCT] = cct,
[IIO_PRESSURE] = pressure,
[IIO_HUMIDITYRELATIVE] = humidityrelative,
+ [IIO_PULSE] = pulse,
};
static const char * const iio_modifier_names[] = {
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 084d882..4fa8840 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -30,6 +30,7 @@ enum iio_chan_type {
IIO_CCT,
IIO_PRESSURE,
IIO_HUMIDITYRELATIVE,
+ IIO_PULSE,
};
enum iio_modifier {
--
1.8.4
--
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
[PATCH v2 2/6] iio: pulse: add TI ECAP driver
Adds support for capturing PWM signals using the TI ECAP peripheral.
This driver supports triggered buffer capture of pulses on multiple
ECAP instances. In addition, the driver supports configurable polarity
of the signal to be captured.
Signed-off-by: Matt Porter mpor...@linaro.org
---
drivers/iio/pulse/Kconfig | 20 ++
drivers/iio/pulse/Makefile | 6 +
drivers/iio/pulse/tiecap.c | 493 +
3 files changed, 519 insertions(+)
create mode 100644 drivers/iio/pulse/Kconfig
create mode 100644 drivers/iio/pulse/Makefile
create mode 100644 drivers/iio/pulse/tiecap.c
diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
new file mode 100644
index 000..9864d4b
--- /dev/null
+++ b/drivers/iio/pulse/Kconfig
@@ -0,0 +1,20 @@
+#
+# Pulse Capture Devices
+#
+# When adding new entries keep the list in alphabetical order
+
+menu Pulse Capture Devices
+
+config IIO_TIECAP
+ tristate TI ECAP Pulse Capture
+ depends on SOC_AM33XX
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+If you say yes here you get support for the TI ECAP peripheral
+in pulse capture mode.
+
+This driver can also be built as a module. If so, the module
+will be called tiecap
+
+endmenu
diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
new file mode 100644
index 000..94d4b00
--- /dev/null
+++ b/drivers/iio/pulse/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO PWM Capture Devices
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_TIECAP) += tiecap.o
diff --git a/drivers/iio/pulse/tiecap.c b/drivers/iio/pulse/tiecap.c
new file mode 100644
index 000..3d21080
--- /dev/null
+++ b/drivers/iio/pulse/tiecap.c
@@ -0,0 +1,493 @@
+/*
+ * ECAP IIO pulse capture driver
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: Matt Porter mpor...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/iio/buffer.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/trigger.h
+#include linux/iio/trigger_consumer.h
+#include linux/iio/triggered_buffer.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+
+#include ../../pwm/pwm-tipwmss.h
+
+/* ECAP regs and bits */
+#define CAP1 0x08
+#define CAP2 0x0c
+#define ECCTL1 0x28
+#define ECCTL1_RUN_FREEBIT(15)
+#define ECCTL1_CAPLDEN BIT(8)
+#define ECCTL1_CAP2POL BIT(2)
+#define ECCTL1_CTRRST1 BIT(1)
+#define ECCTL1_CAP1POL BIT(0)
+#define ECCTL2 0x2a
+#define ECCTL2_SYNCO_SEL_DIS BIT(7)
+#define ECCTL2_TSCTR_FREERUN BIT(4)
+#define ECCTL2_REARM BIT(3)
+#define ECCTL2_STOP_WRAP_2 BIT(1)
+#define ECEINT 0x2c
+#define ECFLG 0x2e
+#define ECCLR 0x30
+#define ECINT_CTRCMP BIT(7)
+#define ECINT_CTRPRD BIT(6)
+#define ECINT_CTROVF BIT(5)
+#define ECINT_CEVT4BIT(4)
+#define ECINT_CEVT3BIT(3)
+#define ECINT_CEVT2BIT(2)
+#define ECINT_CEVT1BIT(1)
+#define ECINT_ALL (ECINT_CTRCMP | \
+ ECINT_CTRPRD | \
+ ECINT_CTROVF | \
+ ECINT_CEVT4 | \
+ ECINT_CEVT3 | \
+ ECINT_CEVT2 | \
+ ECINT_CEVT1)
+
+/* ECAP driver flags */
+#define ECAP_POLARITY_HIGH BIT(1)
+#define ECAP_ENABLED BIT(0)
+
+struct ecap_context {
+ u32 cap1;
+ u32 cap2;
+ u16 ecctl1;
+ u16 ecctl2;
+ u16 eceint;
+};
+
+struct ecap_state {
+ unsigned long flags;
+ unsigned intclk_rate;
+ void __iomem*regs;
+ u32 *buf;
+ struct ecap_context ctx;
+};
+
+#define dev_to_ecap_state(d) iio_priv(dev_to_iio_dev(d))
+
+static const struct iio_chan_spec ecap_channels[] = {
+ {
+ .type = IIO_PULSE,
+ .channel= 0,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 32,
+ .storagebits= 32,
+ .endianness = IIO_LE
[PATCH v2 3/6] iio: enable selection and build of pulse drivers
Add the pulse driver subdirectory when configuring and building IIO. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 5dd0e12..286acc3 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -74,6 +74,7 @@ if IIO_TRIGGER source drivers/iio/trigger/Kconfig endif #IIO_TRIGGER source drivers/iio/pressure/Kconfig +source drivers/iio/pulse/Kconfig source drivers/iio/temperature/Kconfig endif # IIO diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile index 887d390..9a953c9 100644 --- a/drivers/iio/Makefile +++ b/drivers/iio/Makefile @@ -24,5 +24,6 @@ obj-y += light/ obj-y += magnetometer/ obj-y += orientation/ obj-y += pressure/ +obj-y += pulse/ obj-y += temperature/ obj-y += trigger/ -- 1.8.4 -- 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
[PATCH 0/5] IIO pulse capture support for TI ECAP
This series adds support for PWM capture devices within IIO and adds a TI ECAP IIO driver. PWM capture devices are supported using a new IIO pulse channel type. The IIO ECAP driver implements interrupt driven triggered buffer capture only as raw sample reads are not applicable to this hardware. Initially, the driver supports a single pulse width measurement with configurable polarity. The ECAP hardware can support measurement of a complete period and duty cycle but this is not yet implemented. Matt Porter (5): iio: add support for pulse width capture devices iio: pulse: add TI ECAP driver iio: enable selection and build of pulse drivers pwm: enable TI PWMSS if the IIO tiecap driver is selected ARM: dts: AM33XX: Add ecap interrupt properties arch/arm/boot/dts/am33xx.dtsi | 6 + drivers/iio/Kconfig | 1 + drivers/iio/Makefile| 1 + drivers/iio/industrialio-core.c | 1 + drivers/iio/pulse/Kconfig | 20 ++ drivers/iio/pulse/Makefile | 6 + drivers/iio/pulse/tiecap.c | 493 drivers/pwm/Kconfig | 2 +- include/linux/iio/types.h | 1 + 9 files changed, 530 insertions(+), 1 deletion(-) create mode 100644 drivers/iio/pulse/Kconfig create mode 100644 drivers/iio/pulse/Makefile create mode 100644 drivers/iio/pulse/tiecap.c -- 1.8.4 -- 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
[PATCH 2/5] iio: pulse: add TI ECAP driver
Adds support for capturing PWM signals using the TI ECAP peripheral.
This driver supports triggered buffer capture of pulses on multiple
ECAP instances. In addition, the driver supports configurable polarity
of the signal to be captured.
Signed-off-by: Matt Porter mpor...@linaro.org
---
drivers/iio/pulse/Kconfig | 20 ++
drivers/iio/pulse/Makefile | 6 +
drivers/iio/pulse/tiecap.c | 493 +
3 files changed, 519 insertions(+)
create mode 100644 drivers/iio/pulse/Kconfig
create mode 100644 drivers/iio/pulse/Makefile
create mode 100644 drivers/iio/pulse/tiecap.c
diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
new file mode 100644
index 000..9864d4b
--- /dev/null
+++ b/drivers/iio/pulse/Kconfig
@@ -0,0 +1,20 @@
+#
+# Pulse Capture Devices
+#
+# When adding new entries keep the list in alphabetical order
+
+menu Pulse Capture Devices
+
+config IIO_TIECAP
+ tristate TI ECAP Pulse Capture
+ depends on SOC_AM33XX
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+If you say yes here you get support for the TI ECAP peripheral
+in pulse capture mode.
+
+This driver can also be built as a module. If so, the module
+will be called tiecap
+
+endmenu
diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
new file mode 100644
index 000..94d4b00
--- /dev/null
+++ b/drivers/iio/pulse/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO PWM Capture Devices
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_TIECAP) += tiecap.o
diff --git a/drivers/iio/pulse/tiecap.c b/drivers/iio/pulse/tiecap.c
new file mode 100644
index 000..8e2b3a0
--- /dev/null
+++ b/drivers/iio/pulse/tiecap.c
@@ -0,0 +1,493 @@
+/*
+ * ECAP IIO pulse capture driver
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: Matt Porter mpor...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/iio/buffer.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/trigger.h
+#include linux/iio/trigger_consumer.h
+#include linux/iio/triggered_buffer.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+
+#include ../../pwm/pwm-tipwmss.h
+
+/* ECAP regs and bits */
+#define CAP1 0x08
+#define CAP2 0x0c
+#define ECCTL1 0x28
+#define ECCTL1_RUN_FREEBIT(15)
+#define ECCTL1_CAPLDEN BIT(8)
+#define ECCTL1_CAP2POL BIT(2)
+#define ECCTL1_CTRRST1 BIT(1)
+#define ECCTL1_CAP1POL BIT(0)
+#define ECCTL2 0x2a
+#define ECCTL2_SYNCO_SEL_DIS BIT(7)
+#define ECCTL2_TSCTR_FREERUN BIT(4)
+#define ECCTL2_REARM BIT(3)
+#define ECCTL2_STOP_WRAP_2 BIT(1)
+#define ECEINT 0x2c
+#define ECFLG 0x2e
+#define ECCLR 0x30
+#define ECINT_CTRCMP BIT(7)
+#define ECINT_CTRPRD BIT(6)
+#define ECINT_CTROVF BIT(5)
+#define ECINT_CEVT4BIT(4)
+#define ECINT_CEVT3BIT(3)
+#define ECINT_CEVT2BIT(2)
+#define ECINT_CEVT1BIT(1)
+#define ECINT_ALL (ECINT_CTRCMP | \
+ ECINT_CTRPRD | \
+ ECINT_CTROVF | \
+ ECINT_CEVT4 | \
+ ECINT_CEVT3 | \
+ ECINT_CEVT2 | \
+ ECINT_CEVT1)
+
+/* ECAP driver flags */
+#define ECAP_POLARITY_HIGH BIT(1)
+#define ECAP_ENABLED BIT(0)
+
+struct ecap_context {
+ u32 cap1;
+ u32 cap2;
+ u16 ecctl1;
+ u16 ecctl2;
+ u16 eceint;
+};
+
+struct ecap_state {
+ unsigned long flags;
+ unsigned intclk_rate;
+ void __iomem*regs;
+ u32 *buf;
+ struct ecap_context ctx;
+};
+
+#define dev_to_ecap_state(d) iio_priv(dev_to_iio_dev(d))
+
+static const struct iio_chan_spec ecap_channels[] = {
+ {
+ .type = IIO_PULSE,
+ .channel= 0,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 32,
+ .storagebits= 32,
+ .endianness = IIO_LE
[PATCH 3/5] iio: enable selection and build of pulse drivers
Add the pulse driver subdirectory when configuring and building IIO. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 5dd0e12..286acc3 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -74,6 +74,7 @@ if IIO_TRIGGER source drivers/iio/trigger/Kconfig endif #IIO_TRIGGER source drivers/iio/pressure/Kconfig +source drivers/iio/pulse/Kconfig source drivers/iio/temperature/Kconfig endif # IIO diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile index 887d390..9a953c9 100644 --- a/drivers/iio/Makefile +++ b/drivers/iio/Makefile @@ -24,5 +24,6 @@ obj-y += light/ obj-y += magnetometer/ obj-y += orientation/ obj-y += pressure/ +obj-y += pulse/ obj-y += temperature/ obj-y += trigger/ -- 1.8.4 -- 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
[PATCH 5/5] ARM: dts: AM33XX: Add ecap interrupt properties
Add missing interrupt properties to the ecap0, ecap1, and ecap2 nodes. Signed-off-by: Matt Porter mpor...@linaro.org --- arch/arm/boot/dts/am33xx.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 6d95d3d..b4139ba 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -582,6 +582,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48300100 0x80; + interrupts = 31; + interrupt-names = ecap0; ti,hwmods = ecap0; status = disabled; }; @@ -610,6 +612,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48302100 0x80; + interrupts = 47; + interrupt-names = ecap1; ti,hwmods = ecap1; status = disabled; }; @@ -638,6 +642,8 @@ compatible = ti,am33xx-ecap; #pwm-cells = 3; reg = 0x48304100 0x80; + interrupts = 61; + interrupt-names = ecap2; ti,hwmods = ecap2; status = disabled; }; -- 1.8.4 -- 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
[PATCH 4/5] pwm: enable TI PWMSS if the IIO tiecap driver is selected
The IIO TI ECAP driver depends on the TI PWMSS management driver in this subsystem. Enable PWMSS when the IIO TI ECAP driver is selected. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/pwm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 22f2f28..bd3cc65 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -219,7 +219,7 @@ config PWM_TIEHRPWM config PWM_TIPWMSS bool - default y if SOC_AM33XX (PWM_TIECAP || PWM_TIEHRPWM) + default y if SOC_AM33XX (IIO_TIECAP || PWM_TIECAP || PWM_TIEHRPWM) help PWM Subsystem driver support for AM33xx SOC. -- 1.8.4 -- 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
[PATCH 1/5] iio: add support for pulse width capture devices
Add a channel type to support pulse width capture devices.
These devices capture the timing of a PWM signal based on a
configurable trigger
Signed-off-by: Matt Porter mpor...@linaro.org
---
drivers/iio/industrialio-core.c | 1 +
include/linux/iio/types.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index acc911a..6ea0cf8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -70,6 +70,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CCT] = cct,
[IIO_PRESSURE] = pressure,
[IIO_HUMIDITYRELATIVE] = humidityrelative,
+ [IIO_PULSE] = pulse,
};
static const char * const iio_modifier_names[] = {
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 084d882..4fa8840 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -30,6 +30,7 @@ enum iio_chan_type {
IIO_CCT,
IIO_PRESSURE,
IIO_HUMIDITYRELATIVE,
+ IIO_PULSE,
};
enum iio_modifier {
--
1.8.4
--
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
Re: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On Sun, Sep 08, 2013 at 01:12:26PM +0200, Koen Kooi wrote: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. -Matt -- 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
Re: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On Mon, Sep 09, 2013 at 02:51:13PM +0100, Jonathan Austin wrote: Hi Matt, On 09/09/13 14:31, Matt Porter wrote: On Sun, Sep 08, 2013 at 01:12:26PM +0200, Koen Kooi wrote: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. If I've understood Koen correctly then what he's saying is that if you *were* to use the current (before this patch) am335x-bone.dts on a Beagle Bone Black (which would be wrong, as that's not the board you have...) then things would break. I don't see that this patch fixes that - as far as I can see, even after the patch, using am335x-bone.dts with a Bone Black will risk the damage? If so, I don't think this is a 'stable fix' kind of thing, as it doesn't actually fix the problem? It fixes the problem by providing the correct dts for BBB which the vendor tree has had for sometime. In the absence of a specific dts for BBB, it appears everybody (TI and OMAP maintainers, included) has assumed that am335x-bone.dts is correct and safe. I'm sure there's plenty of systems represented in dts/* where you could cause damage by loading another dtb for a similar board from the same SoC family...it's a common risk if you get the wrong dtb with more-or-less arbitrary regulator settings. -Matt Koen - is there a way for a booting kernel to detect which board it is on and avoid any potential damage if someone gives it the wrong DT? Jonny -Matt ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 -- 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
Re: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On Mon, Sep 09, 2013 at 09:59:26AM -0400, Matt Porter wrote: On Mon, Sep 09, 2013 at 02:51:13PM +0100, Jonathan Austin wrote: Hi Matt, On 09/09/13 14:31, Matt Porter wrote: On Sun, Sep 08, 2013 at 01:12:26PM +0200, Koen Kooi wrote: The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI added, so create a common dtsi both can use. IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. MMC support for AM335x still isn't in, so only the LDO change has been added. Signed-off-by: Koen Kooi k...@dominion.thruhere.net Tested-by: Matt Porter matt.por...@linaro.org Works fine for me on tip and 3.11. I did notice a regression in musb (worked on 3.11, now failing to probe but this is not related to your new dts as it happens on am335x-bone.dts too, assuming merge window volatility). One nit, git-am picked up a whitespace error on that extra line at EOF so you should trim that out. Only thing is...for a clear bug like this that will destroy hardware, it should be marked Cc: sta...@vger.kernel.org to be picked up in stable. If I've understood Koen correctly then what he's saying is that if you *were* to use the current (before this patch) am335x-bone.dts on a Beagle Bone Black (which would be wrong, as that's not the board you have...) then things would break. I don't see that this patch fixes that - as far as I can see, even after the patch, using am335x-bone.dts with a Bone Black will risk the damage? If so, I don't think this is a 'stable fix' kind of thing, as it doesn't actually fix the problem? It fixes the problem by providing the correct dts for BBB which the vendor tree has had for sometime. In the absence of a specific dts for BBB, it appears everybody (TI and OMAP maintainers, included) has assumed that am335x-bone.dts is correct and safe. I'm sure there's plenty of systems represented in dts/* where you could cause damage by loading another dtb for a similar board from the same SoC family...it's a common risk if you get the wrong dtb with more-or-less arbitrary regulator settings. Sorry to reply to myself, but I probably didn't make it 100% clear as to why this effectively fixes the problem. Both mainline u-boot *and* the vendor u-boot have findfdt implemented to load an am335x-boneblack.dtb based on board detection. Hopefully this makes it clear why this fixes a bug in the kernel. If you use appended dtb to include the wrong one, well, you shouldn't be using appended dtb. It's a *hack* and loading it separately works fine if you use the U-Boot that ships with BBB or mainline. -Matt Koen - is there a way for a booting kernel to detect which board it is on and avoid any potential damage if someone gives it the wrong DT? Jonny -Matt ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 -- 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
Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
On Mon, Jul 15, 2013 at 07:31:18AM +0200, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@newflow.co.uk writes: Hi, Mark On 08/07/13 13:42, Mark Jackson wrote: On 18/01/13 05:14, Mugunthan V N wrote: On 1/18/2013 3:48 AM, Peter Korsgaard wrote: When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot mode in U-Boot), nothing updates the ethernet hwaddr specified for the CPSW slaves, causing the driver to use a random hwaddr, which is some times troublesome. The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes more sense to default to these rather than random ones. Add a fixup step which adds mac-address dt properties using the efuse addresses if the DTB didn't contain valid ones. Signed-off-by: Peter Korsgaard jac...@sunsite.dk This implementation looks fine. Acked-by: Mugunthan V N mugunthan...@ti.com Tested-by: Mark Jackson mpfj-l...@newflow.co.uk Mark Is this ever going to be put into the mainline code ? Good question. Tony, could you please pick this up? It has been pending since January and has a number of acks. Do you want me to resend? Also working nicely here on 3.11. Tested-by: Matt Porter matt.por...@linaro.org Kevin or Olof: can you apply? Seems to be continuing no response after Ack back in January. -Matt -- 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
Re: [PATCH 1/5] pdev: Fix platform device resource linking
[trimmed my old email] On Wed, Aug 07, 2013 at 10:37:17AM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 7, 2013, at 8:56 AM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 01:27:35PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 1:15 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. Yep, ick, ick, ick is the correct form. Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. It's the same problem really. Another bus type might not fly well. The same device driver should be (in theory) be made to work unchanged either on an OF/ACPI/Fex( :) ) setup. No, that's not quite true, a driver needs to know how to talk to the bus, as that is how it communicates to the hardware. It can be done for different types of busses (see the OHCI USB controller for one example of this), but a driver will have to know what type of bus it is on in order to work properly. In the case of OF ACPI there is no 'bus'. The device is probably integrated in the SoC's silicon, but there is absolutely no way to 'probe' for it's existence; you have to use a-priori knowledge of the SoC's topology in order to configure it (along with any per-board specific information if there is any kind of shared resource configuration - i.e. pinmuxing or something else). Not all busses need to have the aiblity to probe for new devices, that's not a requirement at all. Some of them just know where the devices are at in the driver model, and create the devices for the bus just fine. So don't think that just because of that lack of probing, they should be on the platform bus at all. Platform is for the oh crap, I have no way to bind this to anything else, make it a platform device then. I'm not sure if you remember, but a long time ago when OF started getting into the kernel, there actually was an OCP (On Chip Peripheral) bus, and the switch to platform devices was mandated by kernel people, by their insistance that platform devices would cover every case. See here: http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/0930.html I'm sure Matt Porter can shed some light on the exchange that led to the abandonment of the ocp bus concept. Heh, that OCP support looks a bit antiquated by today's standards. If it helps, http://lkml.indiana.edu/hypermail/linux/kernel/0501.2/0696.html is the posting where Kumar starts taking arch/ppc away from using drivers/ocp/. I can't find any public discussion that led to this, but I recall the common advice was just use platform devices. This was, incidentally, just before the move to arch/powerpc (and DT for all) began. Keep in mind that this is 8ish years ago before embedded was fashionable since we didn't all have Linux machines in our pockets. I suspect that advice was given because nobody cared about platform_device removal and it worked for the use cases at the time. -Matt -- 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
Re: [PATCH 1/5] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM
On Wed, Mar 27, 2013 at 12:59:12PM +, Vaibhav Hiremath wrote: With DT support, where naming convention is based on base-addr and not id, so we should follow TRM/Spec numbering label. This patch changes I2C numbering as per TRM, as I2C0, I2C1 and I2C2. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Benoit Cousson b-cous...@ti.com Acked-by: Matt Porter mpor...@ti.com -Matt -- 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
Re: [PATCH 2/5] ARM: dts: AM33XX: Add default pinctrl binding for I2C device
On Wed, Mar 27, 2013 at 12:59:13PM +, Vaibhav Hiremath wrote: Add pin control binding for I2C device nodes in all board specific DT files (as per current usage), EVM: Both i2c0 and i2c1 EVM-SK and Bone: Only i2c0 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Benoit Cousson b-cous...@ti.com Acked-by: Matt Porter mpor...@ti.com -Matt -- 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
Re: [PATCH 5/5] ARM: dts: AM33XX: Add default pinctrl binding for UART0 device
On Wed, Mar 27, 2013 at 12:59:16PM +, Vaibhav Hiremath wrote:
Add pin control binding for UART0 device nodes in all
board specific DT files.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Except for trivial comments below I'll add my
Acked-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 10 ++
arch/arm/boot/dts/am335x-evm.dts | 10 ++
arch/arm/boot/dts/am335x-evmsk.dts | 10 ++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d623e4..3c4c66f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -43,10 +43,20 @@
0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
Please change this to be uart0 so it all matches.
status = okay;
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 79b3cc8..89e1edd 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -58,10 +58,20 @@
0x15c 0x32 /* spi0_cs0.i2c1_scl PULLUP |
INPUTENABLE | MODE2 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
Also here.
status = okay;
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 21d5a08..0e7f1b8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -58,10 +58,20 @@
0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
status = okay;
};
And here.
-Matt
--
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
Re: [PATCH 3/5] ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM
On Wed, Mar 27, 2013 at 06:29:14PM +0530, Vaibhav Hiremath wrote: With DT support, where naming convention is based on base-addr and not id, so we should follow TRM/Spec numbering label. This patch changes GPIO numbering as per TRM, as gpio0-3. Matt Porter had submitted base patch sometime back but it didn't make it to the mainline - https://patchwork.kernel.org/patch/1433001/ Later DT nodes for gpio based keypad and led driver got merged, so this fix needs to propagate to board dts files as well. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Matt Porter mpor...@ti.com Cc: Benoit Cousson b-cous...@ti.com Thanks for picking this up, Vaibhav. It'll eliminate all the pain people have with the DT not matching the TRM. -Matt -- 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
Re: [PATCH v9 3/9] ARM: edma: add AM33XX support to the private EDMA API
On Thu, Mar 07, 2013 at 08:42:18AM +0200, Andy Shevchenko wrote:
On Wed, Mar 6, 2013 at 6:15 PM, Matt Porter mpor...@ti.com wrote:
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 EDMA
crossbar event mux support. Enables build on OMAP.
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
+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 (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 (ret)
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
Looks like shift = (xbar_chans[i][1] 0x03) 3;
Yes, will update.
+ offset = xbar_chans[i][1] 2;
+ offset = 2;
Is it offset = xbar_chans[i][1] 0xfffc; ?
Yes, will update
+ mux = readl((void *)((u32)xbar + offset));
+ mux = ~(0xff shift);
+ mux |= xbar_chans[i][0] shift;
+ writel(mux, (void *)((u32)xbar + offset));
+ }
--
With Best Regards,
Andy Shevchenko
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
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
Re: [PATCH v9 5/9] dmaengine: edma: Add TI EDMA device tree binding
On Wed, Mar 06, 2013 at 08:24:06PM +, Peter Korsgaard wrote:
Matt == Matt Porter mpor...@ti.com writes:
Matt The binding definition is based on the generic DMA controller
Matt binding.
Matt Signed-off-by: Matt Porter mpor...@ti.com
Matt ---
Matt Documentation/devicetree/bindings/dma/ti-edma.txt | 49
+
Matt 1 file changed, 49 insertions(+)
Matt create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
Matt diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
Matt new file mode 100644
Matt index 000..075a60e3
Matt --- /dev/null
Matt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
Matt @@ -0,0 +1,49 @@
Matt +TI EDMA
Matt +
Matt +Required properties:
Matt +- compatible : ti,edma3
Matt +- ti,hwmods: Name of the hwmods associated to the EDMA
Matt +- ti,edma-regions: Number of regions
Matt +- ti,edma-slots: Number of slots
Matt +- ti,edma-queue-tc-map: List of transfer control to queue mappings
Matt +- ti,edma-queue-priority-map: List of queue priority mappings
Matt +- ti,edma-default-queue: Default queue value
Matt +
Matt +Optional properties:
Matt +- ti,edma-reserved-channels: List of reserved channel regions
Matt +- ti,edma-reserved-slots: List of reserved slot regions
Matt +- ti,edma-xbar-event-map: Crossbar event to channel map
Matt +
Matt +Example:
Matt +
Matt +edma: edma@4900 {
Matt + reg = 0x4900 0x1;
Matt + interrupt-parent = intc;
Matt + interrupts = 12 13 14;
Probably interrupt-parent should be removed from the example as well to
match am33xx.dtsi
On second thought, I'm not sure we're going to get any direction on this
one so let's just do what feels right and make it reflect common usage
like you suggested.
Thanks,
Matt
--
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
Re: [PATCH v9 3/9] ARM: edma: add AM33XX support to the private EDMA API
On Tue, Mar 12, 2013 at 06:45:46AM +, Sekhar Nori wrote:
On 3/6/2013 9:45 PM, Matt Porter wrote:
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 EDMA
crossbar event mux support. Enables build on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/common/edma.c | 300
++--
arch/arm/mach-omap2/Kconfig|1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 292 insertions(+), 10 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a1db6cd..e68ac38 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -1369,31 +1376,278 @@ 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)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* 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)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* 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)
+{
It will be nice to separate the xbar feature from DT'fication of the
existing driver. Right now because of the mix the patch has become
pretty big and its becoming tough to review in isolation.
Sure, I'll do that on v10.
+ 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 (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 (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)
+ return ret;
+ pdata-n_slot = value;
+
+ pdata-n_cc = 1;
+ pdata-n_tc = 3;
Will this mean the DT portion of this driver cannot be used on SoCs
where there are two CCs like DA850? If you are hard-coding
Re: [PATCH v9 5/9] dmaengine: edma: Add TI EDMA device tree binding
On Tue, Mar 12, 2013 at 06:53:03AM +, Sekhar Nori wrote:
On 3/6/2013 9:45 PM, Matt Porter wrote:
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
Okay the bindings the documented after they are used leading to some
confusion. This patch should be moved up the series. As I noted in my
other e-mail, some of these bindings are not really hardware description
and need to be re-looked.
Sure, I'll reorder it.
-Matt
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49
+
1 file changed, 49 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..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+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 {
+ 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;
+};
--
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
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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 c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,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;
+ };
Any specific reason why you did not add edma entry here as well?
Yes, I've answered this one before and I think this illustrates a need
for a comment in the .dtsi. mmc3 edma event are on the crossbar and so
the event that will be mapped is system-specific. Since Luca is still
working on DT support for WiLink, there's no way to show an example of
how this is used upstream as that's the only in-kernel user.
I have a test driver I've cited in the postings that shows how the
crossbar is configured via the board .dts. It doesn't belong in the
.dtsi, however, in this case. When WiLink DT support is ready we can
have an entry in the am335x-evmsk.dts that shows this case.
Also, I wonder why interrupt property is not coming here, I understand
That hwmod is filling the gap here; but I would still recommend you to
complete
The DT node, as we only support DT boot.
Yeah, I only added needed properties so as to not confuse people as to
where the interrupt resources are coming from. If you feel strongly
about this I don't have
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote:
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 7:43 PM
To: Hiremath, Vaibhav
Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List;
Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List;
Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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 c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,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;
+ };
Any specific reason why you did not add edma entry here as well?
Yes
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 09:46:56AM -0500, Matt Porter wrote: On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: 2. And MMC rootFS mount is __not__ working for me. 3. I get following error message - [2.118207] omap_hsmmc mmc.3: unable to obtain RX DMA engine channel 25 See below, you don't have CONFIG_EDMA on most likely. That's CONFIG_TI_EDMA, of course. -Matt -- 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
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:53:51PM +, Vaibhav Hiremath wrote:
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 8:17 PM
To: Hiremath, Vaibhav
Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree
Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux
ARM Kernel List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote:
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter,
Matt
Sent: Thursday, March 07, 2013 7:43 PM
To: Hiremath, Vaibhav
Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List;
Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List;
Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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 c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,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
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:59:42PM +, Vaibhav Hiremath wrote: -Original Message- From: Hiremath, Vaibhav Sent: Thursday, March 07, 2013 8:24 PM To: Porter, Matt Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 8:17 PM To: Hiremath, Vaibhav Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 7:43 PM To: Hiremath, Vaibhav Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 9:47 AM To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support snip I believe you meant CONFIG_TI_EDMA right? Yes, I just enabled it and the result is still same. [root@arago /]# dmesg | grep -ir mmc [0.506844] vmmc: 1800 -- 3300 mV at 3300 mV [0.506970] vmmc: supplied by vbat [root@arago /]# [root@arago /]# [root@arago /]# dmesg | grep -ir dma [0.217063] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.236321] platform 4900.edma: alias fck already exists [0.236360] platform 4900.edma: alias fck already exists [0.236381] platform 4900.edma: alias fck already exists [0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver [0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [root@arago /]# [root@arago /]# I have applied below patches from your recent post [2/2] ARM: dts: add AM33XX MMC support [1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits [v4,3/3] mmc: davinci: get SG segment limits with dma_get_slave_sg_limits() [v4,2/3] dma: edma: add device_slave_sg_limits() support [v4,1/3] dmaengine: add dma_get_slave_sg_limits() [v9,9/9] ARM: dts: add AM33XX SPI DMA support [v9,8/9] spi: omap2-mcspi: add generic DMA request support to the DT binding [v9,7/9] spi: omap2-mcspi: convert to dma_request_slave_channel_compat() [v9,6/9] ARM: dts: add AM33XX EDMA support [v9,5/9] dmaengine: edma: Add TI EDMA device tree binding [v9,4/9] dmaengine: edma: enable build for AM33XX [v9,3/9] ARM: edma: add AM33XX support to the private EDMA API [v9,2/9] ARM: edma: remove unused transfer controller handlers [v9,1/9] ARM: davinci: move private EDMA API to arm/common [v3,2/2] mmc: omap_hsmmc: add generic DMA request support to the DT binding [v3,1/2] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() Am I missing anything here? Yes, you missed the http://www.spinics.net/lists/arm-kernel/msg227886.html dependency mentioned first in the cover letter. -Matt -- 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
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 03:50:01PM +, Vaibhav Hiremath wrote: -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 8:34 PM To: Hiremath, Vaibhav Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP List; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 02:59:42PM +, Vaibhav Hiremath wrote: -Original Message- From: Hiremath, Vaibhav Sent: Thursday, March 07, 2013 8:24 PM To: Porter, Matt Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 8:17 PM To: Hiremath, Vaibhav Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 7:43 PM To: Hiremath, Vaibhav Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux- omap- ow...@vger.kernel.org] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 9:47 AM To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support snip I believe you meant CONFIG_TI_EDMA right? Yes, I just enabled it and the result is still same. [root@arago /]# dmesg | grep -ir mmc [0.506844] vmmc: 1800 -- 3300 mV at 3300 mV [0.506970] vmmc: supplied by vbat [root@arago /]# [root@arago /]# [root@arago /]# dmesg | grep -ir dma [0.217063] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.236321] platform 4900.edma: alias fck already exists [0.236360] platform 4900.edma: alias fck already exists [0.236381] platform 4900.edma: alias fck already exists [0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver [0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [root@arago /]# [root@arago /]# I have applied below patches from your recent post [2/2] ARM: dts: add AM33XX MMC support [1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits [v4,3/3] mmc: davinci: get SG segment limits with dma_get_slave_sg_limits() [v4,2/3] dma: edma: add device_slave_sg_limits() support [v4,1/3] dmaengine: add dma_get_slave_sg_limits() [v9,9/9] ARM: dts: add AM33XX SPI DMA support [v9,8/9] spi: omap2-mcspi: add generic DMA request support to the DT binding [v9,7/9] spi: omap2-mcspi: convert to dma_request_slave_channel_compat() [v9,6/9] ARM: dts: add AM33XX EDMA support [v9,5/9] dmaengine: edma: Add TI EDMA device tree binding [v9,4/9] dmaengine: edma: enable build for AM33XX [v9,3/9] ARM: edma: add AM33XX support to the private EDMA API [v9,2/9] ARM: edma: remove unused transfer controller handlers [v9,1/9] ARM: davinci: move private EDMA API to arm/common [v3,2/2] mmc: omap_hsmmc: add generic DMA request support to the DT binding [v3,1/2] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() Am I missing anything here? Yes, you missed the http://www.spinics.net/lists/arm-kernel/msg227886.html dependency mentioned first in the cover letter. Matt, I manually edited the file with above patch and result is still the same. Can you point me to branch where you have tested MMC code? git://github.com/ohporter/linux.git edma-dmaengine-am33xx-mmc-v1 omap2plus_defconfig + CONFIG_TI_EDMA I just doublechecked MMC rootfs on bone and evmsk as it's the standard smoke test. My EVM is intermittent now so trying to coax it to power up
Re: [PATCH v2 0/3] omap_hsmmc DT DMA Client support
On Tue, Mar 05, 2013 at 09:26:01PM +, Arnd Bergmann wrote: On Tuesday 05 March 2013, Matt Porter wrote: Changes since v1: - rebase to 3.9-rc1, previous dependencies upstream This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The description seems stale, but the patches all look good to me. I guess they can now get merged in any order. Acked-by: Arnd Bergmann a...@arndb.de Yes, missed updating that to indicating that those are now in 3.9-rc1. -Matt -- 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
Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case
On Wed, Mar 06, 2013 at 07:12:29PM +0530, Balaji T K wrote:
On Wednesday 06 March 2013 02:43 AM, Matt Porter wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.
Hi Matt,
Could you please drop this patch from the current series,
since this patch causes regression on omap3,4 platform
which are not yet dma dt adapted.
It is best to send this patch along with Jon Hunter dma dt series,
which adds dt dma support and mmc dma data. DMA dt series is needed
any way before hwmod cleanup can happen.
*sigh* ok, I should have never split this stuff out from the am33xx
series. Will do.
-Matt
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_conf_bus_power(host);
-res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
-if (!res) {
-dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
-ret = -ENXIO;
-goto err_irq;
-}
-tx_req = res-start;
+if (!pdev-dev.of_node) {
+res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
+if (!res) {
+dev_err(mmc_dev(host-mmc), cannot get DMA TX
channel\n);
+ret = -ENXIO;
+goto err_irq;
+}
+tx_req = res-start;
-res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
-if (!res) {
-dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
-ret = -ENXIO;
-goto err_irq;
+res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
+if (!res) {
+dev_err(mmc_dev(host-mmc), cannot get DMA RX
channel\n);
+ret = -ENXIO;
+goto err_irq;
+}
+rx_req = res-start;
}
-rx_req = res-start;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
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
Re: [PATCH v8 6/9] ARM: dts: add AM33XX EDMA support
On Wed, Mar 06, 2013 at 04:19:58AM +, Kumar, Anil wrote:
Hi,
On Wed, Mar 06, 2013 at 02:23:12, Porter, Matt wrote:
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter mpor...@ti.com
---
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 0957645..aaf44122 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;
Is it really need of interrupt-parent = intc here ?
as this property is already with root node.
I am taking reference of 3.9-rc1
You're correct. It's inherited from the parent node so I'll drop it out.
I also noted that the cpsw node has this wrong so I'll send a patch to
address that separately.
-Matt
--
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
[PATCH v3 0/2] omap_hsmmc DT DMA Client support
Changes since v2: - dropped skip platform_get_resource_byname() patch Changes since v1: - rebase to 3.9-rc1, previous dependencies upstream This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers and the dma_request_slave_channel_compat() wrapper to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. Matt Porter (2): mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: add generic DMA request support to the DT binding .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +++- drivers/mmc/host/omap_hsmmc.c | 10 ++-- 2 files changed, 33 insertions(+), 3 deletions(-) -- 1.7.9.5 -- 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
[PATCH v3 1/2] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports platforms booting
with or without DT populated.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Arnd Bergmann a...@arndb.de
---
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
--
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
[PATCH v3 2/2] 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 mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +++-
1 file changed, 25 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..8c8908a 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,29 @@ 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: List of DMA specifiers with the controller specific format
+as described in the generic DMA client binding. A tx and rx
+specifier is required.
+dma-names: List of DMA request names. These strings correspond
+1:1 with the DMA specifiers listed in dmas. The string naming is
+to be rx and tx for RX and TX DMA requests, respectively.
+
+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 +51,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
--
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
[PATCH v9 0/9] DMA Engine support for AM33XX
Changes since v8: - Removed edma node interrupt-parent property, it is inherited Changes since v7: - Dropped dmaengine compat() patch. It is upstream. - Submitted edma_alloc_slot() error checking bug fix separately, now a dependency - Fixed bisect issues due to 3/10 hunks that went into 1/10 - Fixed incorrect IS_ERRVALUE() use in 3/10 Changes since v6: - Converted edma_of_read_*() to wrappers around of_property_read_*() - Fixed wording on the omap-spi generic DMA properties - Added comment/check to clarify that the driver only supports a single EDMA instance when booting from DT Changes since v5: - Dropped mmc portion and moved it to a separate series - Incorporate corrected version of dma_request_slave_channel_compat() - Fix #defines and enablement of TI_PRIV_EDMA option Changes since v4: - Fixed debug section mismatch in private edma api [01/14] - Respun format-patch to catch the platform_data/edma.h rename [01/14] - Removed address/size-cells from the EDMA binding [05/14] 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.9-rc1 and the following patches: - edma private api error check fix from http://www.spinics.net/lists/arm-kernel/msg227886.html 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 the upstream generic DT DMA helpers are leveraged to register EDMA DMAC with the of_dma framework. SPI (and MMC in a separate series) are supported using the upstream dma_request_slave_channel_compat() dmaengine call that allows compatibility with !DT platforms. With this series both BeagleBone and the AM335x EVM have working SPI DMA support (and MMC support with the separate MMC series). 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. Note that MMC can only be tested with a separate MMC dmaengine/DT series applied. 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 (9): 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 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 | 49 +++ Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- arch/arm/Kconfig
[PATCH v9 3/9] 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 EDMA
crossbar event mux support. Enables build on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/common/edma.c | 300 ++--
arch/arm/mach-omap2/Kconfig|1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 292 insertions(+), 10 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a1db6cd..e68ac38 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -1369,31 +1376,278 @@ 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)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* 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)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* 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 (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 (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)
+ return ret;
+ pdata-n_slot = value;
+
+ pdata-n_cc = 1;
+ pdata-n_tc = 3;
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata-rsv = rsv_info;
+
+ /* Build the reserved channel/slots arrays */
+ prop = of_find_property(node, ti,edma-reserved-channels, sz);
+ if (prop) {
+ rsv_chans = devm_kzalloc(dev,
+sz/sizeof(s16) + 2*sizeof(s16
[PATCH v9 2/9] 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 mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
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 dcaeb8e..a1db6cd 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)
@@ -1541,23 +1521,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
--
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
[PATCH v9 4/9] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter mpor...@ti.com --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 80b6997..3b7ea20 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -222,7 +222,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 -- 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
[PATCH v9 5/9] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 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..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+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 {
+ 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
--
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
[PATCH v9 9/9] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter mpor...@ti.com --- 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 cbea5ab..c3c781a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -327,6 +327,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; }; @@ -338,6 +343,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 -- 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
[PATCH v9 8/9] 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 mpor...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 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 specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed 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,17 @@ 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
--
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
[PATCH v9 7/9] 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 mpor...@ti.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/spi/spi-omap2-mcspi.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 893c3d7..38d0915 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);
@@ -1240,12 +1252,13 @@ 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);
+ sprintf(dma_rx_ch_name, rx%d, i);
dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
+ dma_rx_ch_name);
if (!dma_res) {
dev_dbg(pdev-dev, cannot get DMA RX channel\n);
status = -ENODEV;
@@ -1253,9 +1266,9 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
}
mcspi-dma_channels[i].dma_rx_sync_dev = dma_res-start;
- sprintf(dma_ch_name, tx%d, i);
+ sprintf(dma_tx_ch_name, tx%d, i);
dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
+ dma_tx_ch_name);
if (!dma_res) {
dev_dbg(pdev-dev, cannot get DMA TX channel\n);
status = -ENODEV;
--
1.7.9.5
--
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
[PATCH v9 6/9] 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 mpor...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0957645..cbea5ab 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,25 @@
reg = 0x4820 0x1000;
};
+ edma: edma@4900 {
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ reg = 0x4900 0x1,
+ 0x44e10f90 0x10;
+ 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
--
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
[PATCH v9 1/9] 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.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
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|6 +-
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 +-
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
.../mach = include/linux/platform_data}/edma.h| 89 +---
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 |5 +-
23 files changed, 33 insertions(+), 104 deletions(-)
rename arch/arm/{mach-davinci/dma.c = common/edma.c} (99%)
rename {arch/arm/mach-davinci/include/mach =
include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..cb80a4d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -956,6 +956,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 9353184..c3a4e9c 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -17,3 +17,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 dc8dd0d..9643c50 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -11,3 +11,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 45b7c71..dcaeb8e 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include linux/io.h
#include linux/slab.h
-#include mach/edma.h
+#include linux/platform_data/edma.h
/* 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 4f41602..10c9efd 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
+#include linux/platform_data/edma.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include mach/irqs.h
-#include mach/edma.h
#include mach/mux.h
#include mach/cp_intc.h
#include mach/tnetv107x.h
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 linux/platform_device.h
#include linux/spi/spi.h
#include linux/platform_data/davinci_asp.h
+#include linux/platform_data/edma.h
#include linux/platform_data/keyscan-davinci.h
#include mach/hardware.h
-#include mach/edma.h
#include media/davinci/vpfe_capture.h
#include media/davinci/vpif_types.h
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
Re: [PATCH v9 5/9] dmaengine: edma: Add TI EDMA device tree binding
On Wed, Mar 06, 2013 at 08:24:06PM +, Peter Korsgaard wrote:
Matt == Matt Porter mpor...@ti.com writes:
Matt The binding definition is based on the generic DMA controller
Matt binding.
Matt Signed-off-by: Matt Porter mpor...@ti.com
Matt ---
Matt Documentation/devicetree/bindings/dma/ti-edma.txt | 49
+
Matt 1 file changed, 49 insertions(+)
Matt create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
Matt diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
Matt new file mode 100644
Matt index 000..075a60e3
Matt --- /dev/null
Matt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
Matt @@ -0,0 +1,49 @@
Matt +TI EDMA
Matt +
Matt +Required properties:
Matt +- compatible : ti,edma3
Matt +- ti,hwmods: Name of the hwmods associated to the EDMA
Matt +- ti,edma-regions: Number of regions
Matt +- ti,edma-slots: Number of slots
Matt +- ti,edma-queue-tc-map: List of transfer control to queue mappings
Matt +- ti,edma-queue-priority-map: List of queue priority mappings
Matt +- ti,edma-default-queue: Default queue value
Matt +
Matt +Optional properties:
Matt +- ti,edma-reserved-channels: List of reserved channel regions
Matt +- ti,edma-reserved-slots: List of reserved slot regions
Matt +- ti,edma-xbar-event-map: Crossbar event to channel map
Matt +
Matt +Example:
Matt +
Matt +edma: edma@4900 {
Matt + reg = 0x4900 0x1;
Matt + interrupt-parent = intc;
Matt + interrupts = 12 13 14;
Probably interrupt-parent should be removed from the example as well to
match am33xx.dtsi
I'm not sure what the DT maintainers want here. Full context within the
example or the actual real usage where it's typically inherited.
Grant or Rob, any thoughts?
-Matt
--
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
[PATCH 0/2] AM33xx mmc support
This series enable MMC support on AM33xx platforms. Support for platforms incorporating the EDMA DMAC is added using the dma_get_slave_sg_limits() api. AM33xx DTS supported is added for Beaglebone, AM335x-EVM, and AM335x-EVMSK. These patches were split out from the v5 version of the AM33xx DMA series and split from the generic DT/dmanegine omap_hsmmc changes. The series has the following dependencies: - edma private api error check fix http://www.spinics.net/lists/arm-kernel/msg227886.html - DMA Engine support for AM33XX http://www.spinics.net/lists/linux-omap/msg87634.html - omap_hsmmc DT DMA Client support http://www.spinics.net/lists/linux-omap/msg87623.html - dmaengine: add slave sg transfer limits api https://lkml.org/lkml/2013/3/6/462 Matt Porter (2): mmc: omap_hsmmc: set max_segs based on dma engine limits ARM: dts: add AM33XX MMC support 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 drivers/mmc/host/omap_hsmmc.c |8 5 files changed, 57 insertions(+) -- 1.7.9.5 -- 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
[PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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 c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,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
--
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
[PATCH 1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits
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_slave_sg_limits() API. If the max_nr_segs limit is present, the value is used to configure mmc-max_segs appropriately. Signed-off-by: Matt Porter mpor...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- drivers/mmc/host/omap_hsmmc.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e79b12d..f74d2ef 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 dma_slave_sg_limits *dma_sg_limits; struct pinctrl *pinctrl; match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev); @@ -1935,6 +1936,13 @@ static int omap_hsmmc_probe(struct platform_device *pdev) goto err_irq; } + /* Some DMA Engines only handle a limited number of SG segments */ + dma_sg_limits = dma_get_slave_sg_limits(host-rx_chan, + DMA_SLAVE_BUSWIDTH_4_BYTES, + mmc-max_blk_size / 4); + if (dma_sg_limits dma_sg_limits-max_seg_nr) + mmc-max_segs = dma_sg_limits-max_seg_nr; + /* Request IRQ for MMC operations */ ret = request_irq(host-irq, omap_hsmmc_irq, 0, mmc_hostname(mmc), host); -- 1.7.9.5 -- 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
[PATCH v8 6/9] 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 mpor...@ti.com
---
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 0957645..aaf44122 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
--
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
[PATCH v8 9/9] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter mpor...@ti.com --- 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 aaf44122..a13d710 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -328,6 +328,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; }; @@ -339,6 +344,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 -- 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
[PATCH v8 8/9] 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 mpor...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 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 specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed 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,17 @@ 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
--
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
[PATCH v8 5/9] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 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..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+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 {
+ 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
--
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
[PATCH v8 7/9] 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 mpor...@ti.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/spi/spi-omap2-mcspi.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 893c3d7..38d0915 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);
@@ -1240,12 +1252,13 @@ 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);
+ sprintf(dma_rx_ch_name, rx%d, i);
dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
+ dma_rx_ch_name);
if (!dma_res) {
dev_dbg(pdev-dev, cannot get DMA RX channel\n);
status = -ENODEV;
@@ -1253,9 +1266,9 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
}
mcspi-dma_channels[i].dma_rx_sync_dev = dma_res-start;
- sprintf(dma_ch_name, tx%d, i);
+ sprintf(dma_tx_ch_name, tx%d, i);
dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
+ dma_tx_ch_name);
if (!dma_res) {
dev_dbg(pdev-dev, cannot get DMA TX channel\n);
status = -ENODEV;
--
1.7.9.5
--
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
[PATCH v8 4/9] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter mpor...@ti.com --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 80b6997..3b7ea20 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -222,7 +222,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 -- 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
[PATCH v8 2/9] 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 mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
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 dcaeb8e..a1db6cd 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)
@@ -1541,23 +1521,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
--
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
[PATCH v8 0/9] DMA Engine support for AM33XX
Changes since v7: - Dropped dmaengine compat() patch. It is upstream. - Submitted edma_alloc_slot() error checking bug fix separately, now a dependency - Fixed bisect issues due to 3/10 hunks that went into 1/10 - Fixed incorrect IS_ERRVALUE() use in 3/10 Changes since v6: - Converted edma_of_read_*() to wrappers around of_property_read_*() - Fixed wording on the omap-spi generic DMA properties - Added comment/check to clarify that the driver only supports a single EDMA instance when booting from DT Changes since v5: - Dropped mmc portion and moved it to a separate series - Incorporate corrected version of dma_request_slave_channel_compat() - Fix #defines and enablement of TI_PRIV_EDMA option Changes since v4: - Fixed debug section mismatch in private edma api [01/14] - Respun format-patch to catch the platform_data/edma.h rename [01/14] - Removed address/size-cells from the EDMA binding [05/14] 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.9-rc1 and the following patches: - edma private api error check fix from http://www.spinics.net/lists/arm-kernel/msg227886.html 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 SPI DMA support (and MMC support with the separate MMC series). 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-v7 has the complete series, dependencies, and some test drivers/defconfigs. Note that MMC can only be tested with a separate MMC dmaengine/DT series applied. 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 (9): 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 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 | 49 +++ Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- arch/arm/Kconfig |1
[PATCH v8 3/9] 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 EDMA
crossbar event mux support. Enables build on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/common/edma.c | 300 ++--
arch/arm/mach-omap2/Kconfig|1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 292 insertions(+), 10 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a1db6cd..e68ac38 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -1369,31 +1376,278 @@ 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)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* 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)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* 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 (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 (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)
+ return ret;
+ pdata-n_slot = value;
+
+ pdata-n_cc = 1;
+ pdata-n_tc = 3;
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata-rsv = rsv_info;
+
+ /* Build the reserved channel/slots arrays */
+ prop = of_find_property(node, ti,edma-reserved-channels, sz);
+ if (prop) {
+ rsv_chans = devm_kzalloc(dev,
+sz/sizeof(s16) + 2*sizeof(s16
[PATCH v8 1/9] 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.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
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|6 +-
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 +-
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
.../mach = include/linux/platform_data}/edma.h| 89 +---
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 |5 +-
23 files changed, 33 insertions(+), 104 deletions(-)
rename arch/arm/{mach-davinci/dma.c = common/edma.c} (99%)
rename {arch/arm/mach-davinci/include/mach =
include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..cb80a4d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -956,6 +956,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 9353184..c3a4e9c 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -17,3 +17,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 dc8dd0d..9643c50 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -11,3 +11,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 45b7c71..dcaeb8e 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include linux/io.h
#include linux/slab.h
-#include mach/edma.h
+#include linux/platform_data/edma.h
/* 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 4f41602..10c9efd 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
+#include linux/platform_data/edma.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include mach/irqs.h
-#include mach/edma.h
#include mach/mux.h
#include mach/cp_intc.h
#include mach/tnetv107x.h
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 linux/platform_device.h
#include linux/spi/spi.h
#include linux/platform_data/davinci_asp.h
+#include linux/platform_data/edma.h
#include linux/platform_data/keyscan-davinci.h
#include mach/hardware.h
-#include mach/edma.h
#include media/davinci/vpfe_capture.h
#include media/davinci/vpif_types.h
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
[PATCH v2 0/3] omap_hsmmc DT DMA Client support
Changes since v1: - rebase to 3.9-rc1, previous dependencies upstream This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. Matt Porter (2): mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: add generic DMA request support to the DT binding Santosh Shilimkar (1): mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +- drivers/mmc/host/omap_hsmmc.c | 38 2 files changed, 48 insertions(+), 16 deletions(-) -- 1.7.9.5 -- 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
[PATCH v2 1/3] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports platforms booting
with or without DT populated.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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
--
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
[PATCH v2 3/3] 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 mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +++-
1 file changed, 25 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..8c8908a 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,29 @@ 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: List of DMA specifiers with the controller specific format
+as described in the generic DMA client binding. A tx and rx
+specifier is required.
+dma-names: List of DMA request names. These strings correspond
+1:1 with the DMA specifiers listed in dmas. The string naming is
+to be rx and tx for RX and TX DMA requests, respectively.
+
+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 +51,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
--
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
[PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case
From: Santosh Shilimkar santosh.shilim...@ti.com
MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_conf_bus_power(host);
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
- ret = -ENXIO;
- goto err_irq;
- }
- tx_req = res-start;
+ if (!pdev-dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA TX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ tx_req = res-start;
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
- ret = -ENXIO;
- goto err_irq;
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA RX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ rx_req = res-start;
}
- rx_req = res-start;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
--
1.7.9.5
--
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
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote:
Hi Matt,
This version introduces build/bisect issues.
Ok, see later comment which addresses this...
On 2/1/2013 11:52 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include linux/io.h
#include linux/slab.h
-#include mach/edma.h
+#include linux/platform_data/edma.h
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
This needs linux/of.h to be included in this file.
+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);
of_address_to_resource() needs linux/of_address.h
+ if (IS_ERR_VALUE(ret))
This needs linux/err.h
+ 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;
There is no member xbar_chans ATM. It seems to be introduced in 03/10.
+
+static struct of_dma_filter_info edma_filter_info = {
of_dma_filter_info needs linux/of_dma.h.
+ .filter_fn = edma_filter_fn,
edma_filter_fn needs linux/edma.h
BTW, I am not sure if you really intended to introduce EDMA DT support
in this patch. I thought 1/10 was supposed to just move EDMA private API
to a common place. If you really want to introduce DT support as well,
that should be noted in the description. I think it is better done in a
later patch.
This was a complete fubared rebase for this patch. As you noticed, I
got hunks from 3/10 in there and the bisect test didn't run so it was
missed. I've got this fixed up for v8 which address all these comments
that stem from that issue.
diff --git a/sound/soc/davinci/davinci-sffsdr.c
b/sound/soc/davinci/davinci-sffsdr.c
@@ -17,6 +17,7 @@
#include linux/timer.h
#include linux/interrupt.h
#include linux/platform_device.h
+#include linux/platform_data/edma.h
#include linux/gpio.h
#include sound/core.h
#include sound/pcm.h
@@ -28,12 +29,14 @@
#include asm/plat-sffsdr/sffsdr-fpga.h
#endif
-#include mach/edma.h
#include ../codecs/pcm3008.h
#include davinci-pcm.h
#include davinci-i2s.h
+#define DAVINCI_DMA_MCBSP_TX 2
+#define DAVINCI_DMA_MCBSP_RX 3
+
/*
* CLKX and CLKR are the inputs for the Sample Rate Generator.
* FSX and FSR are outputs, driven by the sample Rate Generator.
@@ -124,7 +127,7 @@ static struct resource sffsdr_snd_resources[] = {
static struct evm_snd_platform_data sffsdr_snd_data = {
.tx_dma_ch = DAVINCI_DMA_MCBSP_TX,
- .rx_dma_ch = DAVINCI_DMA_MCBSP_RX,
+ .rx_dma_ch = DAVINCI_DMA_MCBAP_RX,
Typo here. Should be DAVINCI_DMA_MCBSP_RX. Unfortunately
davinci-sffsdr.c seems to be broken already.
Ok, fixed..definitely shouldn't break it more.
-Matt
--
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
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 09, 2013 at 08:08:50PM +, Russell King wrote: On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote: On 2/1/2013 11:52 PM, Matt Porter wrote: + ret = of_address_to_resource(node, 1, res); of_address_to_resource() needs linux/of_address.h + if (IS_ERR_VALUE(ret)) This needs linux/err.h More importantly, is this the correct way to check for errors from of_address_to_resource() ? Grepping the source shows that either less than 0 or non-zero are the commonly used conditions here. Yes, it's not correct. Fixed to check for non-zero/zero in the two cases where of_address_to_resource() is used. -Matt -- 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
Re: [PATCH 0/3] omap_hsmmc DT DMA Client support
On Wed, Feb 06, 2013 at 01:41:06PM +0100, Lars Poeschel wrote: Hi Matt! At first thanks for you efforts on DMA Engine on AM33XX. On Friday 01 February 2013 at 22:01:17, Matt Porter wrote: This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The series depends on the following patches: - dmaengine DT support and edma dmaengine driver fix from the git://git.infradead.org/users/vkoul/slave-dma.git next branch - dma_request_slave_channel_compat() support https://patchwork.kernel.org/patch/2081671/ The series with all dependencies can be found at https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1 I cloned your github repository and did short testing with it. I get the following error when the kernel mounts my sd-card: Starting udev [5.884738] udevd[72]: starting version 182 [8.879651] edma-dma-engine edma-dma-engine.0: Exceeded max SG segments 33 Hi Lars, I left it somewhat ambiguous as to what this series claims to support, sorry about that. This series, by itself, supports only platforms using SDMA (omap 2/3/4/5 assuming you add the appropriate DMA dts bits). This is only part of what am33xx requires for working mmc support. I've also posted v3 of dmaengine slave sg caps series at https://lkml.org/lkml/2013/2/4/561 I have to rebase the am33xx specific bits for omap_hsmmc on top of that and post. That was previously all contained in one series but I didn't want to block omap2/3/4/5 from working DMA on DT support until the api change is resolved for am33xx. -Matt [8.887377] omap_hsmmc mmc.3: prep_slave_sg() failed [8.892588] omap_hsmmc mmc.3: MMC start dma failure [8.897725] mmcblk0: unknown error -1 sending read/write command, card status 0x900 [8.905889] end_request: I/O error, dev mmcblk0, sector 17039 [8.911926] end_request: I/O error, dev mmcblk0, sector 17047 [8.917934] end_request: I/O error, dev mmcblk0, sector 17055 [8.923960] end_request: I/O error, dev mmcblk0, sector 17063 [8.929967] end_request: I/O error, dev mmcblk0, sector 17071 [8.935988] end_request: I/O error, dev mmcblk0, sector 17079 [8.942010] end_request: I/O error, dev mmcblk0, sector 17087 [8.948016] end_request: I/O error, dev mmcblk0, sector 17095 [8.954037] end_request: I/O error, dev mmcblk0, sector 17103 [8.960043] end_request: I/O error, dev mmcblk0, sector 17111 [9.020919] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3764: inode #8: block 239: comm mount: unable to read itable block [9.033514] EXT4-fs (mmcblk0p2): no journal found [9.043799] kjournald starting. Commit interval 5 seconds [9.049589] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, running e2fsck is recommended [9.060940] EXT3-fs (mmcblk0p2): using internal journal [9.066437] EXT3-fs (mmcblk0p2): recovery complete [9.071460] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode After that the filesystem on the sd-card has an error that I have to fix with e2fsck. As rootfs I use a nfsroot. In my quick tests, same setup, I don't get any error on edma-dmaengine- am33xx-v5 branch of your repository. If you need any further information, let me now. Regards, Lars ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- 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
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 12:49:06PM +, Russell King wrote: On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote: * Matt Porter mpor...@ti.com [130201 10:25]: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? Yes, it should, but just like OMAP, there's a conversion effort that needs to be gone through. It has one point - and only one point - which allows its continued existence under arch/arm, and that is it already exists there. If it was new code, the answer would be a definite NACK, but it isn't. It's pre-existing code which is already in mainline. It's merely being moved. Another plus point for it is that there does seem to be a DMA engine driver for it, so hopefully we'll see it killed off in arch/arm soon. That's definitely the plan. I was able to start this effort independently by converting the Davinci mmc and spi drivers to dmaengine before I took this step. I've got the next micro-step of addressing omap_hsmmc in process (pending on agreement on a dmaengine api change with Vinod), cleaning up the mcasp driver is also pending this series so that it can also be converted to dmaengine. Once mcasp (or davinci audio) is converted, we're rid of all the in-kernel users of the private API and can get rid of this...which also is helping clean up mach-davinci, of course. If I can get your ack on this patch that should move things along to these next steps. Thanks, Matt -- 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
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 12:01:37AM +, Sergei Shtylyov wrote: Hello. On 01-02-2013 22:59, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in plat-omap/dma.c. The actual dmaengine driver is in drivers/dma/edma.c as a wrapper around this...same way OMAP DMA engine conversion is being done. Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed that, instead of waiting indefinitely for TI to convert it to drivers/dma/ directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh. That is a shame. Yeah, I've pointed out that I was doing this exactly the same way as was acceptable for the OMAP DMA conversion since it was in RFC. The reasons are sound since in both cases, we have many drivers to convert that need to continue using the private DMA APIs. In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't know them well). Well, it's pretty clear to me now that there's good reason for it not landing in arch/arm/ so the obvious path is to do the dmaengine conversion and put it in drivers/dma/ if it's really a generic dma engine. I'm not sure why you express concern over the dma engine api not fitting with CPPI 4.1? If it doesn't work, work with Vinod to fix the api. It's expected, I'm working on dmaengine API changes right now to deal with a limitation of EDMA that needs to be abstracted. As pointed out, edma.c is already here in arch/arm/, so moving it doesn't add something new. It does let us regression test all platforms that use it (both Davinci and AM33xx) as I go through the conversion process. -Matt -- 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
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote: * Matt Porter mpor...@ti.com [130202 10:10]: If it doesn't work, work with Vinod to fix the api. It's expected, I'm working on dmaengine API changes right now to deal with a limitation of EDMA that needs to be abstracted. Regarding the DMA API limitations, I'm only aware of lack of capability to configure autoincrement at the device end. And that keeps us from converting all GPMC related devices using omap SDMA to use the DMA API. Are there other limitations currently known with the DMA API? Yes, I called one out when this was first posted as an RFC and was working it in parallel with this support. This one blocks AM33XX support in mmc and is the reason I split all of the mmc support out of the base edma dmaengine for am33xx series. Independent of the blockage, whatever we finally settle on to address this API need will also cleanup the use of magic values in the davinci mmc driver (that's part of the second thread below). RFC posting: https://patchwork.kernel.org/patch/1583531/ Posting with initial attempt at a caps api: http://www.spinics.net/lists/linux-mmc/msg18351.html Also, I haven't fully vetted the situation with cyclic transfers and EDMA, however, I'm pretty sure that we'll need some API changes there. The reason is that some Davinci platforms have no FIFO on their McASP implementation (that was a new feature added on DA8xx and also AM33xx). As such they have audio support implemented using ping-pong buffering via an SRAM buffer. There's been a number of patches ahead of all this that myself and others have worked upstream to get the SRAM stuff to be Davinci-independent (genalloc). But, at the end of all of this, there's no notion in a cyclic transfer of doing synchronized ping-pong buffering using two chain channels. This is how it is implemented (and documented in EDMA docs going back to the DSPs this IP first showed up on) using the private API. I'll be looking at this soon, but, I'm more interested in 1) getting the base support in 2) then the mmc stuff blocking DT populated platforms using omap_hsmmc (split out and posted) 3) v3 of the caps api w/ vinod's concerns address (working it not) Normally, I'm not going to bring up the cyclic transfer issue until I have some code to show or reference for discussion...but it's worth being aware. But, in any case, I'm confident that will gate having the mcasp driver that am33xx also uses converted to dmaengine. Except for the gpmc limitation you menationed, that's the last in kernel user of the privat edma api needed to be converted such that we can kill off arch/arm/common/edma.c once it's taken in. -Matt -- 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
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 07:06:06PM +, Sergei Shtylyov wrote: Hello. On 02-02-2013 22:07, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in plat-omap/dma.c. The actual dmaengine driver is in drivers/dma/edma.c as a wrapper around this...same way OMAP DMA engine conversion is being done. Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed that, instead of waiting indefinitely for TI to convert it to drivers/dma/ directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh. That is a shame. Yeah, I've pointed out that I was doing this exactly the same way as was acceptable for the OMAP DMA conversion since it was in RFC. The reasons are sound since in both cases, we have many drivers to convert that need to continue using the private DMA APIs. In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't know them well). Well, it's pretty clear to me now that there's good reason for it not landing in arch/arm/ so the obvious path is to do the dmaengine conversion and put it in drivers/dma/ if it's really a generic dma engine. I'm not sure why you express concern over the dma engine api not fitting with CPPI 4.1? It's not a DMA controller only, it's 3 distinct devices, with the DMA controller being one among them and using another one, the queue manager, as some sort of proxy. The third device doesn't exist on OMAP-L1x SoCs -- it's the buffer manager. Interesting, and you don't see a way to have this split between dmaengine and the musb driver? This all assumes there's even a match as RMK did raise concerns elsewhere in this thread. If it doesn't work, work with Vinod to fix the api. It's expected, I'm working on dmaengine API changes right now to deal with a limitation of EDMA that needs to be abstracted. Sorry, now it's TI's task. I no longer have time to work on this (my internal project to push OMAP-L1x support upstream has expired at Sep 2010) and my future in MV is very uncertain at this moment. Most probably I'll leave it (or be forced to leave). Too bad, it's certainly somebody's task. The people employed by TI have names too. ;) I suspect it falls to Felipe or Kishon these days, but I try to avoid USB as it's generally a source of pain. As pointed out, edma.c is already here in arch/arm/, so moving it doesn't add something new. It does let us regression test all platforms that use it (both Davinci and AM33xx) as I go through the conversion process. Could have been the same with CPPI 4.1 in theory if it was added to mach-davinci/ back in 2009... we'd then only have to move it. EDMA code is much older of course, so it's probably more justified. Absolutely, timing is everything. I can assure you I've flamed enough people internally about leaving this EDMA dmaengine conversion for so long. As you might have guessed, AM33xx is a bit of a driver for it, but all of this would have been quite a bit simpler had somebody taken a little effort and moved edma to dmaengine years ago when slave dma support was added to dmaengine. ;) -Matt -- 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
Re: [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Fri, Feb 01, 2013 at 08:01:41AM +0200, Luciano Coelho wrote: On Thu, 2013-01-31 at 16:42 -0500, Matt Porter wrote: On Thu, Jan 31, 2013 at 08:58:39PM +, Arnd Bergmann wrote: On Thursday 31 January 2013, Matt Porter wrote: On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: On Wednesday 30 January 2013, Matt Porter wrote: + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); + of_dma_controller_register(dev-of_node, + of_dma_simple_xlate, + edma_filter_info); + } How do you actually deal with the problem mentioned by Padma, that the filter function does not know which edma instance it is looking at? If you assume that there can only be a single edma instance in the system, that is probably a limitation that should be documented somewhere, and ideally the probe() function should check for that. I make an assumption of one edma instance in the system in the case of DT being populated. This is always true right now as the only SoC with two EDMA controllers in existence is Davinci DA850. Until recently, Davinci had no DT support. Given the steady work being done today on DT support for DA850, it'll probably be something needed in 3.10. I will add a comment and check in probe() to capture this assumption and then plan to update separately to support DA850 booting from DT. Ok, sounds good. Hopefully by then we will already have a nicer way to write an xlate function that does not rely on a filter function. Yes, it would be nice to avoid what Padma had to do. I should have mentioned also that the second EDMA on DA850 has no DMA events of immediate use on it anyway. All the in-kernel users use events on the first controller, except for the second MMC instance. That's only used for a wl12xx module on the EVM and that driver has no DT support so it doesn't matter yet in the DT case. Because of this, DA850 can actually add EDMA DT support immediately (on top of this series) and add DMA support to the DT support already posted for the Davinci SPI and MMC client drivers. I haven't followed this whole discussion in details, but please notice that I'm aiming to get DT support for the WiLink modules (wlcore, wl12xx...) for 3.10. ;) Great, looks like we'll all be synced then. ;) -Matt -- 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
[PATCH v7 04/10] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter mpor...@ti.com --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 0b408bb..239020b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -220,7 +220,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 -- 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
[PATCH v7 09/10] 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 mpor...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 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 specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed 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,17 @@ 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
--
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
[PATCH v7 08/10] 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 mpor...@ti.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
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 v7 10/10] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter mpor...@ti.com --- 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 e711ffb..ddf702a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -328,6 +328,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; }; @@ -339,6 +344,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 -- 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
[PATCH v7 07/10] 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 t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Arnd Bergmann a...@arndb.de
---
include/linux/dmaengine.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..17d8ffd 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1001,6 +1001,22 @@ 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)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat((mask), x, y, dev, name)
+
+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)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
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
[PATCH v7 00/10] DMA Engine support for AM33XX
Changes since v6:
- Converted edma_of_read_*() to wrappers around of_property_read_*()
- Fixed wording on the omap-spi generic DMA properties
- Added comment/check to clarify that the driver only supports
a single EDMA instance when booting from DT
Changes since v5:
- Dropped mmc portion and moved it to a separate series
- Incorporate corrected version of dma_request_slave_channel_compat()
- Fix #defines and enablement of TI_PRIV_EDMA option
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]
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-rc5 and the following patches:
- dmaengine DT support and edma dmaengine driver fix from
the git://git.infradead.org/users/vkoul/slave-dma.git next
branch
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
SPI DMA support (and MMC support with the separate MMC series).
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-v7
has the complete series, dependencies, and some test
drivers/defconfigs. Note that MMC can only be tested with a
separate MMC dmaengine/DT series applied.
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 (10):
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()
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 | 49 +++
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
arch/arm/Kconfig |1 +
arch/arm/boot/dts/am33xx.dtsi | 30 ++
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci
[PATCH v7 03/10] 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 EDMA
crossbar event mux support. Enables build on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/common/edma.c | 96
arch/arm/plat-omap/Kconfig |1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 89 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 3440d16..bd2416a 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -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);
@@ -1575,27 +1585,69 @@ static struct of_dma_filter_info edma_filter_info = {
static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev-dev.platform_data;
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL, NULL};
+ struct edma_soc_infotmpinfo;
const s8(*queue_priority_mapping)[2];
const s8(*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
+ const s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
- struct resource *r[EDMA_MAX_CC] = {NULL};
+ struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
+ struct resource res[EDMA_MAX_CC];
resource_size_t len[EDMA_MAX_CC];
charres_name[10];
charirq_name[10];
+ struct device_node *node = pdev-dev.of_node;
+ struct device *dev = pdev-dev;
+ int ret;
+
+ if (node) {
+ /* Check if this is a second instance registered */
+ if (arch_num_cc) {
+ dev_err(dev, only one EDMA instance is supported via
DT\n);
+ return -ENODEV;
+ }
+ info = ninfo;
+ edma_of_parse_dt(dev, node, tmpinfo);
+ info[0] = tmpinfo;
+
+ dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+ of_dma_controller_register(dev-of_node,
+ of_dma_simple_xlate,
+ edma_filter_info);
+ }
if (!info)
return -ENODEV;
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev, pm_runtime_get_sync() failed\n);
+ return ret;
+ }
+
for (j = 0; j EDMA_MAX_CC; j++) {
- sprintf(res_name, edma_cc%d, j);
- r[j] = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ if (!info[j]) {
+ if (!found)
+ return -ENODEV;
+ break;
+ }
+ if (node) {
+ ret = of_address_to_resource(node, j, res[j]);
+ if (!IS_ERR_VALUE(ret))
+ r[j] = res[j];
+ } else {
+ sprintf(res_name, edma_cc%d, j);
+ r[j] = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM,
res_name);
- if (!r[j] || !info[j]) {
+ }
+ if (!r[j]) {
if (found)
break;
else
@@ -1670,8 +1722,22 @@ static int edma_probe(struct platform_device *pdev)
}
}
- sprintf(irq_name, edma%d, j);
- irq[j] = platform_get_irq_byname(pdev, irq_name);
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]-xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j
