19 Jul, 2017

1 commit


14 May, 2016

1 commit

  • Currently the following DT description would result in dmac0 always
    being tried first and dmac1 second if dmac0 was unavailable. This
    results in heavier use of dmac0 then of dmac1. This patch adds an
    approximate average distribution over the two nodes lessening the load
    of anyone of them.

    i2c6: i2c@e60b0000 {
    ...
    dmas = , ,
    , ;
    dma-names = "tx", "rx", "tx", "rx";
    ...
    };

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Niklas Söderlund
    Suggested-by: Arnd Bergmann
    Signed-off-by: Vinod Koul

    Niklas Söderlund
     

09 May, 2015

1 commit

  • DMA routers are transparent devices used to mux DMA requests from
    peripherals to DMA controllers. They are used when the SoC integrates more
    devices with DMA requests then their controller can handle.
    DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
    lines, but in SoC level it has 205 DMA requests.

    The of_dma_router will be registered as of_dma_controller with special
    xlate function and additional parameters. The driver for the router is
    responsible to craft the dma_spec (in the of_dma_route_allocate callback)
    which can be used to requests a DMA channel from the real DMA controller.
    This way the router can be transparent for the system while remaining generic
    enough to be used in different environments.

    Signed-off-by: Peter Ujfalusi
    Signed-off-by: Vinod Koul

    Peter Ujfalusi
     

07 Mar, 2015

1 commit

  • Current DMAEngine implementation of DT bindings can't support
    DT subnode. This patch export symbols of of_dma_request_slave_channel()
    for subnode DMA DT bingings.

    ex)

    rcar_sound: rcar_sound@ec500000 {
    ...
    rcar_sound,dvc {
    dvc0: dvc@0 {
    dmas = ;
    dma-names = "tx";
    };
    dvc1: dvc@1 {
    dmas = ;
    dma-names = "tx";
    };
    };
    ...
    };

    Signed-off-by: Kuninori Morimoto
    Acked-by: Vinod Koul
    Signed-off-by: Mark Brown

    Kuninori Morimoto
     

26 Jan, 2015

1 commit


26 Jul, 2014

1 commit

  • This patch adds a new common OF dma xlate callback function which will match a
    channel by it's id. The binding expects one integer argument which it will use to
    lookup the channel by the id.

    Unlike of_dma_simple_xlate this function is able to handle a system with
    multiple DMA controllers. When registering the of dma provider with
    of_dma_controller_register a pointer to the dma_device struct which is
    associated with the dt node needs to passed as the data parameter.
    New function will use this pointer to match only channels which belong to the
    specified DMA controller.

    Signed-off-by: Alexander Popov
    Signed-off-by: Vinod Koul

    Alexander Popov
     

10 Dec, 2013

1 commit

  • 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: Dan Williams
    Signed-off-by: Stephen Warren
    Signed-off-by: Vinod Koul

    Stephen Warren
     

19 Aug, 2013

1 commit


12 Jun, 2013

2 commits

  • Both of_dma_nbcells field of the of_dma_controller and the args_count field of
    the dma_spec are initialized by parsing the #dma-cells attribute of their device
    tree node. So if the device tree nodes of a DMA controller and the dma_spec
    match this means that of_dma_nbcells and args_count will also match. So the
    second test in the of_dma_find_controller loop is redundant because given the
    first test yields true the second test will also yield true. So we can safely
    remove the test whether of_dma_nbcells matches args_count. Since this was the
    last user of the of_dma_nbcells field we can remove it altogether.

    Signed-off-by: Lars-Peter Clausen
    Acked-by: Arnd Bergmann
    Signed-off-by: Vinod Koul

    Lars-Peter Clausen
     
  • There is no sensible reason why #dma-cells shouldn't be allowed to be 0. It is
    completely up to the DMA controller how many additional parameters, besides the
    phandle, it needs to identify a channel. E.g. for DMA controller with only one
    channel or for DMA controllers which don't have a restriction on which channel
    can be used for which peripheral it completely legitimate to not require any
    additional parameters.

    Also fixes the following warning:
    drivers/dma/of-dma.c: In function 'of_dma_controller_register':
    drivers/dma/of-dma.c:67:7: warning: 'nbcells' may be used uninitialized in this function

    Signed-off-by: Lars-Peter Clausen
    Acked-by: Arnd Bergmann
    Signed-off-by: Vinod Koul

    Lars-Peter Clausen
     

03 May, 2013

2 commits

  • Currently the OF DMA code uses a spin lock to protect the of_dma_list from
    concurrent access and a per controller reference count to protect the controller
    from being freed while a request operation is in progress. If
    of_dma_controller_free() is called for a controller who's reference count is not
    zero it will return -EBUSY and not remove the controller. This is fine up until
    here, but leaves the question what the caller of of_dma_controller_free() is
    supposed to do if the controller couldn't be freed. The only viable solution
    for the caller is to spin on of_dma_controller_free() until it returns success.
    E.g.

    do {
    ret = of_dma_controller_free(dev->of_node)
    } while (ret != -EBUSY);

    This is rather ugly and unnecessary and none of the current users of
    of_dma_controller_free() check it's return value anyway. Instead protect the
    list by a mutex. The mutex will be held as long as a request operation is in
    progress. So if of_dma_controller_free() is called while a request operation is
    in progress it will be put to sleep and only wake up once the request operation
    has finished.

    This means that it is no longer possible to register or unregister OF DMA
    controllers from a context where it's not possible to sleep. But I doubt that
    we'll ever need this.

    Also rename of_dma_get_controller back to of_dma_find_controller.

    Signed-off-by: Lars-Peter Clausen
    Acked-by: Arnd Bergmann
    Signed-off-by: Vinod Koul

    Lars-Peter Clausen
     
  • of_dma_request_slave_channel() currently does not drop the reference to the
    dma_spec of_node if no DMA controller matching the of_node could be found. This
    patch fixes it by always calling of_node_put().

    Signed-off-by: Lars-Peter Clausen
    Acked-by: Arnd Bergmann
    Reviewed-by: Jon Hunter
    Signed-off-by: Vinod Koul

    Lars-Peter Clausen
     

15 Apr, 2013

3 commits


14 Feb, 2013

3 commits