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 47A98C4167B for ; Wed, 13 Dec 2023 15:42:42 +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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NMT7l6KKv3LyeinCeIgqkhqwEKERSFlzcTBTywZb/ds=; b=KVbbePbu33hRAR /WbEGKlXEJFg3qUoX+xdUTpRR+cI5BmQRhnxY1iDwb7JerkrWiWOWxd0nZkaydNsJiijzgO6rIBGg 2MeiTtmmu68BEbQEV5GySeZgKNcVk2cfShM2Hv95yi64dpSFSqxBQRXpYXGQZdm6oX9Pw2qmLt3/m APMCQWNqkvP9+q82k2zddHxSlhl5m/+snm8LRB6rnHj0VR9quG4cPumscyy1+qsHHtbP2lKg7ygW/ yGzDPZwsEhjucHEZLr0dsmJPxwxK7RpQCAiRxZxhUm0MFgYDxzaLhJtMAD9+mngNWQ3beuVnfA0eE mxEbNI0BplYogjOwT76Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rDRNH-00FIat-07; Wed, 13 Dec 2023 15:42:15 +0000 Received: from mail-pf1-f181.google.com ([209.85.210.181]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rDRNC-00FIX1-2P for linux-arm-kernel@lists.infradead.org; Wed, 13 Dec 2023 15:42:13 +0000 Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-6ce32821a53so3893388b3a.0 for ; Wed, 13 Dec 2023 07:42:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702482128; x=1703086928; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7dGqDRJ0w9nVIHFYvwy3H2NeZxOqyG5Sv0/1APrHxnU=; b=HZcKBEAf3bbUHFIAwincQo6Jv62/GKG65L49QBvFZH4eXJnXu9xhUaUWHy633EFc8Y MSlFwEHIAJb9mYtEfFjX0eZx+2qlSPYMr41pFnVAqSC6BfgZLHu5ELsCBeCWj8Xii/g8 Ch1gmNEL2wDODRQsduCDtaaWJbc4LT+kBkp54kjDiGBmIS9agg8xuq7saoRg8CtT6yuA 0G9O/3wPDzv06CFvPTW2Gi1PcPN3ZvKqvSpkt1oMWdniv2NeplksVDILslVNdKDEHbz9 u9Q9eMFixUnuldmKMOiXEYNJMx/lJmkoJGiATkg8SLBqUUEZjO049lvzlcIS92LTcs+H g4/w== X-Gm-Message-State: AOJu0YxqwmEEcDAidiDa9ZzNRZIzZUwaTfuVh/oF0GhaJxZf10kznsOU 5LsDTFtilcDCWaWqdQ2I6Nwoww== X-Google-Smtp-Source: AGHT+IHopEAauysSfb8ROWt34w1/YfNc58y9l66Fy5uQbu6hMwlQZkVrsT+zflkJyHs9vn/ZgDLSHA== X-Received: by 2002:a05:6a00:3095:b0:6ce:2731:c247 with SMTP id bh21-20020a056a00309500b006ce2731c247mr2696557pfb.54.1702482128421; Wed, 13 Dec 2023 07:42:08 -0800 (PST) Received: from localhost (75-172-121-199.tukw.qwest.net. [75.172.121.199]) by smtp.gmail.com with ESMTPSA id u23-20020aa78497000000b006d0d83a11afsm1064030pfn.203.2023.12.13.07.41.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 07:42:07 -0800 (PST) From: Kevin Hilman To: Tony Lindgren 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 In-Reply-To: <20231209035900.GW5169@atomide.com> References: <20231114073209.40756-1-tony@atomide.com> <7h5y1c7c0q.fsf@baylibre.com> <20231207060854.GQ5169@atomide.com> <7hedfwd3co.fsf@baylibre.com> <20231209035900.GW5169@atomide.com> Date: Wed, 13 Dec 2023 07:41:44 -0800 Message-ID: <7hcyvam7nr.fsf@baylibre.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231213_074210_788744_2116A0D7 X-CRM114-Status: GOOD ( 22.18 ) 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 Tony Lindgren writes: > * 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. OK, thanks. >> 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. OK, in that case, this all makes sense to me. Reviewed-by: Kevin Hilman Kevin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel