Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
branch: edma-dmaengine…
Commits on Jan 11, 2013
  1. ARM: dts: Add UART4 support to BeagleBone

    Matt Porter authored
    Signed-off-by: Matt Porter <mporter@ti.com>
  2. ARM: configs: working dmaengine configs for da8xx and am33xx

    Matt Porter authored
    Signed-off-by: Matt Porter <mporter@ti.com>
  3. ARM: dts: add BeagleBone gpevt support

    Matt Porter authored
    Signed-off-by: Matt Porter <mporter@ti.com>
  4. misc: add gpevt driver

    Matt Porter authored
    Simply amazing...'nuff said.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  5. ARM: dts: add BeagleBone Adafruit 1.8 LCD support

    Matt Porter authored
    Signed-off-by: Matt Porter <mporter@ti.com>
  6. ARM: dts: enable spi1 node and pinmux on BeagleBone

    Matt Porter authored
    Enables the spi1 IP and pinmuxes for use on the mcasp0
    pins.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  7. Documentation: bindings: add spansion

    Matt Porter authored
    Signed-off-by: Matt Porter <mporter@ti.com>
  8. ARM: dts: Add SPI Flash support to am335x-evm

    Matt Porter authored
    Add SPI pinmuxing and spansion device node for profile 2..
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  9. ARM: dts: add AM33XX SPI DMA support

    Matt Porter authored
    Adds DMA resources to the AM33XX SPI nodes.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  10. spi: omap2-mcspi: add generic DMA request support to the DT binding

    Matt Porter authored
    The binding definition is based on the generic DMA request binding.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  11. spi: omap2-mcspi: convert to dma_request_slave_channel_compat()

    Matt Porter authored
    Convert dmaengine channel requests to use
    dma_request_slave_channel_compat(). This supports the DT case of
    platforms requiring channel selection from either the OMAP DMA or
    the EDMA engine. AM33xx only boots from DT and is the only user
    implementing EDMA so in the !DT case we can default to the OMAP DMA
    filter.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  12. ARM: dts: add AM33XX MMC support

    Matt Porter authored
    Adds AM33XX MMC support for am335x-bone, am335x-evm, and
    am335x-evmsk..
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  13. mmc: omap_hsmmc: add generic DMA request support to the DT binding

    Matt Porter authored
    The binding definition is based on the generic DMA request binding.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  14. mmc: omap_hsmmc: set max_segs based on dma engine limitations

    Matt Porter authored
    The EDMA DMAC has a hardware limitation that prevents supporting
    scatter gather lists with any number of segments. The DMA Engine
    API reports the maximum number of segments a channel can support
    via the optional dma_get_channel_caps() API. If the nr_segs
    capability is present, the value is used to configure mmc->max_segs
    appropriately.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  15. mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()

    Matt Porter authored
    Convert dmaengine channel requests to use
    dma_request_slave_channel_compat(). This supports the DT case of
    platforms requiring channel selection from either the OMAP DMA or
    the EDMA engine. AM33xx only boots from DT and is the only user
    implementing EDMA so in the !DT case we can default to the OMAP DMA
    filter.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  16. dmaengine: add dma_request_slave_channel_compat()

    Matt Porter authored
    Adds a dma_request_slave_channel_compat() wrapper which accepts
    both the arguments from dma_request_channel() and
    dma_request_slave_channel(). Based on whether the driver is
    instantiated via DT, the appropriate channel request call will be
    made.
    
    This allows for a much cleaner migration of drivers to the
    dmaengine DT API as platforms continue to be mixed between those
    that boot using DT and those that do not.
    
    Suggested-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Matt Porter <mporter@ti.com>
  17. ARM: dts: add AM33XX EDMA support

    Matt Porter authored
    Adds AM33XX EDMA support to the am33xx.dtsi as documented in
    Documentation/devicetree/bindings/dma/ti-edma.txt
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  18. dmaengine: edma: Add TI EDMA device tree binding

    Matt Porter authored
    The binding definition is based on the generic DMA controller
    binding.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  19. dmaengine: edma: enable build for AM33XX

    Matt Porter authored
    Enable TI EDMA option on OMAP.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  20. ARM: edma: add AM33XX support to the private EDMA API

    Matt Porter authored
    Adds support for parsing the TI EDMA DT data into the required
    EDMA private API platform data. Enables runtime PM support to
    initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
    support.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  21. ARM: edma: remove unused transfer controller handlers

    Matt Porter authored
    Fix build on OMAP, the irqs are undefined on AM33xx.
    These error interrupt handlers were hardcoded as disabled
    so since they are unused code, simply remove them.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  22. ARM: davinci: move private EDMA API to arm/common

    Matt Porter authored
    Move mach-davinci/dma.c to common/edma.c so it can be used
    by OMAP (specifically AM33xx) as well. This just moves the
    private EDMA API and enables it to build on OMAP.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
