From: Abhishek Sahu <absahu@codeaurora.org>
To: Andy Gross <andy.gross@linaro.org>
Cc: Vinod Koul <vinod.koul@intel.com>,
dan.j.williams@intel.com, stanimir.varbanov@linaro.org,
mcgrof@suse.com, okaya@codeaurora.org, pramod.gurav@linaro.org,
arnd@arndb.de, linux-kernel@vger.kernel.org,
dmaengine@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 2/5] dmaengine: Add support for custom data mapping
Date: Thu, 19 Jan 2017 20:27:43 +0530 [thread overview]
Message-ID: <5332b039ab52d2ef7353121615871757@codeaurora.org> (raw)
In-Reply-To: <20170119141317.GA9631@hector.attlocal.net>
On 2017-01-19 19:43, Andy Gross wrote:
> On Thu, Jan 19, 2017 at 10:31:50AM +0530, Vinod Koul wrote:
>
> <snip>
>
>> > > >
>> > > >I really think that we need some additional API that allows for the flag
>> > > >munging
>> > > >for the descriptors instead of overriding the prep_slave_sg. We already
>> > > >needed
>> > > >to change the way the flags are passed anyway. And instead of building up
>> > > >a
>> > > >special sg list, the API should take a structure that has a 1:1 mapping of
>> > > >the
>> > > >flags to the descriptors. And you would call this API on your descriptor
>> > > >before
>> > > >issuing it.
>>
>> Munging wont be a good idea, but for some of the cases current flags
>> can be
>> used, and if need be, we can add additional flags
>
> Is adding flags a possibility? I tried to match up BAM flags to ones
> that made
> sense that were currently defined, but adding a CMD flag would be kind
> of odd.
>
> It was kind of a stretch to use the PREP_FENCE for the notify when done
> flag.
>
>> > > >
>> > > >So build up the sglist. Call the prep_slave_sg. You get back a tx
>> > > >descriptor
>> > > >that underneath is a bam descriptor. Then call the API giving the
>> > > >descriptor
>> > > >and the structure that defines the flags for the descriptors. Then submit
>> > > >the
>> > > >descriptor.
>> > > >
>> > > >Something like:
>> > > >int qcom_bam_apply_descriptor_flags(struct dma_async_tx_descriptor *tx,
>> > > > u16 *flags)
>> > > >{
>> > > > struct bam_async_desc async_desc = container_of(tx,
>> > > > struct bam_async_desc,
>> > > > vd.tx);
>> > > > int i;
>> > > >
>> > > > for (i = 0; i < async_desc->num_desc; i++)
>> > > > async_desc->desc[i].flags = cpu_to_le16(flags[i]);
>> > > >}
>> > > >
>> > > >EXPORT_SYMBOL(qcom_bam_apply_descriptor_flags)
>>
>> This makes it bam specific and causes issues if we want to use this
>> code in
>> generic libs, but yes this is an option but should be last resort.
>
> If adding flags is a possibility (which it didn't seem to be in the
> past), that
> would make things much easier.
Also, Main reason for this approach was to set different flags for each
BAM descriptor present in a TX descriptor.
>
> Regards,
>
> Andy
--
Abhishek Sahu
next prev parent reply other threads:[~2017-01-19 14:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-15 9:55 [PATCH 0/5] Support for QCA BAM DMA command descriptor Abhishek Sahu
2016-12-15 9:55 ` [PATCH 1/5] dmaengine: qca: bam_dma: Add header file for bam driver Abhishek Sahu
2016-12-15 9:55 ` [PATCH 2/5] dmaengine: Add support for custom data mapping Abhishek Sahu
2016-12-18 16:26 ` Vinod Koul
2016-12-19 5:06 ` Andy Gross
2016-12-19 15:49 ` Vinod Koul
2016-12-19 17:52 ` Andy Gross
2016-12-20 19:28 ` Abhishek Sahu
2016-12-20 20:25 ` Andy Gross
2016-12-21 19:34 ` Abhishek Sahu
2016-12-29 17:54 ` Andy Gross
2017-01-02 14:25 ` Abhishek Sahu
2017-01-02 16:12 ` Andy Gross
2017-01-19 5:01 ` Vinod Koul
2017-01-19 14:13 ` Andy Gross
2017-01-19 14:57 ` Abhishek Sahu [this message]
2017-01-20 16:56 ` Vinod Koul
2017-04-07 13:58 ` Abhishek Sahu
2016-12-15 9:55 ` [PATCH 3/5] dmaengine: qca: bam_dma: Add support for bam sgl Abhishek Sahu
2016-12-15 9:55 ` [PATCH 4/5] dmaengine: qca: bam_dma: implement custom data mapping Abhishek Sahu
2016-12-15 9:55 ` [PATCH 5/5] dmaengine: qca: bam_dma: implement command descriptor Abhishek Sahu
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=5332b039ab52d2ef7353121615871757@codeaurora.org \
--to=absahu@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=arnd@arndb.de \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=okaya@codeaurora.org \
--cc=pramod.gurav@linaro.org \
--cc=stanimir.varbanov@linaro.org \
--cc=vinod.koul@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome