Re: [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver

[Barry Song]

2011/9/9 Vinod Koul <vkoul@xxxxxxxxxxxxx>:
> On Thu, 2011-09-08 at 10:55 +0530, Jassi Brar wrote:
>> On Thu, Sep 8, 2011 at 8:47 AM, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote:
>> > On Thu, Sep 8, 2011 at 7:42 AM, Barry Song <21cnbao@xxxxxxxxx> wrote:
>> >
>> >>>> it is much different with primacell based DMA like pl080, pl330.
>> >>>> prima2 has a self-defined DMAC IP. basically it is a 2D mode dma with
>> >>>> two scales X and Y and direct way to start and stop DMA.
>> >>>> every channel has fixed function to serve only one perpheral. so you
>> >>>> find we have a filter id.
>> >>> okay, what do you mean by 2D mode? Is it similar to what TI folks, Linus
>> >>> W and Jassi Brar posted RFC's on?
>> >>
>> >> In SiRFprimaII 2-D DMA, the system memory space is interpreted
>> >> as a 2-D layout instead of a linear 1-D layout. More specifically, the
>> >> system memory can be considered as
>> >> multiple data lines. The length of the data line is determined by the
>> >> user-selected DMA_WIDTH register.
>> >> The user can specify a data window that the user wants to access using
>> >> four parameters:
>> >> â Start address
>> >> â X length
>> >> â Y length
>> >> â Width
>> >>
>> >> The idea of a 2-D DMA is shown in figure 2d-dma.png attached.
>> >>
>> >> If you specifies the Y length as 0 or the X length equals to the DMA
>> >> width, then this 2-D DMA reduces to
>> >> 1-D. If the user configures the X length greater than the DMA width,
>> >> then the extra data is wrapped around
>> >> to the next data line, this may corrupt the DMA transfer for
>> >> multiple-line 2-D DMA. If this is a 1-D DMA, then
>> >> there is no issue. The attached diagram 2d-dma2.png shows the
>> >> wrap-around of the extra data in case the X length
>> >> greater than DMA width.
>> >
>> > Sorry, the role of DMA_WIDTH is not clear to me yet.
>> > In which case the user _must_ set {xlen > width} ?
>> >
>> Perhaps 2d-dma.PNG is inaccurate - it shouldn't depict any deltaX.
>> Doesn't xlen and width always start together ? If no, please don't read ahead.
>>
>> According to figures, {xlen > width} is to be set _only_ when a transfer
>> is divided into _exactly_ two chunks separated by gap _exactly_
>> equal to length of the second chunk (an extremely rare case).
>>
>> Anyways, every case can be easily expressed using the generic api
>> I proposed. See 'struct xfer_template' in https://lkml.org/lkml/2011/8/12/128
>>
>> Roughly speaking, the following should be done...
>> Client driver :-
>> **************
>> For a 'Rectangular' transfer (2d-dma.PNG) :-
>> Â Â Â xfer_template.numf = Ylen; Â/* height of rectangle */
>> Â Â Â xfer_template.frame_size = 1;
>> Â Â Â xfer_template.sgl[0].size = Xlen; /* width of rectangle */
>> Â Â Â xfer_template.sgl[0].icg = start_addr_Y(n) - end_addr_Y(n-1);
>>
>> For the "A Line and some" transfer (2d-dma2.PNG) :-
>> Â Â Â xfer_template.numf = 1;
>> Â Â Â xfer_template.frame_size = 2;
>> Â Â Â xfer_template.sgl[0].size = xlen1; /* a line */
>> Â Â Â xfer_template.sgl[1].size = xlen2; Â/* and some */
>> Â Â Â xfer_template.sgl[0].icg = start_addr_Y(n) - end_addr_Y(n-1);
>> Â Â Â xfer_template.sgl[1].icg = 0; /* doesn't matter */
>>
>> DMAC driver :-
>> ***************
>> Â Â Â if (xfer_template.frame_size == 1) {
>> Â Â Â Â Â Â/* rectangle */
>> Â Â Â Â Â Âschan->xlen = xfer_template.sgl[0].size;
>> Â Â Â Â Â Âschan->width = schan->xlen + xfer_template.sgl[0].icg;
>> Â Â Â } else if (xfer_template.frame_size == 2 &&
>> Â Â Â Â Â Â Â Â Â xfer_template.numf == 1 &&
>> Â Â Â Â Â Â Â Â Â xfer_template.sgl[1].size == xfer_template.sgl[0].icg){
>> Â Â Â Â Â Â/* a line and some */
>> Â Â Â Â Â Âschan->xlen = xfer_template.sgl[0].size + Âxfer_template.sgl[1].size.
>> Â Â Â Â Â Âschan->width = xfer_template.sgl[0].size;
>> Â Â Â } else {
>> Â Â Â Â Â Â/* _Hardware_ doesn't support the transfer as such. *
>> Â Â Â Â Â Âreturn -EINVAL;
>> Â Â Â }
>> Â Â Â schan->ylen = xfer_template.numf /* -1? */;
> Looks like Jassi got a user for his proposed API. I am not sure whats
> going on with TI folks, they never showed up here @LPC.

yes, i can definitely be an user of Jassi's new generic api. it seems
the api is just there for dma in 2d.

Jassi prefer to use a transfer type instead of a control command.
though we will not really change the interleaved setting for every
transfer(it is more possible for one device, we will not change the
xlen/ylen/dma_width setting in the whole life period), i do believe
the transfer type is enough flexible for my possible applications to
change xlen, ylen and dma_width in different transfers.

as we know, interleaved DMA can also be used for audio driver. for
some audio controllers, if there are n channels, it can't tranfer the
whole audio frame to sound card by one dma channel, and it needs to
tranfer every channel by separate dma. typically, we can define this
kind of xfer to skip other n-1 channel.

Jassi, you might think my reply as an ACK to "[PATCH] DMAEngine:
Define generic transfer request api".

>
>
> --
> ~Vinod Koul
> Intel Corp.
>
>

thanks
barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/