1. 24 9月, 2017 10 次提交
  2. 04 9月, 2017 2 次提交
  3. 21 8月, 2017 16 次提交
  4. 20 8月, 2017 12 次提交
    • P
      iio: adc: rockchip_saradc: explicitly request exclusive reset control · 87587016
      Philipp Zabel 提交于
      Commit a53e35db ("reset: Ensure drivers are explicit when requesting
      reset lines") started to transition the reset control request API calls
      to explicitly state whether the driver needs exclusive or shared reset
      control behavior. Convert all drivers requesting exclusive resets to the
      explicit API call so the temporary transition helpers can be removed.
      
      No functional changes.
      
      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: Heiko Stuebner <heiko@sntech.de>
      Cc: linux-iio@vger.kernel.org
      Cc: linux-rockchip@lists.infradead.org
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      87587016
    • P
      iio: dac: stm32-dac-core: explicitly request exclusive reset control · a1b509df
      Philipp Zabel 提交于
      Commit a53e35db ("reset: Ensure drivers are explicit when requesting
      reset lines") started to transition the reset control request API calls
      to explicitly state whether the driver needs exclusive or shared reset
      control behavior. Convert all drivers requesting exclusive resets to the
      explicit API call so the temporary transition helpers can be removed.
      
      No functional changes.
      
      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: Maxime Coquelin <mcoquelin.stm32@gmail.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      a1b509df
    • A
      iio: adc: ti-ads1015: add threshold event support · d9f39bab
      Akinobu Mita 提交于
      The ADS1015 device provides programmable comparator that can issue an
      interrupt on the ALERT pin.  This change adds the iio threshold event
      support for that feature.
      
      The ADS1015 device only have a single config register which contains an
      input multiplexer selection, comparator settings, and etc.  So only a
      single event channel can be enabled at a time.  Also enabling both buffer
      and event are prohibited for simplicity.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      d9f39bab
    • A
      iio: adc: ti-ads1015: use iio_device_claim_direct_mode() · 47d8cf41
      Akinobu Mita 提交于
      While the iio buffer for the ti-ads1015 driver is enabled, reading the
      raw ADC channel data is restricted.  We usually use the
      iio_device_claim_direct_mode()/iio_device_release_direct_mode() pair for
      that.
      
      This change consequently reverses the locking order for the driver's
      private lock and indio_dev->mlock which acquired by
      iio_device_claim_direct_mode() internally. But it's safe because there is
      no other dependency between these locks.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      47d8cf41
    • A
      iio: adc: ti-ads1015: use devm_iio_triggered_buffer_setup · 4de43d25
      Akinobu Mita 提交于
      Use devm_iio_triggered_buffer_setup to simplify the error path in the
      probe() and remove() function.
      
      This changes the remove order, but the end result of remove function
      actually does the reverse of probe.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      4de43d25
    • A
      iio: adc: ti-ads1015: add helper to set conversion mode · 4128e8de
      Akinobu Mita 提交于
      This adds a helper function to set conversion mode as there are a fair
      number of users.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      4128e8de
    • A
      iio: adc: ti-ads1015: remove unnecessary config register update · 56b57a9e
      Akinobu Mita 提交于
      The ti-ads1015 driver has eight iio voltage channels and each iio channel
      can hold own scale information.
      
      The ADS1015 device only have a single config register which contains an
      input multiplexer selection, PGA and data rate settings.  So the driver
      should load the correct settings when the input multiplexer selection is
      changed.
      
      However, regardless of which channlel is currently selected, changing any
      iio channel's scale information immediately overwrites the current PGA
      setting in the config register.
      
      It is harmless because the correct PGA settings are reloaded just before
      getting adc result anyway.  But it is unnecessary register update and
      should be removed.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      56b57a9e
    • A
      iio: adc: ti-ads1015: add adequate wait time to get correct conversion · 4744d4e2
      Akinobu Mita 提交于
      This driver assumes that the device is operating in the continuous
      conversion mode which performs the conversion continuously.  So this driver
      inserts a wait time before reading the conversion register if the
      configuration is changed from a previous request.
      
      Currently, the wait time is only the period required for a single
      conversion that is calculated as the reciprocal of the sampling frequency.
      However we also need to wait for the the previous conversion to complete.
      Otherwise we probably get the conversion result for the previous
      configuration when the sampling frequency is lower.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      4744d4e2
    • A
      iio: adc: ti-ads1015: don't return invalid value from buffer setup callbacks · a6fe5e52
      Akinobu Mita 提交于
      pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on
      success, 1 if the device's runtime PM status was already requested status
      or error code on failure.  So a positive return value doesn't indicate an
      error condition.
      
      However, any non-zero return values from buffer preenable and postdisable
      callbacks are recognized as an error and this driver reuses the return
      value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in
      these callbacks.  This change fixes the false error detections.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      a6fe5e52
    • A
      iio: adc: ti-ads1015: avoid getting stale result after runtime resume · 73e3e3fc
      Akinobu Mita 提交于
      This driver assumes that the device is operating in the continuous
      conversion mode which performs the conversion continuously.  So this driver
      doesn't insert a wait time before reading the conversion register if the
      configuration is not changed from a previous request.
      
      This assumption is broken if the device is runtime suspended and entered
      a power-down state.  The forthcoming request causes reading a stale result
      from the conversion register as the device is runtime resumed just before.
      
      Fix it by adding a flag to detect that condition and insert a necessary
      wait time.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      73e3e3fc
    • A
      iio: adc: ti-ads1015: enable conversion when CONFIG_PM is not set · e8245c68
      Akinobu Mita 提交于
      The ADS1015 device have two operating modes, continuous conversion mode
      and single-shot mode.  This driver assumes that the continuous conversion
      mode is selected by runtime resume callback when the ADC result is
      requested.
      
      If CONFIG_PM is disabled, the device is always in the default single-shot
      mode and no one begins a single conversion.  So the conversion register
      doesn't contain valid ADC result.  Fix it by changing the continuous mode
      in probe function.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      e8245c68
    • A
      iio: adc: ti-ads1015: fix scale information for ADS1115 · 8d0e8e79
      Akinobu Mita 提交于
      The ti-ads1015 driver supports ADS1015 and ADS1115 devices.  The same
      scale information is used for both devices in this driver, however they
      have actually different values and the ADS1115's one is not correct.
      
      These devices have the same full-scale input voltage range for each PGA
      selection.  So instead of adding another hardcoded scale information,
      compute a correct scale on demand from each device's resolution.
      
      Cc: Daniel Baluta <daniel.baluta@gmail.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      8d0e8e79