Re: help regarding Hardware Triggers in IIO ADC Driver

[Jonathan Cameron <jic23@kernel.org>]

On 25/08/14 09:08, Sricharan Chalasani wrote:
> Hi Jonathan and all,
> 
> I am really thankful to you for your quick responses. It really helps
> me a lot to quckly understand how IIO works. Many thanks in advance
> again.
> 
> This is in continuation to my previous email and your valuable
> response, I have decided to use IIO RTC Trigger as a trigger provider
> and write my own Generic ADC driver. Before start writing my own
> Generic Driver, may I request your help to better understand how a
> Trigger really works.
> 
> As an experiment, I will make use of IIO RTC Trigger
> (staging/iio/trigger) as Trigger provider to Trigger Simple Dummy IIO
> Driver (staging/iio).
> 
> Assuming that I have 2 channels on my ADC. Following is my basic
> understanding of how an RTC Trigger works.
> 
> (After loading both IIO RTC Trigger driver and Simple Dummy IIO Driver)
> 
> Set up periodic RTC trigger frequency
> 
> #echo 1000 > /sys/devices/trigger0/frequency
> 
> Set up the channels in use
> 
> # echo 1 > /sys/bus/iio/devices/iio:device0/scan_elements/in_voltage0_en
> # echo 1 > /sys/bus/iio/devices/iio:device0/scan_elements/in_voltage1_en
> 
> Set up the trigger we want to use (it must be the name of one of the
> triggers present in iio/devices) (assuming that the rtc trigger name -
> my_rtc_trig0)
> 
> # echo "my_rtc_trig0" > /sys/bus/iio/devices/iio:device0/trigger/current_trigger
> 
> Set up the buffer length (Maximum number of data kept in the buffer,
> if we reach this number, the older data will be dropped)
> 
> # echo 100 > /sys/bus/iio/devices/iio:device0/buffer/length
> 
> Enable the capture
> 
> # echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
> 
> With the above configuration, I understand that whenever the RTC
> Periodic Interrupt is generated, the periodic RTC interrupt handler
> (ISR) in-turn invokes my Simple Dummy Trigger Handler
> (iio_simple_dummy_trigger_h). My Simple dummy trigger handler is
> invoked (iio_simple_dummy_trigger_h) periodically with the help of RTC
> periodic interrupt. I will copy data corresponding to all the enabled
> channels (fake data in this case) to ring buffer from the function
> iio_simple_dummy_trigger_h periodically.
A small point - it's a fifo not a ring buffer, but otherwise fine
(used to be a ring buffer, but no one really cared about that so
we switched over the a fifo using the kfifo infrastructure.)
> 
> Please correct me if my understanding of how a periodic RTC Trigger
> really Triggers an IIO device to copy data to ring buffer
> periodically, is wrong ......
All correct as far as I can see.

J
> 
> 
> Thanks in advance,
> 
> Sricharan.
> 
> 
> 
> 
> 
> 
> 
> On Fri, Aug 22, 2014 at 2:38 AM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 20/08/14 19:19, Sricharan Chalasani wrote:
>>> Hi Mr. Jonathan,
>> Hi Sricharan,
>>
>> It is almost always best to address questions like this to the relevant mailing list
>> (find that out from MAINTAINERS in the root of the kernel source tree).  In this
>> case linux-iio.  If nothing else, others on there tend to respond faster than I do
>> and it is useful to have discussions such as this available in the archives to
>> refer to later.
>>>
>>> My name is Sricharan. I am from Pune, South India. I know it is not correct to directly write to you. But I request you
>>> to please help me in this regard.
>>>
>>> I tried a lot to undersatand whether my following approach really satisfy the principles of IIO Subsystem, but feel like
>>> I am missing something in properly understanding my Subsystem properly.
>>>
>>> In the existing IIO drivers (linux-3.16), my understanding is that Hardware Triggers are just used to copy sampled data
>>> from the ADC to the Kernel buffer. I think none of the hardware triggers are really configuring ADC to Start the analog
>>> to digital conversion.
>> Actually quite a few hardware triggers can be used in this fashion, though often in the case
>> of Data Ready type interrupts they can be used to trigger 'other' devices.
>> Also we have a number of standalone triggers. The most relevant are still to be
>> found in drivers/staging/iio/triggers (rtc and blackfin timers triggers).  They
>> are there because we actually intend to drop them once we have a better means of
>> configuring the high resolution timer based trigger that has been posted to the
>> lists a few times.  The jitter on that trigger is actually very low reducing the
>> point of using hardware counters and now high resolution timers are nearly always
>> available.
>>>
>>> I have a Hardware Counter on my Board. I am planning to configure my Counter overflow interrupt as an IIO Hardware
>>> Trigger.
>> This is pretty much a periodic rtc interrupt (note these are now all emulated via high
>> res timers in the rtc system but they used to do it exactly the way you describe!)
>>
>>> In my IIO ADC driver probe function I am planning to start my Counter for the first time. Once the counter
>>> overflow interrupted is generated, inside the counter ISR, I am planning to configure ADC to start analog to digital
>>> conversion on all the channels (4 of them), one sample on each channel and once the Conversion is completed, I am
>>> planning to copy the Sampled data to Kernel buffer associated with the Trigger.
>> This is fine and is how pretty much all the buffer supporting drivers that don't
>> supply a trigger (no fixed internal sampling rate typically) do it.
>> A simple example would be something like drivers/iio/max1363 though in that conversions
>> are clocked directly from the i2c bus so 'appear' instantaneous.
>>
>> If you have an interrupt to indicate the end of the conversion, then the normal trick is
>> to use a completion to basically sleep the trigger handler (which is in a thread) until
>> the data is ready.  Lots of drivers do this as well.
>>
>>>
>>> I will program the Counter again and wait for interrupt and repeat the steps above. I am planning to continue this
>>> approach indefinitely.
>> Hmm.  If you actually have to reprogram the counter rather than it being periodic you 'might'
>> have a small amount of drift if you are not careful...
>>>
>>> Does this approach satisfy the principles of IIO Subsystem ? Am I missing anything here in understanding the IIO
>>> Subsystem properly ?
>> This is fine.  Note however that what you describe is best implemented as two drivers.
>> One is a generic adc driver which uses the trigger and the second is a trigger provider.
>>
>> J
>>>
>>> Thanks in advance,
>>>
>>> Sricharan,
>>> Pune (India).
>>>
>>>
> --
> 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
>