From: Gary R Hook <ghook@amd.com>
To: Vinod Koul <vkoul@kernel.org>, "Hook, Gary" <Gary.Hook@amd.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dmaengine: dmatest: timeout value of -1 should specify infinite wait
Date: Tue, 4 Jun 2019 16:47:05 +0000 [thread overview]
Message-ID: <010db7bb-dee2-4ba8-a085-4154735b98db@amd.com> (raw)
In-Reply-To: <20190604122356.GY15118@vkoul-mobl>
On 6/4/19 7:23 AM, Vinod Koul wrote:
> [CAUTION: External Email]
>
> On 31-05-19, 19:43, Hook, Gary wrote:
>> The dmatest module parameter 'timeout' is documented as accepting a
>> -1 to mean "infinite timeout". Change the parameter to to signed
>> integer, and check the value to call the appropriate wait_event()
>> function.
>>
>> Signed-off-by: Gary R Hook <gary.hook@amd.com>
>> ---
>> drivers/dma/dmatest.c | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
>> index b96814a7dceb..28a237686578 100644
>> --- a/drivers/dma/dmatest.c
>> +++ b/drivers/dma/dmatest.c
>> @@ -63,7 +63,7 @@ MODULE_PARM_DESC(pq_sources,
>> "Number of p+q source buffers (default: 3)");
>>
>> static int timeout = 3000;
>> -module_param(timeout, uint, S_IRUGO | S_IWUSR);
>> +module_param(timeout, int, S_IRUGO | S_IWUSR);
>> MODULE_PARM_DESC(timeout, "Transfer Timeout in msec (default: 3000), "
>> "Pass -1 for infinite timeout");
>>
>> @@ -795,8 +795,13 @@ static int dmatest_func(void *data)
>> }
>> dma_async_issue_pending(chan);
>>
>> - wait_event_freezable_timeout(thread->done_wait, done->done,
>> - msecs_to_jiffies(params->timeout));
>> + /* A timeout value of -1 means infinite wait */
>> + if (timeout == -1)
>> + wait_event_freezable(thread->done_wait, done->done);
>
> well i am not too happy that we have a infinite wait and no way to
> cancel, maybe remove this case?
Well, I was uncomfortable with documentation that didn't match behavior.
I see two choices (and I just chose one to start a conversation):
1) Accept this patch, with an infinite timeout, or
2) Leave the data type alone, but change the description to state that
timeout values up to hex 0xFFFFFFFF / decimal 4294967295 can be used,
emulating an "infinite" wait. A very long wait that eventually pops a
timer is probably preferable. I don't think there are any conversion
issues since the jiffy parameter to wait_event_freezable_timeout() is
converted to a long. I could be wrong about that.
I'm happy to go with option (2). Please suggest a course of action.
grh
>
>> + else
>> + wait_event_freezable_timeout(thread->done_wait,
>> + done->done,
>> + msecs_to_jiffies(params->timeout));
>>
>> status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
next prev parent reply other threads:[~2019-06-04 16:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 19:43 Hook, Gary
2019-06-04 12:23 ` Vinod Koul
2019-06-04 16:47 ` Gary R Hook [this message]
2019-06-13 11:12 ` 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=010db7bb-dee2-4ba8-a085-4154735b98db@amd.com \
--to=ghook@amd.com \
--cc=Gary.Hook@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vkoul@kernel.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome