On 02/05/2024 11:56, Johan Hovold wrote: > Hi Krzysztof, > > and sorry about the late reply. Got side-tracked. > > On Thu, Apr 25, 2024 at 11:39:24AM +0200, Krzysztof Kozlowski wrote: >> On 24/04/2024 09:34, Johan Hovold wrote: >>> On Tue, Apr 23, 2024 at 06:29:44PM +0200, Krzysztof Kozlowski wrote: >>>> On 23/04/2024 15:46, Johan Hovold wrote: >>>>> When the power supply is shared with other peripherals the reset line >>>>> can be wired in such a way that it can remain deasserted regardless of >>>>> whether the supply is on or not. > >>>>> This is important as it can be used to avoid holding the controller in >>>>> reset for extended periods of time when it remains powered, something >>>>> which can lead to increased power consumption. Leaving reset deasserted >>>>> also avoids leaking current through the reset circuitry pull-up >>>>> resistors. >>>>> >>>>> Add a new 'no-reset-on-power-off' devicetree property which can be used >>>>> by the OS to determine when reset needs to be asserted on power down. >>>>> >>>>> Note that this property can also be used when the supply cannot be >>>>> turned off by the OS at all. >>> >>>>> reset-gpios: >>>>> description: Reset GPIO; not all touchscreens using eKTH6915 hook this up. >>>>> >>>>> + no-reset-on-power-off: > >>>> Anyway, the property sounds like what the OS should be doing, which is >>>> not what we want. You basically instruct driver what to do. We want a >>>> described hardware configuration or hardware specifics. >>> >>> Right, and this was why I at first rejected a property name like this in >>> favour of 'reset-pulled-to-supply' in my first draft. That name >>> obviously does not work as the 'supply' suffix is already claimed, but I >>> also realised that it doesn't really describe the hardware property that >>> allows the reset line to remain asserted. >>> >>> The key feature in this hardware design is that the reset line will not >>> just be pulled to the supply voltage (what other voltage would it be >>> pulled to), but that it is also pulled to ground when the supply is >>> disabled. >> >> OK, if the property was specific to the hardware, then I would propose >> something more hardware-related, e.g. "reset-supply-tied". However : >> >>> Rather than trying to encode this in the property name, I settled on the >>> descriptive 'no-reset-on-power-off' after the seeing the prior art in >>> 'goodix,no-reset-during-suspend' property. The latter is too specific >>> and encodes policy, but the former could still be considered hardware >>> description and would also apply to other designs which have the >>> property that the reset line should be left deasserted. >>> >>> One such example is when the supply can not be disabled at all (e.g. the >>> Goodix case), but I can imagine there being more than one way to design >>> such reset circuits. >> >> It seems it is common problem. LEDs have property >> "retain-state-shutdown", to indicate that during system shutdown we >> should not touch them (like power off). Would some variant be applicable >> here? First, do we talk here about power off like system shutdown or >> runtime PM, thus suspend? > > A name like 'retain-state-shutdown' would also be too specific as what > I'm describing here is that the reset line should be (or can be) left > deasserted whenever the OS wants to power off the device. I don't think it is more specific than yours. It is actually more generic. First, shutdown=poweroff, so that part is the same. retain-state means keep things enabled, asserted, deasserted, etc, so multiple cases. Your wording is specific - only one state is kept during power off: reset deassert. Best regards, Krzysztof
