Jonathan Cameron [Wed, 20 Mar 2013 22:21:00 +0000 (22:21 +0000)]
hwmon: Move the IIO client driver for hwmon out of staging
This driver uses channel maps, defined either through device tree
or platform data, to create a hwmon driver which acts as a client
for the underlying IIO device channels. Thus a general purpose
IIO adc driver can be used to provide hardware monitoring using a subset
of its channels.
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net>
--
The only non move changes here concern the description and changes to the
dependencies to IIO explicit and hwmon implicit.
I'm proposing moving this into hwmon on the basis of placing drivers
based on what they provide rather than what their underlying hardware
is.
Guenter Roeck [Wed, 20 Mar 2013 15:52:00 +0000 (15:52 +0000)]
staging/iio: iio_hwmon: Use device tree node name for hwmon name attribute
So far, all instances of iio_hwmon set their hwmon name attribute
to "iio_hwmon", which is not very descriptive. Set it to the device tree
node name if available, and only revert to iio_hwmon otherwise.
Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Doug Anderson [Wed, 13 Mar 2013 20:40:00 +0000 (20:40 +0000)]
iio: adc: Add dt support for turning on the phy in exynos-adc
Without this change the exynos adc controller needed to have its phy
enabled in some out-of-driver C code. Add support for specifying the
phy enable register by listing it in the reg list.
Signed-off-by: Doug Anderson <dianders@chromium.org> Tested-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The driver already claims to support scale reporting in its channel spec, but
doesn't actually implement this yet. This patch uses the regulator API to get
the reference voltage and calculates the scale based on that. The patch also
moves the global configuration bits into a field in the ad7923_state struct,
since depending on the RANGE bit, the range goes either from 0 to VREF or from 0
to 2 * VREF. So we need to know the setting of the RANGE bit when calculating
the scale.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Patrick Vasseur <patrick.vasseur@c-s.fr> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: events: Make iio_push_event() IRQ context save
Currently it is not save to call iio_push_event() from hard IRQ context since
the IIO event code uses spin_lock()/spin_unlock() and it is not save to mix
calls to spin_lock()/spin_unlock() from different contexts on the same lock.
E.g. if the lock is being held in iio_event_chrdev_read() and an interrupts
kicks in and the interrupt handler calls iio_push_event() we end uo with a
deadlock.
This patch updates iio_push_event() to use spin_lock_irqsave()/
spin_unlock_irqstrestore(), since it can be called from both IRQ and non-IRQ
context. All other other users of the lock, which are always run in non-IRQ
context, are updated to spin_lock_irq()/spin_unlock_irq().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Jonathan Cameron [Tue, 19 Feb 2013 21:10:30 +0000 (21:10 +0000)]
iio: Add broken out info_mask fields for shared_by_type and separate
This simplifies the code, removes an extensive layer of 'helper' macros
and gives us twice as much room to play with in these masks before we
have any need to be clever.
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Lars-Peter Clausen <lars@metafoo.de>
iio: adc: add exynos adc driver under iio framwork
This patch adds New driver to support:
1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
and future SoCs from Samsung
2. Add ADC driver under iio/adc framework
3. Also adds the Documentation for device tree bindings
Ian Abbott [Fri, 15 Mar 2013 13:39:52 +0000 (13:39 +0000)]
staging: comedi: ni_labpc: fix common detach
`labpc_common_detach()` calls `comedi_pci_disable()` unconditionally.
That's okay for PCI devices and harmless for ISA devices (as the
`hw_dev` member will be NULL so `comedi_to_pci_dev()` will return NULL
and `comedi_pci_disable()` checks for that), but it is disastrous for
PCMCIA devices. Those are managed by the "ni_labpc_cs" module but it
calls this `labpc_common_detach()` and the `hw_dev` member will be
pointing to the `struct device` embedded in a `struct pcmcia_device` in
that case. That's enough to confuse `comedi_pci_disable()` into
thinking it's a valid PCI device to be disabled.
Use the private board information (`thisboard`) to make sure it is a PCI
device before calling `comedi_pci_disable()`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 15 Mar 2013 13:15:36 +0000 (13:15 +0000)]
staging: comedi: remove unneeded settings of `dev->iobase`
Some PCI drivers use the "spare" `iobase` member of `struct
comedi_device` as a flag to indicate that the call to
`comedi_pci_enable()` was successful. This is no longer necessary now
that `comedi_pci_enable()` and `comedi_pci_disable()` use the
`ioenabled` member of `struct comedi_device` themselves to keep track of
what needs to be done.
Remove the unnecessary assignments to the `iobase` member in the
relevant drivers.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 15 Mar 2013 13:15:35 +0000 (13:15 +0000)]
staging: comedi: add 'ioenabled' flag to device
Add 1-bit bit-field member `ioenabled` of type `bool` to `struct
comedi_device`. Use this to keep track of whether a PCI device and its
BARs have been successfully enabled by `comedi_pci_enable()`. This
avoids overloading the meaning of the `iobase` member which is used by
several drivers to hold the base port I/O address of a board's "main"
registers. Other drivers using MMIO use `iobase` as a flag to indicate
that the preceding call to `comedi_pci_enable()` was successful. They
no longer need to do that.
The name `ioenabled` is intended to be PCI-agnostic so it can be used
for similar purposes by non-PCI drivers.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 15 Mar 2013 13:15:34 +0000 (13:15 +0000)]
staging: comedi: make 'in_request_module' a bool bit-field
Change the `in_request_module` member of `struct comedi_device` to a
1-bit bit-field of type `bool` and move it into a suitable hole in the
data type to save a few bytes. Change the assigned values to `true` and
`false`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 15 Mar 2013 13:15:33 +0000 (13:15 +0000)]
staging: comedi: make 'dev->attached' a bool bit-field
Change the `attached` member of `struct comedi_device` to a 1-bit
bit-field of type `bool`. Change assigned values to `true` and `false`
and replace or remove comparison operations with simple boolean tests.
We'll put some extra bit-fields in the gap later to save space.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 15 Mar 2013 11:16:36 +0000 (11:16 +0000)]
staging: comedi: ni_660x: support NI PXI-6624
Florent Boudet reports success using a NI PXI-6624 board with a
trivially modified version of the "ni_660x" driver (addition to the PCI
device ID table and comedi board table). He did this with the
out-of-tree Comedi drivers at www.comedi.org, but it applies equally to
the in-tree "staging" drivers.
He reports the PXI-6624 is basically the same as the PXI-6602, but with
isolated channels and external voltage source.
Add support for NI PXI-6224 to the "ni_660x" driver.
(Maybe the driver should be renamed to "ni_66xx"?)
Ian Abbott [Fri, 15 Mar 2013 10:32:12 +0000 (10:32 +0000)]
staging: comedi: adv_pci_dio: restore PCI-1753E support
Back in the old days (before "staging") when Comedi only supported
manual configuration of devices, the "adv_pci_dio" driver supported both
PCI-1753 ("pci1753") and PCI-1753E ("pci1753e"). In actual fact,
"pci1753e" is just a PCI-1753 connected by a ribbon cable to a PCI-1753E
expansion card, which is plugged into a PCI slot but is not a PCI device
itself. Now that the "adv_pci_dio" driver only supports automatic
configuration of devices and the main "comedi" module no longer allows
auto-configuration to be disabled, a PCI-1753 with a PCI-1753E expansion
card is always treated as an unexpanded PCI-1753 ("pci1753") and there
is no way to override it. (Recently, an undefined macro
`USE_PCI1753E_BOARDINFO` was used to make the driver switch to
supporting "pci1753e" instead of "pci1753", but this is less than
ideal.)
Advantech has their own Linux (non-Comedi) driver for the PCI-1753 which
detects whether the PCI-1753E expansion card is connected to the
PCI-1753 by fiddling with a register at offset 53 from the main
registers base.
Use Advantech's test in our "adv_pci_dio" driver. If the board appears
to be a PCI-1753 ("pci1753"), check if the expansion card appears to be
present, and if so, treat the device as a PCI-1753 plus PCI-1753E
expansion card ("pci1753e").
Also, get rid of `enum dio_boardid` (`BOARD_...` enum values) which was
added recently and just use the older `TYPE_...` enum values from `enum
hw_cards_id` instead as the mapping is now 1-to-1.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Yongjun [Fri, 15 Mar 2013 09:20:08 +0000 (17:20 +0800)]
staging: sep: fix possible memory leak in sep_prepare_input_dma_table()
'lli_array_ptr' etc. are malloced in sep_prepare_input_dma_table() and should
be freed before leaving from the error handling case, otherwise it will cause
memory leak.
projects / linux-beck.git / log