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
