Re: [PATCH 2/2] dt-bindings: rtc: nxp,pcf8563: add hiz-output property

[Javier Carrasco <javier.carrasco@wolfvision.net>]

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.