>> - Thinking further on this, I realized that for common case signal >> polarity is something defined by chip, and thus this knowledge belongs >> to chip's driver and not to chip user's device tree. Moreover, device >> tree writer could easily be not aware of signal polarity (too many >> datasheets are NDA-closed), thus hello copy-pasting, try-and-check and >> other counterproductive approaches. >> >> - Then Vladimir pointed real-life case with signal inversion by handmade >> level shifter. Although scope of this is likely limited to hw labs, >> support for this is wanted and thus some way to override polarity in >> chip user's dts be available. Still, this should be optional, without >> requiring dts to always define polarity of each gpio. > > I have real hardware that effectively does the equivalent for interrupt > lines coming into the processor from some sensors. Note quite the same, > but shows these things often do turn up as a fix on 'real' hardware. Well no doubt that sometimes there is need to invert polarity for particular use case. But still forcing explicit definition of polarity of each and every gpio usage is a bad way to solve this. > You are correct, this needs some wider guidance. I've cc'd Linus > Walleij more to make sure he has a heads up than to suggest > we continue this conversation in this thread. As I've already written elsewhere, possible solution is a new pair of gpio flags, GPIO_DEFAULT_POLARITY / GPIO_INVERTED_POLARITY, which means that polarity of signal is, corresponding, chip's default or inverted chip's default. And matching API for drivers to set default when requesting gpio. > > I don't know what the 'correct' way forward is. Funnily enough > my immediate thought is to it it with a big hammer and define > an inverting gpiochip to represent the possible inverter. > So a bit like a gpiochip setting on i2c but in this case > it sits on a gpio. So when you set the front gpio > (representing the inverter) it knows to set the opposite > on the actual gpio on the processor. This may be alternative to GPIO_DEFAULT_POLARITY / GPIO_INVERTED_POLARITY, that perhaps allows for device tree to better follow schematics. Still this does not play well with existing requirement to explicitly set ACTIVE_LOW / ACTIVE_HIGH at gpio usage side. Nikita P.S. Another view is that for such a trivial entity as gpio, we already have - physical gpio values, - logical values that come from ACTIVE_LOW / ACTIVE_HIGH, - for gpios used as interrupts, active low / active high irq's, and discussing addition more to that... for simplification? Joking? At least, if adding default-polarity / inverted-polarity, this should be done mutually-exclusive with active-high / active-low. And if adding inverter gpiochip, then also this should be mutual exclusive with setting active-high / active-low. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
