On Tue, Sep 14, 2010 at 12:51:09PM -0500, Sergei Shtylyov wrote:
Hello.
Felipe Balbi wrote:
If a DMA interrupt comes when the whole transfer is not yet
complete (and
other Ming Lei's patches are making this possible),
Oh, here I mixed some other patch with Ming Lei's ones...
it will
2010/9/15 Felipe Balbi ba...@ti.com:
if request-length == 1MB and dma-max_len = 128KB, when is_dma is true,
request-actual will be different from request-length for 7
'iterations', then only on the 8th it will be the same. I believe that's
what Ming is trying to fix.
Ming, am I correct ?
Hello.
On 15-09-2010 10:53, Felipe Balbi wrote:
If a DMA interrupt comes when the whole transfer is not yet
complete (and
other Ming Lei's patches are making this possible),
Oh, here I mixed some other patch with Ming Lei's ones...
it will pass due to the
than this is the actual
Hi,
On Wed, Sep 15, 2010 at 05:01:05AM -0500, Sergei Shtylyov wrote:
I didn't say it was duplicate for DMA, just too late.
how come ? we need to send ZLP before giving back the request.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
Hello.
On 15-09-2010 14:05, Felipe Balbi wrote:
I didn't say it was duplicate for DMA, just too late.
how come ? we need to send ZLP before giving back the request.
Well, look at the code ionce again. We need to send ZLP *after*
request-actual == request-length, but as the check is
2010/9/15 Sergei Shtylyov sshtyl...@mvista.com:
Hello.
On 15-09-2010 14:05, Felipe Balbi wrote:
I didn't say it was duplicate for DMA, just too late.
how come ? we need to send ZLP before giving back the request.
Well, look at the code ionce again. We need to send ZLP *after*
Hello.
On 15-09-2010 14:14, Ming Lei wrote:
I didn't say it was duplicate for DMA, just too late.
how come ? we need to send ZLP before giving back the request.
Well, look at the code ionce again. We need to send ZLP *after*
request-actual == request-length, but as the check is
Hi,
On Wed, Sep 15, 2010 at 05:18:47AM -0500, Sergei Shtylyov wrote:
I don't see why we should fix only this problem, while it's obvious tha
the fix is incomplete and leaves the other problem exposed. Please recast the
patch.
IMO, the ZLP fix is *another* fix and as such subject to a
On 15.09.2010 14:22, Felipe Balbi wrote:
I don't see why we should fix only this problem, while it's obvious tha
the fix is incomplete and leaves the other problem exposed. Please recast the
patch.
IMO, the ZLP fix is *another* fix and as such subject to a different
patch.
IMHO, this
Hi,
On Wed, Sep 15, 2010 at 05:27:37AM -0500, Sergei Shtylyov wrote:
IMHO, this fix as it is now is quite stupid. It's clear that the check is
misplaced and will be removed once the ZLP fix is done. So why not do it once
your forgetting the fact that not always you need to send ZLP after
2010/9/15 Sergei Shtylyov sshtyl...@mvista.com:
On 15.09.2010 14:22, Felipe Balbi wrote:
I don't see why we should fix only this problem, while it's obvious tha
the fix is incomplete and leaves the other problem exposed. Please recast
the
patch.
IMO, the ZLP fix is *another* fix and as
Hello.
On 15-09-2010 14:31, Felipe Balbi wrote:
IMHO, this fix as it is now is quite stupid. It's clear that the check is
misplaced and will be removed once the ZLP fix is done. So why not do it once
your forgetting the fact that not always you need to send ZLP after
completing a
Hi,
On Wed, Sep 15, 2010 at 05:41:39AM -0500, Sergei Shtylyov wrote:
your forgetting the fact that not always you need to send ZLP after
completing a packet_size-aligned transfer,
So what?
what you're saying is that when we change the ZLP handling, the
request-actual == request-lenght
Felipe Balbi wrote:
your forgetting the fact that not always you need to send ZLP after
completing a packet_size-aligned transfer,
So what?
what you're saying is that when we change the ZLP handling, the
request-actual == request-lenght check will have to be removed, but
that's not
Hi,
On Mon, Sep 13, 2010 at 11:26:52AM -0500, Sergei Shtylyov wrote:
Oops, I've been too fast and haven't realized that the check done here
_is_ actually wrong. It causes ZLP send to trigger too fast in the DMA
case. So please fix this patch. Felipe, please drop it for now.
patch is not even
Hello.
On 14-09-2010 10:56, Felipe Balbi wrote:
Oops, I've been too fast and haven't realized that the check done here
_is_ actually wrong. It causes ZLP send to trigger too fast in the DMA
case. So please fix this patch. Felipe, please drop it for now.
patch is not even touching that part
Hi,
On Tue, Sep 14, 2010 at 05:46:22AM -0500, Sergei Shtylyov wrote:
If a DMA interrupt comes when the whole transfer is not yet complete (and
other Ming Lei's patches are making this possible), it will pass due to the
than this is the actual problem, no ? If we're using mode1 dma (as we
Hello.
Felipe Balbi wrote:
If a DMA interrupt comes when the whole transfer is not yet
complete (and
other Ming Lei's patches are making this possible),
Oh, here I mixed some other patch with Ming Lei's ones...
it will pass due to the
than this is the actual problem, no ? If
Hello.
tom.leim...@gmail.com wrote:
From: Ming Lei tom.leim...@gmail.com
Complete the current request only if the data transfer is over.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand
2010/9/13 Sergei Shtylyov sshtyl...@mvista.com:
But why not modify the conditional above all that code, just excluding
'is_dma' from it. This conditional already includes (request-actual ==
request-length) check. Please recast this patch.
The two condition is OR relation, not and, so we
Hello.
I wrote:
But why not modify the conditional above all that code, just excluding
'is_dma' from it. This conditional already includes (request-actual ==
request-length) check. Please recast this patch.
The two condition is OR relation, not and, so we can't exclude
'is_dma' simply.
From: Ming Lei tom.leim...@gmail.com
Complete the current request only if the data transfer is over.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger
22 matches
Mail list logo
