On 26.10.23 11:56, Alexandre Belloni wrote: > On 26/10/2023 11:41:47+0200, Javier Carrasco wrote: >> >> On 26.10.23 02:50, Alexandre Belloni wrote: >>> On 26/10/2023 01:23:21+0200, Javier Carrasco wrote: >>>>>>> + hiz-output: >>>>>>> + description: >>>>>>> + Use enabled if the output should stay in high-impedance. This >>>>>>> + mode will mask the output as an interrupt source. >>>>>>> + Use sleep if the otuput should be only active in sleep mode. >>>>>>> + This mode is compatible with any other output configuration. >>>>>>> + The disabled value acts as if the property was not defined. >>>>>>> + enum: >>>>>>> + - enabled >>>>>>> + - sleep >>>>>>> + - disabled >>>>>>> + default: disabled >>>>>>> + >>>>>> >>>>>> If instead of using a custom property, you consider this as what it >>>>>> actually is: pinmuxing, then everything else comes for free. With >>>>>> pinctrl, you can define different states for runtime and sleep and they >>>>>> will get applied automatically instead of open coding in the driver. >>>> >>>> I am not sure if your solution would cover all my needs: >>>> >>>> 1.- With pinctrl I can model the SoC pins, right? That would not stop >>>> the RTC output though, so the 32 kHz signal would be generated anyways >>>> even though the SoC would ignore it. That is one of the things I want to >>>> avoid. >>>> >>> >>> No, you would model the INTA pin. >> I am sorry for insisting on this topic, but if I get you right, I would >> be modeling an interrupt pin (INTA) to keep it from generating a clock >> signal when the RTC itself offers a high-impedance mode i.e. avoiding to >> use the RTC feature. >> >> Is that not a misuse of the INTA pin in the first place? If there was no >> other option, that would be an easy fix, but why would we not implement >> the hi-Z mode when it is available? If I see a pinctrl-* modeling an >> interrupt pin, it is not obvious that I am doing that to stop the clock >> signal and I would have to clarify it explicitly, especially if I am not >> interested in the interrupt. >> >> I would rather implement and document the hi-Z mode the RTC offers >> instead of using another mode like INTA which actually can trigger >> interrupts. If the implementation must be different is of course another >> topic. > > There is a pin named INTA, it can mux 4 different functions: > > - clock output > - battery mode indication > - interrupt > - HiZ > > with pinmuxing, you can select which function you want for the pin. I'm > not sure what is misused there. > > Can you explain what is your actual use case? I'm starting to understand > that what you want is simply disable clock out because you are not using > the interrupt. > > If we assume we are never going to use battery mode, then we could > simply used the CCF for this like the other RTC drivers. > I want to model the INTA pin as a clock source that only should run in sleep mode because its clock is only used in that mode. Therefore I want the pin to stay in hi-Z during normal operation. I do not want to get any interrupts from the INTA pin and the battery mode indication is not relevant for me either. I do not know the CCF mechanism in other RTCs though, but I think that the hi-Z mode accomplishes exactly what I described.The assumption about the battery mode is therefore beyond my knowledge, but my first reaction is that we already have the hi-Z for that. So in the end I just need a mechanism to configure INTA as hi-Z, which the driver still does not support. There is another application where the clock output is not required even though it is physically connected, so hi-Z is again an interesting mode and the battery mode would be available if it ever becomes relevant for anyone.
