Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 4月, 2014 3 次提交
  3. 26 4月, 2014 2 次提交
    • L
      iio: st_sensors: move regulator retrieveal to core · ea7e586b
      由 Linus Walleij 提交于 
      Currently the pressure sensor has code to retrieve and enable two
regulators for Vdd and Vdd IO, but actually these voltage inputs
are found on all of these ST sensors, so move the regulator
handling to the core and make sure all the ST sensors call these
functions on probe() and remove() to enable/disable power.

Here also mover over to obtaining the regulator from the *parent*
device of the IIO device, as the IIO device is created on-the-fly
in this very subsystem it very unlikely evert have any regulators
attached to it whatsoever. It is much more likely that the parent
is a platform device, possibly instantiated from a device tree,
which in turn have Vdd and Vdd IO supplied assigned to it.

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      ea7e586b
    • L
      iio: st_sensors: announce registered sensors · 4f544ced
      由 Linus Walleij 提交于 
      It is pretty helpful to know already from dmesg that a certain
device is successfully registered, instead of having to browse
sysfs to see if it's actually there.

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      4f544ced
  5. 24 4月, 2014 1 次提交
  7. 12 4月, 2014 1 次提交
  9. 29 3月, 2014 2 次提交
    • S
      iio: imu: inv_mpu6050: Add compatibity with MPU6500 · 6f174fd3
      由 Srinivas Pandruvada 提交于 
      Adding MPU6500 in target list for this driver.

Description:
Source
Document: MPU-6500 Register Map and Descriptions Revision 2.1
Section 3: Register Map

This section describes difference in terms device programmability
between MPU6050 and MPU6500.
These are different registers, which differs between MPU6050 and
MPU6500.

Addr	Name
---------------------
1E 	LP_ACCEL_ODR
6C	PWR_MGMT_2
77	XA_OFFSET_H
78	XA_OFFSET_L
7A	YA_OFFSET_H
7B	YA_OFFSET_L
7D	ZA_OFFSET_H
7E	ZA_OFFSET_L

But the current MPU6050 driver doesn't use registers which are different
except PWR_MGMT_2. The difference is support of "LP_WAKE_CTRL" at bit6-7
in MPU6050 mode. In MPU6500 they are not defined.
In current mpu6050 driver, only values used for this register are for
standby mode for gyro and accelerometer.
In both case frequency of wakeups is set to default and not using
bit 6-7.

So this driver van as well support MPU6500. In addition MPU6500 can
run MPU6050 mode by changing device trim settings.

So changing config comments to allow MPU6500 to use this driver.
When the driver is enhanced to support more functions, i2c driver
data INV_MPU6500 or "WHO_AM_I" register can be used to add additional
functionality.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      6f174fd3
    • S
      iio: ak8975: Added ACPI enumeration · d913971e
      由 Srinivas Pandruvada 提交于 
      Added capability so that this device can be enumerated via ACPI.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      d913971e
  11. 22 3月, 2014 3 次提交
  13. 19 3月, 2014 1 次提交
  15. 18 3月, 2014 1 次提交
  17. 17 3月, 2014 6 次提交
  19. 16 3月, 2014 1 次提交
  21. 15 3月, 2014 2 次提交
  23. 09 3月, 2014 1 次提交
  25. 07 3月, 2014 1 次提交
    • A
      iio: adc: at91_adc: Repair broken platform_data support · 467a44b0
      由 Alexandre Belloni 提交于 
      Trying to use the at91_adc driver while not using device tree is ending up in a
kernel crash:

