1. 23 9月, 2014 1 次提交
  2. 04 8月, 2014 1 次提交
  3. 25 7月, 2014 1 次提交
  4. 05 7月, 2014 1 次提交
  5. 22 5月, 2014 2 次提交
  6. 06 3月, 2014 1 次提交
    • L
      dma: Remove comment about embedding dma_slave_config into custom structs · 7cbccb55
      Lars-Peter Clausen 提交于
      The documentation for the dma_slave_config struct recommends that if a DMA
      controller has special configuration options, which can not be configured
      through the dma_slave_config struct, the driver should create its own custom
      config struct and embed the dma_slave_config struct in it and pass the custom
      config struct to dmaengine_slave_config(). This overloads the generic
      dmaengine_slave_config() API with custom semantics and any caller of the
      dmaengine_slave_config() that is not aware of these special semantics will cause
      undefined behavior. This means that it is impossible for generic code to make
      use of dmaengine_slave_config(). Such a restriction contradicts the very idea of
      having a generic API.
      
      E.g. consider the following case of a DMA controller that has an option to
      reverse the field polarity of the DMA transfer with the following implementation
      for setting the configuration:
      
      	struct my_slave_config {
      		struct dma_slave_config config;
      		unsigned int field_polarity;
      	};
      
      	static int my_dma_controller_slave_config(struct dma_chan *chan,
      		struct dma_slave_config *config)
      	{
      		struct my_slave_config *my_cfg = container_of(config,
      				struct my_slave_config, config);
      
      		...
      		my_dma_set_field_polarity(chan, my_cfg->field_polarity);
      		...
      	}
      
      Now a generic user of the dmaengine API might want to configure a DMA channel
      for this DMA controller that it obtained using the following code:
      
      	struct dma_slave_config config;
      
      	config.src_addr = ...;
      	...
      	dmaengine_slave_config(chan, &config);
      
      The call to dmaengine_slave_config() will eventually call into
      my_dma_controller_slave_config() which will cast from dma_slave_config to
      my_slave_config and then tries to access the field_polarity member. Since the
      dma_slave_config struct that was passed in was never embedded into a
      my_slave_config struct this attempt will just read random stack garbage and use
      that to configure the DMA controller. This is bad. Instead, if a DMA controller
      really needs to have custom configuration options, the driver should create a
      custom API for it. This makes it very clear that there is a direct dependency
      of a user of such an API and the implementer. E.g.:
      
      	int my_dma_set_field_polarity(struct dma_chan *chan,
      		unsigned int field_polarity) {
      		if (chan->device->dev->driver != &my_dma_controller_driver.driver)
      			return -EINVAL;
      		...
      	}
      	EXPORT_SYMBOL_GPL(my_dma_set_field_polarity);
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      7cbccb55
  7. 20 1月, 2014 1 次提交
  8. 15 1月, 2014 1 次提交
    • L
      dma: Indicate residue granularity in dma_slave_caps · 50720563
      Lars-Peter Clausen 提交于
      This patch adds a new field to the dma_slave_caps struct which indicates the
      granularity with which the driver is able to update the residue field of the
      dma_tx_state struct. Making this information available to dmaengine users allows
      them to make better decisions on how to operate. E.g. for audio certain features
      like wakeup less operation or timer based scheduling only make sense and work
      correctly if the reported residue is fine-grained enough.
      
      Right now four different levels of granularity are supported:
      	* DESCRIPTOR: The DMA channel is only able to tell whether a descriptor has
      	  been completed or not, which means residue reporting is not supported by
      	  this channel. The residue field of the dma_tx_state field will always be
      	  0.
      	* SEGMENT: The DMA channel updates the residue field after each successfully
      	  completed segment of the transfer (For cyclic transfers this is after each
      	  period). This is typically implemented by having the hardware generate an
      	  interrupt after each transferred segment and then the drivers updates the
      	  outstanding residue by the size of the segment. Another possibility is if
      	  the hardware supports SG and the segment descriptor has a field which gets
      	  set after the segment has been completed. The driver then counts the
      	  number of segments without the flag set to compute the residue.
      	* BURST: The DMA channel updates the residue field after each transferred
      	  burst. This is typically only supported if the hardware has a progress
      	  register of some sort (E.g. a register with the current read/write address
      	  or a register with the amount of bursts/beats/bytes that have been
      	  transferred or still need to be transferred).
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      50720563
  9. 18 12月, 2013 1 次提交
  10. 10 12月, 2013 2 次提交
    • S
      dma: add dma_get_any_slave_channel(), for use in of_xlate() · 8010dad5
      Stephen Warren 提交于
      mmp_pdma.c implements a custom of_xlate() function that is 95% identical
      to what Tegra will need. Create a function to implement the common part,
      so everyone doesn't just cut/paste the implementation.
      
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: dmaengine@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      8010dad5
    • S
      dma: add channel request API that supports deferred probe · 0ad7c000
      Stephen Warren 提交于
      dma_request_slave_channel() simply returns NULL whenever DMA channel
      lookup fails. Lookup could fail for two distinct reasons:
      
      a) No DMA specification exists for the channel name.
         This includes situations where no DMA specifications exist at all, or
         other general lookup problems.
      
      b) A DMA specification does exist, yet the driver for that channel is not
         yet registered.
      
      Case (b) should trigger deferred probe in client drivers. However, since
      they have no way to differentiate the two situations, it cannot.
      
      Implement new function dma_request_slave_channel_reason(), which performs
      identically to dma_request_slave_channel(), except that it returns an
      error-pointer rather than NULL, which allows callers to detect when
      deferred probe should occur.
      
      Eventually, all drivers should be converted to this new API, the old API
      removed, and the new API renamed to the more desirable name. This patch
      doesn't convert the existing API and all drivers in one go, since some
      drivers call dma_request_slave_channel() then dma_request_channel() if
      that fails. That would require either modifying dma_request_channel() in
      the same way, or adding extra error-handling code to all affected
      drivers, and there are close to 100 drivers using the other API, rather
      than just the 15-20 or so that use dma_request_slave_channel(), which
      might be tenable in a single patch.
      
      acpi_dma_request_slave_chan_by_name() doesn't currently implement
      deferred probe. It should, but this will be addressed later.
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      0ad7c000
  11. 15 11月, 2013 2 次提交
  12. 14 11月, 2013 2 次提交
  13. 25 10月, 2013 2 次提交
  14. 10 9月, 2013 1 次提交
  15. 02 9月, 2013 1 次提交
  16. 23 8月, 2013 1 次提交
  17. 13 8月, 2013 1 次提交
    • Z
      dmaengine: add interface of dma_get_slave_channel · 7bb587f4
      Zhangfei Gao 提交于
      Suggested by Arnd, add dma_get_slave_channel interface
      Dma host driver could get specific channel specificied by request line, rather than filter.
      
      host example:
      static struct dma_chan *xx_of_dma_simple_xlate(struct of_phandle_args *dma_spec,
      		struct of_dma *ofdma)
      {
      	struct xx_dma_dev *d = ofdma->of_dma_data;
      	unsigned int request = dma_spec->args[0];
      
      	if (request > d->dma_requests)
      		return NULL;
      
      	return dma_get_slave_channel(&(d->chans[request].vc.chan));
      }
      
      probe:
      of_dma_controller_register((&op->dev)->of_node, xx_of_dma_simple_xlate, d);
      Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      7bb587f4
  18. 16 7月, 2013 1 次提交
  19. 04 7月, 2013 1 次提交
  20. 15 4月, 2013 2 次提交
  21. 28 2月, 2013 1 次提交
  22. 14 2月, 2013 1 次提交
  23. 12 1月, 2013 1 次提交
  24. 08 1月, 2013 5 次提交
  25. 07 1月, 2013 2 次提交
  26. 25 9月, 2012 1 次提交
  27. 22 9月, 2012 1 次提交
  28. 20 6月, 2012 2 次提交