From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AF6E0C5AD49 for ; Wed, 28 May 2025 13:23:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ji7AVV+5CsPwmqsSq6jj3Ypm8VYYWe+Bf4NiBDPXbxM=; b=v68ccG5PFrK8CQJ8hKDoPbAVSU 4Op+LuO7HNR2CIjqLQclegw+4fZU5VBP+zMlx1Ey27gv4eWmV89fgkiE8pG6LUpVYgobhh1q7cj44 /PHYdq9VloJBnNVPAAhoPLsGcxoWa4xdi0kG8QKtGST54zqqiOvGwq8gbXlSextVLAUK/XZ0xlNoD 4zLBzVQfQoa6q5OQMTJYh2x1YnJ2iwnd1b1f0XtHG32Pq7EREZ5etTAU8TEyHXqPlkePKinLcghja MKq7w8IuKmHjaJPcJ8AIg+Xqmcbo9P9nayPgFbQUdrgjum6GFUGiwzCeP70ZEwB1IccsRZ6rEszCf UMG8RT9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uKGlC-0000000DEXa-1eKU; Wed, 28 May 2025 13:23:58 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uKGl9-0000000DEXB-3vYL for linux-phy@lists.infradead.org; Wed, 28 May 2025 13:23:57 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D0E295C2BCA; Wed, 28 May 2025 13:21:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEA28C4CEE7; Wed, 28 May 2025 13:23:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748438634; bh=5vKSGaBChbSlR5lX+l//vJBLLeI/kpeZbgb9bJhXdmI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SvGahb1Do9eqe3wYzPHut9tiGeekau9E3fkbyq23F3FrZk/QHelsJAtjySHEJh/S2 BP/9WfUEWcRRx5e+n07v424qqusqgcwVW0B1iKztcH9mvKersXINz2nOVHJ033iSbM t5aeZXGDeNd0MYvnQo5kOg1eZ5YEsJu4zHSkJQHWl9jQQyuONp4yNjCvyTsL3CV/tP y4G3wCbrF7x3FU0EHTfQ0jnZhCxXpwQc2wMCGhb4+JCD4QKVz2RfnSux88ZJGtnKTT 3ZWXiI9Euov3Ym4g6mVEjSxIgRGRRyI7qJOAxlrUKosARIRmzlfONW3KZG90X+TrM3 9JG2TsMFQCGFg== MIME-Version: 1.0 Date: Wed, 28 May 2025 15:23:47 +0200 From: Michael Walle To: Devarsh Thakkar Cc: Tomi Valkeinen , Aradhya Bhatia , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, Francesco Dolcini , Jyri Sarha , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Vinod Koul , Kishon Vijay Abraham I , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec Subject: Re: [PATCH v2 03/18] drm/tidss: Adjust the pclk based on the HW capabilities In-Reply-To: References: <20250402-cdns-dsi-impro-v2-0-4a093eaa5e27@ideasonboard.com> <20250402-cdns-dsi-impro-v2-3-4a093eaa5e27@ideasonboard.com> <8fc0c880-0809-43d6-b03a-1a5728f5d0d4@ideasonboard.com> Message-ID: <27fa4ad56a57f0c408d3b119a620c1cb@kernel.org> X-Sender: mwalle@kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250528_062356_061533_2A2C94D0 X-CRM114-Status: GOOD ( 28.72 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org Hi Devarsh, Hi Tomi, >>> While testing Aardhya's OLDI support patches [1], I've noticed that >>> the resulting LVDS clock is wrong if this patch is applied. >>> >>>> In practice, with the current K3 SoCs, the display PLL is capable of >>>> producing very exact clocks, so most likely the rounded rate is the >>>> same >>>> as the original one. >>> > > Yes, display PLL is flexible and device manager should set exact > frequency. > Please note that there was a bug in device manager in earlier releases > which > would prevent setting it to exact clocks. You should try with latest > SDK > release firmware binaries (11.0...(10.1 should also work though)) if > seeing > any misbehaviour in that regard. Yes, I don't doubt that. But it's the way the driver is handling the clock w.r.t. to the fixed-clock-divider in the LVDS case which is causing problems. >>> This is now what I'm seeing. Most SoCs have that fixed clock thingy >>> for (some?) VPs, e.g. [2]. And clk_round_rate() will return the >>> fixed clock rate for this clock, which will then result in an LVDS >>> clock which is way off. >>> >>> I'm testing on an AM67A (J722S) and I've backported some of the >>> patches as well as dtsi fragmets from downstream. Thus, it might be >>> as well the case that the fixed-factor-clock node is wrong here. >>> OTOH other K3 SoCs do this in mainline as well. >> >> Thanks for findings this (It's not a fixed clock, but a (fixed) >> divider). I can reproduce on my AM62 SK's OLDI output. >> >> I didn't see AM625 TRM explaining the DSS + OLDI clocking. I remember >> it >> was a bit "interesting". Afaics from testing, the VP clock is derived >> from the OLDI serial clock divided by 7. To change the VP clock, we >> need >> to set the OLDI clock's rate. But the code we have at the moment is >> using clk_round_rate/set_rate to the VP clock. >> > > This is correct. The pixel clock is derived as OLDI clock/7 when OLDI > is > enabled. What means "if OLDI is enabled"? Is there any other clock otherwise or none at all? Reading the clock ID desciption in the TISCI documentation, I presume there is no configurable clock for the first VP at all. I.e. if one compares it with DSS1 which has two muxed clocks, DSS0 only has one muxed clock (DEV_DSS0_DPI_1_IN_CLK) and DEV_DSS0_DPI_0_IN_CLK is fixed, presumely thats the fixed /7 clock. Also how is this handled for the DSS1 (on an AM67A)? The TI downstream kernel also has a fixed-clock-divider for the VP1 on DSS1, but I think that is wrong, because it's actually configurable (if OLDI is disabled?). >> And we get the crtc atomic_check called before setting the OLDI clock >> rate, so it doesn't even work by luck (i.e. if the OLDI clock was set >> earlier, the VP clock would already have the right rate, and it would >> seem that everything is ok). In the atomic_check we see the OLDI >> bypass >> clock (25 MHz), which results in 3571428 Hz VP clock. >> >> And with this patch, the code then decides that 3571428 Hz is what the >> HW can do, and uses it as the pixel clock. FWIW, I'm seeing exactly 300MHz on the AM67A (the FCLK is 2.1GHz according to k3conf). -michael >> >> Aradhya, Devarsh, do you remember how the clocking goes here? Or if >> it's >> in the TRM, please point me to it... >> > > I think what you described is correct, if any specific questions I can > help > check. But any misbehaviour you are seeing w.r.t clock setting (i.e. > what > driver is trying to set versus what actually is getting set) > then please dump the dss clock tree along with relevant details of test > done: > > k3conf dump clock > > You can get the device ID via TISCI Doc [1] > > [1]: > https://downloads.ti.com/tisci/esd/latest/5_soc_doc/am62x/clocks.html#clock-for-am62x-device > > Regards > Devarsh -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy