Signed-off-by: Tomas Novotny <tomas@novotny.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

MCP47x6 chip supports selection of a voltage reference (VDD, VREF buffered
or unbuffered). MCP4725 doesn't have this feature thus the eventual setting
is ignored and user is warned.

The setting is stored only in the volatile memory of the chip. You need to
manually store it to the EEPROM of the chip via 'store_eeprom' sysfs entry.
Signed-off-by: Tomas Novotny <tomas@novotny.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Signed-off-by: Tomas Novotny <tomas@novotny.cz>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Number 2 is referencing to the settings with the largest available
resistor.

No functional change.
Signed-off-by: Tomas Novotny <tomas@novotny.cz>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Currently, this driver ignores all errors from regulator_get(). The way
it is now, it also breaks probe deferral (EPROBE_DEFER). The correct
behavior is to propagate the error to the upper layers so they can
handle it accordingly.

Rework the regulator handling so that it matches the standard behavior.
If the specific design uses a static always-on regulator and does not
explicitly specify it, regulator_get() will return the dummy regulator.
Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

The name passed to devm_regulator_get() should match the name of the
supply as specified in the device datasheet. The supply on this device
is called 'AVcc' while currently, the driver uses just 'vcc'.

Use 'avcc' to specify the supply voltage since it is custom to use the
lower-caps version of the datasheet name.
Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Currently the ad7606 buffer handling code resides in its own source file.
But this file contains only 4 small functions of which half are just
wrappers around other functions. Buffer support is also always enabled for
this driver, so move them over to the main source file. This reduces the
amount of boilerplate code.

Also rename the main function from ad7606_core.c to ad7606.c since there is
only a single file now.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Convert the ad7606 driver away from the deprecated legacy GPIO API and use
the new GPIO descriptor API.

