On 07/16/2013 03:26 PM, Denis CIOCCA wrote: > Hi Lars, > > thank you very much, now it works fine! > > Only one thing: > - In your patch I think there is a mistake on iio_trigger_poll_chained > function: generic_handle_irq should be replaced by handle_nested_irq. > Yep, thanks. Will fix that in v2. Can you give v2 a try? - Lars > > > On Tuesday, July 16, 2013 12:28:06 PM Lars-Peter Clausen wrote: >> On 07/16/2013 11:26 AM, Denis CIOCCA wrote: >>> Hi all, >>> >>> I need your help to understanding my strange issue... >>> The scenario is that: >>> >>> - I have one I2C device (microcontroller) that expose some sensors. >>> - I wrote one driver that create one IIO device for each sensor. >>> - There is only one trigger associated to all IIO devices, and one buffer >>> for each device. >>> >>> When interrupt appear (DRDY of one or more sensors), the driver reads a >>> mask from micro to understand how many sensors have new data. After that, >>> the driver reads all new data from micro and save all data to one buffer. >>> This is done in a threaded irq function. >>> >>> When iio_trigger_poll_chained is called, all data are saved to one common >>> buffer, each iio_triggered_buffer_setup functions is called and can split >>> and push their data to iio_buffer. >>> >>> The issue is that: after some samples (about 50:100) the >>> iio_trigger_poll_chained doesn't call the iio_triggered_buffer_setup >>> functions and trig->use_count is always equals to 1. >> >> Yea, there is a race condition. Try this patch: >> http://www.spinics.net/lists/linux-iio/msg08710.html >> >> - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
