kernel/linux.git/drivers/gpu/drm/bridge, branch v4.20.5

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

drm/bridge: ti-sn65dsi86: Add mystery delay to enable()

2018-08-27T14:57:20+00:00

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 Reviewed-by: Sandeep Panda Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180813213058.184821-8-sean@poorly.run

Merge drm/drm-next into drm-misc-next

2018-08-27T14:00:03+00:00

Now that 4.19-rc1 is cut, backmerge it into -misc-next. Signed-off-by: Sean Paul

drm/bridge: ti-sn65dsi86: Fix 0-day build error

2018-08-16T15:26:37+00:00

0day reports: >> drivers/gpu/drm/bridge/ti-sn65dsi86.o: In function mipi_dsi_detach' >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:630: undefined reference to ti_sn_bridge_attach': >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:249: undefined reference to mipi_dsi_device_register_full' >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:276: undefined reference to mipi_dsi_device_unregister' Quite obviously the driver depends on DRM_MIPI_DSI. We can not use depends since the driver configuration uses select, so we'll have to select the missing dependency instead. Cc: Sean Paul Cc: Dylan Reid Reviewed-by: Daniel Vetter Signed-off-by: Guenter Roeck Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180815194923.3258-1-sean@poorly.run

Merge tag 'drm-next-2018-08-15' of git://anongit.freedesktop.org/drm/drm

2018-08-16T00:39:07+00:00

Pull drm updates from Dave Airlie: "This is the main drm pull request for 4.19. Rob has some new hardware support for new qualcomm hw that I'll send along separately. This has the display part of it, the remaining pull is for the acceleration engine. This also contains a wound-wait/wait-die mutex rework, Peter has acked it for merging via my tree. Otherwise mostly the usual level of activity. Summary: core: - Wound-wait/wait-die mutex rework - Add writeback connector type - Add "content type" property for HDMI - Move GEM bo to drm_framebuffer - Initial gpu scheduler documentation - GPU scheduler fixes for dying processes - Console deferred fbcon takeover support - Displayport support for CEC tunneling over AUX panel: - otm8009a panel driver fixes - Innolux TV123WAM and G070Y2-L01 panel driver - Ilitek ILI9881c panel driver - Rocktech RK070ER9427 LCD - EDT ETM0700G0EDH6 and EDT ETM0700G0BDH6 - DLC DLC0700YZG-1 - BOE HV070WSA-100 - newhaven, nhd-4.3-480272ef-atxl LCD - DataImage SCF0700C48GGU18 - Sharp LQ035Q7DB03 - p079zca: Refactor to support multiple panels tinydrm: - ILI9341 display panel New driver: - vkms - virtual kms driver to testing. i915: - Icelake: Display enablement DSI support IRQ support Powerwell support - GPU reset fixes and improvements - Full ppgtt support refactoring - PSR fixes and improvements - Execlist improvments - GuC related fixes amdgpu: - Initial amdgpu documentation - JPEG engine support on VCN - CIK uses powerplay by default - Move to using core PCIE functionality for gens/lanes - DC/Powerplay interface rework - Stutter mode support for RV - Vega12 Powerplay updates - GFXOFF fixes - GPUVM fault debugging - Vega12 GFXOFF - DC improvements - DC i2c/aux changes - UVD 7.2 fixes - Powerplay fixes for Polaris12, CZ/ST - command submission bo_list fixes amdkfd: - Raven support - Power management fixes udl: - Cleanups and fixes nouveau: - misc fixes and cleanups. msm: - DPU1 support display controller in sdm845 - GPU coredump support. vmwgfx: - Atomic modesetting validation fixes - Support for multisample surfaces armada: - Atomic modesetting support completed. exynos: - IPPv2 fixes - Move g2d to component framework - Suspend/resume support cleanups - Driver cleanups imx: - CSI configuration improvements - Driver cleanups - Use atomic suspend/resume helpers - ipu-v3 V4L2 XRGB32/XBGR32 support pl111: - Add Nomadik LCDC variant v3d: - GPU scheduler jobs management sun4i: - R40 display engine support - TCON TOP driver mediatek: - MT2712 SoC support rockchip: - vop fixes omapdrm: - Workaround for DRA7 errata i932 - Fix mm_list locking mali-dp: - Writeback implementation PM improvements - Internal error reporting debugfs tilcdc: - Single fix for deferred probing hdlcd: - Teardown fixes tda998x: - Converted to a bridge driver. etnaviv: - Misc fixes" * tag 'drm-next-2018-08-15' of git://anongit.freedesktop.org/drm/drm: (1506 commits) drm/amdgpu/sriov: give 8s for recover vram under RUNTIME drm/scheduler: fix param documentation drm/i2c: tda998x: correct PLL divider calculation drm/i2c: tda998x: get rid of private fill_modes function drm/i2c: tda998x: move mode_valid() to bridge drm/i2c: tda998x: register bridge outside of component helper drm/i2c: tda998x: cleanup from previous changes drm/i2c: tda998x: allocate tda998x_priv inside tda998x_create() drm/i2c: tda998x: convert to bridge driver drm/scheduler: fix timeout worker setup for out of order job completions drm/amd/display: display connected to dp-1 does not light up drm/amd/display: update clk for various HDMI color depths drm/amd/display: program display clock on cache match drm/amd/display: Add NULL check for enabling dp ss drm/amd/display: add vbios table check for enabling dp ss drm/amd/display: Don't share clk source between DP and HDMI drm/amd/display: Fix DP HBR2 Eye Diagram Pattern on Carrizo drm/amd/display: Use calculated disp_clk_khz value for dce110 drm/amd/display: Implement custom degamma lut on dcn drm/amd/display: Destroy aux_engines only once ...

drm/bridge: ti-sn65dsi86: Poll for training complete

2018-08-14T18:06:13+00:00

Instead of just waiting 20ms for training to complete, actually poll the status to ensure training is finished. Changes in v3: - Added to the set Cc: Sandeep Panda Reviewed-by: Sandeep Panda Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180813213058.184821-7-sean@poorly.run

drm/bridge: ti-sn65dsi86: Poll for DP PLL Lock

2018-08-14T18:06:01+00:00

Instead of just waiting and hoping, actually poll for the pll lock to be acquired. As a bonus, this should be significantly faster than the sleep. Changes in v3: - Added to the set Cc: Sandeep Panda Reviewed-by: Sandeep Panda Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180813213058.184821-6-sean@poorly.run