linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
	mwelling@ieee.org, fabrice.gasnier@st.com,
	linaro-kernel@lists.linaro.org,
	Benjamin Gaignard <benjamin.gaignard@st.com>
Subject: Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
Date: Mon, 8 May 2017 11:17:01 -0400	[thread overview]
Message-ID: <20170508151701.GA26979@sophia> (raw)
In-Reply-To: <194c7da3-f674-e024-ba59-8b353c3f089b@kernel.org>

On Sun, May 07, 2017 at 02:49:16PM +0100, Jonathan Cameron wrote:
>On 01/05/17 01:50, Jonathan Cameron wrote:
>> On 27/04/17 14:29, Benjamin Gaignard wrote:
>>> Add validate function to be use to use the correct trigger.
>>> Add an attribute to configure device mode like for quadrature and
>>> enable modes
>>>
>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> Hmm.  I think I quite like this as an approach but have changed my
>> mind several times over the last few days :)
>> 
>> Hence I'd ideally like some more opinions and will be leaving it
>> on the list for at least a short time longer.
>> 
>> It's missed the current merge window anyway so plenty of time to
>> tick off this last element of your support.
>> 
>> I also just checked and our docs for the existing modes is rubbish
>> (or I can't find it with a quick grep ;)
>> so we should tidy that up and add some description of this as well.	
>Still looking for more input on this!
>
>Lars - do you have time for a quick look?
>
>No real rush though as we are early in the cycle.
>
>Thanks,
>
>Jonathan

I haven't used triggers before in my drivers so perhaps I can provide
the naive perspective of someone approaching the API for the first time.

>From what I gather, the INDIO_BUFFERED_TRIGGERED option is used for
triggers associated with a buffer; for example, a device keeping track
of ambient temperature may periodically sample its sensors and store the
data in a buffer for later evaluation.

The INDIO_EVENT_TRIGGERED option appears to be used for triggers
associated with some sort of event; for example, a threshold voltage is
reached on an ADC device.

I'm having trouble groking how the INDIO_HARDWARE_TRIGGERED option
differs from the INDIO_EVENT_TRIGGERED option. It looks like the
INDIO_HARDWARE_TRIGGERED option is used in this case to associate a
trigger with a clock edge (first timer chained to second timer).
Wouldn't an INDIO_EVENT_TRIGGERED option be sufficient in this case
where the event is defined as the clock edge input to the second timer?

William Breathitt Gray

>> 
>> Jonathan
>>> ---
>>>  .../ABI/testing/sysfs-bus-iio-timer-stm32          | 15 ++++++
>>>  drivers/iio/trigger/stm32-timer-trigger.c          | 61 ++++++++++++++++++++++
>>>  2 files changed, 76 insertions(+)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>> index 230020e..cccdf57 100644
>>> --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>> @@ -90,3 +90,18 @@ Description:
>>>  			Counting is enabled on rising edge of the connected
>>>  			trigger, and remains enabled for the duration of this
>>>  			selected mode.
>>> +
>>> +What:		/sys/bus/iio/devices/iio:deviceX/in_count_trigger_mode_available
>>> +KernelVersion:	4.13
>>> +Contact:	benjamin.gaignard@st.com
>>> +Description:
>>> +		Reading returns the list possible trigger modes.
>>> +
>>> +What:		/sys/bus/iio/devices/iio:deviceX/in_count0_trigger_mode
>>> +KernelVersion:	4.13
>>> +Contact:	benjamin.gaignard@st.com
>>> +Description:
>>> +		Configure the device counter trigger mode
>>> +		counting direction is set by in_count0_count_direction
>>> +		attribute and the counter is clocked by the connected trigger
>>> +		rising edges.
>>> diff --git a/drivers/iio/trigger/stm32-timer-trigger.c b/drivers/iio/trigger/stm32-timer-trigger.c
>>> index 0f1a2cf..7c6e90e 100644
>>> --- a/drivers/iio/trigger/stm32-timer-trigger.c
>>> +++ b/drivers/iio/trigger/stm32-timer-trigger.c
>>> @@ -347,12 +347,70 @@ static int stm32_counter_write_raw(struct iio_dev *indio_dev,
>>>  	return -EINVAL;
>>>  }
>>>  
>>> +static int stm32_counter_validate_trigger(struct iio_dev *indio_dev,
>>> +					  struct iio_trigger *trig)
>>> +{
>>> +	struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>> +	const char * const *cur = priv->valids;
>>> +	unsigned int i = 0;
>>> +
>>> +	if (!is_stm32_timer_trigger(trig))
>>> +		return -EINVAL;
>>> +
>>> +	while (cur && *cur) {
>>> +		if (!strncmp(trig->name, *cur, strlen(trig->name))) {
>>> +			regmap_update_bits(priv->regmap,
>>> +					   TIM_SMCR, TIM_SMCR_TS,
>>> +					   i << TIM_SMCR_TS_SHIFT);
>>> +			return 0;
>>> +		}
>>> +		cur++;
>>> +		i++;
>>> +	}
>>> +
>>> +	return -EINVAL;
>>> +}
>>> +
>>>  static const struct iio_info stm32_trigger_info = {
>>>  	.driver_module = THIS_MODULE,
>>> +	.validate_trigger = stm32_counter_validate_trigger,
>>>  	.read_raw = stm32_counter_read_raw,
>>>  	.write_raw = stm32_counter_write_raw
>>>  };
>>>  
>>> +static const char *const stm32_trigger_modes[] = {
>>> +	"trigger",
>>> +};
>>> +
>>> +static int stm32_set_trigger_mode(struct iio_dev *indio_dev,
>>> +				  const struct iio_chan_spec *chan,
>>> +				  unsigned int mode)
>>> +{
>>> +	struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>> +
>>> +	regmap_update_bits(priv->regmap, TIM_SMCR, TIM_SMCR_SMS, TIM_SMCR_SMS);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int stm32_get_trigger_mode(struct iio_dev *indio_dev,
>>> +				  const struct iio_chan_spec *chan)
>>> +{
>>> +	struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>> +	u32 smcr;
>>> +
>>> +	regmap_read(priv->regmap, TIM_SMCR, &smcr);
>>> +
>>> +	return smcr == TIM_SMCR_SMS ? 0 : -EINVAL;
>>> +}
>>> +
>>> +static const struct iio_enum stm32_trigger_mode_enum = {
>>> +	.items = stm32_trigger_modes,
>>> +	.num_items = ARRAY_SIZE(stm32_trigger_modes),
>>> +	.set = stm32_set_trigger_mode,
>>> +	.get = stm32_get_trigger_mode
>>> +};
>>> +
>>>  static const char *const stm32_enable_modes[] = {
>>>  	"always",
>>>  	"gated",
>>> @@ -536,6 +594,8 @@ static ssize_t stm32_count_set_preset(struct iio_dev *indio_dev,
>>>  	IIO_ENUM_AVAILABLE("quadrature_mode", &stm32_quadrature_mode_enum),
>>>  	IIO_ENUM("enable_mode", IIO_SEPARATE, &stm32_enable_mode_enum),
>>>  	IIO_ENUM_AVAILABLE("enable_mode", &stm32_enable_mode_enum),
>>> +	IIO_ENUM("trigger_mode", IIO_SEPARATE, &stm32_trigger_mode_enum),
>>> +	IIO_ENUM_AVAILABLE("trigger_mode", &stm32_trigger_mode_enum),
>>>  	{}
>>>  };
>>>  
>>> @@ -560,6 +620,7 @@ static struct stm32_timer_trigger *stm32_setup_counter_device(struct device *dev
>>>  	indio_dev->name = dev_name(dev);
>>>  	indio_dev->dev.parent = dev;
>>>  	indio_dev->info = &stm32_trigger_info;
>>> +	indio_dev->modes = INDIO_HARDWARE_TRIGGERED;
>>>  	indio_dev->num_channels = 1;
>>>  	indio_dev->channels = &stm32_trigger_channel;
>>>  	indio_dev->dev.of_node = dev->of_node;
>>>
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>

  reply	other threads:[~2017-05-08 15:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 13:29 [PATCH 0/2] Benjamin Gaignard
2017-04-27 13:29 ` [PATCH 1/2] iio: add hardware triggered operating mode Benjamin Gaignard
2017-04-27 13:29 ` [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode Benjamin Gaignard
2017-05-01  0:50   ` Jonathan Cameron
2017-05-07 13:49     ` Jonathan Cameron
2017-05-08 15:17       ` William Breathitt Gray [this message]
2017-05-09  7:46         ` Benjamin Gaignard
2017-05-14 16:02           ` Jonathan Cameron
2017-06-06  9:41             ` Benjamin Gaignard
2017-06-11 15:01               ` 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=20170508151701.GA26979@sophia \
    --to=vilhelm.gray@gmail.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=benjamin.gaignard@st.com \
    --cc=fabrice.gasnier@st.com \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mwelling@ieee.org \
    --cc=pmeerw@pmeerw.net \
    /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).