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

From: Barry Song <21cnbao@gmail.com>
To: Jassi Brar <jaswinder.singh@linaro.org>
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: Tue, 13 Sep 2011 16:58:10 +0800	[thread overview]
Message-ID: <CAGsJ_4ypKFD-a==gsMoPiwyHx39vAcsJr_5iyFS0fOn7-jHKbQ@mail.gmail.com> (raw)
In-Reply-To: <CAJe_ZhfrrJUySt0JpM4n2cU0874kBJhMoMG9NMS5kX+C5f+rXQ@mail.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.

>
> thanks.
>

-barry
--
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