From: Vinod Koul <vinod.koul@intel.com> To: Sinan Kaya <okaya@codeaurora.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>, linux-arm-msm@vger.kernel.org, timur@codeaurora.org, linux-kernel@vger.kernel.org, Christopher Covington <cov@codeaurora.org>, dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback Date: Fri, 19 Aug 2016 08:18:53 +0530 [thread overview] Message-ID: <20160819024853.GR9681@localhost> (raw) In-Reply-To: <d09ebb5f-99ea-a4e9-da9c-693be89c7cd4@codeaurora.org> <sorry for delay, i was out> 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 to call one. > > The result quried maybe txn completed or error. Since you have means, please > > report.. > > > > If there is a good way to fix tx_status, I can certainly do so. I just need to make > sure my implementation is robust and reliable. > > I saw your reply that we need to keep this information around until terminate_all is > called. > > What is a good implementation strategy? > > 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? > What should I do if code reaches to the size limit? > > Size the error cookie list double the size of available descriptors? That won't help as you would have two values per cookie and we dont want that :) > >> Again, it will be a different patch than this one. I think v2 of this patch > >> > needs to go in as it is. > >> > > >> > https://lkml.org/lkml/2016/7/31/64 > > I havent looked at the patch. If it is not invoking callback set by user, > > then I am not taking it. Sorry, we dont choose over client's wish. > > Ok. The problem you are referring to is something else and needs to be addressed > separately. I can create a series with first implement a reliable tx_status based > on your recommendation above. > > Then, change the current behavior so that client callback is always executed as you > requested. > > After that this patch to fix the free order. -- ~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: qcom_hidma: release the descriptor before the callback Date: Fri, 19 Aug 2016 08:18:53 +0530 [thread overview] Message-ID: <20160819024853.GR9681@localhost> (raw) In-Reply-To: <d09ebb5f-99ea-a4e9-da9c-693be89c7cd4@codeaurora.org> <sorry for delay, i was out> 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 to call one. > > The result quried maybe txn completed or error. Since you have means, please > > report.. > > > > If there is a good way to fix tx_status, I can certainly do so. I just need to make > sure my implementation is robust and reliable. > > I saw your reply that we need to keep this information around until terminate_all is > called. > > What is a good implementation strategy? > > 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? > What should I do if code reaches to the size limit? > > Size the error cookie list double the size of available descriptors? That won't help as you would have two values per cookie and we dont want that :) > >> Again, it will be a different patch than this one. I think v2 of this patch > >> > needs to go in as it is. > >> > > >> > https://lkml.org/lkml/2016/7/31/64 > > I havent looked at the patch. If it is not invoking callback set by user, > > then I am not taking it. Sorry, we dont choose over client's wish. > > Ok. The problem you are referring to is something else and needs to be addressed > separately. I can create a series with first implement a reliable tx_status based > on your recommendation above. > > Then, change the current behavior so that client callback is always executed as you > requested. > > After that this patch to fix the free order. -- ~Vinod
next prev parent reply other threads:[~2016-08-19 2:48 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-07-14 2:57 [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback Sinan Kaya 2016-07-14 2:57 ` Sinan Kaya 2016-07-16 1:00 ` Sinan Kaya 2016-07-16 1:00 ` Sinan Kaya 2016-07-24 6:24 ` Vinod Koul 2016-07-24 6:24 ` Vinod Koul 2016-07-25 14:19 ` Sinan Kaya 2016-07-25 14:19 ` Sinan Kaya 2016-08-04 12:55 ` Vinod Koul 2016-08-04 12:55 ` Vinod Koul 2016-08-04 12:55 ` Vinod Koul 2016-08-04 14:17 ` Sinan Kaya 2016-08-04 14:17 ` Sinan Kaya 2016-08-04 14:40 ` Russell King - ARM Linux 2016-08-04 14:40 ` Russell King - ARM Linux 2016-08-04 15:27 ` Sinan Kaya 2016-08-04 15:27 ` Sinan Kaya 2016-08-04 15:38 ` Russell King - ARM Linux 2016-08-04 15:38 ` Russell King - ARM Linux 2016-08-04 15:59 ` Lars-Peter Clausen 2016-08-04 15:59 ` Lars-Peter Clausen 2016-08-08 9:08 ` Vinod Koul 2016-08-08 9:08 ` Vinod Koul 2016-08-08 12:25 ` Lars-Peter Clausen 2016-08-08 12:25 ` Lars-Peter Clausen 2016-08-10 17:23 ` Vinod Koul 2016-08-10 17:23 ` Vinod Koul 2016-08-10 17:23 ` Vinod Koul 2016-08-04 16:08 ` Sinan Kaya 2016-08-04 16:08 ` Sinan Kaya 2016-08-04 16:15 ` Lars-Peter Clausen 2016-08-04 16:15 ` Lars-Peter Clausen 2016-08-05 6:32 ` Robert Jarzmik 2016-08-05 6:32 ` Robert Jarzmik 2016-08-05 8:34 ` Lars-Peter Clausen 2016-08-05 8:34 ` Lars-Peter Clausen 2016-08-05 8:34 ` Lars-Peter Clausen 2016-08-05 15:17 ` Sinan Kaya 2016-08-05 15:17 ` Sinan Kaya 2016-08-08 9:02 ` Vinod Koul 2016-08-08 9:02 ` Vinod Koul 2016-08-08 14:45 ` Sinan Kaya 2016-08-08 14:45 ` Sinan Kaya 2016-08-10 17:28 ` Vinod Koul 2016-08-10 17:28 ` Vinod Koul 2016-08-10 17:28 ` Vinod Koul 2016-08-10 17:31 ` Sinan Kaya 2016-08-10 17:31 ` Sinan Kaya 2016-08-10 17:31 ` Sinan Kaya 2016-08-19 2:48 ` Vinod Koul [this message] 2016-08-19 2:48 ` Vinod Koul 2016-08-19 3:26 ` Sinan Kaya 2016-08-19 3:26 ` Sinan Kaya 2016-08-19 3:26 ` Sinan Kaya 2016-08-19 3:42 ` Vinod Koul 2016-08-19 3:42 ` Vinod Koul 2016-08-19 3:48 ` Sinan Kaya 2016-08-19 3:48 ` Sinan Kaya 2016-08-19 5:52 ` Vinod Koul 2016-08-19 5:52 ` Vinod Koul 2016-08-19 11:13 ` okaya 2016-08-19 11:13 ` okaya at codeaurora.org 2016-08-19 11:13 ` okaya 2016-08-19 17:02 ` Vinod Koul 2016-08-19 17:02 ` Vinod Koul 2016-08-19 17:02 ` Vinod Koul 2016-08-19 17:21 ` Sinan Kaya 2016-08-19 17:21 ` Sinan Kaya 2016-08-19 17:21 ` Sinan Kaya 2016-08-22 6:08 ` Vinod Koul 2016-08-22 6:08 ` Vinod Koul 2016-08-22 6:08 ` Vinod Koul 2016-08-22 13:27 ` Sinan Kaya 2016-08-22 13:27 ` Sinan Kaya 2016-08-22 17:00 ` Vinod Koul 2016-08-22 17:00 ` Vinod Koul 2016-08-08 8:51 ` Vinod Koul 2016-08-08 8:51 ` Vinod Koul 2016-08-08 12:10 ` okaya 2016-08-08 12:10 ` okaya at codeaurora.org
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=20160819024853.GR9681@localhost \ --to=vinod.koul@intel.com \ --cc=cov@codeaurora.org \ --cc=dmaengine@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=okaya@codeaurora.org \ --cc=timur@codeaurora.org \ /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: linkBe 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.