From: Trilok Soni <tsoni@codeaurora.org>
To: Vinod Koul <vinod.koul@linux.intel.com>
Cc: Russell King <linux@arm.linux.org.uk>,
Ravi Kumar V <kumarrav@codeaurora.org>,
"Ira W. Snyder" <iws@ovro.caltech.edu>,
Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>,
linux-arm-msm@vger.kernel.or, linux-kernel@vger.kernel.org,
Zhang Wei <zw@zh-kernel.org>,
Bryan Huntsman <bryanh@codeaurora.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Barry Song <baohua.song@csr.com>,
Daniel Walker <dwalker@fifo99.com>,
Dan Williams <dan.j.williams@intel.com>,
linuxppc-dev@lists.ozlabs.org,
David Brown <davidb@codeaurora.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 1/2] dmaengine: Add context parameter to prep_dma_sg and prep_interleaved_dma
Date: Mon, 26 Mar 2012 12:25:56 +0530 [thread overview]
Message-ID: <4F7012FC.10203@codeaurora.org> (raw)
In-Reply-To: <1332743073.19804.26.camel@vkoul-udesk3>
On 3/26/2012 11:54 AM, Vinod Koul wrote:
> On Thu, 2012-03-22 at 19:52 +0530, Ravi Kumar V wrote:
>> Add new context parameter to DMA SG and Interleaveid mode for passing
> Typo ^^^^^^^^^^^^
Sorry, we will fix this.
>> diff --git a/drivers/misc/carma/carma-fpga-program.c b/drivers/misc/carma/carma-fpga-program.c
>> index a2d25e4..3739a12 100644
>> --- a/drivers/misc/carma/carma-fpga-program.c
>> +++ b/drivers/misc/carma/carma-fpga-program.c
>> @@ -530,7 +530,7 @@ static noinline int fpga_program_dma(struct fpga_dev *priv)
>> }
>>
>> /* setup and submit the DMA transaction */
>> - tx = chan->device->device_prep_dma_sg(chan,
>> + tx = chan->device->dmaengine_prep_dma_sg(chan,
>> table.sgl, num_pages,
>> vb->sglist, vb->sglen, 0);
> No the idea is that clients will not know anything about additionlay
> parameter hence avoiding abuse. You need to reread the patches sent by
> Alexandre.
>
> You need to
> 1) add wrappers over interleaved api which dont expose this additional
> parameter
> 2) move existing users to use these wrappers
Above two steps would be exactly same as
https://lkml.org/lkml/2012/3/8/401 - [PATCH 1/2 V2] dmaengine/dma_slave:
introduce inline wrappers, right?
> 3) add a new API which has your additional argument (not an opaque
> object) and this calls .device_xx callback with additional arg.
> 4. Above can be under conditional of your specific subsystem where these
> parameters are valid.
Now, this would be different from what Alexandre had submitted, since he
had added "void *context" parameter directly to existing callbacks
dma_slave_sg and and cyclic under struct dma_device.
And you prefer that we add new callbacks under "struct dma_device" for
our specific requirement with new name and with that extra non-opaque
object. After that add wrappers for these two new callbacks say
dmaengine_prep_dma_sg_ext and dmagengine_prep_interleaved_dma_ext (same
name goes for callback).
---Trilok Soni
--
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
WARNING: multiple messages have this Message-ID (diff)
From: tsoni@codeaurora.org (Trilok Soni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/2] dmaengine: Add context parameter to prep_dma_sg and prep_interleaved_dma
Date: Mon, 26 Mar 2012 12:25:56 +0530 [thread overview]
Message-ID: <4F7012FC.10203@codeaurora.org> (raw)
In-Reply-To: <1332743073.19804.26.camel@vkoul-udesk3>
On 3/26/2012 11:54 AM, Vinod Koul wrote:
> On Thu, 2012-03-22 at 19:52 +0530, Ravi Kumar V wrote:
>> Add new context parameter to DMA SG and Interleaveid mode for passing
> Typo ^^^^^^^^^^^^
Sorry, we will fix this.
>> diff --git a/drivers/misc/carma/carma-fpga-program.c b/drivers/misc/carma/carma-fpga-program.c
>> index a2d25e4..3739a12 100644
>> --- a/drivers/misc/carma/carma-fpga-program.c
>> +++ b/drivers/misc/carma/carma-fpga-program.c
>> @@ -530,7 +530,7 @@ static noinline int fpga_program_dma(struct fpga_dev *priv)
>> }
>>
>> /* setup and submit the DMA transaction */
>> - tx = chan->device->device_prep_dma_sg(chan,
>> + tx = chan->device->dmaengine_prep_dma_sg(chan,
>> table.sgl, num_pages,
>> vb->sglist, vb->sglen, 0);
> No the idea is that clients will not know anything about additionlay
> parameter hence avoiding abuse. You need to reread the patches sent by
> Alexandre.
>
> You need to
> 1) add wrappers over interleaved api which dont expose this additional
> parameter
> 2) move existing users to use these wrappers
Above two steps would be exactly same as
https://lkml.org/lkml/2012/3/8/401 - [PATCH 1/2 V2] dmaengine/dma_slave:
introduce inline wrappers, right?
> 3) add a new API which has your additional argument (not an opaque
> object) and this calls .device_xx callback with additional arg.
> 4. Above can be under conditional of your specific subsystem where these
> parameters are valid.
Now, this would be different from what Alexandre had submitted, since he
had added "void *context" parameter directly to existing callbacks
dma_slave_sg and and cyclic under struct dma_device.
And you prefer that we add new callbacks under "struct dma_device" for
our specific requirement with new name and with that extra non-opaque
object. After that add wrappers for these two new callbacks say
dmaengine_prep_dma_sg_ext and dmagengine_prep_interleaved_dma_ext (same
name goes for callback).
---Trilok Soni
--
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
WARNING: multiple messages have this Message-ID (diff)
From: Trilok Soni <tsoni@codeaurora.org>
To: Vinod Koul <vinod.koul@linux.intel.com>
Cc: Ravi Kumar V <kumarrav@codeaurora.org>,
Russell King <linux@arm.linux.org.uk>,
Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Ira W. Snyder" <iws@ovro.caltech.edu>,
linux-arm-msm@vger.kernel.or, linux-kernel@vger.kernel.org,
Zhang Wei <zw@zh-kernel.org>,
Bryan Huntsman <bryanh@codeaurora.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Barry Song <baohua.song@csr.com>,
Daniel Walker <dwalker@fifo99.com>,
Dan Williams <dan.j.williams@intel.com>,
Li Yang <leoli@freescale.com>,
linuxppc-dev@lists.ozlabs.org,
David Brown <davidb@codeaurora.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 1/2] dmaengine: Add context parameter to prep_dma_sg and prep_interleaved_dma
Date: Mon, 26 Mar 2012 12:25:56 +0530 [thread overview]
Message-ID: <4F7012FC.10203@codeaurora.org> (raw)
In-Reply-To: <1332743073.19804.26.camel@vkoul-udesk3>
On 3/26/2012 11:54 AM, Vinod Koul wrote:
> On Thu, 2012-03-22 at 19:52 +0530, Ravi Kumar V wrote:
>> Add new context parameter to DMA SG and Interleaveid mode for passing
> Typo ^^^^^^^^^^^^
Sorry, we will fix this.
>> diff --git a/drivers/misc/carma/carma-fpga-program.c b/drivers/misc/carma/carma-fpga-program.c
>> index a2d25e4..3739a12 100644
>> --- a/drivers/misc/carma/carma-fpga-program.c
>> +++ b/drivers/misc/carma/carma-fpga-program.c
>> @@ -530,7 +530,7 @@ static noinline int fpga_program_dma(struct fpga_dev *priv)
>> }
>>
>> /* setup and submit the DMA transaction */
>> - tx = chan->device->device_prep_dma_sg(chan,
>> + tx = chan->device->dmaengine_prep_dma_sg(chan,
>> table.sgl, num_pages,
>> vb->sglist, vb->sglen, 0);
> No the idea is that clients will not know anything about additionlay
> parameter hence avoiding abuse. You need to reread the patches sent by
> Alexandre.
>
> You need to
> 1) add wrappers over interleaved api which dont expose this additional
> parameter
> 2) move existing users to use these wrappers
Above two steps would be exactly same as
https://lkml.org/lkml/2012/3/8/401 - [PATCH 1/2 V2] dmaengine/dma_slave:
introduce inline wrappers, right?
> 3) add a new API which has your additional argument (not an opaque
> object) and this calls .device_xx callback with additional arg.
> 4. Above can be under conditional of your specific subsystem where these
> parameters are valid.
Now, this would be different from what Alexandre had submitted, since he
had added "void *context" parameter directly to existing callbacks
dma_slave_sg and and cyclic under struct dma_device.
And you prefer that we add new callbacks under "struct dma_device" for
our specific requirement with new name and with that extra non-opaque
object. After that add wrappers for these two new callbacks say
dmaengine_prep_dma_sg_ext and dmagengine_prep_interleaved_dma_ext (same
name goes for callback).
---Trilok Soni
--
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2012-03-26 7:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-22 14:22 [PATCH v5 1/2] dmaengine: Add context parameter to prep_dma_sg and prep_interleaved_dma Ravi Kumar V
2012-03-22 14:22 ` Ravi Kumar V
2012-03-22 14:22 ` Ravi Kumar V
2012-03-26 6:24 ` Vinod Koul
2012-03-26 6:24 ` Vinod Koul
2012-03-26 6:24 ` Vinod Koul
2012-03-26 6:55 ` Trilok Soni [this message]
2012-03-26 6:55 ` Trilok Soni
2012-03-26 6:55 ` Trilok Soni
2012-03-26 7:24 ` Vinod Koul
2012-03-26 7:24 ` Vinod Koul
2012-03-26 7:24 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F7012FC.10203@codeaurora.org \
--to=tsoni@codeaurora.org \
--cc=baohua.song@csr.com \
--cc=bryanh@codeaurora.org \
--cc=dan.j.williams@intel.com \
--cc=davidb@codeaurora.org \
--cc=dwalker@fifo99.com \
--cc=iws@ovro.caltech.edu \
--cc=kumarrav@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.or \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=srinidhi.kasagar@stericsson.com \
--cc=vinod.koul@linux.intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zw@zh-kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.