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 02:50:08 +0200	[thread overview]
Message-ID: <20231026005008b8255799@mail.local> (raw)
In-Reply-To: <1c4a6185-fe09-45d1-900a-10abf48e3fc9@wolfvision.net>

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.

> 2.- What happens if the RTC output is a clock for an external device
> that is only required when the SoC is in sleep mode? In that case I
> would like the RTC driver to control the output with the modes it provides.

Even if I doubt this is a valid use case, this would be possible as long
as the external device node has the correct pinctrl-* properties.


> >>
> >> Also, how you define this property means that everyone currently using
> >> this RTC is going to have a new warning that they should just ignore.
> >>
> >>
> > Thanks for your reply. The warning can only be triggered if the property
> > is defined, so in principle no one could have that warning yet. Only the
> > ones who actually define it and use an invalid value would get the warning.
> > 
> > On the other hand I did not consider your approach, which might make
> > this patch irrelevant. So I will have a look at it to make sure that it
> > achieves the same results.
> > 
> > Thanks again and best regards,
> > Javier Carrasco
> > 

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

  reply	other threads:[~2023-10-26  0:50 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 [this message]
2023-10-26  9:41           ` Javier Carrasco
2023-10-26  9:56             ` Alexandre Belloni
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=20231026005008b8255799@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).