From: Nish Aravamudan <nish.aravamudan@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: rpurdie@rpsys.net, lenz@cs.wisc.edu,
kernel list <linux-kernel@vger.kernel.org>,
rmk@arm.linux.org.uk, vojtech@suse.cz
Subject: Re: [patch,rfc] Support for touchscreen on sharp zaurus sl-5500
Date: Thu, 21 Jul 2005 17:24:34 -0700 [thread overview]
Message-ID: <29495f1d05072117247817c5d1@mail.gmail.com> (raw)
In-Reply-To: <20050721052455.GB7849@elf.ucw.cz>
On 7/20/05, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> This adds support for touchscreen of sharp zaurus sl-5500. I got the
> patches from John Lenz <lenz@cs.wisc.edu>, but lots of copyrights are
> Russell King. To do so, it needs to add quite a bit of
> infrastructure. If there's better place for some code, please let me
> know (I already moved touchscreen parts to drivers/input).
<snip>
> diff --git a/drivers/input/touchscreen/collie_ts.c
> b/drivers/input/touchscreen/collie_ts.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/input/touchscreen/collie_ts.c
<snip>
> +static int ucb1x00_thread(void *_ts)
> +{
> + struct ucb1x00_ts *ts = _ts;
> + struct task_struct *tsk = current;
> + int valid;
> +
> + ts->rtask = tsk;
> +
> + daemonize("ktsd");
> + /* only want to receive SIGKILL */
> + allow_signal(SIGKILL);
> +
> + /*
> + * We run as a real-time thread. However, thus far
> + * this doesn't seem to be necessary.
> + */
> + tsk->policy = SCHED_FIFO;
> + tsk->rt_priority = 1;
> +
> + complete(&ts->init_exit);
> +
> + valid = 0;
> +
> + for (;;) {
> + unsigned int x, y, p, val;
> +
> + ts->restart = 0;
> +
> + ucb1x00_adc_enable(ts->ucb);
> +
> + x = ucb1x00_ts_read_xpos(ts);
> + y = ucb1x00_ts_read_ypos(ts);
> + p = ucb1x00_ts_read_pressure(ts);
> +
> + /*
> + * Switch back to interrupt mode.
> + */
> + ucb1x00_ts_mode_int(ts);
> + ucb1x00_adc_disable(ts->ucb);
> +
> + set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> + schedule_timeout(HZ / 100);
> + if (signal_pending(tsk))
> + break;
You specifically allow SIGKILL, but then sleep uninterruptibly? And
then you check if signal_pending() :) I think you may want
TASK_INTERRUPTIBLE? Or, go one better and use msleep_interruptible(),
as I don't see any wait-queues in the immediate area of this code...
<snip>
> + set_task_state(tsk, TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ / 100);
> + }
> +
> + if (signal_pending(tsk))
> + break;
Then you use INTERRUPTIBLE and check signal_pending() again, so I'm
pretty sure you wanted INTERRUPTIBLE above...But this sleep can be
msleep_interruptible(), as well?
<snip>
> diff --git a/drivers/misc/ucb1x00-core.c b/drivers/misc/ucb1x00-core.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/misc/ucb1x00-core.c
<snip>
> +/**
> + * ucb1x00_adc_read - read the specified ADC channel
> + * @ucb: UCB1x00 structure describing chip
> + * @adc_channel: ADC channel mask
> + * @sync: wait for syncronisation pulse.
> + *
> + * Start an ADC conversion and wait for the result. Note that
> + * synchronised ADC conversions (via the ADCSYNC pin) must wait
> + * until the trigger is asserted and the conversion is finished.
> + *
> + * This function currently spins waiting for the conversion to
> + * complete (2 frames max without sync).
You technically sleep (schedule_timeout()), not spin...
> + *
> + * If called for a synchronised ADC conversion, it may sleep
> + * with the ADC semaphore held.
> + */
> +unsigned int ucb1x00_adc_read(struct ucb1x00 *ucb, int adc_channel, int sync)
> +{
> + unsigned int val;
> +
> + if (sync)
> + adc_channel |= UCB_ADC_SYNC_ENA;
> +
> + ucb1x00_reg_write(ucb, UCB_ADC_CR, ucb->adc_cr | adc_channel);
> + ucb1x00_reg_write(ucb, UCB_ADC_CR, ucb->adc_cr | adc_channel | UCB_ADC_START);
> +
> + for (;;) {
> + val = ucb1x00_reg_read(ucb, UCB_ADC_DATA);
> + if (val & UCB_ADC_DAT_VAL)
> + break;
> + /* yield to other processes */
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(1);
> + }
If I ever add a poll_event() interface to the kernel, this would be a
good user. You don't check if signal_pending(), though, even though
you are in INTERRUPTIBLE state... Maybe this case can use
UNINTERRUPTIBLE?
Thanks,
Nish
next prev parent reply other threads:[~2005-07-22 0:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-21 5:24 [patch,rfc] Support for touchscreen on sharp zaurus sl-5500 Pavel Machek
2005-07-21 5:50 ` Dmitry Torokhov
2005-07-21 15:40 ` Pavel Machek
2005-07-22 0:24 ` Nish Aravamudan [this message]
2005-07-22 1:28 ` Pavel Machek
2005-07-22 5:02 ` Nish Aravamudan
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=29495f1d05072117247817c5d1@mail.gmail.com \
--to=nish.aravamudan@gmail.com \
--cc=lenz@cs.wisc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rmk@arm.linux.org.uk \
--cc=rpurdie@rpsys.net \
--cc=vojtech@suse.cz \
/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.