mxs-lradc: Add support for current sources
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 of 3 patches 0 repliesNew
1 of 3 patches is in this archive. The cover letter announces 3.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | iio: mxs-lradc: Add regulators for current sources | +0 | 3 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] mxs-lradc: Add support for current sources
Hi Harald,
Am 01.05.2016 um 20:02 schrieb Jonathan Cameron:
Quoted 24 lines · Harald Geyer
Quoted 23 lines
Hi Stefan!
Quoted 13 lines · Stefan Wahren
Hi Harald,
Am 22.04.2016 um 15:52 schrieb Harald Geyer:
Quoted 10 lines
Patch 1/3 changes the driver and updates the binding documentation (I guess it is still in staging.)
Patches 2/3 and 3/3 add the devicetree nodes to imx23 and imx28 boards. I'd like to get input whether this is actually desired. On boards where these regulators would never be enabled this costs a few extra bytes of RAM for allocation of the device data, because the nodes can't be easily removed in .dts files which are including the .dtsi files. The alternative is to add the new nodes to many .dts files, which would be a lot code duplication.
Quoted 2 lines
if i get it right the real intention of this patch series is to make the mxs-lradc provide resistance values instead of voltages.
... or even temperature values if a thermistor is connected.
Quoted 3 lines
So how about
dropping the whole regulator stuff and provide the values asIIO_RESISTANCEvia iio interface?
Quoted 8 lines
Quoted 6 lines
Can you elaborate on this?
My thinking is that there should be a thermistor (or whatever else) driver, that is a consumer of the regulator and a consumer of the
IIO_VOLTAGEiio channel and provides a new device with anIIO_RESISTANCEorIIO_TEMPchannel. Maybe there is a simpler solution, that I'm missing?I agree with that approach - need a way to describe the upstream hardware - so will need a thermistor driver
okay, this makes more sense to me. In this case it would be good to have this new driver in this patch series. So it's possible to verify the matching binding.
Quoted 5 lines
Quoted 5 lines
Actually I'm not 100% happy with the above solution myself, because if we start supporting devices that act as an iio-multiplexer (some device that is an iio consumer and provides many new iio channels and can control via gpios which of it child channels is actually routed to the upstream device) I don't know how to properly manage the regulator device.
Quoted 14 lines
Hmm. Are you talking about muxing the regulator as well? That will get complex indeed. Might be possible to cheat and imply the regulators are always connected to all inputs... or do you want to dynamically change the regulator output? That gets messy fast - though in theory might be possible...
Quoted 9 lines
However since this is only hypothetical ATM, I think we don't have to worry about this too much.
Quoted 1 line
Btw this feature should be only added to dts files where is actually used.
Ok, so how do we figure out which boards these are?
I use this on the olinuxino and I guess all evaluation boards support the use case too. The others I don't know enough about to be sure and I guess it's not a good idea to just wait until somebody speaks up and complains that the feature is missing on board X ...
The imx23 dtsi file specifies features on SoC level and i think this should be kept. We shouldn't implement features for ADC pins without deeper knowledge about these boards.
Maybe we could introduce a new dtsi file in order to reduce copy & paste. But at first the OlinuXino should be a good starting point ...
Regards
Stefan