[lkml]   [2008]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: dmaengine.c: question about device_alloc_chan_resources
    On Sun, 21 Sep 2008, Haavard Skinnemoen wrote:

    > > 2/ What about platform specific concerns where dma_cap_mask_t is not
    > > descriptive enough e.g. only one memcpy channel can address a certain
    > > bus? Currently a client implementation can have some intelligence to
    > > return DMA_DUP for channels that do not have the platform capability.
    > Currently, clients requesting the DMA_SLAVE capability can specify
    > which particular DMA device they need. Would it make sense to allow
    > other clients to do that as well?

    This is how it is documented in dmaengine.h:

    * @slave: data for preparing slave transfer. Must be non-NULL iff the
    * DMA_SLAVE capability is requested.

    But, looking at dma_client_chan_alloc() it seems, any client requesting a
    channel can provide a slave and link it to a specific dma_dev, regardless
    what capabilities the client is requesting, or am I missing something? If
    so, then yes, please, let's allow all do this. Wouldn't it be better to
    move the .dma_dev member to dma_client?

    > Also, struct dma_slave can be extended with
    > controller-/platform-specific fields. Maybe we need a similar mechanism
    > for passing platform-specific constraints when requesting "regular"
    > channels?

    As far as I understand, this extension can only be done by "wrapping"
    dma_slave with driver-specific data:

    * If dma_dev is non-NULL, the client can not be bound to other DMA
    * masters than the one corresponding to this device. The DMA master
    * driver may use this to determine if there is controller-specific
    * data wrapped around this struct. Drivers of platform code that sets
    * the dma_dev field must therefore make sure to use an appropriate
    * controller-specific dma slave structure wrapping this struct.

    i.e., there is no "void *priv" or similar. So, the same "wrapping" can be
    used with dma_client, even more conveniently so, if we move .dma_dev into

    Guennadi Liakhovetski, Ph.D.
    Freelance Open-Source Software Developer

     \ /
      Last update: 2008-09-21 21:53    [W:0.021 / U:15.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site