redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity
alistair23-linux/Documentation/devicetree/bindings/dma/ti-edma.txt

149 lines
4.6 KiB
Plaintext
Raw Normal View History

dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 01:18:10 -06:00
Texas Instruments eDMA
The eDMA3 consists of two components: Channel controller (CC) and Transfer
Controller(s) (TC). The CC is the main entry for DMA users since it is
responsible for the DMA channel handling, while the TCs are responsible to
execute the actual DMA tansfer.
------------------------------------------------------------------------------
eDMA3 Channel Controller
Required properties:
- compatible: "ti,edma3-tpcc" for the channel controller(s)
- #dma-cells: Should be set to <2>. The first number is the DMA request
number and the second is the TC the channel is serviced on.
- reg: Memory map of eDMA CC
- reg-names: "edma3_cc"
- interrupts: Interrupt lines for CCINT, MPERR and CCERRINT.
ARM: dts: Correct misspelling, "emda3" -> "edma3" Correct misspelling, "emda3" -> "edma3". Reported-by: Adam J Allison <adamj.allison@gmail.com> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2016-05-24 15:20:28 -06:00
- interrupt-names: "edma3_ccint", "edma3_mperr" and "edma3_ccerrint"
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 01:18:10 -06:00
- ti,tptcs: List of TPTCs associated with the eDMA in the following form:
<&tptc_phandle TC_priority_number>. The highest priority is 0.
Optional properties:
- ti,hwmods: Name of the hwmods associated to the eDMA CC
- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 01:18:10 -07:00
these channels will be SW triggered channels. See example.
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 01:18:10 -06:00
- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
the driver, they are allocated to be used by for example the
DSP. See example.
------------------------------------------------------------------------------
eDMA3 Transfer Controller
Required properties:
- compatible: "ti,edma3-tptc" for the transfer controller(s)
- reg: Memory map of eDMA TC
- interrupts: Interrupt number for TCerrint.
Optional properties:
- ti,hwmods: Name of the hwmods associated to the given eDMA TC
- interrupt-names: "edma3_tcerrint"
------------------------------------------------------------------------------
Example:
edma: edma@49000000 {
compatible = "ti,edma3-tpcc";
ti,hwmods = "tpcc";
reg = <0x49000000 0x10000>;
reg-names = "edma3_cc";
interrupts = <12 13 14>;
ARM: dts: Correct misspelling, "emda3" -> "edma3" Correct misspelling, "emda3" -> "edma3". Reported-by: Adam J Allison <adamj.allison@gmail.com> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2016-05-24 15:20:28 -06:00
interrupt-names = "edma3_ccint", "edma3_mperr", "edma3_ccerrint";
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 01:18:10 -06:00
dma-requests = <64>;
#dma-cells = <2>;
ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 7>, <&edma_tptc2 0>;
/* Channel 20 and 21 is allocated for memcpy */
dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type This change makes the DT file to be easier to read since the memcpy channels array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 01:18:10 -07:00
ti,edma-memcpy-channels = <20 21>;
dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type This change makes the DT file to be easier to read since the reserved slots array does not need the '/bits/ 16' to be specified, which might confuse some people. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-12-09 01:18:11 -07:00
/* The following PaRAM slots are reserved: 35-44 and 100-109 */
ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
dmaengine: edma: New device tree binding With the old binding and driver architecture we had many issues: No way to assign eDMA channels to event queues, thus not able to tune the system by moving specific DMA channels to low/high priority servicing. We moved the cyclic channels to high priority within the code, but that was just a workaround to this issue. Memcopy was fundamentally broken: even if the driver scanned the DT/devices in the booted system for direct DMA users (which is not effective when the events are going through a crossbar) and created a map of 'used' channels, this information was not really usable. Since via dmaengien API the eDMA driver will be called with _some_ channel number, we would try to request this channel when any channel is requested for memcpy. By luck we got channel which is not used by any device most of the time so things worked, but if a device would have been using the given channel, but not requested it, the memcpy channel would have been waiting for HW event. The old code had the am33xx/am43xx DMA event router handling embedded. This should have been done in a separate driver since it is not part of the actual eDMA IP. There were no way to 'lock' PaRAM slots to be used by the DSP for example when booting with DT. In DT boot the edma node used more than one hwmod which is not a good practice and the kernel prints warning because of this. With the new bindings and the changes in the driver we can: - No regression with Legacy binding and non DT boot - DMA channels can be assigned to any TC (to set priority) - PaRAM slots can be reserved for other cores to use - Dynamic power management for CC and TCs, if only TC0 is used all other TC can be powered down for example Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-16 01:18:10 -06:00
};
edma_tptc0: tptc@49800000 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc0";
reg = <0x49800000 0x100000>;
interrupts = <112>;
interrupt-names = "edm3_tcerrint";
};
edma_tptc1: tptc@49900000 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc1";
reg = <0x49900000 0x100000>;
interrupts = <113>;
interrupt-names = "edm3_tcerrint";
};
edma_tptc2: tptc@49a00000 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc2";
reg = <0x49a00000 0x100000>;
interrupts = <114>;
interrupt-names = "edm3_tcerrint";
};
sham: sham@53100000 {
compatible = "ti,omap4-sham";
ti,hwmods = "sham";
reg = <0x53100000 0x200>;
interrupts = <109>;
/* DMA channel 36 executed on eDMA TC0 - low priority queue */
dmas = <&edma 36 0>;
dma-names = "rx";
};
mcasp0: mcasp@48038000 {
compatible = "ti,am33xx-mcasp-audio";
ti,hwmods = "mcasp0";
reg = <0x48038000 0x2000>,
<0x46000000 0x400000>;
reg-names = "mpu", "dat";
interrupts = <80>, <81>;
interrupt-names = "tx", "rx";
status = "disabled";
/* DMA channels 8 and 9 executed on eDMA TC2 - high priority queue */
dmas = <&edma 8 2>,
<&edma 9 2>;
dma-names = "tx", "rx";
};
------------------------------------------------------------------------------
DEPRECATED binding, new DTS files must use the ti,edma3-tpcc/ti,edma3-tptc
binding.
dmaengine: edma: Add TI EDMA device tree binding The binding definition is based on the generic DMA controller binding. Joel: * Droped reserved and queue DT entries from Documentation for now from the original patch series (v10) * Included properties in Documentation and clarified DMA properties (V11) * Made ti,hwmod option * Clarified DMA entries Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Joel A Fernandes <joelagnel@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-20 15:06:37 -06:00
Required properties:
- compatible : "ti,edma3"
- #dma-cells: Should be set to <1>
Clients should use a single channel number per DMA request.
- reg: Memory map for accessing module
- interrupt-parent: Interrupt controller the interrupt is routed through
- interrupts: Exactly 3 interrupts need to be specified in the order:
1. Transfer completion interrupt.
2. Memory protection interrupt.
3. Error interrupt.
Optional properties:
- ti,hwmods: Name of the hwmods associated to the EDMA
- ti,edma-xbar-event-map: Crossbar event to channel map
dt/bindings: ti,edma: Remove redundant properties from documentation From CCCFG register of eDMA3 we can get all the needed information for the driver about the IP: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE The ti,edma-regions; ti,edma-slots and dma-channels in DT are redundant since the very same information can be obtained from the HW. The mentioned properties are deprecated. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2014-05-16 06:17:16 -06:00
Deprecated properties:
Listed here in case one wants to boot an old kernel with new DTB. These
properties might need to be added to the new DTS files.
- ti,edma-regions: Number of regions
- ti,edma-slots: Number of slots
- dma-channels: Specify total DMA channels per CC
dmaengine: edma: Add TI EDMA device tree binding The binding definition is based on the generic DMA controller binding. Joel: * Droped reserved and queue DT entries from Documentation for now from the original patch series (v10) * Included properties in Documentation and clarified DMA properties (V11) * Made ti,hwmod option * Clarified DMA entries Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Joel A Fernandes <joelagnel@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-20 15:06:37 -06:00
Example:
edma: edma@49000000 {
reg = <0x49000000 0x10000>;
interrupt-parent = <&intc>;
interrupts = <12 13 14>;
compatible = "ti,edma3";
ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
#dma-cells = <1>;
ARM: common: edma: Fix xbar mapping This is another great example of trainwreck engineering: commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support) added support for using EDMA on peripherals which have no direct EDMA event mapping. The code compiles and does not explode in your face, but that's it. 1) Reading an u16 array from an u32 device tree array simply does not work. Even if the function is named "edma_of_read_u32_to_s16_array". It merily calls of_property_read_u16_array. So the resulting 16bit array will have every other entry = 0. 2) The DT entry for the xbar registers related to xbar has length 0x10 instead of the real length: 0xfd0 - 0xf90 = 0x40. Not a real problem as it does not cross a page boundary, but wrong nevertheless. 3) But none of this matters as the mapping never happens: After reading nonsense edma_of_read_u32_to_s16_array() invalidates the first array entry pair, so nobody can ever notice the braindamage by immediate explosion. Seems the QA criteria for this code was solely not to explode when someone adds edma-xbar-event-map entries to the DT. Goal achieved, congratulations! Not really helpful if someone wants to use edma on a device which requires a xbar mapping. Fix the issues by: - annotating the device tree entry with "/bits/ 16" as documented in the of_property_read_u16_array kernel doc - make the size of the xbar register mapping correct - invalidating the end of the array and not the start This convoluted mess wants to be completely rewritten as there is no point to keep the xbar_chan array memory and the iomapping of the xbar regs around forever. Marking the xbar mapped channels as used should be done right there. But that's a different issue and this patch is small enough to make it work and allows a simple backport for stable. Cc: stable@vger.kernel.org # v3.12+ Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2014-04-13 12:44:46 -06:00
ti,edma-xbar-event-map = /bits/ 16 <1 12
2 13>;
dmaengine: edma: Add TI EDMA device tree binding The binding definition is based on the generic DMA controller binding. Joel: * Droped reserved and queue DT entries from Documentation for now from the original patch series (v10) * Included properties in Documentation and clarified DMA properties (V11) * Made ti,hwmod option * Clarified DMA entries Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Joel A Fernandes <joelagnel@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-20 15:06:37 -06:00
};