Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391334 > unrolled thread

[RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings

Started byCrestez Dan Leonard <leonard.crestez@intel.com>
First post2016-04-29 21:10 +0200
Last post2016-05-03 13:40 +0200
Articles 7 on this page of 27 — 6 participants

Back to article view | Back to linux.kernel

Contents

  [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
    [RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
      Re: [RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:40 +0200
        Re: [RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-05-05 14:40 +0200
          Re: [RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master Rob Herring <robh+dt@kernel.org> - 2016-05-05 15:20 +0200
      Re: [RFC 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master Peter Rosin <peda@axentia.se> - 2016-05-02 17:40 +0200
    [PATCH 4/7] iio: inv_mpu6050: Cache non-volatile bits of user_ctrl Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
      Re: [PATCH 4/7] iio: inv_mpu6050: Cache non-volatile bits of  user_ctrl Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:40 +0200
    [PATCH 6/7] iio: inv_mpu6050: Check channel configuration on preenable Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
      Re: [PATCH 6/7] iio: inv_mpu6050: Check channel configuration on  preenable Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:30 +0200
        Re: [PATCH 6/7] iio: inv_mpu6050: Check channel configuration on  preenable Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-05-03 15:10 +0200
          Re: [PATCH 6/7] iio: inv_mpu6050: Check channel configuration on  preenable Jonathan Cameron <jic23@kernel.org> - 2016-05-04 16:40 +0200
            Re: [PATCH 6/7] iio: inv_mpu6050: Check channel configuration on  preenable Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-05-04 17:40 +0200
              Re: [PATCH 6/7] iio: inv_mpu6050: Check channel configuration on preenable Jonathan Cameron <jic23@jic23.retrosnub.co.uk> - 2016-05-04 20:30 +0200
    [PATCH 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c directly Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
      Re: [PATCH 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c  directly Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:30 +0200
        Re: [PATCH 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c  directly Mark Brown <broonie@kernel.org> - 2016-05-02 17:30 +0200
    [RFC 7/7] iio: inv_mpu6050: Add support for external sensors Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
      Re: [RFC 7/7] iio: inv_mpu6050: Add support for external sensors Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:40 +0200
    [PATCH 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
      Re: [PATCH 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in  inv_reset_fifo Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:30 +0200
    [PATCH 2/7] iio: inv_mpu6050: Initial regcache support Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-04-29 21:10 +0200
      Re: [PATCH 2/7] iio: inv_mpu6050: Initial regcache support Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:40 +0200
    Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external  readings Jonathan Cameron <jic23@kernel.org> - 2016-05-01 23:40 +0200
      Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external  readings Mark Brown <broonie@kernel.org> - 2016-05-02 17:30 +0200
        Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external  readings Crestez Dan Leonard <leonard.crestez@intel.com> - 2016-05-03 13:30 +0200
          Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external  readings Mark Brown <broonie@kernel.org> - 2016-05-03 13:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1391906 — Re: [PATCH 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo

FromJonathan Cameron <jic23@kernel.org>
Date2016-05-01 23:30 +0200
SubjectRe: [PATCH 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo
Message-ID<ru76c-86o-53@gated-at.bofh.it>
In reply to#1391341
On 29/04/16 20:02, Crestez Dan Leonard wrote:
> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Looks fine to me...
> ---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c    | 13 +++++++-----
>  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c |  3 ++-
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> index 8455af0..3fc0b71 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> @@ -41,7 +41,8 @@ int inv_reset_fifo(struct iio_dev *indio_dev)
>  	struct inv_mpu6050_state  *st = iio_priv(indio_dev);
>  
>  	/* disable interrupt */
> -	result = regmap_write(st->map, st->reg->int_enable, 0);
> +	result = regmap_update_bits(st->map, st->reg->int_enable,
> +				    INV_MPU6050_BIT_DATA_RDY_EN, 0);
>  	if (result) {
>  		dev_err(regmap_get_device(st->map), "int_enable failed %d\n",
>  			result);
> @@ -68,8 +69,9 @@ int inv_reset_fifo(struct iio_dev *indio_dev)
>  	/* enable interrupt */
>  	if (st->chip_config.accl_fifo_enable ||
>  	    st->chip_config.gyro_fifo_enable) {
> -		result = regmap_write(st->map, st->reg->int_enable,
> -				      INV_MPU6050_BIT_DATA_RDY_EN);
> +		result = regmap_update_bits(st->map, st->reg->int_enable,
> +					    INV_MPU6050_BIT_DATA_RDY_EN,
> +					    INV_MPU6050_BIT_DATA_RDY_EN);
>  		if (result)
>  			return result;
>  	}
> @@ -92,8 +94,9 @@ int inv_reset_fifo(struct iio_dev *indio_dev)
>  
>  reset_fifo_fail:
>  	dev_err(regmap_get_device(st->map), "reset fifo failed %d\n", result);
> -	result = regmap_write(st->map, st->reg->int_enable,
> -			      INV_MPU6050_BIT_DATA_RDY_EN);
> +	result = regmap_update_bits(st->map, st->reg->int_enable,
> +				    INV_MPU6050_BIT_DATA_RDY_EN,
> +				    INV_MPU6050_BIT_DATA_RDY_EN);
>  
>  	return result;
>  }
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> index e8818d4..1a6bad3 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> @@ -69,7 +69,8 @@ static int inv_mpu6050_set_enable(struct iio_dev *indio_dev, bool enable)
>  		if (result)
>  			return result;
>  
> -		result = regmap_write(st->map, st->reg->int_enable, 0);
> +		result = regmap_update_bits(st->map, st->reg->int_enable,
> +					INV_MPU6050_BIT_DATA_RDY_EN, 0);
>  		if (result)
>  			return result;
>  
>

[toc] | [prev] | [next] | [standalone]

#1391342 — [PATCH 2/7] iio: inv_mpu6050: Initial regcache support

FromCrestez Dan Leonard <leonard.crestez@intel.com>
Date2016-04-29 21:10 +0200
Subject[PATCH 2/7] iio: inv_mpu6050: Initial regcache support
Message-ID<rtlXA-2Jp-25@gated-at.bofh.it>
In reply to#1391334
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
---
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 47 ++++++++++++++++++++++++++++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c  |  5 ----
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |  1 +
 drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c  |  5 ----
 4 files changed, 48 insertions(+), 10 deletions(-)

diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index b269b37..5918c23 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -116,6 +116,53 @@ static const struct inv_mpu6050_hw hw_info[] = {
 	},
 };
 
+static bool inv_mpu6050_volatile_reg(struct device *dev, unsigned int reg)
+{
+	if (reg >= INV_MPU6050_REG_RAW_ACCEL && reg < INV_MPU6050_REG_RAW_ACCEL + 6)
+		return true;
+	if (reg >= INV_MPU6050_REG_RAW_GYRO && reg < INV_MPU6050_REG_RAW_GYRO + 6)
+		return true;
+	switch (reg) {
+	case INV_MPU6050_REG_TEMPERATURE:
+	case INV_MPU6050_REG_TEMPERATURE + 1:
+	case INV_MPU6050_REG_USER_CTRL:
+	case INV_MPU6050_REG_PWR_MGMT_1:
+	case INV_MPU6050_REG_FIFO_COUNT_H:
+	case INV_MPU6050_REG_FIFO_COUNT_H + 1:
+	case INV_MPU6050_REG_FIFO_R_W:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static bool inv_mpu6050_precious_reg(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case INV_MPU6050_REG_FIFO_R_W:
+		return true;
+	default:
+		return false;
+	}
+}
+
+/*
+ * Common regmap config for inv_mpu devices
+ *
+ * The current volatile/precious registers are common among supported devices.
+ * When that changes the volatile/precious callbacks should go through the
+ * inv_mpu6050_reg_map structs.
+ */
+const struct regmap_config inv_mpu_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+
+	.cache_type = REGCACHE_RBTREE,
+	.volatile_reg = inv_mpu6050_volatile_reg,
+	.precious_reg = inv_mpu6050_precious_reg,
+};
+EXPORT_SYMBOL_GPL(inv_mpu_regmap_config);
+
 int inv_mpu6050_switch_engine(struct inv_mpu6050_state *st, bool en, u32 mask)
 {
 	unsigned int d, mgmt_1;
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index 1a424a6..1a8d1a5 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -20,11 +20,6 @@
 #include <linux/module.h>
 #include "inv_mpu_iio.h"
 
-static const struct regmap_config inv_mpu_regmap_config = {
-	.reg_bits = 8,
-	.val_bits = 8,
-};
-
 /*
  * The i2c read/write needs to happen in unlocked mode. As the parent
  * adapter is common. If we use locked versions, it will fail as
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
index 47ca25b..297b0ef 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
@@ -291,3 +291,4 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
 int inv_mpu_core_remove(struct device *dev);
 int inv_mpu6050_set_power_itg(struct inv_mpu6050_state *st, bool power_on);
 extern const struct dev_pm_ops inv_mpu_pmops;
+extern const struct regmap_config inv_mpu_regmap_config;
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
index 190a4a5..b3bd977 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
@@ -17,11 +17,6 @@
 #include <linux/iio/iio.h>
 #include "inv_mpu_iio.h"
 
-static const struct regmap_config inv_mpu_regmap_config = {
-	.reg_bits = 8,
-	.val_bits = 8,
-};
-
 static int inv_mpu_i2c_disable(struct iio_dev *indio_dev)
 {
 	struct inv_mpu6050_state *st = iio_priv(indio_dev);
-- 
2.5.5

[toc] | [prev] | [next] | [standalone]

#1391913 — Re: [PATCH 2/7] iio: inv_mpu6050: Initial regcache support

FromJonathan Cameron <jic23@kernel.org>
Date2016-05-01 23:40 +0200
SubjectRe: [PATCH 2/7] iio: inv_mpu6050: Initial regcache support
Message-ID<ru7fQ-8d7-17@gated-at.bofh.it>
In reply to#1391342
On 29/04/16 20:02, Crestez Dan Leonard wrote:
> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Looks fine to me.

Jonathan
> ---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 47 ++++++++++++++++++++++++++++++
>  drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c  |  5 ----
>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |  1 +
>  drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c  |  5 ----
>  4 files changed, 48 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index b269b37..5918c23 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -116,6 +116,53 @@ static const struct inv_mpu6050_hw hw_info[] = {
>  	},
>  };
>  
> +static bool inv_mpu6050_volatile_reg(struct device *dev, unsigned int reg)
> +{
> +	if (reg >= INV_MPU6050_REG_RAW_ACCEL && reg < INV_MPU6050_REG_RAW_ACCEL + 6)
> +		return true;
> +	if (reg >= INV_MPU6050_REG_RAW_GYRO && reg < INV_MPU6050_REG_RAW_GYRO + 6)
> +		return true;
> +	switch (reg) {
> +	case INV_MPU6050_REG_TEMPERATURE:
> +	case INV_MPU6050_REG_TEMPERATURE + 1:
> +	case INV_MPU6050_REG_USER_CTRL:
> +	case INV_MPU6050_REG_PWR_MGMT_1:
> +	case INV_MPU6050_REG_FIFO_COUNT_H:
> +	case INV_MPU6050_REG_FIFO_COUNT_H + 1:
> +	case INV_MPU6050_REG_FIFO_R_W:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +static bool inv_mpu6050_precious_reg(struct device *dev, unsigned int reg)
> +{
> +	switch (reg) {
> +	case INV_MPU6050_REG_FIFO_R_W:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +/*
> + * Common regmap config for inv_mpu devices
> + *
> + * The current volatile/precious registers are common among supported devices.
> + * When that changes the volatile/precious callbacks should go through the
> + * inv_mpu6050_reg_map structs.
> + */
> +const struct regmap_config inv_mpu_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +
> +	.cache_type = REGCACHE_RBTREE,
> +	.volatile_reg = inv_mpu6050_volatile_reg,
> +	.precious_reg = inv_mpu6050_precious_reg,
> +};
> +EXPORT_SYMBOL_GPL(inv_mpu_regmap_config);
> +
>  int inv_mpu6050_switch_engine(struct inv_mpu6050_state *st, bool en, u32 mask)
>  {
>  	unsigned int d, mgmt_1;
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
> index 1a424a6..1a8d1a5 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
> @@ -20,11 +20,6 @@
>  #include <linux/module.h>
>  #include "inv_mpu_iio.h"
>  
> -static const struct regmap_config inv_mpu_regmap_config = {
> -	.reg_bits = 8,
> -	.val_bits = 8,
> -};
> -
>  /*
>   * The i2c read/write needs to happen in unlocked mode. As the parent
>   * adapter is common. If we use locked versions, it will fail as
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> index 47ca25b..297b0ef 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> @@ -291,3 +291,4 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
>  int inv_mpu_core_remove(struct device *dev);
>  int inv_mpu6050_set_power_itg(struct inv_mpu6050_state *st, bool power_on);
>  extern const struct dev_pm_ops inv_mpu_pmops;
> +extern const struct regmap_config inv_mpu_regmap_config;
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
> index 190a4a5..b3bd977 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
> @@ -17,11 +17,6 @@
>  #include <linux/iio/iio.h>
>  #include "inv_mpu_iio.h"
>  
> -static const struct regmap_config inv_mpu_regmap_config = {
> -	.reg_bits = 8,
> -	.val_bits = 8,
> -};
> -
>  static int inv_mpu_i2c_disable(struct iio_dev *indio_dev)
>  {
>  	struct inv_mpu6050_state *st = iio_priv(indio_dev);
>

[toc] | [prev] | [next] | [standalone]

#1391912 — Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings

FromJonathan Cameron <jic23@kernel.org>
Date2016-05-01 23:40 +0200
SubjectRe: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings
Message-ID<ru7fP-8d7-5@gated-at.bofh.it>
In reply to#1391334
On 29/04/16 20:02, Crestez Dan Leonard wrote:
> This series attempts to implement support for external readings in i2c master
> mode. I don't expect this to go in this form but I wanted to present a
> functional version in order to start the discussion earlier.
> 
> 
> The I2C master support is useful even without external readings. For example in
> SPI mode this is the only way to contact auxiliary devices. Differences from
> the previous version:
>  - Require an explicit "inv,i2c-aux-master" bool property. Supporting dynamic
> switches between bypass/master mode is extremely difficult and not really
> worthwhile. Switching to bypass mode requires explicitly disabling all i2c
> master functionality, including external readings! After Peter Rosin's mux
> cleanup patches go in I would like to disable the mux entirely when in master
> mode.
>  - Describe i2c clients behind i2c@1. Maybe it should be i2c@0 like mux mode?
>  - Validate parameters and return an error on unsupported ops (like read_word)
>  - Wait for SLV4_DONE even on writes!
>  - Fix issues when other parts of the driver write to the same registers.
> 
> My initial idea was to use regcache and regmap_update_bits to handle config
> bits like in PATCH 2. It turn out that the device has several registers with a
> combination of volatile "command bits" (writing triggers an action) and "config
> bits" (value must normally be preserved). This requires manually storing the
> state of those config bits in "chip_config". I could try to make do without
> regcache support, even though it offers some advantages.
If you were to break these registers up into regmap fields it might solve 
this..  Regmap writes always go through whatever - whether they match the
existing state of the cache or not.  If fields are involved the write will get
built up from whatever field you change and whatever the cache has for other
elements.  I guess it only works if they volatile bits are contiguous though.
Maybe hand rolling it is cleaner here.

Mark, any clever thoughts on this?
> 
>
> Support for external sensors is rather nasty. What it does is dynamically copy
> iio_chan_spec from the slave device and register it for itself (with an updated
> scan index). Then it forwards everything but IIO_CHAN_INFO_RAW to the other
> driver while serving raw value requests from the MPU's own registers.
> 
> The original device is still registered with linux as a normal driver and works
> normally and you can poke at it to configure stuff like sample rates and
> scaling factors. You can read the same samples from the slaved device, just
> slower. For example:
> 	cat /sys/bus/iio/devices/iio:device1/in_magn_*_raw
> will be slower than:
> 	cat /sys/bus/iio/devices/iio:device0/in_magn_*_raw
> In the first case values are read through SLV4, byte-by-byte. In the second
> they are served directly from EXT_SENS_DATA_* registers.
ouch
> 
> In theory the ak8975 inside mpu9150 could be supported as a slave device but
> that requires further work. Unlike the hmc5883l I've been testing with that
> sensor does not update automatically by default. This means that the mpu6050
> buffer code must call a function from that driver to "enable automatic updates"
> somehow. For example this could be implemented as an additional bufferop?
That's hideous, but sure I guess we could have such an op.
> 
> So far this works surprisingly well without any changes in the iio core or
> drivers for aux devices. But perhaps "external channels" should be listed in
> struct iio_dev and a special marking should be done for iio_chan_spec's which
> can accessed this way.
> 
> External/slaved channels are limited to 16bits because it would otherwise be
> difficult to comply with iio alignment requirements. Support for other channel
> sizes should be implemented separately. There should be a separate discussion
> for how to properly support driver-specified channel offsets instead of
> implicit iio rules.
hmm. You'd need to give more detail on what sort of alignments we are looking at.
It might just be a case of the driver having to do a bit of memcpy magic to 
'fix up' the alignment being read from the device. 
> 
> Patches 1,2,3,4 and 6 are required cleanups/fixed to make the rest work. They
> could go in separately.
> 
> Crestez Dan Leonard (7):
>   iio: inv_mpu6050: Do burst reads using spi/i2c directly
>   iio: inv_mpu6050: Initial regcache support
>   iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo
>   iio: inv_mpu6050: Cache non-volatile bits of user_ctrl
>   iio: inv_mpu6050: Add support for auxiliary I2C master
>   iio: inv_mpu6050: Check channel configuration on preenable
>   iio: inv_mpu6050: Add support for external sensors
> 
>  .../devicetree/bindings/iio/imu/inv_mpu6050.txt    |  96 ++-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c         | 708 ++++++++++++++++++++-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c          |   5 -
>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h          | 116 +++-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c         | 134 +++-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c          |   5 -
>  drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c      |  15 +-
>  7 files changed, 1029 insertions(+), 50 deletions(-)
>

[toc] | [prev] | [next] | [standalone]

#1392296 — Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings

FromMark Brown <broonie@kernel.org>
Date2016-05-02 17:30 +0200
SubjectRe: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings
Message-ID<runXl-5Ww-31@gated-at.bofh.it>
In reply to#1391912

[Multipart message — attachments visible in raw view] — view raw

On Sun, May 01, 2016 at 06:04:08PM +0100, Jonathan Cameron wrote:

> If you were to break these registers up into regmap fields it might solve 
> this..  Regmap writes always go through whatever - whether they match the
> existing state of the cache or not.  If fields are involved the write will get
> built up from whatever field you change and whatever the cache has for other
> elements.  I guess it only works if they volatile bits are contiguous though.
> Maybe hand rolling it is cleaner here.

> Mark, any clever thoughts on this?

I don't have enough context here to be sure what the problem you're
trying to solve is, sorry.

[toc] | [prev] | [next] | [standalone]

#1393342 — Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings

FromCrestez Dan Leonard <leonard.crestez@intel.com>
Date2016-05-03 13:30 +0200
SubjectRe: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings
Message-ID<ruGGC-7g5-11@gated-at.bofh.it>
In reply to#1392296
On 05/02/2016 06:23 PM, Mark Brown wrote:
> On Sun, May 01, 2016 at 06:04:08PM +0100, Jonathan Cameron wrote:
> 
>> If you were to break these registers up into regmap fields it might solve 
>> this..  Regmap writes always go through whatever - whether they match the
>> existing state of the cache or not.  If fields are involved the write will get
>> built up from whatever field you change and whatever the cache has for other
>> elements.  I guess it only works if they volatile bits are contiguous though.
>> Maybe hand rolling it is cleaner here.
> 
>> Mark, any clever thoughts on this?
> 
> I don't have enough context here to be sure what the problem you're
> trying to solve is, sorry.
> 
This is worth explaining:

I have a device which has several registers with bits that are a mix of
"cacheable" and "volatile". For example for register SLV4_CTRL:

- Bit 7 (I2C_SLV4_EN) triggers a transaction with slave 4 when a "1" is
written. The bit is cleared when the transaction is done.
- Bits 0-4 (I2C_MST_DLY) configures the reduced access rate of I2C
slaves relative to the device sample rate. This applies to slaves 0-3 as
well.

If I2C_MST_DLY was a separate register it could be easily cached by
regmap. Because it's part of a volatile register I have to add a
private_data field caching the value and always write it when triggering
a SLV4 transfer.

Jonathan was wondering if regmap can still be used somehow instead of
custom caching.

-- 
Regards,
Leonard

[toc] | [prev] | [next] | [standalone]

#1393347 — Re: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings

FromMark Brown <broonie@kernel.org>
Date2016-05-03 13:40 +0200
SubjectRe: [RFC 0/7] iio: inv_mpu6050: Support i2c master and external readings
Message-ID<ruGQh-7ml-17@gated-at.bofh.it>
In reply to#1393342

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 03, 2016 at 02:21:40PM +0300, Crestez Dan Leonard wrote:

> I have a device which has several registers with bits that are a mix of
> "cacheable" and "volatile". For example for register SLV4_CTRL:

> - Bit 7 (I2C_SLV4_EN) triggers a transaction with slave 4 when a "1" is
> written. The bit is cleared when the transaction is done.
> - Bits 0-4 (I2C_MST_DLY) configures the reduced access rate of I2C
> slaves relative to the device sample rate. This applies to slaves 0-3 as
> well.

> If I2C_MST_DLY was a separate register it could be easily cached by
> regmap. Because it's part of a volatile register I have to add a
> private_data field caching the value and always write it when triggering
> a SLV4 transfer.

> Jonathan was wondering if regmap can still be used somehow instead of
> custom caching.

If you want to cache in regmap just write a 0 back to the enable bit
after you've set it.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web