linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Gross <andy.gross@linaro.org>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Abhishek Sahu <absahu@codeaurora.org>,
	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 08:13:17 -0600	[thread overview]
Message-ID: <20170119141317.GA9631@hector.attlocal.net> (raw)
In-Reply-To: <20170119050150.GI3573@localhost>

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.

Regards,

Andy

  reply	other threads:[~2017-01-19 14:22 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 [this message]
2017-01-19 14:57                           ` Abhishek Sahu
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=20170119141317.GA9631@hector.attlocal.net \
    --to=andy.gross@linaro.org \
    --cc=absahu@codeaurora.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;
as well as URLs for NNTP newsgroup(s).