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 89DE3CA0EF9 for ; Fri, 30 Aug 2024 09:31:08 +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: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=pG9oo89m0Mfwl0OcNnkoux1O7Jv2EBGVMR7oc8+mQEA=; b=wYU7ztq0EOBzn9 5sJRhEB6qr7s4mYjMT1mM6H7XCaiM9u7VqAh6aoSudngYdMiAcIzvOlUuy6Lu+6zYjkryMc5XERQD Ul0dWUWTfmH/c1vPdIBtUS64groFZBUl+5OVFquM+Mu92Zim/hN3nL8yW5x90Cf6+p2p2CPjCl3O/ fkui4X6pWbLns5C0bI9NRTybiK4jUDR9kuIZjVsAIBK/9GRrrTlveGCK3WPLdUAmfU+EJU6749p33 6hKFopbTG2hz15at+Zidt6w+Jdwyq7eXCXt4zvcnSFEs4FZ8ZmzWAvpYYL1B1/uLxWntCONooFIL3 Af4baQRaZhOVy+95BLzA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjxyG-00000005ZEe-131W; Fri, 30 Aug 2024 09:31:08 +0000 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjwu6-00000005K91-2DNv for linux-phy@lists.infradead.org; Fri, 30 Aug 2024 08:22:47 +0000 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4281d812d3eso17028545e9.3 for ; Fri, 30 Aug 2024 01:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1725006164; x=1725610964; 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=zchK+tZfRdJr/B0VNKRrEBtLoJmeJfsr2YpFzQ08IdE=; b=qIqR2qafk7Hu69phmpTXelIbSWgjKhYsHc11o+6Uql5uavAxDv9cV+k0xjzKs4WOUe DzRQfEgtHtdsa0tei9YEDux2wKvyc6jI41mNkX04fQ7cLy4NXxje8UhcAMiibmQAjYYi 2cmnIagV0qCoOpEbFcb8DJXZ2NQde6AIL2QCjUXKWm5pEtrxIQ0V/Xyp9z6jU4pwJp5E smunqZkuV61DcRbpMZjSrYjek3Qh3qEMOtnGwV2FAhvR0YSJ7sFmpM2txXgQr33KaFqn XNAdjF0epaasSXK53P/68NmcvkJ5VS5uKp/T+UmQU+sAif3iEG9f6j4lToQQdV5FcaW5 AN/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725006164; x=1725610964; 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=zchK+tZfRdJr/B0VNKRrEBtLoJmeJfsr2YpFzQ08IdE=; b=j7/NYsgR0s3/OjuC+GzMNaPa72dmQn928U7FhFQZQ/GaqTrYm4FOo5ik4kvxl6JOlp /MoR1n5taWl/CKtD0AcJpxU453keYcU/0r4jTZ57TZGcCQZ1uLuS92kyBceKlgaHfzk0 mV68cDVbKALJaf6SYB8jSqkkAScAHMkDK3ls2PvAZbwIz6w9r7p9WiHtltPxB5PVQSiu xCEa3DaM5T7ljVzj2v3SHWqTVttypkifxcuSZoibr7+znbl367hiLlh7zT1wGslGIPJy zDBklB3gIRRwX/qshm6jsj4eaksFrHguFde5bWmk6zjLN5LnxtvVrLP92GbEOwp/fimi WGdw== X-Forwarded-Encrypted: i=1; AJvYcCW8PLeHam5QnL4uc52+r+EoFv7/0PG4Eb1A/K8sC9EBdUdvURKpw3ZlzSUkp8nJ0oiW5vHlGakaFeQ=@lists.infradead.org X-Gm-Message-State: AOJu0YwnJBqjGD3fd25xzBkGm7bDXi/gvu07/go3JDddTBDC+xZNlHNn 8TCXFV/F4JFZQEZkDtUyL2AxqV+pEfdTRl+5A7rH4r0D7KipqJ89jb484LQY5hY= X-Google-Smtp-Source: AGHT+IF8ZkJGKUmuglZKyShKgzTB0GuKfWBu6xay0mGYscvHuYinOaW5h5J83vGVNlCFB6KS0zIxvQ== X-Received: by 2002:a05:600c:3ca2:b0:426:5520:b835 with SMTP id 5b1f17b1804b1-42bb01ae206mr53646705e9.5.1725006164296; Fri, 30 Aug 2024 01:22:44 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bb87f7fccsm31864805e9.46.2024.08.30.01.22.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Aug 2024 01:22:43 -0700 (PDT) Message-ID: <99bef301-9f6c-4797-b47e-c83e56dfbda9@tuxon.dev> Date: Fri, 30 Aug 2024 11:22: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: 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.uh@renesas.com, biju.das.jz@bp.renesas.com, 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> From: claudiu beznea In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240830_012246_611945_501175AB X-CRM114-Status: GOOD ( 24.55 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org Hi, Ulf, On 29.08.2024 18:26, Ulf Hansson wrote: > On Thu, 22 Aug 2024 at 17:28, Claudiu wrote: >> >> From: Claudiu Beznea >> >> Hi, >> >> Series adds initial USB support for the Renesas RZ/G3S SoC. >> >> Series is split as follows: >> >> - patch 01/16 - add clock reset and power domain support for USB >> - patch 02-04/16 - add reset control support for a USB signal >> that need to be controlled before/after >> the power to USB area is turned on/off. >> >> Philipp, Ulf, Geert, all, >> >> I detailed my approach for this in patch >> 04/16, please have a look and let me know >> your input. > > I have looked briefly. Your suggested approach may work, but I have a > few thoughts, see below. > > If I understand correctly, it is the consumer driver for the device > that is attached to the USB power domain that becomes responsible for > asserting/de-asserting this new signal. Right? Right! > > In this regard, please note that the consumer driver doesn't really > know when the power domain really gets powered-on/off. Calling > pm_runtime_get|put*() is dealing with the reference counting. For > example, a call to pm_runtime_get*() just makes sure that the PM > domain gets-or-remains powered-on. Could this be a problem from the > reset-signal point of view? It should be safe. From the HW manual I understand the hardware block is something like the following: USB area +-------------------------+ | | | PHY --->USB controller | SYSC --> | ^ | | | | | PHY reset | +-------------------------+ Where: - SYSC is the system controller that controls the new signal for which I'm requesting opinions in this series - PHY reset: is the block controlling the PHYs - PHY: is the block controlling the USB PHYs - USB controller: is the USB controller Currently, I passed the SYSC signal handling to the PHY reset driver; w/o PHY reset the rest of the USB logic cannot work (neither PHY block nor USB controller). Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe and pm_runtime_put() in remove. The struct reset_control_ops::{assert, deassert} only set specific bits in registers (no pm_runtime* calls). The PHY driver is taking its PHY reset in probe and release it in remove(). With this approach the newly introduced SYSC signal will be de-asserted/asserted only in the PHY reset probe/remove (either if it is handled though PM domain or reset control signal). If the SYSC signal would be passed to all the blocks in the USB area (and it would be handled though PM domains) it should be no problem either, AFAICT, because of reference counting the pm_runtime_get|put*() is taking care of. As the PHY reset is the root node the in the devices node tree for USB the reference counting should work, too (I may miss something though, please correct me if I'm wrong). If the SYSC signal would be handled though a reset control driver (as proposed in this series) and we want to pass this reference to all the blocks in the USB area then we can request the reset signal as shared and, AFAIK, this is also reference counted. The devices node tree should help with the order, too, if I'm not wrong. Thank you for looking at this, Claudiu Beznea > > [...] > > Kind regards > Uffe -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy