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: <ac7ce475-23dd-4d9d-afd1-ad139496a510@denx.de>
Date:   Tue, 18 Apr 2023 01:23:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH 5/6] drm: bridge: samsung-dsim: Support non-burst mode
To:     Adam Ford <aford173@gmail.com>
Cc:     dri-devel@lists.freedesktop.org, m.szyprowski@samsung.com,
        aford@beaconembedded.com, Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        Inki Dae <inki.dae@samsung.com>,
        Jagan Teki <jagan@amarulasolutions.com>,
        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>,
        Frieder Schrempf <frieder.schrempf@kontron.de>,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, Lucas Stach <l.stach@pengutronix.de>
References: <20230415104104.5537-1-aford173@gmail.com>
 <20230415104104.5537-5-aford173@gmail.com>
 <807aa6c6-bbea-abcc-172d-17e22d1a3988@denx.de>
 <CAHCN7x+NUnMtLbj_7A_uqxPsi5NXRXsPFwDnn=sf1bgm-Q-BsQ@mail.gmail.com>
 <88e53197-2819-c068-eba6-a218a19d8d15@denx.de>
 <CAHCN7xLbbyTaN43pJe3NMdupoGb5vC3yXc_vBn6+CRChWCt92A@mail.gmail.com>
Content-Language: en-US
From:   Marek Vasut <marex@denx.de>
In-Reply-To: <CAHCN7xLbbyTaN43pJe3NMdupoGb5vC3yXc_vBn6+CRChWCt92A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 4/18/23 00:24, Adam Ford wrote:
> On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 4/17/23 13:57, Adam Ford wrote:
>>> On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 4/15/23 12:41, Adam Ford wrote:
>>>>> The high-speed clock is hard-coded to the burst-clock
>>>>> frequency specified in the device tree.  However, when
>>>>> using devices like certain bridge chips without burst mode
>>>>> and varying resolutions and refresh rates, it may be
>>>>> necessary to set the high-speed clock dynamically based
>>>>> on the desired pixel clock for the connected device.
>>>>
>>>> The link rate negotiation should happen internally between the nearest
>>>> bridge and DSIM, so please add that to DRM core instead of hacking
>>>> around it by tweaking the HS clock again.
>>>
>>> I thought you tried to add something like this before and had some resistance.
>>
>> Yes, all my attempts were rejected by a single reviewer. I suspended my
>> efforts in that area for now.
>>
>>> The Pixel clock is set by the bridge already without any new code
>>> added to the DRM core..  I am just reading that value that's there,
>>> and setting the clock accordingly.  I don't see how this is a hack.
>>
>> Assume you have a DSI-to-HDMI bridge attached to your DSIM bridge, it
>> operates in non-burst mode, like ADV7533 . How would you configure the
> 
> I have an ADV7535
> 
>> HS clock rate for such a bridge in DT ? (hint: you cannot, because the
>> required clock comes from the EDID, which may not be available just yet)
> 
> The whole idea is that you wouldn't want to or need to configure the
> clock speed in the device tree because it comes from the
> EDID->bridge->DSI.
> 
> I've tested this configuration on imx8mm, imx8mn, and imx8mp and I can
> change the resolution and refresh rate on the fly and the DSI will
> automatically readjust accordingly.   If you fixed the clock in the
> device tree, you wouldn't be able to do that, and that was the point
> of this patch.

Uh, I retract my comment, I was clearly confused here and we're talking 
about the same thing.