Skip to content

Commit 4316776

Browse files
mwallegregkh
authored andcommitted
drm/bridge: ti-sn65dsi86: fix REFCLK setting
[ Upstream commit bdd5a14 ] The bridge has three bootstrap pins which are sampled to determine the frequency of the external reference clock. The driver will also (over)write that setting. But it seems this is racy after the bridge is enabled. It was observed that although the driver write the correct value (by sniffing on the I2C bus), the register has the wrong value. The datasheet states that the GPIO lines have to be stable for at least 5us after asserting the EN signal. Thus, there seems to be some logic which samples the GPIO lines and this logic appears to overwrite the register value which was set by the driver. Waiting 20us after asserting the EN line resolves this issue. Fixes: a095f15 ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250821122341.1257286-1-mwalle@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
1 parent f2e6b99 commit 4316776

1 file changed

Lines changed: 11 additions & 0 deletions

File tree

drivers/gpu/drm/bridge/ti-sn65dsi86.c

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -313,6 +313,17 @@ static int __maybe_unused ti_sn65dsi86_resume(struct device *dev)
313313

314314
gpiod_set_value(pdata->enable_gpio, 1);
315315

316+
/*
317+
* After EN is deasserted and an external clock is detected, the bridge
318+
* will sample GPIO3:1 to determine its frequency. The driver will
319+
* overwrite this setting in ti_sn_bridge_set_refclk_freq(). But this is
320+
* racy. Thus we have to wait a couple of us. According to the datasheet
321+
* the GPIO lines has to be stable at least 5 us (td5) but it seems that
322+
* is not enough and the refclk frequency value is still lost or
323+
* overwritten by the bridge itself. Waiting for 20us seems to work.
324+
*/
325+
usleep_range(20, 30);
326+
316327
/*
317328
* If we have a reference clock we can enable communication w/ the
318329
* panel (including the aux channel) w/out any need for an input clock

0 commit comments

Comments
 (0)