31 Aug, 2016

3 commits

  • The HIDMA driver is capable of error detection. However, the error was
    not being passed back to the client when tx_status API is called.

    Changing the error handling behavior to follow this oder.

    1. dmaengine asserts error interrupt
    2. Driver receives and mark's the txn as error
    3. Driver completes the txn and intimates the client. No further
    submissions. Drop the locks before calling callback, as subsequent
    processing by client maybe in callback thread.
    4. Client invokes status and you can return error
    5. On error, client calls terminate_all. You can reset channel, free all
    descriptors in the active, pending and completed lists
    6. Client prepares new txn and so on.

    As part of this work, got rid of the reset in the interrupt handler when
    an error happens and the HW is put into disabled state. The only way to
    recover is for the client to terminate the channel.

    Signed-off-by: Sinan Kaya
    Signed-off-by: Vinod Koul

    Sinan Kaya
     
  • Pass the DMA errors to the client by passing a result argument. The HW only
    supports a generic error when something goes wrong. That's why, using
    DMA_TRANS_ABORTED all the time.

    Signed-off-by: Sinan Kaya
    Signed-off-by: Vinod Koul

    Sinan Kaya
     
  • There is a race condition between data transfer callback and descriptor
    free code. The callback routine may decide to clear the resources even
    though the descriptor has not yet been freed.

    Instead of calling the callback first and then releasing the memory,
    this code is changing the order to return the descriptor back to the
    free pool and then call the user provided callback.

    Signed-off-by: Sinan Kaya
    Signed-off-by: Vinod Koul

    Sinan Kaya
     

08 Aug, 2016

1 commit

  • This is in preperation of moving to a callback that provides results to the
    callback for the transaction. The conversion will maintain current behavior
    and the driver must convert to new callback mechanism at a later time in
    order to receive results.

    Signed-off-by: Dave Jiang
    Reviewed-by: Lars-Peter Clausen
    Acked-by: Sinan Kaya
    Signed-off-by: Vinod Koul

    Dave Jiang
     

28 Jul, 2016

1 commit


24 Jul, 2016

1 commit


23 Jul, 2016

2 commits


16 Jul, 2016

1 commit


12 Jul, 2016

1 commit


07 Jul, 2016

1 commit

  • The bam_dma driver gained runtime PM support, but that causes build
    warnings whenever CONFIG_PM is disabled:

    drivers/dma/qcom/bam_dma.c:1324:12: error: 'bam_dma_runtime_resume' defined but not used [-Werror=unused-function]
    static int bam_dma_runtime_resume(struct device *dev)
    ^~~~~~~~~~~~~~~~~~~~~~
    drivers/dma/qcom/bam_dma.c:1315:12: error: 'bam_dma_runtime_suspend' defined but not used [-Werror=unused-function]
    static int bam_dma_runtime_suspend(struct device *dev)

    This removes the incomplete #ifdef guard and instead marks all
    four PM functions as __maybe_unused, which avoids this kind of
    warning.

    Signed-off-by: Arnd Bergmann
    Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support")
    Signed-off-by: Vinod Koul

    Arnd Bergmann
     

30 Jun, 2016

1 commit


14 May, 2016

3 commits

  • In order to create a relationship model between the channels and the
    management object, we are adding support for object hierarchy to the
    drivers. This patch simplifies the userspace application development.
    We will not have to traverse different firmware paths based on device
    tree or ACPI based kernels.

    No matter what flavor of kernel is used, objects will be represented as
    platform devices.

    The new layout is as follows:

    hidmam_10: hidma-mgmt@0x5A000000 {
    compatible = "qcom,hidma-mgmt-1.0";
    ...

    hidma_10: hidma@0x5a010000 {
    compatible = "qcom,hidma-1.0";
    ...
    }
    }

    The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
    in device tree and calls into the channel driver to create platform devices
    for each child of the management object.

    Signed-off-by: Sinan Kaya
    Signed-off-by: Vinod Koul

    Sinan Kaya
     
  • Add debugfs hooks for debugging the execution behavior of the DMA
    channel. The debugfs hooks get initialized by the probe function and
    uninitialized by the remove function.

    A stats file is created in debugfs. The stats file will show the
    information about each HIDMA channel as well as each asynchronous job
    queued and completed at a given time.

    Signed-off-by: Sinan Kaya
    Signed-off-by: Vinod Koul

    Sinan Kaya
     
  • This patch implements the hardware hooks for the HIDMA channel driver.

    The main functions of interest are:
    - hidma_ll_init
    - hidma_ll_request
    - hidma_ll_queue_request
    - hidma_ll_hw_start

    OS layer calls the hidma_ll_init function during probe to set up the
    hardware. At this moment, the number of supported descriptors are also
    given. On each request, a descriptor is allocated from the free pool and
    filled in with the transfer parameters. Multiple requests can be queued
    into the hardware via the OS interface. When client is ready for requests
    to be executed, start method is called.

    Completions are delivered via callbacks via tasklet.

    Signed-off-by: Sinan Kaya
    Signed-off-by: Vinod Koul

    Sinan Kaya
     

