From: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
To: "Emanuele Ghidoli" <ghidoliemanuele@gmail.com>,
"João Paulo Gonçalves" <jpaulo.silvagoncalves@gmail.com>,
"Francesco Dolcini" <francesco@dolcini.it>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>
Cc: "Philippe Schenker" <philippe.schenker@impulsing.ch>,
"Hui Pu" <Hui.Pu@gehealthcare.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, "Hervé Codina" <herve.codina@bootlin.com>
Subject: Re: [PATCH] drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors
Date: Wed, 03 Dec 2025 18:32:47 +0100 [thread overview]
Message-ID: <DEORF6XCJEOG.3BGTKVL2QFQKN@bootlin.com> (raw)
In-Reply-To: <cd607656-90d3-4821-98ea-4dad48288fc9@gmail.com>
Hi Emanuele,
On Tue Dec 2, 2025 at 12:19 PM CET, Emanuele Ghidoli wrote:
>
>
> On 27/11/2025 09:42, Luca Ceresoli wrote:
>> On hardware based on Toradex Verdin AM62 the recovery mechanism added by
>> commit ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery
>> mechanism") has been reported [0] to make the display turn on and off and
>> and the kernel logging "Unexpected link status 0x01".
>>
>> According to the report, the error recovery mechanism is triggered by the
>> PLL_UNLOCK error going active. Analysis suggested the board is unable to
>> provide the correct DSI clock neede by the SN65DSI84, to which the TI
>> SN65DSI84 reacts by raising the PLL_UNLOCK, while the display still works
>> apparently without issues.
>>
>> On other hardware, where all the clocks are within the components
>> specifications, the PLL_UNLOCK bit does not trigger while the display is in
>> normal use. It can trigger for e.g. electromagnetic interference, which is
>> a transient event and exactly the reason why the error recovery mechanism
>> has been implemented.
>>
>> Idelly the PLL_UNLOCK bit could be ignored when working out of
>> specification, but this requires to detect in software whether it triggers
>> because the device is working out of specification but visually correctly
>> for the user or for good reasons (e.g. EMI, or even because working out of
>> specifications but compromising the visual output).
>>
>> The ongoing analysis as of this writing [1][2] has not yet found a way for
>> the driver to discriminate among the two cases. So as a temporary measure
>> mask the PLL_UNLOCK error bit unconditionally.
>>
>> [0] https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsdx@mgkdf6ztow42
>> [1] https://lore.kernel.org/all/b71e941c-fc8a-4ac1-9407-0fe7df73b412@gmail.com/
>> [2] https://lore.kernel.org/all/20251125103900.31750-1-francesco@dolcini.it/
>>
>> Closes: https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsdx@mgkdf6ztow42
>> Cc: stable@vger.kernel.org # 6.15+
>> Co-developed-by: Hervé Codina <herve.codina@bootlin.com>
>> Signed-off-by: Hervé Codina <herve.codina@bootlin.com>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> ---
>> Francesco, Emanuele, João: can you please apply this patch and report
>> whether the display on the affected boards gets back to working as before?
>>
>> Cc: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
>> Cc: Francesco Dolcini <francesco@dolcini.it>
>> Cc: Emanuele Ghidoli <ghidoliemanuele@gmail.com>
>> ---
>> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> index 033c44326552..fffb47b62f43 100644
>> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> @@ -429,7 +429,14 @@ static void sn65dsi83_handle_errors(struct sn65dsi83 *ctx)
>> */
>>
>> ret = regmap_read(ctx->regmap, REG_IRQ_STAT, &irq_stat);
>> - if (ret || irq_stat) {
>> +
>> + /*
>> + * Some hardware (Toradex Verdin AM62) is known to report the
>> + * PLL_UNLOCK error interrupt while working without visible
>> + * problems. In lack of a reliable way to discriminate such cases
>> + * from user-visible PLL_UNLOCK cases, ignore that bit entirely.
>> + */
>> + if (ret || irq_stat & ~REG_IRQ_STAT_CHA_PLL_UNLOCK) {
>> /*
>> * IRQ acknowledged is not always possible (the bridge can be in
>> * a state where it doesn't answer anymore). To prevent an
>> @@ -654,7 +661,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge,
>> if (ctx->irq) {
>> /* Enable irq to detect errors */
>> regmap_write(ctx->regmap, REG_IRQ_GLOBAL, REG_IRQ_GLOBAL_IRQ_EN);
>> - regmap_write(ctx->regmap, REG_IRQ_EN, 0xff);
>> + regmap_write(ctx->regmap, REG_IRQ_EN, 0xff & ~REG_IRQ_EN_CHA_PLL_UNLOCK_EN);
>> } else {
>> /* Use the polling task */
>> sn65dsi83_monitor_start(ctx);
>>
>> ---
>> base-commit: c884ee70b15a8d63184d7c1e02eba99676a6fcf7
>> change-id: 20251126-drm-ti-sn65dsi83-ignore-pll-unlock-4a28aa29eb5c
>>
>> Best regards,
Thanks for testing!
We'll still need a R-by from a maintainer, after that this patch can be applied.
> I would suggest a couple of tags, thanks.
> Emanuele
>
> Fixes: ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism")
I'm not sure about this one. There is no known bug in that commit, right?
It's rather exposing a pre-existing issue. I thought about adding it for
stable branches pickup, but the 'Cc: stable...v6.15+' line is for that.
So apart from blaming someone I don't see much point.
That said, if there is a valid reason I'm not seeing for the Fixes: line,
I'll be OK in adding it while applying.
> Reported-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
Absolutely! Sorry I forgot to add this.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2025-12-03 17:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 8:42 Luca Ceresoli
2025-12-02 10:56 ` Emanuele Ghidoli
2025-12-02 11:19 ` Emanuele Ghidoli
2025-12-03 17:32 ` Luca Ceresoli [this message]
2025-12-05 9:07 ` Maxime Ripard
2025-12-09 10:29 ` Luca Ceresoli
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=DEORF6XCJEOG.3BGTKVL2QFQKN@bootlin.com \
--to=luca.ceresoli@bootlin.com \
--cc=Hui.Pu@gehealthcare.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=francesco@dolcini.it \
--cc=ghidoliemanuele@gmail.com \
--cc=herve.codina@bootlin.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=jpaulo.silvagoncalves@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=philippe.schenker@impulsing.ch \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=tzimmermann@suse.de \
/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®