All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH v4 1/3] iio: chemical: atlas-sensor: allow probe without interrupt line
Date: Fri, 14 Feb 2020 13:27:43 +0000	[thread overview]
Message-ID: <20200214132743.04d6d12d@archlinux> (raw)
In-Reply-To: <09D15D9D-2EBD-4BFF-A5BA-FA0B25F0E750@konsulko.com>

On Sat, 8 Feb 2020 18:12:03 -0800
Matt Ranostay <matt.ranostay@konsulko.com> wrote:

> > On Feb 8, 2020, at 08:39, Jonathan Cameron <jic23@kernel.org> wrote:
> > 
> > On Wed,  5 Feb 2020 22:13:30 -0800
> > Matt Ranostay <matt.ranostay@konsulko.com> wrote:
> >   
> >> Sensors don't actually need a interrupt line to give valid readings,
> >> and can triggered with CONFIG_IIO_HRTIMER_TRIGGER as well. Remove
> >> the required check for interrupt, and continue along in the probe
> >> function.  
> > 
> > Basic aim is good, but if you don't have an interrupt doesn't make
> > sense to register the trigger either.
> > 
> > The interrupt enable / disable is also tied up with the buffer whereas
> > it should probably be done via the trigger enable callback or am I
> > missing something?  
>  
> It was for allowing sysfs and hrtimer triggers. But just remembered most these sensors have a low refresh rate. I can go either way on having it or not. Thoughts?
I'm a bit confused.   With sysfs and hrtimer triggers why would we
need the interrupt enabled?  As things stand it will be as it's done
in the buffer setup.  I was suggesting moving it to the trigger
setup so we only deal with the interrupt if we are actually using
the data ready trigger.

So move it the atlas_set_interrupt call from pre / post enable to
the trigger state callback.

Jonathan
> 
> - Matt
> 
> 
> > 
> > Jonathan
> >   
> >> 
> >> Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
> >> ---
> >> drivers/iio/chemical/atlas-sensor.c | 27 ++++++++++++---------------
> >> 1 file changed, 12 insertions(+), 15 deletions(-)
> >> 
> >> diff --git a/drivers/iio/chemical/atlas-sensor.c b/drivers/iio/chemical/atlas-sensor.c
> >> index 2f0a6fed2589..2e34c82cb65d 100644
> >> --- a/drivers/iio/chemical/atlas-sensor.c
> >> +++ b/drivers/iio/chemical/atlas-sensor.c
> >> @@ -572,11 +572,6 @@ static int atlas_probe(struct i2c_client *client,
> >>    if (ret)
> >>        return ret;
> >> 
> >> -    if (client->irq <= 0) {
> >> -        dev_err(&client->dev, "no valid irq defined\n");
> >> -        return -EINVAL;
> >> -    }
> >> -
> >>    ret = chip->calibration(data);
> >>    if (ret)
> >>        return ret;
> >> @@ -596,16 +591,18 @@ static int atlas_probe(struct i2c_client *client,
> >> 
> >>    init_irq_work(&data->work, atlas_work_handler);
> >> 
> >> -    /* interrupt pin toggles on new conversion */
> >> -    ret = devm_request_threaded_irq(&client->dev, client->irq,
> >> -                    NULL, atlas_interrupt_handler,
> >> -                    IRQF_TRIGGER_RISING |
> >> -                    IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> >> -                    "atlas_irq",
> >> -                    indio_dev);
> >> -    if (ret) {
> >> -        dev_err(&client->dev, "request irq (%d) failed\n", client->irq);
> >> -        goto unregister_buffer;
> >> +    if (client->irq <= 0) {
> >> +        /* interrupt pin toggles on new conversion */
> >> +        ret = devm_request_threaded_irq(&client->dev, client->irq,
> >> +                NULL, atlas_interrupt_handler,
> >> +                IRQF_TRIGGER_RISING |
> >> +                IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> >> +                "atlas_irq",
> >> +                indio_dev);
> >> +
> >> +        if (ret)
> >> +            dev_warn(&client->dev,
> >> +                "request irq (%d) failed\n", client->irq);
> >>    }
> >> 
> >>    ret = atlas_set_powermode(data, 1);  
> >   


  parent reply	other threads:[~2020-02-14 13:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06  6:13 [PATCH v4 0/3] iio: chemical: atlas-sensor: add DO support Matt Ranostay
2020-02-06  6:13 ` [PATCH v4 1/3] iio: chemical: atlas-sensor: allow probe without interrupt line Matt Ranostay
2020-02-07  0:53   ` Jeremy Fertic
2020-02-07  4:59     ` Matt Ranostay
2020-02-08 16:39   ` Jonathan Cameron
2020-02-09  2:12     ` Matt Ranostay
2020-02-09  2:16       ` Matt Ranostay
2020-02-14 13:27       ` Jonathan Cameron [this message]
2020-02-06  6:13 ` [PATCH v4 2/3] iio: chemical: atlas-sensor: add DO-SM module support Matt Ranostay
2020-02-08 16:41   ` Jonathan Cameron
2020-02-06  6:13 ` [PATCH v4 3/3] dt-bindings: iio: chemical: consolidate atlas-sensor docs Matt Ranostay
2020-02-06 21:52   ` Rob Herring
2020-02-08 16:34   ` Jonathan Cameron

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=20200214132743.04d6d12d@archlinux \
    --to=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=matt.ranostay@konsulko.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.