[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150819123101.GC27721@hard-bop>
Date: Wed, 19 Aug 2015 15:31:01 +0300
From: Teodora Baluta <teodora.baluta@...el.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: knaack.h@....de, lars@...afoo.de, pmeerw@...erw.net,
daniel.baluta@...el.com, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] iio: mxc4005: add data ready trigger for mxc4005
On Sun, Aug 16, 2015 at 09:01:39AM +0100, Jonathan Cameron wrote:
> On 13/08/15 18:31, Teodora Baluta wrote:
> > Add iio trigger for the data ready interrupt that signals new
> > measurements for the X, Y and Z axes.
> >
> > Signed-off-by: Teodora Baluta <teodora.baluta@...el.com>
> Various bits inline.
Thanks for the review!
>
> Jonathan
> > ---
> > drivers/iio/accel/mxc4005.c | 159 +++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 158 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
> > index 5f4813d..0c47bfe 100644
> > --- a/drivers/iio/accel/mxc4005.c
> > +++ b/drivers/iio/accel/mxc4005.c
> > @@ -17,13 +17,16 @@
> > #include <linux/i2c.h>
> > #include <linux/iio/iio.h>
> > #include <linux/acpi.h>
> > +#include <linux/gpio/consumer.h>
> > #include <linux/regmap.h>
> > #include <linux/iio/sysfs.h>
> > +#include <linux/iio/trigger.h>
> > #include <linux/iio/buffer.h>
> > #include <linux/iio/triggered_buffer.h>
> > #include <linux/iio/trigger_consumer.h>
> >
> > #define MXC4005_DRV_NAME "mxc4005"
> > +#define MXC4005_IRQ_NAME "mxc4005_event"
> > #define MXC4005_REGMAP_NAME "mxc4005_regmap"
> >
> > #define MXC4005_REG_XOUT_UPPER 0x03
> > @@ -33,6 +36,15 @@
> > #define MXC4005_REG_ZOUT_UPPER 0x07
> > #define MXC4005_REG_ZOUT_LOWER 0x08
> >
> > +#define MXC4005_REG_INT_SRC1 0x01
> > +#define MXC4005_REG_INT_SRC2_BIT_DRDY 0x01
> > +
> > +#define MXC4005_REG_INT_MASK1 0x0B
> > +#define MXC4005_REG_INT_MASK1_BIT_DRDYE 0x01
> > +
> > +#define MXC4005_REG_INT_CLR1 0x01
> > +#define MXC4005_REG_INT_CLR1_BIT_DRDYC 0x01
> > +
> > #define MXC4005_REG_CONTROL 0x0D
> > #define MXC4005_REG_CONTROL_MASK_FSR GENMASK(6, 5)
> > #define MXC4005_CONTROL_FSR_SHIFT 5
> > @@ -55,7 +67,10 @@ struct mxc4005_data {
> > struct i2c_client *client;
> > struct mutex mutex;
> > struct regmap *regmap;
> > + struct iio_trigger *dready_trig;
>
> As mentioned below, use the pf->timestamp or you'll get in a mess if for
> example you driver the capture from this via a slow sysfs trigger.
> > + int64_t timestamp;
> > __be16 buffer[3];
> > + bool trigger_enabled;
> > };
> >
> > /*
> > @@ -97,6 +112,7 @@ static bool mxc4005_is_readable_reg(struct device *dev, unsigned int reg)
> > case MXC4005_REG_ZOUT_UPPER:
> > case MXC4005_REG_ZOUT_LOWER:
> > case MXC4005_REG_DEVICE_ID:
> > + case MXC4005_REG_INT_SRC1:
> > case MXC4005_REG_CONTROL:
> > return true;
> > default:
> > @@ -107,6 +123,8 @@ static bool mxc4005_is_readable_reg(struct device *dev, unsigned int reg)
> > static bool mxc4005_is_writeable_reg(struct device *dev, unsigned int reg)
> > {
> > switch (reg) {
> > + case MXC4005_REG_INT_CLR1:
> > + case MXC4005_REG_INT_MASK1:
> > case MXC4005_REG_CONTROL:
> > return true;
> > default:
> > @@ -300,7 +318,7 @@ static irqreturn_t mxc4005_trigger_handler(int irq, void *private)
> > goto err;
> >
> > iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> > - iio_get_time_ns());
> > + data->timestamp);
> Who said this was being triggered by the devices own trigger? If
> you want to do this, then use pull the timestamp save in the pollfunc
> top half. (iio_pollfunc_store_time is available for this).
>
Ok, thanks!
> >
> > err:
> > iio_trigger_notify_done(indio_dev->trig);
> > @@ -308,6 +326,103 @@ err:
> > return IRQ_HANDLED;
> > }
> >
> > +static int mxc4005_set_trigger_state(struct iio_trigger *trig,
> > + bool state)
> > +{
> > + struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
> > + struct mxc4005_data *data = iio_priv(indio_dev);
> > + int ret;
> > +
> > + mutex_lock(&data->mutex);
> > + if (state) {
> > + ret = regmap_write(data->regmap, MXC4005_REG_INT_MASK1,
> > + MXC4005_REG_INT_MASK1_BIT_DRDYE);
> > + } else {
> > + ret = regmap_write(data->regmap, MXC4005_REG_INT_MASK1,
> > + ~MXC4005_REG_INT_MASK1_BIT_DRDYE);
> > + }
> > +
> > + if (ret < 0) {
> > + mutex_unlock(&data->mutex);
> > + dev_err(&data->client->dev,
> > + "failed to update reg_int_mask1");
> > + return ret;
> > + }
> > +
> > + data->trigger_enabled = state;
> > + mutex_unlock(&data->mutex);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct iio_trigger_ops mxc4005_trigger_ops = {
> > + .set_trigger_state = mxc4005_set_trigger_state,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static irqreturn_t mxc4005_irq_thrd_handler(int irq, void *private)
> > +{
> > + struct iio_dev *indio_dev = private;
> > + struct mxc4005_data *data = iio_priv(indio_dev);
> > + unsigned int reg;
> > + int ret;
> > +
> > + ret = regmap_read(data->regmap, MXC4005_REG_INT_SRC1, ®);
> > + if (ret < 0) {
> > + dev_err(&data->client->dev, "failed to read reg_int_src1\n");
> > + goto exit;
> > + }
> Guessing you have to read the interrupt source to get it clear? If so
> please comment it. If not, don't bother reading it :)
The datasheet says that just reading the interrupt source doesn't clear
the interrupt but I'll have to test this. There could be other interrupt
sources - the device has support for shake and tilt events. I guess when
support for these is added it will make sense to read the INT_SRCx
registers.
> > +
> > + /* clear interrupt */
> > + ret = regmap_write(data->regmap, MXC4005_REG_INT_CLR1,
> > + MXC4005_REG_INT_CLR1_BIT_DRDYC);
> > + if (ret < 0) {
> > + dev_err(&data->client->dev, "failed to write to reg_int_clr1\n");
> > + goto exit;
> > + }
>
> This is what the try_to_reenable callback is meant for. That will clear
> the interrupt, only when all child interrupts are done (i.e. all
> triggers consumers are ready for the next one). Here you clear it immediately
> and hence could end up feeding interrupts into that system faster than they
> can be handled (though the masking that occurs should prevent that actually
> causing too much trouble).
>
I'll look into this and fix it.
> > +
> > +exit:
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t mxc4005_irq_handler(int irq, void *private)
> > +{
> > + struct iio_dev *indio_dev = private;
> > + struct mxc4005_data *data = iio_priv(indio_dev);
> > +
> > + data->timestamp = iio_get_time_ns();
> > +
> Right now you don't need this as this is the only supported interrupt.
> I'm guessing you have some events to come though?
> > + if (data->trigger_enabled)
> > + iio_trigger_poll(data->dready_trig);
> > +
> Unusual to have a thread handler here when only one interrupt type is possible.
There are the shake, tilt functions of the device which make sense to be
events, but I am not going to add these anytime soon so you're right.
At this level, I don't think the handler is necessary. I'll rework this
code as per your suggestion.
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static int mxc4005_gpio_probe(struct i2c_client *client,
> > + struct mxc4005_data *data)
> > +{
> > + struct device *dev;
> > + struct gpio_desc *gpio;
> > + int ret;
> > +
> > + if (!client)
> > + return -EINVAL;
> > +
> > + dev = &client->dev;
> > +
> > + gpio = devm_gpiod_get_index(dev, "mxc4005_int", 0, GPIOD_IN);
> > + if (IS_ERR(gpio)) {
> > + dev_err(dev, "failed to get acpi gpio index\n");
> > + return PTR_ERR(gpio);
> > + }
> > +
> > + ret = gpiod_to_irq(gpio);
> > +
> > + dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
> > +
> > + return ret;
> > +}
> > +
> > static int mxc4005_chip_init(struct mxc4005_data *data)
> > {
> > int ret;
> > @@ -373,6 +488,43 @@ static int mxc4005_probe(struct i2c_client *client,
> > return ret;
> > }
> >
> > + if (client->irq < 0)
> > + client->irq = mxc4005_gpio_probe(client, data);
> > +
> > + if (client->irq >= 0) {
> Should be > 0.
>
> IRQ of 0 is nolonger considered valid (used to indicate a specified not
> connected IRQ which isn't going to be useful here!)
>
> Had a patch set correcting all remaining cases of this in IIO the other
> day. Quite a few years ago now, IRQ 0 was valid on arm, but that was
> changed.
>
Ok.
> > + ret = devm_request_threaded_irq(&client->dev, client->irq,
> > + mxc4005_irq_handler,
> > + mxc4005_irq_thrd_handler,
> > + IRQF_TRIGGER_FALLING |
> > + IRQF_ONESHOT,
> > + MXC4005_IRQ_NAME,
> > + indio_dev);
> > + if (ret) {
> > + dev_err(&client->dev,
> > + "failed to init threaded irq\n");
> > + goto err_buffer_cleanup;
> > + }
> > +
> > + data->dready_trig = devm_iio_trigger_alloc(&client->dev,
> > + "%s-dev%d",
> > + indio_dev->name,
> > + indio_dev->id);
> > + if (!data->dready_trig)
> > + return -ENOMEM;
> > +
> > + data->dready_trig->dev.parent = &client->dev;
> > + data->dready_trig->ops = &mxc4005_trigger_ops;
> > + iio_trigger_set_drvdata(data->dready_trig, indio_dev);
> > + indio_dev->trig = data->dready_trig;
> > + iio_trigger_get(indio_dev->trig);
> > + ret = iio_trigger_register(data->dready_trig);
> > + if (ret) {
> > + dev_err(&client->dev,
> > + "failed to register trigger\n");
> > + goto err_trigger_unregister;
> > + }
> > + }
> > +
> > ret = iio_device_register(indio_dev);
> > if (ret < 0) {
> > dev_err(&client->dev,
> > @@ -382,6 +534,8 @@ static int mxc4005_probe(struct i2c_client *client,
> >
> > return 0;
> >
> > +err_trigger_unregister:
> > + iio_trigger_unregister(data->dready_trig);
> > err_buffer_cleanup:
> > iio_triggered_buffer_cleanup(indio_dev);
> >
> > @@ -391,10 +545,13 @@ err_buffer_cleanup:
> > static int mxc4005_remove(struct i2c_client *client)
> > {
> > struct iio_dev *indio_dev = i2c_get_clientdata(client);
> > + struct mxc4005_data *data = iio_priv(indio_dev);
> >
> > iio_device_unregister(indio_dev);
> >
> > iio_triggered_buffer_cleanup(indio_dev);
> > + if (data->dready_trig)
> > + iio_trigger_unregister(data->dready_trig);
> >
> > return 0;
> > }
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists