]> asedeno.scripts.mit.edu Git - linux.git/commitdiff
drm/bridge: ti-sn65dsi86: Add mystery delay to enable()
authorSean Paul <seanpaul@chromium.org>
Mon, 13 Aug 2018 21:30:46 +0000 (17:30 -0400)
committerSean Paul <seanpaul@chromium.org>
Mon, 27 Aug 2018 14:57:20 +0000 (10:57 -0400)
This patch adds a 70ms mystery delay to the bridge driver in enable.
By experimentation, it seems like it can go anywhere up until we
initiate semi-auto link training. If we don't have the delay, link
training fails.

I tried to root cause this as best I could, but neither the datasheet
for the panel nor the bridge mention a delay of this magnitude in their
timing requirements. So for now, add the mystery delay until someone
figures out a better fix.

Changes in v3:
- Added to the set

Cc: Sandeep Panda <spanda@codeaurora.org>
Reviewed-by: Sandeep Panda <spanda@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180813213058.184821-8-sean@poorly.run
drivers/gpu/drm/bridge/ti-sn65dsi86.c

index d3e27e52ea7597686fe1b46cd8d9719fee3e0da3..f8a931cf3665e8bac6a02017760c33d790d530a0 100644 (file)
@@ -458,6 +458,18 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
        unsigned int val;
        int ret;
 
+       /*
+        * FIXME:
+        * This 70ms was found necessary by experimentation. If it's not
+        * present, link training fails. It seems like it can go anywhere from
+        * pre_enable() up to semi-auto link training initiation below.
+        *
+        * Neither the datasheet for the bridge nor the panel tested mention a
+        * delay of this magnitude in the timing requirements. So for now, add
+        * the mystery delay until someone figures out a better fix.
+        */
+       msleep(70);
+
        /* DSI_A lane config */
        val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
        regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,