iio_trigger_poll from IRQ thread

iio_trigger_poll from IRQ thread

[Hegbeli, Ciprian]

Hi, 

I'm currently trying to call iio_trigger_poll from the bottom-half of an interrupt handler and get the following waring;

[  101.814234] WARNING: CPU: 0 PID: 1204 at kernel/irq/handle.c:152 __handle_irq_event_percpu+0x234/0x238
[  101.814255] irq 60 handler irq_default_primary_handler+0x0/0x1c enabled interrupts
[  101.814268] Modules linked in: ade9078 cmac rfcomm bnep hci_uart btbcm bluetooth ecdh_generic ecc fuse 8021q garp brcmfmac brcmutil cfg80211 v3d rfkill spi_bcm2835 gpu_sched raspberrypi_hwmon bcm2835_codec(C) snd_bcm2835(C) bcm2835_v4l2(C) bcm2835_isp(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) vc_sm_cma(C) rpivid_mem vc4 uio_pdrv_genirq uio i2c_dev ip_tables x_tables
[  101.814452] CPU: 0 PID: 1204 Comm: irq/58-ade9078 Tainted: G         C        5.4.83-v7l+ #7

This warning occurs only once, the first time it goes through this scenario, on a second passing through it I get no warning.
After reading online about it, the problem is related to disabling the interrupts prior to entering the IIO Handler. 
By doing this manually I don't get any Warnings, but it has been pointed out to me that this might not be a good solution.

I'm using the bottom-half of the handler because the interrupt requires reading the status register of the IC, which can be slow.
Unfortunately there is no way to insert the iio_trigger_poll in the top-half because all the checks are done in the bottom-half.

The trigger_handler reads the samples from an internal FIFO in the IC, I'm not sure if this detail is relevant or not. 

Regards,
Ciprian

Re: iio_trigger_poll from IRQ thread

[Jonathan Cameron]

On Wed, 26 Jan 2022 14:43:45 +0000
"Hegbeli, Ciprian" <Ciprian.Hegbeli@analog.com> wrote:

> Hi, 
> 
> I'm currently trying to call iio_trigger_poll from the bottom-half of an interrupt handler and get the following waring;
> 
> [  101.814234] WARNING: CPU: 0 PID: 1204 at kernel/irq/handle.c:152 __handle_irq_event_percpu+0x234/0x238
> [  101.814255] irq 60 handler irq_default_primary_handler+0x0/0x1c enabled interrupts
> [  101.814268] Modules linked in: ade9078 cmac rfcomm bnep hci_uart btbcm bluetooth ecdh_generic ecc fuse 8021q garp brcmfmac brcmutil cfg80211 v3d rfkill spi_bcm2835 gpu_sched raspberrypi_hwmon bcm2835_codec(C) snd_bcm2835(C) bcm2835_v4l2(C) bcm2835_isp(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) vc_sm_cma(C) rpivid_mem vc4 uio_pdrv_genirq uio i2c_dev ip_tables x_tables
> [  101.814452] CPU: 0 PID: 1204 Comm: irq/58-ade9078 Tainted: G         C        5.4.83-v7l+ #7
> 
> This warning occurs only once, the first time it goes through this scenario, on a second passing through it I get no warning.
> After reading online about it, the problem is related to disabling the interrupts prior to entering the IIO Handler. 
> By doing this manually I don't get any Warnings, but it has been pointed out to me that this might not be a good solution.
> 
> I'm using the bottom-half of the handler because the interrupt requires reading the status register of the IC, which can be slow.
> Unfortunately there is no way to insert the iio_trigger_poll in the top-half because all the checks are done in the bottom-half.
> 
> The trigger_handler reads the samples from an internal FIFO in the IC, I'm not sure if this detail is relevant or not. 

If in bottom half, call iio_trigger_poll_chained().

It's a bit of a hack in the sense that it will only run the bottom half
of the pollfuncs which isn't always what is wanted (can miss timestamps
being stored for example) but mostly works.

