From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDDC81C84B9 for ; Fri, 13 Jun 2025 09:49:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.118.77.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749808184; cv=none; b=czQybZQKjdpZ4WAvEOE7BfMds++tmEvtyWa4GWj2qKnYQevDPwCuHqsFd0oN3y8umQKgkl9yg6s52P0+n18lSbA1uqYuMVfStZ25/Rl9d3aRtJ7RGsr52RqeibuvY8y+3nFnqBMjF5s4Cq9bKtzsBPaHyHUbIFkqAznV5B4Drs8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749808184; c=relaxed/simple; bh=E9g4iKJ+yCKvXWA3cSjWNe7gwUJseaOGz0cRtZ/FmX0=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:In-Reply-To: Content-Type:References; b=Hpzd0kUlBPxWMG+atYakJb19+aFkYIemVtHZNsiKzmHnklrmavvzEa9tvGu7evFBnjmXJjC/enQwBH9HKgnPORQCo0qm2TzPfy4mrqWvOD9ruklwf6hL7S/DB2O1SUlwn1lUEuo9lcQKYjQHiZczRXGvuJmyZGxP6QgcWyEmGKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=KeXXtrQr; arc=none smtp.client-ip=210.118.77.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="KeXXtrQr" Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20250613094940euoutp018796f35552839e8e9b1702241a856e71~IkUTUXUu41980019800euoutp01V for ; Fri, 13 Jun 2025 09:49:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20250613094940euoutp018796f35552839e8e9b1702241a856e71~IkUTUXUu41980019800euoutp01V DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1749808180; bh=kh1WI/bcozY1n6lzmehL+B2GaHGpJodSvRw79/7fyDs=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=KeXXtrQrpOo9k9DvNiYd5/p0RN5OETv7UZnLk2u/rgXrUymIm52y9w85Yr7XC/g/t ol8m6jQ7WrEMV/OQwyzA/v6GLEdTz9UB5OCdWztyv53RRzBRZfI8K3/IbkePmcs9Ki WK165kGbRXZvrbmDLUIR30Nzoczywx3Q9x0rfURw= Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20250613094939eucas1p223e7a49c4cdbbfbeb66f81b1c4d38a64~IkUS23hRn0145001450eucas1p26; Fri, 13 Jun 2025 09:49:39 +0000 (GMT) Received: from [192.168.1.44] (unknown [106.210.136.40]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20250613094938eusmtip1d772fb1eb26491c3a808b58eca12daed~IkURy2A162383923839eusmtip1j; Fri, 13 Jun 2025 09:49:38 +0000 (GMT) Message-ID: <44090712-0635-47bf-b73d-d9b16ec446a4@samsung.com> Date: Fri, 13 Jun 2025 11:49:38 +0200 Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/8] drm/imagination: Use pwrseq for TH1520 GPU power management From: Michal Wilczynski To: Krzysztof Kozlowski , Bartosz Golaszewski , Matt Coster , "krzk+dt@kernel.org" Cc: Drew Fustini , Guo Ren , Fu Wei , Rob Herring , Conor Dooley , Philipp Zabel , Frank Binns , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Ulf Hansson , Marek Szyprowski , linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, dri-devel@lists.freedesktop.org Content-Language: en-US In-Reply-To: Content-Transfer-Encoding: 7bit X-CMS-MailID: 20250613094939eucas1p223e7a49c4cdbbfbeb66f81b1c4d38a64 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250529222405eucas1p18ed1254bf1b2d78468734656fec537e1 X-EPHeader: CA X-CMS-RootMailID: 20250529222405eucas1p18ed1254bf1b2d78468734656fec537e1 References: <20250530-apr_14_for_sending-v3-0-83d5744d997c@samsung.com> <20250530-apr_14_for_sending-v3-3-83d5744d997c@samsung.com> <20250603-whispering-jaybird-of-thunder-f87867@kuoka> <59cc6827-1602-402a-9279-96ad6285cff4@kernel.org> On 6/13/25 10:25, Michal Wilczynski wrote: > > > On 6/13/25 08:44, Krzysztof Kozlowski wrote: >> On 11/06/2025 14:01, Michal Wilczynski wrote: >>> >>> However, this leads me back to a fundamental issue with the >>> consumer side implementation in the generic pvr_device.c driver. The >>> current fallback code is: >>> >>> /* >>> * If the error is -EPROBE_DEFER, it's because the >>> * optional sequencer provider is not present >>> * and it's safe to fall back on manual power-up. >>> */ >>> if (pwrseq_err == -EPROBE_DEFER) >>> pvr_dev->pwrseq = NULL; >>> >>> As Krzysztof noted, simply ignoring -EPROBE_DEFER is not ideal. But if I >>> change this to a standard deferred probe, the pvr_device.c driver will >> >> Why? You have specific compatible for executing such quirks only for >> given platform. I realized now that you may have meant the "thead,th1520-gpu" compatible, not the "thead,th1520" SoC compatible. In any case, the whole reason for using the pwrseq framework is to avoid polluting the generic driver with SoC specific logic and instead offload that responsibility to a pwrseq provider. Therefore, I can't simply add a check like if (compatible == "thead,th1520-gpu") to the generic driver to decide whether to get a power sequencer. This entire matching responsibility was intended to be offloaded to the pwrseq framework. > > This is due to how the pwrseq API works; it constructs a bus on which > provider devices may appear at any time. With the current API, there is > no way to express that a provider for a specific target will never > appear. ('gpu-power' is the generic target name, and of course, more > specific binding is handled in the provider's .match callback - based on > the compatible and the node phandle like discussed previously). > > For all other supported SoCs, no such provider will ever appear on the > bus, and the current pwrseq API doesn't allow a generic consumer to know > this. > > However, your suggestion of handling this with a platform specific > driver is a good path forward. It would still require a minimal addition > to the pwrseq API to work. For example, a new SoC specific driver for > "thead,th1520" could call a new function like > pwrseq_enable_optional_target("gpu-power") during its probe. This would > signal to the pwrseq core that this target is expected on the platform. > Therefore, when the Imagination driver later calls pwrseq_get() on a > TH1520, it would correctly result in either a match or a deferral. > > On all other platforms, this optional target would not be enabled. The > pwrseq_get() call would then immediately return -ENODEV instead of > deferring, which solves the problem and allows the other supported SoCs > to probe correctly. > > I wonder whether Bartosz would be okay with such an addition. > >> >>> break on all other supported SoCs. It would wait indefinitely for a >>> pwrseq-thead-gpu provider that will never appear on those platforms. >>> >> >> >> >> Best regards, >> Krzysztof >> > > Best regards, Best regards, -- Michal Wilczynski