[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71b4bd21-573e-4b48-a57f-6496e97d2eff@ti.com>
Date: Wed, 2 Jul 2025 12:31:55 +0530
From: Jayesh Choudhary <j-choudhary@...com>
To: Devarsh Thakkar <devarsht@...com>, <jyri.sarha@....fi>,
<maarten.lankhorst@...ux.intel.com>, <mripard@...nel.org>,
<tzimmermann@...e.de>, <dri-devel@...ts.freedesktop.org>,
<tomi.valkeinen@...asonboard.com>, <mwalle@...nel.org>
CC: <airlied@...il.com>, <simona@...ll.ch>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 0/3] Decouple max_pclk check from constant display
feats
Hello Devarsh,
On 01/07/25 19:00, Devarsh Thakkar wrote:
> On 01/07/25 15:25, Jayesh Choudhary wrote:
>> In an effort to make the existing compatibles more usable, we are
>> removing the max_pclk_khz form dispc_features structure and doing the
>> correspondig checks using "curr_max_pclk[]".
>>
>> Changes are fully backwards compatible.
>>
>> After integration of OLDI support[0], we need additional patches in
>> oldi to identify the VP that has OLDI. We have to do this since
>> OLDI driver owns the VP clock (its serial clock) and we cannot perform
>> clock operations on those VP clock from tidss driver. This issue was
>> also reported upstream when DSI fixes[1] had some clock related calls
>> in tidss driver. When "clk_round_rate()" is called, ideally it should
>> have gone to "sci_clk_determine_rate()" to query DM but it doesn't since
>> clock is owned by OLDI not tidss.
>>
>
> As series is fixing above issue (abnormal behaviour while calling
> clk_round_rate from tidss for VP clock being used by OLDI), can we add
> "Fixes tag" for the patches?
This seems like a preemptive fix. So I was not sure what to add.
If it should be added then which commit?
7246e0929945 ("drm/tidss: Add OLDI bridge support") ?
Warm Regards,
Jayesh
>
> Regards
> Devarsh
Powered by blists - more mailing lists