On 7/18/2012 11:54 AM, Darshan Kumar NANDANWAR wrote:
When you say internal do you mean in a soc or internal as in you can't
point us to a datasheet? Obviously if you can, a datasheet would
save a lot of confusion rather than you having to repeat lots of
it in this thread!
Yes , Indeed Datasheet could have saved a lot of fuss. But due to
some
Company's policy , i can't put it here. But its just 10:8 ADC , nothing
else...
Which has two interrupts coming out of it.. One is EOC (end of
conversion) and another is AWDT(analog watch dog timer) ..
EOC: will be generated for each conversion , whether voltage is
reference voltage on any of the channel or fluctuated one...
AWDT: will be generated once voltage fluctuates between min and max
.
EOC will not be of use for me as It will generate thousands of time
depending upon clock frequency.(that's what i am going for polling ) .
and AWDT doesn't come to my CPU , instead its fed to other cpu which is
not of use to me..
I guess it gives the clearer picture now.. Nevertheless , if you
want
more stuffs which can help in designing , i will surely tell you...
Sometimes one wonders if hardware designers go out fo their way
to make software fiddly. One of the favourite phrases round
here is, 'It's just software'... Admittedly it's usually followed
by me laughing manically at the next lot of electronics that catches
fire ;)
-----Original Message-----
From: Jonathan Cameron [mailto:jic23@xxxxxxxxx]
Sent: 18 July 2012 15:50
To: Darshan Kumar NANDANWAR
Cc: hennerich@xxxxxxxxxxxxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx;
dk.manit@xxxxxxxxx; Srikrishna Pramoda ATIKUKKE
Subject: Re: Regarding iio-trigger functioning
On 7/18/2012 11:15 AM, Jonathan Cameron wrote:
On 7/18/2012 10:28 AM, Darshan Kumar NANDANWAR wrote:
Jonathan,
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 for your precious explanations.. I am working on ST's
Internal
Low Bandwidth ADC having 10bit resolution with 8 Input Analog
channels ..
When you say internal do you mean in a soc or internal as in you can't
point us to a datasheet? Obviously if you can, a datasheet would
save a lot of confusion rather than you having to repeat lots of
it in this thread!
But has different requirement... Every channel connects
to different devices(sensors,key scanner,SCART etc ) with the
reference voltage will be different (~2V-5V)-can be changed
on-the-fly .
So far not that weird which is good...
So every Analog channel had to be configured within
(conversion_cycle_per_channel+ some buffer_jiffies) ..
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)?
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
