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