{"push_id":800013403,"size":795,"distinct_size":795,"ref":"refs/heads/3.8","head":"3bbe7e4f59e5092b97909e20d51f35c8c9a29f7a","before":"1dd7ab28af8ef80e0c82a4620b790f26729adf03","commits":[{"sha":"97fef9938ed0bfa526613e688463bed7550ff825","author":{"email":"4f3b1600df7149f497143de91f9544f58c8925ec@ti.com","name":"hvaibhav@ti.com"},"message":"Without MACH_ option Early printk (DEBUG_LL)\n\nOn Fri, Aug 31, 2012 at 22:07:37, Hiremath, Vaibhav wrote:\n> On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote:\n> > * Hiremath, Vaibhav <hvaibhav@ti.com> [120831 09:06]:\n> > > On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:\n> > > > * Vaibhav Hiremath <hvaibhav@ti.com> [120831 07:55]:\n> > > > > Hi Russell & Tony,\n> > > > >\n> > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and\n> > > > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during\n> > > > > baseport submission we had aligned that, we won't create separate EVM\n> > > > > options, killing the board file all-together.\n> > > > >\n> > > > > Having said that, the early printk option (DEBUG_LL) is broken, the\n> > > > > auto-generated file \"./include/generated/mach-types.h\" still refers to\n> > > > > CONFIG_MACH_AM335XEVM option,\n> > > >\n> > > > The way we're heading is that the DEBUG_LL options will only work for\n> > > > one hardcoded machine where you need to select the uart type and address\n> > > > in Kconfig. Or just patch it in.\n> > > >\n> > > > > #ifdef CONFIG_MACH_AM335XEVM\n> > > > > # ifdef machine_arch_type\n> > > > > #  undef machine_arch_type\n> > > > > #  define machine_arch_type     __machine_arch_type\n> > > > > # else\n> > > > > #  define machine_arch_type     MACH_TYPE_AM335XEVM\n> > > > > # endif\n> > > > > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM)\n> > > > > #else\n> > > > > # define machine_is_am335xevm() (0)\n> > > > > #endif\n> > > > >\n> > > > >\n> > > > > So I am thinking of changing the config_xxx option to SOC_AM33XX or\n> > > > > ARCH_OMAP2PLUS, something like below,\n> > > > >\n> > > > > am335xevm        SOC_AM33XX          AM335XEVM         3589\n> > > > >\n> > > > > OR\n> > > > >\n> > > > > am335xevm        ARCH_OMAP2PLUS      AM335XEVM         3589\n> > > > >\n> > > > >\n> > > > > Can you comment on this? Based on that I will submit the patch.\n> > > >\n> > > > I think that would at minimum break things for autogenerated\n> > > > mach-types.h where if only some other non-am335xevm machine is\n> > > > selected (like omap-generic) things don't get optimized out any\n> > > > longer as they currently do.\n> > > >\n> > >\n> > > Agreed. In that case the first option should work here, right?\n> >\n> > It gets messy if we start mixing mach and soc defines there..\n> >\n> > How about just add a hidden Kconfig option to mach-omap2/Kconfig\n> > that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set?\n>\n> Great, this is what I had in my mind but since it is hidden option I thought\n> may not be right thing to do.\n> I was just thinking in the direction that, it should be logical and fine if\n> SOC_AM33XX is used for all AM33xx based machines, isn't it?\n>\n> Anyway, I think we are on same page here, I will add it and submit the patch\n> ASAP.\n>\n> > Or does that require that MACHINE_START is there as well?\n> >\n>\n> I do not think so, they are not related to each other, this option is\n> required only during decompression.\n> I have tested it on BeagleBone and it is working.\n>\n\nCan you please review below patch? If you think its ok, I will send the\npatch -\n\nThanks,\nVaibhav","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/97fef9938ed0bfa526613e688463bed7550ff825"},{"sha":"fa4fc91ccd93ef0d2a8f0cc74ff02c0ae577e441","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"ARM: OMAP: Hack AM33xx clock data to allow JTAG use\n\nThe debugss interface clock must remain enabled at init\nin order to prevent an attached JTAG probe from hanging.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/fa4fc91ccd93ef0d2a8f0cc74ff02c0ae577e441"},{"sha":"a7104bc13b0f4b77e6fe1d00fabcb6efed4ab1fd","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"video: st7735fb: add st7735 framebuffer driver\n\nAdd driver for the SPI-connected ST7735 display controller.\nThis driver requires that the platform support DT booting.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/a7104bc13b0f4b77e6fe1d00fabcb6efed4ab1fd"},{"sha":"aae575dc324871f7edc796363d04db1a50516c5b","author":{"email":"843c43c6ca6ac047d393694d733847b0a7f0f436@ti.com","name":"Jon Hunter"},"message":"dmaengine: add helper function to request a slave DMA channel\n\nCurrently slave DMA channels are requested by calling dma_request_channel()\nand requires DMA clients to pass various filter parameters to obtain the\nappropriate channel.\n\nWith device-tree being used by architectures such as arm and the addition of\ndevice-tree helper functions to extract the relevant DMA client information\nfrom device-tree, add a new function to request a slave DMA channel using\ndevice-tree. This function is currently a simple wrapper that calls the\ndevice-tree of_dma_request_slave_channel() function.\n\nCc: Nicolas Ferre <nicolas.ferre@atmel.com>\nCc: Benoit Cousson <b-cousson@ti.com>\nCc: Stephen Warren <swarren@nvidia.com>\nCc: Grant Likely <grant.likely@secretlab.ca>\nCc: Russell King <linux@arm.linux.org.uk>\nCc: Rob Herring <rob.herring@calxeda.com>\nCc: Arnd Bergmann <arnd@arndb.de>\nCc: Vinod Koul <vinod.koul@intel.com>\nCc: Dan Williams <djbw@fb.com>\n\nAcked-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Jon Hunter <jon-hunter@ti.com>\nReviewed-by: Stephen Warren <swarren@wwwdotorg.org>\nAcked-by: Rob Herring <rob.herring@calxeda.com>\nSigned-off-by: Vinod Koul <vinod.koul@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/aae575dc324871f7edc796363d04db1a50516c5b"},{"sha":"54a2ee89f9bb3645c44658d6ec0fb8b82482d3a3","author":{"email":"843c43c6ca6ac047d393694d733847b0a7f0f436@ti.com","name":"Jon Hunter"},"message":"of: Add generic device tree DMA helpers\n\nThis is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]\nto add some basic helpers to retrieve a DMA controller device_node and the\nDMA request/channel information.\n\nAim of DMA helpers\n- The purpose of device-tree is to describe the capabilites of the hardware.\n  Thinking about DMA controllers purely from the context of the hardware to\n  begin with, we can describe a device in terms of a DMA controller as\n  follows ...\n  \t1. Number of DMA controllers\n\t2. Number of channels (maybe physical or logical)\n\t3. Mapping of DMA requests signals to DMA controller\n\t4. Number of DMA interrupts\n\t5. Mapping of DMA interrupts to channels\n- With the above in mind the aim of the DT DMA helper functions is to extract\n  the above information from the DT and provide to the appropriate driver.\n  However, due to the vast number of DMA controllers and not all are using a\n  common driver (such as DMA Engine) it has been seen that this is not a\n  trivial task. In previous discussions on this topic the following concerns\n  have been raised ...\n\t1. How does the binding support devices with multiple DMA controllers?\n  \t2. How to support both legacy DMA controllers not using DMA Engine as\n\t   well as those that support DMA Engine.\n\t3. When using with DMA Engine how do we support the various\n\t   implementations where the opaque filter function parameter differs\n\t   between implementations?\n\t4. How do we handle DMA channels that are identified with a string\n\t   versus a integer?\n- Hence the design of the DMA helpers has to accomodate the above or align on\n  an agreement what can be or should be supported.\n\nDesign of DMA helpers\n\n1. Registering DMA controllers\n\n   In the case of DMA controllers that are using DMA Engine, requesting a\n   channel is performed by calling the following function.\n\n\tstruct dma_chan *dma_request_channel(dma_cap_mask_t mask,\n\t\t\tdma_filter_fn filter_fn,\n\t\t\tvoid *filter_param);\n\n   The mask variable is used to match a type of the device controller in a list\n   of controllers. The filter_fn and filter_param are used to identify the\n   required dma channel and return a handle to the dma channel of type dma_chan.\n\n   From the examples I have seen, the mask and filter_fn are constant\n   for a given DMA controller and therefore, we can specify these as controller\n   specific data when registering the DMA controller with the device-tree DMA\n   helpers.\n\n   The filter_param variable is of an unknown type and is typically specific\n   to the DMA engine implementation for a given DMA controller. To allow some\n   flexibility in the type and formating of this filter_param we employ an\n   xlate to translate the device-tree binding information into the appropriate\n   format. The xlate function used for a DMA controller can also be specified\n   when registering the DMA controller with the device-tree DMA helpers.\n\n   Based upon the above, a function for registering the DMA controller with the\n   DMA helpers now looks like the below. The data variable is used to pass a\n   pointer to DMA controller specific data used by the xlate function.\n\n\tint of_dma_controller_register(struct device_node *np,\n\t\tstruct dma_chan *(*of_dma_xlate)\n\t\t(struct of_phandle_args *, struct of_dma *),\n\t\tvoid *data)\n\n   For example, in the case where DMA engine is used, we define the following\n   structure (that stores the DMA engine capability mask and filter function)\n   and pass this to the data variable in the above function.\n\n\tstruct of_dma_filter_info {\n\t\tdma_cap_mask_t  dma_cap;\n\t\tdma_filter_fn   filter_fn;\n\t};\n\n2. Representing and requesting channel information\n\n   Please see the dma binding documentation included in this patch for a\n   description of how DMA controllers and client information should be\n   represented with device-tree. For more information on how this binding\n   came about please see [3]. In addition to this, feedback received from\n   the Linux kernel summit showed a consensus (among those who attended) to\n   use a name to identify DMA client information [4].\n\n   A DMA channel can be requested by calling the following function, where name\n   is a required parameter used for identifying a DMA channel. This function\n   has been designed to return a structure of type dma_chan to work with the\n   DMA engine driver. Note that if DMA engine is used then drivers should be\n   using the DMA engine API dma_request_slave_channel() (implemented in part 2\n   of this series, \"dmaengine: add helper function to request a slave DMA\n   channel\") which will in turn call the below function if device-tree is\n   present. The aim being to have a common DMA engine interface regardless of\n   whether device tree is being used.\n\n\tstruct dma_chan *of_dma_request_slave_channel(struct device_node *np,\n\t\t\t\t\t\t      char *name)\n\n3. Supporting legacy devices not using DMA Engine\n\n   These devices present a problem, as there may not be a uniform way to easily\n   support them with regard to device tree. Ideally, these should be migrated\n   to DMA engine. However, if this is not possible, then they should still be\n   able to use this binding, the only constaint imposed by this implementation\n   is that when requesting a DMA channel via of_dma_request_slave_channel(), it\n   will return a type of dma_chan.\n\nThis implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I\nhave validated that MMC is working on the PANDA board with this implementation.\nMy development branch for testing on OMAP can be found here [5].\n\nv6: - minor corrections in DMA binding documentation\nv5: - minor update to binding documentation\n    - added loop to exhaustively search for a slave channel in the case where\n      there could be alternative channels available\nv4: - revert the removal of xlate function from v3\n    - update the proposed binding format and APIs based upon discussions [3]\nv3: - avoid passing an xlate function and instead pass DMA engine parameters\n    - define number of dma channels and requests in dma-controller node\nv2: - remove of_dma_to_resource API\n    - make property #dma-cells required (no fallback anymore)\n    - another check in of_dma_xlate_onenumbercell() function\n\n[1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022\n[2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622\n[3] http://marc.info/?l=linux-omap&m=133582085008539&w=2\n[4] http://pad.linaro.org/arm-mini-summit-2012\n[5] https://github.com/jonhunter/linux/tree/dev-dt-dma\n\nCc: Nicolas Ferre <nicolas.ferre@atmel.com>\nCc: Benoit Cousson <b-cousson@ti.com>\nCc: Stephen Warren <swarren@nvidia.com>\nCc: Grant Likely <grant.likely@secretlab.ca>\nCc: Russell King <linux@arm.linux.org.uk>\nCc: Rob Herring <rob.herring@calxeda.com>\nCc: Arnd Bergmann <arnd@arndb.de>\nCc: Vinod Koul <vinod.koul@intel.com>\nCc: Dan Williams <djbw@fb.com>\n\nReviewed-by: Arnd Bergmann <arnd@arndb.de>\nReviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>\nSigned-off-by: Jon Hunter <jon-hunter@ti.com>\nReviewed-by: Stephen Warren <swarren@wwwdotorg.org>\nAcked-by: Rob Herring <rob.herring@calxeda.com>\nSigned-off-by: Vinod Koul <vinod.koul@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/54a2ee89f9bb3645c44658d6ec0fb8b82482d3a3"},{"sha":"3a0f0aa01703c7c926c07527d3c1adcf8f659f96","author":{"email":"5cf69c63beb17bf38d63aa0e923ee8256af0e205@linux.intel.com","name":"Vinod Koul"},"message":"of: dma- fix build break for !CONFIG_OF\n\nSigned-off-by: Vinod Koul <vinod.koul@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/3a0f0aa01703c7c926c07527d3c1adcf8f659f96"},{"sha":"58cae498d3fe9c4607180302d3fa1b7b7b1e80e9","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"of: dma: fix typos in generic dma binding definition\n\nSome semicolons were left out in the examples.\n\nThe #dma-channels and #dma-requests properties have a prefix\nthat is, by convention, reserved for cell size properties.\nRename those properties to dma-channels and dma-requests.\n\nSigned-off-by: Matt Porter <mporter@ti.com>\nAcked-by: Arnd Bergmann <arnd@arndb.de>\nAcked-by: Jon Hunter <jon-hunter@ti.com>\nSigned-off-by: Vinod Koul <vinod.koul@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/58cae498d3fe9c4607180302d3fa1b7b7b1e80e9"},{"sha":"63bbf4b07150ad824883573ade719be12da229bb","author":{"email":"5cf69c63beb17bf38d63aa0e923ee8256af0e205@linux.intel.com","name":"Vinod Koul"},"message":"dmaengine: fix build failure due to missing semi-colon\n\nReported-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: Vinod Koul <vinod.koul@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/63bbf4b07150ad824883573ade719be12da229bb"},{"sha":"ff1935b49e4189844c2085febfc69d91292288be","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"dmaengine: edma: fix slave config dependency on direction\n\nThe edma_slave_config() implementation depends on the\ndirection field such that it will not properly configure\na slave channel when called without direction set.\n\nThis fixes the implementation so that the slave config\nis copied as is and prep_slave_sg() handles the\ndirection dependent handling. spi-omap2-mcspi and\nomap_hsmmc both expose this bug as they configure the\nslave channel config from a common path with an unconfigured\ndirection field.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/ff1935b49e4189844c2085febfc69d91292288be"},{"sha":"15aee69ad81061ec51000cf66f8080061b706719","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"dmaengine: add dma_get_channel_caps()\n\nAdd a dmaengine API to retrieve per channel capabilities.\nCurrently, only channel ops and SG segment limitations are\nimplemented caps.\n\nThe API is optionally implemented by drivers and when\nunimplemented will return a NULL pointer. It is intended\nto be executed after a channel has been requested and, if\nthe channel is intended to be used with slave SG transfers,\nthen it may only be called after dmaengine_slave_config()\nhas executed. The slave driver provides parameters such as\nburst size and address width which may be necessary for\nthe dmaengine driver to use in order to properly return SG\nsegment limit caps.\n\nSuggested-by: Vinod Koul <vinod.koul@intel.com>\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/15aee69ad81061ec51000cf66f8080061b706719"},{"sha":"4867caa7825613426c4f166f57146efdf4f654ee","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"dma: edma: add device_channel_caps() support\n\nImplement device_channel_caps().\n\nEDMA has a finite set of PaRAM slots available for linking\na multi-segment SG transfer. In order to prevent any one\nchannel from consuming all PaRAM slots to fulfill a large SG\ntransfer, the driver reports a static per-channel max number\nof SG segments it will handle.\n\nThe maximum size of SG segment is limited by the slave config\nmaxburst and addr_width for the channel in question. These values\nare used from the current channel config to calculate and return\nthe max segment length cap.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/4867caa7825613426c4f166f57146efdf4f654ee"},{"sha":"3cd9bbf5f2f0226401a12444a82acbf290072eca","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"mmc: davinci: get SG segment limits with dma_get_channel_caps()\n\nReplace the hardcoded values used to set max_segs/max_seg_size with\na dma_get_channel_caps() query to the dmaengine driver.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/3cd9bbf5f2f0226401a12444a82acbf290072eca"},{"sha":"206ede793b0a31719fcc2c8e00b6cbc514990af0","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"ARM: davinci: move private EDMA API to arm/common\n\nMove mach-davinci/dma.c to common/edma.c so it can be used\nby OMAP (specifically AM33xx) as well. This just moves the\nprivate EDMA API and enables it to build on OMAP.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/206ede793b0a31719fcc2c8e00b6cbc514990af0"},{"sha":"ded7dedf6f979254c426811074626eefda1a6c2b","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"ARM: edma: remove unused transfer controller handlers\n\nFix build on OMAP, the irqs are undefined on AM33xx.\nThese error interrupt handlers were hardcoded as disabled\nso since they are unused code, simply remove them.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/ded7dedf6f979254c426811074626eefda1a6c2b"},{"sha":"1b254a9e0e15bdf4f619374579db52231a06dba3","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"ARM: edma: add AM33XX support to the private EDMA API\n\nAdds support for parsing the TI EDMA DT data into the required\nEDMA private API platform data. Enables runtime PM support to\ninitialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux\nsupport.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/1b254a9e0e15bdf4f619374579db52231a06dba3"},{"sha":"ab60f5ef62cdca94910a873b5fb69b0c796a7603","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"dmaengine: edma: enable build for AM33XX\n\nEnable TI EDMA option on OMAP.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/ab60f5ef62cdca94910a873b5fb69b0c796a7603"},{"sha":"c43e30ef4d835080f289606147d7e4c8d22f82e8","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"dmaengine: edma: Add TI EDMA device tree binding\n\nThe binding definition is based on the generic DMA controller\nbinding.\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/c43e30ef4d835080f289606147d7e4c8d22f82e8"},{"sha":"e1af04523ea69ad5e5ab72586775b6e484dd9a23","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"ARM: dts: add AM33XX EDMA support\n\nAdds AM33XX EDMA support to the am33xx.dtsi as documented in\nDocumentation/devicetree/bindings/dma/ti-edma.txt\n\nSigned-off-by: Matt Porter <mporter@ti.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/e1af04523ea69ad5e5ab72586775b6e484dd9a23"},{"sha":"91efbe7752808ef4c522664d006b71fe711b6e8a","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"dmaengine: add dma_request_slave_channel_compat()\n\nAdds a dma_request_slave_channel_compat() wrapper which accepts\nboth the arguments from dma_request_channel() and\ndma_request_slave_channel(). Based on whether the driver is\ninstantiated via DT, the appropriate channel request call will be\nmade.\n\nThis allows for a much cleaner migration of drivers to the\ndmaengine DT API as platforms continue to be mixed between those\nthat boot using DT and those that do not.\n\nSuggested-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Matt Porter <mporter@ti.com>\nAcked-by: Tony Lindgren <tony@atomide.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/91efbe7752808ef4c522664d006b71fe711b6e8a"},{"sha":"d8ba0dc9552024cb0fc38fd6f1745ff27f76f73a","author":{"email":"c1d287ff3802a4aab0e3770389ea24a33314618b@ti.com","name":"Matt Porter"},"message":"mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()\n\nConvert dmaengine channel requests to use\ndma_request_slave_channel_compat(). This supports the DT case of\nplatforms requiring channel selection from either the OMAP DMA or\nthe EDMA engine. AM33xx only boots from DT and is the only user\nimplementing EDMA so in the !DT case we can default to the OMAP DMA\nfilter.\n\nSigned-off-by: Matt Porter <mporter@ti.com>\nAcked-by: Tony Lindgren <tony@atomide.com>","distinct":true,"url":"https://api.github.com/repos/beagleboard/linux/commits/d8ba0dc9552024cb0fc38fd6f1745ff27f76f73a"}]}