[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c49f1741-d03a-08f2-ddb1-3b0462a67790@ti.com>
Date: Mon, 3 Feb 2025 13:29:59 +0530
From: Devarsh Thakkar <devarsht@...com>
To: Jai Luthra <jai.luthra@...asonboard.com>
CC: <vkoul@...nel.org>, <kishon@...nel.org>, <mripard@...nel.org>,
<linux-phy@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
<sakari.ailus@...ux.intel.com>, <vigneshr@...com>,
<aradhya.bhatia@...ux.dev>, <s-jain1@...com>, <r-donadkar@...com>,
<tomi.valkeinen@...asonboard.com>, <j-choudhary@...com>,
<h-shenoy@...com>, <praneeth@...com>, <u-kumar1@...com>
Subject: Re: [PATCH] phy: cadence: cdns-dphy: Fix PLL lock and common ready
poll timeout
Hi Jai,
On 30/12/24 19:12, Jai Luthra wrote:
> Hi Devarsh,
>
> Thanks for the patch, must have been a fun debug :)
>
Thanks for the review. Oh yeah indeed :).
<snip>
>> 1) PLL lockup and O_CMN_READY assertion can only happen after common state
>> machine gets enabled, but driver was polling them before the common
>> state machine was enabled. To fix this, add new function callbacks for
>> polling on PLL lock and O_CMN_READY assertion and call them only after
>> common state machine gets enabled.
>>
>> 2) The cadence DPHY IP registers (as described in J721E TRM [2]) has
>> default reset values for register fields in some of the registers
>> which were getting reset to 0 as driver was not preserving them and
>> overwriting those bits to 0 while updating the registers thus impacting
>> the overall PLL lockup time. For e.g. DPHY_TX_CMN0_CMN_DIG_TBIT2 has
>> bits 1-8 used for PLL wait time calibrations with default value as 0x14h
>> and DPHY_TX_CMN0_CMN_DIG_TBIT10 has bits 27-20 used for PWM Byteclock
>> divider which is default set to 0x8. To avoid resetting these register
>> bit-fields, perform read-modify-write while updating above registers.
>
> IMHO these are separate changes, and thus should be separate patches,
> even if they are both done to reduce the time spent in the wait loop.
>
> Ideally first patch to fix (2) across the driver, checking if there are
> any other registers with default values that are being overwritten.
>
> And the second patch to fix (1)
Yes that sounds like a good idea indeed. Will fix this in V2 and re-spin.
Regards
Devarsh
Powered by blists - more mailing lists