* [PATCH V6 0/2] of: Add generic device tree DMA helpers @ 2012-09-14 22:41 Jon Hunter 2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter [not found] ` <1347662517-4210-1-git-send-email-jon-hunter-l0cyMroinI0@public.gmane.org> 0 siblings, 2 replies; 39+ messages in thread From: Jon Hunter @ 2012-09-14 22:41 UTC (permalink / raw) To: device-tree, linux-omap, linux-arm; +Cc: Jon Hunter Hi all, I apologise for sending out so many updates in quick succession before everyone has had chance to review, however, I will be out of office next week and I know that several people have been waiting for this. Normally, I would not send out a series and disappear for a week, but Arnd agreed to help while I am out. Arnd, Feel free to make any changes you see fit while I am out or correct any balls-up I have made! Cheers Jon This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic device-tree helpers to retrieve a DMA controller device_node and the DMA request/channel information. 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 Jon Hunter (2): of: Add generic device tree DMA helpers dmaengine: add helper function to request a slave DMA channel Documentation/devicetree/bindings/dma/dma.txt | 81 +++++++++ drivers/dma/dmaengine.c | 16 ++ drivers/of/Makefile | 2 +- drivers/of/dma.c | 219 +++++++++++++++++++++++++ include/linux/dmaengine.h | 6 + include/linux/of_dma.h | 45 +++++ 6 files changed, 368 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/dma.txt create mode 100644 drivers/of/dma.c create mode 100644 include/linux/of_dma.h -- 1.7.9.5 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-14 22:41 [PATCH V6 0/2] of: Add generic device tree DMA helpers Jon Hunter @ 2012-09-14 22:41 ` Jon Hunter 2012-09-14 22:46 ` Stephen Warren ` (4 more replies) [not found] ` <1347662517-4210-1-git-send-email-jon-hunter-l0cyMroinI0@public.gmane.org> 1 sibling, 5 replies; 39+ messages in thread From: Jon Hunter @ 2012-09-14 22:41 UTC (permalink / raw) To: device-tree, linux-omap, linux-arm Cc: Jon Hunter, Nicolas Ferre, Benoit Cousson, Stephen Warren, Grant Likely, Russell King, Rob Herring, Arnd Bergmann, Vinod Koul, Dan Williams 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> --- Documentation/devicetree/bindings/dma/dma.txt | 81 +++++++++ drivers/of/Makefile | 2 +- drivers/of/dma.c | 219 +++++++++++++++++++++++++ include/linux/of_dma.h | 45 +++++ 4 files changed, 346 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/dma.txt create mode 100644 drivers/of/dma.c create mode 100644 include/linux/of_dma.h diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt new file mode 100644 index 0000000..a4f59a5 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/dma.txt @@ -0,0 +1,81 @@ +* Generic DMA Controller and DMA request bindings + +Generic binding to provide a way for a driver using DMA Engine to retrieve the +DMA request or channel information that goes from a hardware device to a DMA +controller. + + +* DMA controller + +Required property: +- #dma-cells: Must be at least 1. Used to provide DMA controller + specific information. See DMA client binding below for + more details. + +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the + controller. + +Example: + + dma: dma@48000000 { + compatible = "ti,omap-sdma" + reg = <0x48000000 0x1000>; + interrupts = <0 12 0x4 + 0 13 0x4 + 0 14 0x4 + 0 15 0x4>; + #dma-cells = <1>; + #dma-channels = <32>; + #dma-requests = <127>; + }; + + +* DMA client + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of + - A phandle pointing to DMA controller node + - A number of integer cells, as determined by the + #dma-cells property in the node referenced by phandle + containing DMA controller specific information. This + typically contains a DMA request line number or a + channel number, but can contain any data that is used + required for configuring a channel. +- dma-names: Contains one identifier string for each DMA specifier in + the dmas property. The specific strings that can be used + are defined in the binding of the DMA client device. + Multiple DMA specifiers can be used to represent + alternatives and in this case the dma-names for those + DMA specifiers must be identical (see examples). + +Examples: + +1. A device with one DMA read channel, one DMA write channel: + + i2c1: i2c@1 { + ... + dmas = <&dma 2 /* read channel */ + &dma 3>; /* write channel */ + dma-names = "rx", "tx" + ... + }; + +2. A single read-write channel with three alternative DMA controllers: + + dmas = <&dma1 5 + &dma2 7 + &dma3 2>; + dma-names = "rx-tx", "rx-tx", "rx-tx" + +3. A device with three channels, one of which has two alternatives: + + dmas = <&dma1 2 /* read channel */ + &dma1 3 /* write channel */ + &dma2 0 /* error read */ + &dma3 0>; /* alternative error read */ + dma-names = "rx", "tx", "error", "error"; diff --git a/drivers/of/Makefile b/drivers/of/Makefile index e027f44..eafa107 100644 --- a/drivers/of/Makefile +++ b/drivers/of/Makefile @@ -1,4 +1,4 @@ -obj-y = base.o +obj-y = base.o dma.o obj-$(CONFIG_OF_FLATTREE) += fdt.o obj-$(CONFIG_OF_PROMTREE) += pdt.o obj-$(CONFIG_OF_ADDRESS) += address.o diff --git a/drivers/of/dma.c b/drivers/of/dma.c new file mode 100644 index 0000000..19ad37c --- /dev/null +++ b/drivers/of/dma.c @@ -0,0 +1,219 @@ +/* + * Device tree helpers for DMA request / controller + * + * Based on of_gpio.c + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/device.h> +#include <linux/err.h> +#include <linux/module.h> +#include <linux/rculist.h> +#include <linux/slab.h> +#include <linux/of.h> +#include <linux/of_dma.h> + +static LIST_HEAD(of_dma_list); + +/** + * of_dma_find_controller - Find a DMA controller in DT DMA helpers list + * @np: device node of DMA controller + */ +static struct of_dma *of_dma_find_controller(struct device_node *np) +{ + struct of_dma *ofdma; + + if (list_empty(&of_dma_list)) { + pr_err("empty DMA controller list\n"); + return NULL; + } + + list_for_each_entry_rcu(ofdma, &of_dma_list, of_dma_controllers) + if (ofdma->of_node == np) + return ofdma; + + return NULL; +} + +/** + * of_dma_controller_register - Register a DMA controller to DT DMA helpers + * @np: device node of DMA controller + * @of_dma_xlate: translation function which converts a phandle + * arguments list into a dma_chan structure + * @data pointer to controller specific data to be used by + * translation function + * + * Returns 0 on success or appropriate errno value on error. + * + * Allocated memory should be freed with appropriate of_dma_controller_free() + * call. + */ +int of_dma_controller_register(struct device_node *np, + struct dma_chan *(*of_dma_xlate) + (struct of_phandle_args *, struct of_dma *), + void *data) +{ + struct of_dma *ofdma; + int nbcells; + + if (!np || !of_dma_xlate) { + pr_err("%s: not enough information provided\n", __func__); + return -EINVAL; + } + + ofdma = kzalloc(sizeof(*ofdma), GFP_KERNEL); + if (!ofdma) + return -ENOMEM; + + nbcells = be32_to_cpup(of_get_property(np, "#dma-cells", NULL)); + if (!nbcells) { + pr_err("%s: #dma-cells property is missing or invalid\n", + __func__); + return -EINVAL; + } + + ofdma->of_node = np; + ofdma->of_dma_nbcells = nbcells; + ofdma->of_dma_xlate = of_dma_xlate; + ofdma->of_dma_data = data; + + /* Now queue of_dma controller structure in list */ + list_add_tail_rcu(&ofdma->of_dma_controllers, &of_dma_list); + + return 0; +} +EXPORT_SYMBOL_GPL(of_dma_controller_register); + +/** + * of_dma_controller_free - Remove a DMA controller from DT DMA helpers list + * @np: device node of DMA controller + * + * Memory allocated by of_dma_controller_register() is freed here. + */ +void of_dma_controller_free(struct device_node *np) +{ + struct of_dma *ofdma; + + ofdma = of_dma_find_controller(np); + if (ofdma) { + list_del_rcu(&ofdma->of_dma_controllers); + kfree(ofdma); + } +} +EXPORT_SYMBOL_GPL(of_dma_controller_free); + +/** + * of_dma_find_channel - Find a DMA channel by name + * @np: device node to look for DMA channels + * @name: name of desired channel + * @dma_spec: pointer to DMA specifier as found in the device tree + * + * Find a DMA channel by the name. Returns 0 on success or appropriate + * errno value on error. + */ +static int of_dma_find_channel(struct device_node *np, char *name, + struct of_phandle_args *dma_spec) +{ + int count, i; + const char *s; + + count = of_property_count_strings(np, "dma-names"); + if (count < 0) + return count; + + for (i = 0; i < count; i++) { + if (of_property_read_string_index(np, "dma-names", i, &s)) + continue; + + if (strcmp(name, s)) + continue; + + if (!of_parse_phandle_with_args(np, "dmas", "#dma-cells", i, + dma_spec)) + return 0; + } + + return -ENODEV; +} + +/** + * of_dma_request_slave_channel - Get the DMA slave channel + * @np: device node to get DMA request from + * @name: name of desired channel + * + * Returns pointer to appropriate dma channel on success or NULL on error. + */ +struct dma_chan *of_dma_request_slave_channel(struct device_node *np, + char *name) +{ + struct of_phandle_args dma_spec; + struct of_dma *ofdma; + struct dma_chan *chan; + int r; + + if (!np || !name) { + pr_err("%s: not enough information provided\n", __func__); + return NULL; + } + + do { + r = of_dma_find_channel(np, name, &dma_spec); + if (r) { + pr_err("%s: can't find DMA channel\n", np->full_name); + return NULL; + } + + ofdma = of_dma_find_controller(dma_spec.np); + if (!ofdma) { + pr_debug("%s: can't find DMA controller %s\n", + np->full_name, dma_spec.np->full_name); + continue; + } + + if (dma_spec.args_count != ofdma->of_dma_nbcells) { + pr_debug("%s: wrong #dma-cells for %s\n", np->full_name, + dma_spec.np->full_name); + continue; + } + + chan = ofdma->of_dma_xlate(&dma_spec, ofdma); + + of_node_put(dma_spec.np); + + } while (!chan); + + return chan; +} + +/** + * of_dma_simple_xlate - Simple DMA engine translation function + * @dma_spec: pointer to DMA specifier as found in the device tree + * @of_dma: pointer to DMA controller data + * + * A simple translation function for devices that use a 32-bit value for the + * filter_param when calling the DMA engine dma_request_channel() function. + * Note that this translation function requires that #dma-cells is equal to 1 + * and the argument of the dma specifier is the 32-bit filter_param. Returns + * pointer to appropriate dma channel on success or NULL on error. + */ +struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, + struct of_dma *ofdma) +{ + int count = dma_spec->args_count; + struct of_dma_filter_info *info = ofdma->of_dma_data; + + if (!info || !info->filter_fn) + return NULL; + + if (count != 1) + return NULL; + + return dma_request_channel(info->dma_cap, info->filter_fn, + &dma_spec->args[0]); +} +EXPORT_SYMBOL_GPL(of_dma_simple_xlate); diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h new file mode 100644 index 0000000..337823d --- /dev/null +++ b/include/linux/of_dma.h @@ -0,0 +1,45 @@ +/* + * OF helpers for DMA request / controller + * + * Based on of_gpio.h + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __LINUX_OF_DMA_H +#define __LINUX_OF_DMA_H + +#include <linux/of.h> +#include <linux/dmaengine.h> + +struct device_node; + +struct of_dma { + struct list_head of_dma_controllers; + struct device_node *of_node; + int of_dma_nbcells; + struct dma_chan *(*of_dma_xlate) + (struct of_phandle_args *, struct of_dma *); + void *of_dma_data; +}; + +struct of_dma_filter_info { + dma_cap_mask_t dma_cap; + dma_filter_fn filter_fn; +}; + +extern int of_dma_controller_register(struct device_node *np, + struct dma_chan *(*of_dma_xlate) + (struct of_phandle_args *, struct of_dma *), + void *data); +extern void of_dma_controller_free(struct device_node *np); +extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np, + char *name); +extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, + struct of_dma *ofdma); + +#endif /* __LINUX_OF_DMA_H */ -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter @ 2012-09-14 22:46 ` Stephen Warren 2012-09-15 0:14 ` Russell King - ARM Linux ` (3 subsequent siblings) 4 siblings, 0 replies; 39+ messages in thread From: Stephen Warren @ 2012-09-14 22:46 UTC (permalink / raw) To: Jon Hunter Cc: device-tree, linux-omap, linux-arm, Stephen Warren, Vinod Koul, Rob Herring, Dan Williams, Russell King On 09/14/2012 04:41 PM, Jon Hunter wrote: > 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. The binding looks good to me now, so, Reviewed-by: Stephen Warren <swarren@wwwdotorg.org> ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter 2012-09-14 22:46 ` Stephen Warren @ 2012-09-15 0:14 ` Russell King - ARM Linux [not found] ` <20120915001431.GB12445-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2012-09-19 13:52 ` Matt Porter ` (2 subsequent siblings) 4 siblings, 1 reply; 39+ messages in thread From: Russell King - ARM Linux @ 2012-09-15 0:14 UTC (permalink / raw) To: Jon Hunter Cc: device-tree, linux-omap, linux-arm, Nicolas Ferre, Benoit Cousson, Stephen Warren, Grant Likely, Rob Herring, Arnd Bergmann, Vinod Koul, Dan Williams On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > 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. As far as devices not using DMA engine, the answer is we don't support their specification in the DT model. Note that the legacy OMAP DMA API is scheduled for removal next year, so it's not going to be around that much longer. ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <20120915001431.GB12445-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers [not found] ` <20120915001431.GB12445-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> @ 2012-09-17 20:42 ` Arnd Bergmann [not found] ` <201209172042.11860.arnd-r2nGTMty4D4@public.gmane.org> 2012-09-18 22:19 ` Mitch Bradley 0 siblings, 2 replies; 39+ messages in thread From: Arnd Bergmann @ 2012-09-17 20:42 UTC (permalink / raw) To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, David Brown, linux-omap On Saturday 15 September 2012, Russell King - ARM Linux wrote: > > On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > > 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. > > As far as devices not using DMA engine, the answer is we don't support > their specification in the DT model. Note that the legacy OMAP DMA > API is scheduled for removal next year, so it's not going to be around > that much longer. There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), and I agree that they are unlikely to see OF support, although if they did, it wouldn't be unreasonable to encode their DMA channels using the same binding. The other ones that are currently around with their own DMA implementation are bcmring --> platform is going away samsung --> gradually getting moved to dmaengine, already has its own binding that needs to be replaced with this one, so best do it at the same time. tegra --> old dma code gone in 3.7 pxa/mmp --> dmaengine implementation being worked on, should wait for that. msm --> dma implementation only used by two drivers (serial and mmc). Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their own dma APIs based on the ISA interfaces. I don't currently see any of them moving towards DT, but it's definitely possible. Among the above MSM seems to be the most likely candidate to use the binding before moving to DT. The msm_sdcc driver is (like much of the msm platform code) lagging far behind the internel version that qualcomm have, and the device tree binding they are using is incompatible with the common MMC binding (and of course the DMA binding here) as well. For getting MSM up to speed compared with the other platforms, they have to use proper DT bindings as well as proper DMA engine support. Between those two, I'd prefer fixing the DT binding first, in order to limit the amount of changes that have to be done to external device tree files. Arnd ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <201209172042.11860.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers [not found] ` <201209172042.11860.arnd-r2nGTMty4D4@public.gmane.org> @ 2012-09-17 23:06 ` David Brown [not found] ` <20120917230615.GA26502-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 0 siblings, 1 reply; 39+ messages in thread From: David Brown @ 2012-09-17 23:06 UTC (permalink / raw) To: Arnd Bergmann Cc: Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, Sep 17, 2012 at 08:42:11PM +0000, Arnd Bergmann wrote: > On Saturday 15 September 2012, Russell King - ARM Linux wrote: > > > > On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > > > 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. > > > > As far as devices not using DMA engine, the answer is we don't support > > their specification in the DT model. Note that the legacy OMAP DMA > > API is scheduled for removal next year, so it's not going to be around > > that much longer. > > There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), > and I agree that they are unlikely to see OF support, although if they did, it > wouldn't be unreasonable to encode their DMA channels using the same binding. > > The other ones that are currently around with their own DMA implementation are > > bcmring --> platform is going away > samsung --> gradually getting moved to dmaengine, already has its own binding > that needs to be replaced with this one, so best do it at the same > time. > tegra --> old dma code gone in 3.7 > pxa/mmp --> dmaengine implementation being worked on, should wait for that. > msm --> dma implementation only used by two drivers (serial and mmc). > > Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their > own dma APIs based on the ISA interfaces. I don't currently see any of them > moving towards DT, but it's definitely possible. > > Among the above MSM seems to be the most likely candidate to use the binding > before moving to DT. The msm_sdcc driver is (like much of the msm platform > code) lagging far behind the internel version that qualcomm have, and the > device tree binding they are using is incompatible with the common MMC > binding (and of course the DMA binding here) as well. For getting MSM up > to speed compared with the other platforms, they have to use proper DT > bindings as well as proper DMA engine support. Between those two, I'd prefer > fixing the DT binding first, in order to limit the amount of changes that > have to be done to external device tree files. There is also a lot of similarity between the mmci hardware and the msm_sdcc hardware. Enough so, that it is probably better for us to make the mmci driver work with our hardware, rather than trying to keep msm_sdcc going. There is also an MSM nand device that appears to have not made it in. It is heavily dependent on the weird features of the DMA hardware. I don't have any current plans to support this device, since most boards using MSMs these days are using mmc/sd instead of bare NAND. Our DMA hardware is really weird, but should be a bit reasonable. It is also being gradually replaced in newer chips with a different DMA framework. As far as I'm concerned, I consider making our DMA driver(s) use the DMA engine API to be part of getting these platforms working with DT. It is planned, but there are quite a few things that need to be tackled first. David -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <20120917230615.GA26502-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers [not found] ` <20120917230615.GA26502-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> @ 2012-09-18 12:50 ` Arnd Bergmann 0 siblings, 0 replies; 39+ messages in thread From: Arnd Bergmann @ 2012-09-18 12:50 UTC (permalink / raw) To: David Brown Cc: Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Monday 17 September 2012, David Brown wrote: > There is also a lot of similarity between the mmci hardware and the > msm_sdcc hardware. Enough so, that it is probably better for us to > make the mmci driver work with our hardware, rather than trying to > keep msm_sdcc going. > > There is also an MSM nand device that appears to have not made it in. > It is heavily dependent on the weird features of the DMA hardware. I > don't have any current plans to support this device, since most boards > using MSMs these days are using mmc/sd instead of bare NAND. > > Our DMA hardware is really weird, but should be a bit reasonable. It > is also being gradually replaced in newer chips with a different DMA > framework. > > As far as I'm concerned, I consider making our DMA driver(s) use the > DMA engine API to be part of getting these platforms working with DT. > > It is planned, but there are quite a few things that need to be > tackled first. Ok, thanks for the information. Arnd ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-17 20:42 ` Arnd Bergmann [not found] ` <201209172042.11860.arnd-r2nGTMty4D4@public.gmane.org> @ 2012-09-18 22:19 ` Mitch Bradley [not found] ` <5058F35A.8040702-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2012-09-19 11:09 ` Arnd Bergmann 1 sibling, 2 replies; 39+ messages in thread From: Mitch Bradley @ 2012-09-18 22:19 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, David Brown, linux-omap On 9/18/2012 4:42 AM, Arnd Bergmann wrote: > On Saturday 15 September 2012, Russell King - ARM Linux wrote: >> >> On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: >>> 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. >> >> As far as devices not using DMA engine, the answer is we don't support >> their specification in the DT model. Note that the legacy OMAP DMA >> API is scheduled for removal next year, so it's not going to be around >> that much longer. > > There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), > and I agree that they are unlikely to see OF support, (Warning - historical rambling follows) There is a delicious irony here with respect to Shark. Shark has real Open Firmware. It's the platform that I used for the first OFW port to ARM. We (the Shark design team) had a version of NetBSD that would run on Shark without any native drivers, calling into the Open Firmware drivers. It was very useful for bringup. I wonder when was the last time anyone turned on a Shark? I ran my mail server on one until 8 years ago, when the incoming spam load began to saturate the 10 Mbit Ethernet. Shark had decent computational power, but the I/O system, built around a low cost PC I/O chip, didn't have much bandwidth. Also in that time frame (early 2000s), some of us Shark designers managed to grab a pile of Sharks that HP was going to scrap. (HP had inherited them as part of Compaq, who had acquired them as part of Digital.) We used them as production unit testers for a consumer gadget that we were building. But, alas, even that usage fell to the wayside. I redesigned the tester around an ATSAM7 chip and put the entire test setup into a tiny box. I still have a couple of Sharks, but they haven't been turned on for at least 6 years. Is there ever a point when old architectures leave the Linux tree, or will people have to see grep hits from them until the end of time? although if they did, it > wouldn't be unreasonable to encode their DMA channels using the same binding. > > The other ones that are currently around with their own DMA implementation are > > bcmring --> platform is going away > samsung --> gradually getting moved to dmaengine, already has its own binding > that needs to be replaced with this one, so best do it at the same > time. > tegra --> old dma code gone in 3.7 > pxa/mmp --> dmaengine implementation being worked on, should wait for that. > msm --> dma implementation only used by two drivers (serial and mmc). > > Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their > own dma APIs based on the ISA interfaces. I don't currently see any of them > moving towards DT, but it's definitely possible. > > Among the above MSM seems to be the most likely candidate to use the binding > before moving to DT. The msm_sdcc driver is (like much of the msm platform > code) lagging far behind the internel version that qualcomm have, and the > device tree binding they are using is incompatible with the common MMC > binding (and of course the DMA binding here) as well. For getting MSM up > to speed compared with the other platforms, they have to use proper DT > bindings as well as proper DMA engine support. Between those two, I'd prefer > fixing the DT binding first, in order to limit the amount of changes that > have to be done to external device tree files. > > Arnd > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <5058F35A.8040702-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>]
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers [not found] ` <5058F35A.8040702-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> @ 2012-09-18 22:32 ` Russell King - ARM Linux 0 siblings, 0 replies; 39+ messages in thread From: Russell King - ARM Linux @ 2012-09-18 22:32 UTC (permalink / raw) To: Mitch Bradley Cc: Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, David Brown, linux-omap, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Wed, Sep 19, 2012 at 06:19:06AM +0800, Mitch Bradley wrote: > Is there ever a point when old architectures leave the Linux tree, or > will people have to see grep hits from them until the end of time? That depends on use and the burden of keeping them in the tree. I'm not aware of much activity around Shark, and I'm not aware of Shark causing that many problems either... ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-18 22:19 ` Mitch Bradley [not found] ` <5058F35A.8040702-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> @ 2012-09-19 11:09 ` Arnd Bergmann [not found] ` <201209191109.16529.arnd-r2nGTMty4D4@public.gmane.org> 1 sibling, 1 reply; 39+ messages in thread From: Arnd Bergmann @ 2012-09-19 11:09 UTC (permalink / raw) To: Mitch Bradley Cc: linux-arm-kernel, Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, David Brown, linux-omap, Alexander Schulz On Tuesday 18 September 2012, Mitch Bradley wrote: > There is a delicious irony here with respect to Shark. Shark has real > Open Firmware. It's the platform that I used for the first OFW port to > ARM. We (the Shark design team) had a version of NetBSD that would run > on Shark without any native drivers, calling into the Open Firmware > drivers. It was very useful for bringup. Very interesting, thanks for sharing this bit of history. Are you aware of other ARM systems using open firmware that we still support in Linux (besides the XO-1.75)? > Is there ever a point when old architectures leave the Linux tree, or > will people have to see grep hits from them until the end of time? As long as someone is interested in keeping an architecture or driver alive, it stays. If something is causing problems and we have reason to assume it will never be used again with current kernels, we toss them out. Russell has recently removed support for ARMv3 CPUs, but some of the StrongARM targets (especially SA-1100) are still being actively used, so the CPU support is not going away any time soon. If you have a bunch of Shark machines for testing and would like to port it over to device tree passing from its open firmware, you are definitely welcome ;-) Arnd ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <201209191109.16529.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers [not found] ` <201209191109.16529.arnd-r2nGTMty4D4@public.gmane.org> @ 2012-09-19 14:40 ` Mitch Bradley 0 siblings, 0 replies; 39+ messages in thread From: Mitch Bradley @ 2012-09-19 14:40 UTC (permalink / raw) To: Arnd Bergmann Cc: Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, David Brown, linux-omap, Alexander Schulz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On 9/19/2012 7:09 PM, Arnd Bergmann wrote: > On Tuesday 18 September 2012, Mitch Bradley wrote: >> There is a delicious irony here with respect to Shark. Shark has real >> Open Firmware. It's the platform that I used for the first OFW port to >> ARM. We (the Shark design team) had a version of NetBSD that would run >> on Shark without any native drivers, calling into the Open Firmware >> drivers. It was very useful for bringup. > > Very interesting, thanks for sharing this bit of history. Are you aware > of other ARM systems using open firmware that we still support in Linux > (besides the XO-1.75)? There is the successor to the XO-1.75 that we working on now. I don't know of any others. We just did a big push to convert a bunch of drivers to DT so we will able to use the same kernel on XO-1.75 and XO-4. The conversion went pretty smoothly, but there is still a fair amount of testing, integration, and coordination to do. When things get a bit less hectic, we'll start submitting patches. > >> Is there ever a point when old architectures leave the Linux tree, or >> will people have to see grep hits from them until the end of time? > > As long as someone is interested in keeping an architecture or driver > alive, it stays. If something is causing problems and we have reason > to assume it will never be used again with current kernels, we toss > them out. Russell has recently removed support for ARMv3 CPUs, but > some of the StrongARM targets (especially SA-1100) are still being > actively used, so the CPU support is not going away any time soon. > > If you have a bunch of Shark machines for testing and would like to > port it over to device tree passing from its open firmware, you are > definitely welcome ;-) I'm too busy working on new machines :-) Old machines are an exercise in frustration, due to hardware that stops working over time and insufficient hardware resources to meet the expectations of modern software. Not to mention the financial advantages of doing work that someone cares about ... > > Arnd > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter 2012-09-14 22:46 ` Stephen Warren 2012-09-15 0:14 ` Russell King - ARM Linux @ 2012-09-19 13:52 ` Matt Porter 2012-09-19 14:07 ` Matt Porter 2012-09-19 14:10 ` Rob Herring 4 siblings, 0 replies; 39+ messages in thread From: Matt Porter @ 2012-09-19 13:52 UTC (permalink / raw) To: Jon Hunter Cc: device-tree, linux-omap, linux-arm, Nicolas Ferre, Benoit Cousson, Stephen Warren, Grant Likely, Russell King, Rob Herring, Arnd Bergmann, Vinod Koul, Dan Williams On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: ... Typo nits in the binding examples below... > Documentation/devicetree/bindings/dma/dma.txt | 81 +++++++++ > drivers/of/Makefile | 2 +- > drivers/of/dma.c | 219 +++++++++++++++++++++++++ > include/linux/of_dma.h | 45 +++++ > 4 files changed, 346 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/dma/dma.txt > create mode 100644 drivers/of/dma.c > create mode 100644 include/linux/of_dma.h > > diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt > new file mode 100644 > index 0000000..a4f59a5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/dma.txt > @@ -0,0 +1,81 @@ > +* Generic DMA Controller and DMA request bindings > + > +Generic binding to provide a way for a driver using DMA Engine to retrieve the > +DMA request or channel information that goes from a hardware device to a DMA > +controller. > + > + > +* DMA controller > + > +Required property: > +- #dma-cells: Must be at least 1. Used to provide DMA controller > + specific information. See DMA client binding below for > + more details. > + > +Optional properties: > +- #dma-channels: Number of DMA channels supported by the controller. > +- #dma-requests: Number of DMA requests signals supported by the > + controller. > + > +Example: > + > + dma: dma@48000000 { > + compatible = "ti,omap-sdma" ; here > + reg = <0x48000000 0x1000>; > + interrupts = <0 12 0x4 > + 0 13 0x4 > + 0 14 0x4 > + 0 15 0x4>; > + #dma-cells = <1>; > + #dma-channels = <32>; > + #dma-requests = <127>; > + }; > + > + > +* DMA client > + > +Client drivers should specify the DMA property using a phandle to the controller > +followed by DMA controller specific data. > + > +Required property: > +- dmas: List of one or more DMA specifiers, each consisting of > + - A phandle pointing to DMA controller node > + - A number of integer cells, as determined by the > + #dma-cells property in the node referenced by phandle > + containing DMA controller specific information. This > + typically contains a DMA request line number or a > + channel number, but can contain any data that is used > + required for configuring a channel. > +- dma-names: Contains one identifier string for each DMA specifier in > + the dmas property. The specific strings that can be used > + are defined in the binding of the DMA client device. > + Multiple DMA specifiers can be used to represent > + alternatives and in this case the dma-names for those > + DMA specifiers must be identical (see examples). > + > +Examples: > + > +1. A device with one DMA read channel, one DMA write channel: > + > + i2c1: i2c@1 { > + ... > + dmas = <&dma 2 /* read channel */ > + &dma 3>; /* write channel */ > + dma-names = "rx", "tx" ; here too > + ... > + }; > + > +2. A single read-write channel with three alternative DMA controllers: > + > + dmas = <&dma1 5 > + &dma2 7 > + &dma3 2>; > + dma-names = "rx-tx", "rx-tx", "rx-tx" again ; > + > +3. A device with three channels, one of which has two alternatives: > + > + dmas = <&dma1 2 /* read channel */ > + &dma1 3 /* write channel */ > + &dma2 0 /* error read */ > + &dma3 0>; /* alternative error read */ > + dma-names = "rx", "tx", "error", "error"; Patch for these posted separately. -Matt ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter ` (2 preceding siblings ...) 2012-09-19 13:52 ` Matt Porter @ 2012-09-19 14:07 ` Matt Porter 2012-09-19 14:24 ` Arnd Bergmann 2012-09-19 14:10 ` Rob Herring 4 siblings, 1 reply; 39+ messages in thread From: Matt Porter @ 2012-09-19 14:07 UTC (permalink / raw) To: Jon Hunter Cc: device-tree, linux-omap, linux-arm, Nicolas Ferre, Benoit Cousson, Stephen Warren, Grant Likely, Russell King, Rob Herring, Arnd Bergmann, Vinod Koul, Dan Williams On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt > new file mode 100644 > index 0000000..a4f59a5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/dma.txt > @@ -0,0 +1,81 @@ > +* Generic DMA Controller and DMA request bindings > + > +Generic binding to provide a way for a driver using DMA Engine to retrieve the > +DMA request or channel information that goes from a hardware device to a DMA > +controller. > + > + > +* DMA controller > + > +Required property: > +- #dma-cells: Must be at least 1. Used to provide DMA controller > + specific information. See DMA client binding below for > + more details. > + > +Optional properties: > +- #dma-channels: Number of DMA channels supported by the controller. > +- #dma-requests: Number of DMA requests signals supported by the > + controller. Shouldn't these two optional properties drop the prefix #? By convention adopted from the various original OF/ePAPR/etc specs, the only properties I would expect to see with this prefix are the "*-cells" cell sizes. A quick search indicates this is the case throughout all the current bindings. -Matt ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-19 14:07 ` Matt Porter @ 2012-09-19 14:24 ` Arnd Bergmann 2012-09-19 14:36 ` Rob Herring 2012-09-19 21:25 ` Mitch Bradley 0 siblings, 2 replies; 39+ messages in thread From: Arnd Bergmann @ 2012-09-19 14:24 UTC (permalink / raw) To: Matt Porter Cc: Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King, linux-omap, linux-arm On Wednesday 19 September 2012, Matt Porter wrote: > > +Optional properties: > > +- #dma-channels: Number of DMA channels supported by the controller. > > +- #dma-requests: Number of DMA requests signals supported by the > > + controller. > > Shouldn't these two optional properties drop the prefix #? By > convention adopted from the various original OF/ePAPR/etc specs, the > only properties I would expect to see with this prefix are the > "*-cells" cell sizes. A quick search indicates this is the case > throughout all the current bindings. I always assumed that the # prefix is used to indicate that we are counting things instead of listing them. Arnd ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-19 14:24 ` Arnd Bergmann @ 2012-09-19 14:36 ` Rob Herring 2012-09-19 14:40 ` Matt Porter 2012-09-19 21:25 ` Mitch Bradley 1 sibling, 1 reply; 39+ messages in thread From: Rob Herring @ 2012-09-19 14:36 UTC (permalink / raw) To: Arnd Bergmann Cc: Matt Porter, Jon Hunter, device-tree, linux-omap, linux-arm, Nicolas Ferre, Benoit Cousson, Stephen Warren, Grant Likely, Russell King, Vinod Koul, Dan Williams On 09/19/2012 09:24 AM, Arnd Bergmann wrote: > On Wednesday 19 September 2012, Matt Porter wrote: >>> +Optional properties: >>> +- #dma-channels: Number of DMA channels supported by the controller. >>> +- #dma-requests: Number of DMA requests signals supported by the >>> + controller. >> >> Shouldn't these two optional properties drop the prefix #? By >> convention adopted from the various original OF/ePAPR/etc specs, the >> only properties I would expect to see with this prefix are the >> "*-cells" cell sizes. A quick search indicates this is the case >> throughout all the current bindings. > > I always assumed that the # prefix is used to indicate that we are counting > things instead of listing them. Lots of properties count things, but don't have a #. nr_gpios or spi chipselect counts for example. I'd say drop the #. Rob ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-19 14:36 ` Rob Herring @ 2012-09-19 14:40 ` Matt Porter 2012-09-19 14:50 ` Arnd Bergmann 0 siblings, 1 reply; 39+ messages in thread From: Matt Porter @ 2012-09-19 14:40 UTC (permalink / raw) To: Rob Herring Cc: Arnd Bergmann, Jon Hunter, device-tree, linux-omap, linux-arm, Nicolas Ferre, Benoit Cousson, Stephen Warren, Grant Likely, Russell King, Vinod Koul, Dan Williams On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote: > On 09/19/2012 09:24 AM, Arnd Bergmann wrote: > > On Wednesday 19 September 2012, Matt Porter wrote: > >>> +Optional properties: > >>> +- #dma-channels: Number of DMA channels supported by the controller. > >>> +- #dma-requests: Number of DMA requests signals supported by the > >>> + controller. > >> > >> Shouldn't these two optional properties drop the prefix #? By > >> convention adopted from the various original OF/ePAPR/etc specs, the > >> only properties I would expect to see with this prefix are the > >> "*-cells" cell sizes. A quick search indicates this is the case > >> throughout all the current bindings. > > > > I always assumed that the # prefix is used to indicate that we are counting > > things instead of listing them. > > Lots of properties count things, but don't have a #. nr_gpios or spi > chipselect counts for example. I'd say drop the #. Ok, I can drop another trivial patch since I hear Jon is on vacation. Yeah, I grepped all the bindings and it's only ever encountered on cell sizes. There's not even one example of it used as above. -Matt ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-19 14:40 ` Matt Porter @ 2012-09-19 14:50 ` Arnd Bergmann 0 siblings, 0 replies; 39+ messages in thread From: Arnd Bergmann @ 2012-09-19 14:50 UTC (permalink / raw) To: Matt Porter Cc: Stephen Warren, Vinod Koul, device-tree, Dan Williams, Russell King, linux-omap, linux-arm On Wednesday 19 September 2012, Matt Porter wrote: > On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote: > > On 09/19/2012 09:24 AM, Arnd Bergmann wrote: > > > On Wednesday 19 September 2012, Matt Porter wrote: > > >>> +Optional properties: > > >>> +- #dma-channels: Number of DMA channels supported by the controller. > > >>> +- #dma-requests: Number of DMA requests signals supported by the > > >>> + controller. > > >> > > >> Shouldn't these two optional properties drop the prefix #? By > > >> convention adopted from the various original OF/ePAPR/etc specs, the > > >> only properties I would expect to see with this prefix are the > > >> "*-cells" cell sizes. A quick search indicates this is the case > > >> throughout all the current bindings. > > > > > > I always assumed that the # prefix is used to indicate that we are counting > > > things instead of listing them. > > > > Lots of properties count things, but don't have a #. nr_gpios or spi > > chipselect counts for example. I'd say drop the #. > > Ok, I can drop another trivial patch since I hear Jon is on vacation. > > Yeah, I grepped all the bindings and it's only ever encountered on cell > sizes. There's not even one example of it used as above. Ok, sounds good. Arnd ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-19 14:24 ` Arnd Bergmann 2012-09-19 14:36 ` Rob Herring @ 2012-09-19 21:25 ` Mitch Bradley 1 sibling, 0 replies; 39+ messages in thread From: Mitch Bradley @ 2012-09-19 21:25 UTC (permalink / raw) To: Arnd Bergmann Cc: Matt Porter, Stephen Warren, Vinod Koul, device-tree, Rob Herring, Dan Williams, Russell King, linux-omap, linux-arm On 9/19/2012 10:24 PM, Arnd Bergmann wrote: > On Wednesday 19 September 2012, Matt Porter wrote: >>> +Optional properties: >>> +- #dma-channels: Number of DMA channels supported by the controller. >>> +- #dma-requests: Number of DMA requests signals supported by the >>> + controller. >> >> Shouldn't these two optional properties drop the prefix #? By >> convention adopted from the various original OF/ePAPR/etc specs, the >> only properties I would expect to see with this prefix are the >> "*-cells" cell sizes. A quick search indicates this is the case >> throughout all the current bindings. > > I always assumed that the # prefix is used to indicate that we are counting > things instead of listing them. Your assumption is historically correct. It seems that usage has drifted somewhat. > > Arnd > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers 2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter ` (3 preceding siblings ...) 2012-09-19 14:07 ` Matt Porter @ 2012-09-19 14:10 ` Rob Herring 4 siblings, 0 replies; 39+ messages in thread From: Rob Herring @ 2012-09-19 14:10 UTC (permalink / raw) To: Jon Hunter Cc: device-tree, linux-omap, linux-arm, Stephen Warren, Vinod Koul, Rob Herring, Dan Williams, Russell King On 09/14/2012 05:41 PM, Jon Hunter wrote: > 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. [snip] > Reviewed-by: Arnd Bergmann <arnd@arndb.de> > Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com> > Signed-off-by: Jon Hunter <jon-hunter@ti.com> > --- > Documentation/devicetree/bindings/dma/dma.txt | 81 +++++++++ > drivers/of/Makefile | 2 +- > drivers/of/dma.c | 219 +++++++++++++++++++++++++ We've been moving in the direction of not putting subsystem related code under drivers/of, but rather with the subsystem. Although in some cases (i2c), the maintainers didn't want the OF code there. In any case, I guess this will go thru Vinod's tree, so: Acked-by: Rob Herring <rob.herring@calxeda.com> ^ permalink raw reply [flat|nested] 39+ messages in thread
[parent not found: <1347662517-4210-1-git-send-email-jon-hunter-l0cyMroinI0@public.gmane.org>]
* [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel [not found] ` <1347662517-4210-1-git-send-email-jon-hunter-l0cyMroinI0@public.gmane.org> @ 2012-09-14 22:41 ` Jon Hunter 2012-09-17 3:33 ` Vinod Koul 0 siblings, 1 reply; 39+ messages in thread From: Jon Hunter @ 2012-09-14 22:41 UTC (permalink / raw) To: device-tree, linux-omap, linux-arm Cc: Stephen Warren, Vinod Koul, Rob Herring, Dan Williams, Russell King Currently slave DMA channels are requested by calling dma_request_channel() and requires DMA clients to pass various filter parameters to obtain the appropriate channel. With device-tree being used by architectures such as arm and the addition of device-tree helper functions to extract the relevant DMA client information from device-tree, add a new function to request a slave DMA channel using device-tree. This function is currently a simple wrapper that calls the device-tree of_dma_request_slave_channel() function. Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org> Cc: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org> Cc: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> Cc: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Cc: Dan Williams <djbw-b10kYP2dOMg@public.gmane.org> Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> Signed-off-by: Jon Hunter <jon-hunter-l0cyMroinI0@public.gmane.org> --- drivers/dma/dmaengine.c | 16 ++++++++++++++++ include/linux/dmaengine.h | 6 ++++++ 2 files changed, 22 insertions(+) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index 3491654..9b466da 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -62,6 +62,7 @@ #include <linux/rculist.h> #include <linux/idr.h> #include <linux/slab.h> +#include <linux/of_dma.h> static DEFINE_MUTEX(dma_list_mutex); static DEFINE_IDR(dma_idr); @@ -546,6 +547,21 @@ struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn, v } EXPORT_SYMBOL_GPL(__dma_request_channel); +/** + * dma_request_slave_channel - try to allocate an exclusive slave channel + * @dev: pointer to client device structure + * @name: slave channel name + */ +struct dma_chan *dma_request_slave_channel(struct device *dev, char *name) +{ + /* If device-tree is present get slave info from here */ + if (dev->of_node) + return of_dma_request_slave_channel(dev->of_node, name); + + return NULL; +} +EXPORT_SYMBOL_GPL(dma_request_slave_channel); + void dma_release_channel(struct dma_chan *chan) { mutex_lock(&dma_list_mutex); diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index 9c02a45..9500aa5 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -973,6 +973,7 @@ enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie); enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx); void dma_issue_pending_all(void); struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param); +struct dma_chan *dma_request_slave_channel(struct device *dev, char *name); void dma_release_channel(struct dma_chan *chan); #else static inline enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx) @@ -987,6 +988,11 @@ static inline struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, { return NULL; } +static inline struct dma_chan *dma_request_slave_channel(struct device *dev, + char *name) +{ + return NULL +} static inline void dma_release_channel(struct dma_chan *chan) { } -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-14 22:41 ` [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel Jon Hunter @ 2012-09-17 3:33 ` Vinod Koul 2012-09-17 11:59 ` Arnd Bergmann 0 siblings, 1 reply; 39+ messages in thread From: Vinod Koul @ 2012-09-17 3:33 UTC (permalink / raw) To: Jon Hunter Cc: device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Arnd Bergmann, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams, Russell King On Fri, 2012-09-14 at 17:41 -0500, Jon Hunter wrote: > +/** > + * dma_request_slave_channel - try to allocate an exclusive slave > channel > + * @dev: pointer to client device structure > + * @name: slave channel name > + */ > +struct dma_chan *dma_request_slave_channel(struct device *dev, char *name) > +{ > + /* If device-tree is present get slave info from here */ > + if (dev->of_node) > + return of_dma_request_slave_channel(dev->of_node, name); > + Shouldn't this be conditionally compiled only when OF is built. I think this might be problematic for systems which doesn't have device tree. Or perhaps you can declare these symbols as dummy in of_dma.h when device tree is not selected. > + return NULL; > +} > +EXPORT_SYMBOL_GPL(dma_request_slave_channel); -- ~Vinod ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-17 3:33 ` Vinod Koul @ 2012-09-17 11:59 ` Arnd Bergmann 2012-09-17 22:36 ` Russell King - ARM Linux 2012-09-18 3:00 ` Vinod Koul 0 siblings, 2 replies; 39+ messages in thread From: Arnd Bergmann @ 2012-09-17 11:59 UTC (permalink / raw) To: Vinod Koul Cc: Jon Hunter, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams, Russell King On Monday 17 September 2012, Vinod Koul wrote: > On Fri, 2012-09-14 at 17:41 -0500, Jon Hunter wrote: > > +/** > > + * dma_request_slave_channel - try to allocate an exclusive slave > > channel > > + * @dev: pointer to client device structure > > + * @name: slave channel name > > + */ > > +struct dma_chan *dma_request_slave_channel(struct device *dev, char *name) > > +{ > > + /* If device-tree is present get slave info from here */ > > + if (dev->of_node) > > + return of_dma_request_slave_channel(dev->of_node, name); > > + > Shouldn't this be conditionally compiled only when OF is built. I think > this might be problematic for systems which doesn't have device tree. > Or perhaps you can declare these symbols as dummy in of_dma.h when > device tree is not selected. Right, good point. I'd prefer the dummy functions, since that is in line with what a lot of other subsystems do: #ifdef CONFIG_OF extern int of_dma_controller_register(struct device_node *np, struct dma_chan *(*of_dma_xlate) (struct of_phandle_args *, struct of_dma *), void *data); extern void of_dma_controller_free(struct device_node *np); extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np, char *name); extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, struct of_dma *ofdma); #else static inline int of_dma_controller_register(struct device_node *np, struct dma_chan *(*of_dma_xlate) (struct of_phandle_args *, struct of_dma *), void *data) { return -ENODEV; } static inline void of_dma_controller_free(struct device_node *np) { } static inline struct dma_chan *of_dma_request_slave_channel(struct device_node *np, char *name) { return NULL; } static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, struct of_dma *ofdma) { return NULL; } #endif I believe that Jon is on vacation this week, so if this is the only issue holding up the merge, maybe you can change this in his patch directly, or I can send an updated version if you prefer. Arnd ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-17 11:59 ` Arnd Bergmann @ 2012-09-17 22:36 ` Russell King - ARM Linux 2012-09-18 3:13 ` Vinod Koul 2012-09-18 3:00 ` Vinod Koul 1 sibling, 1 reply; 39+ messages in thread From: Russell King - ARM Linux @ 2012-09-17 22:36 UTC (permalink / raw) To: Arnd Bergmann Cc: Vinod Koul, Jon Hunter, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams On Mon, Sep 17, 2012 at 11:59:27AM +0000, Arnd Bergmann wrote: > On Monday 17 September 2012, Vinod Koul wrote: > > On Fri, 2012-09-14 at 17:41 -0500, Jon Hunter wrote: > > > +/** > > > + * dma_request_slave_channel - try to allocate an exclusive slave > > > channel > > > + * @dev: pointer to client device structure > > > + * @name: slave channel name > > > + */ > > > +struct dma_chan *dma_request_slave_channel(struct device *dev, char *name) > > > +{ > > > + /* If device-tree is present get slave info from here */ > > > + if (dev->of_node) > > > + return of_dma_request_slave_channel(dev->of_node, name); > > > + > > Shouldn't this be conditionally compiled only when OF is built. I think > > this might be problematic for systems which doesn't have device tree. > > Or perhaps you can declare these symbols as dummy in of_dma.h when > > device tree is not selected. > > Right, good point. I'd prefer the dummy functions, since that is in line > with what a lot of other subsystems do: > > #ifdef CONFIG_OF > extern int of_dma_controller_register(struct device_node *np, > struct dma_chan *(*of_dma_xlate) > (struct of_phandle_args *, struct of_dma *), > void *data); > extern void of_dma_controller_free(struct device_node *np); > extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np, > char *name); > extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, > struct of_dma *ofdma); > #else > static inline int of_dma_controller_register(struct device_node *np, > struct dma_chan *(*of_dma_xlate) > (struct of_phandle_args *, struct of_dma *), > void *data) > { > return -ENODEV; > } > static inline void of_dma_controller_free(struct device_node *np) > { > } > static inline struct dma_chan *of_dma_request_slave_channel(struct device_node *np, > char *name) > { > return NULL; > } > static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, > struct of_dma *ofdma) > { > return NULL; > } > #endif > > I believe that Jon is on vacation this week, so if this is the only issue > holding up the merge, maybe you can change this in his patch directly, or > I can send an updated version if you prefer. I worry that too much is going on here too quickly. We have some people working on changing the way DMA engine selects channels. Meanwhile we have other people trying to create an OF DMA engine API. It seems that Vinod's working on a way for platforms to specify bindings to the DMA engine code, and the DMA engine code itself selects the appropriate channel. This patch, on the other hand, introduces a set of translation functions which need to be provided by platform code, which returns the dma_chan pointer. This sounds like a recipe for a total abortion of interfaces. Only one of those two activities should be going on at any one time, or if they have to occur, they need coordination so that the we don't end up with two totally different schemes. In the mad rush to DTify everything, don't make hasty decisions, because it is very difficult to change it later - especially something like this which defines how DT encodes this information. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-17 22:36 ` Russell King - ARM Linux @ 2012-09-18 3:13 ` Vinod Koul 2012-09-18 13:21 ` Matt Porter 2012-09-24 22:25 ` Jon Hunter 0 siblings, 2 replies; 39+ messages in thread From: Vinod Koul @ 2012-09-18 3:13 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Arnd Bergmann, Jon Hunter, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams On Mon, 2012-09-17 at 23:36 +0100, Russell King - ARM Linux wrote: > > > > I believe that Jon is on vacation this week, so if this is the only issue > > holding up the merge, maybe you can change this in his patch directly, or > > I can send an updated version if you prefer. > > I worry that too much is going on here too quickly. We have some people > working on changing the way DMA engine selects channels. Meanwhile we > have other people trying to create an OF DMA engine API. > > It seems that Vinod's working on a way for platforms to specify bindings > to the DMA engine code, and the DMA engine code itself selects the > appropriate channel. This patch, on the other hand, introduces a set of > translation functions which need to be provided by platform code, > which returns the dma_chan pointer. > > This sounds like a recipe for a total abortion of interfaces. Only one > of those two activities should be going on at any one time, or if they > have to occur, they need coordination so that the we don't end up with > two totally different schemes. > > In the mad rush to DTify everything, don't make hasty decisions, because > it is very difficult to change it later - especially something like this > which defines how DT encodes this information. We discussed this in KS and IMHO we need to merge these two approaches. For DT bindings, I think the binding itself shouldn't change based on my work but I would like these same bindings to help build the DMA engine code mappings. Now would it make sense to NOT merge these changes for 3.7 and postpone to 3.8. I can host these patches on a topic branch and merge them when we are ready. I plan to spend some good amount of time on my work this week so we should be ready pretty soon. One these changes are merged, users can start moving to this scheme. -- ~Vinod ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-18 3:13 ` Vinod Koul @ 2012-09-18 13:21 ` Matt Porter 2012-09-18 15:20 ` Arnd Bergmann 2012-09-24 22:25 ` Jon Hunter 1 sibling, 1 reply; 39+ messages in thread From: Matt Porter @ 2012-09-18 13:21 UTC (permalink / raw) To: Vinod Koul Cc: Russell King - ARM Linux, Arnd Bergmann, Jon Hunter, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams On Tue, Sep 18, 2012 at 08:43:55AM +0530, Vinod Koul wrote: > On Mon, 2012-09-17 at 23:36 +0100, Russell King - ARM Linux wrote: > > > > > > I believe that Jon is on vacation this week, so if this is the only issue > > > holding up the merge, maybe you can change this in his patch directly, or > > > I can send an updated version if you prefer. > > > > I worry that too much is going on here too quickly. We have some people > > working on changing the way DMA engine selects channels. Meanwhile we > > have other people trying to create an OF DMA engine API. > > > > It seems that Vinod's working on a way for platforms to specify bindings > > to the DMA engine code, and the DMA engine code itself selects the > > appropriate channel. This patch, on the other hand, introduces a set of > > translation functions which need to be provided by platform code, > > which returns the dma_chan pointer. > > > > This sounds like a recipe for a total abortion of interfaces. Only one > > of those two activities should be going on at any one time, or if they > > have to occur, they need coordination so that the we don't end up with > > two totally different schemes. > > > > In the mad rush to DTify everything, don't make hasty decisions, because > > it is very difficult to change it later - especially something like this > > which defines how DT encodes this information. > We discussed this in KS and IMHO we need to merge these two approaches. > > For DT bindings, I think the binding itself shouldn't change based on my > work but I would like these same bindings to help build the DMA engine > code mappings. > > Now would it make sense to NOT merge these changes for 3.7 and postpone > to 3.8. I can host these patches on a topic branch and merge them when > we are ready. I plan to spend some good amount of time on my work this > week so we should be ready pretty soon. > One these changes are merged, users can start moving to this scheme. FWIW, I'm already basing the EDMA dmaengine support for OMAP (specifically for AM335x) on using these helpers since AM335x *only* boots from DT. -Matt ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-18 13:21 ` Matt Porter @ 2012-09-18 15:20 ` Arnd Bergmann 2012-09-18 18:10 ` Russell King - ARM Linux 0 siblings, 1 reply; 39+ messages in thread From: Arnd Bergmann @ 2012-09-18 15:20 UTC (permalink / raw) To: Matt Porter Cc: Vinod Koul, Russell King - ARM Linux, device-tree, Rob Herring, Dan Williams, Stephen Warren, linux-omap, linux-arm On Tuesday 18 September 2012, Matt Porter wrote: > On Tue, Sep 18, 2012 at 08:43:55AM +0530, Vinod Koul wrote: > > > > Now would it make sense to NOT merge these changes for 3.7 and postpone > > to 3.8. I can host these patches on a topic branch and merge them when > > we are ready. I plan to spend some good amount of time on my work this > > week so we should be ready pretty soon. > > One these changes are merged, users can start moving to this scheme. > > FWIW, I'm already basing the EDMA dmaengine support for OMAP (specifically > for AM335x) on using these helpers since AM335x only boots from DT. I suspect the same thing will be happening for a lot of platforms after 3.7-rc1: ux500, lpc32xx, integrator, imx, mxs and probably others are all waiting for this so they can complete the move to DT-only booting. Having some support for the new binding in 3.7 would be a great help to reduce interdependencies for the 3.8 merge cycle. Both the driver interface and the binding should actually be in a good shape now, so I'd very much appriciate it getting merged for 3.7, even if the implementation may have to change again in 3.8. Arnd ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-18 15:20 ` Arnd Bergmann @ 2012-09-18 18:10 ` Russell King - ARM Linux 0 siblings, 0 replies; 39+ messages in thread From: Russell King - ARM Linux @ 2012-09-18 18:10 UTC (permalink / raw) To: Arnd Bergmann Cc: Matt Porter, Vinod Koul, Jon Hunter, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams On Tue, Sep 18, 2012 at 03:20:08PM +0000, Arnd Bergmann wrote: > On Tuesday 18 September 2012, Matt Porter wrote: > > FWIW, I'm already basing the EDMA dmaengine support for OMAP (specifically > > for AM335x) on using these helpers since AM335x only boots from DT. > > I suspect the same thing will be happening for a lot of platforms > after 3.7-rc1: ux500, lpc32xx, integrator, imx, mxs and probably > others are all waiting for this so they can complete the move > to DT-only booting. Integrator won't be, because no integrator platforms have DMA support. That only came in with the Versatile range, of which it's extremely dodgy and unreliable to use. So in general, ARMs platforms do not have working DMA support. (I actually carry a private patch set which does enable full support on Versatile platforms, but given the general brokenness of the platform I see no reason to merge it and cause people issues with the platform when they find out that DMA is broken in weird and wonderful ways depending on the FPGA build they've happened to end up with...) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-18 3:13 ` Vinod Koul 2012-09-18 13:21 ` Matt Porter @ 2012-09-24 22:25 ` Jon Hunter 2012-09-25 4:35 ` Vinod Koul 1 sibling, 1 reply; 39+ messages in thread From: Jon Hunter @ 2012-09-24 22:25 UTC (permalink / raw) To: Vinod Koul Cc: Russell King - ARM Linux, Arnd Bergmann, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams Hi Vinod, On 09/17/2012 10:13 PM, Vinod Koul wrote: > On Mon, 2012-09-17 at 23:36 +0100, Russell King - ARM Linux wrote: >>> >>> I believe that Jon is on vacation this week, so if this is the only issue >>> holding up the merge, maybe you can change this in his patch directly, or >>> I can send an updated version if you prefer. >> >> I worry that too much is going on here too quickly. We have some people >> working on changing the way DMA engine selects channels. Meanwhile we >> have other people trying to create an OF DMA engine API. >> >> It seems that Vinod's working on a way for platforms to specify bindings >> to the DMA engine code, and the DMA engine code itself selects the >> appropriate channel. This patch, on the other hand, introduces a set of >> translation functions which need to be provided by platform code, >> which returns the dma_chan pointer. >> >> This sounds like a recipe for a total abortion of interfaces. Only one >> of those two activities should be going on at any one time, or if they >> have to occur, they need coordination so that the we don't end up with >> two totally different schemes. >> >> In the mad rush to DTify everything, don't make hasty decisions, because >> it is very difficult to change it later - especially something like this >> which defines how DT encodes this information. > We discussed this in KS and IMHO we need to merge these two approaches. > > For DT bindings, I think the binding itself shouldn't change based on my > work but I would like these same bindings to help build the DMA engine > code mappings. > > Now would it make sense to NOT merge these changes for 3.7 and postpone > to 3.8. I can host these patches on a topic branch and merge them when > we are ready. I plan to spend some good amount of time on my work this > week so we should be ready pretty soon. > One these changes are merged, users can start moving to this scheme. I just wanted to see how things are progressing your side. Did you create a topic branch for this? If so let me know where I can find it, I did not find a branch on your infradead git tree. I wanted to pull in the latest patches for some testing. Cheers Jon ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-24 22:25 ` Jon Hunter @ 2012-09-25 4:35 ` Vinod Koul 2012-10-16 2:43 ` Shawn Guo 0 siblings, 1 reply; 39+ messages in thread From: Vinod Koul @ 2012-09-25 4:35 UTC (permalink / raw) To: Jon Hunter Cc: Russell King - ARM Linux, Arnd Bergmann, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams On Mon, 2012-09-24 at 17:25 -0500, Jon Hunter wrote: > > For DT bindings, I think the binding itself shouldn't change based on my > > work but I would like these same bindings to help build the DMA engine > > code mappings. > > > > Now would it make sense to NOT merge these changes for 3.7 and postpone > > to 3.8. I can host these patches on a topic branch and merge them when > > we are ready. I plan to spend some good amount of time on my work this > > week so we should be ready pretty soon. > > One these changes are merged, users can start moving to this scheme. > > I just wanted to see how things are progressing your side. Did you > create a topic branch for this? If so let me know where I can find it, I > did not find a branch on your infradead git tree. > > I wanted to pull in the latest patches for some testing. Sorry for delay, I had everything ready, but couldn't manage to commit and push. I have pushed to topic/dmaengine_dt, it is pushing out now... This has your two patches, my fix for build breakage, and Matt's typo patch. This is based on my next. -- ~Vinod ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-25 4:35 ` Vinod Koul @ 2012-10-16 2:43 ` Shawn Guo 2012-10-16 2:39 ` Vinod Koul 0 siblings, 1 reply; 39+ messages in thread From: Shawn Guo @ 2012-10-16 2:43 UTC (permalink / raw) To: Vinod Koul Cc: Jon Hunter, Stephen Warren, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm On Tue, Sep 25, 2012 at 10:05:01AM +0530, Vinod Koul wrote: > On Mon, 2012-09-24 at 17:25 -0500, Jon Hunter wrote: > > > For DT bindings, I think the binding itself shouldn't change based on my > > > work but I would like these same bindings to help build the DMA engine > > > code mappings. > > > > > > Now would it make sense to NOT merge these changes for 3.7 and postpone > > > to 3.8. I can host these patches on a topic branch and merge them when > > > we are ready. I plan to spend some good amount of time on my work this > > > week so we should be ready pretty soon. > > > One these changes are merged, users can start moving to this scheme. > > > > I just wanted to see how things are progressing your side. Did you > > create a topic branch for this? If so let me know where I can find it, I > > did not find a branch on your infradead git tree. > > > > I wanted to pull in the latest patches for some testing. > Sorry for delay, I had everything ready, but couldn't manage to commit > and push. I have pushed to topic/dmaengine_dt, it is pushing out now... > Vinod, Looks it seemed 3.7-rc1. Does that mean we have to wait for 3.8, or will it show on later -rc for 3.7? Shawn ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-10-16 2:43 ` Shawn Guo @ 2012-10-16 2:39 ` Vinod Koul 2012-11-09 20:01 ` Jon Hunter 0 siblings, 1 reply; 39+ messages in thread From: Vinod Koul @ 2012-10-16 2:39 UTC (permalink / raw) To: Shawn Guo Cc: Jon Hunter, Stephen Warren, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm On Tue, 2012-10-16 at 10:43 +0800, Shawn Guo wrote: > On Tue, Sep 25, 2012 at 10:05:01AM +0530, Vinod Koul wrote: > > On Mon, 2012-09-24 at 17:25 -0500, Jon Hunter wrote: > > > > For DT bindings, I think the binding itself shouldn't change based on my > > > > work but I would like these same bindings to help build the DMA engine > > > > code mappings. > > > > > > > > Now would it make sense to NOT merge these changes for 3.7 and postpone > > > > to 3.8. I can host these patches on a topic branch and merge them when > > > > we are ready. I plan to spend some good amount of time on my work this > > > > week so we should be ready pretty soon. > > > > One these changes are merged, users can start moving to this scheme. > > > > > > I just wanted to see how things are progressing your side. Did you > > > create a topic branch for this? If so let me know where I can find it, I > > > did not find a branch on your infradead git tree. > > > > > > I wanted to pull in the latest patches for some testing. > > Sorry for delay, I had everything ready, but couldn't manage to commit > > and push. I have pushed to topic/dmaengine_dt, it is pushing out now... > > > Vinod, > > Looks it seemed 3.7-rc1. Does that mean we have to wait for 3.8, or > will it show on later -rc for 3.7? Yes this will be merged once we work out the common interface, otherwise we will end up redoing interfaces for all drivers. -- ~Vinod ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-10-16 2:39 ` Vinod Koul @ 2012-11-09 20:01 ` Jon Hunter 2012-11-16 1:37 ` Vinod Koul 0 siblings, 1 reply; 39+ messages in thread From: Jon Hunter @ 2012-11-09 20:01 UTC (permalink / raw) To: Vinod Koul Cc: Shawn Guo, Stephen Warren, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm On 10/15/2012 09:39 PM, Vinod Koul wrote: > On Tue, 2012-10-16 at 10:43 +0800, Shawn Guo wrote: >> On Tue, Sep 25, 2012 at 10:05:01AM +0530, Vinod Koul wrote: >>> On Mon, 2012-09-24 at 17:25 -0500, Jon Hunter wrote: >>>>> For DT bindings, I think the binding itself shouldn't change based on my >>>>> work but I would like these same bindings to help build the DMA engine >>>>> code mappings. >>>>> >>>>> Now would it make sense to NOT merge these changes for 3.7 and postpone >>>>> to 3.8. I can host these patches on a topic branch and merge them when >>>>> we are ready. I plan to spend some good amount of time on my work this >>>>> week so we should be ready pretty soon. >>>>> One these changes are merged, users can start moving to this scheme. >>>> >>>> I just wanted to see how things are progressing your side. Did you >>>> create a topic branch for this? If so let me know where I can find it, I >>>> did not find a branch on your infradead git tree. >>>> >>>> I wanted to pull in the latest patches for some testing. >>> Sorry for delay, I had everything ready, but couldn't manage to commit >>> and push. I have pushed to topic/dmaengine_dt, it is pushing out now... >>> >> Vinod, >> >> Looks it seemed 3.7-rc1. Does that mean we have to wait for 3.8, or >> will it show on later -rc for 3.7? > Yes this will be merged once we work out the common interface, otherwise > we will end up redoing interfaces for all drivers. Hi Vinod, A few people have been asking me if getting device-tree support for DMA engine is plan for record for v3.8. I know that you were working through implementing a common interface and so I wanted to check how that is going. Do you have any insight to when device-tree support may get added? Cheers Jon ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-11-09 20:01 ` Jon Hunter @ 2012-11-16 1:37 ` Vinod Koul 2012-11-16 8:39 ` Nicolas Ferre ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Vinod Koul @ 2012-11-16 1:37 UTC (permalink / raw) To: Jon Hunter Cc: Shawn Guo, Stephen Warren, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: > Hi Vinod, > > A few people have been asking me if getting device-tree support for DMA > engine is plan for record for v3.8. I know that you were working through > implementing a common interface and so I wanted to check how that is > going. Do you have any insight to when device-tree support may get added? > I have not been able to do much work on this for last couple of weeks. I hope to do it in by this weekend. If not I will merge yours and then uppdate. Anyway, DT would be there in 3.8 with or without my changes. -- ~Vinod ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-11-16 1:37 ` Vinod Koul @ 2012-11-16 8:39 ` Nicolas Ferre 2012-11-16 15:45 ` Jon Hunter 2012-12-19 17:12 ` Jon Hunter 2 siblings, 0 replies; 39+ messages in thread From: Nicolas Ferre @ 2012-11-16 8:39 UTC (permalink / raw) To: Vinod Koul Cc: Jon Hunter, linux-omap, Russell King - ARM Linux, device-tree, Rob Herring, Dan Williams, Stephen Warren, linux-arm On 11/16/2012 02:37 AM, Vinod Koul : > On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: >> Hi Vinod, >> >> A few people have been asking me if getting device-tree support for DMA >> engine is plan for record for v3.8. I know that you were working through >> implementing a common interface and so I wanted to check how that is >> going. Do you have any insight to when device-tree support may get added? >> > I have not been able to do much work on this for last couple of weeks. I > hope to do it in by this weekend. If not I will merge yours and then > uppdate. > > Anyway, DT would be there in 3.8 with or without my changes. Vinod, So, can we imagine having this tree in linux-next rapidly (with or without your changes)? Thanks, best regards, -- Nicolas Ferre ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-11-16 1:37 ` Vinod Koul 2012-11-16 8:39 ` Nicolas Ferre @ 2012-11-16 15:45 ` Jon Hunter 2012-11-28 17:06 ` Vinod Koul 2012-12-19 17:12 ` Jon Hunter 2 siblings, 1 reply; 39+ messages in thread From: Jon Hunter @ 2012-11-16 15:45 UTC (permalink / raw) To: Vinod Koul Cc: Shawn Guo, Stephen Warren, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm On 11/15/2012 07:37 PM, Vinod Koul wrote: > On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: >> Hi Vinod, >> >> A few people have been asking me if getting device-tree support for DMA >> engine is plan for record for v3.8. I know that you were working through >> implementing a common interface and so I wanted to check how that is >> going. Do you have any insight to when device-tree support may get added? >> > I have not been able to do much work on this for last couple of weeks. I > hope to do it in by this weekend. If not I will merge yours and then > uppdate. > > Anyway, DT would be there in 3.8 with or without my changes. Thanks, Vinod. Can you make sure you also pick up the two fixes [1][2] I sent out? Cheers Jon [1] http://marc.info/?l=linux-omap&m=134859981920598&w=2 [2] http://marc.info/?l=linux-omap&m=134998461526129&w=2 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-11-16 15:45 ` Jon Hunter @ 2012-11-28 17:06 ` Vinod Koul 0 siblings, 0 replies; 39+ messages in thread From: Vinod Koul @ 2012-11-28 17:06 UTC (permalink / raw) To: Jon Hunter Cc: vinod.koul, linux-omap, Russell King - ARM Linux, device-tree, Rob Herring, Dan Williams, Stephen Warren, Shawn Guo, linux-arm On Fri, 2012-11-16 at 09:45 -0600, Jon Hunter wrote: > > Thanks, Vinod. Can you make sure you also pick up the two fixes [1][2] > I sent out? > > Cheers > Jon > > [1] http://marc.info/?l=linux-omap&m=134859981920598&w=2 > [2] http://marc.info/?l=linux-omap&m=134998461526129&w=2 > Applied both and merged the branch to my next. It should show up in linux-next tomorrow Please check Thanks -- Vinod Koul Intel Corp. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-11-16 1:37 ` Vinod Koul 2012-11-16 8:39 ` Nicolas Ferre 2012-11-16 15:45 ` Jon Hunter @ 2012-12-19 17:12 ` Jon Hunter 2012-12-20 14:57 ` Vinod Koul 2 siblings, 1 reply; 39+ messages in thread From: Jon Hunter @ 2012-12-19 17:12 UTC (permalink / raw) To: Vinod Koul Cc: Shawn Guo, Stephen Warren, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm Hi Vinod, On 11/15/2012 07:37 PM, Vinod Koul wrote: > On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: >> Hi Vinod, >> >> A few people have been asking me if getting device-tree support for DMA >> engine is plan for record for v3.8. I know that you were working through >> implementing a common interface and so I wanted to check how that is >> going. Do you have any insight to when device-tree support may get added? >> > I have not been able to do much work on this for last couple of weeks. I > hope to do it in by this weekend. If not I will merge yours and then > uppdate. > > Anyway, DT would be there in 3.8 with or without my changes. I am not sure if I have missed your pull request, but wanted to see if you had or were going to send a pull request for the DT changes for v3.8? I believe that the merge window ends this week. Cheers Jon ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-12-19 17:12 ` Jon Hunter @ 2012-12-20 14:57 ` Vinod Koul 0 siblings, 0 replies; 39+ messages in thread From: Vinod Koul @ 2012-12-20 14:57 UTC (permalink / raw) To: Jon Hunter Cc: vinod.koul, Shawn Guo, Stephen Warren, device-tree, Rob Herring, Dan Williams, Russell King - ARM Linux, linux-omap, linux-arm On Wed, 2012-12-19 at 11:12 -0600, Jon Hunter wrote: > I am not sure if I have missed your pull request, but wanted to see if > you had or were going to send a pull request for the DT changes for > v3.8? I believe that the merge window ends this week. Not yet sent. I was waiting on Dan's changes, just merged and pushed those. Pull request should show up in couple of days. Thanks -- Vinod Koul Intel Corp. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel 2012-09-17 11:59 ` Arnd Bergmann 2012-09-17 22:36 ` Russell King - ARM Linux @ 2012-09-18 3:00 ` Vinod Koul 1 sibling, 0 replies; 39+ messages in thread From: Vinod Koul @ 2012-09-18 3:00 UTC (permalink / raw) To: Arnd Bergmann Cc: Jon Hunter, device-tree, linux-omap, linux-arm, Stephen Warren, Benoit Cousson, Nicolas Ferre, Rob Herring, Grant Likely, Dan Williams, Russell King On Mon, 2012-09-17 at 11:59 +0000, Arnd Bergmann wrote: > On Monday 17 September 2012, Vinod Koul wrote: > > I believe that Jon is on vacation this week, so if this is the only issue > holding up the merge, maybe you can change this in his patch directly, or > I can send an updated version if you prefer. Yes that was my idea as well, we do similar stuff in dmaengine. Okay I think we are good for merging this, I will add the patch for this as well. If anyone has objection please speak up _now_ -- ~Vinod ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2012-12-20 14:57 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-09-14 22:41 [PATCH V6 0/2] of: Add generic device tree DMA helpers Jon Hunter 2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter 2012-09-14 22:46 ` Stephen Warren 2012-09-15 0:14 ` Russell King - ARM Linux [not found] ` <20120915001431.GB12445-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2012-09-17 20:42 ` Arnd Bergmann [not found] ` <201209172042.11860.arnd-r2nGTMty4D4@public.gmane.org> 2012-09-17 23:06 ` David Brown [not found] ` <20120917230615.GA26502-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2012-09-18 12:50 ` Arnd Bergmann 2012-09-18 22:19 ` Mitch Bradley [not found] ` <5058F35A.8040702-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2012-09-18 22:32 ` Russell King - ARM Linux 2012-09-19 11:09 ` Arnd Bergmann [not found] ` <201209191109.16529.arnd-r2nGTMty4D4@public.gmane.org> 2012-09-19 14:40 ` Mitch Bradley 2012-09-19 13:52 ` Matt Porter 2012-09-19 14:07 ` Matt Porter 2012-09-19 14:24 ` Arnd Bergmann 2012-09-19 14:36 ` Rob Herring 2012-09-19 14:40 ` Matt Porter 2012-09-19 14:50 ` Arnd Bergmann 2012-09-19 21:25 ` Mitch Bradley 2012-09-19 14:10 ` Rob Herring [not found] ` <1347662517-4210-1-git-send-email-jon-hunter-l0cyMroinI0@public.gmane.org> 2012-09-14 22:41 ` [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel Jon Hunter 2012-09-17 3:33 ` Vinod Koul 2012-09-17 11:59 ` Arnd Bergmann 2012-09-17 22:36 ` Russell King - ARM Linux 2012-09-18 3:13 ` Vinod Koul 2012-09-18 13:21 ` Matt Porter 2012-09-18 15:20 ` Arnd Bergmann 2012-09-18 18:10 ` Russell King - ARM Linux 2012-09-24 22:25 ` Jon Hunter 2012-09-25 4:35 ` Vinod Koul 2012-10-16 2:43 ` Shawn Guo 2012-10-16 2:39 ` Vinod Koul 2012-11-09 20:01 ` Jon Hunter 2012-11-16 1:37 ` Vinod Koul 2012-11-16 8:39 ` Nicolas Ferre 2012-11-16 15:45 ` Jon Hunter 2012-11-28 17:06 ` Vinod Koul 2012-12-19 17:12 ` Jon Hunter 2012-12-20 14:57 ` Vinod Koul 2012-09-18 3:00 ` Vinod Koul
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).