From: Kevin Hilman <khilman@kernel.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Dhruva Gole <d-gole@ti.com>
Subject: Re: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0
Date: Fri, 08 Dec 2023 09:13:43 -0800 [thread overview]
Message-ID: <7hedfwd3co.fsf@baylibre.com> (raw)
In-Reply-To: <20231207060854.GQ5169@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Kevin Hilman <khilman@kernel.org> [231205 18:14]:
>> I'm a little confused why these power-domain and clocks stay here and
>> are not moved under the wkup_uart0 node...
>
> The resources are also needed by the interconnect target module. It's the
> wrapper IP for the child device(s). In this case there's one chip 8250 IP
> instance. In some other devices there can be multiple child IP devices
> wired to one target module.
>
>> > - clock-names = "fclk";
>> > - status = "disabled";
>> > + clock-names = "fck";
>> > + #address-cells = <1>;
>> > + #size-cells = <1>;
>> > + ranges = <0 0 0x2b300000 0x100000>;
>> > +
>> > + wkup_uart0: serial@2b300000 {
>> > + compatible = "ti,am64-uart", "ti,am654-uart";
>> > + reg = <0 0x100>;
>> > + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> > + status = "disabled";
>>
>> ...here.
>>
>> The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
>> me those should be in the wkup_uart0 node.
>
> Those resources are also needed for the parent target module for revision
> detection, quirks, reset, idle register configuration, and to probe the
> child devices.
>
> Here the 8250 IP can be set to status = "reserved" when used by the
> firmware, and 8250 not touched by Linux. However, the parent interconnect
> target module still needs to be configured for idle registers and wake-up
> path register bit so the wake-up from deeper suspend states works.
OK, makes sense. Thanks for the clarification.
In that case, shouldn't the same be done for the other wakeup sources
there (e.g. wkup_rtc0) ?
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Dhruva Gole <d-gole@ti.com>
Subject: Re: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0
Date: Fri, 08 Dec 2023 09:13:43 -0800 [thread overview]
Message-ID: <7hedfwd3co.fsf@baylibre.com> (raw)
In-Reply-To: <20231207060854.GQ5169@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Kevin Hilman <khilman@kernel.org> [231205 18:14]:
>> I'm a little confused why these power-domain and clocks stay here and
>> are not moved under the wkup_uart0 node...
>
> The resources are also needed by the interconnect target module. It's the
> wrapper IP for the child device(s). In this case there's one chip 8250 IP
> instance. In some other devices there can be multiple child IP devices
> wired to one target module.
>
>> > - clock-names = "fclk";
>> > - status = "disabled";
>> > + clock-names = "fck";
>> > + #address-cells = <1>;
>> > + #size-cells = <1>;
>> > + ranges = <0 0 0x2b300000 0x100000>;
>> > +
>> > + wkup_uart0: serial@2b300000 {
>> > + compatible = "ti,am64-uart", "ti,am654-uart";
>> > + reg = <0 0x100>;
>> > + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> > + status = "disabled";
>>
>> ...here.
>>
>> The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
>> me those should be in the wkup_uart0 node.
>
> Those resources are also needed for the parent target module for revision
> detection, quirks, reset, idle register configuration, and to probe the
> child devices.
>
> Here the 8250 IP can be set to status = "reserved" when used by the
> firmware, and 8250 not touched by Linux. However, the parent interconnect
> target module still needs to be configured for idle registers and wake-up
> path register bit so the wake-up from deeper suspend states works.
OK, makes sense. Thanks for the clarification.
In that case, shouldn't the same be done for the other wakeup sources
there (e.g. wkup_rtc0) ?
Kevin
next prev parent reply other threads:[~2023-12-08 17:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 7:32 [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0 Tony Lindgren
2023-11-14 7:32 ` Tony Lindgren
2023-12-05 18:13 ` Kevin Hilman
2023-12-05 18:13 ` Kevin Hilman
2023-12-07 6:08 ` Tony Lindgren
2023-12-07 6:08 ` Tony Lindgren
2023-12-08 17:13 ` Kevin Hilman [this message]
2023-12-08 17:13 ` Kevin Hilman
2023-12-09 3:59 ` Tony Lindgren
2023-12-09 3:59 ` Tony Lindgren
2023-12-13 15:41 ` Kevin Hilman
2023-12-13 15:41 ` Kevin Hilman
2023-12-15 16:00 ` Nishanth Menon
2023-12-15 16:00 ` Nishanth Menon
2023-12-18 7:28 ` Tony Lindgren
2023-12-18 7:28 ` Tony Lindgren
2023-12-18 16:19 ` Nishanth Menon
2023-12-18 16:19 ` Nishanth Menon
2023-12-19 7:06 ` Tony Lindgren
2023-12-19 7:06 ` Tony Lindgren
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=7hedfwd3co.fsf@baylibre.com \
--to=khilman@kernel.org \
--cc=d-gole@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nm@ti.com \
--cc=tony@atomide.com \
--cc=vigneshr@ti.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.