Linux IIO development
 help / color / mirror / Atom feed
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
> 

  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