This also means that the platform data struct is now empty and can be
removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Currently the ad7606 driver installs the same function for the hard-irq and
threaded trigger handlers. This was introduced in commit 1caf7cb4
("staging:iio:adc:ad7606 Convert to new channel registration method Update
Add missing call to iio_trigger_notify_done() Set pollfunc top and bottom
half handler"). Unfortunately the commit message does not mention why this
was done and Michael does not remember either.

Since the trigger handler function is idempotent (set a GPIO to 1) running
it twice does not do any harm, but is simply not necessary either. So set
the threaded trigger handler for the driver to NULL.

While we are at it also remove the function description comment that does
no say anything that can't be derived from the function name itself.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Currently the common remove function takes a struct iio_dev *. This
parameter is retrieved by the individual driver remove functions by calling
get_drvdata() on their device. To simplify the code let the common remove
function directly take a struct dev * and do the IIO device in retrieval
the common remove function.

This also aligns the interface with the common probe function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

The common probe function for the ad7606 currently returns a struct iio_dev
pointer. The returned value is not used by the individual driver probe
functions other than for error checking.

Let the common probe function return a int instead to report the error
value directly (or 0 on success). This allows to simplify the code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Both the platform_device and SPI driver call set_drvdata() at the end of
their probe function. Move this into the common probe() function to reduce
duplicated code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Both the periodic buffer based and one-shot sysfs based capture methods
share a large portion of their code. Factor this out into a common helper
function.

Also provide a comment that better explains in more detail what is going on
in the capture function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Currently the ad7606 driver dynamically allocates and frees a transfer
buffer each time a sample capture is performed in buffered mode, which
introduces unnecessary overhead. The driver state struct already contains a
buffer that is used for transfers in one-shot mode. This buffer is large
enough to hold all samples, but not the timestamp that might be present in
buffered mode. Extend the buffer size to be able to contain the timestamp
and update the buffered capture function to use this buffer.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Currently the ad7606 driver uses a value of 0 for the oversampling ratio to
express that no oversampling is done. Strictly speaking this means though
that no data capture is done at all. Instead change the driver to use a
value of 1, this is in accordance with what other drivers do and what the
IIO spec suggests.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Currently the ad7606 driver prints a error message to the kernel log when
an application writes an invalid value to a sysfs attribute. While for
initial driver development and testing this might be useful it is quite
disadvantageous in a production environment. The write() call to the sysfs
attribute will already return an error if the value was invalid so the
application is aware that the operation failed. And generally speaking it
is impossible for an application to reliably match a log message in the
kernel log to a specific operation it performed, so the message becomes
just noise and might distract from more critical messages.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

While for some very selected setups it might be useful to be able to
provide default configuration data via the platform data, generally this
becomes very impractical as the number of configuration options increases.
So the general policy is to use the power-on default values of the device
and let the application using the device configure it according to its
needs.

Implement this scheme for the ad7606 driver by removing support for
specifying a default configuration via the platform data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

The name field in the ad7606_chip_info struct is set to the same value as
the as the name field in the corresponding {platform,spi}_device_id table
entry. Remove it from the ad7606_chip_info struct and pass the name from
the ID to the probe function. This slightly reduces the size of the
chip_info table and adding new entries requires less boilerplate.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Remove the int_vref_mv field from the ad7606_chip_info struct since the
field is never used by the driver. The value is also the same for all
derivatives of this chip, so if it will ever be used in the driver a
constant value will work just fine.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Remove extra parentheses introduced in commit <73e176a tools: iio:
iio_generic_buffer: add -A to force-enable all channels>.
Suggested-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Replace the type of 'force' flag from int to bool and at the same time
rename it to 'force_autochannels' for better readability.
Suggested-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Add support to STM HTS221 humidity + temperature sensor

http://www.st.com/resource/en/datasheet/hts221.pdf

- continuous mode support
- i2c support
- spi support
- trigger mode support
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during all raw write operations.
Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during required raw read cases.
Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Now the driver is in a reasonable state, lets get it (finally) out
of staging.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Basic tidy up of comments to bring them into a standard style.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Tidied up where checkpatch warning suppressions doesn't effect the
readability of the code.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Previously the device was exposed to userspace and in kernel consumers
before the interrupts had been configured. As nothing stopped them being
enabled in the interval this could cause unhandled interrupts.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

There seems little point in being able to query the part revision number
via sysfs.  Hence just put it in the kernel logs during probe incase
anyone ever wants to know.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

This is now represented by the standard 3db filter frequency controls.
Things get complex wrt to the sampling frequency as these modes change
but that is fine under the IIO ABI where any value is allowed to effect
any other.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Also includes an available attribute.  The ordering of values appears
a bit random, but as the ABI doesn't specify this and we already have
both rising and falling lists I think this is fine.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Given the introduction of IIO_NO_MOD was prior to the first submission
prior to IIO entering staging this has been broken for a while.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Driving towards getting rid of the non standard mode control interface.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Introduce some more masks and generally drive towards consistent naming.
Note the small indents used to indicate parts of registers + parts of
multiplexed registers.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

This is an approach used in some newer drivers as it exposes the
compound channel events to the core rather than hiding their control
in sysfs attributes entirely via the driver.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

In a similar fashion to other newer drivers (e.g. ti_am335x), instead
of using the hardware buffer support in IIO to directly access the hardware
fifo, insert a software fifo and feed that from the hardware one when
interrupts occur.  This gives a simpler structure to the data flows and
allows more flexibility over how often data is shipped to userspace etc.

This was also the only direct user of the simplistic generalization found
in ring_hw.h so that header is removed.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

For now we support only the 50% watershed interrupt and start and stop it
as part of the buffer bring up.  The 75% case may come back in future.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>

Not clearing the stuff_to_read flag can lead to a false flag being set
on restarting the buffer if the data was not all read the previous time.

The size of the scan is needed to ensure the function
iio_buffer_read_first_n_outer actually tries to read the data.

This stuff has been broken for some time so not stable material.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>