On Fri, Dec 15, 2023 at 06:13:51PM +0100, Fabrice Gasnier wrote:
> >> + /*
> >> + * Handle diversity for stm32 timers features. For now encoder is found with
> >> + * advanced timers or gp timers with 4 channels. Timers with less channels
> >> + * doesn't support encoder.
> >> + */
> >> + switch (priv->nchannels) {
> >> + case 4:
> >> + if (priv->has_encoder)
> >> + counter->counts = &stm32_counts_enc_4ch;
> >> + else
> >> + counter->counts = &stm32_counts_4ch;
> >> + counter->signals = stm32_signals;
> >> + counter->num_signals = ARRAY_SIZE(stm32_signals);
> >> + break;
> >> + case 2:
> >> + counter->counts = &stm32_counts_2ch;
> >> + counter->signals = stm32_signals;
> >> + counter->num_signals = 3; /* clock, ch1 and ch2 */
> >> + break;
> >> + case 1:
> >> + counter->counts = &stm32_counts_1ch;
> >> + counter->signals = stm32_signals;
> >> + counter->num_signals = 2; /* clock, ch1 */
> >> + break;
> >> + default:
> >> + counter->counts = &stm32_counts;
> >> + counter->signals = stm32_signals;
> >> + counter->num_signals = 1; /* clock */
> >> + break;
> >> + }
> >
> > Rather than adjusting the number of counts and signals, keep the
> > configuration static and use a single stm32_counts array. The reason is
> > that in the Counter subsystem paradigm Signals do not necessary
> > correlate to specific hardware signals but are rather an abstract
> > representation of the device behavior at a high level. In other words, a
> > Synapse with an action mode set to COUNTER_SYNAPSE_ACTION_NONE can be
> > viewed as representing a Signal that does not affect the Count (i.e. in
> > this case equivalent to an unconnected line).
> >
> > What you'll need to do instead is check priv->nchannels during
> > stm32_action_read and stm32_count_function_read calls in order to return
> > the correct synapse action and count function for the particular
> > channels configuration you have. In stm32_count_function_write you would
> > return an -EINVAL (maybe -EOPNOTSUPP would be better?) when the channels
> > configuration does not support a particular count function.
>
> Hi William,
>
> Sorry for the long delay to address your comments here. Many thanks for
> these guidelines.
>
> I'm preparing a v3, to address these. I'll probably send it soon, so we
> can start to review also the capture part of it. Still there are few
> things here I'm wondering about (as an anticipation task).
>
> Basically, removing all the diversity here means the most featured timer
> model will be represented here (with all possible signals).
> When I wrote the various configuration arrays, I'd have been tempted to
> allocate them dynamically upon probing to avoid having all these
> variants described as const arrays. This may have eased other signals
> additions later. But that's not the direction. So, this simplifies the
> description here, clearly, to describe the full-featured timer/counter,
> and handle the ("unconnected") variants by returning errors.
>
> I still have in mind the replacement of the last IIO_COUNT device [1]
> (not addressed in this series), e.g. in
> drivers/iio/trigger/stm32-timer-trigger.c. Here, there are
> "valids_table" that are used to cascade two timers (one timer output
> being the input to another timer). With this table currently, an IIO
> user knows the name of the signal it selects (then the driver looks up
> the 'valids' table to set SMCR / TS bits, e.g. trigger select). Each
> individual timer has a different input mapping, so called peripheral
> interconnect in STM32.
> What bothers me here is: with an abstracted full-featured timer, without
> any diversity on the signal names, I fear the userland has no clue on
> which signal would be used. Abstracting the timer this way would mean
> the user only knows it selects "Internal Trigger 0" for example, without
> knowing which internal signal in the SoC it has selected.
>
> Even if this is out of scope for this series, would you have some clue
> so I can anticipate it ? Or if we stick with abstract names? In which
> case the userland may need to be aware of the signals mapping (where
> currently in IIO_COUNT driver, the signal names are privided). I'd be
> glad to get some direction here.
>
> Please advise,
> Best Regards,
> Fabrice
>
> [1] https://lore.kernel.org/linux-arm-kernel/Y0vzlOmFrVCQVXMq@fedora/
Hi Fabrice,
I took a look the stm32-timer-trigger.c file, but I'm having trouble
understanding it well (probably the cascading is confusing me). If I
understand the logic correctly, the user selects the trigger they want
by the attribute's name which is compared via strncmp() against the
'valids' table. It's possible we could dynamically configure the signal
names, but keep the signal id static so the driver code won't need some
many variations; alternatively, we could introduce a new signal
extension attribute that could display the trigger name.
Would you walk me through an example of using the stm32-timer-trigger
IIO sysfs interface? I think that would help me understand how users
currently interact with the triggers for that driver, and then maybe I
can figure out an appropriate equivalent in the Counter paradigm for
the migration. Right now, the timer cascade is confusing me so if I can
grok it well, the right solution for this may come to me more easily.
Thanks,
William Breathitt Gray
Attachment:
signature.asc
Description: PGP signature
