1. 22 8月, 2016 2 次提交
    • V
      iio: adc: ti_am335x_adc: Increase timeout value waiting for ADC sample · 7175cce1
      Vignesh R 提交于
      Now that open delay and sample delay for each channel is configurable
      via DT, the default IDLE_TIMEOUT value is not enough as this is
      calculated based on hardcoded macros. This results in driver returning
      EBUSY sometimes. Fix this by increasing the timeout
      value based on maximum value possible to open delay and sample delays
      for each channel.
      
      Fixes: 5dc11e81 ("iio: adc: ti_am335x_adc: make sample delay, open delay, averaging DT parameters")
      Signed-off-by: NVignesh R <vigneshr@ti.com>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      7175cce1
    • V
      iio: adc: ti_am335x_adc: Protect FIFO1 from concurrent access · 90c43ec6
      Vignesh R 提交于
      It is possible that two or more ADC channels can be simultaneously
      requested for raw samples, in which case there can be race in access to
      FIFO data resulting in loss of samples.
      If am335x_tsc_se_set_once() is called again from tiadc_read_raw(), when
      ADC is still acquired to sample one of the channels, the second process
      might be put into uninterruptible sleep state. Fix these issues, by
      protecting FIFO access and channel configurations with a mutex. Since
      tiadc_read_raw() might take anywhere between few microseconds to few
      milliseconds to finish execution (depending on averaging and delay
      values supplied via DT), its better to use mutex instead of spinlock.
      
      Fixes: 7ca6740c ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization")
      Signed-off-by: NVignesh R <vigneshr@ti.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      90c43ec6
  2. 03 6月, 2016 2 次提交
  3. 16 1月, 2016 1 次提交
    • J
      iio:adc:ti_am335x_adc Fix buffered mode by identifying as software buffer. · 9d0be85d
      Jonathan Cameron 提交于
      Whilst this part has a hardware buffer, the identifcation that IIO cares
      about is the userspace facing end.  It this case we push individual elements
      from the hardware fifo into the software interface (specifically a kfifo)
      rather than providing direct reads through to a hardware buffer
      (as we still do in the sca3000 for example).
      
      Technically the original specification as a hardware buffer could be
      considered wrong, but it didn't matter until the patch listed below.
      
      Result is that any attempt to enable the buffer will return -EINVAL
      
      Fixes: 225d59ad ("iio: Specify supported modes for buffers")
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      9d0be85d
  4. 14 5月, 2015 1 次提交
  5. 09 4月, 2015 1 次提交
  6. 08 3月, 2015 1 次提交
  7. 04 2月, 2015 1 次提交
  8. 26 12月, 2014 1 次提交
  9. 12 12月, 2014 1 次提交
    • L
      iio: Move buffer registration to the core · 3e1b6c95
      Lars-Peter Clausen 提交于
      Originally device and buffer registration were kept as separate operations
      in IIO to allow to register two distinct sets of channels for buffered and
      non-buffered operations. This has since already been further restricted and
      the channel set registered for the buffer needs to be a subset of the
      channel set registered for the device. Additionally the possibility to not
      have a raw (or processed) attribute for a channel which was registered for
      the device was added a while ago. This means it is possible to not register
      any device level attributes for a channel even if it is registered for the
      device. Also if a channel's scan_index is set to -1 and the channel is
      registered for the buffer it is ignored.
      
      So in summary it means it is possible to register the same channel array for
      both the device and the buffer yet still end up with distinctive sets of
      channels for both of them. This makes the argument for having to have to
      manually register the channels for both the device and the buffer invalid.
      Considering that the vast majority of all drivers want to register the same
      set of channels for both the buffer and the device it makes sense to move
      the buffer registration into the core to avoid some boiler-plate code in the
      device driver setup path.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      3e1b6c95
  10. 27 8月, 2014 1 次提交
  11. 09 7月, 2014 1 次提交
  12. 11 1月, 2014 1 次提交
  13. 07 1月, 2014 4 次提交
    • S
      mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization · 7ca6740c
      Sebastian Andrzej Siewior 提交于
      The ADC driver always programs all possible ADC values and discards
      them except for the value IIO asked for. On the am335x-evm the driver
      programs four values and it takes 500us to gather them. Reducing the number
      of conversations down to the (required) one also reduces the busy loop down
      to 125us.
      
      This leads to another error, namely the FIFOCOUNT register is sometimes
      (like one out of 10 attempts) not updated in time leading to EBUSY.
      The next read has the FIFOCOUNT register updated.
      Checking for the ADCSTAT register for being idle isn't a good choice either.
      The problem is that if TSC is used at the same time, the HW completes the
      conversation for ADC *and* before the driver noticed it, the HW begins to
      perform a TSC conversation and so the driver never seen the HW idle. The
      next time we would have two values in the FIFO but since the driver reads
      everything we always see the current one.
      So instead of polling for the IDLE bit in ADCStatus register, we should
      check the FIFOCOUNT register. It should be one instead of zero because we
      request one value.
      
      This change in turn leads to another error. Sometimes if TSC & ADC are
      used together the TSC starts generating interrupts even if nobody
      actually touched the touchscreen. The interrupts seem valid because TSC's
      FIFO is filled with values for each channel of the TSC. This condition stops
      after a few ADC reads but will occur again. Not good.
      
      On top of this (even without the changes I just mentioned) there is a ADC
      & TSC lockup condition which was reported to me by Jeff Lance including the
      following test case:
      A busy loop of "cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw"
      and a mug on touch screen. With this setup, the hardware will lockup after
      something between 20 minutes and it could take up to a couple of hours.
      During that lockup, the ADCSTAT register says 0x30 (or 0x70) which means
      STEP_ID = IDLE and FSM_BUSY = yes. That means the hardware says that it is
      idle and busy at the same time which is an invalid condition.
      
      For all this reasons I decided to rework this TSC/ADC part and add a
      handshake / synchronization here:
      First the ADC signals that it needs the HW and writes a 0 mask into the
      SE register. The HW (if active) will complete the current conversation
      and become idle. The TSC driver will gather the values from the FIFO
      (woken up by an interrupt) and won't "enable" another conversation.
      Instead it will wake up the ADC driver which is already waiting. The ADC
      driver will start "its" conversation and once it is done, it will
      enable the TSC steps so the TSC will work again.
      
      After this rework I haven't observed the lockup so far. Plus the busy
      loop has been reduced from 500us to 125us.
      
      The continues-read mode remains unchanged.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      7ca6740c
    • S
      mfd: ti_am335x: Drop am335x_tsc_se_update() from resume path · 3954b7bf
      Sebastian Andrzej Siewior 提交于
      The update of the SE register in MFD doesn't look right as it has
      nothing to do with it. The better place to do it is in TSC driver (which
      is already doing it) and in the ADC driver which needs this only in the
      continues mode.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      3954b7bf
    • S
      mfd: ti_am335x_tscadc: Don't read back REG_SE · 7e170c6e
      Sebastian Andrzej Siewior 提交于
      The purpose of reg_se_cache has been defeated. It should avoid the
      read-back of the register to avoid the latency and the fact that the
      bits are reset to 0 after the individual conversation took place.
      
      The reason why this is required like this to work, is that read-back of
      the register removes the bits of the ADC so they do not start another
      conversation after the register is re-written from the TSC side for the
      update.
      To avoid the not required read-back I introduce a "set once" variant which
      does not update the cache mask. After the conversation completes, the
      bit is removed from the SE register anyway and we don't plan a new
      conversation "any time soon". The current set function is renamed to
      set_cache to distinguish the two operations.
      This is a small preparation for a larger sync-rework.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      7e170c6e
    • S
      iio: ti_am335x_adc: Adjust the closing bracket in tiadc_read_raw() · fb7f8ce3
      Sebastian Andrzej Siewior 提交于
      It somehow looks like the ending bracket belongs to the if statement but
      it does belong to the while loop. This patch moves the bracket where it
      belongs.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      fb7f8ce3
  14. 09 11月, 2013 1 次提交
  15. 24 10月, 2013 1 次提交
  16. 17 10月, 2013 1 次提交
  17. 23 9月, 2013 3 次提交
  18. 22 9月, 2013 1 次提交
  19. 21 9月, 2013 1 次提交
  20. 04 8月, 2013 1 次提交
  21. 22 7月, 2013 1 次提交
  22. 06 7月, 2013 1 次提交
  23. 13 6月, 2013 8 次提交
  24. 12 6月, 2013 1 次提交
  25. 18 3月, 2013 1 次提交
  26. 04 1月, 2013 1 次提交
    • G
      Drivers: iio: remove __dev* attributes. · fc52692c
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, and __devexit
      from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Jonathan Cameron <jic23@cam.ac.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc52692c