19 Apr, 2016

5 commits

  • It seems that the define has not been with acurate name and
    makes confusion while reading the code. The more acurate
    name should be BAM_FIFO_SIZE.

    Signed-off-by: Stanimir Varbanov
    Reviewed-by: Andy Gross
    Signed-off-by: Vinod Koul

    Stanimir Varbanov
     
  • The pipe fifo size register must instruct the bam hw
    how many hw descriptors can be pushed to fifo. Currently
    we instruct the hw with 32KBytes but wrap the tail in
    bam_start_dma in BAM_P_EVNT_REG on 4095 i.e. 32760. This
    leads to stalled transactions when the tail wraps.

    Fix this by use the correct fifo size in BAM_P_FIFO_SIZES
    register i.e. 32K - 8.

    Signed-off-by: Stanimir Varbanov
    Signed-off-by: Vinod Koul

    Stanimir Varbanov
     
  • Some of the peripherals has bam which is controlled by remote
    processor, thus the bam dma driver must avoid register writes
    which initialise bam hw block. Those registers are protected
    from xPU block and any writes to them will lead to secure
    violation and system reboot.

    Adding the contolled_remotely flag in bam driver to avoid
    not permitted register writes in bam_init function.

    Signed-off-by: Stanimir Varbanov
    Reviewed-by: Andy Gross
    Tested-by: Pramod Gurav
    Signed-off-by: Vinod Koul

    Stanimir Varbanov
     
  • Currently we write BAM_IRQ_CLR register with zero even when no
    BAM_IRQ occured. This write has some bad side effects when the
    BAM instance is for the crypto engine. In case of crypto engine
    some of the BAM registers are xPU protected and they cannot be
    controlled by the driver.

    Signed-off-by: Stanimir Varbanov
    Reviewed-by: Andy Gross
    Tested-by: Pramod Gurav
    Signed-off-by: Vinod Koul

    Stanimir Varbanov
     
  • Building the driver as a module and when removing the already
    inserted module gives below:

    [ 1389.392788] Unable to handle kernel paging request at virtual address ffffffbdc000001c
    [ 1389.421321] pgd = ffffffc02fa87000
    [ 1389.447899] [ffffffbdc000001c] *pgd=0000000000000000, *pud=0000000000000000
    [ 1389.460142] Internal error: Oops: 96000006 [#1] PREEMPT SMP
    [ 1389.466963] Modules linked in: qcom_bam_dma(-)
    [ 1389.486608] CPU: 2 PID: 2442 Comm: rmmod Not tainted 4.2.0+ #407
    [ 1389.493885] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
    [ 1389.501196] task: ffffffc035bae2c0 ti: ffffffc0368a8000 task.ti: ffffffc0368a8000
    [ 1389.508566] PC is at __free_pages+0xc/0x40
    [ 1389.515893] LR is at free_pages.part.93+0x30/0x38
    [ 1389.523141] pc : [] lr : [] pstate: 80000145
    [ 1389.530602] sp : ffffffc0368abc20
    [ 1389.537931] x29: ffffffc0368abc20 x28: ffffffc0368a8000
    [ 1389.549153] x27: 0000000000000000 x26: 0000000000000000
    [ 1389.560412] x25: ffffffc000cb2000 x24: 0000000000000170
    [ 1389.571530] x23: 0000000000000004 x22: ffffffc036bc5010
    [ 1389.582721] x21: ffffffc036bc5010 x20: 0000000000000000
    [ 1389.593981] x19: 0000000000000002 x18: 0000007fcbc8e8b0
    [ 1389.605301] x17: 0000007f9b8226ec x16: ffffffc0002089e8
    [ 1389.616647] x15: 0000007f9b8a0588 x14: 0ffffffffffffffc
    [ 1389.628039] x13: 0000000000000030 x12: 0000000000000000
    [ 1389.639436] x11: 0000000000000008 x10: ffffffc000ecc000
    [ 1389.650872] x9 : ffffffc035bae2c0 x8 : ffffffc035bae9a8
    [ 1389.662367] x7 : ffffffc035bae9a0 x6 : 0000000000000000
    [ 1389.673906] x5 : ffffffbdc000001c x4 : 0000000080000000
    [ 1389.685475] x3 : ffffffbdc0000000 x2 : 0000004080000000
    [ 1389.697049] x1 : 0000000000000003 x0 : ffffffbdc0000000

    The memory has been already freed by bam_free_chan() so fix this
    by skiping already freed memory.

    Signed-off-by: Stanimir Varbanov
    Reviewed-by: Andy Gross
    Signed-off-by: Vinod Koul

    Stanimir Varbanov
     

18 Mar, 2016

1 commit

  • Pull dmaengine updates from Vinod Koul:
    "This is smallish update with minor changes to core and new driver and
    usual updates. Nothing super exciting here..

    - We have made slave address as physical to enable driver to do the
    mapping.

    - We now expose the maxburst for slave dma as new capability so
    clients can know this and program accordingly

    - addition of device synchronize callbacks on omap and edma.

    - pl330 updates to support DMAFLUSHP for Rockchip platforms.

    - Updates and improved sg handling in Xilinx VDMA driver.

    - New hidma qualcomm dma driver, though some bits are still in
    progress"

    * tag 'dmaengine-4.6-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (40 commits)
    dmaengine: IOATDMA: revise channel reset workaround on CB3.3 platforms
    dmaengine: add Qualcomm Technologies HIDMA channel driver
    dmaengine: add Qualcomm Technologies HIDMA management driver
    dmaengine: hidma: Add Device Tree binding
    dmaengine: qcom_bam_dma: move to qcom directory
    dmaengine: tegra: Move of_device_id table near to its user
    dmaengine: xilinx_vdma: Remove unnecessary variable initializations
    dmaengine: sirf: use __maybe_unused to hide pm functions
    dmaengine: rcar-dmac: clear pertinence number of channels
    dmaengine: sh: shdmac: don't open code of_device_get_match_data()
    dmaengine: tegra: don't open code of_device_get_match_data()
    dmaengine: qcom_bam_dma: Make driver work for BE
    dmaengine: sun4i: support module autoloading
    dma/mic_x100_dma: IS_ERR() vs PTR_ERR() typo
    dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's
    dmaengine: xilinx_vdma: Simplify spin lock handling
    dmaengine: xilinx_vdma: Fix issues with non-parking mode
    dmaengine: xilinx_vdma: Improve SG engine handling
    dmaengine: pl330: fix to support the burst mode
    dmaengine: make slave address physical
    ...

    Linus Torvalds
     

11 Mar, 2016

3 commits

  • This patch adds support for hidma engine. The driver consists of two
    logical blocks. The DMA engine interface and the low-level interface.
    The hardware only supports memcpy/memset and this driver only support
    memcpy interface. HW and driver doesn't support slave interface.

    Signed-off-by: Sinan Kaya
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Vinod Koul

    Sinan Kaya
     
  • The Qualcomm Technologies HIDMA device has been designed to support
    virtualization technology. The driver has been divided into two to follow
    the hardware design.

    1. HIDMA Management driver
    2. HIDMA Channel driver

    Each HIDMA HW consists of multiple channels. These channels share some set
    of common parameters. These parameters are initialized by the management
    driver during power up. Same management driver is used for monitoring the
    execution of the channels. Management driver can change the performance
    behavior dynamically such as bandwidth allocation and prioritization.

    The management driver is executed in host context and is the main
    management entity for all channels provided by the device.

    Signed-off-by: Sinan Kaya
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Vinod Koul

    Sinan Kaya
     
  • Creating a QCOM directory for all QCOM DMA source files.

    Signed-off-by: Sinan Kaya
    Reviewed-by: Andy Gross
    Signed-off-by: Vinod Koul

    Sinan Kaya