linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Javier Carrasco <javier.carrasco@wolfvision.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: rtc: nxp,pcf8563: add hiz-output property
Date: Thu, 26 Oct 2023 11:56:16 +0200	[thread overview]
Message-ID: <202310260956166bdcb845@mail.local> (raw)
In-Reply-To: <8fec6c89-548b-43b5-8361-869663a58573@wolfvision.net>

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.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2023-10-26  9:56 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 [this message]
2023-10-26 10:13               ` Javier Carrasco
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=202310260956166bdcb845@mail.local \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=javier.carrasco@wolfvision.net \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).