Commits on Jan 10, 2013
  1. mmc: davinci: get SG segment limits with dma_get_channel_caps()

    Matt Porter authored
    Replace the hardcoded values used to set max_segs/max_seg_size with
    a dma_get_channel_caps() query to the dmaengine driver.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  2. dma: edma: add device_channel_caps() support

    Matt Porter authored
    Implement device_channel_caps().
    
    EDMA has a finite set of PaRAM slots available for linking
    a multi-segment SG transfer. In order to prevent any one
    channel from consuming all PaRAM slots to fulfill a large SG
    transfer, the driver reports a static per-channel max number
    of SG segments it will handle.
    
    The maximum size of SG segment is limited by the slave config
    maxburst and addr_width for the channel in question. These values
    are used from the current channel config to calculate and return
    the max segment length cap.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  3. dmaengine: add dma_get_channel_caps()

    Matt Porter authored
    Add a dmaengine API to retrieve per channel capabilities.
    Currently, only channel ops and SG segment limitations are
    implemented caps.
    
    The API is optionally implemented by drivers and when
    unimplemented will return a NULL pointer. It is intended
    to be executed after a channel has been requested and, if
    the channel is intended to be used with slave SG transfers,
    then it may only be called after dmaengine_slave_config()
    has executed. The slave driver provides parameters such as
    burst size and address width which may be necessary for
    the dmaengine driver to use in order to properly return SG
    segment limit caps.
    
    Suggested-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Matt Porter <mporter@ti.com>
  4. dmaengine: edma: fix slave config dependency on direction

    Matt Porter authored
    The edma_slave_config() implementation depends on the
    direction field such that it will not properly configure
    a slave channel when called without direction set.
    
    This fixes the implementation so that the slave config
    is copied as is and prep_slave_sg() handles the
    direction dependent handling. spi-omap2-mcspi and
    omap_hsmmc both expose this bug as they configure the
    slave channel config from a common path with an unconfigured
    direction field.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  5. dmaengine: fix build failure due to missing semi-colon

    Vinod Koul authored Matt Porter committed
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
  6. of: dma: fix typos in generic dma binding definition

    Matt Porter authored
    Some semicolons were left out in the examples.
    
    The #dma-channels and #dma-requests properties have a prefix
    that is, by convention, reserved for cell size properties.
    Rename those properties to dma-channels and dma-requests.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Jon Hunter <jon-hunter@ti.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
  7. of: dma- fix build break for !CONFIG_OF

    Vinod Koul authored Matt Porter committed
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
  8. @jonhunter

    of: Add generic device tree DMA helpers

    jonhunter authored Matt Porter committed
    This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
    to add some basic helpers to retrieve a DMA controller device_node and the
    DMA request/channel information.
    
    Aim of DMA helpers
    - The purpose of device-tree is to describe the capabilites of the hardware.
      Thinking about DMA controllers purely from the context of the hardware to
      begin with, we can describe a device in terms of a DMA controller as
      follows ...
      	1. Number of DMA controllers
    	2. Number of channels (maybe physical or logical)
    	3. Mapping of DMA requests signals to DMA controller
    	4. Number of DMA interrupts
    	5. Mapping of DMA interrupts to channels
    - With the above in mind the aim of the DT DMA helper functions is to extract
      the above information from the DT and provide to the appropriate driver.
      However, due to the vast number of DMA controllers and not all are using a
      common driver (such as DMA Engine) it has been seen that this is not a
      trivial task. In previous discussions on this topic the following concerns
      have been raised ...
    	1. How does the binding support devices with multiple DMA controllers?
      	2. How to support both legacy DMA controllers not using DMA Engine as
    	   well as those that support DMA Engine.
    	3. When using with DMA Engine how do we support the various
    	   implementations where the opaque filter function parameter differs
    	   between implementations?
    	4. How do we handle DMA channels that are identified with a string
    	   versus a integer?
    - Hence the design of the DMA helpers has to accomodate the above or align on
      an agreement what can be or should be supported.
    
    Design of DMA helpers
    
    1. Registering DMA controllers
    
       In the case of DMA controllers that are using DMA Engine, requesting a
       channel is performed by calling the following function.
    
    	struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
    			dma_filter_fn filter_fn,
    			void *filter_param);
    
       The mask variable is used to match a type of the device controller in a list
       of controllers. The filter_fn and filter_param are used to identify the
       required dma channel and return a handle to the dma channel of type dma_chan.
    
       From the examples I have seen, the mask and filter_fn are constant
       for a given DMA controller and therefore, we can specify these as controller
       specific data when registering the DMA controller with the device-tree DMA
       helpers.
    
       The filter_param variable is of an unknown type and is typically specific
       to the DMA engine implementation for a given DMA controller. To allow some
       flexibility in the type and formating of this filter_param we employ an
       xlate to translate the device-tree binding information into the appropriate
       format. The xlate function used for a DMA controller can also be specified
       when registering the DMA controller with the device-tree DMA helpers.
    
       Based upon the above, a function for registering the DMA controller with the
       DMA helpers now looks like the below. The data variable is used to pass a
       pointer to DMA controller specific data used by the xlate function.
    
    	int of_dma_controller_register(struct device_node *np,
    		struct dma_chan *(*of_dma_xlate)
    		(struct of_phandle_args *, struct of_dma *),
    		void *data)
    
       For example, in the case where DMA engine is used, we define the following
       structure (that stores the DMA engine capability mask and filter function)
       and pass this to the data variable in the above function.
    
    	struct of_dma_filter_info {
    		dma_cap_mask_t  dma_cap;
    		dma_filter_fn   filter_fn;
    	};
    
    2. Representing and requesting channel information
    
       Please see the dma binding documentation included in this patch for a
       description of how DMA controllers and client information should be
       represented with device-tree. For more information on how this binding
       came about please see [3]. In addition to this, feedback received from
       the Linux kernel summit showed a consensus (among those who attended) to
       use a name to identify DMA client information [4].
    
       A DMA channel can be requested by calling the following function, where name
       is a required parameter used for identifying a DMA channel. This function
       has been designed to return a structure of type dma_chan to work with the
       DMA engine driver. Note that if DMA engine is used then drivers should be
       using the DMA engine API dma_request_slave_channel() (implemented in part 2
       of this series, "dmaengine: add helper function to request a slave DMA
       channel") which will in turn call the below function if device-tree is
       present. The aim being to have a common DMA engine interface regardless of
       whether device tree is being used.
    
    	struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
    						      char *name)
    
    3. Supporting legacy devices not using DMA Engine
    
       These devices present a problem, as there may not be a uniform way to easily
       support them with regard to device tree. Ideally, these should be migrated
       to DMA engine. However, if this is not possible, then they should still be
       able to use this binding, the only constaint imposed by this implementation
       is that when requesting a DMA channel via of_dma_request_slave_channel(), it
       will return a type of dma_chan.
    
    This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
    have validated that MMC is working on the PANDA board with this implementation.
    My development branch for testing on OMAP can be found here [5].
    
    v6: - minor corrections in DMA binding documentation
    v5: - minor update to binding documentation
        - added loop to exhaustively search for a slave channel in the case where
          there could be alternative channels available
    v4: - revert the removal of xlate function from v3
        - update the proposed binding format and APIs based upon discussions [3]
    v3: - avoid passing an xlate function and instead pass DMA engine parameters
        - define number of dma channels and requests in dma-controller node
    v2: - remove of_dma_to_resource API
        - make property #dma-cells required (no fallback anymore)
        - another check in of_dma_xlate_onenumbercell() function
    
    [1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
    [2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
    [3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
    [4] http://pad.linaro.org/arm-mini-summit-2012
    [5] https://github.com/jonhunter/linux/tree/dev-dt-dma
    
    Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
    Cc: Benoit Cousson <b-cousson@ti.com>
    Cc: Stephen Warren <swarren@nvidia.com>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Rob Herring <rob.herring@calxeda.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Vinod Koul <vinod.koul@intel.com>
    Cc: Dan Williams <djbw@fb.com>
    
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Jon Hunter <jon-hunter@ti.com>
    Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
    Acked-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
  9. @jonhunter

    dmaengine: add helper function to request a slave DMA channel

    jonhunter authored Matt Porter committed
    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@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>
    
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jon Hunter <jon-hunter@ti.com>
    Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
    Acked-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
  10. @AnilKumarCh

    mfd: tps65910: Select REGMAP_IRQ in Kconfig to fix build error

    AnilKumarCh authored Matt Porter committed
    TPS65910 mfd driver uses functions that are only avaiable when
    REGMAP_IRQ is enabled. So "select REGMAP_IRQ" is added to mfd
    Kconfig to fix below build error:
    
    drivers/built-in.o: In function `tps65910_irq_exit':
    /media/anil/kernel/drivers/mfd/tps65910.c:265: undefined reference to `regmap_del_irq_chip'
    drivers/built-in.o: In function `tps65910_irq_init':
    /media/anil/kernel/drivers/mfd/tps65910.c:254: undefined reference to `regmap_add_irq_chip'
    drivers/built-in.o: In function `tps65910_i2c_probe':
    /media/anil/kernel/drivers/mfd/tps65910.c:509: undefined reference to `regmap_irq_get_domain'
    make: *** [vmlinux] Error 1
    
    Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
    Tested-by: Matt Porter <mporter@ti.com>
  11. video: st7735fb: add st7735 framebuffer driver

    Matt Porter authored
    Add driver for the SPI-connected ST7735 display controller.
    This driver requires that the platform support DT booting.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
  12. @Alan-Cox

    fb: Rework locking to fix lock ordering on takeover

    Alan-Cox authored Matt Porter committed
    [The fb maintainer appears to be absent at the moment].
    
    This is needed to fix a pile of lockdep splats that now show up because console_lock()
    is being properly audited. Hugh Dickins and Sasha Levin have tested it and both reports
    all looks good. This is probably not the whole story - the entire fb layer has locking
    confusion problems that were previously hidden but it seems to get the ones people hit
    in testing. This hopefully explains a few of the weird fb hangs that have been floating
    around forever.
    
    From: Alan Cox <alan@linux.intel.com>
    
    Adjust the console layer to allow a take over call where the caller already
    holds the locks. Make the fb layer lock in order.
    
    This s partly a band aid, the fb layer is terminally confused about the
    locking rules it uses for its notifiers it seems.
    
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Tested-by: Borislav Petkov <bp@alien8.de>
  13. ARM: OMAP: Hack AM33xx clock data to allow JTAG use

    Matt Porter authored
    The debugss interface clock must remain enabled at init
    in order to prevent an attached JTAG probe from hanging.
    
    Signed-off-by: Matt Porter <mporter@ti.com>
Something went wrong with that request. Please try again.