linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2]
@ 2017-04-27 13:29 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
  0 siblings, 2 replies; 13+ messages in thread
From: Benjamin Gaignard @ 2017-04-27 13:29 UTC (permalink / raw)
  To: linux-kernel, jic23, linux-iio, knaack.h, lars, pmeerw,
	vilhelm.gray, mwelling
  Cc: fabrice.gasnier, linaro-kernel, benjamin.gaignard, Benjamin Gaignard

Those patches aim to complete stm32 timer features support.
The last missing part is to be able to chain to timer blocks
which mean that one of timerX's trigger could be used as clock for timerY.

Since this operating is neither event or buffer triggered mode I would
like to introduce a hardware triggered mode in IIO core.

Benjamin Gaignard (2):
  iio: add hardware triggered operating mode
  iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode

 .../ABI/testing/sysfs-bus-iio-timer-stm32          | 15 ++++++
 drivers/iio/industrialio-core.c                    |  4 +-
 drivers/iio/trigger/stm32-timer-trigger.c          | 61 ++++++++++++++++++++++
 include/linux/iio/iio.h                            |  6 +++
 4 files changed, 84 insertions(+), 2 deletions(-)

-- 
1.9.1

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 1/2] iio: add hardware triggered operating mode
  2017-04-27 13:29 [PATCH 0/2] Benjamin Gaignard
@ 2017-04-27 13:29 ` Benjamin Gaignard
  2017-04-27 13:29 ` [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode Benjamin Gaignard
  1 sibling, 0 replies; 13+ messages in thread
From: Benjamin Gaignard @ 2017-04-27 13:29 UTC (permalink / raw)
  To: linux-kernel, jic23, linux-iio, knaack.h, lars, pmeerw,
	vilhelm.gray, mwelling
  Cc: fabrice.gasnier, linaro-kernel, benjamin.gaignard, Benjamin Gaignard

Devices, like stm32 timer, could be triggered by hardware events which
are not buffer or software events. However it could be necessary to
validate the triggers like it is done for buffer or event triggered modes.
This patch add a new INDIO_HARDWARE_TRIGGERED operating mode for this
kind of devices and allow this mode to register trigger consumer.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
 drivers/iio/industrialio-core.c | 4 ++--
 include/linux/iio/iio.h         | 6 ++++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index d18ded4..7872219 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -1429,7 +1429,7 @@ static void iio_device_unregister_sysfs(struct iio_dev *indio_dev)
 static void iio_dev_release(struct device *device)
 {
 	struct iio_dev *indio_dev = dev_to_iio_dev(device);
-	if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
+	if (indio_dev->modes & INDIO_ALL_TRIGGERED_MODES)
 		iio_device_unregister_trigger_consumer(indio_dev);
 	iio_device_unregister_eventset(indio_dev);
 	iio_device_unregister_sysfs(indio_dev);
@@ -1711,7 +1711,7 @@ int iio_device_register(struct iio_dev *indio_dev)
 			"Failed to register event set\n");
 		goto error_free_sysfs;
 	}
