From: Felipe Contreras <felipe.contreras@nokia.com>
To: fernando.lugo@ti.com, felipe.contreras@gmail.com
Cc: gregkh@suse.de, hiroshi.doyu@nokia.com,
linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible
Date: Tue, 26 Oct 2010 20:03:22 +0300 [thread overview]
Message-ID: <1288112260-notmuch-felipe.contreras@nokia.com> (raw)
In-Reply-To: <496565EC904933469F292DDA3F1663E602F49E2802@dlee06.ent.ti.com>
fernando.lugo@ti.com wrote:
> > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
> > <x0095840@ti.com> wrote:
> > > So that avoid non-killable process.
> >
> > It would be useful to interrupt these tasks from user-space.
> > A separate ioctl to do that would be needed.
>
> I don't see use case where that could be needed. It is only
> To avoid a nonkillable task in the case the user pass an infinite
> Timeout.
>
> If you have some test case where that ioctl would be needed
> Please share it in order to find the best solution.
Well, imagine the application is using a library to access the DSP, and
the library has a dedicated thread listening for DSP events in a loop.
This happens to be how libomxil-ti and gst-dsp work.
Now, the thread received the last message, but has set a timeout of 10s,
or even worst, no timeout at all.
After realizing that was the last message, the main thread decides to
shut down, but it has to wait for the DSP thread to join. Unfortunately
the DSP thread is stuck waiting for events, and there's nothing that can
be done.
However, if we have a separate ioctl to interrupt that task, then the
main thread can issue that ioctl, and unlock the DSP thread without
having to wait 10s, or forever.
Does that make sense?
--
Felipe Contreras
WARNING: multiple messages have this Message-ID (diff)
From: felipe.contreras@nokia.com (Felipe Contreras)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible
Date: Tue, 26 Oct 2010 20:03:22 +0300 [thread overview]
Message-ID: <1288112260-notmuch-felipe.contreras@nokia.com> (raw)
In-Reply-To: <496565EC904933469F292DDA3F1663E602F49E2802@dlee06.ent.ti.com>
fernando.lugo at ti.com wrote:
> > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
> > <x0095840@ti.com> wrote:
> > > So that avoid non-killable process.
> >
> > It would be useful to interrupt these tasks from user-space.
> > A separate ioctl to do that would be needed.
>
> I don't see use case where that could be needed. It is only
> To avoid a nonkillable task in the case the user pass an infinite
> Timeout.
>
> If you have some test case where that ioctl would be needed
> Please share it in order to find the best solution.
Well, imagine the application is using a library to access the DSP, and
the library has a dedicated thread listening for DSP events in a loop.
This happens to be how libomxil-ti and gst-dsp work.
Now, the thread received the last message, but has set a timeout of 10s,
or even worst, no timeout at all.
After realizing that was the last message, the main thread decides to
shut down, but it has to wait for the DSP thread to join. Unfortunately
the DSP thread is stuck waiting for events, and there's nothing that can
be done.
However, if we have a separate ioctl to interrupt that task, then the
main thread can issue that ioctl, and unlock the DSP thread without
having to wait 10s, or forever.
Does that make sense?
--
Felipe Contreras
next prev parent reply other threads:[~2010-10-26 17:03 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-26 0:51 [PATCH 0/8] staging: tidspbridge - misc fixes Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 2/8] staging: tidspbridge - add kconfig parameter for DMM size Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 3/8] staging: tidspbridge - change mmufault tasklet to a workqueue Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 4/8] staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 5/8] staging: tidspbridge - use GTP7 for DSP stack dump Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 6/8] staging: tidspbridge - remove disabling twl when printing DSP stack Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 7/8] staging: tidspbridge - fix some issues after iommu patches Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:51 ` Fernando Guzman Lugo
2010-10-26 0:58 ` Felipe Contreras
2010-10-26 0:58 ` Felipe Contreras
2010-10-26 15:50 ` Guzman Lugo, Fernando
2010-10-26 15:50 ` Guzman Lugo, Fernando
2010-10-26 15:50 ` Guzman Lugo, Fernando
2010-10-26 17:03 ` Felipe Contreras [this message]
2010-10-26 17:03 ` Felipe Contreras
2010-10-26 17:58 ` Guzman Lugo, Fernando
2010-10-26 17:58 ` Guzman Lugo, Fernando
2010-10-26 17:58 ` Guzman Lugo, Fernando
2010-10-26 19:27 ` Felipe Contreras
2010-10-26 19:27 ` Felipe Contreras
2010-10-26 20:01 ` Guzman Lugo, Fernando
2010-10-26 20:01 ` Guzman Lugo, Fernando
2010-10-26 20:01 ` Guzman Lugo, Fernando
2010-12-06 8:51 ` Ramirez Luna, Omar
2010-12-06 8:51 ` Ramirez Luna, Omar
2010-10-26 11:46 ` [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Felipe Contreras
2010-10-26 11:46 ` Felipe Contreras
2010-10-26 15:52 ` Guzman Lugo, Fernando
2010-10-26 15:52 ` Guzman Lugo, Fernando
2010-10-26 15:52 ` Guzman Lugo, Fernando
2010-10-26 17:07 ` Felipe Contreras
2010-10-26 17:07 ` Felipe Contreras
2010-10-26 18:08 ` Guzman Lugo, Fernando
2010-10-26 18:08 ` Guzman Lugo, Fernando
2010-10-26 18:08 ` Guzman Lugo, Fernando
2010-10-26 19:37 ` Felipe Contreras
2010-10-26 19:37 ` Felipe Contreras
2010-10-26 20:39 ` Guzman Lugo, Fernando
2010-10-26 20:39 ` Guzman Lugo, Fernando
2010-10-26 20:39 ` Guzman Lugo, Fernando
2010-10-27 8:19 ` Felipe Contreras
2010-10-27 8:19 ` Felipe Contreras
2010-10-27 8:19 ` Felipe Contreras
2010-10-28 15:38 ` Guzman Lugo, Fernando
2010-10-28 15:38 ` Guzman Lugo, Fernando
2010-10-28 15:38 ` Guzman Lugo, Fernando
2010-10-28 15:56 ` Russell King - ARM Linux
2010-10-28 15:56 ` Russell King - ARM Linux
2010-10-28 15:56 ` Russell King - ARM Linux
2010-10-26 4:06 ` [PATCH 0/8] staging: tidspbridge - misc fixes Greg KH
2010-10-26 4:06 ` Greg KH
2010-10-26 14:43 ` Felipe Contreras
2010-10-26 14:43 ` Felipe Contreras
2010-10-26 14:55 ` Omar Ramirez Luna
2010-10-26 14:55 ` Omar Ramirez Luna
2010-10-26 14:55 ` Omar Ramirez Luna
2010-10-26 15:46 ` Guzman Lugo, Fernando
2010-10-26 15:46 ` Guzman Lugo, Fernando
2010-10-26 15:46 ` Guzman Lugo, Fernando
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=1288112260-notmuch-felipe.contreras@nokia.com \
--to=felipe.contreras@nokia.com \
--cc=andy.shevchenko@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=fernando.lugo@ti.com \
--cc=gregkh@suse.de \
--cc=hiroshi.doyu@nokia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.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 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.