Re: [PATCH] DMAEngine: Define generic transfer request api

From: Jassi Brar <jaswinder.singh@linaro.org>
To: Barry Song <21cnbao@gmail.com>
Cc: dan.j.williams@intel.com, sundaram@ti.com,
	linus.walleij@linaro.org, vinod.koul@intel.com,
	rmk+kernel@arm.linux.org.uk, linux-omap@vger.kernel.org,
	DL-SHA-WorkGroupLinux <workgroup.linux@csr.com>
Subject: Re: [PATCH] DMAEngine: Define generic transfer request api
Date: Thu, 15 Sep 2011 12:13:14 +0530	[thread overview]
Message-ID: <CAJe_ZheZwHM7qH=s0KCQAyoZDmXmdX0ZK5oBgJ7dTw5Vg8tHVw@mail.gmail.com> (raw)
In-Reply-To: <CAGsJ_4y_Qp-F8z5m_nK5rTjCy4p-Cgr5DoHD0rzRjnLrTq=TEQ@mail.gmail.com>

On 15 September 2011 12:01, Barry Song <21cnbao@gmail.com> wrote:
> 2011/9/13 Barry Song <21cnbao@gmail.com>:
>> 2011/9/13 Jassi Brar <jaswinder.singh@linaro.org>:
>>> On 13 September 2011 13:16, Barry Song <21cnbao@gmail.com> wrote:
>>>>> if test pass, to the patch, and even for the moment, to the API's idea
>>>>> Acked-by: Barry Song <baohua.song@csr.com>
>>>>
>>>> one issue i noticed is with a device_prep_dma_genxfer, i don't need
>>>> device_prep_slave_sg any more,
>>> Yeah, the damengine would need to adapt to the fact that these
>>> interleaved tranfers could be Mem->Mem as well as Mem<->Dev
>>> (even though yours could be only one type, but some dmacs could
>>> do both).
>>>
>>>> How about:
>>>>
>>>>       BUG_ON(dma_has_cap(DMA_MEMCPY, device->cap_mask) &&
>>>> -               !device->device_prep_dma_memcpy);
>>>> +               !device->device_prep_dma_memcpy &&
>>>> +               !device->device_prep_dma_genxfer);
>>>>
>>>>        BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
>>>>  -               !device->device_prep_slave_sg);
>>>> +               !device->device_prep_slave_sg &&
>>>> +               !device->device_prep_dma_genxfer);
>>>>
>>> Seems ok, but please modify in a way you think is best and submit a patch
>>> on top of this new api. Then it'll be easier to evaluate everything.
>>
>> i think it should be handled by this patch but not a new one.
>
> and i also think xfer_template is a bad name for a structure which is
> an API. i'd like to add namespace for it and rename it to dma_genxfer.
> or have any good suggestion?
I think xfer_template is better - which stresses the usage as having prepared
templates of transfers and only change src/dst address before submitting.
'device_prep_dma_genxfer' is the API which is already named so.

> i'd like to send this together with "BUG_ON(dma_has_cap(DMA_SLAVE,
> device->cap_mask) &&!device->device_prep_dma_genxfer)" as v2.
Is there no change other than skipping check for SLAVE when using this api ?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html