On 1/31/2012 11:39 AM, Vinod Koul wrote:
> On Tue, 2012-01-31 at 11:29 +0530, Ravi Kumar V wrote:
>>> [1]: https://lkml.org/lkml/2011/10/24/275
>>> [2]: https://lkml.org/lkml/2012/1/26/405
>>>
>>
>> Yes if we follow the above RFC and add extra context parameter also
>> in
>> device_prep_dma_sg()& device_prep_interleaved_dma() then it supports
>> our hardware and our work will be completed.
>>
>> can we follow above RFC and implement our driver.
>> Is above RFC finalized and included in mainline?
> Alexandre will post an updated one soon, but the idea is same
>
Can we add extra parameter context to device_prep_dma_sg() &
device_prep_interleaved_dma() API's and implement our driver.
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Wed, 2012-02-01 at 11:46 +0530, Ravi Kumar V wrote:
> On 1/31/2012 11:39 AM, Vinod Koul wrote:
> > On Tue, 2012-01-31 at 11:29 +0530, Ravi Kumar V wrote:
> >>> [1]: https://lkml.org/lkml/2011/10/24/275
> >>> [2]: https://lkml.org/lkml/2012/1/26/405
> >>>
> >>
> >> Yes if we follow the above RFC and add extra context parameter also
> >> in
> >> device_prep_dma_sg()& device_prep_interleaved_dma() then it supports
> >> our hardware and our work will be completed.
> >>
> >> can we follow above RFC and implement our driver.
> >> Is above RFC finalized and included in mainline?
> > Alexandre will post an updated one soon, but the idea is same
> >
>
> Can we add extra parameter context to device_prep_dma_sg() &
> device_prep_interleaved_dma() API's and implement our driver.
So what one are you going to use...
>From the description sounds like you need interleaved API but with
changes to make it interleaved in both src and dtsn, right?
Then why prep_dma_sg?
--
~Vinod
On 2/1/2012 1:59 PM, Vinod Koul wrote:
> On Wed, 2012-02-01 at 11:46 +0530, Ravi Kumar V wrote:
>> On 1/31/2012 11:39 AM, Vinod Koul wrote:
>>> On Tue, 2012-01-31 at 11:29 +0530, Ravi Kumar V wrote:
>>>>> [1]: https://lkml.org/lkml/2011/10/24/275
>>>>> [2]: https://lkml.org/lkml/2012/1/26/405
>>>>>
>>>>
>>>> Yes if we follow the above RFC and add extra context parameter also
>>>> in
>>>> device_prep_dma_sg()& device_prep_interleaved_dma() then it supports
>>>> our hardware and our work will be completed.
>>>>
>>>> can we follow above RFC and implement our driver.
>>>> Is above RFC finalized and included in mainline?
>>> Alexandre will post an updated one soon, but the idea is same
>>>
>>
>> Can we add extra parameter context to device_prep_dma_sg()&
>> device_prep_interleaved_dma() API's and implement our driver.
> So what one are you going to use...
>
>> From the description sounds like you need interleaved API but with
> changes to make it interleaved in both src and dtsn, right?
> Then why prep_dma_sg?
>
>
Our hardware supports single transfer mode,scatter gather mode & box mode.
we are using these dmaengine API's for our HW
device_prep_memcpy() for single mode.
device_prep_dma_sg() for sg mode.
device_prep_interleaved_dma() for box mode.
We need to pass command configuration parameter to all of the above
three modes and it can be possible if extra context parameter is added
into these API's
Thanks
Ravi Kumar
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.