[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdaqTYK5TJL2u+aeOfnzhdtdjxZhyu661eGKrNBOXTUTeA@mail.gmail.com>
Date: Thu, 8 Sep 2011 12:29:01 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Viresh Kumar <viresh.kumar@...com>
Cc: "Koul, Vinod" <vinod.koul@...el.com>,
Pratyush ANAND <pratyush.anand@...com>,
Rajeev KUMAR <rajeev-dlh.kumar@...com>,
"linux@....linux.org.uk" <linux@....linux.org.uk>,
Bhupesh SHARMA <bhupesh.sharma@...com>,
Armando VISCONTI <armando.visconti@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Vipin KUMAR <vipin.kumar@...com>,
Shiraz HASHIM <shiraz.hashim@...com>,
Amit VIRDI <Amit.VIRDI@...com>,
Vipul Kumar SAMAR <vipulkumar.samar@...com>,
"viresh.linux@...il.com" <viresh.linux@...il.com>,
Deepak SIKRI <deepak.sikri@...com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 16/18] dmaengine/amba-pl08x: Add support for sg len
greater than one for slave transfers
On Thu, Sep 8, 2011 at 5:50 AM, Viresh Kumar <viresh.kumar@...com> wrote:
> If i am getting this clearly, the concern is "why to queue separate transfers for
> individual sg's? Better would be to prepare the complete list at once and
> start the transfer, so that DMA stops only after finishing all sg's
> passed from user." Is this what you are pointing at?
Yes.
> If yes, then the same is done in this patch too. An array for llis is allocated at
> the start, then for each sg i prepare lli list from this array. Last lli from one sg
> is followed by first lli from next sg. And so i get a continuous chain of llis.
OK so I guess I was lost in the code ...
So this is mainy cached as txd->dsg_list so you can quickly retrieve the
number of bytes pending in the LLI by traversing that sglist.
This is better than what the coh901318 does, because that driver
resorts to going into the physical LLIs themselves to retrieve this
info.
It also seems like this will play nice with Per Forlin's MMC
speed-up patches, so that will become effective for your MMC
usecases.
Now I really like this patch.
Sorry for being such a slow learner!
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists