On Mon, Aug 22, 2016 at 09:27:04AM -0400, Sinan Kaya wrote:
> > You didn't answer my question!
> >
> > On error you said you flush, so who does that?
>
> This is done by the driver in interrupt context when an error
> interrupt is received. All transactions are posted and
On 8/22/2016 2:08 AM, Vinod Koul wrote:
> On Fri, Aug 19, 2016 at 01:21:34PM -0400, Sinan Kaya wrote:
>> On 8/19/2016 1:02 PM, Vinod Koul wrote:
>>> On Fri, Aug 19, 2016 at 07:13:43AM -0400, ok...@codeaurora.org wrote:
On 2016-08-19 01:52, Vinod Koul wrote:
> On Thu, Aug 18, 2016 at 11:48:
On Fri, Aug 19, 2016 at 01:21:34PM -0400, Sinan Kaya wrote:
> On 8/19/2016 1:02 PM, Vinod Koul wrote:
> > On Fri, Aug 19, 2016 at 07:13:43AM -0400, ok...@codeaurora.org wrote:
> >> On 2016-08-19 01:52, Vinod Koul wrote:
> >>> On Thu, Aug 18, 2016 at 11:48:52PM -0400, Sinan Kaya wrote:
> On 8/1
On 8/19/2016 1:02 PM, Vinod Koul wrote:
> On Fri, Aug 19, 2016 at 07:13:43AM -0400, ok...@codeaurora.org wrote:
>> On 2016-08-19 01:52, Vinod Koul wrote:
>>> On Thu, Aug 18, 2016 at 11:48:52PM -0400, Sinan Kaya wrote:
On 8/18/2016 11:42 PM, Vinod Koul wrote:
> On Thu, Aug 18, 2016 at 11:26
On Fri, Aug 19, 2016 at 07:13:43AM -0400, ok...@codeaurora.org wrote:
> On 2016-08-19 01:52, Vinod Koul wrote:
> >On Thu, Aug 18, 2016 at 11:48:52PM -0400, Sinan Kaya wrote:
> >>On 8/18/2016 11:42 PM, Vinod Koul wrote:
> >>> On Thu, Aug 18, 2016 at 11:26:28PM -0400, Sinan Kaya wrote:
> On 8/18
On 2016-08-19 01:52, Vinod Koul wrote:
On Thu, Aug 18, 2016 at 11:48:52PM -0400, Sinan Kaya wrote:
On 8/18/2016 11:42 PM, Vinod Koul wrote:
> On Thu, Aug 18, 2016 at 11:26:28PM -0400, Sinan Kaya wrote:
>> On 8/18/2016 10:48 PM, Vinod Koul wrote:
Keep a size limited list with error cookies a
On Thu, Aug 18, 2016 at 11:48:52PM -0400, Sinan Kaya wrote:
> On 8/18/2016 11:42 PM, Vinod Koul wrote:
> > On Thu, Aug 18, 2016 at 11:26:28PM -0400, Sinan Kaya wrote:
> >> On 8/18/2016 10:48 PM, Vinod Koul wrote:
> Keep a size limited list with error cookies and flush them in terminate
>
On 8/18/2016 11:42 PM, Vinod Koul wrote:
> On Thu, Aug 18, 2016 at 11:26:28PM -0400, Sinan Kaya wrote:
>> On 8/18/2016 10:48 PM, Vinod Koul wrote:
Keep a size limited list with error cookies and flush them in terminate
all?
>>> I think so, terminate_all anyway cleans up the channel. Btw
On 8/18/2016 10:48 PM, Vinod Koul wrote:
>> Keep a size limited list with error cookies and flush them in terminate all?
> I think so, terminate_all anyway cleans up the channel. Btw what is the
> behaviour on error? Do you terminate or somthing else?
>
On error, I flush all outstanding transacti
On Thu, Aug 18, 2016 at 11:26:28PM -0400, Sinan Kaya wrote:
> On 8/18/2016 10:48 PM, Vinod Koul wrote:
> >> Keep a size limited list with error cookies and flush them in terminate
> >> all?
> > I think so, terminate_all anyway cleans up the channel. Btw what is the
> > behaviour on error? Do you t
On Wed, Aug 10, 2016 at 01:31:21PM -0400, Sinan Kaya wrote:
> On 8/10/2016 1:28 PM, Vinod Koul wrote:
> >> That's why, I preferred not to call the callback when I observe an error
> >> which I
> >> > think it makes more sense.
> > That doesnt make sense. A client set a callback, it expect you t
On 8/10/2016 1:28 PM, Vinod Koul wrote:
>> That's why, I preferred not to call the callback when I observe an error
>> which I
>> > think it makes more sense.
> That doesnt make sense. A client set a callback, it expect you to call one.
> The result quried maybe txn completed or error. Since you
On Mon, Aug 08, 2016 at 10:45:24AM -0400, Sinan Kaya wrote:
> On 8/8/2016 5:02 AM, Vinod Koul wrote:
> >> What Vinod is telling me that I need to set the cookie to complete
> >> > whether the transaction is successful or not if the request was accepted
> >> > by HW. xyz_tx_status is just an indica
On Mon, Aug 08, 2016 at 02:25:28PM +0200, Lars-Peter Clausen wrote:
> On 08/08/2016 11:08 AM, Vinod Koul wrote:
> > On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote:
> >> On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote:
> >> [...]
> >>> What you instead need to do is to fin
On 8/8/2016 5:02 AM, Vinod Koul wrote:
>> What Vinod is telling me that I need to set the cookie to complete
>> > whether the transaction is successful or not if the request was accepted
>> > by HW. xyz_tx_status is just an indication that the transaction was
>> > accepted
>> > by HW. An error ca
On 08/08/2016 11:08 AM, Vinod Koul wrote:
> On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote:
>> On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote:
>> [...]
>>> What you instead need to do is to find some way to record in your
>>> driver that transaction 2 failed, and when dm
On 2016-08-08 04:51, Vinod Koul wrote:
This patch is needed to fix a race condition as the commit message
describes.
The callback is called before returning the descriptor back to free
pool.
If the client calls free resources, the descriptor that was not
returned to free pool gets lost due
On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote:
> On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote:
> [...]
> > What you instead need to do is to find some way to record in your
> > driver that transaction 2 failed, and when dma_cookie_status() says
> > that a transaction
On Thu, Aug 04, 2016 at 11:27:46AM -0400, Sinan Kaya wrote:
> On 8/4/2016 10:40 AM, Russell King - ARM Linux wrote:
> > On Thu, Aug 04, 2016 at 10:17:24AM -0400, Sinan Kaya wrote:
> >> On 8/4/2016 8:55 AM, Vinod Koul wrote:
> >>> Dmaengine tells transaction is complete. It does not say if the txn i
On Thu, Aug 04, 2016 at 10:17:24AM -0400, Sinan Kaya wrote:
> On 8/4/2016 8:55 AM, Vinod Koul wrote:
> > Dmaengine tells transaction is complete. It does not say if the txn is
> > success or failure. It can transfer data and not say if data was
> > correct. A successful transaction implies data int
On 8/5/2016 4:34 AM, Lars-Peter Clausen wrote:
> I believe we need to invest some effort to come up with clear semantics on
> what is the expected behavior when transferring a descriptor fails.
> Potentially allowing clients to choose the desired behavior, e.g. either
> abort all descriptors on err
On 08/05/2016 08:32 AM, Robert Jarzmik wrote:
> Lars-Peter Clausen writes:
>
>> On 08/04/2016 06:08 PM, Sinan Kaya wrote:
>> [...]
>>> The other way is I can feed this information to what Dave just introduced
>>> as part of the callback mechanism and not touch this.
>>
>> Use the callback mechani
Lars-Peter Clausen writes:
> On 08/04/2016 06:08 PM, Sinan Kaya wrote:
> [...]
>> The other way is I can feed this information to what Dave just introduced
>> as part of the callback mechanism and not touch this.
>
> Use the callback mechanism. It is a lot easier to implement correctly than
> the
On 08/04/2016 06:08 PM, Sinan Kaya wrote:
[...]
> The other way is I can feed this information to what Dave just introduced
> as part of the callback mechanism and not touch this.
Use the callback mechanism. It is a lot easier to implement correctly than
the tx_status() mechanism.
> The main disc
On 8/4/2016 11:38 AM, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:27:46AM -0400, Sinan Kaya wrote:
>> On 8/4/2016 10:40 AM, Russell King - ARM Linux wrote:
>>> On Thu, Aug 04, 2016 at 10:17:24AM -0400, Sinan Kaya wrote:
Thanks for describing this. I was confused about DMA_SUCC
On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote:
[...]
> What you instead need to do is to find some way to record in your
> driver that transaction 2 failed, and when dma_cookie_status() says
> that a transaction has DMA_COMPLETE status, you need to look up to
> see whether it failed.
In m
On 8/4/2016 10:40 AM, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 10:17:24AM -0400, Sinan Kaya wrote:
>> On 8/4/2016 8:55 AM, Vinod Koul wrote:
>>> Dmaengine tells transaction is complete. It does not say if the txn is
>>> success or failure. It can transfer data and not say if data w
On Thu, Aug 04, 2016 at 11:27:46AM -0400, Sinan Kaya wrote:
> On 8/4/2016 10:40 AM, Russell King - ARM Linux wrote:
> > On Thu, Aug 04, 2016 at 10:17:24AM -0400, Sinan Kaya wrote:
> >> Thanks for describing this. I was confused about DMA_SUCCESS and
> >> DMA_COMPLETE.
> >> I now understand that tx
On Thu, Aug 04, 2016 at 10:17:24AM -0400, Sinan Kaya wrote:
> On 8/4/2016 8:55 AM, Vinod Koul wrote:
> > Dmaengine tells transaction is complete. It does not say if the txn is
> > success or failure. It can transfer data and not say if data was
> > correct. A successful transaction implies data int
On 8/4/2016 8:55 AM, Vinod Koul wrote:
> Dmaengine tells transaction is complete. It does not say if the txn is
> success or failure. It can transfer data and not say if data was
> correct. A successful transaction implies data integrity as well, which
> dmaengine can't provide.
Thanks for describ
On Mon, Jul 25, 2016 at 10:19:44AM -0400, Sinan Kaya wrote:
> >>
> >> It looks like I introduced a behavioral change while refactoring the code.
> >> The previous one would call the callback only if the transfer was
> >> successful
> >> but it would always call dma_cookie_complete.
> >>
> >> The n
Hi,
On 7/24/2016 2:24 AM, Vinod Koul wrote:
> On Fri, Jul 15, 2016 at 09:00:52PM -0400, Sinan Kaya wrote:
>> Hi Vinod,
>>
>> On 7/13/2016 10:57 PM, Sinan Kaya wrote:
>>> There is a race condition between data transfer callback and descriptor
>>> free code. The callback routine may decide to clear
On Fri, Jul 15, 2016 at 09:00:52PM -0400, Sinan Kaya wrote:
> Hi Vinod,
>
> On 7/13/2016 10:57 PM, Sinan Kaya wrote:
> > There is a race condition between data transfer callback and descriptor
> > free code. The callback routine may decide to clear the resources even
> > though the descriptor has
Hi Vinod,
On 7/13/2016 10:57 PM, Sinan Kaya wrote:
> There is a race condition between data transfer callback and descriptor
> free code. The callback routine may decide to clear the resources even
> though the descriptor has not yet been freed.
>
> Instead of calling the callback first and then
34 matches
Mail list logo
