Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp439990rwl; Sat, 25 Mar 2023 05:10:48 -0700 (PDT) X-Google-Smtp-Source: AKy350amJvj8nyXHmd1G7XmA306S8XvMoC8COM863hHaqv+8NxoQmTnS6cD1ASvRmrnRUO/DBrF8 X-Received: by 2002:aa7:cf02:0:b0:501:e26e:502b with SMTP id a2-20020aa7cf02000000b00501e26e502bmr5906932edy.29.1679746247978; Sat, 25 Mar 2023 05:10:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679746247; cv=none; d=google.com; s=arc-20160816; b=IcvcH9r9IP5gni9pFg+w5MBnKg7cNx2e5/OqTueQmZeP2zcK3+UhS3scma380zRfCr DSlQpkt+ZMeBfS+xlo+5fFcB+pb4Gf8AgaYda8hQ8L/Mbr/bdoJDkzgW6NBQEehFK0gu d73eD1POK/S9Qb+S1QB9mHw8zpxBpLqH5bx7XKXg+PYbe/WHPoojs7rVlTWiUAFZIYF8 OSZfYEy0QKeywxHRkr1cJAlw9cGPlA6j5B406ixLzsd5jeyv/XV/2Juq+wBo4Xj9TEzn 7jR+khzbl4SK5yTNrD4g7cKVOXGRGEmepvHK1GDWn7IaDIvfJU3/6PWu1tM4bxbDpriv SvwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:in-reply-to:references :date:subject:cc:to:from:dkim-signature; bh=QalUgYTR7L02Pm/gpKnsde2aCBCLEQnrH09k5/MdlqE=; b=cRU/u4J9Tx1ejP6E438u8oYFjM33aPpG3bXeQmpK6LD8m/9k+ImyDR63DgLTTBLR0l ks/eIZItKQfgPQhWHPv+H53RIagZYSPmR8kGsan24wbjLnlZwBH8oxJQQ+7PQ0vhWS6K gi2rKYzDj8J4D+e6CB2bpcXCwXKoH3DBo8AysBXMm5LGn+OdJ/E3irj66pw3cVoskJeD PslqhHCXb9mjrWVwCE3eLbb/XHZ31Tc5rds4xyTVTvA0d2SZ7Jb57icOs93pruD0SFPm DrxHb2xlRtePlfjDZ7nkUiEcyKb3fkLV7bh9PxNXHRfjjYDKD8e+VbmCFmFP/DmD0nvh JjQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=fK8Dw61C; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g21-20020aa7d1d5000000b004acc575090fsi2309633edp.36.2023.03.25.05.10.23; Sat, 25 Mar 2023 05:10:47 -0700 (PDT) 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; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=fK8Dw61C; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231693AbjCYMKA (ORCPT + 99 others); Sat, 25 Mar 2023 08:10:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230292AbjCYMJ7 (ORCPT ); Sat, 25 Mar 2023 08:09:59 -0400 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050:0:465::201]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E176DBE2 for ; Sat, 25 Mar 2023 05:09:58 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4PkHvP2qKjz9sW6; Sat, 25 Mar 2023 13:09:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1679746193; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QalUgYTR7L02Pm/gpKnsde2aCBCLEQnrH09k5/MdlqE=; b=fK8Dw61CyQMFkvLPY0C5GZzBqzfKwKLL9ub62cJXQZpF70SVtceBlF8/sJaEciLa8exyNp dzf43/oEBdYAsXWhujvF3E+HE/SMU812X2riTfovbQtzke/6Q9YE9zDfVIgAe2FRRsqBW+ VYpIsZEJAslBFZzwj9ERjXeKehSwZSTZMCU3EpfLE9j9xuQSOkiz//Si/hG1cGoCJH5wu1 fM/frIuk6Rntpszv+Zw2XoMyTkHiMWdF17/2wydEtOnfLwJKKsDAen+zgC/nl19AcbZR3G qrZn8jks90hm2z9b93b2CDvoJa5CYGqunGPr2HEWsEQu3cqqoCJZXsKgQ9P+qA== From: Frank Oltmanns To: Roman Beranek , Maxime Ripard Cc: Chen-Yu Tsai , David Airlie , Daniel Vetter , Jernej Skrabec , Samuel Holland , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG Date: Sat, 25 Mar 2023 12:40:04 +0100 References: <20230320161636.24411-1-romanberanek@icloud.com> In-reply-to: <20230320161636.24411-1-romanberanek@icloud.com> Message-ID: <87wn356ni4.fsf@oltmanns.dev> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Rspamd-Queue-Id: 4PkHvP2qKjz9sW6 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On 2023-03-20 at 17:16:36 +0100, Roman Beranek wr= ote: > In the case of DSI output, the value of SUN4I_TCON0_DCLK_DIV (4) does > not represent the actual dotclock divider, PLL_MIPI instead runs at > (bpp / lanes )-multiple [1] of the dotclock. [2] Setting 4 as dotclock > divder thus leads to reduced frame rate, specifically by 1/3 on 4-lane > panels, and by 2/3 on 2-lane panels respectively. > > As sun4i_dotclock driver stores its calculated divider directly in > the register, conditional handling of the DSI output scenario is needed. > Instead of reading the divider from SUN4I_TCON0_DCLK_REG, retrieve > the value from tcon->dclk_min_div. > > [1] bits per pixel / number of DSI lanes > [2] > > Signed-off-by: Roman Beranek > =E2=80=94 > drivers/gpu/drm/sun4i/sun4i_dotclock.c | 6 +++++- > drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +++=E2=80=93 > drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + > 3 files changed, 9 insertions(+), 3 deletions(-) > > diff =E2=80=93git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c b/drivers/gpu/= drm/sun4i/sun4i_dotclock.c > index 417ade3d2565..26fa99aff590 100644 > =E2=80=94 a/drivers/gpu/drm/sun4i/sun4i_dotclock.c > +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c > @@ -11,6 +11,7 @@ > > #include =E2=80=9Csun4i_tcon.h=E2=80=9D > #include =E2=80=9Csun4i_dotclock.h=E2=80=9D > +#include =E2=80=9Csun6i_mipi_dsi.h=E2=80=9D > > struct sun4i_dclk { > struct clk_hw hw; > @@ -56,6 +57,9 @@ static unsigned long sun4i_dclk_recalc_rate(struct clk_= hw *hw, > struct sun4i_dclk *dclk =3D hw_to_dclk(hw); > u32 val; > > + if (dclk->tcon->is_dsi) > + return parent_rate / dclk->tcon->dclk_min_div; > + > regmap_read(dclk->regmap, SUN4I_TCON0_DCLK_REG, &val); > > val >>=3D SUN4I_TCON0_DCLK_DIV_SHIFT; > @@ -116,7 +120,7 @@ static int sun4i_dclk_set_rate(struct clk_hw *hw, uns= igned long rate, > unsigned long parent_rate) > { > struct sun4i_dclk *dclk =3D hw_to_dclk(hw); > - u8 div =3D parent_rate / rate; > + u8 div =3D dclk->tcon->is_dsi ? SUN6I_DSI_TCON_DIV : parent_rate / rate; > > return regmap_update_bits(dclk->regmap, SUN4I_TCON0_DCLK_REG, > GENMASK(6, 0), div); > diff =E2=80=93git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/= sun4i/sun4i_tcon.c > index 523a6d787921..7f5d3c135058 100644 > =E2=80=94 a/drivers/gpu/drm/sun4i/sun4i_tcon.c > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > @@ -367,8 +367,9 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tco= n *tcon, > u32 block_space, start_delay; > u32 tcon_div; > > - tcon->dclk_min_div =3D SUN6I_DSI_TCON_DIV; > - tcon->dclk_max_div =3D SUN6I_DSI_TCON_DIV; > + tcon->is_dsi =3D true; > + tcon->dclk_min_div =3D bpp / lanes; > + tcon->dclk_max_div =3D bpp / lanes; Claiming to set the divider to a different value (bpp / lanes) than what we= =E2=80=99re actually using in the end (SUN6I_DSIO_TCON_DIV) is somehow bugg= ing me. I feel like the proposal that I submitted is more direct: Actually, I had the following third patch prepared that adjusted the dotclo= ck rate so that the required PLL rate is set. But again, this seems very in= direct, so that=E2=80=99s why I refrained from submitting it and I submitte= d the linked patch above instead. Anyway, here is the third proposal: =E2=80=94 a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encod= er *encoder) regulator_disable(dsi->regulator); } +static bool sun6i_dsi_encoder_mode_fixup( =E2=81=83 struct drm_encoder *encoder, =E2=81=83 const struct drm_display_mode *mode, =E2=81=83 struct drm_display_mode *adjusted_mode) +{ =E2=81=83 if (encoder->encoder_type =3D=3D DRM_MODE_ENCODER_DSI) { =E2=81=83 /* =E2=81=83 * For DSI the PLL rate has to respect the bits per pixel and =E2=81=83 * number of lanes. =E2=81=83 * =E2=81=83 * According to the BSP code: =E2=81=83 * PLL rate =3D DOTCLOCK * bpp / lanes =E2=81=83 * =E2=81=83 * Therefore, the clock has to be adjusted in order to set the =E2=81=83 * correct PLL rate when actually setting the clock. =E2=81=83 */ =E2=81=83 struct sun6i_dsi *dsi =3D encoder_to_sun6i_dsi(encoder); =E2=81=83 struct mipi_dsi_device *device =3D dsi->device; =E2=81=83 u8 bpp =3D mipi_dsi_pixel_format_to_bpp(device->format); =E2=81=83 u8 lanes =3D device->lanes; =E2=81=83=20 =E2=81=83 adjusted_mode->crtc_clock =3D mode->crtc_clock =E2=81=83 * bpp / (lanes * SUN6I_DSI_TCON_DIV); =E2=81=83 } =E2=81=83=20 =E2=81=83 return true; +} =E2=81=83 static int sun6i_dsi_get_modes(struct drm_connector *connector) { struct sun6i_dsi *dsi =3D connector_to_sun6i_dsi(connector); @@ -851,6 +879,7 @@ static const struct drm_connector_funcs sun6i_dsi_conne= ctor_funcs =3D { static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = =3D { .disable =3D sun6i_dsi_encoder_disable, .enable =3D sun6i_dsi_encoder_enable, =E2=81=83 .mode_fixup =3D sun6i_dsi_encoder_mode_fixup, }; static u32 sun6i_dsi_dcs_build_pkt_hdr(struct sun6i_dsi *dsi, Maxime, Roman, CC, what do you think? Can we achieve consensus? If I=E2=80= =99m not mistaken, all of the three proposal are a step in the right direct= ion, because they correct faulty behavior. Don=E2=80=99t you think? Thanks, Frank > > sun4i_tcon0_mode_set_common(tcon, mode); > > diff =E2=80=93git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/= sun4i/sun4i_tcon.h > index fa23aa23fe4a..d8150ba2f319 100644 > =E2=80=94 a/drivers/gpu/drm/sun4i/sun4i_tcon.h > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h > @@ -271,6 +271,7 @@ struct sun4i_tcon { > struct clk *dclk; > u8 dclk_max_div; > u8 dclk_min_div; > + bool is_dsi; > > /* Reset control */ > struct reset_control *lcd_rst; --=-=-=--