The original device tree binding for this driver, from Viresh Kumar
unfortunately conflicted with the generic DMA binding, and did not allow
to completely seperate slave device configuration from the controller.
This is an attempt to replace it with an implementation of the generic
binding, but it is currently completely untested, because I do not have
any hardware with this particular controller.
The patch applies on top of the slave-dma tree, which contains both the base
support for the generic DMA binding, as well as the earlier attempt from
Viresh. Both of these are currently not merged upstream however.
This version incorporates feedback from Viresh Kumar, Andy Shevchenko
and Russell King.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
dw_dmac driver already supports device tree but it used to have its platform
data passed the non-DT way.
This patch does following changes:
- pass platform data via DT, non-DT way still takes precedence if both are used.
- create generic filter routine
- Earlier slave information was made available by slave specific filter routines
in chan->private field. Now, this information would be passed from within dmac
DT node. Slave drivers would now be required to pass bus_id (a string) as
parameter to this generic filter(), which would be compared against the slave
data passed from DT, by the generic filter routine.
- Update binding document
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[Fixed __devinit usage]
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Some semicolons were left out in the examples.
The #dma-channels and #dma-requests properties have a prefix
that is, by convention, reserved for cell size properties.
Rename those properties to dma-channels and dma-requests.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, "dmaengine: add helper function to request a slave DMA
channel") which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
char *name)
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to easily
support them with regard to device tree. Ideally, these should be migrated
to DMA engine. However, if this is not possible, then they should still be
able to use this binding, the only constaint imposed by this implementation
is that when requesting a DMA channel via of_dma_request_slave_channel(), it
will return a type of dma_chan.
This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
have validated that MMC is working on the PANDA board with this implementation.
My development branch for testing on OMAP can be found here [5].
v6: - minor corrections in DMA binding documentation
v5: - minor update to binding documentation
- added loop to exhaustively search for a slave channel in the case where
there could be alternative channels available
v4: - revert the removal of xlate function from v3
- update the proposed binding format and APIs based upon discussions [3]
v3: - avoid passing an xlate function and instead pass DMA engine parameters
- define number of dma channels and requests in dma-controller node
v2: - remove of_dma_to_resource API
- make property #dma-cells required (no fallback anymore)
- another check in of_dma_xlate_onenumbercell() function
[1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
[2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
[4] http://pad.linaro.org/arm-mini-summit-2012
[5] https://github.com/jonhunter/linux/tree/dev-dt-dma
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
This patch finally adds a Device Tree binding to the mv_xor
driver. Thanks to the previous cleanup patches, the Device Tree
binding is relatively simply: one DT node per XOR engine, with
sub-nodes for each XOR channel of the XOR engine. The binding
obviously comes with the necessary documentation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree-discuss@lists.ozlabs.org
Pull CMA and DMA-mapping updates from Marek Szyprowski:
"This time the pull request is rather small, because the further
redesign patches were not ready on time.
This pull request consists of the patches which extend ARM DMA-mapping
subsystem with support for CPU coherent (ACP) DMA busses. The first
client of the new version is HighBank SATA driver. The second part of
the pull request includes various cleanup for both CMA common code and
ARM DMA-mapping subsystem."
Fix up trivial add-add conflict due to the "dma-coherent" DT property
being added next to the "calxeda,port-phys" property for the Calxeda
AHCI controller.
* 'for-v3.7' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping:
ARM: dma-mapping: Remove unsed var at arm_coherent_iommu_unmap_page
ARM: highbank: add coherent DMA setup
ARM: kill off arch_is_coherent
ARM: add coherent iommu dma ops
ARM: add coherent dma ops
ARM: dma-mapping: Refrain noisy console message
ARM: dma-mapping: Small logical clean up
drivers: dma-contiguous: refactor dma_alloc_from_contiguous()
Some highbank DMA masters can support coherent (ACP) or non-coherent DMA.
This sets up dma_map_ops for masters which are configured for coherent DMA.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
These continue the device tree work from part 1, this set is for the
tegra, mxs and imx platforms, all of which have dependencies on clock
or pinctrl changes submitted earlier.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPuex7AAoJEIwa5zzehBx3xsQP/jkyt74MvuKUi8pi2zkeMIgn
4XieyqcA0KZjJzfB22q3GIZjNIf/mEIGE4E/3bneVMPh/E2zaiohaXFExBmjNjml
hhzWeZlFGPBjrZsfpIXJIIUhwSI7gX2rjYh4npJmdNhZmy8Y89XnpNJhN1kOwMuV
oN23hPWoSVGbyDMQ0fmHx9GyOL8m7yap+joG13aljDa2OKpQg+pYvdwft+k1K9di
8yPF+qA043UUR7dSsjmTbiCcjZy2eySdCmfOAkEG4inSgxNoM7GBs3MuwZo/veCD
v5WssJqWDbLXtqKn5Uo2bvGWiEcf0xtwOAqhSpbaup3dQFJSWMEenBTtA9UlxFhk
6gdY62O+7k6N0thkxXyLNGkgaGzexZAsK7dM6XSDB+PqD+OSNJS7dvmxZM8tuaRn
rvCM1XWcNeN/dpnLbgwCR12efkwWtJoqqUZUUp/tFFaTo8HriqeAIYk7obnR8s9n
S5x9LeueQGNgaxXJzVdh481YKG/1lqjG/a06HbVgYS4XQvtdA+4khalOefJv10tm
Nkg8+4/8pMthWJfhhlfPUgWFXOXFF2AGPG4su2XwKuFXypO8599lzi7gUQaEZu2U
7caqoWP69KsKvK5iAAmA4DQ2rcsgHd44NXx/8Jjes9ma8knlYjrf42dBH6AZMQBG
69I9sJ1cyqusBwx72NPN
=WeDQ
-----END PGP SIGNATURE-----
Merge tag 'dt2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull arm-soc device tree conversions (part 2) from Olof Johansson:
"These continue the device tree work from part 1, this set is for the
tegra, mxs and imx platforms, all of which have dependencies on clock
or pinctrl changes submitted earlier."
Fix up trivial conflicts due to nearby changes in
drivers/{gpio/gpio,i2c/busses/i2c}-mxs.c
* tag 'dt2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (73 commits)
ARM: dt: tegra: invert status=disable vs status=okay
ARM: dt: tegra: consistent basic property ordering
ARM: dt: tegra: sort nodes based on bus order
ARM: dt: tegra: remove duplicate device_type property
ARM: dt: tegra: consistenly use lower-case for hex constants
ARM: dt: tegra: format regs properties consistently
ARM: dt: tegra: gpio comment cleanup
ARM: dt: tegra: remove unnecessary unit addresses
ARM: dt: tegra: whitespace cleanup
ARM: dt: tegra cardhu: fix typo in SDHCI node name
ARM: dt: tegra: cardhu: register core regulator tps62361
ARM: dt: tegra30.dtsi: Add SMMU node
ARM: dt: tegra20.dtsi: Add GART node
ARM: dt: tegra30.dtsi: Add Memory Controller(MC) nodes
ARM: dt: tegra20.dtsi: Add Memory Controller(MC) nodes
ARM: dt: tegra: Add device tree support for AHB
ARM: dts: enable audio support for imx28-evk
ARM: dts: enable i2c device for imx28-evk
i2c: mxs: add device tree probe support
ARM: dts: enable mmc for imx28-evk
...
SPEAr platforms now support DT and so must convert all drivers to support DT.
This patch adds DT probing support for Synopsys DMA controller and updates its
documentation too.
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Document binding, and add the node to tegra*.dtsi.
The driver isn't actually instantiated from this node yet, but the I2S
binding will rely on being able to refer to the APB DMA node using a
phandle.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: Boojin Kim <boojin.kim@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Add device tree probe support for atmel at_hdmac DMA driver.
Bindings are added to specify DMA controller configuration.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
