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@xxxxxxxxxx> Sent: Wednesday, January 26, 2022 9:16 PM To: Hegbeli, Ciprian <Ciprian.Hegbeli@xxxxxxxxxx> Cc: linux-iio@xxxxxxxxxxxxxxx Subject: Re: iio_trigger_poll from IRQ thread [External] On Wed, 26 Jan 2022 14:43:45 +0000 "Hegbeli, Ciprian" <Ciprian.Hegbeli@xxxxxxxxxx> 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
