Input: rotary-encoder - use more than two gpios

Hello Daniel,

Quoted 43 lines · Daniel Mack

Quoted 26 lines · Uwe Kleine-K?nig

Some time ago I sent a v1 of this, now after testing the changes more deeply patch 3 changed a bit. The old series started with

	Date: Wed,  2 Dec 2015 11:07:11 +0100
	From: Uwe Kleine-K?nig <[email protected]>
	Subject: [PATCH RFC 0/3] input: rotary_encoder: use more than two gpios as input
	Message-Id: <[email protected]>

The two first patches are just preparation for the third patch.

There is an obvious improvement that allows detection of quick changes more reliably with >2 gpios, but I didn't implement this yet. (With 4 GPIOs you can distinguish a counter clockwise movement of three states from a clock wise movement of a single state. Still the patch is useful as it makes these devices work at all.

My test device looks as follows:

        rotary at 0 {
                compatible = "rotary-encoder";
                gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, <&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>;

                rotary-encoder,steps = <16>;
		rotary-encoder,steps-per-period = <16>;
        };

Quoted 5 lines

While Daniel Mack and Rojhalat Ibrahim agreed that this device is an absolute encoder and should be supported by a simpler logic, I still consider it worthwhile to get these patches in as a first step. Also the binding looks right, so IMHO the comments shouldn't stop this series from going in.

I still don't understand why this is implemented that way, rather than going for a much simpler logic of interpretation that also allows users to read out the absolute position.

The code to read the value would be really just as simple as reading all GPIOs and or-ing their values into the result, and skip the state machine completely. This code would be active if a new attribute (something like 'rotary-encoder,hardware-absolute') is set, or even implicitly, when more than 2 GPIOs are specified.

Quoted 1 line

Is there any reason for not doing that?

Currently the reason is lack of time. And when implementing rotary-encoder,hardware-absolute something similar would be the result for the relative reporting anyhow. So the problem is only that I don't have absolute support yet, but the patches as is would be the base for that anyhow.