archive mirror
 help / color / mirror / Atom feed
From: Javier Carrasco <>
To: Alexandre Belloni <>
Cc: Alessandro Zummo <>,
	Rob Herring <>,
	Krzysztof Kozlowski <>,
	Conor Dooley <>,,,
Subject: Re: [PATCH 2/2] dt-bindings: rtc: nxp,pcf8563: add hiz-output property
Date: Thu, 26 Oct 2023 12:13:23 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <202310260956166bdcb845@mail.local>

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.

  reply	other threads:[~2023-10-26 10:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25 16:21 [PATCH 0/2] rtc: pcf85363: add support for high-impedance output Javier Carrasco
2023-10-25 16:21 ` [PATCH 1/2] " Javier Carrasco
2023-10-25 16:21 ` [PATCH 2/2] dt-bindings: rtc: nxp,pcf8563: add hiz-output property Javier Carrasco
2023-10-25 22:23   ` Alexandre Belloni
2023-10-25 22:30     ` Javier Carrasco
2023-10-25 23:23       ` Javier Carrasco
2023-10-26  0:50         ` Alexandre Belloni
2023-10-26  9:41           ` Javier Carrasco
2023-10-26  9:56             ` Alexandre Belloni
2023-10-26 10:13               ` Javier Carrasco [this message]
2023-10-26 10:21                 ` Alexandre Belloni
2023-10-26 10:35                   ` Javier Carrasco
2024-01-30 21:34               ` Javier Carrasco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).