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

iio: magnetometer: separate the values of attributes based on their usage type for HID compass sensor

2016-11-24T20:41:30+00:00

There are 2 usage types (Magnetic Flux and Heading data field) for HID
compass sensor, thus the values of offset, scale, and sensitivity should
be separated according to their respective usage type. The changes made
are as below:
1. Hysteresis: A struct hid_sensor_common rot_attributes is created in
struct magn_3d_state to contain the sensitivity for IIO_ROT.
2. Scale: scale_pre_decml and scale_post_decml are separated for IIO_MAGN
and IIO_ROT.
3. Offset: Same as scale, value_offset is separated for IIO_MAGN and
IIO_ROT.

For sensitivity, HID_USAGE_SENSOR_ORIENT_MAGN_FLUX and
HID_USAGE_SENSOR_ORIENT_MAGN_HEADING are used for sensivitity fields based
on the HID Sensor Usages specifications. Hence, these changes are added on
the sensitivity field.

Signed-off-by: Ooi, Joyce 
Acked-by: Srinivas Pandruvada 
Signed-off-by: Jonathan Cameron

iio: magn: st_magn: inline per-sensor data

2016-11-12T15:45:37+00:00

We have #defines for all the individual sensor registers and
value/mask pairs #defined at the top of the file and used at
exactly one spot.

This is usually good if the #defines give a meaning to the
opaque magic numbers.

However in this case, the semantic meaning is inherent in the
name of the C99-addressable fields, and that means duplication
of information, and only makes the code hard to maintain since
you every time have to add a new #define AND update the site
where it is to be used.

Get rid of the #defines and just open code the values into the
appropriate struct elements. Make sure to explicitly address
the .hz and .value fields in the st_sensor_odr_avl struct
so that the meaning of all values is clear.

This patch is purely syntactic should have no semantic effect.

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

iio: magnetometer: ak8974: small endianness fixes

2016-10-03T20:30:00+00:00

Fixes two cases of 'cast to restricted __le16' as reported by sparse.

Signed-off-by: Ico Doornekamp 
Signed-off-by: Jonathan Cameron

drivers: iio: magnetometer: Fix sparse endianness warnings cast to restricted __be16

2016-09-27T20:08:45+00:00

Fix the following sparse endianness warnings:

drivers/iio/magnetometer/ak8975.c:716:16: warning: cast to restricted __le16
drivers/iio/magnetometer/ak8975.c:837:19: warning: cast to restricted __le16
drivers/iio/magnetometer/ak8975.c:838:19: warning: cast to restricted __le16
drivers/iio/magnetometer/ak8975.c:839:19: warning: cast to restricted __le16

Signed-off-by: Sandhya Bankar 
Signed-off-by: Jonathan Cameron

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