Re: [PATCH v3 2/3] Input: adc-joystick - Add polled input device support

Artur Rojek
2022-06-19T16:31:26Z

On 2022-06-19 17:32, Jonathan Cameron wrote:
> On Sat, 18 Jun 2022 15:08:29 +0200
> Artur Rojek <contact@artur-rojek.eu> wrote:
>
>> On 2022-06-15 17:12, Chris Morgan wrote:
>> > On Wed, Jun 15, 2022 at 03:43:07AM +0200, Artur Rojek wrote:
>> >> On 2022-06-13 21:23, Chris Morgan wrote:
>> >> > From: Chris Morgan <macromorgan@hotmail.com>
>> >> >
>> >> > Add polled input device support to the adc-joystick driver. This is
>> >> > useful for devices which do not have hardware capable triggers on
>> >> > their SARADC. Code modified from adc-joystick.c changes made by Maya
>> >> > Matuszczyk.
>> >> >
>> >> > Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
>> >> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
>> >>
>> >> Hi Chris,
>> >>
>> >> Comments inline. I also Cc'd Paul and Jonathan, who were attached in
>> >> v2.
> +CC linux-iio
>
>> >>
>> >> > ---
>> >> > drivers/input/joystick/adc-joystick.c | 52 +++++++++++++++++++++------
>> >> > 1 file changed, 41 insertions(+), 11 deletions(-)
>> >> >
>> >> > diff --git a/drivers/input/joystick/adc-joystick.c
>> >> > b/drivers/input/joystick/adc-joystick.c
>> >> > index 78ebca7d400a..dc01cd0214d2 100644
>> >> > --- a/drivers/input/joystick/adc-joystick.c
>> >> > +++ b/drivers/input/joystick/adc-joystick.c
>> >> > @@ -13,6 +13,10 @@
>> >> >
>> >> > #include <asm/unaligned.h>
>> >> >
>> >> > +#define ADC_JSK_POLL_INTERVAL 16
>> >> > +#define ADC_JSK_POLL_MIN 8
>> >> > +#define ADC_JSK_POLL_MAX 32
>> >> > +
>> >> > struct adc_joystick_axis {
>> >> > u32 code;
>> >> > s32 range[2];
>> >> > @@ -26,8 +30,21 @@ struct adc_joystick {
>> >> > struct adc_joystick_axis *axes;
>> >> > struct iio_channel *chans;
>> >> > int num_chans;
>> >> > + bool polled;
>> >> > };
>> >> >
>> >> > +static void adc_joystick_poll(struct input_dev *input)
>> >> > +{
>> >> > + struct adc_joystick *joy = input_get_drvdata(input);
>> >> > + int i, val;
>> >> > +
>> >> > + for (i = 0; i < joy->num_chans; i++) {
>> >> > + iio_read_channel_raw(&joy->chans[i], &val);
Perhaps check the return value and leave early on error.
>> >> > + input_report_abs(input, joy->axes[i].code, val);
>> >> > + }
>> >> > + input_sync(input);
>> >> > +}
>> >> > +
>> >> > static int adc_joystick_handle(const void *data, void *private)
>> >> > {
>> >> > struct adc_joystick *joy = private;
>> >> > @@ -215,8 +232,19 @@ static int adc_joystick_probe(struct
>> >> > platform_device *pdev)
>> >> > joy->input = input;
>> >> > input->name = pdev->name;
>> >> > input->id.bustype = BUS_HOST;
>> >> > - input->open = adc_joystick_open;
>> >> > - input->close = adc_joystick_close;
>> >> > +
>> >> > + if (device_property_read_bool(dev,
>> >> > "adc-joystick,no-hardware-trigger"))
>> >> > + joy->polled = 1;
>> >> As mentioned in v2, I don't think a DT property is required here.
>> >> Assuming
>> >> the polled mode is a fallback for devices with no buffers, just do:
>> >> ```
>> >> joy->polled = !(joy->chans[0].indio_dev->modes &
>> >> INDIO_ALL_BUFFER_MODES);
>> >> ```
>> >
>> > Understood. I attempted this and noticed that it was showing I have
>> > INDIO_BUFFER_TRIGGERED in addition to INDIO_DIRECT_MODE (the
>> > INDIO_DIRECT_MODE is the only one specified at the hardware level
>> > though). Should I just check for INDIO_BUFFER_SOFTWARE &
>> > INDIO_BUFFER_HARDWARE instead? I think it's possible that the inclusion
>> > of the industrialio_triggered_buffer module in my kernel is adding
>> > this to the channel somehow?
>> Having INDIO_BUFFER_TRIGGERED means that your saradc is capable of
>> using
>> the existing flow. You should be able to register a software trigger
>> and
>> use the adc-joystick driver without further issues.
>> That said, this is where it gets problematic - there is no way to
>> create
>> an IIO trigger via Device Tree, since triggers don't describe any
>> piece
>> of hardware, and you shouldn't need to register it at runtime
>> (configfs/sysfs) for communication between two kernel drivers either.
>> At
>> the same time, it's not adc-joystick's job to register an external
>> trigger.
>>
>> Jonathan,
>> I don't know what the proper approach to this should be, perhaps you
>> could assist?
>
> You are correct in your description above. Device tree folk take the
> view
> that sysfs / hrtimer etc triggers are a policy decision so don't belong
> in device tree. In general you need some userspace code to stitch up
> the trigger anyway (even ADCs that provide triggers of their own often
> have several).
>
> An alternative that may make sense here would be for the adc-joystick
> driver to provide a trigger of it's own. That's easy enough to do,
> but as things stand we don't provide a way to control the attached
> trigger from other kernel drivers (i.e. you can't do the equivalent
> of writing current_trigger for another device).
>
> It's probably not implausible to add that though. Is it worth it for
> a joystick (vs doing what is done here), maybe not.
>
> It would be worth doing if we cared about high performance (for some
> ADCs
> anyway) but here we don't really so the polled read functions are fine.
>
> Note many ADC drivers only support running in either polled or buffered
> mode in IIO because polling random channels when doing highly optimised
> accesses tends to make the drivers complex. Hence you might find this
> doesn't work for all setups...
>
> Thanks,
>
> Jonathan

Jonathan,
thanks for the detailed answer.

Chris,
In light of the above, I think the best course of action should be to
keep your polling code. It looks like your saradc has introduced [1]
`INDIO_BUFFER_TRIGGERED` support exclusively for this very
(adc-joystick) case. This means we can't use `indio_dev->modes` to
determine whether the joystick can be polled, otherwise we might break
behavior of existing hardware. I suggest that we get back to passing
this intention via optional `poll-interval` DT property, that enables
the polling path if present (indiscriminately of the IIO mode). Let's
see what the Device Tree folk say about that :)

Cheers,
Artur

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e130dc7b41348b13684f0758c26cc6cf72a3449
>
>
>
>>
>> Cheers,
>> Artur
>> >
>> > Thank you.
>> >
>> >> > +
>> >> > + if (joy->polled) {
>> >> > + input_setup_polling(input, adc_joystick_poll);
>> >> > + input_set_poll_interval(input, ADC_JSK_POLL_INTERVAL);
>> >> > + input_set_min_poll_interval(input, ADC_JSK_POLL_MIN);
>> >> > + input_set_max_poll_interval(input, ADC_JSK_POLL_MAX);
>> >> > + } else {
>> >> > + input->open = adc_joystick_open;
>> >> > + input->close = adc_joystick_close;
>> >> > + }
>> >> >
>> >> > error = adc_joystick_set_axes(dev, joy);
>> >> > if (error)
>> >> > @@ -229,16 +257,18 @@ static int adc_joystick_probe(struct
>> >> > platform_device *pdev)
>> >> > return error;
>> >> > }
>> >> >
>> >> > - joy->buffer = iio_channel_get_all_cb(dev, adc_joystick_handle, joy);
>> >> > - if (IS_ERR(joy->buffer)) {
>> >> > - dev_err(dev, "Unable to allocate callback buffer\n");
>> >> > - return PTR_ERR(joy->buffer);
>> >> > - }
>> >> > + if (!joy->polled) {
>> >> > + joy->buffer = iio_channel_get_all_cb(dev, adc_joystick_handle, joy);
>> >> Please maintain line discipline of 80 chars to stay consistent with
>> >> the rest
>> >> of this driver.
>> >
>> > Understood, sorry about that.
>> >
>> >> > + if (IS_ERR(joy->buffer)) {
>> >> > + dev_err(dev, "Unable to allocate callback buffer\n");
>> >> > + return PTR_ERR(joy->buffer);
>> >> > + }
>> >> >
>> >> > - error = devm_add_action_or_reset(dev, adc_joystick_cleanup,
>> >> > joy->buffer);
>> >> > - if (error) {
>> >> > - dev_err(dev, "Unable to add action\n");
>> >> > - return error;
>> >> > + error = devm_add_action_or_reset(dev, adc_joystick_cleanup,
>> >> > joy->buffer);
>> >> Same here.
>> >
>> > Ditto.
>> >
>> >>
>> >> Cheers,
>> >> Artur
>> >> > + if (error) {
>> >> > + dev_err(dev, "Unable to add action\n");
>> >> > + return error;
>> >> > + }
>> >> > }
>> >> >
>> >> > return 0;