kernel.git/drivers/gpu/drm/msm/edp, branch linux-5.14.y

drm/msm: Fix null pointer dereference on pointer edp

2021-10-20T09:57:57Z

commit 2133c4fc8e1348dcb752f267a143fe2254613b34 upstream. The initialization of pointer dev dereferences pointer edp before edp is null checked, so there is a potential null pointer deference issue. Fix this by only dereferencing edp after edp has been null checked. Addresses-Coverity: ("Dereference before null check") Fixes: ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)") Signed-off-by: Colin Ian King Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210929121857.213922-1-colin.king@canonical.com Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

Merge tag 'drm-msm-next-2021-06-23b' of https://gitlab.freedesktop.org/drm/msm into drm-next

2021-06-23T21:21:16Z

* devcoredump support for display errors * dpu: irq cleanup/refactor * dpu: dt bindings conversion to yaml * dsi: dt bindings conversion to yaml * mdp5: alpha/blend_mode/zpos support * a6xx: cached coherent buffer support * a660 support * gpu iova fault improvements: - info about which block triggered the fault, etc - generation of gpu devcoredump on fault * assortment of other cleanups and fixes Signed-off-by: Dave Airlie From: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGs4=qsGBBbyn-4JWqW4-YUSTKh67X3DsPQ=T2D9aXKqNA@mail.gmail.com

drm/msm: Generated register update

2021-06-23T14:33:54Z

Based on mesa commit daa2ccff7a0201941db3901780d179e2634057d5 Small bit of .c churn in the phy code to adapt to split up of phy related registers. Signed-off-by: Rob Clark

drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()

2021-04-27T22:43:42Z

So that we can start using drm_dbg_*() for drm_dp_link_train_channel_eq_delay() and drm_dp_lttpr_link_train_channel_eq_delay(). Signed-off-by: Lyude Paul Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-7-lyude@redhat.com Reviewed-by: Dave Airlie

drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()

2021-04-27T22:43:42Z

So that we can start using drm_dbg_*() in drm_dp_link_train_clock_recovery_delay(). Signed-off-by: Lyude Paul Reviewed-by: Laurent Pinchart Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-6-lyude@redhat.com Reviewed-by: Dave Airlie

drm/dp: Add backpointer to drm_device in drm_dp_aux

2021-04-27T22:43:42Z

This is something that we've wanted for a while now: the ability to actually look up the respective drm_device for a given drm_dp_aux struct. This will also allow us to transition over to using the drm_dbg_*() helpers for debug message printing, as we'll finally have a drm_device to reference for doing so. Note that there is one limitation with this - because some DP AUX adapters exist as platform devices which are initialized independently of their respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be non-NULL until drm_dp_aux_register() has been called. We make sure to point this out in the documentation for struct drm_dp_aux. v3: * Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out Signed-off-by: Lyude Paul Acked-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-4-lyude@redhat.com Reviewed-by: Dave Airlie

drm/msm: sync generated headers

2020-07-31T13:46:16Z

We haven't sync'd for a while.. pull in updates to get definitions for some fields in pkt7 payloads. Signed-off-by: Rob Clark Acked-by: Jordan Crouse Signed-off-by: Rob Clark

Merge tag 'drm-msm-next-2020-03-22' of https://gitlab.freedesktop.org/drm/msm into drm-next

2020-03-31T06:34:55Z

A bit smaller this time around.. there are still a couple uabi additions for vulkan waiting in the wings, but I punted on them this cycle due to running low on time. (They should be easy enough to rebase, and if it is a problem for anyone I can push a next+uabi branch so that tu work can proceed.) The bigger change is refactoring dpu resource manager and moving dpu to use atomic global state. Other than that, it is mostly cleanups and fixes. From: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/

drm/msm: avoid double-attaching hdmi/edp bridges

2020-03-19T19:08:52Z

Each of hdmi and edp are already attached in msm_*_bridge_init. A second attachment returns -EBUSY, failing the driver load. Tested with HDMI on IFC6410 (APQ8064 / MDP4), but eDP case should be analogous. Fixes: 3ef2f119bd3ed (drm/msm: Use drm_attach_bridge() to attach a bridge to an encoder) Cc: Boris Brezillon Signed-off-by: Ilia Mirkin Reviewed-by: Rob Clark Reviewed-by: Boris Brezillon Tested-by: Bjorn Andersson (hdmi part) Reviewed-by: Bjorn Andersson Signed-off-by: Rob Clark

drm/bridge: Extend bridge API to disable connector creation

2020-02-26T11:31:23Z

Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector should be moved to the display controller driver (where it can be implemented using helpers provided by the core). Extend the bridge API to allow disabling connector creation in bridge drivers as a first step towards the new model. The new flags argument to the bridge .attach() operation allows instructing the bridge driver to skip creating a connector. Unconditionally set the new flags argument to 0 for now to keep the existing behaviour, and modify all existing bridge drivers to return an error when connector creation is not requested as they don't support this feature yet. The change is based on the following semantic patch, with manual review and edits. @ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .attach = fn }; @ depends on rule1 @ identifier rule1.fn; identifier bridge; statement S, S1; @@ int fn( struct drm_bridge *bridge + , enum drm_bridge_attach_flags flags ) { ... when != S + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) { + DRM_ERROR("Fix bridge driver to make connector optional!"); + return -EINVAL; + } + S1 ... } @ depends on rule1 @ identifier rule1.fn; identifier bridge, flags; expression E1, E2, E3; @@ int fn( struct drm_bridge *bridge, enum drm_bridge_attach_flags flags ) { <... drm_bridge_attach(E1, E2, E3 + , flags ) ...> } @@ expression E1, E2, E3; @@ drm_bridge_attach(E1, E2, E3 + , 0 ) Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon Acked-by: Sam Ravnborg Reviewed-by: Tomi Valkeinen Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel Acked-by: Daniel Vetter Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com