From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Jon Hunter <jonathanh@nvidia.com>,
devicetree@vger.kernel.org,
"open list:REAL TIME CLOCK (RTC) SUBSYSTEM"
<linux-rtc@vger.kernel.org>,
linux-tegra <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] dt-bindings: mfd: Document the RTC present on MAX77620
Date: Fri, 1 May 2020 15:53:09 +0200 [thread overview]
Message-ID: <20200501135309.GC51277@piout.net> (raw)
In-Reply-To: <CAL_Jsq+HzG8QT+kHUjqC8joDxfm1WM+N_F1ZwYXg7cL5faGxVA@mail.gmail.com>
On 01/05/2020 08:00:11-0500, Rob Herring wrote:
> > I don't think this is true because in the case of a discrete RTC, its
> > interrupt pin can be connected directly to a PMIC to power up a board
> > instead of being connected to the SoC. In that case we don't have an
> > interrupt property but the RTC is still a wakeup source. This is the
> > usual use case for wakeup-source in the RTC subsystem. Else, if there is
> > an interrupt, then we assume the RTC is a wakeup source and there is no
> > need to have the wakeup-source property.
>
> Yes, that would be an example of "unless the wakeup mechanism is
> somehow not an interrupt". I guess I should add not an interrupt from
> the perspective of the OS.
>
> So if the wakeup is self contained within the PMIC, why do we need a
> DT property? The capability is always there and enabling/disabling
> wakeup from it is userspace policy.
>
Yes, for this particular case, I'm not sure wakeup-source is actually
necessary. If the interrupt line is used to wakeup the SoC, then the
presence of the interrupts property is enough to enable wakeup.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Alessandro Zummo
<a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>,
Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"open list:REAL TIME CLOCK (RTC) SUBSYSTEM"
<linux-rtc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-tegra <linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/3] dt-bindings: mfd: Document the RTC present on MAX77620
Date: Fri, 1 May 2020 15:53:09 +0200 [thread overview]
Message-ID: <20200501135309.GC51277@piout.net> (raw)
In-Reply-To: <CAL_Jsq+HzG8QT+kHUjqC8joDxfm1WM+N_F1ZwYXg7cL5faGxVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/05/2020 08:00:11-0500, Rob Herring wrote:
> > I don't think this is true because in the case of a discrete RTC, its
> > interrupt pin can be connected directly to a PMIC to power up a board
> > instead of being connected to the SoC. In that case we don't have an
> > interrupt property but the RTC is still a wakeup source. This is the
> > usual use case for wakeup-source in the RTC subsystem. Else, if there is
> > an interrupt, then we assume the RTC is a wakeup source and there is no
> > need to have the wakeup-source property.
>
> Yes, that would be an example of "unless the wakeup mechanism is
> somehow not an interrupt". I guess I should add not an interrupt from
> the perspective of the OS.
>
> So if the wakeup is self contained within the PMIC, why do we need a
> DT property? The capability is always there and enabling/disabling
> wakeup from it is userspace policy.
>
Yes, for this particular case, I'm not sure wakeup-source is actually
necessary. If the interrupt line is used to wakeup the SoC, then the
presence of the interrupts property is enough to enable wakeup.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2020-05-01 13:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 17:08 [PATCH 1/3] dt-bindings: mfd: Document the RTC present on MAX77620 Thierry Reding
2020-04-17 17:08 ` Thierry Reding
2020-04-17 17:08 ` [PATCH 2/3] rtc: max77686: Make wakeup support configurable Thierry Reding
2020-04-17 17:08 ` Thierry Reding
2020-04-20 14:42 ` Jon Hunter
2020-04-20 14:42 ` Jon Hunter
2020-04-17 17:08 ` [PATCH 3/3] rtc: max77686: Use single-byte writes on MAX77620 Thierry Reding
2020-04-20 14:43 ` Jon Hunter
2020-04-20 14:43 ` Jon Hunter
2020-05-11 14:27 ` Alexandre Belloni
2020-05-11 14:27 ` Alexandre Belloni
2020-04-30 14:07 ` [PATCH 1/3] dt-bindings: mfd: Document the RTC present " Rob Herring
2020-04-30 14:15 ` Alexandre Belloni
2020-04-30 14:15 ` Alexandre Belloni
2020-05-01 13:00 ` Rob Herring
2020-05-01 13:00 ` Rob Herring
2020-05-01 13:53 ` Alexandre Belloni [this message]
2020-05-01 13:53 ` Alexandre Belloni
2020-05-08 11:02 ` Thierry Reding
2020-05-08 11:02 ` Thierry Reding
2020-05-11 14:28 ` Alexandre Belloni
2020-05-11 14:28 ` Alexandre Belloni
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=20200501135309.GC51277@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=a.zummo@towertech.it \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.