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
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
