On 04/04/17 08:37, Benjamin Gaignard wrote:
> 2017-04-03 21:58 GMT+02:00 Jonathan Cameron <jic23@xxxxxxxxxx>:
>> On 03/04/17 11:17, Benjamin Gaignard wrote:
>>> 2017-04-02 13:12 GMT+02:00 Jonathan Cameron <jic23@xxxxxxxxxx>:
>>>> On 27/03/17 10:43, Benjamin Gaignard wrote:
>>>>> Device counting could be controlled by the level or the edges of
>>>>> a trigger.
>>>>> in_count0_enable_mode attibute allow to set the control mode.
>>>>>
>>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@xxxxxx>
>>>>> ---
>>>>> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 23 +++++++
>>>>> drivers/iio/trigger/stm32-timer-trigger.c | 70 ++++++++++++++++++++++
>>>>> 2 files changed, 93 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> index bf795ad..c0a1edc 100644
>>>>> --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> @@ -59,3 +59,26 @@ Description:
>>>>> quadrature:
>>>>> Encoder A and B inputs are mixed to get direction
>>>>> and count with a scale of 0.25.
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/in_count_enable_mode_available
>>>>> +KernelVersion: 4.12
>>>>> +Contact: benjamin.gaignard@xxxxxx
>>>>> +Description:
>>>>> + Reading returns the list possible enable modes.
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/in_count0_enable_mode
>>>>> +KernelVersion: 4.12
>>>>> +Contact: benjamin.gaignard@xxxxxx
>>>>> +Description:
>>>>> + Configure the device counter enable modes, in all case
>>>>> + counting direction is set by in_count0_count_direction
>>>>> + attribute and the counter is clocked by the internal clock.
>>>> Silly question, how does one use the encoder modes then?
>>>
>>> When setting an encoder mode internal counter is enabled no need to touch to
>>> in_count0_enable_mode in those cases
>> So in that case it's ignored?
>> I'd be tempted to change the docs to drop the fact it is an internal clock.
>> However you'll also need to ensure that when an encoder mode is selected
>> this attribute will always read 'always'. I think that ends up consistent..
>
> The counter could be drive (i.e counting up/down) by 3 type of source:
> - the internal clock with 3 modes "always", "gated" and "triggered"
> - the encoder input egdes and levels: 3 modes "channel_A", "channel_B"
> and "quadrature"
> - the rising egdes of a connected trigger which is an internal signal
> (for a later patch)
>
> For each counter "source" I have an attribute but in the hardware they
> are exclusive.
> For example set "quadrature" means that the counter is counting on the edges of
> encoder inputs and no more on the rising edges of the internal clock.
>
> I would like to keep this representing the hardware status so if an
> encoder mode is
> selected in_count0_enable_mode will return -EINVAL.
Cool. As long as there is a valid path between modes that's an acceptable
option.
>
>>
>> Also there will be other devices that do these gating and triggering etc but
>> will do it even when fed by an encoder.
>>
>> Jonathan
>>>
>>>>
>>>>> + always:
>>>>> + Counter is always ON.
>>>>> +
>>>>> + gated:
>>>>> + Counting is enabled when connected trigger signal
>>>>> + level is high else counting is disabled.
>>>>> +
>>>>> + triggered:
>>>>> + Counting start on rising edge of the connected trigger.
>>>>
>>>>
>>>>> diff --git a/drivers/iio/trigger/stm32-timer-trigger.c b/drivers/iio/trigger/stm32-timer-trigger.c
>>>>> index 7db904c..0f1a2cf 100644
>>>>> --- a/drivers/iio/trigger/stm32-timer-trigger.c
>>>>> +++ b/drivers/iio/trigger/stm32-timer-trigger.c
>>>>> @@ -353,6 +353,74 @@ static int stm32_counter_write_raw(struct iio_dev *indio_dev,
>>>>> .write_raw = stm32_counter_write_raw
>>>>> };
>>>>>
>>>>> +static const char *const stm32_enable_modes[] = {
>>>>> + "always",
>>>>> + "gated",
>>>>> + "triggered",
>>>>> +};
>>>>> +
>>>>> +static int stm32_enable_mode2sms(int mode)
>>>>> +{
>>>>> + switch (mode) {
>>>>> + case 0:
>>>>> + return 0;
>>>>> + case 1:
>>>>> + return 5;
>>>>> + case 2:
>>>>> + return 6;
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static int stm32_set_enable_mode(struct iio_dev *indio_dev,
>>>>> + const struct iio_chan_spec *chan,
>>>>> + unsigned int mode)
>>>>> +{
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + int sms = stm32_enable_mode2sms(mode);
>>>>> +
>>>>> + if (sms < 0)
>>>>> + return sms;
>>>>> +
>>>>> + regmap_update_bits(priv->regmap, TIM_SMCR, TIM_SMCR_SMS, sms);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static int stm32_sms2enable_mode(int mode)
>>>>> +{
>>>>> + switch (mode) {
>>>>> + case 0:
>>>>> + return 0;
>>>>> + case 5:
>>>>> + return 1;
>>>>> + case 6:
>>>>> + return 2;
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static int stm32_get_enable_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);
>>>>> + smcr &= TIM_SMCR_SMS;
>>>>> +
>>>>> + return stm32_sms2enable_mode(smcr);
>>>>> +}
>>>>> +
>>>>> +static const struct iio_enum stm32_enable_mode_enum = {
>>>>> + .items = stm32_enable_modes,
>>>>> + .num_items = ARRAY_SIZE(stm32_enable_modes),
>>>>> + .set = stm32_set_enable_mode,
>>>>> + .get = stm32_get_enable_mode
>>>>> +};
>>>>> +
>>>>> static const char *const stm32_quadrature_modes[] = {
>>>>> "channel_A",
>>>>> "channel_B",
>>>>> @@ -466,6 +534,8 @@ static ssize_t stm32_count_set_preset(struct iio_dev *indio_dev,
>>>>> IIO_ENUM_AVAILABLE("count_direction", &stm32_count_direction_enum),
>>>>> IIO_ENUM("quadrature_mode", IIO_SEPARATE, &stm32_quadrature_mode_enum),
>>>>> 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),
>>>>> {}
>>>>> };
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
--
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
