linux-toradex.git/drivers/iio/magnetometer, branch v4.9.7

iio: magn: ak8974: remove .owner field for driver

2016-08-29T19:12:10+00:00

Remove .owner field if calls are used which set it automatically.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: Wei Yongjun 
Acked-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: magn/ak8974: avoid unused function warning

2016-08-29T18:54:55+00:00

The ak8974_configure() function is used only from the PM code,
but that can be hidden when CONFIG_PM is disabled:

drivers/iio/magnetometer/ak8974.c:201:12: error: 'ak8974_configure' defined but not used [-Werror=unused-function]

This replaces the #ifdef with a __maybe_unused annotation, which
will work correctly in all configurations and avoid the warning,
as the compiler can now see where ak8974_configure is called from.

Signed-off-by: Arnd Bergmann 
Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Signed-off-by: Jonathan Cameron

iio: magnetometer: mag3110: claim direct mode during raw reads

2016-08-21T18:37:35+00:00

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during raw reads.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
Signed-off-by: Jonathan Cameron

iio: magn: add a driver for AK8974

2016-08-15T15:49:39+00:00

This adds a driver for the Asahi Kasei AK8974 and its sibling
AMI305 magnetometers. It was deployed on scale in 2009 on a
multitude of devices. It is distincly different from AK8973
and AK8975 and needs its own driver.

This patch is based on the long lost work of Samu Onkalo at Nokia,
who made a misc character device driver for the Maemo/MeeGo Nokia
devices, before the time of the IIO subsystem. It was mounted in e.g.
the Nokia N950, N8, N86, N97 etc. It is also mounted on the
ST-Ericsson HREF reference designs.

It works nicely in sysfs:

$ cat in_magn_x_raw && cat in_magn_y_raw && cat in_magn_z_raw
-55
-101
161

And with buffered reads using a simple HRTimer trigger:
$ generic_buffer -c10 -a -n ak8974 -t foo
iio device number being used is 3
iio trigger number being used is 2
No channels are enabled, enabling all channels
Enabling: in_magn_x_en
Enabling: in_magn_y_en
Enabling: in_magn_z_en
Enabling: in_timestamp_en
/sys/bus/iio/devices/iio:device3 foo
-58.000000 -102.000000 157.000000 946684970985321044
-60.000000 -98.000000 159.000000 946684971012237548
-60.000000 -106.000000 163.000000 946684971032257080
-62.000000 -94.000000 169.000000 946684971052185058
-58.000000 -98.000000 163.000000 946684971072204589
-54.000000 -100.000000 163.000000 946684971092224121
-53.000000 -103.000000 164.000000 946684971112731933
-50.000000 -102.000000 165.000000 946684971132232666
-61.000000 -101.000000 164.000000 946684971152191162
-57.000000 -99.000000 168.000000 946684971172210693
Disabling: in_magn_x_en
Disabling: in_magn_y_en
Disabling: in_magn_z_en
Disabling: in_timestamp_en

I cannot currently scale these raw values to gauss. This is
because of lack of documentation. I have sent a request for
a datasheet to Asahi Kasei.

The driver can optionally use a DRDY line IRQ to capture data,
else it will sleep and poll.

Cc: Samu Onkalo 
Cc: Sebastian Reichel 
Cc: Peter Meerwald-Stadler 
Tested-By: Sebastian Reichel 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: magn: ak8975: deploy runtime and system PM

2016-06-30T19:40:16+00:00

This adds runtime PM support to the AK8975 driver. It solves two
problems:

- After reading the first value the chip was left in MODE_ONCE,
  meaning (presumably) it may be consuming more power. Now the
  runtime PM hooks kick in and set it to POWER_DOWN.

- Regulators were simply enabled and left on, making it
  impossible to turn the power consuming regulators off because
  of the increased refcount. We now disable the regulators at
  autosuspend.

- We also handle system suspend: by using pm_runtime_force_suspend()
  and pm_runtime_force_resume() from the system PM sleep hooks,
  the runtime PM code is managing the power also for this case.
  It is currently not completely optimal: when the system resumes
  the AK8975 goes into active mode even if noone is going to use
  it: currently the force calls need to be paired, but the runtime
  PM people are working on making it possible to leave devices
  runtime suspended when coming back from sleep.

Inspired by my work on the BH1780 light sensor driver.

Signed-off-by: Linus Walleij 
Reviewed-by: Ulf Hansson 
Signed-off-by: Jonathan Cameron

iio: magn: ak8975: make sure to power down at remove()

2016-06-30T19:40:12+00:00

The code was not powering the magnetometer down properly at
remove(): just cutting the regulators without first setting the
device in power off mode. Fix this.

Signed-off-by: Linus Walleij 
Reviewed-by: Ulf Hansson 
Signed-off-by: Jonathan Cameron

iio: magn: ak8975: allow a delay after enabling regulators

2016-06-30T19:40:04+00:00

The datasheet actually specifies that we need to wait atleast
500us after powering on the device before trying to set mode.

Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: magn: ak8975: refactor regulator handlers

2016-06-30T19:39:58+00:00

Move the regulator_get() calls directly into the probe() function,
keep only the power_on()/power_off() functions to flick the
regulators on/off.

Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: magn: ak8975: add Vid regulator

2016-06-30T19:39:51+00:00

The AK8975 has two power sources: Vdd (analog voltage supply)
and Vid (digital voltage supply). Optionally also obtain the Vid
supply regulator and enable it.

If an error occurs when enabling one of the regulators: bail out.

Cc: Gregor Boirie 
Cc: Richard Leitner 
Cc: Krzysztof Kozlowski 
Cc: Lars-Peter Clausen 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: magn: ak8975: fix regulator usage

2016-06-30T19:39:43+00:00

IS_ERR_OR_NULL() should never be used with regulators because
a NULL pointer may be a perfectly valid dummy regulator

We should always succeed to fetch and enable a regulator, but
it may be a dummy. That is fine, so bail out for any real
errors or probe deferrals

Include the error code in the warning print so we know what
kind of problem we're dealing with (for example it is nice to
see if it is a probe deferral).

As we will bail out of probe if the regulator is erroneous,
just issue regulator_disable() on the poweroff path: it will
succeed.

Cc: Mark Brown 
Cc: Lars-Peter Clausen Lars-Peter Clausen 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron