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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
