linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eva Rachel Retuya <eraretuya@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org, knaack.h@gmx.de, lars@metafoo.de,
	pmeerw@pmeerw.net, dmitry.torokhov@gmail.com,
	michael.hennerich@analog.com, daniel.baluta@gmail.com,
	amsfield22@gmail.com, florian.vaussard@heig-vd.ch,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger
Date: Tue, 2 May 2017 19:59:18 +0800	[thread overview]
Message-ID: <20170502115917.GC3030@Socrates-UM> (raw)
In-Reply-To: <977684c1-8c87-80ae-fc13-576e30e88384@kernel.org>

On Mon, May 01, 2017 at 01:32:00AM +0100, Jonathan Cameron wrote:
[...]
> Coming together nicely, but a few more bits and pieces inline...
> 
> One slight worry is that the irq names stuff is to restrictive
> as we want to direct different interrupts to different pins if
> both are supported!
> 
> Jonathan
[...]
> > +#define ADXL345_IRQ_NAME		"adxl345_event"
> I'd just put this inline.  It doesn't really give any benefit to
> have this defined at the top.

Ack.

> > +
> >  /*
> >   * In full-resolution mode, scale factor is maintained at ~4 mg/LSB
> >   * in all g ranges.
> > @@ -49,6 +56,8 @@
> >  static const int adxl345_uscale = 38300;
> >  
> >  struct adxl345_data {
> > +	struct iio_trigger *data_ready_trig;
> > +	bool data_ready_trig_on;
> >  	struct regmap *regmap;
> >  	struct mutex lock; /* protect this data structure */
> >  	u8 data_range;
> > @@ -158,17 +167,62 @@ static int adxl345_read_raw(struct iio_dev *indio_dev,
> >  	return -EINVAL;
> >  }
> >  
[...]
> > -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> > +int adxl345_core_probe(struct device *dev, struct regmap *regmap, int irq,
> >  		       const char *name)
> >  {
> >  	struct adxl345_data *data;
> >  	struct iio_dev *indio_dev;
> >  	u32 regval;
> > +	int of_irq;
> >  	int ret;
> >  
> >  	ret = regmap_read(regmap, ADXL345_REG_DEVID, &regval);
> > @@ -199,6 +253,22 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> >  		dev_err(dev, "Failed to set data range: %d\n", ret);
> >  		return ret;
> >  	}
> > +	/*
> > +	 * Any bits set to 0 send their respective interrupts to the INT1 pin,
> > +	 * whereas bits set to 1 send their respective interrupts to the INT2
> > +	 * pin. Map all interrupts to the specified pin.
> This is an interesting comment.  The usual reason for dual interrupt
> pins is precisely to not map all functions to the same one.  That allows
> for a saving in querying which interrupt it is by having just the data ready
> on one pin and just the events on the other...
> 
> Perhaps the current approach won't support that mode of operation?
> Clearly we can't merge a binding that enforces them all being the same
> and then change it later as it'll be incompatible.
> 

I've thought about this before since to me that's the better approach
than one or the other. I'm in a time crunch before hence I went with
this way. The input driver does this as well and what I just did is to
match what it does. If you could point me some drivers for reference,
I'll gladly analyze those and present something better on the next
revision.

Thanks,
Eva

> I'm not quite sure how one should do this sort of stuff in DT though.
> 
> Rob?
> > +	 */
> > +	of_irq = of_irq_get_byname(dev->of_node, "INT2");
> > +	if (of_irq == irq)
> > +		regval = 0xFF;
> > +	else
> > +		regval = 0x00;
> > +
> > +	ret = regmap_write(data->regmap, ADXL345_REG_INT_MAP, regval);
> > +	if (ret < 0) {
> > +		dev_err(dev, "Failed to set up interrupts: %d\n", ret);
> > +		return ret;
> > +	}
> >  
> >  	mutex_init(&data->lock);
> >  

  parent reply	other threads:[~2017-05-02 11:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-29  7:48 [PATCH v2 0/4] iio: accel: adxl345: Add support for buffered readings Eva Rachel Retuya
2017-04-29  7:48 ` [PATCH v2 1/4] dt-bindings: iio: accel: adxl345: Add optional interrupt-names support Eva Rachel Retuya
2017-04-29  7:48 ` [PATCH v2 2/4] iio: accel: adxl345_core: Introduce set_mode and data_ready functions Eva Rachel Retuya
2017-05-01  0:22   ` Jonathan Cameron
2017-05-01 19:42     ` Andy Shevchenko
2017-05-01 19:48       ` Jonathan Cameron
2017-05-01 20:07         ` Andy Shevchenko
2017-05-01 20:18           ` Jonathan Cameron
2017-05-02 11:39     ` Eva Rachel Retuya
2017-05-02 16:32       ` Jonathan Cameron
2017-05-10 13:07         ` Eva Rachel Retuya
2017-05-01 11:21   ` Andy Shevchenko
2017-05-02 11:46     ` Eva Rachel Retuya
2017-04-29  7:49 ` [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger Eva Rachel Retuya
2017-05-01  0:32   ` Jonathan Cameron
2017-05-02  3:01     ` Rob Herring
2017-05-02 15:59       ` Jonathan Cameron
2017-05-10 14:33         ` Eva Rachel Retuya
2017-05-02 11:59     ` Eva Rachel Retuya [this message]
2017-05-01 11:31   ` Andy Shevchenko
2017-05-02 12:15     ` Eva Rachel Retuya
2017-05-02 21:05       ` Andy Shevchenko
2017-05-10 13:24         ` Eva Rachel Retuya
2017-05-14 15:15           ` Jonathan Cameron
2017-05-14 16:08             ` Dmitry Torokhov
2017-05-05 18:26       ` Jonathan Cameron
2017-05-10 13:31         ` Eva Rachel Retuya
2017-04-29  7:49 ` [PATCH v2 4/4] iio: accel: adxl345: Add support for triggered buffer Eva Rachel Retuya
2017-05-01  0:42   ` Jonathan Cameron
2017-05-02 12:23     ` Eva Rachel Retuya
2017-05-02 16:08       ` Jonathan Cameron
2017-05-01 11:24   ` Andy Shevchenko
2017-05-02 12:24     ` Eva Rachel Retuya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170502115917.GC3030@Socrates-UM \
    --to=eraretuya@gmail.com \
    --cc=amsfield22@gmail.com \
    --cc=daniel.baluta@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=florian.vaussard@heig-vd.ch \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.hennerich@analog.com \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).