properties to describe a rotary encoder

properties to describe a rotary encoder

[Uwe Kleine-König]

Hello,

there is already a driver for rotary encoders described in
Documentation/devicetree/bindings/input/rotary-encoder.txt. This however
is not suitable to describe the device I have here for two reasons:

First the driver can only make use of 2 gpio lines, while the device
here has 4 lines, so I have 16 sectors instead of only 4. And the
second difference is that my encoder has a detend for each sector while
the driver only supports "half-period" and "full-period" (default) mode.
These names really only make sense for the 2 line case and mean the
encoder has detends in 2 or 1 sector respectively.

So I'm thinking about how to generalize the description to allow to add
support for "my" device.

For the added gpio lines it's easy, that's just allowing more than two
gpios for the "gpios" property.

Currently there is a property "rotary-encoder,steps" that describes the
number of detends in a full turnaround. So if we stick to "steps" to
describe detends, maybe something like "sectors-per-step" (with a
default of 4) would be needed to describe what "half-period" is now.
Does this make sense? Maybe someone has a better suggestion?

I'll start implementing that now, but give you time to think about a
good name/scheme already. :-)

Feedback welcome.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: properties to describe a rotary encoder

[Daniel Mack]

Hi,

On 10/16/2015 11:59 AM, Uwe Kleine-König wrote:
> there is already a driver for rotary encoders described in
> Documentation/devicetree/bindings/input/rotary-encoder.txt. This however
> is not suitable to describe the device I have here for two reasons:
> 
> First the driver can only make use of 2 gpio lines, while the device
> here has 4 lines,

How does the phase diagram of that device look like, on what edges is
the system supposed to trigger?

> so I have 16 sectors instead of only 4. And the

What's a 'sector'?

> second difference is that my encoder has a detend for each sector while
> the driver only supports "half-period" and "full-period" (default) mode.
> These names really only make sense for the 2 line case and mean the
> encoder has detends in 2 or 1 sector respectively.
> 
> So I'm thinking about how to generalize the description to allow to add
> support for "my" device.
> 
> For the added gpio lines it's easy, that's just allowing more than two
> gpios for the "gpios" property.

Doesn't the number of GPIOs already give enough information to implement
proper support? Maybe there's no need for any other properties here.

> Currently there is a property "rotary-encoder,steps" that describes the
> number of detends in a full turnaround. So if we stick to "steps" to
> describe detends, maybe something like "sectors-per-step" (with a
> default of 4) would be needed to describe what "half-period" is now.
> Does this make sense? Maybe someone has a better suggestion?

I'm not sure what a sector is supposed to refer to, but the number of
steps per 360° is something that can vary for both 2-line and 4-line
versions of a rotary encoder. So isn't that unrelated?


Thanks,
Daniel

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: properties to describe a rotary encoder

[Uwe Kleine-König]

Hello,

On Fri, Oct 16, 2015 at 12:09:21PM +0200, Daniel Mack wrote:
> Hi,
> 
> On 10/16/2015 11:59 AM, Uwe Kleine-König wrote:
> > there is already a driver for rotary encoders described in
> > Documentation/devicetree/bindings/input/rotary-encoder.txt. This however
> > is not suitable to describe the device I have here for two reasons:
> > 
> > First the driver can only make use of 2 gpio lines, while the device
> > here has 4 lines,
> 
> How does the phase diagram of that device look like, on what edges is
> the system supposed to trigger?
> 
> > so I have 16 sectors instead of only 4. And the
> 
> What's a 'sector'?

My imagination is the image on the right on
https://en.wikipedia.org/wiki/Rotary_encoder#Gray_encoding .

With more than period per 360° "sector" is probably not a lucky
choice. A colleague suggested "increment" instead, maybe this one is
better? So with a 4-line encoder there are 16 increments per period
while a 2-line encoder has only 4 increments per period.

An rotary encoder that is currently described by:

	{
		compatible = "rotary-encoder";
		gpios = <..>, <..>;
		rotary-encoder,steps = <24>;
		rotary-encoder,half-period;
	}

would then be described as:

	{
		compatible = ...;
		gpios = <..>, <..>;
		rotary-encoder,steps = <24>;
		rotary-encoder,increments-per-step = <2>;
	}

, an encoder without "..,half-period" would get
"...,increments-per-step = <4>" and for mine I'd use

	{
		compatible = ...;
		gpios = <..>, <..>, <..>, <..>;
		rotary-encoder,steps = <16>;
		rotary-encoder,increments-per-step = <1>;
	}

> > second difference is that my encoder has a detend for each sector while
> > the driver only supports "half-period" and "full-period" (default) mode.
> > These names really only make sense for the 2 line case and mean the
> > encoder has detends in 2 or 1 sector respectively.
> > 
> > So I'm thinking about how to generalize the description to allow to add
> > support for "my" device.
> > 
> > For the added gpio lines it's easy, that's just allowing more than two
> > gpios for the "gpios" property.
> 
> Doesn't the number of GPIOs already give enough information to implement
> proper support? Maybe there's no need for any other properties here.

No, that alone isn't enough because "my" encoder has one increment per
step while the driver only supports two increments per step
("half-period") or four increments per step (absence of "half-period").

> > Currently there is a property "rotary-encoder,steps" that describes the
> > number of detends in a full turnaround. So if we stick to "steps" to
> > describe detends, maybe something like "sectors-per-step" (with a
> > default of 4) would be needed to describe what "half-period" is now.
> > Does this make sense? Maybe someone has a better suggestion?
> 
> I'm not sure what a sector is supposed to refer to, but the number of
> steps per 360° is something that can vary for both 2-line and 4-line
> versions of a rotary encoder. So isn't that unrelated?

Yes, this is an (nearly) orthogonal property. But for a 4-line encoder
I'd say that "half-period" would mean 8 increments per step (because a
full period is 2**4 == 16 increments), and that is hardly sensible.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html