From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 585C5C4167B for ; Sat, 9 Dec 2023 03:59:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=boIcgBVKYl62FK1tdJA1s2M2TW/CRu0QrucuUqmgKXY=; b=iKfI+rPo7IBx6m oxrmHEtCBZfFflUuFFSaLwtAaP4r1fEREXs/BXsiwcfQPj66c2o9eWETz06loM8Sq+VDvHZjmOSj7 ZsYpnqjGxf7dHrgIjbIq3/Ukhfur5SmsxAr/fvBTo/3l9xAjOSBwfJvWHxCvrkYmM2VpL+5QEKiwz b1Gn+lyCif2gWF/TzMnvcP6Qd3EQCE2yYHhxVxAwdo5AmNQ+5njK6DZHIvYu2s0DAOY3pxIzAOeZW 0bBkSDCXJYZfRVMySL1Q+QV3Xuze2Vnr9/0oMkvgsh5HHw5Ht0QLIS1RHV5vbY/fABjTIiRAr3Cci vyZEg2kch2sG4jwx2Lvg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rBoUr-00H2r6-02; Sat, 09 Dec 2023 03:59:21 +0000 Received: from mail5.25mail.st ([74.50.62.9]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rBoUn-00H2qY-2E for linux-arm-kernel@lists.infradead.org; Sat, 09 Dec 2023 03:59:19 +0000 Received: from localhost (91-158-86-216.elisa-laajakaista.fi [91.158.86.216]) by mail5.25mail.st (Postfix) with ESMTPSA id 4315F60504; Sat, 9 Dec 2023 03:59:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=atomide.com; s=25mailst; t=1702094354; bh=6qStuqkA2YXHsC9AdwTd6rpYJTKwRcTek2CqtNee2VE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tDk7szmz9JUFUAZ1ckvgVBQsoeAhvAo9u6S23z9NBbxNg6rdjuBylHBk3B9Pg6VKr YGcBd/z8xJ4/XiTHVrHKvJfUJC0j9Y9n/2wgNxwoQr/9NdKhBo4vvLo5O6g/uWDYnR qNfBKVdjEF4R1kx0gM7lkUKAGu+949cEMWj0T8EuboNIua7kEVNoLxHzpnOaOOmIpb 1lUFdr5lsLIKn0jDPcScCC8OyDWtuHYhV+P6l/S4VOGrgdbz9oXYrit2jAQbpaVh0y WQrINLGVDETyt5IGLbhd4oO01mhjmpz+DrikMdyfukP6mdrWxiEwf+WsrOb6fDJ/Ar Nt+XihBQhRURw== Date: Sat, 9 Dec 2023 05:59:00 +0200 From: Tony Lindgren To: Kevin Hilman Cc: Nishanth Menon , Vignesh Raghavendra , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Dhruva Gole Subject: Re: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0 Message-ID: <20231209035900.GW5169@atomide.com> References: <20231114073209.40756-1-tony@atomide.com> <7h5y1c7c0q.fsf@baylibre.com> <20231207060854.GQ5169@atomide.com> <7hedfwd3co.fsf@baylibre.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7hedfwd3co.fsf@baylibre.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231208_195918_043491_C0FD1099 X-CRM114-Status: GOOD ( 22.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Kevin Hilman [231208 17:13]: > Tony Lindgren writes: > > > * Kevin Hilman [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 = ; > >> > + 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. One more thing to clarify, there's nothing stopping also mapping the needed resources for the child IP too if needed by the driver or the dts binding. The calls for resources by the 8250 driver just won't do anything as the resources are already enabled by the parent. > In that case, shouldn't the same be done for the other wakeup sources > there (e.g. wkup_rtc0) ? Yes it should be done for devices with the wake-up path wired like wkup_rtc0. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel