Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1160416pxb; Fri, 21 Jan 2022 11:08:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJw6sM5YPdNo18Guo+t4UuuzYfSpbYfn5WFopAEVuQiTrIFuo4Jr5j5WVneaYn7BZYVqZ88e X-Received: by 2002:a17:90b:3707:: with SMTP id mg7mr2124364pjb.56.1642792084504; Fri, 21 Jan 2022 11:08:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642792084; cv=none; d=google.com; s=arc-20160816; b=Li2dx33pe7UpS8fUjnLYayIYnlb4GMUGunLqSagnXGB2kw3pHbr4CaszqKfsBDPcK4 QoCjywpGqLUmt+oGEngCBMjqR7ft+qQMTsq3NZrtizulToVu/bIXzSUe6/KxKAZuQj9E /GiIWy7z5gDMfjFDqcCKMAKMb053/kMx7PcF9OjG4Ge7BsSOH/UEaGudAg+BMZE8/7LP +6wzBPT6iru4qqMeVD3QOlGcodJvNeTA4xoWKtP3yAp/03ml7I9hmlXY4HmdWDW+Sx/v D9mEHa7v0zJ/R7aHy2Bt+oLFrLPBgVHhSvr9ma8SptpLVVji4910Q+0SP7G+fFnRzwIB w+Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=HJNnzt0d5+w9Guhb3CJhVdmh2tzznUIQr10p4N94BuY=; b=XRFQxJQ+UAqV25DMIS5TvpxOTzEgP24jzBJTU7V2JG+Vjwv99rN8QaSq5FqRiJXb/+ Ne8ube5H4W2YEAoONZqUCyB5IgLQFbTtsRQl6FXtn9fGNX9XZoHu1fHveyhLAwwfFLki VR4jIr0cXVYRG+nWRdZkJ+p3xnNjPk4ge16finU8DFOAAwZP2KrI2lmvag+UMGTWY1q8 wvdetqUKCiertfnzA58CBi2AGGZ6YzY4bcCrHf7BPQhP4Zx/Y9UV9CECDTePWY7p5+Ry StgjKSBIfFyLRUha4XlaGeynGMdWLQltu7T6E1smcWtdCpR6h5UFACbHLewgUpZA5gOT UR9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20210112.gappssmtp.com header.s=20210112 header.b=P3YqFoM3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z3si11454933pjn.35.2022.01.21.11.07.51; Fri, 21 Jan 2022 11:08:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20210112.gappssmtp.com header.s=20210112 header.b=P3YqFoM3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353462AbiASKLY (ORCPT + 99 others); Wed, 19 Jan 2022 05:11:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353440AbiASKLX (ORCPT ); Wed, 19 Jan 2022 05:11:23 -0500 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EEB5C061574 for ; Wed, 19 Jan 2022 02:11:22 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id p18so4277831wmg.4 for ; Wed, 19 Jan 2022 02:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HJNnzt0d5+w9Guhb3CJhVdmh2tzznUIQr10p4N94BuY=; b=P3YqFoM3CZXc6yzRuSnNXCecrPFfoynbKUNRVTkd2+EEf4WLvh76+qjqw8uy4Ep7hL RBgu0J3AaPevsGeVNw2xHAqNU5dz0RtDMzIvBpAmadOkkZZ6r2aICeUaITTK5JljfYv6 x3Nx3OqPQP4sKcYaA9VlbpuGntZOX4TiW2dn4uzJU0Bp4MC7hkmSigLazkmwuiZTO5Me 5oO8QTbjO8SIU/7K1EN9bmYddnV89rLeSdmRTKQlaNJ8z5SHg7J6rQdmZXqZqJciY/so 23w4yqgi77XteHP95woiWgBtIgwJv/HMM7HM/s88w0Tr7iDb423XEjl48kyI7v+nDLA4 gvJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=HJNnzt0d5+w9Guhb3CJhVdmh2tzznUIQr10p4N94BuY=; b=doidSzexiGXSvQhWZP/yX5B6hluWD/a0PTGpDRYGkq2rMyeRDxDxTkBTepce/R42wB CHHu3TfapuDaGpN30P1AvwjLNxcmaa4MfE/vRTrg20gCnAg7Gz0cbnmNu80vm18wOvKb NHyN3V8zGoWCr80SxLtb+yhhxprbGDYMsD+JY/ty4EPqEvRkRqva4FX0GxjXJwTyDIvZ QUfTfzrrjk4tcVj6fr9sH/NrdIRVDi8HmgDbN7OA1IuGRtC/BRfqarFdft8JmYRC4xBj jgi8YNyHOjoJmJchKGSQllG4RE1AMN2Rbz4k0QeOTCpg1UfyUZoxAYJigqu/n1eYXphC XvUA== X-Gm-Message-State: AOAM532JBNnnLaMZEP4cvrlhd8RnIuJ/HI/ZU5xxozy+IGbGQWeqBiAJ 78p18Esdlum7BZVphms2o6gErA== X-Received: by 2002:a7b:c042:: with SMTP id u2mr2796832wmc.18.1642587081098; Wed, 19 Jan 2022 02:11:21 -0800 (PST) Received: from ?IPv6:2001:861:44c0:66c0:d394:97d0:bc02:3846? ([2001:861:44c0:66c0:d394:97d0:bc02:3846]) by smtp.gmail.com with ESMTPSA id u5sm5089062wrs.16.2022.01.19.02.11.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jan 2022 02:11:20 -0800 (PST) Subject: Re: [PATCH v2] phy: dphy: Correct clk_pre parameter To: Liu Ying , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-rockchip@lists.infradead.org Cc: linux-imx@nxp.com, Andrzej Hajda , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , Kishon Vijay Abraham I , Vinod Koul , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Heiko Stuebner , Maxime Ripard , =?UTF-8?Q?Guido_G=c3=bcnther?= References: <20220119023714.1498508-1-victor.liu@nxp.com> <28e3f723-daf0-b3c5-ee10-519c4cabfe17@baylibre.com> <5a638561-c704-49e7-1fed-70e26fedb186@baylibre.com> <8ad2cd76e80056192395ca5b73ff514e59881ba3.camel@nxp.com> From: Neil Armstrong Organization: Baylibre Message-ID: Date: Wed, 19 Jan 2022 11:11:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <8ad2cd76e80056192395ca5b73ff514e59881ba3.camel@nxp.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 19/01/2022 11:01, Liu Ying wrote: > Hi Neil, > > On Wed, 2022-01-19 at 10:11 +0100, Neil Armstrong wrote: >> On 19/01/2022 09:40, Neil Armstrong wrote: >>> Hi, >>> >>> On 19/01/2022 03:37, Liu Ying wrote: >>>> The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE >>>> parameter's unit is Unit Interval(UI) and the minimum value is 8. Also, >>>> kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy >>>> mentions that it should be in UI. However, the dphy core driver wrongly >>>> sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds. >>>> And, the kernel doc of the 'clk_pre' member wrongly says the minimum value >>>> is '8 UI', instead of 8. >>>> >>>> So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre' >>>> member to correctly reflect the T-CLK-PRE parameter's unit and the minimum >>>> value according to the D-PHY specification. >>>> >>>> I'm assuming that all impacted custom drivers shall program values in >>>> TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY >>>> specification mentions that the frequency of TxByteClkHS is exactly 1/8 >>>> the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant >>>> custom driver code is changed to program those values as >>>> DIV_ROUND_UP(cfg->clk_pre, BITS_PER_BYTE), then. >>>> >>>> Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK. >>>> Help is needed to test with other i.MX8mq, Meson and Rockchip platforms, >>>> as I don't have the hardwares. >>>> >>>> Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options") >>>> Cc: Andrzej Hajda >>>> Cc: Neil Armstrong >>>> Cc: Robert Foss >>>> Cc: Laurent Pinchart >>>> Cc: Jonas Karlman >>>> Cc: Jernej Skrabec >>>> Cc: David Airlie >>>> Cc: Daniel Vetter >>>> Cc: Kishon Vijay Abraham I >>>> Cc: Vinod Koul >>>> Cc: Kevin Hilman >>>> Cc: Jerome Brunet >>>> Cc: Martin Blumenstingl >>>> Cc: Heiko Stuebner >>>> Cc: Maxime Ripard >>>> Cc: Guido Günther >>>> Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK >>>> Signed-off-by: Liu Ying >>>> --- >>>> v1->v2: >>>> * Use BITS_PER_BYTE macro. (Andrzej) >>>> * Drop dsi argument from ui2bc() in nwl-dsi.c. >>>> >>>> drivers/gpu/drm/bridge/nwl-dsi.c | 12 +++++------- >>>> drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c | 3 ++- >>>> drivers/phy/phy-core-mipi-dphy.c | 4 ++-- >>>> drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 3 ++- >>>> include/linux/phy/phy-mipi-dphy.h | 2 +- >>>> 5 files changed, 12 insertions(+), 12 deletions(-) >>>> >> [...] >> >>>> diff --git a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c >>>> index cd2332bf0e31..fdbd64c03e12 100644 >>>> --- a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c >>>> +++ b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c >>>> @@ -9,6 +9,7 @@ >>>> >>>> #include >>>> #include >>>> +#include >>>> #include >>>> #include >>>> #include >>>> @@ -250,7 +251,7 @@ static int phy_meson_axg_mipi_dphy_power_on(struct phy *phy) >>>> (DIV_ROUND_UP(priv->config.clk_zero, temp) << 16) | >>>> (DIV_ROUND_UP(priv->config.clk_prepare, temp) << 24)); >>>> regmap_write(priv->regmap, MIPI_DSI_CLK_TIM1, >>>> - DIV_ROUND_UP(priv->config.clk_pre, temp)); >>>> + DIV_ROUND_UP(priv->config.clk_pre, BITS_PER_BYTE)); >>>> >>>> regmap_write(priv->regmap, MIPI_DSI_HS_TIM, >>>> DIV_ROUND_UP(priv->config.hs_exit, temp) | >>> >>> I'll try to run a test, currently the calculation gives 2, so this would give 1. >> >> The Amlogic vendor code does: >> >> /* >8*ui */ >> #define DPHY_TIME_CLK_PRE(ui) (10 * ui) > > This looks like clk_pre time is 10 * ui, which matches the comment > '>8*ui' - longer time 8 * ui. > >> >> t_ui = lcd_timing.bit_rate >> >> t_ui = (1000000 * 100) / (dsi_ui / 1000); /*100*ns */ >> temp = t_ui * 8; /* lane_byte cycle time */ > > If I read correctly, this temp in vendor code is TxByteClkHS period > time in picoseconds. So... > >> >> dphy->clk_pre = ((DPHY_TIME_CLK_PRE(t_ui) + temp - 1) / temp) & 0xff; > > IIUC, 'dphy->clk_pre' essentially means dphy->clk_pre = DIV_ROUND_UP(10 > * ui, temp), that is, the time for dphy->clk_pre is no less than > 10 * ui. The D-PHY spec (v1.2)'s saying is that the minimum time for > dphy->clk_pre is 8 * ui. So, it looks like meson is stricter than the > spec. > > However, the vendor code doesn't seem to match the current meson driver > implementation. The temp in driver code is also TxByteClkHS period > time in picoseconds. And, without this patch, I'm assuming that > priv->config.clk_pre is 8000. So, it looks like MIPI_DSI_CLK_TIM1 is > set to DIV_ROUND_UP(8000, temp). This '8000' does _not_ reflect > '10 * ui'. > > So, 3 choices for meson, up to you: > 1) If meson really requires the time for clk_pre no less than > 10 * ui, then sth like DIV_ROUND_UP(10, BITS_PER_BYTE) can be used. > 2) If meson follows the spec's minimum value, then the patch does > things right for meson. > 3) Force to use 8000 picoseconds for clk_pre, that is, use sth like > DIV_ROUND_UP(8000, temp). > > With this patch applied, do you see any display artifacts by visual > check? Or even checked signals through DSI analyzer? Thanks for the feedback, I'm currently trying to put the setup back to run a test with this change. Neil > > Regards, > Liu Ying > >> >> PHY Registers only says: >> MIPI_DSI_CLK_TIM1 [31:0] >> 7:0 R/W 0 tCLK_PRE >> >>> Neil >>> >> >> [...] >