public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Mudit Sharma <muditsharma.info@gmail.com>
Cc: lars@metafoo.de, krzk+dt@kernel.org, conor+dt@kernel.org,
	robh@kernel.org, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	Ivan Orlov <ivan.orlov0322@gmail.com>,
	Javier Carrasco <javier.carrasco.cruz@gmail.com>
Subject: Re: [PATCH v6 2/2] iio: light: ROHM BH1745 colour sensor
Date: Sat, 29 Jun 2024 18:50:46 +0100	[thread overview]
Message-ID: <20240629185046.290c7d81@jic23-huawei> (raw)
In-Reply-To: <66122c40-9c69-471c-8f59-cfb1c9b0b6ec@gmail.com>

On Sat, 29 Jun 2024 10:10:19 +0100
Mudit Sharma <muditsharma.info@gmail.com> wrote:

> On 28/06/2024 20:37, Jonathan Cameron wrote:
> > Hi Mudit,
> > 
> > I'd failed on previous reviews to notice the odd trigger in here.
> > What is it, because it doesn't seem to be a dataready trigger as the device
> > doesn't seem to provide such an interrupt?  
> 
> Hi Jonathan,
> 
> Thank you for your review on this.
> 
> I've incorrect called it as a dataready trigger, I missed this as part 
> of my initial cleanup - apologies for the confusion caused by this. I 
> should potentially call it 'threshold' or 'dev'. Please suggest what you 
> think would be appropriate here.
> 
> The sensor has an active low interrupt pin which is connected to a GPIO 
> (input, pullup). When the sensor reading crosses value set in threshold 
> high or threshold low resisters, interrupt signal is generated and the 
> interrupt gets handled in 'bh1745_interrupt_handler()' (interrupt also 
> depends on number of consecutive judgements set in BH1745_PERSISTENCE 
> register)

This isn't really a trigger. Just report the event and don't register a trigger at
all. 

In theory we could have a trigger with these properties (and we did discuss
many years ago how to do this in a generic fashion) but today it isn't
something any standard userspace will understand how to use.

> 
> > 
> > Various other comments inline.  
> 
> Will address all for v7
> >  
> ...
> >> +static irqreturn_t bh1745_interrupt_handler(int interrupt, void *p)
> >> +{
> >> +	struct iio_dev *indio_dev = p;
> >> +	struct bh1745_data *data = iio_priv(indio_dev);
> >> +	int ret;
> >> +	int value;
> >> +
> >> +	ret = regmap_read(data->regmap, BH1745_INTR, &value);
> >> +	if (ret)
> >> +		return IRQ_NONE;
> >> +
> >> +	if (value & BH1745_INTR_STATUS) {
> >> +		guard(mutex)(&data->lock);
> >> +		iio_push_event(indio_dev,
> >> +			       IIO_UNMOD_EVENT_CODE(IIO_INTENSITY, data->int_src,
> >> +						    IIO_EV_TYPE_THRESH,
> >> +						    IIO_EV_DIR_EITHER),
> >> +			       iio_get_time_ns(indio_dev));  
> > 
> > What is happening here.  You always push out the event and use that as
> > a trigger?  This is an unusual trigger if it's appropriate to use it for
> > one at all.  You've called it a dataready trigger but it is not obvious
> > that this device provides any such signal.  
> 
> When an interrupt occurs, BH1745_INTR_STATUS bit is set in the 
> BH1745_INTR register. Event is only pushed out when the 
> BH1745_INTR_STATUS bit is set.
That bit is fine. My confusion is more about the trigger.  I think
the short answer is drop the next line and indeed all the code registering
a trigger as this device doesn't provide appropriate hardware.

> >> +
> >> +		iio_trigger_poll_nested(data->trig);
> >> +
> >> +		return IRQ_HANDLED;
> >> +	}
> >> +
> >> +	return IRQ_NONE;
> >> +}  
> 
> Best regards,
> Mudit Sharma
> 


  reply	other threads:[~2024-06-29 17:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25 22:03 [PATCH v6 1/2] dt-bindings: iio: light: ROHM BH1745 Mudit Sharma
2024-06-25 22:03 ` [PATCH v6 2/2] iio: light: ROHM BH1745 colour sensor Mudit Sharma
2024-06-28 19:37   ` Jonathan Cameron
2024-06-29  9:10     ` Mudit Sharma
2024-06-29 17:50       ` Jonathan Cameron [this message]
2024-07-01 19:34         ` Mudit Sharma
2024-07-01 11:32   ` Matti Vaittinen
2024-07-01 21:32     ` Mudit Sharma

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=20240629185046.290c7d81@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ivan.orlov0322@gmail.com \
    --cc=javier.carrasco.cruz@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muditsharma.info@gmail.com \
    --cc=robh@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