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;
Message-ID: <45e4370f-fdee-9178-5c15-43205dc02bb9@samsung.com>
Date:   Wed, 17 May 2023 23:34:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0)
        Gecko/20100101 Thunderbird/102.10.1
Subject: Re: [PATCH V6 5/6] drm: bridge: samsung-dsim: Dynamically configure
 DPHY timing
Content-Language: en-US
To:     Adam Ford <aford173@gmail.com>, dri-devel@lists.freedesktop.org
Cc:     aford@beaconembedded.com, Lucas Stach <l.stach@pengutronix.de>,
        Chen-Yu Tsai <wenst@chromium.org>,
        Frieder Schrempf <frieder.schrempf@kontron.de>,
        Michael Walle <michael@walle.cc>,
        Andrzej Hajda <andrzej.hajda@intel.com>,
        Neil Armstrong <neil.armstrong@linaro.org>,
        Robert Foss <rfoss@kernel.org>,
        Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
        Jonas Karlman <jonas@kwiboo.se>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Inki Dae <inki.dae@samsung.com>,
        Jagan Teki <jagan@amarulasolutions.com>,
        Marek Vasut <marex@denx.de>, linux-kernel@vger.kernel.org
From:   Marek Szyprowski <m.szyprowski@samsung.com>
In-Reply-To: <CAHCN7xL8qkCgXEE3nZvmwbWGO5GtF+37eOVYq63djGOHDaSdmA@mail.gmail.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <20230515235713.232939-1-aford173@gmail.com>
        <20230515235713.232939-6-aford173@gmail.com>
        <CGME20230517025535eucas1p2d85f8f2954262ca9e54cc4d7bdb9567a@eucas1p2.samsung.com>
        <CAHCN7xL8qkCgXEE3nZvmwbWGO5GtF+37eOVYq63djGOHDaSdmA@mail.gmail.com>
Precedence: bulk

Hi Adam,

On 17.05.2023 04:55, Adam Ford wrote:
> On Mon, May 15, 2023 at 6:57 PM Adam Ford <aford173@gmail.com> wrote:
>> The DPHY timings are currently hard coded. Since the input
>> clock can be variable, the phy timings need to be variable
>> too.  To facilitate this, we need to cache the hs_clock
>> based on what is generated from the PLL.
>>
>> The phy_mipi_dphy_get_default_config_for_hsclk function
>> configures the DPHY timings in pico-seconds, and a small macro
>> converts those timings into clock cycles based on the hs_clk.
>>
>> Signed-off-by: Adam Ford <aford173@gmail.com>
>> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>> Tested-by: Chen-Yu Tsai <wenst@chromium.org>
>> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> Tested-by: Michael Walle <michael@walle.cc>
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 57 +++++++++++++++++++++++----
>>   include/drm/bridge/samsung-dsim.h     |  1 +
>>   2 files changed, 51 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 08266303c261..3944b7cfbbdf 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -218,6 +218,8 @@
>>
>>   #define OLD_SCLK_MIPI_CLK_NAME         "pll_clk"
>>
>> +#define PS_TO_CYCLE(ps, hz) DIV64_U64_ROUND_CLOSEST(((ps) * (hz)), 1000000000000ULL)
>> +
>>   static const char *const clk_names[5] = {
>>          "bus_clk",
>>          "sclk_mipi",
>> @@ -651,6 +653,8 @@ static unsigned long samsung_dsim_set_pll(struct samsung_dsim *dsi,
>>                  reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
>>          } while ((reg & DSIM_PLL_STABLE) == 0);
>>
>> +       dsi->hs_clock = fout;
>> +
>>          return fout;
>>   }
>>
>> @@ -698,13 +702,46 @@ static void samsung_dsim_set_phy_ctrl(struct samsung_dsim *dsi)
>>          const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
>>          const unsigned int *reg_values = driver_data->reg_values;
>>          u32 reg;
>> +       struct phy_configure_opts_mipi_dphy cfg;
>> +       int clk_prepare, lpx, clk_zero, clk_post, clk_trail;
>> +       int hs_exit, hs_prepare, hs_zero, hs_trail;
>> +       unsigned long long byte_clock = dsi->hs_clock / 8;
>>
>>          if (driver_data->has_freqband)
>>                  return;
>>
>> +       phy_mipi_dphy_get_default_config_for_hsclk(dsi->hs_clock,
>> +                                                  dsi->lanes, &cfg);
>> +
>> +       /*
>> +        * TODO:
>> +        * The tech reference manual for i.MX8M Mini/Nano/Plus
>> +        * doesn't state what the definition of the PHYTIMING
>> +        * bits are beyond their address and bit position.
>> +        * After reviewing NXP's downstream code, it appears
>> +        * that the various PHYTIMING registers take the number
>> +        * of cycles and use various dividers on them.  This
>> +        * calculation does not result in an exact match to the
>> +        * downstream code, but it is very close, and it appears
>> +        * to sync at a variety of resolutions. If someone
>> +        * can get a more accurate mathematical equation needed
>> +        * for these registers, this should be updated.
>> +        */
> Marek Szyprowski -
>
> I was curious to know if you have any opinion on this TODO note and/or
> if you have any stuff you can share about how the values of the
> following variables are configured?
>> +
>> +       lpx = PS_TO_CYCLE(cfg.lpx, byte_clock);
>> +       hs_exit = PS_TO_CYCLE(cfg.hs_exit, byte_clock);
>> +       clk_prepare = PS_TO_CYCLE(cfg.clk_prepare, byte_clock);
>> +       clk_zero = PS_TO_CYCLE(cfg.clk_zero, byte_clock);
>> +       clk_post = PS_TO_CYCLE(cfg.clk_post, byte_clock);
>> +       clk_trail = PS_TO_CYCLE(cfg.clk_trail, byte_clock);
>> +       hs_prepare = PS_TO_CYCLE(cfg.hs_prepare, byte_clock);
>> +       hs_zero = PS_TO_CYCLE(cfg.hs_zero, byte_clock);
>> +       hs_trail = PS_TO_CYCLE(cfg.hs_trail, byte_clock);
>> +
> These 'work' but they don't exactly match the NXP reference code, but
> they're not significantly different.  The NXP reference manual doesn't
> describe how these registers are set, they only publish the register
> and bits used.  Since you work for Samsung, I was hoping you might
> have inside information to know if this is a reasonable approach.

Unfortunately I won't be able to provide any info on that. You may check 
the reference Samsung code for various Exynos based products, but I 
suspect it will be similar to what was already in the Exynos DSI driver.

 > ...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland