linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: Bottom half trigger function never called when using the sysfs trigger
Date: Fri, 15 Jun 2012 15:59:05 +0100	[thread overview]
Message-ID: <4FDB4DB9.7080402@cam.ac.uk> (raw)
In-Reply-To: <4FDB4D3E.6050907@metafoo.de>

On 6/15/2012 3:57 PM, Lars-Peter Clausen wrote:
> On 06/15/2012 03:32 PM, Jonathan Cameron wrote:
>> On 6/15/2012 2:08 PM, Lars-Peter Clausen wrote:
>>> hi,
>>>
>>> The sysfs trigger uses iio_trigger_poll_chained which calls
>>> handle_nested_irq. The problem now is that for nested IRQs the primary
>>> handler is not called. Which obviously breaks drivers which have a bottom
>>> half trigger function.
>>>
>>> This behaviour was introduced in commit 1f785681 ("staging:iio:trigger sysfs
>>> userspace trigger rework."). The commit message says you are "awaiting
>>> comments on using the nested_irq_trick", but not why it is necessary to use
>>> nested IRQs. And honestly I don't get why it would be necessary either.
>>> handle_nested_irq is supposed to be used with chained IRQs if we are already
>>> running in a thread handler of parent. Neither seems to be true here.
>> It was a while ago so my memory is rather sketchy.
>> do you meant the bottom half?  Unless I'm very confused its the top half
>> that doesn't
>
> Uhm, yes the top half.
>
>> get called.. handle_nested_irq calls thread_fn which is the bottom half.
>>
>> It's the only way I've come up with for cleanly running through our trigger
>> distribution
>> given that is all irq based.  Top halves expect to be run in interrupt mode.
>> I don't know
>> of any way to ensure this is true if one is 'creating' the interrupt from
>> software.
>>
>> I did wonder at the time about putting an explicit call of the interrupt
>> handler in
>> to deal with the missing top halves. It's rather uggly though and suffers
>> from things
>> not being run in the state they expect to be run in....
>>
>> Other suggestions welcome.
>
> Hm, maybe not use interrupts for the trigger events... ;)
>
> On the other hand there is the new irq_work framework which lets you
> schedule events which should be run in hardirq context. The following patch
> seems to do the trick (Note the patch won't apply as my mail client will
> insert line breaks where it shouldn't. I'll sent a proper patch if you agree
> with the general idea).
Looks like someone else ran into the same problem and came up with
a much better solution than I did.

This certainly looks better than the current.
>
> diff --git a/drivers/staging/iio/trigger/Kconfig
> b/drivers/staging/iio/trigger/Kconfig
> index b8abf54..d44d3ad 100644
> --- a/drivers/staging/iio/trigger/Kconfig
> +++ b/drivers/staging/iio/trigger/Kconfig
> @@ -21,6 +21,7 @@ config IIO_GPIO_TRIGGER
>   config IIO_SYSFS_TRIGGER
>   	tristate "SYSFS trigger"
>   	depends on SYSFS
> +	select IRQ_WORK
>   	help
>   	  Provides support for using SYSFS entry as IIO triggers.
>   	  If unsure, say N (but it's safe to say "Y").
> diff --git a/drivers/staging/iio/trigger/iio-trig-sysfs.c
> index 552763b..fde93a8 100644
> --- a/drivers/staging/iio/trigger/iio-trig-sysfs.c
> +++ b/drivers/staging/iio/trigger/iio-trig-sysfs.c
> @@ -10,12 +10,14 @@
>   #include<linux/platform_device.h>
>   #include<linux/slab.h>
>   #include<linux/list.h>
> +#include<linux/irq_work.h>
>
>   #include<linux/iio/iio.h>
>   #include<linux/iio/trigger.h>
>
>   struct iio_sysfs_trig {
>   	struct iio_trigger *trig;
> +	struct irq_work work;
>   	int id;
>   	struct list_head l;
>   };
> @@ -89,11 +91,17 @@ static struct device iio_sysfs_trig_dev = {
>   	.release =&iio_trigger_sysfs_release,
>   };
>
> +static void iio_sysfs_trigger_work(struct irq_work *work)
> +{
> +	struct iio_sysfs_trig *trig = container_of(work, struct iio_sysfs_trig, work);
> +	iio_trigger_poll(trig->trig, 0);
> +}
> +
>   static ssize_t iio_sysfs_trigger_poll(struct device *dev,
>   		struct device_attribute *attr, const char *buf, size_t count)
>   {
> -	struct iio_trigger *trig = dev_get_drvdata(dev);
> -	iio_trigger_poll_chained(trig, 0);
> +	struct iio_sysfs_trig *trig = dev_get_drvdata(dev);
> +	irq_work_queue(&trig->work);
>
>   	return count;
>   }
> @@ -148,6 +156,9 @@ static int iio_sysfs_trigger_probe(int id)
>   	t->trig->dev.groups = iio_sysfs_trigger_attr_groups;
>   	t->trig->ops =&iio_sysfs_trigger_ops;
>   	t->trig->dev.parent =&iio_sysfs_trig_dev;
> +	dev_set_drvdata(&t->trig->dev, t);
> +
> +	init_irq_work(&t->work, iio_sysfs_trigger_work);
>
>   	ret = iio_trigger_register(t->trig);
>   	if (ret)
> --
> 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:[~2012-06-15 14:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15 13:08 Bottom half trigger function never called when using the sysfs trigger Lars-Peter Clausen
2012-06-15 13:32 ` Jonathan Cameron
2012-06-15 14:57   ` Lars-Peter Clausen
2012-06-15 14:59     ` Jonathan Cameron [this message]

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=4FDB4DB9.7080402@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).