Not well named either which I've been meaning to fix for a very
long time :(

However, if there is a fifo involved, is it useful to use the trigger
framework at all?  That only normally makes sense if there is one
'trigger' per 'scan'.  If your fifo is working on the basis of
a watermark interrupt for when the buffer has N scans of data in it
then it's normally better to just not use a trigger at all and fill
the buffer directly from the interrupt bottom half.
Things can get a bit fiddly if you also want to support other triggers
but there are drivers that do that.  No trigger means fill directly,
trigger means grabbing data via a path not using the fifo (or with
fifo depth set to 1 scan)

Jonathan

> 
> Regards,
> Ciprian

RE: iio_trigger_poll from IRQ thread

[Hegbeli, Ciprian]

Thank you for the input. 

Interesting point you bring up with the no trigger setup in this case. I will be both easier and more convenient if I can give up on the trigger functionality altogether for my driver. I will ask around and see if that is acceptable. 

-Ciprian 

-----Original Message-----
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com> 
Sent: Wednesday, January 26, 2022 9:16 PM
To: Hegbeli, Ciprian <Ciprian.Hegbeli@analog.com>
Cc: linux-iio@vger.kernel.org
Subject: Re: iio_trigger_poll from IRQ thread

[External]

On Wed, 26 Jan 2022 14:43:45 +0000
"Hegbeli, Ciprian" <Ciprian.Hegbeli@analog.com> wrote:

> Hi,
> 
> I'm currently trying to call iio_trigger_poll from the bottom-half of 
> an interrupt handler and get the following waring;
> 
> [  101.814234] WARNING: CPU: 0 PID: 1204 at kernel/irq/handle.c:152 
> __handle_irq_event_percpu+0x234/0x238
> [  101.814255] irq 60 handler irq_default_primary_handler+0x0/0x1c 
> enabled interrupts [  101.814268] Modules linked in: ade9078 cmac rfcomm bnep hci_uart btbcm bluetooth ecdh_generic ecc fuse 8021q garp brcmfmac brcmutil cfg80211 v3d rfkill spi_bcm2835 gpu_sched raspberrypi_hwmon bcm2835_codec(C) snd_bcm2835(C) bcm2835_v4l2(C) bcm2835_isp(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) vc_sm_cma(C) rpivid_mem vc4 uio_pdrv_genirq uio i2c_dev ip_tables x_tables
> [  101.814452] CPU: 0 PID: 1204 Comm: irq/58-ade9078 Tainted: G         C        5.4.83-v7l+ #7
> 
> This warning occurs only once, the first time it goes through this scenario, on a second passing through it I get no warning.
> After reading online about it, the problem is related to disabling the interrupts prior to entering the IIO Handler. 
> By doing this manually I don't get any Warnings, but it has been pointed out to me that this might not be a good solution.
> 
> I'm using the bottom-half of the handler because the interrupt requires reading the status register of the IC, which can be slow.
> Unfortunately there is no way to insert the iio_trigger_poll in the top-half because all the checks are done in the bottom-half.
> 
> The trigger_handler reads the samples from an internal FIFO in the IC, I'm not sure if this detail is relevant or not. 

If in bottom half, call iio_trigger_poll_chained().

It's a bit of a hack in the sense that it will only run the bottom half of the pollfuncs which isn't always what is wanted (can miss timestamps being stored for example) but mostly works.

Not well named either which I've been meaning to fix for a very long time :(

However, if there is a fifo involved, is it useful to use the trigger framework at all?  That only normally makes sense if there is one 'trigger' per 'scan'.  If your fifo is working on the basis of a watermark interrupt for when the buffer has N scans of data in it then it's normally better to just not use a trigger at all and fill the buffer directly from the interrupt bottom half.
Things can get a bit fiddly if you also want to support other triggers but there are drivers that do that.  No trigger means fill directly, trigger means grabbing data via a path not using the fifo (or with fifo depth set to 1 scan)

Jonathan

> 
> Regards,
> Ciprian