kernel/linux.git/drivers/gpu/drm/bridge, branch linux-4.20.y

drm/bridge: tc358767: fix output H/V syncs

2019-02-20T09:29:04+00:00

[ Upstream commit 7923e09c7a766e2d58de7fc395bb84c18e5bc625 ] The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin

drm/bridge: tc358767: reject modes which require too much BW

2019-02-20T09:29:04+00:00

[ Upstream commit 51b9e62eb6950c762162ab7eb8390990179be067 ] The current driver accepts any videomode with pclk < 154MHz. This is not correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be supported. Add code to reject modes that require more bandwidth that is available. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin

drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value

2019-02-20T09:29:04+00:00

[ Upstream commit 9a63bd6fe1b5590ffa42ae2ed22ee21363293e31 ] Initially DP0_SRCCTRL is set to a static value which includes DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of 1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number. This patch changes the configuration as follows: Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct value. DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL: SSCG and BW27. All other bits can be zero. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin

drm/bridge: tc358767: fix single lane configuration

2019-02-20T09:29:03+00:00

[ Upstream commit 4d9d54a730434cc068dd3515ba6116697196f77b ] PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use. Set PHY_2LANE only when 2 lanes are used. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-4-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin

drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE

2019-02-20T09:29:03+00:00

[ Upstream commit adf4109896bbee27fd2ac3b48d22d6a0062fe517 ] DP1_SRCCTRL register and PHY_2LANE field did not have matching defines. Add these. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-3-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin

drm/bridge: tc358767: add bus flags

2019-02-20T09:29:03+00:00

[ Upstream commit 4842379cbe6e851de914a7132f76f4e200b9a98b ] tc358767 driver does not set DRM bus_flags, even if it does configures the polarity settings into its registers. This means that the DPI source can't configure the polarities correctly. Add sync flags accordingly. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-2-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin

drm/bridge: fix AUX_CMD_SEND bit value for ti, sn65dsi86 bridge

2018-11-30T15:45:06+00:00

Fix the AUX_CMD_SEND bit for ti,sn65dsi86 bridge chip. With wrong value the dpcd aux transactions with eDP panel are failing. Signed-off-by: Sandeep Panda Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20181130092745.4219-1-spanda@codeaurora.org

drm/bridge: ti-sn65dsi86: Remove the mystery delay

2018-10-29T15:53:27+00:00

Let's solve the mystery of commit bf1178c98930 ("drm/bridge: ti-sn65dsi86: Add mystery delay to enable()"). Specifically the reason we needed that mystery delay is that we weren't paying attention to HPD. Looking at the datasheet for the same panel that was tested for the original commit, I see there's a timing "t3" that times from power on to the aux channel being operational. This time is specced as 0 - 200 ms. The datasheet says that the aux channel is operational at exactly the same time that HPD is asserted. Scoping the signals on this board showed that HPD was asserted 84 ms after power was asserted. That very closely matches the magic 70 ms delay that we had. ...and actually, in my testing the 70 ms wasn't quite enough of a delay and some percentage of the time the display didn't come up until I bumped it to 100 ms (presumably 84 ms would have worked too). To solve this, we tried to hook up the HPD signal in the bridge. ...but in doing so we found that that the bridge didn't report that HPD was asserted until ~280 ms after we powered it (!). This is explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD (Hot Plug/Unplug Detection)". Reading there we see that the bridge isn't even intended to report HPD until 100 ms after it's asserted. ...but that would have left us at 184 ms. The extra 100 ms (presumably) comes from this part in the datasheet: > The HPD state machine operates off an internal ring oscillator. The > ring oscillator frequency will vary [ ... ]. The min/max range in > the HPD State Diagram refers to the possible times based off > variation in the ring oscillator frequency. Given that the 280 ms we'll end up delaying if we hook up HPD is _slower_ than the 200 ms we could just hardcode, for now we'll solve the problem by just hardcoding a 200 ms delay in the panel driver using the patch in this series ("drm/panel: simple: Support panels with HPD where HPD isn't connected"). If we later find a panel that needs to use this bridge where we need HPD then we'll have to come up with some new code to handle it. Given the silly debouncing in the bridge chip, though, it seems unlikely. One last note is that I tried to solve this through another way: In ti_sn_bridge_enable() I tried to use various combinations of dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel was up. In theory that would let me detect _exactly_ when I could continue and do link training. Unfortunately even if I did an aux transfer w/out waiting I couldn't see any errors. Possibly I could keep looping over link training until it came back with success, but that seemed a little overly hacky to me. Reviewed-by: Sean Paul Reviewed-by: Andrzej Hajda Signed-off-by: Douglas Anderson Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-4-dianders@chromium.org

drm: bridge: thc63: Restrict modes based on hardware operating frequency

2018-09-24T21:40:51+00:00

The THC63LVD1024 is restricted to a pixel clock frequency in the range of 8 to 135 MHz. Implement the bridge .mode_valid() operation accordingly. Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Tested-by: Jacopo Mondi

drm/bridge: analogix_dp: Downgrade "Link Training" messages to dev_dbg

2018-09-13T08:47:17+00:00

The Analogix DP bridge driver is pretty verbose, and outputs things like [ 619.414067] rockchip-dp ff970000.edp: Link Training Clock Recovery success [ 619.429233] rockchip-dp ff970000.edp: Link Training success! each time the display gets unblanked. While it is good to know that the device is behaving correctly, users already know that because they can see some video output. Let's keep these messages for cases where we need to actually debug the driver (we have dynamic debug to enable them at runtime if need be), and let's keep the kernel quiet otherwise. Signed-off-by: Marc Zyngier Reviewed-by: Laurent Pinchart Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20180805172857.2517-1-marc.zyngier@arm.com