> so changing this to have the driver now all of a sudden expect > And in all the ACPI tables the GPIOs are marked as active-high Lets just focus on making sure these changes don't break AcPI It seems that Dmitry is in favor of the change you suggest, so > So clearly, we do not agree on what, at least in the DT, the level of a reset gpio should mean. > The current implementation is playing the double-invert game for me. > us / gives us any added value, in any way. > I don't see how playing this double-invert game is going to help > means that I need to set the logical output to HIGH to have a HW reset, which is not what happens for this driver. I just don't get the current implementation with reset-gpios in DT. If it was named enable-gpios, I would understand. If it was called nreset, that would be a different story. I do a "positive" action, so I activate something. For Goodix, its reset line is active low. > When I want to put a device into reset mode, I activate/assert the line so that its logical state is "active". > to side by the init-sequence specified in the datasheet. > just makes the driver code harder to read when putting it side > (from the datasheet init sequence specified values pov) IMHO > active-low (1) to then invert the value again in the driver > By default marking all the direct-attached RST pin connections as The driver tries to enforce physical level (on the touchscreen controller side) by expecting the logical level (of the gpio controller) to match. > As Dmitry pointed out, we're talking about logical vs physical level. > But as I mentioned before the datasheet spells out a very specific > the pin as active-low in the DT makes a lot of sense here. > Right and if a line runs through an inverting buffer then marking > peripheral is not attached directly, but potentially through an inverter
> the AP point of view (as opposed to device). > active/inactive) and allows platform/firmware to specify polarity from GPIOD API operates on a logival level (think of them as > We are driving GPIOs here and those are driven low/high.
> reset-framework (drivers/reset/*) terminology. > It is not asserted/deasserted, asserted/deasserted is reset-controller/ > The reset line is asserted for selecting the I2C target address and then
0 kommentar(er)