Unable to handle kernel NULL pointer dereference at virtual address 00000004
[...]
[<c01f3510>] (at91_adc_probe) from [<c0183828>] (platform_drv_probe+0x18/0x48)
[<c0183828>] (platform_drv_probe) from [<c01824a4>] (driver_probe_device+0x100/0x218)
[<c01824a4>] (driver_probe_device) from [<c0182648>] (__driver_attach+0x8c/0x90)
[<c0182648>] (__driver_attach) from [<c0180de4>] (bus_for_each_dev+0x58/0x88)
[<c0180de4>] (bus_for_each_dev) from [<c0181c7c>] (bus_add_driver+0xd4/0x1d4)
[<c0181c7c>] (bus_add_driver) from [<c0182c40>] (driver_register+0x78/0xf4)
[<c0182c40>] (driver_register) from [<c0008998>] (do_one_initcall+0xe8/0x14c)
[<c0008998>] (do_one_initcall) from [<c02f0b50>] (kernel_init_freeable+0xec/0x1b4)
[<c02f0b50>] (kernel_init_freeable) from [<c022acdc>] (kernel_init+0x8/0xe4)
[<c022acdc>] (kernel_init) from [<c0009670>] (ret_from_fork+0x14/0x24)

This is because the at91_adc_caps structure is mandatory but is not filled when
using platform_data. Correct that by using an id_table. It ensues that the
driver will not match "at91_adc" anymore but it was crashing anyway.

Fixes: c4601666 (iio: at91: ADC start-up time calculation changed since at91sam9x5)
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Tested-by: NJosh Wu <josh.wu@atmel.com>
Acked-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      467a44b0
  27. 03 3月, 2014 1 次提交
  29. 02 3月, 2014 1 次提交
    • L
      iio:adc: Add Xilinx XADC driver · bdc8cda1
      由 Lars-Peter Clausen 提交于 
      The Xilinx XADC is a ADC that can be found in the series 7 FPGAs from Xilinx.
The XADC has a DRP interface for communication. Currently two different
frontends for the DRP interface exist. One that is only available on the ZYNQ
family as a hardmacro in the SoC portion of the ZYNQ. The other one is available
on all series 7 platforms and is a softmacro with a AXI interface. This driver
supports both interfaces and internally has a small abstraction layer that hides
the specifics of these interfaces from the main driver logic.

The ADC has a couple of internal channels which are used for voltage and
temperature monitoring of the FPGA as well as one primary and up to 16 channels
auxiliary channels for measuring external voltages. The external auxiliary
channels can either be directly connected each to one physical pin on the FPGA
or they can make use of an external multiplexer which is responsible for
multiplexing the external signals onto one pair of physical pins.

The voltage and temperature monitoring channels also have an event capability
which allows to generate a interrupt when their value falls below or raises
above a set threshold.

Buffered sampling mode is supported by the driver, but only for AXI-XADC since
the ZYNQ XADC interface does not have capabilities for supporting buffer mode
(no end-of-conversion interrupt). If buffered mode is supported the driver will
register two triggers. One "xadc-samplerate" trigger which will generate samples
with the configured samplerate. And one "xadc-convst" trigger which will
generate one sample each time the CONVST (conversion start) signal is asserted.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      bdc8cda1
  31. 01 3月, 2014 1 次提交
  33. 26 2月, 2014 1 次提交
  35. 23 2月, 2014 1 次提交
    • L
      iio:event: Fix and cleanup locking · b91accaf
      由 Lars-Peter Clausen 提交于 
      The event code currently holds a spinlock with IRQs disabled while calling
kfifo_to_user(). kfifo_to_user() can generate a page fault though, which means
we have to be able to sleep, which is not possible if the interrupts are
disabled. The good thing is that kfifo handles concurrent read and write access
just fine as long as there is only one reader and one writer, so we do not any
locking to protect against concurrent access from the read and writer thread. It
is possible though that userspace is trying to read from the event FIFO from
multiple concurrent threads, so we need to add locking to protect against this.
This is done using a mutex. The mutex will only protect the kfifo_to_user()
call, it will not protect the waitqueue. This means that multiple threads can be
waiting for new data and once a new event is added to the FIFO all waiting
threads will be woken up. If one of those threads is unable to read any data
(because another thread already read all the data) it will go back to sleep. The
only remaining issue is that now that the clearing of the BUSY flag and the
emptying of the FIFO does no longer happen in one atomic step it is possible
that a event is added to the FIFO after it has been emptied and this sample will
be visible the next time a new event file descriptor is created. To avoid this
rather move the emptying of the FIFO from iio_event_chrdev_release to
iio_event_getfd().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      b91accaf
  37. 22 2月, 2014 3 次提交
  39. 18 2月, 2014 7 次提交