-	if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
+	if (indio_dev->modes & INDIO_ALL_TRIGGERED_MODES)
 		iio_device_register_trigger_consumer(indio_dev);
 
 	if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 3f5ea2e..d68bec2 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -352,10 +352,16 @@ static inline bool iio_channel_has_available(const struct iio_chan_spec *chan,
 #define INDIO_BUFFER_SOFTWARE		0x04
 #define INDIO_BUFFER_HARDWARE		0x08
 #define INDIO_EVENT_TRIGGERED		0x10
+#define INDIO_HARDWARE_TRIGGERED	0x20
 
 #define INDIO_ALL_BUFFER_MODES					\
 	(INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE | INDIO_BUFFER_SOFTWARE)
 
+#define INDIO_ALL_TRIGGERED_MODES	\
+	(INDIO_BUFFER_TRIGGERED		\
+	 | INDIO_EVENT_TRIGGERED	\
+	 | INDIO_HARDWARE_TRIGGERED)
+
 #define INDIO_MAX_RAW_ELEMENTS		4
 
 struct iio_trigger; /* forward declaration */
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  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 ` Benjamin Gaignard
  2017-05-01  0:50   ` Jonathan Cameron
  1 sibling, 1 reply; 13+ messages in thread
From: Benjamin Gaignard @ 2017-04-27 13:29 UTC (permalink / raw)
  To: linux-kernel, jic23, linux-iio, knaack.h, lars, pmeerw,
	vilhelm.gray, mwelling
  Cc: fabrice.gasnier, linaro-kernel, benjamin.gaignard, Benjamin Gaignard

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>
---
 .../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;
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  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
  0 siblings, 1 reply; 13+ messages in thread
From: Jonathan Cameron @ 2017-05-01  0:50 UTC (permalink / raw)
  To: Benjamin Gaignard, linux-kernel, linux-iio, knaack.h, lars,
	pmeerw, vilhelm.gray, mwelling
  Cc: fabrice.gasnier, linaro-kernel, Benjamin Gaignard

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.	

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;
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  2017-05-01  0:50   ` Jonathan Cameron
@ 2017-05-07 13:49     ` Jonathan Cameron
  2017-05-08 15:17       ` William Breathitt Gray
  0 siblings, 1 reply; 13+ messages in thread
From: Jonathan Cameron @ 2017-05-07 13:49 UTC (permalink / raw)
  To: Benjamin Gaignard, linux-kernel, linux-iio, knaack.h, lars,
	pmeerw, vilhelm.gray, mwelling
  Cc: fabrice.gasnier, linaro-kernel, Benjamin Gaignard

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
> 
> 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
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  2017-05-07 13:49     ` Jonathan Cameron
@ 2017-05-08 15:17       ` William Breathitt Gray
  2017-05-09  7:46         ` Benjamin Gaignard
  0 siblings, 1 reply; 13+ messages in thread
From: William Breathitt Gray @ 2017-05-08 15:17 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Benjamin Gaignard, linux-kernel, linux-iio, knaack.h, lars,
	pmeerw, mwelling, fabrice.gasnier, linaro-kernel,
	Benjamin Gaignard

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
>> 
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  2017-05-08 15:17       ` William Breathitt Gray
@ 2017-05-09  7:46         ` Benjamin Gaignard
  2017-05-14 16:02           ` Jonathan Cameron
  0 siblings, 1 reply; 13+ messages in thread
From: Benjamin Gaignard @ 2017-05-09  7:46 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: Jonathan Cameron, Linux Kernel Mailing List, linux-iio,
	Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
	mwelling, Fabrice Gasnier, Linaro Kernel Mailman List,
	Benjamin Gaignard

2017-05-08 17:17 GMT+02:00 William Breathitt Gray <vilhelm.gray@gmail.com>:
> 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?

The main difference I have introduce between INDIO_EVENT_TRIGGERED and
INDIO_HARDWARE_TRIGGERED is that this last one doesn't have poll function
(i.e. userland can't wait on the event).
For me userland doesn't need to be informed of each clock rising edge.
More generally this new mode can be used when the event can't/doesn't need be
notified to userland which is the case in my hardware where it is a
signal on internal
wire.

>
> 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
>>>
>>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  2017-05-09  7:46         ` Benjamin Gaignard
@ 2017-05-14 16:02           ` Jonathan Cameron
  2017-06-06  9:41             ` Benjamin Gaignard
  0 siblings, 1 reply; 13+ messages in thread
From: Jonathan Cameron @ 2017-05-14 16:02 UTC (permalink / raw)
  To: Benjamin Gaignard, William Breathitt Gray
  Cc: Linux Kernel Mailing List, linux-iio, Hartmut Knaack,
	Lars-Peter Clausen, Peter Meerwald-Stadler, mwelling,
	Fabrice Gasnier, Linaro Kernel Mailman List, Benjamin Gaignard

On 09/05/17 08:46, Benjamin Gaignard wrote:
> 2017-05-08 17:17 GMT+02:00 William Breathitt Gray <vilhelm.gray@gmail.com>:
>> 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?
> 
> The main difference I have introduce between INDIO_EVENT_TRIGGERED and
> INDIO_HARDWARE_TRIGGERED is that this last one doesn't have poll function
> (i.e. userland can't wait on the event).
INDIO_EVENT_TRIGGERED has a different intent as well. It's about doing
synchronized acquisition of whether a threshold has been passed or not.
It's used for comparator chips that don't have anything else to them.
Right now the only user is the hi8435.  It took a lot of bouncing backwards
and forwards before we came up with this way of handling that chip.
So what you have is a comparator with lots of channels, but it will only
give you info on which are above threshold when you ask it (not interrupts
or internal clocking).  Odd beasts typically used in PLCs where you have
a scan function polling the lot in realtime very 5 msecs or so.

> For me userland doesn't need to be informed of each clock rising edge.
> More generally this new mode can be used when the event can't/doesn't need be
> notified to userland which is the case in my hardware where it is a
> signal on internal
> wire.
Absolutely.  The 'fun' corner case is triggers that 'can' be exposed to userspace
(so there is an interrupt available) but don't have to be to run the
capture on a tightly coupled bit of hardware.  Conceptually there is a hardware
implementation of the interrupt handler available.
> 
>>
>> 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
>>>>
>>>
> 
> 
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  2017-05-14 16:02           ` Jonathan Cameron
@ 2017-06-06  9:41             ` Benjamin Gaignard
  2017-06-11 15:01               ` Jonathan Cameron
  0 siblings, 1 reply; 13+ messages in thread
From: Benjamin Gaignard @ 2017-06-06  9:41 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: William Breathitt Gray, Linux Kernel Mailing List, linux-iio,
	Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
	mwelling, Fabrice Gasnier, Linaro Kernel Mailman List,
	Benjamin Gaignard

2017-05-14 18:02 GMT+02:00 Jonathan Cameron <jic23@kernel.org>:
> On 09/05/17 08:46, Benjamin Gaignard wrote:
>>
>> 2017-05-08 17:17 GMT+02:00 William Breathitt Gray
>> <vilhelm.gray@gmail.com>:
>>>
>>> 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?
>>
>>
>> The main difference I have introduce between INDIO_EVENT_TRIGGERED and
>> INDIO_HARDWARE_TRIGGERED is that this last one doesn't have poll function
>> (i.e. userland can't wait on the event).
>
> INDIO_EVENT_TRIGGERED has a different intent as well. It's about doing
> synchronized acquisition of whether a threshold has been passed or not.
> It's used for comparator chips that don't have anything else to them.
> Right now the only user is the hi8435.  It took a lot of bouncing backwards
> and forwards before we came up with this way of handling that chip.
> So what you have is a comparator with lots of channels, but it will only
> give you info on which are above threshold when you ask it (not interrupts
> or internal clocking).  Odd beasts typically used in PLCs where you have
> a scan function polling the lot in realtime very 5 msecs or so.
>
>> For me userland doesn't need to be informed of each clock rising edge.
>> More generally this new mode can be used when the event can't/doesn't need
>> be
>> notified to userland which is the case in my hardware where it is a
>> signal on internal
>> wire.
>
> Absolutely.  The 'fun' corner case is triggers that 'can' be exposed to
> userspace
> (so there is an interrupt available) but don't have to be to run the
> capture on a tightly coupled bit of hardware.  Conceptually there is a
> hardware
> implementation of the interrupt handler available.

What can I do to progress in implementation of INDIO_HARDWARE_TRIGGERED ?
Do it feel sensible for you to use it ?


>
>>
>>>
>>> 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
>>>>>
>>>>
>>
>>
>>
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
  2017-06-06  9:41             ` Benjamin Gaignard
@ 2017-06-11 15:01               ` Jonathan Cameron
  0 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2017-06-11 15:01 UTC (permalink / raw)
  To: Benjamin Gaignard
  Cc: William Breathitt Gray, Linux Kernel Mailing List, linux-iio,
	Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
	mwelling, Fabrice Gasnier, Linaro Kernel Mailman List,
	Benjamin Gaignard

On Tue, 6 Jun 2017 11:41:43 +0200
Benjamin Gaignard <benjamin.gaignard@linaro.org> wrote:

> 2017-05-14 18:02 GMT+02:00 Jonathan Cameron <jic23@kernel.org>:
> > On 09/05/17 08:46, Benjamin Gaignard wrote:  
> >>
> >> 2017-05-08 17:17 GMT+02:00 William Breathitt Gray
> >> <vilhelm.gray@gmail.com>:  
> >>>
> >>> 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?  
> >>
> >>
> >> The main difference I have introduce between INDIO_EVENT_TRIGGERED and
> >> INDIO_HARDWARE_TRIGGERED is that this last one doesn't have poll function
> >> (i.e. userland can't wait on the event).  
> >
> > INDIO_EVENT_TRIGGERED has a different intent as well. It's about doing
> > synchronized acquisition of whether a threshold has been passed or not.
> > It's used for comparator chips that don't have anything else to them.
> > Right now the only user is the hi8435.  It took a lot of bouncing backwards
> > and forwards before we came up with this way of handling that chip.
> > So what you have is a comparator with lots of channels, but it will only
> > give you info on which are above threshold when you ask it (not interrupts
> > or internal clocking).  Odd beasts typically used in PLCs where you have
> > a scan function polling the lot in realtime very 5 msecs or so.
> >  
> >> For me userland doesn't need to be informed of each clock rising edge.
> >> More generally this new mode can be used when the event can't/doesn't need
> >> be
> >> notified to userland which is the case in my hardware where it is a
> >> signal on internal
> >> wire.  
> >
> > Absolutely.  The 'fun' corner case is triggers that 'can' be exposed to
> > userspace
> > (so there is an interrupt available) but don't have to be to run the
> > capture on a tightly coupled bit of hardware.  Conceptually there is a
> > hardware
> > implementation of the interrupt handler available.  
> 
> What can I do to progress in implementation of INDIO_HARDWARE_TRIGGERED ?
> Do it feel sensible for you to use it ?
I originally thought this was quite a nice solution and my thoughts haven't
changed.  Given no-one else has joined in the conversation - lets take the
view that it's the way to go (at least for now - it's mostly
internal to the kernel so we can always do something different in future).

Both patches applied to the togreg branch of iio.git.

Let's see if anyone screams ;)

Thanks and good thing you reminded me about these - they'd fallen
straight off the back of my queue (and out of my head - sorry about
that!),

Jonathan
> 
> 
> >  
> >>  
> >>>
> >>> 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
> >>>>>  
> >>>>  
> >>
> >>
> >>  
> >  
> 
> 
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 0/2]
  2022-01-07  9:57 Zhenneng Li
@ 2022-01-07 22:51 ` Rodrigo Siqueira Jordao
  0 siblings, 0 replies; 13+ messages in thread
From: Rodrigo Siqueira Jordao @ 2022-01-07 22:51 UTC (permalink / raw)
  To: Zhenneng Li, Alex Deucher, Zhuo, Qingqing, jasdeep.dhillon
  Cc: Christian König, Xinhui.Pan, David Airlie, Daniel Vetter,
	Rodrigo Siqueira, Leo Li, Harry Wentland, amd-gfx, dri-devel,
	linux-kernel, Isabella Basso

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 0/2]
@ 2022-01-07  9:57 Zhenneng Li
  2022-01-07 22:51 ` Rodrigo Siqueira Jordao
  0 siblings, 1 reply; 13+ messages in thread
From: Zhenneng Li @ 2022-01-07  9:57 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Christian König, Xinhui.Pan, David Airlie, Daniel Vetter,
	Rodrigo Siqueira, Leo Li, Harry Wentland, amd-gfx, dri-devel,
	linux-kernel, Zhenneng Li

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 0/2]
@ 2021-10-26 15:27 Antoniu Miclaus
  0 siblings, 0 replies; 13+ messages in thread
From: Antoniu Miclaus @ 2021-10-26 15:27 UTC (permalink / raw)
  To: jic23, robh+dt, linux-iio, devicetree, linux-kernel; +Cc: Antoniu Miclaus

The ADMV1013 is a wideband, microwave upconverter optimized
for point to point microwave radio designs operating in the
24 GHz to 44 GHz radio frequency (RF) range.

Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADMV1013.pdf

NOTE:
Currently depends on 64-bit architecture since the input
clock that server as Local Oscillator should support values
in the range 5.4 GHz to 10.25 GHz.

We might need some scaling implementation in the clock
framework so that u64 types are supported when using 32-bit
architectures.

Antoniu Miclaus (2):
  iio: frequency: admv1013: add support for ADMV1013
  dt-bindings: iio: frequency: add admv1013 doc

 .../bindings/iio/frequency/adi,admv1013.yaml  | 110 ++++
 drivers/iio/frequency/Kconfig                 |  13 +
 drivers/iio/frequency/Makefile                |   1 +
 drivers/iio/frequency/admv1013.c              | 579 ++++++++++++++++++
 4 files changed, 703 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
 create mode 100644 drivers/iio/frequency/admv1013.c

-- 
2.33.1


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-01-07 22:51 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
2021-10-26 15:27 [PATCH 0/2] Antoniu Miclaus
2022-01-07  9:57 Zhenneng Li
2022-01-07 22:51 ` Rodrigo Siqueira Jordao

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).