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 4F4DDCA0ED3 for ; Mon, 2 Sep 2024 10:41:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zWWCgOPtFspoggG7+OMLKZKpBUJ4rokojwECnjcrCcM=; b=EpibSmQJlxzVwLU/7jTzQMxEWH g1VOaIIck3bqVQiqsQloIImlmsVmblx1Ng7nUZtYZ90DTtez8Ph9ScYnCYq6uUCNSeHtDj5HPRFFn CpN/8/fYhVwHYYIHdGgHqbzla/2iS9xpyXcgiE0pRhnXPriZjSjLvkiliSsbNHDHSLVR8Ue5YpTyZ Tl79BMf7++tuynT5xEM3e0slmYH7+eDM2S3f6ja2F7ZYmlII/VTBU5wp1T3If0Pi8j6zYWaTjpwa8 wBqu5VrwMIVzixJjy6AW/MKuolWvUHZNbqZwligE1jwNbo+/kExDe5Q7iKs+zWCaXCDKBaIP3Xz3A cAZ5LzXg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sl4VD-0000000Dxd8-1wIc; Mon, 02 Sep 2024 10:41:43 +0000 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sl4UI-0000000DxRC-12LA for linux-arm-kernel@lists.infradead.org; Mon, 02 Sep 2024 10:40:48 +0000 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-42bb4f8a4bfso21809935e9.1 for ; Mon, 02 Sep 2024 03:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1725273645; x=1725878445; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zWWCgOPtFspoggG7+OMLKZKpBUJ4rokojwECnjcrCcM=; b=cUv1jd3vbTcAswXWODkzilzzCiwLZwFuHVp9hIZ/+1JCqnS5bu0hbvz/hw3GPbzh3K 99NajJ+r75Xg3oIYUPrKxAkrk+2/R/IG2so8MilN4r7CHI0GnYBQnX7mcIlEq7VIZCBa qzYRJz5MMRhd73deMPwihkYNo3WF+NDttZBwCxHtomvZMTxgnfjTUBcnl620Begx5c+3 Rp/oyJO3qbbqpJOTZBEUYpqoBBaDomEnlljdLLeSxHyXUYhLPVrPrKKlYnVK8iV9qYPa zH2QE8rswQ9nBlK/As+clzwKnEjBzej742kWT6YtOCFAaXcMv4XSVBFsYBR6EP79dCCX 4h8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725273645; x=1725878445; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zWWCgOPtFspoggG7+OMLKZKpBUJ4rokojwECnjcrCcM=; b=PQRiylNdN0DzP75OZJ1S/OgIg1lVZFCEXd1JRb0UCZFdH1RRExhUBTVzZrXBK7xbf1 XZLYG80EtS5uzizIfXVI9LgT5u5uIt85uRTTEGg2l8GjggcV79kT4tqU+6NyUHB620kV how/II25qHb5H3zszuTxKiHEQtJEEpOTKKj2hXGRdjMCmQ6g5bqOJAdk8CEPt6K5aMsD wXtrY6PgHVQLKJ+nta2TY5nRYsgEDS6WEQVaq7y1jbBGzH7TBOivqgDXPUN180LIN6r7 u0V8et1Oxbbyr/UgwjzxYQ+Z3kG+bpdM0zUV9nIVz7QfzC8tl6aEWnYXEiZu4oP63un/ G1aQ== X-Forwarded-Encrypted: i=1; AJvYcCXqKZ2Ycr/f6Bg910JQT6gPUren3nFdoZreYq9e2qIUq/qMn+LlBFbX59/sfQmoqD1qZ+ht+l6aW45wrC/EgYiP@lists.infradead.org X-Gm-Message-State: AOJu0YxuiSLFW1A4FDjtXnkDTgnALzKLKSC1jAR2b20tvi7dhjm3Qu18 OkSR/fjmuPQ+7clihjM/QMpUJ0aFBxSiKKg4YkvS/cH/Ndhfspdweeh9rYsVLzLaHBOjU69VFjT g X-Google-Smtp-Source: AGHT+IEniJ2zOfbNHplbZjwpzuwiNjNlpRHzMFPmgRBRzmpJXPHJZQY3Y0Tn4zQKdT5Es5pJWppmSw== X-Received: by 2002:a05:600c:1c18:b0:424:a7f1:ba2 with SMTP id 5b1f17b1804b1-42bb4e9f61bmr76021345e9.17.1725273644573; Mon, 02 Sep 2024 03:40:44 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bbc127ec5sm105407055e9.19.2024.09.02.03.40.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Sep 2024 03:40:44 -0700 (PDT) Message-ID: <35dc7414-f5bd-4ed4-bfa1-f723f4f0078c@tuxon.dev> Date: Mon, 2 Sep 2024 13:40:41 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC Content-Language: en-US To: Biju Das , Ulf Hansson Cc: "vkoul@kernel.org" , "kishon@kernel.org" , "robh@kernel.org" , "krzk+dt@kernel.org" , "conor+dt@kernel.org" , "p.zabel@pengutronix.de" , "geert+renesas@glider.be" , "magnus.damm@gmail.com" , "gregkh@linuxfoundation.org" , "mturquette@baylibre.com" , "sboyd@kernel.org" , Yoshihiro Shimoda , "linux-phy@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" , "linux-pm@vger.kernel.org" , Claudiu Beznea References: <20240822152801.602318-1-claudiu.beznea.uj@bp.renesas.com> <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev> <5556d176-cca7-492c-ba21-48256d5d6338@tuxon.dev> <590a4fb2-24b2-432b-92db-534c5a52ed0b@tuxon.dev> From: claudiu beznea In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240902_034046_328127_61F9960C X-CRM114-Status: GOOD ( 16.59 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 02.09.2024 12:18, Biju Das wrote: >>>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux? >>>> As you know, the RZ/G3S USB PM code is already prepared. This is also >>>> configuring these signals when going to suspend/exiting from resume. >>>> W/o configuring properly these signals the USB is not working after a suspend/resume cycle. >>> One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan to handle system transitions >> there?? >> >> As I mentioned, the settings in these registers may be changed by intermediary booting applications. >> Depending on that, Linux need to control it also on probe for USB to work (it should be the same with >> PCIe, these signals seems similar from HW manual description). > You mean system transition settings will be override by U-boot, so Linux needs to restore it back?? It was talking about booting... You proposed to handle SYSC signals from TF-A in a discussion about system power transitions: "One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan to handle system transitions" (I was guessing the "system transition" statement there refers to power states transitions, ALL_ON <-> AWO/VBAT) and I gave the booting process as a counter example: if we handle it in TF-A it may not be enough as these signals might be changed by intermediary booting applications (e.g., U-Boot). To conclude, there are 3 scenarios I see where these signals need to be handled: 1/ booting 2/ suspend to RAM 3/ driver unbind/bind In case of booting: if we have TF-A to set signals there might be intermediary booting applications (e.g. U-Boot) that set these signals also. If it leaves it in improper state and Linux wants to use USB then the USB will not work (if Linux doesn't handle it). In case of suspend to RAM: as TF-A is the only application in the suspend to RAM chain, it should work handling it in TF-A. In case of unbind/bind: currently we don't know if these signals introduces any kind of power saving so asserting/de-asserting them in Linux may be useful from this perspective, if any. Either way, I think Linux should handle all that it can to make the devices work and not rely on third party applications. Thank you, Claudiu Beznea > > Cheers, > Biju