summaryrefslogtreecommitdiff
path: root/include/drm/drm_panel.h
AgeCommit message (Collapse)Author
2018-10-04BackMerge v4.19-rc6 into drm-nextDave Airlie
I have some pulls based on rc6, and I prefer to have an explicit backmerge. Signed-off-by: Dave Airlie <airlied@redhat.com>
2018-09-27Revert "drm/panel: Add device_link from panel device to DRM device"Linus Walleij
This reverts commit 0c08754b59da5557532d946599854e6df28edc22. commit 0c08754b59da ("drm/panel: Add device_link from panel device to DRM device") creates a circular dependency under these circumstances: 1. The panel depends on dsi-host because it is MIPI-DSI child device. 2. dsi-host depends on the drm parent device (connector->dev->dev) this should be allowed. 3. drm parent dev (connector->dev->dev) depends on the panel after this patch. This makes the dependency circular and while it appears it does not affect any in-tree drivers (they do not seem to have dsi hosts depending on the same parent device) this does not seem right. As noted in a response from Andrzej Hajda, the intent is likely to make the panel dependent on the DRM device (connector->dev) not its parent. But we have no way of doing that since the DRM device doesn't contain any struct device on its own (arguably it should). Revert this until a proper approach is figured out. Cc: Jyri Sarha <jsarha@ti.com> Cc: Eric Anholt <eric@anholt.net> Cc: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180927124130.9102-1-linus.walleij@linaro.org
2018-08-16drm: Add kerneldoc description for "link"-member in struct drm_panelJyri Sarha
Add kerneldoc description for "struct device_link *link"-member in struct drm_panel. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1534352611-19074-1-git-send-email-jsarha@ti.com
2018-07-10drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of NULLBoris Brezillon
Right now, the DRM panel logic returns NULL when a panel pointing to the passed OF node is not present in the list of registered panels. Most drivers interpret this NULL value as -EPROBE_DEFER, but we are about to modify the semantic of of_drm_find_panel() and let the framework return -ENODEV when the device node we're pointing to has a status property that is not equal to "okay" or "ok". Let's first patch the of_drm_find_panel() implementation to return ERR_PTR(-EPROBE_DEFER) instead of NULL and patch all callers to replace the '!panel' check by an 'IS_ERR(panel)' one. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180509130042.9435-2-boris.brezillon@bootlin.com
2018-05-18drm/panel: Add device_link from panel device to DRM deviceJyri Sarha
Add device_link from panel device (supplier) to DRM device (consumer) when drm_panel_attach() is called. This patch should protect the master DRM driver if an attached panel driver unbinds while it is in use. The device_link should make sure the DRM device is unbound before the panel driver becomes unavailable. The device_link is removed when drm_panel_detach() is called. The drm_panel_detach() should be called by the consumer DRM driver, not the panel driver, otherwise both drivers are racing to delete the same link. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/b53584fd988d045c13de22d81825395b0ae0aad7.1524727888.git.jsarha@ti.com
2017-05-16drm: make drm_panel.h self-containedMasahiro Yamada
-ENOSYS and -EINVAL are referenced in some static inline functions. of_drm_find_pane() takes a pointer to struct device_node. Make this header self-contained to not depend on specific include order. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1493009447-31524-2-git-send-email-yamada.masahiro@socionext.com
2017-04-06drm: make of_drm_find_panel also depend on CONFIG_DRM_PANELRob Herring
For drm_of_find_panel_or_bridge() added in the next commit, an empty version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2017-01-04drm/panel: Constify device node argument to of_drm_find_panel()Laurent Pinchart
The argument is never modified by the function, make it const. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-05-06drm/panel: Flesh out kerneldocThierry Reding
Write more complete kerneldoc comments for the DRM panel API and integrate the helpers in the DRM DocBook reference. Signed-off-by: Thierry Reding <treding@nvidia.com>drm/panel: Add helper for simple panel connector Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160506140137.GA4641@ulmo.ba.sec
2015-04-02drm/panel: Add display timing supportPhilipp Zabel
Many panel data sheets, additionally to typical values, list allowed ranges for timings such as hsync/vsync lengths, porches, and the pixel clock rate. These can be stored in a struct display_timing, to be used by an encoder mode_fixup callback to clamp user provided timing values or to validate workarounds for clock source limitations. This patch adds a new drm_panel_funcs callback that returns the panel's available display_timing entries. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-08-06drm/panel: Provide convenience wrapper for .get_modes()Ajay Kumar
Add a convenience wrapper for the struct drm_panel_funcs' .get_modes() function so that not every driver needs to check that the panel driver implements the function before calling it. Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> [treding: extract from larger patch, commit message] Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-08-06drm/panel: add .prepare() and .unprepare() functionsAjay Kumar
Panels often require an initialization sequence that consists of three steps: a) powering up the panel, b) starting transmission of video data and c) enabling the panel (e.g. turn on backlight). This is usually necessary to avoid visual glitches at the beginning of video data transmission. Similarly, the shutdown sequence is typically done in three steps as well: a) disable the panel (e.g. turn off backlight), b) cease video data transmission and c) power down the panel. Currently drivers can only implement .enable() and .disable() functions, which is not enough to implement the above sequences. This commit adds a second pair of functions, .prepare() and .unprepare() to allow more fine-grained control over when the above steps are performed. Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> [treding: rewrite changelog, add kerneldoc] Signed-off-by: Thierry Reding <treding@nvidia.com>
2013-12-17drm: Add panel supportThierry Reding
Add a very simple framework to register and lookup panels. Panel drivers can initialize a DRM panel and register it with the framework, allowing them to be retrieved and used by display drivers. Currently only support for DPMS and obtaining panel modes is provided. However it should be sufficient to enable a large number of panels. The framework should also be easily extensible to support more sophisticated kinds of panels such as DSI. The framework hasn't been tied into the DRM core, even though it should be easily possible to do so if that's what we want. In the current implementation, display drivers can simple make use of it to retrieve a panel, obtain its modes and control its DPMS mode. Note that this is currently only tested on systems that boot from a device tree. No glue code has been written yet for systems that use platform data, but it should be easy to add. Signed-off-by: Thierry Reding <treding@nvidia.com>