From nobody Mon Feb 9 06:25:29 2026 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) (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 46CB91E5B72 for ; Sat, 1 Mar 2025 17:36:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.11.138.130 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740850590; cv=none; b=WmtcUB43lp7yxzKk4orInfPdRoKQJGQWk3F5fsLLYBgiyjyYG/oGUwJRXWlQOWQbxrhjCVxBTlFWEUi7KTfRC2PXWPbbd58bt0WRgzfCXCeYquQ2VW8zH1YVn74ThDuif+0AOjufI9Ea5kBFHF20O0kY26oAYR8yiR7cToG+HVc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740850590; c=relaxed/simple; bh=4cFrJzdvIBeLK1E4VwP8M4rBsGeMFMns4LjpE0CsqYo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=scYlpV30C7mTWB2Tv6i7IfZLx4/HoEQVot761+iMoxsmVDNTeMua2FXECHGWaRaw3Z4gZ1d+trTPvC2VXoEXqmHiBC22uKHyF0ZPEdUjDBhUmWlNeaoAKipjPAjKXBUhKWHlsncDhQrzmCjRdZSgrX3j6sQAfcZBfhwYV4VFF+Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de; spf=pass smtp.mailfrom=sntech.de; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b=0fBkTHGP; arc=none smtp.client-ip=185.11.138.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sntech.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b="0fBkTHGP" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=khpROQz+QoHslWzkgE9bCS7jGbs+TMKrHMOcimF7a4I=; b=0fBkTHGP4ldi2nAVA5K4i25Xtb YZRlvA0+aq8oHnqqyaVNwNweokElJnVn1SG7vorhi89gKFsUmamxLngSd/2On6B/AGMX1ey0zpWdk +lw+LtXd7yEaHE47Pv4h7JvwX3dLw9WHayFqWATSuGcp6FYn7kOEF8PAeRpkuTdB3AkKfGJSwFtge 0Ayf1wnHf4p8rjIHq2qkjnzk+c8vWNA2EhZ1zG/GyZs/IL2IBF9E2xzlhFdtpd0VaYaU3ufXroD37 iW6pS+bT5TkovpbD/Wu9IeAHBOw+BVs+CzS+hxzxZpcYlq1fiy4NsUVRocyBYuMzpKeWt17S9uTZ/ Nvf91OKw==; Received: from i53875b47.versanet.de ([83.135.91.71] helo=localhost.localdomain) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1toQkn-0001Tm-OM; Sat, 01 Mar 2025 18:35:57 +0100 From: Heiko Stuebner To: heiko@sntech.de Cc: andy.yan@rock-chips.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, quentin.schulz@cherry.de, Heiko Stuebner Subject: [PATCH v2 1/2] drm/rockchip: lvds: move pclk preparation in with clk_get Date: Sat, 1 Mar 2025 18:35:46 +0100 Message-ID: <20250301173547.710245-2-heiko@sntech.de> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250301173547.710245-1-heiko@sntech.de> References: <20250301173547.710245-1-heiko@sntech.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Heiko Stuebner The LVDS block needs a separate pclk only on some socs, so currently requests and prepares it in the soc-specific probe function, but common code is required to unprepare it in the error path or on driver remove. While this works because clk_unprepare just does nothing if clk is NULL, this mismatch of who is responsible still is not very nice. The clock-framework already has a helper for clk-get-and-prepare even with devres support in devm_clk_get_prepared(). This will get and prepare the clock and also unprepare it on driver removal, saving the driver from having to handle it "manually". Reviewed-by: Quentin Schulz Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/rockchip/rockchip_lvds.c | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/roc= kchip/rockchip_lvds.c index 385cf6881504..ecfae8d5da89 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -448,15 +448,13 @@ struct drm_encoder_helper_funcs px30_lvds_encoder_hel= per_funcs =3D { static int rk3288_lvds_probe(struct platform_device *pdev, struct rockchip_lvds *lvds) { - int ret; - lvds->regs =3D devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(lvds->regs)) return PTR_ERR(lvds->regs); =20 - lvds->pclk =3D devm_clk_get(lvds->dev, "pclk_lvds"); + lvds->pclk =3D devm_clk_get_prepared(lvds->dev, "pclk_lvds"); if (IS_ERR(lvds->pclk)) { - DRM_DEV_ERROR(lvds->dev, "could not get pclk_lvds\n"); + DRM_DEV_ERROR(lvds->dev, "could not get or prepare pclk_lvds\n"); return PTR_ERR(lvds->pclk); } =20 @@ -480,12 +478,6 @@ static int rk3288_lvds_probe(struct platform_device *p= dev, } } =20 - ret =3D clk_prepare(lvds->pclk); - if (ret < 0) { - DRM_DEV_ERROR(lvds->dev, "failed to prepare pclk_lvds\n"); - return ret; - } - return 0; } =20 @@ -728,20 +720,15 @@ static int rockchip_lvds_probe(struct platform_device= *pdev) dev_set_drvdata(dev, lvds); =20 ret =3D component_add(&pdev->dev, &rockchip_lvds_component_ops); - if (ret < 0) { + if (ret < 0) DRM_DEV_ERROR(dev, "failed to add component\n"); - clk_unprepare(lvds->pclk); - } =20 return ret; } =20 static void rockchip_lvds_remove(struct platform_device *pdev) { - struct rockchip_lvds *lvds =3D platform_get_drvdata(pdev); - component_del(&pdev->dev, &rockchip_lvds_component_ops); - clk_unprepare(lvds->pclk); } =20 struct platform_driver rockchip_lvds_driver =3D { --=20 2.47.2