> Step one. Is there actually a use case for changing an individual > channels reference voltage all that often? A fair bit of kit can do > this, but to pull it off in software you'll need to effectively run > a triggered DAC alongside the adc and it'll get really fiddly. > Or having read more of your supply are you saying that we actually have > a mux and so only sample one channel at a time (and hence have to > change > the reference voltage etc)? In my ADC we can configure whether we want to go for one_shot mode or continuous mode with the preferred channel (index 0--7) .. One_shot mode will run for "set channels" , after that you will have reconfigure the ADC(channel_configure_registers) to use further-this configurations include ref Vol ,channels to scan ,Interrupts etc .. Instead Continous_Mode will run all the time for selected channels without need to reconfiguring everytime :best suitable if you have NOT VARYING REFVOLTAGE connected to its channels or devices which work on same REFVOLTAGEs. So Indeed , i am about to use ONE_SHOT mode with the selected channels which are going to work on Same REFVOLATGE.. >So you are really dead reckoning when the capture is done? That is fine. Look at how the sysfs-trigger works - that will show you how >to do a soft interrupt fire and cause capture to happen and you can >have whatever timing you like on the trigger. Also are we capturing >all channels on each of these cycles, or just one of them? Yes.. i will take it as reference.. As i told ,depends upon Mode and programmed channels ,i will have to capture them using trigger.. example: if i have programmed my adc registered for 1,3 channels, then after one Full Cycle( 2 Conversion_CYLEs(since only 2 channels are programmed) + buffer_time_ms) i have to capture them .. > If just one channel per 'trigger' you have three options > 1) register separate iio devices for each channel (thus letting you do any scheduling you like). > 2) Enforce some constraints such as all enabled channels wil be sampled > in a fixed order. E.g. 0123 - sleep - 0123 - sleep - 0123 > Then your trigger will be for the set (and the timing between > individual > samples will be entirely hidden inside your driver). > 3) If it's slow don't do a buffered interface at all - do it all > through > the sysfs interface and do stuff on demand. I will take care of all above points mentioned by you . > subirq handled by pollfunc. So conceptually a trigger is causing a > device to be polled for data. That's an statement!! In other words , if i am using iio_trigger_poll(trigger,0) it means my ring buffer's (top half+ bottom-half) are getting called . > They are wrapped up entirely so you shouldn't care about them. > Trigger fires all enabled subirqs. ONE of these triggers has the > pollfunc stuff registered to handle it. So the subirq handlers are > the pollfunc stuff. Had it been great if i would have know some hard_logic wiring subirqs to this capture_functions... Thanks Darshan Kumar > > So my choice > > to design this is to use IIO subsystem.. But until i know this > > subsystem i will not be able to start writing this...Meanwhile , i > > have copied maillist too ... > Sure. > > > > >> Note that a lot of triggers are from the devices themselves and > >> hence lie in the relevant drivers.. (data ready signals typically > >> on devices with their own clocking). > > > > Yes , May be in IIO terminology this is trigger , but from device > > point of view these can be called interrupts viz . EOC or analog > > watchdog interrupts. Right? > Indeed. Sometimes these are inttrupts, sometimes they are other things > entirely (e.g. input from userspace). The terminology comes from > oscilloscopes where a trigger is what causes data capture to occur. > > > > > >> the interrupt routine fires off sub interrupts for any devices that > >> have attached to it (attachment usually done by name from userspace > >> - poke the trigger name into iio:deviceX/trigger/current_trigger > >> iirc). > > True.. > > > >> These ADCs register interrupt handlers for the subirqs and it is > >> these that grab the data form the adc and push it into the buffers. > >> Current tree has pushing only to a single buffer, but there are > >> patches on the mailing list to do it to multiple buffers (handy for > >> bridging to other subsytems). > > > > ADCs are registering interrupt_handler for their Interrupt_lines > > right? > Yes if they are data ready type interrupts). These typically feed > triggers which in turn cause this adc (and sometime other devices) > to capture. > And during the iio_allocate_trigger call, which in turn being > > called from trigger_initialisation (referring at91_adc.c) we are > > doing following : irq_set_handler(trig->subirq_base + i, > > &handle_simple_irq); > > > > Its the generic handler for all sub_irqs.. Now during > > data_ready_signal or eoc , they are calling > > iio_trigger_poll(idev->trig, iio_get_time_ns(),if buffer is enabled); > > .. which is going to call nothing but handle_simple_irq ... But still > > when i go through this call , i see action->handler(irq, > > action->dev_id); is getting called.this must be someone which you are > > pointing out.. SO far no real handler is registered which is > > capturing the data from ADC and putting the content into buffer . > > But during ring_buffer setup , capture(bottom_half) and > > hard_handler(top half) is given which are going to form poll_function > > , which is going to be called when i do echo 1 > > > /sys/bus/iio/devices/iio\:device0/buffer/enable along with preenable > > , and postenable callbacks.. during the postenable this poll_func is > > getting called which is running in trigger's irq context ,right? > Not during post enable it isn't. That will just be setting it up as the > interrupt handler. > So > > where does the subirq specific handlers are coming into play? > They are wrapped up entirely so you shouldn't care about them. > Trigger fires all enabled subirqs. ONE of these triggers has the > pollfunc stuff registered to handle it. So the subirq handlers are > the pollfunc stuff. > And > > whats the usage? Please comment on my understanding too.. > subirq handled by pollfunc. So conceptually a trigger is causing a > device to be polled for data. > > > > For my ADC , i am prohibited to work on interrupts mechanism (EOC > > etc) , instead i will use polling for my device (if needed )... but i > > want to generate one soft_interrupt after > > (conversion_cycle+buffer_jiffies) to capture the data from device and > > sleep for next cycle... > So you are really dead reckoning when the capture is done? That is > fine. Look at how the sysfs-trigger works - that will show you how > to do a soft interrupt fire and cause capture to happen and you can > have whatever timing you like on the trigger. Also are we capturing > all channels on each of these cycles, or just one of them? > > If just one channel per 'trigger' you have three options > 1) register separate iio devices for each channel (thus letting you don > any scheduling you like). > 2) Enforce some constraints such as all enabled channels wil be sampled > in a fixed order. E.g. 0123 - sleep - 0123 - sleep - 0123 > Then your trigger will be for the set (and the timing between > individual > samples will be entirely hidden inside your driver). > 3) If it's slow don't do a buffered interface at all - do it all > through > the sysfs interface and do stuff on demand. > > > > > > > > I hope , i sound legitimate.. Please make me come out of above > > doubts.. > > > > Thanks Darshan > > > > > > > > > > > > > > -----Original Message----- From: Jonathan Cameron > > [mailto:jic23@xxxxxxxxx] Sent: 18 July 2012 12:54 To: Darshan Kumar > > NANDANWAR > > Cc: hennerich@xxxxxxxxxxxxxxxxxxxx > > Subject: Re: Regarding iio-trigger functioning > > > > On 7/18/2012 5:56 AM, Darshan Kumar NANDANWAR wrote: > >> Jonathan/Hennerich , > >> > >> I am trying to use IIO subsystem for one of my ADC with quite > >> different functions. So traversing the code . There are few > doubts > >> regarding triggers which are placed in *drivers/staging/iio/trigger/ > >> directory..* > > Note that a lot of triggers are from the devices themselves and hence > > lie in the relevant drivers.. (data ready signals typically on > devices > > with their own clocking). > >> > >> *Lets say example of iio-trig-bfin-timer.c:* > >> > >> ** > >> > >> Ø*How this trigger is going to communicate with actual device (say > ADC)?* > > the interrupt routine fires off sub interrupts for any devices that > have > > attached to it (attachment usually done by name from userspace - poke > > the trigger name into iio:deviceX/trigger/current_trigger iirc). > > Thus multiple ADCs or similar can run off a single trigger. > > These ADCs register interrupt handlers for the subirqs and it is > these > > that grab the data form the adc and push it into the buffers. > Current > > tree has pushing only to a single buffer, but there are patches on > the > > mailing list to do it to multiple buffers (handy for bridging to > other > > subsytems). > >> > >> Ø*What i see: this timer will have IRQ handler for its IRQ and > IRQ > >> handler implementation is like following in this driver:* > >> > >> ** > >> > >> ** > >> > >> *static irqreturn_t iio_bfin_tmr_trigger_isr(int irq, void *devid)* > >> > >> *{* > >> > >> * struct bfin_tmr_state *st = devid;* > >> > >> ** > >> > >> * clear_gptimer_intr(st->t->id);* > >> > >> * iio_trigger_poll(st->trig, 0);* > >> > >> ** > >> > >> * return IRQ_HANDLED;* > >> > >> *}* > >> > >> ** > >> > >> ** > >> > >> ** > >> > >> *Where iio_trigger_poll will be working on subirqs assigned to > >> consumers.. Unfortunately i am not able to establish the link > between > >> how does this trigger yields me to capture the data from ring > >> buffer , as i don't see any such implementation in this trigger's > ISR > >> routine?* > > The subirqs are not for 'consumers' but rather drive either > retrieving > > the data from the adc or initiate the capture. Then the data is > pushed > > into buffers and on to consumers. > > > > The adc capture logic lies in the adc driver not the trigger driver > > (often they are the same driver, but as you've gone with blackfin > timer > > they aren't here). > >> > >> ** > >> > >> *Please provide me insight into this , so that i can use this > subsystem > >> to wrire a driver for my ADC...* > > Just out of curiousity, which ADC are you working with? Also please > > note that questions such as this are best posted to the mailing list. > > Everyone started from scratch once, hence there are lots of people > who > > might help on there! linux-iio@xxxxxxxxxxxxxxx. Basically if there > is > > no particularly strong reason to keep things confidential they should > be > > on the list. > >> > >> ** > >> > >> ** > >> > >> *Thanks* > >> > >> *Darshan Kumar* > >> > >> ** > >> > >> ** > >> > > > > > -- 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
