2017-05-14 18:02 GMT+02:00 Jonathan Cameron <jic23@xxxxxxxxxx>:
> On 09/05/17 08:46, Benjamin Gaignard wrote:
>>
>> 2017-05-08 17:17 GMT+02:00 William Breathitt Gray
>> <vilhelm.gray@xxxxxxxxx>:
>>>
>>> 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@xxxxxx>
>>>>>
>>>>> 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@xxxxxx
>>>>>> +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@xxxxxx
>>>>>> +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@xxxxxxxxxxxxxxx
>>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
