From: Jonathan Cameron <jic23@cam.ac.uk>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: michael.hennerich@analog.com,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 05/12] staging:iio:adis16400 replace unnecessary event line registration.
Date: Sun, 17 Apr 2011 19:41:36 +0100 [thread overview]
Message-ID: <4DAB3460.4080006@cam.ac.uk> (raw)
In-Reply-To: <4DA5B708.5090404@cam.ac.uk>
Hi Michael,
Did my reply answer your question such that you don't mind me sending
these (well rebased version anyway) on to Greg?
I'm really not liking my 100 patch queue :(
> ...
>>> 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);
>>> }
>>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-04-17 18:41 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
2011-04-17 18:41 ` Jonathan Cameron [this message]
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=4DAB3460.4080006@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