Patch: iio: adc: ltc2485: add support for Linear Technology LTC2485 ADC
Take a look at the linux-iio mailing list discussion of this patch. It includes a conversation about what additional support can be added to this driver.
Beyond the set up adventures which I posted previously, here are a few noteworthy items from the LTC2485 driver development & test.
Configuring the LTC2485
I want to default to the power-on configuration in this first submittal, but I really can't assume the device was just powered on when we are probing it. The power-on default configuration value is 0 and there is no way to read it back after you write it. (Unlike some other devices where you can do a read after write to verify your settings) So, I needed to make a change to the configuration that I could actually verify. I used the option of reading Temperature, instead of voltage. I configured the ADC to return temperatures instead of voltages, and it worked, so I knew that my configuration writes were going to the correct location. (Saved that code for possible later implementation of temperature reads.)
Implementing Conversion Wait Time
In previous drivers, I triggered a conversion, waited the appropriate amount of time, then read the data. In this driver a new conversion is triggered any time we read a conversion or we write the configuration. It's considered single-shot mode because it does one conversion and waits for you to read it before doing another conversion.
When you go to read the data it may be:
- READY to read (perhaps even very stale data) We don't address the stale data at the driver level. The application would need to know that the first read after idle time is going to be stale. We don't want to refresh that automatically, because what is stale to us, is perhaps just what the application wanted.
- NOT READY yet. This will be the case when conversion time has not passed since the last read. This is the case we need to avoid because it will generate errors.
The code to wait conversion time stores the last conversion completion time in the global data struct, and verifies that the desired conversion time (147ms) has passed before sending the next read. Here it is:
Testing the conversion wait time
The 147ms conversion time is from the datasheet and is based on the configuration setting. Since we are not allowing changes to the configuration yet, that hard-coded value is fine.
I could tweek the 147 and see the driver pass/fail, but what I really wanted to do was see it wait for the 147 to pass. I wanted to know that it waited when bombarded with reads, and see that it never waited when reads were done at a leisurely pace. For that case I incremented a sleep counter that was stored in global data whenever msleep() was called. Then I defined a sysfs attribute to read and reset that counter so I could use it in my test script.
It was just a small thing, but it opened my eyes to how I can use that sysfs interface for debug hooks in future development & test. (It beats printk)
Handling the Return Data
The point of the driver is to return the data correctly. Here I used a culmination of the things I had learned in 2 previous drivers, plus a bit extra for the LTC2485:
- sign_extend32() from MCP9808
- be32_to_cpu() from HDC100x
- shifting out the invalid bits from LTC2485
to deliver the data as: sign_extend32(be32_to_cpu(buf) >> 6, 24);
(It use to be that those lines of code would make my head spin, now they just slow me down)
Labels: LTC2485
