[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160905075042.zeumdequro3bp3bj@pengutronix.de>
Date: Mon, 5 Sep 2016 01:50:42 -0600
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Vignesh R <vigneshr@...com>
CC: Daniel Mack <daniel@...que.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Tony Lindgren <tony@...mide.com>,
Russell King <linux@...linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
Daniel Hung-yu Wu <hywu@...gle.com>,
Grant Grundler <grundler@...omium.org>,
S Twiss <stwiss.opensource@...semi.com>,
Moritz Fischer <moritz.fischer@...us.com>,
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>,
John Stultz <john.stultz@...aro.org>,
"Andrew F . Davis" <afd@...com>, <linux-input@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-omap@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 0/2] AM335x-ICE: Add support for rotary switch
Hello,
On Wed, Aug 24, 2016 at 02:45:17PM +0530, Vignesh R wrote:
> On Wednesday 24 August 2016 02:05 PM, Daniel Mack wrote:
> > On 08/24/2016 09:58 AM, Vignesh R wrote:
> >> This series adds support for rotary-switch on AM335x-ICE that is
> >> connected to TI PCA9536 I2C GPIO expander.
> >> First patch adds new generic driver to read status of group of GPIO
> >> lines and report the value as an input event. The second patch adds DT
> >> entries for the same.
> >>
> >> v2: https://lkml.org/lkml/2016/8/23/111
> >> v1: https://lkml.org/lkml/2016/8/12/7
> >
> > Is there a reason why the rotary-encoder driver cannot handle this?
> > Commit 7dde4e74744 ("Input: rotary-encoder - support more than 2 gpios
> > as input") added support for that mode AFAIU.
> >
>
> Rotary encoder driver handles incremental encoders only and does not
> support absolute encoders. The rotary switch on am335x-ice is different
> from the incremental encoders in the
> sense that GPIO line status directly reflect the position(number)
> pointed by the dial of the encoder. So, there is no need to count steps
> or know the direction of rotation as it does not matter.
I'd still prefer to expand drivers/input/misc/rotary_encoder.c to handle
this. Yes, there is no reason to count steps or determine the direction
of a rotation in this case, but still there is much code to share and
IMHO it's ok that a driver that handles several types of similar devices
does too much for some special cases.
> I did try to enhance rotary-encoder driver to support absolute
> encoder[1] but the comment there was to write new driver that simply
> translates gpio-encoded value into ABS* event. Indeed, the new driver
> looks more simple and can handle more such hardwares.
Which type of hardware can be handled by your driver that the generic
rotary encoder cannot? I guess it's just a matter of a (simple) patch?
Best regards
Uwe
> [1] https://lkml.org/lkml/2016/5/19/98
--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists