Message-ID: <20161220202511.GD3047@hector.attlocal.net>
Date:   Tue, 20 Dec 2016 14:25:11 -0600
From:   Andy Gross <andy.gross@...aro.org>
To:     Abhishek Sahu <absahu@...eaurora.org>
Cc:     Vinod Koul <vinod.koul@...el.com>, dan.j.williams@...el.com,
        stanimir.varbanov@...aro.org, mcgrof@...e.com,
        okaya@...eaurora.org, pramod.gurav@...aro.org, arnd@...db.de,
        linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 2/5] dmaengine: Add support for custom data mapping

On Wed, Dec 21, 2016 at 12:58:50AM +0530, Abhishek Sahu wrote:

<snip>

> >>Okay, do you have pointer on that one, will avoid asking the same
> >>questions
> >>again.
> >
> >I'll see if I can find the correspondance and send to you directly.
> >
> >>
> >>> Ahbishek, correct me where i am wrong on the following:
> >>> So two main differences between a normal descriptor and a command descriptor:
> >>> 1) size of the descriptor
> >>> 2) the flag setting
> >>> 3) data sent in is a modified scatter gather that includes flags , vs a normal
> >>> scatter gather
> 
> Top level descriptor is same for both. Only difference is Command flag. The
> command descriptor will contain list of register read/write instead of data
> address
> The peripheral driver can form the list with helper function provided in
> patch 5
> and submit it to BAM. The main issue is for other flag like EOT/NWD.
> 
> The top level descriptor is again in the form of list where BAM writes the
> address of the list in register before starting of transfer. In this list,
> each element will have different flags.

Ah that's right.  The command descriptor information is the format of the data
pointed to by the sgl.  So you'd have some set of register read/writes described
in those entries.

> 
> >>>
> >>> So the CMD descriptors in a given sgl can all have varying flags set? I'd assume
> >>> they all have CMD flag set.  Do the current users of the command descriptors
> >>> coalesce all of their requests into a big list?
> >>>
> 
> The main user for command descriptor is currently QPIC NAND/LCD. The NAND
> uses
> 3 BAM channels- tx, rx and command. NAND controller do the data transfer in
> chunk of codeword (maximum 544 bytes). NAND chip does the data transfer on
> page basis so each page read/write can have multiple codewords. The NAND
> driver prepares command, tx(write) or rx(read) descriptor for complete page
> , submit it to BAM and wait for its completion. So NAND driver coalesces
> all of their requests into a big list. In this big list,
> 
> 1. Some of the request for command channel requires NWD flag to be set.

I'd expect this to occur at the end of a chain.  So if you had 5 CMD descriptors
described in the SGL, only the last descriptor would have the NWD set.  Correct?

> 2. TX request depends upon the setting of EOT flag so some of the TX request
>    in complete page write will contain EOT flag and others will not. So this
>    custom mapping will be used for data descriptor also in NAND driver.

Can you give a sequence description of the descriptors and flags?  I haven't
seen the NAND documentation that describes the sequence/flow.

> >>> So a couple of thoughts on how to deal with this:
> >>>
> >>> 1) Define a virtual channel for the command descriptors vs a normal DMA
> >>> transaction.  This lets you use the same hardware channel, but lets you discern
> >>> which descriptor format you need to use.  The only issue I see with this is the
> >>> required change in device tree binding to target the right type of channel (cmd
> >>> vs normal).
> >>
> >>Or mark the descriptor is cmd and write accordingly...
> >
> >The only issue i see with that is knowing how much to pre-allocate during
> >the
> >prep call.  The flag set API would be called on the allocated tx
> >descriptor.  So
> >you'd have to know up front and be able to specify it.
> >
> >>
> >>>
> >>> 2) Provide an API to set flags for the descriptor on a whole descriptor basis.
> >>>
> >>> 3) If you have a set of transactions described by an sgl that has disparate use
> >>> of flags, you split the list and use a separate transaction.  In other words, we
> >>> need to enforce that the flag set API will be applied to all descriptors
> >>> described by an sgl.  This means that the whole transaction may be comprised of
> >>> multiple async TX descriptors.
> 
> Each async TX descriptor will generate the BAM interrupt so we are deviating
> from main purpose of DMA where ideally we should get the interrupt at the
> end
> of transfer. This is the main reason for going for this patch.

If the client queues 1 descriptor or 5 descriptors, it doesn't matter that much.
The client knows when it is done by waiting for the descriptors to complete.  It
is less efficient than grouping them all, but it should still work.

> 
> With the submitted patch, only 1 interrupt per channel is required for
> complete NAND page and it solves the setting of BAM specific flags also.
> Only issue with this patch is adding new API in DMA framework itself. But
> this API can be used by other DMA engines in future for which mapping cannot
> be done with available APIs and if this mapping is vendor specific.

I guess the key point in all of this is that the DMA operation being done is not
a normal data flow to/from the device.  It's direct remote register access to
the device using address information contained in the sgl.  And you are
collating the standard data access along with the special command access in the
same API call.

Regards,

Andy

Powered by blists - more mailing lists