Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp2366987rwb; Fri, 20 Jan 2023 01:50:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXtLZ72y0tpmIzAov7HRmz4SpUB54UL21vVWaJ5ndeLi2tSdCa8ZcNKA5h6kwPKwy2Ct96Zl X-Received: by 2002:a17:90b:2685:b0:219:7d75:de7b with SMTP id pl5-20020a17090b268500b002197d75de7bmr14396129pjb.35.1674208255263; Fri, 20 Jan 2023 01:50:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674208255; cv=none; d=google.com; s=arc-20160816; b=zQCHq2VkJcbVTPbGFrCU9JilFmRIOiuMob9Pr+6ezGmjbTjcX34f4isr8baS+CRb7d FHiYxq9DU+m9hJJrm+MteY+nSUUi9kyEhqAH341SYDZ0426VYHlfuOebimE0MiBtapw2 GfsQY6SaLLBsYbZAGOslMDnNKp5HFIIsPMQMkAmf1yizuQHPKklXQEvnCgyWvcbPF5+L 34j84fXuWUmFcoOyefE8I+QzOTSnhLVsz3Ty9DPg9EezNIV5Chy2RltLYBwn5syprbDL YR/QbpHxXyK8asDLmEOFSE7qPf3h9ZHf5MwkGeVSbYFlZy5kE4swER5WZNHSh83Hrqo6 b3mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=YDH0xWiKzposqGL0Q4o0jmp1uSpy9t4zcqLpdfHk43w=; b=EPl9tGSN3sAj9xHavTw+I/LMgK45MDiie46u8Hb7aAZ40o9mq89ds18dksrJHZ0j2L KE4ejZtuA/BOiI2u6ML2JWQy4vaZDpuqMTyAmRWrSTL1u7JX9JZvy86nGgw2+NAeWSYk SKov3aN5rM+re37u45SKVxyIYBlLrStW7JvwwRXpkx8SURxhXxSOvIeHMlKeF/HJbgUo PPhAQV/qU60xxNAKy2teVPIHMGRIZHNH832dzSk6PQj7btWyB0Ts/GUBNj0qacJjOF/v pwUs17Oc3jgEoKtt1zr49wWLTF3nrMIHav3MdFJoUrLN0OV47CrbseNCdwC0rDKGVNbN Bo+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w2-20020a17090aaf8200b002265c110dbasi1927880pjq.28.2023.01.20.01.50.49; Fri, 20 Jan 2023 01:50:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229652AbjATJRb (ORCPT + 48 others); Fri, 20 Jan 2023 04:17:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230029AbjATJR3 (ORCPT ); Fri, 20 Jan 2023 04:17:29 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B8D4C14C for ; Fri, 20 Jan 2023 01:17:01 -0800 (PST) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pInVs-00022D-Ic; Fri, 20 Jan 2023 10:16:44 +0100 Received: from sha by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1pInVp-0004z4-60; Fri, 20 Jan 2023 10:16:41 +0100 Date: Fri, 20 Jan 2023 10:16:41 +0100 From: Sascha Hauer To: Alibek Omarov Cc: alexander.sverdlin@siemens.com, macromorgan@hotmail.com, Sandy Huang , Heiko =?iso-8859-15?Q?St=FCbner?= , David Airlie , Daniel Vetter , Rob Herring , Krzysztof Kozlowski , Michael Riesch , Peter Geis , Frank Wunderlich , Nicolas Frattaroli , Ezequiel Garcia , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] drm/rockchip: lvds: add rk3568 support Message-ID: <20230120091641.GL24755@pengutronix.de> References: <20230119184807.171132-1-a1ba.omarov@gmail.com> <20230119184807.171132-2-a1ba.omarov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230119184807.171132-2-a1ba.omarov@gmail.com> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 19, 2023 at 09:48:03PM +0300, Alibek Omarov wrote: > One of the ports of RK3568 can be configured as LVDS, re-using the DSI DPHY > > Signed-off-by: Alibek Omarov > --- > drivers/gpu/drm/rockchip/rockchip_lvds.c | 144 +++++++++++++++++++++-- > drivers/gpu/drm/rockchip/rockchip_lvds.h | 10 ++ > 2 files changed, 147 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c > index 68f6ebb33460..83c60240af85 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c > +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c > @@ -433,6 +433,90 @@ static void px30_lvds_encoder_disable(struct drm_encoder *encoder) > drm_panel_unprepare(lvds->panel); > } > > +static int rk3568_lvds_poweron(struct rockchip_lvds *lvds) > +{ > + int ret; > + > + ret = clk_enable(lvds->pclk); > + if (ret < 0) { > + DRM_DEV_ERROR(lvds->dev, "failed to enable lvds pclk %d\n", ret); > + return ret; > + } > + > + ret = pm_runtime_get_sync(lvds->dev); > + if (ret < 0) { > + DRM_DEV_ERROR(lvds->dev, "failed to get pm runtime: %d\n", ret); > + clk_disable(lvds->pclk); > + return ret; > + } > + > + /* Enable LVDS mode */ > + return regmap_update_bits(lvds->grf, RK3568_GRF_VO_CON2, > + RK3568_LVDS0_MODE_EN(1), > + RK3568_LVDS0_MODE_EN(1)); Isn't this the same as: regmap_write(lvds->grf, RK3568_GRF_VO_CON2, RK3568_LVDS0_MODE_EN(1)); Unless I am missing something I find a plain regmap_write() easier to read. > +} > + > +static void rk3568_lvds_poweroff(struct rockchip_lvds *lvds) > +{ > + regmap_update_bits(lvds->grf, RK3568_GRF_VO_CON2, > + RK3568_LVDS0_MODE_EN(1) | RK3568_LVDS0_P2S_EN(1), > + RK3568_LVDS0_MODE_EN(0) | RK3568_LVDS0_P2S_EN(0)); Same here: regmap_write(lvds->grf, RK3568_GRF_VO_CON2, RK3568_LVDS0_MODE_EN(0) | RK3568_LVDS0_P2S_EN(0)); What about the RK3568_LVDS0_P2S_EN bit? This is set in probe() and cleared here. For symmetry reasons shouldn't it be set in rk3568_lvds_poweron() instead? > + > + pm_runtime_put(lvds->dev); > + clk_disable(lvds->pclk); > +} > + > +static int rk3568_lvds_grf_config(struct drm_encoder *encoder, > + struct drm_display_mode *mode) > +{ > + struct rockchip_lvds *lvds = encoder_to_lvds(encoder); > + > + if (lvds->output != DISPLAY_OUTPUT_LVDS) { > + DRM_DEV_ERROR(lvds->dev, "Unsupported display output %d\n", > + lvds->output); > + return -EINVAL; > + } > + > + /* Set format */ > + return regmap_update_bits(lvds->grf, RK3568_GRF_VO_CON0, > + RK3568_LVDS0_SELECT(3), > + RK3568_LVDS0_SELECT(lvds->format)); It seems lvds->format does not match what the register expects. We have: #define LVDS_VESA_24 0 #define LVDS_JEIDA_24 1 #define LVDS_VESA_18 2 #define LVDS_JEIDA_18 3 According to the reference manual the register expects: lvdsformat_lvds0_select 2'b00: VESA 24bit 2'b01: JEIDA 24bit 2'b10: JEIDA 18bit 2'b11: VESA 18bit I only have the RK3568 manual but no PX30 or RK3288 manual, so I can't say if they changed the register mapping between the SoCs or if it's wrong on the other SoCs as well. BTW you correctly set the mask to RK3568_LVDS0_SELECT(3), but for the PX30 it looks wrong: return regmap_update_bits(lvds->grf, PX30_LVDS_GRF_PD_VO_CON1, PX30_LVDS_FORMAT(lvds->format), PX30_LVDS_FORMAT(lvds->format)); I really think regmap_write() would be better to use here to avoid such things. > + > +static void rk3568_lvds_encoder_enable(struct drm_encoder *encoder) > +{ > + struct rockchip_lvds *lvds = encoder_to_lvds(encoder); > + struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode; 'mode' is unused. > + int ret; > + > + drm_panel_prepare(lvds->panel); > + > + ret = rk3568_lvds_poweron(lvds); > + if (ret) { > + DRM_DEV_ERROR(lvds->dev, "failed to power on LVDS: %d\n", ret); > + drm_panel_unprepare(lvds->panel); > + return; > + } > + > + ret = rk3568_lvds_grf_config(encoder, mode); > + if (ret) { > + DRM_DEV_ERROR(lvds->dev, "failed to configure LVDS: %d\n", ret); > + drm_panel_unprepare(lvds->panel); > + return; > + } > + > + drm_panel_enable(lvds->panel); > +} > + > +static void rk3568_lvds_encoder_disable(struct drm_encoder *encoder) > +{ > + struct rockchip_lvds *lvds = encoder_to_lvds(encoder); > + > + drm_panel_disable(lvds->panel); > + rk3568_lvds_poweroff(lvds); > + drm_panel_unprepare(lvds->panel); > +} > + > static const > struct drm_encoder_helper_funcs rk3288_lvds_encoder_helper_funcs = { > .enable = rk3288_lvds_encoder_enable, > @@ -447,6 +531,13 @@ struct drm_encoder_helper_funcs px30_lvds_encoder_helper_funcs = { > .atomic_check = rockchip_lvds_encoder_atomic_check, > }; > > +static const > +struct drm_encoder_helper_funcs rk3568_lvds_encoder_helper_funcs = { > + .enable = rk3568_lvds_encoder_enable, > + .disable = rk3568_lvds_encoder_disable, > + .atomic_check = rockchip_lvds_encoder_atomic_check, > +}; > + > static int rk3288_lvds_probe(struct platform_device *pdev, > struct rockchip_lvds *lvds) > { > @@ -491,6 +582,26 @@ static int rk3288_lvds_probe(struct platform_device *pdev, > return 0; > } > > +static int rockchip_lvds_phy_probe(struct platform_device *pdev, > + struct rockchip_lvds *lvds) > +{ > + int ret; > + > + lvds->dphy = devm_phy_get(&pdev->dev, "dphy"); > + if (IS_ERR(lvds->dphy)) > + return PTR_ERR(lvds->dphy); > + > + ret = phy_init(lvds->dphy); > + if (ret) > + return ret; > + > + ret = phy_set_mode(lvds->dphy, PHY_MODE_LVDS); > + if (ret) > + return ret; > + > + return phy_power_on(lvds->dphy); > +} You factor out the steps done for px30 to a separate function in order to reuse it on rk3568. You could make a separate patch from this to make it easier to understand and to verify that there is no functional change involved for the px30. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |