From: Jonathan Cameron <jic23@cam.ac.uk>
To: michael.hennerich@analog.com
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 05/12] staging:iio:adis16400 replace unnecessary event line registration.
Date: Wed, 13 Apr 2011 15:45:28 +0100 [thread overview]
Message-ID: <4DA5B708.5090404@cam.ac.uk> (raw)
In-Reply-To: <4DA5AB5F.2060000@analog.com>
...
>> iio_device_unregister(indio_dev);
>> diff --git a/drivers/staging/iio/imu/adis16400_trigger.c b/drivers/staging/iio/imu/adis16400_trigger.c
>> index 36b5ff5..afa5e74 100644
>> --- a/drivers/staging/iio/imu/adis16400_trigger.c
>> +++ b/drivers/staging/iio/imu/adis16400_trigger.c
>> @@ -15,21 +15,13 @@
>> /**
>> * adis16400_data_rdy_trig_poll() the event handler for the data rdy trig
>> **/
>> -static int adis16400_data_rdy_trig_poll(struct iio_dev *dev_info,
>> - int index,
>> - s64 timestamp,
>> - int no_test)
>> +static irqreturn_t adis16400_data_rdy_trig_poll(int irq, void *private)
>> {
>> - struct adis16400_state *st = iio_dev_get_devdata(dev_info);
>> - struct iio_trigger *trig = st->trig;
>> -
>> - iio_trigger_poll(trig, timestamp);
>> -
>> + disable_irq_nosync(irq);
>> + iio_trigger_poll(private, iio_get_time_ns());
>>
> Is it save to call iio_trigger_poll() from the Top Half Hard-IRQ?
> Instead of disable/enable irq shouldn't this be better a threaded_irq
> with IRQF_ONESHOT?
Yes. Actually after conversion to irq chips this is precisely what you
want to do. If you call it as threaded_irq with oneshot enabled,
then the triggered devices can't have top halves. That only really
matters if you either want a timestamp or you want to flip a gpio
to trigger the actual sampling. Note we can't do top halves at all
for software triggers. How to handle this is a corner I haven't cleaned
up yet.
When we switch over to that approach you don't disable this irq at all.
Rather you have the trigger_consumer as a threaded_irq with
IRQF_ONESHOT set. That serializes reads from the device and writing
to the buffer implementation. It's this serialization that motivates
the disabling of irq's here.
Having said that, the reason it is like this here, is that it
replicates what was previously happening. Without the hardware
I don't want to mess with it too much + most of this code is
going to go away shortly anyway!
To illustrate, take a look at accel/lis3l02dq (bit of a weird case)
or imu/adis16400 (untested right now) in
http://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git
in a few mins (just pushed).
Ripping out the relevant bits...
from adis16400_trigger.c
static irqreturn_t adis16400_data_rdy_trig_poll(int irq, void *private)
{
iio_trigger_poll(private, iio_get_time_ns());
return IRQ_HANDLED;
}
int adis16400_probe_trigger(struct iio_dev *indio_dev)
{
...
ret = request_irq(st->us->irq,
adis16400_data_rdy_trig_poll,
IRQF_TRIGGER_RISING,
"adis16400",
st->trig);
...
}
from adis16400_ring.c
static irqreturn_t adis16400_trigger_handler(int irq, void *p)
{
struct iio_poll_func *pf = p;
struct iio_dev *indio_dev = pf->private_data;
struct adis16400_state *st = iio_dev_get_devdata(indio_dev);
... do stuff...
iio_trigger_notify_done(st->indio_dev->trig);
... clean up ...
return IRQ_HANDLED;
}
int adis16400_configure_ring(struct iio_dev *indio_dev)
{
...
indio_dev->pollfunc->private_data = indio_dev;
indio_dev->pollfunc->h = &iio_pollfunc_store_time;
indio_dev->pollfunc->thread = &adis16400_trigger_handler;
indio_dev->pollfunc->type = IRQF_ONESHOT;
indio_dev->pollfunc->name =
kasprintf(GFP_KERNEL, "adis16400_consumer%d", indio_dev->id);
...
}
Sometimes some fiddling is needed in the reenable for the interrupt to make sure
we don't get stuck with it high (for interrupts that don't clear unless a read
occurs - see lis3l02dq).
>
>> return IRQ_HANDLED;
>> }
>>
>> -IIO_EVENT_SH(data_rdy_trig, &adis16400_data_rdy_trig_poll);
>> -
>> static IIO_TRIGGER_NAME_ATTR;
>>
>> static struct attribute *adis16400_trigger_attrs[] = {
>> @@ -49,22 +41,9 @@ static int adis16400_data_rdy_trigger_set_state(struct iio_trigger *trig,
>> {
>> struct adis16400_state *st = trig->private_data;
>> struct iio_dev *indio_dev = st->indio_dev;
>> - int ret = 0;
>>
>> dev_dbg(&indio_dev->dev, "%s (%d)\n", __func__, state);
>> - ret = adis16400_set_irq(&st->indio_dev->dev, state);
>> - if (state == false) {
>> - iio_remove_event_from_list(&iio_event_data_rdy_trig,
>> - &indio_dev->interrupts[0]
>> - ->ev_list);
>> - /* possible quirk with handler currently worked around
>> - by ensuring the work queue is empty */
>> - flush_scheduled_work();
>> - } else {
>> - iio_add_event_to_list(&iio_event_data_rdy_trig,
>> - &indio_dev->interrupts[0]->ev_list);
>> - }
>> - return ret;
>> + return adis16400_set_irq(&st->indio_dev->dev, state);
>> }
>>
>> /**
>> @@ -85,12 +64,23 @@ int adis16400_probe_trigger(struct iio_dev *indio_dev)
>> struct adis16400_state *st = indio_dev->dev_data;
>>
>> st->trig = iio_allocate_trigger();
>> + if (st->trig == NULL) {
>> + ret = -ENOMEM;
>> + goto error_ret;
>> + }
>> + ret = request_irq(st->us->irq,
>> + adis16400_data_rdy_trig_poll,
>> + IRQF_TRIGGER_RISING,
>> + "adis16400",
>> + st->trig);
>>
>
> threaded_irq with IRQF_ONESHOT?
>
>> + if (ret)
>> + goto error_free_trig;
>> st->trig->name = kasprintf(GFP_KERNEL,
>> "adis16400-dev%d",
>> indio_dev->id);
>> if (!st->trig->name) {
>> ret = -ENOMEM;
>> - goto error_free_trig;
>> + goto error_free_irq;
>> }
>> st->trig->dev.parent = &st->us->dev;
>> st->trig->owner = THIS_MODULE;
>> @@ -109,9 +99,11 @@ int adis16400_probe_trigger(struct iio_dev *indio_dev)
>>
>> error_free_trig_name:
>> kfree(st->trig->name);
>> +error_free_irq:
>> + free_irq(st->us->irq, st->trig);
>> error_free_trig:
>> iio_free_trigger(st->trig);
>> -
>> +error_ret:
>> return ret;
>> }
>>
>> @@ -121,5 +113,6 @@ void adis16400_remove_trigger(struct iio_dev *indio_dev)
>>
>> iio_trigger_unregister(state->trig);
>> kfree(state->trig->name);
>> + free_irq(state->us->irq, state->trig);
>> iio_free_trigger(state->trig);
>> }
>>
>
>
next prev parent reply other threads:[~2011-04-13 14:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-13 13:42 [PATCH 00/12] IIO: precursor cleanups to even system rewrite Jonathan Cameron
2011-04-13 13:42 ` [PATCH 01/12] staging:iio:tsl2563 take advantage of new iio_device_allocate private data Jonathan Cameron
2011-04-13 13:42 ` [PATCH 02/12] staging:iio:light:tsl2563 constify gain level table Jonathan Cameron
2011-04-13 13:42 ` [PATCH 03/12] staging:iio:adis16300 replace unnecessary event line registration Jonathan Cameron
2011-04-13 13:42 ` [PATCH 04/12] staging:iio:adis16350 " Jonathan Cameron
2011-04-13 13:43 ` [PATCH 05/12] staging:iio:adis16400 " Jonathan Cameron
2011-04-13 13:55 ` Michael Hennerich
2011-04-13 14:45 ` Jonathan Cameron [this message]
2011-04-17 18:41 ` Jonathan Cameron
2011-04-18 7:16 ` Hennerich, Michael
2011-04-13 13:43 ` [PATCH 06/12] staging:iio:adis16260 " Jonathan Cameron
2011-04-13 13:43 ` [PATCH 07/12] staging:iio:adis16203 " Jonathan Cameron
2011-04-13 13:43 ` [PATCH 08/12] staging:iio:adis16204 " Jonathan Cameron
2011-04-13 13:43 ` [PATCH 09/12] staging:iio:adis16201 " Jonathan Cameron
2011-04-13 13:43 ` [PATCH 10/12] staging:iio:adis16240 " Jonathan Cameron
2011-04-13 13:43 ` [PATCH 11/12] staging:iio:adis16209 " Jonathan Cameron
2011-04-13 13:43 ` [PATCH 12/12] staging:iio:ade7758 " Jonathan Cameron
2011-04-18 11:59 ` [PATCH 00/12] IIO: precursor cleanups to even system rewrite Jonathan Cameron
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=4DA5B708.5090404@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=linux-iio@vger.kernel.org \
--cc=michael.hennerich@analog.com \
/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