Thread (17 messages) 17 messages, 5 authors, 2016-07-19

[RFC PATCH 1/2] Input: rotary-encoder- Add support for absolute encoder

From: vigneshr@ti.com (Vignesh R)
Date: 2016-06-16 10:48:34
Also in: linux-devicetree, linux-input, linux-omap, lkml

Hi Dmitry,

On Wednesday 25 May 2016 02:14 PM, Vignesh R wrote:
Hi Dmitry,

On 05/23/2016 02:48 PM, R, Vignesh wrote:
quoted

On 5/20/2016 10:04 PM, Dmitry Torokhov wrote:
quoted
On Thu, May 19, 2016 at 02:34:00PM +0530, Vignesh R wrote:
quoted
There are rotary-encoders where GPIO lines reflect the actual position
of the rotary encoder dial. For example, if dial points to 9, then four
GPIO lines connected to the rotary encoder will read HLLH(1001b = 9).
Add support for such rotary-encoder.
The driver relies on rotary-encoder,absolute-encoder DT property to
detect such encoders.
Since, GPIO IRQs are not necessary to work with
such encoders, optional polling mode support is added using
input_poll_dev skeleton. This is can be used by enabling
CONFIG_INPUT_GPIO_ROTARY_ENCODER_POLL_MODE_SUPPORT.
Does this really belong to a rotary encoder and not a new driver that
simply translates gpio-encoded value into ABS* event?
Currently rotary encoder driver only supports incremental/step counting
rotary devices. However, the device that is there on am335x-ice is an
absolute encoder but, IMO, nevertheless a kind of rotary encoder. The
only difference is that there is no need to count steps and the absolute
position value is always available as binary encoded state of connected
GPIOs.
The hardware on am335x-ice is a mechanical rotary encoder switch
connected over 4 GPIOs. It is same as binary encoder described at [1]
(except there are 4 GPIO lines), so this lead me to add support in
rotary-encoder.

[1]https://en.wikipedia.org/wiki/Rotary_encoder#Standard_binary_encoding
Could you please comment on how would you like to support above
described encoder: As a new driver or with existing driver with new
compatible/mode setting via DT or as suggest by Uwe in another reply?
IMHO, supporting using existing driver with new mode/compatible string
looks a better option as the hardware is a kind of rotary-encoder.
It would be great if you could comment on how would you like to see
support for absolute rotary-encoder(the one I described above)? As a new
driver or handle it by adding new compatible to existing rotary-encoder
driver?


-- 
Regards
Vignesh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help