1. 10 1月, 2018 1 次提交
  2. 10 10月, 2017 2 次提交
    • L
      iio: adc: mcp320x: Add support for mcp3550/1/3 · c1375d67
      Lukas Wunner 提交于
      These ADCs are marketed as single-channel 22 bit delta-sigma ADCs, but
      in reality their resolution is 21 bit with an overrange or underrange
      of 12% beyond Vref.  In other words, "full scale" means +/- 2^20.
      
      This driver does not explicitly signal back to the user when an
      overrange or underrange occurs, but the user can detect it by comparing
      the raw value to +/- 2^20 (or the scaled value to Vref).
      
      The chips feature an extended temperature range and high accuracy,
      low noise characteristics, but their conversion times are slow with
      up to 80 ms +/- 2% (on the MCP3550-50).
      
      Hence, unlike the other ADCs supported by the driver, conversion does
      not take place in realtime upon lowering CS.  Instead, CS is asserted
      for 8 usec to start the conversion.  After waiting for the duration of
      the conversion, the result can be fetched.  While waiting, control of
      the bus is ceased so it may be used by a different device.
      
      After the result has been fetched and 10 us have passed, the chip goes
      into shutdown and an additional power-up delay of 144 clock periods is
      then required to wake the analog circuitry upon the next conversion
      (footnote below table 4-1, page 16 in the spec).
      
      Optionally, the chips can be used in so-called "continuous conversion
      mode":  Conversions then take place continuously and the last result may
      be fetched at any time without observing a delay.  The mode is enabled
      by permanently driving CS low, e.g. by wiring it to ground.  The driver
      only supports "single conversion mode" for now but should be adaptable
      to "continuous conversion mode" with moderate effort.
      
      The chips clock out a 3 byte word, unlike the other ADCs supported by
      the driver which all have a lower resolution than 16 bit and thus make
      do with 2 bytes.  Calculate the word length on probe by rounding up the
      resolution to full bytes.  Crucially, if the clock idles low, the
      transfer is preceded by a useless Data Ready bit which increases its
      length from 24 bit to 25 bit = 4 bytes (section 5.5 in the spec).
      Autosense this based on the SPI slave's configuration.
      
      Cc: Mathias Duckeck <m.duckeck@kunbus.de>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      c1375d67
    • G
      iio: adc: rcar-gyroadc: Enable compile-testing on non-ARM · af5d716a
      Geert Uytterhoeven 提交于
      The rcar-gyroadc driver compiles fine on other platforms, hence increase
      compile coverage.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      af5d716a
  3. 08 10月, 2017 1 次提交
  4. 17 8月, 2017 1 次提交
  5. 26 7月, 2017 1 次提交
  6. 10 7月, 2017 1 次提交
  7. 05 7月, 2017 1 次提交
  8. 01 7月, 2017 1 次提交
  9. 21 5月, 2017 1 次提交
    • J
      iio: adc: Add support for TI ADC108S102 and ADC128S102 · 7e87d11c
      Jan Kiszka 提交于
      This is an upstream port of an IIO driver for the TI ADC108S102 and
      ADC128S102. The former can be found on the Intel Galileo Gen2 and the
      Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
      included.
      
      Due to the lack of regulators under ACPI, we hard-code the voltage
      provided to the VA pin of the ADC to 5 V, the value used on Galileo and
      IOT2000. For DT usage, the regulator "vref-supply" provides this
      information. Note that DT usage has not been tested.
      
      Original author: Bogdan Pricop <bogdan.pricop@emutex.com>
      Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
      Todor Minchev <todor@minchev.co.uk>.
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      7e87d11c
  10. 14 5月, 2017 1 次提交
  11. 27 4月, 2017 1 次提交
  12. 14 4月, 2017 1 次提交
    • A
      iio: adc: add max1117/max1118/max1119 ADC driver · a9e9c715
      Akinobu Mita 提交于
      This adds max1117/max1118/max1119 8-bit, dual-channel ADC driver.
      
      This new driver uses the zero length spi_transfers with the cs_change
      flag set and/or the non-zero delay_usecs.
      
      1. The zero length transfer with the spi_transfer.cs_change set is
      required in order to select CH1.  The chip select line must be brought
      high and low again without transfer.
      
      2. The zero length transfer with the spi_transfer.delay_usecs > 0 is
      required for waiting the conversion to be complete.  The conversion
      begins with the falling edge of the chip select.  During the conversion
      process, SCLK is ignored.
      
      These two usages are unusual.  But the spi controller drivers that use
      a default implementation of transfer_one_message() are likely to work.
      (I've tested this adc driver with spi-omap2-mcspi and spi-xilinx)
      
      On the other hand, some spi controller drivers that have their own
      transfer_one_message() may not work.  But at least for the zero length
      transfer with delay_usecs > 0, I'm proposing a new testcase for the
      spi-loopback-test that can test whether the delay_usecs setting has
      taken effect.
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mark Brown <broonie@kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      a9e9c715
  13. 09 4月, 2017 4 次提交
    • L
      iio: adc: add a driver for Qualcomm PM8xxx HK/XOADC · 63c3ecd9
      Linus Walleij 提交于
      The Qualcomm PM8xxx PMICs contain a simpler ADC than its
      successors (already in the kernel as qcom-spmi-vadc.c):
      the HK/XO ADC (Housekeeping/Chrystal oscillator ADC).
      
      As far as I can understand this is equal to the PMICs
      using SSBI transport and encompass PM8018, PM8038,
      PM8058, and PM8921, so this is shortly named PM8xxx.
      
      This ADC monitors a bunch of on-board voltages and the die
      temperature of the PMIC itself, but it can also be routed
      to convert a few external MPPs (multi-purpose pins). On
      the APQ8060 DragonBoard this feature is used to let this
      ADC convert an analog ALS (Ambient Light Sensor) voltage
      signal from a Capella CM3605 ALS into a LUX value.
      
      Developed and tested with APQ8060 DragonBoard based on
      Ivan's driver and Rama Krishna's patches. The SPMI VADC
      driver is quite different, but share enough minor
      functionality that I have split out to the common file
      in a previous patch.
      
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-arm-msm@vger.kernel.org
      Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
      Cc: Andy Gross <andy.gross@linaro.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Rama Krishna Phani A <rphani@codeaurora.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      63c3ecd9
    • L
      iio: adc: break out common code from SPMI VADC · e932d4f0
      Linus Walleij 提交于
      The SPMI VADC and the earlier XOADC share a subset of
      common code, so to be able to use the same code in both
      drivers, we break out a separate file with the common code,
      prefix exported functions that are no longer static with
      qcom_* and bake an object qcom-spmi-vadc.o that contains both
      files: qcom-vadc-common.o and qcom-spmi-vadc-core.o.
      
      As we need to follow the procedure for making a kernel module
      or compiled in object from several files, but still want to
      produce the same module name, rename the qcom-spmi-vadc.c
      file to qcom-spmi-vadc-core.c so we can bake the two objects
      into qcom-spmi-vadc.o
      
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-arm-msm@vger.kernel.org
      Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
      Cc: Andy Gross <andy.gross@linaro.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Rama Krishna Phani A <rphani@codeaurora.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      e932d4f0
    • Q
      iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor · 808a8b73
      Quentin Schulz 提交于
      This adds support for the Allwinner A33 thermal sensor.
      
      Unlike the A10, A13 and A31, the Allwinner A33 only has one channel
      which is dedicated to the thermal sensor. Moreover, its thermal sensor
      does not generate interruptions, thus we only need to directly read the
      register storing the temperature value.
      
      The MFD used by the A10, A13 and A31, was created to avoid breaking the
      DT binding, but since the nodes for the ADC weren't there for the A33,
      it is not needed.
      
      Though the A33 does not have an internal ADC, it has a thermal sensor
      which shares the same registers with GPADC of the already supported SoCs
      and almost the same bits, for the same purpose (thermal sensor).
      
      The thermal sensor behaves exactly the same (except the presence of
      interrupts or not) on the different SoCs.
      Signed-off-by: NQuentin Schulz <quentin.schulz@free-electrons.com>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      808a8b73
    • J
      iio: adc: Add Maxim max9611 ADC driver · 69780a3b
      Jacopo Mondi 提交于
      Add iio driver for Maxim max9611 and max9612 current-sense amplifiers
      with 12-bits ADC interface.
      
      Datasheet publicly available at:
      https://datasheets.maximintegrated.com/en/ds/MAX9611-MAX9612.pdfSigned-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      69780a3b
  14. 02 4月, 2017 2 次提交
  15. 01 4月, 2017 1 次提交
  16. 31 3月, 2017 1 次提交
    • T
      iio: adc: cpcap: Add minimal support for CPCAP PMIC ADC · 25ec2496
      Tony Lindgren 提交于
      On Motorola phones like droid 4 there is a custom CPCAP PMIC. This PMIC
      has ADCs that are used for battery charging and USB PHY VBUS and ID pin
      detection.
      
      Unfortunately the only documentation for this ADC seems to be the
      Motorola mapphone Linux kernel tree. I have tested that reading raw and
      scaled values works, but I have not used the timed sampling that the ADC
      seems to support.
      
      Let's add a minimal support for it so we can eventually provide IIO
      channels for the related battery charging and USB PHY drivers.
      
      Cc: devicetree@vger.kernel.org
      Cc: Marcel Partap <mpartap@gmx.net>
      Cc: Michael Scott <michael.scott@linaro.org>
      Cc: Sebastian Reichel <sre@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      25ec2496
  17. 23 3月, 2017 2 次提交
  18. 16 3月, 2017 1 次提交
  19. 09 3月, 2017 1 次提交
    • Q
      iio: adc: add support for Allwinner SoCs ADC · d1caa990
      Quentin Schulz 提交于
      The Allwinner SoCs all have an ADC that can also act as a touchscreen
      controller and a thermal sensor. This patch adds the ADC driver which is
      based on the MFD for the same SoCs ADC.
      
      This also registers the thermal adc channel in the iio map array so
      iio_hwmon could use it without modifying the Device Tree. This registers
      the driver in the thermal framework.
      
      The thermal sensor requires the IP to be in touchscreen mode to return
      correct values. Therefore, if the user is continuously reading the ADC
      channel(s), the thermal framework in which the thermal sensor is
      registered will switch the IP in touchscreen mode to get a temperature
      value and requires a delay of 100ms (because of the mode switching),
      then the ADC will switch back to ADC mode and requires also a delay of
      100ms. If the ADC readings are critical to user and the SoC temperature
      is not, this driver is capable of not registering the thermal sensor in
      the thermal framework and thus, "quicken" the ADC readings.
      
      This driver probes on three different platform_device_id to take into
      account slight differences (registers bit and temperature computation)
      between Allwinner SoCs ADCs.
      Signed-off-by: NQuentin Schulz <quentin.schulz@free-electrons.com>
      Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Acked-for-MFD-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      d1caa990
  20. 11 2月, 2017 2 次提交
    • J
      staging:iio:adc:lpc32xx Move out of staging. · 0097e20e
      Jonathan Cameron 提交于
      There are a few more little cleanups that could be done on this driver, but
      I don't think any are sufficient to justify not moving it out of staging.
      
      It's a very simple driver (presumably for a simple part) so not much that can
      go wrong.  I think it was only ever in staging because that's where IIO was
      as a whole at the time and then we forgot about it!
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      Cc: Roland Stigge <stigge@antcom.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      0097e20e
    • J
      staging:iio:adc:spear Move out of staging. · af8f651b
      Jonathan Cameron 提交于
      There are some unanswered questions due to disagreements between the code
      and various datasheets (including between different datasheets for the same
      part).
      
      I don't think that is necessarily a reason to keep it in staging however.
      I'm partly posting this patch inorder to reignite debate and with a bit
      of luck find someone who has one of these to test!
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      af8f651b
  21. 29 1月, 2017 3 次提交
  22. 28 1月, 2017 2 次提交
    • M
      iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs · 3adbf342
      Martin Blumenstingl 提交于
      This adds support for the SAR (Successive Approximation Register) ADC
      on the Amlogic Meson SoCs.
      
      The code is based on the public S805 (Meson8b) and S905 (GXBB)
      datasheets (see [0] and [1]), as well as by reading (various versions
      of) the vendor driver and by inspecting the registers on the vendor
      kernels of my testing-hardware.
      
      Currently the GXBB, GXL and GXM SoCs are supported. GXBB hardware has
      10-bit ADC resolution, while GXL and GXM have 12-bit ADC resolution.
      The code was written to support older SoCs (Meson8 and Meson8b) as well,
      but due to lack of actual testing-hardware no of_device_id was added for
      these.
      
      Two "features" from the vendor driver are currently missing:
      - the vendor driver uses channel #7 for calibration (this improves the
        accuracy of the results - in my tests the results were less than 3%
        off without calibration compared to the vendor driver). Adding support
        for this should be easy, but is not required for most applications.
      - channel #6 is connected to the SoCs internal temperature sensor.
        Adding support for this is probably not so easy since (based on the
        u-boot sources) most SoC versions are using different registers and
        algorithms for the conversion from "ADC value" to temperature.
      
      Supported by the hardware but currently not supported by the driver:
      - reading multiple channels at the same time (the hardware has a FIFO
        buffer which stores multiple results)
      - continuous sampling (this would require a way to enable this
        individually because otherwise the ADC would be drawing power
        constantly)
      - interrupt support (similar to the vendor driver this new driver is
        polling the results. It is unclear if the IRQ-mode is supported on
        older (Meson6 or Meson8) hardware as well or if there are any errata)
      
      [0]
      http://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf
      [1] http://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdfSigned-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      3adbf342
    • M
      iio: adc: Add Renesas GyroADC driver · 059c53b3
      Marek Vasut 提交于
      Add IIO driver for the Renesas RCar GyroADC block. This block is a
      simple 4/8-channel ADC which samples 12/15/24 bits of data every
      cycle from all channels.
      Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: linux-renesas-soc@vger.kernel.org
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      059c53b3
  23. 22 1月, 2017 1 次提交
  24. 21 1月, 2017 1 次提交
  25. 11 1月, 2017 1 次提交
  26. 31 12月, 2016 1 次提交
  27. 03 12月, 2016 1 次提交
  28. 19 11月, 2016 2 次提交
  29. 13 11月, 2016 1 次提交