[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202310260956166bdcb845@mail.local>
Date: Thu, 26 Oct 2023 11:56:16 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Javier Carrasco <javier.carrasco@...fvision.net>
Cc: Alessandro Zummo <a.zummo@...ertech.it>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, linux-rtc@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: rtc: nxp,pcf8563: add hiz-output
property
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
Powered by blists - more mailing lists