mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Devarsh Thakkar <devarsht@ti.com>
Cc: sakari.ailus@linux.intel.com, u.kleine-koenig@baylibre.com,
	vigneshr@ti.com, aradhya.bhatia@linux.dev, s-jain1@ti.com,
	r-donadkar@ti.com, vkoul@kernel.org, kishon@kernel.org,
	mripard@kernel.org, linux-phy@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] phy: cadence: cdns-dphy: Update calibration wait time for startup state machine
Date: Wed, 2 Apr 2025 16:59:51 +0300	[thread overview]
Message-ID: <4015caef-1afb-4c3f-8768-a3a5d51390a0@ideasonboard.com> (raw)
In-Reply-To: <223da324-4de7-4e62-b001-ea89c4768a13@ti.com>

Hi,

On 02/04/2025 16:35, Devarsh Thakkar wrote:
> Hi Tomi,
> 
> Thanks for the review.
> 
> On 02/04/25 17:12, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 26/03/2025 17:23, Devarsh Thakkar wrote:
>>> Use system characterized reset value specified in TRM [1] to program
>>> calibration wait time which defines number of cycles to wait for after
>>> startup state machine is in bandgap enable state.
>>>
>>> This fixes PLL lock timeout error faced while using RPi DSI Panel on 
>>> TI's
>>> AM62L and J721E SoC [2].
>>>
>>> [1] AM62P TRM (Section ):
>>> https://www.ti.com/lit/pdf/spruj83
>>>
>>> [2]:
>>> Link: https://gist.github.com/devarsht/89e4830e886774fcd50aa6e29cce3a79
>>>
>>> Cc: stable@vger.kernel.org
>>> Fixes: 7a343c8bf4b5 ("phy: Add Cadence D-PHY support")
>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>> ---
>>> V2: Introduced this as as separate patch
>>>
>>>   drivers/phy/cadence/cdns-dphy.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/ 
>>> cdns-dphy.c
>>> index c4de9e4d3e93..11fbffe5aafd 100644
>>> --- a/drivers/phy/cadence/cdns-dphy.c
>>> +++ b/drivers/phy/cadence/cdns-dphy.c
>>> @@ -30,6 +30,7 @@
>>>   #define DPHY_CMN_SSM            DPHY_PMA_CMN(0x20)
>>>   #define DPHY_CMN_SSM_EN            BIT(0)
>>> +#define DPHY_CMN_SSM_CAL_WAIT_TIME    GENMASK(8, 1)
>>>   #define DPHY_CMN_TX_MODE_EN        BIT(9)
>>>   #define DPHY_CMN_PWM            DPHY_PMA_CMN(0x40)
>>> @@ -405,6 +406,8 @@ static int cdns_dphy_configure(struct phy *phy, 
>>> union phy_configure_opts *opts)
>>>       reg = FIELD_PREP(DPHY_BAND_CFG_LEFT_BAND, band_ctrl) |
>>>             FIELD_PREP(DPHY_BAND_CFG_RIGHT_BAND, band_ctrl);
>>>       writel(reg, dphy->regs + DPHY_BAND_CFG);
>>> +    writel(FIELD_PREP(DPHY_CMN_SSM_CAL_WAIT_TIME, 0x14) | 
>>> DPHY_CMN_SSM_EN | DPHY_CMN_TX_MODE_EN,
>>> +           dphy->regs + DPHY_CMN_SSM);
>>
>> This sounds like a TI specific characterized value, but the function 
>> here is a generic one. Also, is the value same for all TI SoCs? Or is 
>> it per-soc?
>>
> 
> No this is not TI specific value. As mentioned in commit message, 0x14 
> is the cadence characterized default value for calibration wait time 
> which they put in as reset value in the IP (if you reset the IP you will 
> see calibration wait time as 0x14) to be used by software for optimal 
> initialization.

If it's a register default value, why do you need to write it? Also, why 
do you say "characterized reset value"? I can't find any reference to 
this in the TRM (in the patch you point to the TRM, but not where to 
find the data there). The reset value of 0x14 could be just a default 
value, not characterized at all. And if this is a bandgad related wait 
timeout, shouldn't it be set before the BAND_CFG registers? Although 
It's not clear what those do.

  Tomi


  reply	other threads:[~2025-04-02 13:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-26 15:23 [PATCH v2 0/2] Fix PLL lock timeout and calibration wait time Devarsh Thakkar
2025-03-26 15:23 ` [PATCH v2 1/2] phy: cadence: cdns-dphy: Fix PLL lock and O_CMN_READY polling Devarsh Thakkar
2025-04-02 11:55   ` Tomi Valkeinen
2025-04-02 13:29     ` Devarsh Thakkar
2025-03-26 15:23 ` [PATCH v2 2/2] phy: cadence: cdns-dphy: Update calibration wait time for startup state machine Devarsh Thakkar
2025-04-02 11:42   ` Tomi Valkeinen
2025-04-02 13:35     ` Devarsh Thakkar
2025-04-02 13:59       ` Tomi Valkeinen [this message]
2025-04-30  7:36     ` Devarsh Thakkar

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=4015caef-1afb-4c3f-8768-a3a5d51390a0@ideasonboard.com \
    --to=tomi.valkeinen@ideasonboard.com \
    --cc=aradhya.bhatia@linux.dev \
    --cc=devarsht@ti.com \
    --cc=kishon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=mripard@kernel.org \
    --cc=r-donadkar@ti.com \
    --cc=s-jain1@ti.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=vigneshr@ti.com \
    --cc=vkoul@kernel.org \
    /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

all inboxes | Powered by JetHome®