From: Vinod Koul <vinod.koul@intel.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Padma Venkat <padma.kvr@gmail.com>,
Padmavathi Venna <padma.v@samsung.com>,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, dmaengine@vger.kernel.org,
broonie@kernel.org, Dylan Reid <dgreid@chromium.org>
Subject: Re: [PATCH] dmaengine: pl330: Set residue in tx_status callback
Date: Fri, 5 Dec 2014 20:40:14 +0530 [thread overview]
Message-ID: <20141205151014.GK3411@intel.com> (raw)
In-Reply-To: <547DF61D.3010909@metafoo.de>
On Tue, Dec 02, 2014 at 06:25:49PM +0100, Lars-Peter Clausen wrote:
> On 12/02/2014 06:38 AM, Padma Venkat wrote:
>
> Well it doesn't break audio, but I don't think it has the correct
> haviour for all cases yet.
>
> Again, the semantics are that it should return the progress of the
> transfer for which the allocation function returned the cookie that
> is passe to this function. You have to consider that there might be
> multiple different descriptors submitted and in the work list, not
> just the one we want to know the status of. The big problem with the
> pl330 driver is that the current structure of the driver makes it
> not so easy to implement the residue reporting correctly.
well you can use the completed_cookie as hint. This was last trasaction
which was issues, so calculate remianing bytes for this and subsequent ones
resiude would only be size of transaction
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dmaengine: pl330: Set residue in tx_status callback
Date: Fri, 5 Dec 2014 20:40:14 +0530 [thread overview]
Message-ID: <20141205151014.GK3411@intel.com> (raw)
In-Reply-To: <547DF61D.3010909@metafoo.de>
On Tue, Dec 02, 2014 at 06:25:49PM +0100, Lars-Peter Clausen wrote:
> On 12/02/2014 06:38 AM, Padma Venkat wrote:
>
> Well it doesn't break audio, but I don't think it has the correct
> haviour for all cases yet.
>
> Again, the semantics are that it should return the progress of the
> transfer for which the allocation function returned the cookie that
> is passe to this function. You have to consider that there might be
> multiple different descriptors submitted and in the work list, not
> just the one we want to know the status of. The big problem with the
> pl330 driver is that the current structure of the driver makes it
> not so easy to implement the residue reporting correctly.
well you can use the completed_cookie as hint. This was last trasaction
which was issues, so calculate remianing bytes for this and subsequent ones
resiude would only be size of transaction
--
~Vinod
next prev parent reply other threads:[~2014-12-05 15:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 9:44 [PATCH] dmaengine: pl330: Set residue in tx_status callback Padmavathi Venna
2014-11-26 9:44 ` Padmavathi Venna
2014-12-02 5:38 ` Padma Venkat
2014-12-02 5:38 ` Padma Venkat
2014-12-02 17:25 ` Lars-Peter Clausen
2014-12-02 17:25 ` Lars-Peter Clausen
2014-12-03 4:47 ` Padma Venkat
2014-12-03 4:47 ` Padma Venkat
2014-12-03 7:51 ` Jassi Brar
2014-12-03 7:51 ` Jassi Brar
2014-12-05 15:15 ` Vinod Koul
2014-12-05 15:15 ` Vinod Koul
2014-12-05 15:18 ` Russell King - ARM Linux
2014-12-05 15:18 ` Russell King - ARM Linux
2014-12-06 7:01 ` Jassi Brar
2014-12-06 7:01 ` Jassi Brar
2014-12-08 13:07 ` Vinod Koul
2014-12-08 13:07 ` Vinod Koul
2014-12-08 14:23 ` Russell King - ARM Linux
2014-12-08 14:23 ` Russell King - ARM Linux
2014-12-09 6:10 ` Vinod Koul
2014-12-09 6:10 ` Vinod Koul
2014-12-09 15:18 ` Jassi Brar
2014-12-09 15:18 ` Jassi Brar
2014-12-11 4:47 ` Vinod Koul
2014-12-11 4:47 ` Vinod Koul
2014-12-11 6:12 ` Jassi Brar
2014-12-11 6:12 ` Jassi Brar
2015-03-12 8:47 ` Jassi Brar
2015-03-12 8:47 ` Jassi Brar
2014-12-04 20:15 ` Lars-Peter Clausen
2014-12-04 20:15 ` Lars-Peter Clausen
2014-12-05 15:10 ` Vinod Koul [this message]
2014-12-05 15:10 ` Vinod Koul
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=20141205151014.GK3411@intel.com \
--to=vinod.koul@intel.com \
--cc=broonie@kernel.org \
--cc=dgreid@chromium.org \
--cc=dmaengine@vger.kernel.org \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=padma.kvr@gmail.com \
--cc=padma.v@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.