1. 15 Dec, 2019 21 commits
  2. 01 Dec, 2019 4 commits
  3. 23 Nov, 2019 15 commits
    • Andreas Klinger's avatar
      dt-bindings: add parallax ping sensors · b7f35e7d
      Andreas Klinger authored
      Add dt-bindings for parallax PING))) and LaserPING iio sensors, which
      are used for measuring distances.
      Signed-off-by: default avatarAndreas Klinger <ak@it-klinger.de>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      b7f35e7d
    • Andreas Klinger's avatar
      dt-bindings: add vendor prefix parallax · 3e976962
      Andreas Klinger authored
      Add new vendor prefix parallax for newly created ping iio sensors.
      Signed-off-by: default avatarAndreas Klinger <ak@it-klinger.de>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      3e976962
    • Alexandru Tachici's avatar
      iio: dac: ad7303: use regulator get optional to check for ext supply · a8b26c2d
      Alexandru Tachici authored
      Previously, the code was using the of_read_property_bool() to check if
      an external regulator was provided. However, this is redundant, as it's
      more simple/direct to just ask the regulator is provided, via a
      `devm_regulator_get_optional()` call.
      Signed-off-by: default avatarAlexandru Tachici <alexandru.tachici@analog.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      a8b26c2d
    • Andrea Merello's avatar
      dt-bindings: iio: maxim_thermocouple: document new 'compatible' strings · 3922f930
      Andrea Merello authored
      Now the maxim_thermocouple has new, more specific, 'compatible' strings for
      better distinguish the various supported chips.
      
      This patch updates the DT bindings documentation accordingly
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      3922f930
    • Andrea Merello's avatar
      iio: maxim_thermocouple: add thermocouple_type sysfs attribute · d7f6a749
      Andrea Merello authored
      We added a sysfs ABI for getting/setting the type of a thermocouple. This
      driver supports chips that support specific fixed thermocouple types; we
      cannot set it, but still we can add this sysfs attribute in RO mode to
      read-back the thermocouple type.
      
      This driver supports actually several chips:
       - max6675
       - max31855[k/j/n/s/t/e/r]asa family
      
      Max6675 supports only K-type thermocouples, so we can just report that.
      
      Each chip in max31855 family supports just one specific thermocouple type
      (in the obvious way: i.e. max31855jasa supports J-type). This driver did
      accept a generic SPI ID and OF compatible "max31855" which does not give
      any clue about which chip is really involved (and unfortunately it seems
      we have no way to detect it).
      
      This patch introduces a new set of, more specific, SPI IDs and OF
      compatible strings to better match the chip type.
      
      The old, generic, "max31855" binding is kept for compatibility reasons, but
      this patch aims to deprecate it, so, should we hit it, a warning is spit.
      In such case the reported thermocouple type in sysfs is '?', because we
      have no way to know.
      
      Regarding the implementation: the thermocouple type information is stored
      in the driver private data and I've kept only two maxim_thermocouple_chip
      types in order to avoid a lot of duplications (seven chip types with just
      a different thermocouple type).
      
      RFT because I have no real HW to test this.
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      d7f6a749
    • Andrea Merello's avatar
      iio: max31856: add support for runtime-configuring the thermocouple type · ea410307
      Andrea Merello authored
      The sensor support various thermocouple types (e.g. J, K, N, ...). The
      driver allows to configure this parameter using a DT property.
      
      This is useful when i.e. the thermocouple is physically tied to the sensor
      and it is usually not removed, or when it is at least known in advance
      which sensor will be connected to the circuit.
      
      However, if the user can randomly connect any kind of thermocouples (i.e.
      the device exposes a connector, and the user is free to connect its own
      sensors), it would be more appropriate to provide a mechanism to
      dynamically switch from one thermocouple type to another. This can be i.e.
      handled in userspace by a GUI, a configuration file or a program that
      detects the thermocouple type by reading a GPIO, or a eeprom on the probe,
      or whatever.
      
      This patch adds a IIO attribute that can be used to override, at run-time,
      the DT-provided setting (which serves as default).
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      ea410307
    • Andrea Merello's avatar
      Documentation: ABI: document IIO thermocouple_type file · 83b9af6f
      Andrea Merello authored
      IIO core layer gained a new sysfs standard attribute "thermocouple_type".
      This patch adds it to the list of documented ABI for sysfs-bus-iio
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      83b9af6f
    • Andrea Merello's avatar
      iio: core: add thermocouple_type standard attribute · ddfb97d8
      Andrea Merello authored
      We have a couple of thermocouple IIO drivers, supporting several chips.
      Some of them support only one specific thermocouple type (e.g. "K", "J"),
      one of them can be configured to work with several different thermocouple
      types.
      
      In certain applications thermocouples could be externally connected to the
      chip by the user.
      
      This patch introduces a new IIO standard attribute to report the supported
      thermocouple type and, where applicable, to allow it to be dynamically set
      using sysfs.
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      ddfb97d8
    • Andrea Merello's avatar
      iio: core: add char type for sysfs attributes · 8cb34036
      Andrea Merello authored
      This patch introduces IIO_VAL_CHAR type for standard IIO attributes to
      allow for attributes that needs to be represented by character rather
      than a number. This is preparatory for introducing a new attribute whose
      purpose is to describe thermocouple type, that can be i.e. "J", "K", etc..
      
      The char-type value is stored in the first "value" integer that is passed
      to the .[read/write]_raw() callbacks.
      
      Note that in order to make it possible for the IIO core to correctly parse
      this type (actually, to avoid integer parsing), it became mandatory for
      any driver that wish to use IIO_VAL_CHAR on a writable attribute to
      implement .write_raw_get_fmt().
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      8cb34036
    • Andrea Merello's avatar
      iio: max31856: add support for configuring the HW averaging · 57a4274c
      Andrea Merello authored
      This sensor can perform samples averaging in hardware, but currently the
      driver leaves this setting alone (default is no averaging).
      
      This patch binds this HW setting to the "oversampling_ratio" IIO attribute
      and allows the user to set the averaging as desired (the HW supports
      averaging of 2, 5, 8 or 16 samples; in-between values are rounded up).
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      57a4274c
    • Andrea Merello's avatar
      Documentation: ABI: document IIO in_temp_filter_notch_center_frequency file · 3f6bba19
      Andrea Merello authored
      max31856 IIO driver introduced a new attribute
      "in_temp_filter_notch_center_frequency".
      This patch adds it to the list of documented ABI for sysfs-bus-iio
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      3f6bba19
    • Andrea Merello's avatar
      iio: max31856: add option for setting mains filter rejection frequency · 76aa41c1
      Andrea Merello authored
      This sensor has an embedded notch filter for reducing interferences caused
      by the power mains. This filter can be tuned to reject either 50Hz or 60Hz
      (and harmonics).
      
      Currently the said setting is left alone (the sensor defaults to 60Hz).
      This patch introduces a IIO attribute that allows the user to set the said
      filter to the desired frequency.
      
      NOTE: this has been intentionally not tied to any DT property to allow
      the configuration of this setting from userspace, e.g. with a GUI or by
      reading a configuration file, or maybe reading a GPIO tied to a physical
      switch or accessing some device that can autodetect the line frequency.
      
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Patrick Havelange <patrick.havelange@essensium.com>
      Cc: Matt Weber <matthew.weber@rockwellcollins.com>
      Cc: Matt Ranostay <matt.ranostay@konsulko.com>
      Cc: Chuhong Yuan <hslester96@gmail.com>
      Cc: Daniel Gomez <dagmcr@gmail.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Reviewed-by: default avatarMatt Ranostay <matt.ranostay@konsulko.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      76aa41c1
    • Alexandru Ardelean's avatar
      iio: gyro: adis16260: replace mlock with ADIS lib's state_lock · 160b37f4
      Alexandru Ardelean authored
      This change uses the ADIS library's state_lock to protect the state of the
      `max_speed_hz` change that is done during the set of the sampling
      frequency.
      Signed-off-by: default avatarAlexandru Ardelean <alexandru.ardelean@analog.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      160b37f4
    • Alexandru Ardelean's avatar
      iio: imu: adis16480: use state lock for filter freq set · d693845d
      Alexandru Ardelean authored
      It's the only operation that does 2 operations (a read & a write), so the
      unlocked functions can be used under a single state lock.
      Signed-off-by: default avatarAlexandru Ardelean <alexandru.ardelean@analog.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      d693845d
    • Alexandru Ardelean's avatar
      iio: gyro: adis16136: rework locks using ADIS library's state lock · 0aee99a1
      Alexandru Ardelean authored
      This replaces indio_dev's mlock with the state lock/mutex from the ADIS
      library.
      
      The __adis16136_get_freq() function has been prefixed to mark it as
      unlocked. The adis16136_{set,get}_filter() functions now hold the state
      lock for all the ops that they do.
      Signed-off-by: default avatarAlexandru Ardelean <alexandru.ardelean@analog.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      0aee99a1