[PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi!

These two drivers share the fact that they wrap another iio channel,
and I use the first in combination with the second, which is why I'm
submitting them as a pair.

The first driver is a simple wrapper converting an iio dpot into an
iio dac. It only changes the unit and scale. It also does not add any
fancy iio buffer support that I don't need. I suppose that can be
added. By someone else :-)

Please look over the scale conversion, notably for the fractional log2
case that I don't need myself, so is untested. Maybe I should just
remove it?

Also, is there some agreed-upon way to dig out the maximum value from
an iio channel? If so, "dpot-dac,max-ohms" can be eliminated from the
dt bindings, which would have been nice...

I'm also wondering if I'm somehow abusing the regulator? I only added
it to get rid of a "dpot-dac,max-voltage" thing from the dt bindings.
It feels right though, but maybe I should do more with it than check
its voltage? What?

The second driver (the envelope detector) is more involved. It also
explains why I need the dpot-dac driver. I wanted the envelope
detector to be generic and work with any dac, but I had a dpot...

The envelope detector was previously discussed late last year [1],
and this is what I came up with instead of that mess.

There are a couple of things to be said about the envelope detector,
one question is where it should live? I placed it in the adc directory,
but maybe it deserves an iio directory of its own? I'm also a bit
worried that the name is a wee bit too generic. But what is a good
name? I don't want it to be too long like dac-comp-envelope-detector
and something like dac-comp-env-det is just unreadable. Naming is
difficult... And suggestions?

Another thing is that I'm not 100% satisfied with the fact that you
have to decide at instantiation if you are going to invert the search
or not (search from below). But in order for that to be selectable
at runtime with a channel attribute of some sort, I need to be able
to rebind the interrupt to the other edge and I want to do that
without releasing the irq and grabbing it again (someone might
otherwise steal the irq, making the driver lose the irq all together).
I don't see any API to change the irq trigger condition. Is there
such a thing?

Anyway, despite all the above questions and remarks, this works for
me. Please consider applying.

Cheers,
Peter

[1] http://www.gossamer-threads.com/lists/linux/kernel/2320755

Peter Rosin (4):
  dt-bindings: iio: document dpot-dac bindings
  iio: dpot-dac: DAC driver based on a digital potentiometer
  dt-bindings: iio: document envelope-detector bindings
  iio: envelope-detector: ADC driver based on a DAC and a comparator

 .../bindings/iio/adc/envelope-detector.txt         |  65 +++++
 .../devicetree/bindings/iio/dac/dpot-dac.txt       |  43 +++
 MAINTAINERS                                        |  14 +
 drivers/iio/adc/Kconfig                            |  10 +
 drivers/iio/adc/Makefile                           |   1 +
 drivers/iio/adc/envelope-detector.c                | 305 +++++++++++++++++++++
 drivers/iio/dac/Kconfig                            |  10 +
 drivers/iio/dac/Makefile                           |   1 +
 drivers/iio/dac/dpot-dac.c                         | 219 +++++++++++++++
 9 files changed, 668 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
 create mode 100644 Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
 create mode 100644 drivers/iio/adc/envelope-detector.c
 create mode 100644 drivers/iio/dac/dpot-dac.c

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux