devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aradhya Bhatia <aradhya.bhatia@linux.dev>
To: "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>
Cc: "j-choudhary@ti.com" <j-choudhary@ti.com>,
	"u-kumar1@ti.com" <u-kumar1@ti.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"devarsht@ti.com" <devarsht@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"nm@ti.com" <nm@ti.com>, "vigneshr@ti.com" <vigneshr@ti.com>,
	"praneeth@ti.com" <praneeth@ti.com>
Subject: Re: [PATCH v4 0/3] drm/tidss: Add OLDI bridge support
Date: Thu, 20 Mar 2025 18:54:05 +0530	[thread overview]
Message-ID: <2c0b49a2-7cf3-4432-bab0-1eb110e8e8c2@linux.dev> (raw)
In-Reply-To: <8366a3d736f9937667aab024895a59e5947dd4a5.camel@siemens.com>

Hi Alexander,

Thank you for testing and reviewing the patches!

On 19/03/25 23:30, Sverdlin, Alexander wrote:
> Thank you for the patches, Aradhya!
> 
> On Sun, 2024-11-24 at 20:06 +0530, Aradhya Bhatia wrote:
>> Regardless, I'd appreciate it if somebody can test it, and report back if they
>> observe any issues.
> 
> I've tried to test the patchset with necessary pre-requisites and DT additions
> with a single channel LVDS pannel and while I'm not successful yet, I've also noticed
> the following warning:
> 
> tidss 30200000.dss: vp0: Clock rate 24285714 differs over 5% from requested 37000000
> 
> even though later the clock seems to be correctly set up:
> 
> $ cat /sys/kernel/debug/clk/clk_summary 
> 
>                                  enable  prepare  protect                                duty  hardware                            connection
>    clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
> ---------------------------------------------------------------------------------------------------------------------------------------------
>  clk:186:6                           1       1        0        250000000   0          0     50000      Y   30200000.dss                    fck                      
>                                                                                                            deviceless                      no_connection_id         
>  clk:186:4                           0       0        0        0           0          0     50000      Y   deviceless                      no_connection_id         
>  clk:186:3                           0       0        0        170000000   0          0     50000      Y   deviceless                      no_connection_id         
>     clk:186:2                        0       0        0        170000000   0          0     50000      Y      30200000.dss                    vp2                      
>                                                                                                               deviceless                      no_connection_id         
>  clk:186:0                           1       1        0        259090909   0          0     50000      Y   oldi@0                          serial                   
>                                                                                                            deviceless                      no_connection_id         
>     clock-divider-oldi               1       1        0        37012987    0          0     50000      Y      30200000.dss                    vp1                      
> 
> Looks like "clock-divider-oldi" doesn't propagate clk_set_rate() to the parent,
> but the parent is being set later independently?
> 

Yes, you are right. The "clock-divider-oldi" does not propagate the
clk_set_rate() to the parent.

The actual parent clock is now owned by the oldi bridge driver, and that
is what sets the clock rate (7 * pixel freq). The equivalent action from
tidss vp (DRM crtc) is a no op in cases of OLDI display pipeline.

Usually, the DRM crtc is enabled first, before _any_ of the DRM bridges
get pre_enabled or enabled.

Since, OLDI is a DRM bridge, the OLDI enable (and by extension the
actual clk_set_rate()) takes place _after_ the DRM crtc has been
enabled (which is why you see the parent being set later on).

DRM crtc enable is where tidss vp attempts (and fails) to set the clock
rate, causing the warning you see initially.


I have attempted to re-order the bridge pre_enable and crtc enable calls
in these patches[0], separately.

While you have mentioned that you did add the prerequisites, could you
confirm that you applied the (now older) dependency patch mentioned in
the v4 cover-letter[1]?
Ideally, you should not observe these concerns if [1] were successfully
applied.

More importantly, if you are already on latest linux-next, I would
request you to use v6 of this OLDI series[2], along with the latest
dependency patches[0], as the older dependency patch is simply not
applicable on latest kernel anymore! =)

I'd appreciate it if you are able to test the latest revisions on your
single-link setup, and report back any issue you see! Thank you! =)


-- 
Regards
Aradhya



[0]: Pre Requisite patches that re-order crtc/encoder/bridge sequences
(latest revision).

a. ("drm/atomic-helper: Refactor crtc & encoder-bridge op loops into
separate functions")
https://lore.kernel.org/all/20250226155737.565931-3-aradhya.bhatia@linux.dev/

b. ("drm/atomic-helper: Separate out bridge pre_enable/post_disable from
enable/disable")
https://lore.kernel.org/all/20250226155737.565931-4-aradhya.bhatia@linux.dev/

c. ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
https://lore.kernel.org/all/20250226155737.565931-5-aradhya.bhatia@linux.dev/


[1]: Dependency patch mentioned in v4 OLDI series.
("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
https://lore.kernel.org/all/20240622110929.3115714-11-a-bhatia1@ti.com/


[2]: Latest OLDI series (v6)
https://lore.kernel.org/all/20250226181300.756610-1-aradhya.bhatia@linux.dev/


  reply	other threads:[~2025-03-20 13:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-24 14:36 [PATCH v4 0/3] drm/tidss: Add OLDI bridge support Aradhya Bhatia
2024-11-24 14:36 ` [PATCH v4 1/3] dt-bindings: display: ti,am65x-dss: Re-indent the example Aradhya Bhatia
2024-11-24 14:36 ` [PATCH v4 2/3] dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter Aradhya Bhatia
2024-12-04 14:09   ` Rob Herring
2024-11-24 14:36 ` [PATCH v4 3/3] drm/tidss: Add OLDI bridge support Aradhya Bhatia
2025-03-18 13:35   ` Sverdlin, Alexander
2025-03-20 13:27     ` Aradhya Bhatia
2024-12-03 12:12 ` [PATCH v4 0/3] " Tomi Valkeinen
2024-12-03 18:14   ` Aradhya Bhatia
2024-12-03 18:36     ` Tomi Valkeinen
2024-12-09  4:17       ` Aradhya Bhatia
2025-03-19 18:00 ` Sverdlin, Alexander
2025-03-20 13:24   ` Aradhya Bhatia [this message]
2025-03-20 13:30     ` Sverdlin, Alexander
2025-03-25 18:57     ` Sverdlin, Alexander
2025-03-29 13:45       ` Aradhya Bhatia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c0b49a2-7cf3-4432-bab0-1eb110e8e8c2@linux.dev \
    --to=aradhya.bhatia@linux.dev \
    --cc=alexander.sverdlin@siemens.com \
    --cc=devarsht@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j-choudhary@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=praneeth@ti.com \
    --cc=u-kumar1@ti.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).