summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/omapdrm/omap_encoder.c
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15drm/omap: drop unused DSS next pointerSebastian Reichel1-4/+0
Since all encoders and panels are using the bridge API now, we next pointer is no longer useful and can be dropped. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-45-tomi.valkeinen@ti.com
2020-12-15drm/omap: remove unused omap_connectorSebastian Reichel1-19/+0
Remove unused code. Connectors are now created via drm_bridge_connector_init() and no longer OMAP specific. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-43-tomi.valkeinen@ti.com
2020-12-15drm/omap: remove legacy DSS device operationsSebastian Reichel1-56/+0
All DSS devices have been converted to bridge API, so the device operations are always NULL. This removes the device ops function pointers and all code using it. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-42-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: Reverse direction of the DSS device enable/disable operationsSebastian Reichel1-20/+8
Complete the direction reversal of the DSS device enable/disable operations started by commit 19b4200d8f4b ("drm/omap: Reverse direction of the DSS device enable/disable operations"). This effectively drops the requirement of calling DSS specific code from the DSI panel driver moving it a bit further to a standard drm_panel driver. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-31-tomi.valkeinen@ti.com
2020-12-15Revert "drm/omap: dss: Remove unused omap_dss_device operations"Sebastian Reichel1-5/+39
This reverts commit e086558ae923 ("drm/omap: dss: Remove unused omap_dss_device operations") This is still needed by DSI. E.g. unloading modules without this will cause a crash. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-2-tomi.valkeinen@ti.com
2020-11-10drm: omapdrm: Replace HTTP links with HTTPS onesAlexander A. Klimov1-1/+1
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713122859.34135-1-grandmaster@al2klimov.de
2020-02-26drm/omap: dss: Remove unused omap_dss_device operationsLaurent Pinchart1-39/+5
The omap_dss_device .pre_enable(), .post_disable() and .set_timings() are not used anymore. Remove them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-55-laurent.pinchart@ideasonboard.com
2020-02-26drm/omap: dss: Remove .set_hdmi_mode() and .set_infoframe() operationsLaurent Pinchart1-26/+0
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations operations are not used anymore, remove them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-37-laurent.pinchart@ideasonboard.com
2020-02-26drm/omap: dss: Make omap_dss_device_ops optionalLaurent Pinchart1-5/+7
As part of the move to drm_bridge ops, the dssdev ops will become empty for some of the internal encoders. Make them optional in the driver to allow them to be removed completely, easing the transition. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-28-laurent.pinchart@ideasonboard.com
2020-02-26drm/omap: Use the drm_panel_bridge APILaurent Pinchart1-13/+0
Replace the manual panel handling code by a drm_panel_bridge. This simplifies the driver and allows all components in the display pipeline to be treated as bridges, paving the way to generic connector handling. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-25-laurent.pinchart@ideasonboard.com
2020-02-26drm/omap: Simplify HDMI mode and infoframe configurationLaurent Pinchart1-3/+1
Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can be accessed directly from the connector's display info. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-23-laurent.pinchart@ideasonboard.com
2019-12-09drm/bridge: Introduce drm_bridge_get_next_bridge()Boris Brezillon1-1/+2
And use it in drivers accessing the bridge->next field directly. This is part of our attempt to make the bridge chain a double-linked list based on the generic list helpers. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-3-boris.brezillon@collabora.com
2019-08-28drm: Stop including drm_bridge.h from drm_crtc.hBoris Brezillon1-0/+1
We are about to add a drm_bridge_state that inherits from drm_private_state which is defined in drm_atomic.h. Problem is, drm_atomic.h includes drm_crtc.h which in turn includes drm_bridge.h, leading to "drm_private_state has incomplete type" error. Let's force all users of the drm_bridge API to explicitly include drm_bridge.h. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190826152649.13820-2-boris.brezillon@collabora.com
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 234Thomas Gleixner1-12/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not see http www gnu org licenses extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 503 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Enrico Weigelt <info@metux.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190602204653.811534538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-18drm/omap: Add support for drm_panelLaurent Pinchart1-13/+28
Hook up drm_panel support in the omapdrm driver. The change is relatively simply as the way has been paved by drm_bridge support already. In addition to looking up, attaching to and detaching from the panel, we only need to add panel support in the connector .get_modes() handler, take connector bus flags (set by the panel) into account, and enable/disable the panel in the encoder enable/disable operations handlers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Add support for drm_bridgeLaurent Pinchart1-27/+42
Hook up drm_bridge support in the omapdrm driver. Despite the recent extensive preparation work, this is a rather intrusive change, as the management of outputs needs to be adapted through the driver to handle both omap_dss_device and drm_bridge. Connector creation is skipped when using a drm_bridge, as the bridge creates the connector internally. This creates issues with systems that split connector operations (such as modes retrieval and hot-plug detection) across different bridges. These systems can't be supported using drm_bridge for now (their support through the omap_dss_device infrastructure is not affected), this will be fixed in subsequent changes. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flagsLaurent Pinchart1-4/+4
The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them through the code. This effectively changes the value of the .sampling_edge bridge timings field in the dumb-vga-dac driver. This is safe to do as no driver consumes these values yet. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Stefan Agner <stefan@agner.ch> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Merge omap_dss_device type and output_type fieldsLaurent Pinchart1-3/+3
The omap_dss_device type and output_type fields differ mostly for historical reasons. The output_type field is required for all devices but the display at the end of the pipeline, and must be set to OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for all devices but the internal encoder, for which it is ignored. The only reason why the output_type field must be set to OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to identify omap_dss_device instances corresponding to displays. This is not documented and confusing. Clean the code by adding a new display field to the omap_dss_device structure to identify displays, and merge the type and output_type fields. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()Laurent Pinchart1-1/+1
The omap_dss_device .check_timings() and .set_timings() operations operate on struct videomode, while the DRM API operates on struct drm_display_mode. This forces conversion from to videomode in the callers. While that's not a problem per se, it creates a difference with the drm_bridge API. Replace the videomode parameter to the .check_timings() and .set_timings() operations with a drm_display_mode. This pushed the conversion to videomode down to the DSS devices in some cases. If needed they will be converted to operate on drm_display_mode natively. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Factor out common mode validation codeLaurent Pinchart1-21/+9
The encoder .atomic_check() and connector .mode_valid() operations both walk through the dss devices in the pipeline to validate the mode. Factor out the common code in a new omap_drm_connector_mode_fixup() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Move DISPC timing checks to CRTC .mode_valid() operationLaurent Pinchart1-6/+0
The DISPC timings checks relate to the CRTC, but they're performed in the encoder and connector .atomic_check() and .mode_valid() operations. Move them to the CRTC .mode_valid() operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Don't pass display pointer to encoder init functionLaurent Pinchart1-4/+1
The display isn't used by the encoder implementation, don't pass it to the initialization function and store it internally needlessly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Reverse direction of the DSS device enable/disable operationsLaurent Pinchart1-11/+38
The omapdrm and omapdss drivers are architectured based on display pipelines made of multiple components handled from sink (display) to source (DSS output). This is incompatible with the DRM bridge and panel APIs that handle components from source to sink. Reconcile the omapdrm and omapdss drivers with the DRM bridge and panel model by reversing the direction of the DSS device .enable() and .disable() operations. This completes the move to the DRM bridge model, with the notable exception of the DSI pipelines that will require more work. We also adapt the omapdss shutdown handler dss_shutdown() to shut down all active pipelines starting from the pipeline output device instead of the display device. As a consequence the for_each_dss_display() macro isn't used and can be removed, and the omapdss_device_get_next() function underlying the macro can be simplified to search for output devices only. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Remove enable checks from display .enable() and .remove()Laurent Pinchart1-6/+0
The displays (connectors, panels and encoders) bail out from their .enable() and .disable() handlers if the dss device is already enabled or disabled. Those safety checks are not needed when the functions are called through the omapdss_device_ops, as the .enable() and .disable() handlers are called from the DRM atomic helpers that already guarantee that no double enabling or disabling can occur. However, the handlers are also called directly from the .remove() handler. While this shouldn't be needed either as the modules can't be removed as long as the device is in use, it's still a good practice to disable the device explicitly. There is currently a safety check in .remove() in some drivers but not all of them. Remove the safety checks from the .enable() and .disable() handlers, and add missing ones in the .remove() handler. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Remove connection checks from display .enable() and .remove()Laurent Pinchart1-12/+5
The displays (connectors, panels and encoders) return an error from their .enable() handler when the dss device is not connected. They also disconnect the dss device explicitly from their .remove() handler if it is still connected. Those safety checks are not needed: - The .enable() handler is called from code paths that access the dss devices chain from the display device, which is set to NULL when the device isn't connected. - The .remove() handler can only be called when unloading the module as the driver has the suppress_bind_attrs attribute set, and a reference to the module is taken when constructing the dss devices chain, so the module can only be unloaded when the dss device is disconnected. Remove the safety checks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Move common display enable/disable code to encoderLaurent Pinchart1-3/+27
All .enable() and .disable() handlers for panels and connectors share common code that validates and updates the device's state. Move it to common locations in the omap_encoder_enable() and omap_encoder_disable() handlers. The enabled check in the .disable() handler is left untouched, it will be addressed separately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-01-24drm: Split out drm_probe_helper.hDaniel Vetter1-1/+1
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically v5: Actually try to sort them, and while at it, sort all the ones I touch. v6: Rebase onto i915 changes. v7: Rebase once more. Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: CK Hu <ck.hu@mediatek.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etnaviv@lists.freedesktop.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-tegra@vger.kernel.org Cc: xen-devel@lists.xen.org Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
2019-01-11Merge drm/drm-next into drm-misc-nextMaxime Ripard1-25/+33
drm-next has been forwarded to 5.0-rc1, and we need it to apply the damage helper for dirtyfb series from Noralf Trønnes. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-01-10drm/edid: Pass connector to AVI infoframe functionsVille Syrjälä1-2/+2
Make life easier for drivers by simply passing the connector to drm_hdmi_avi_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range(). That way drivers don't need to worry about is_hdmi2_sink mess. v2: Make is_hdmi2_sink() return true for sil-sii8620 Adapt to omap/vc4 changes Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Russell King <linux@armlinux.org.uk> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: amd-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-1-ville.syrjala@linux.intel.com
2018-12-03drm/omap: fix incorrect union usageSebastian Reichel1-25/+33
The DSI encoder sets dssdev->ops->dsi.set_config, which is stored at the same offset as dssdev->ops->hdmi.set_hdmi_mode. The code in omap_encoder only checks if dssdev->ops->hdmi.set_hdmi_mode is NULL. Due to the way union works, it won't be NULL if dsi.set_config is set. This means dsi_set_config will be called with config=hdmi_mode=false=NULL parameter resulting in a NULL dereference. Also the dereference happens while console is locked, so kernel hangs without any debug output without "fb.lockless_register_fb=1" parameter. This restructures the code, so that the HDMI mode is only configured for HDMI output types. Fixes: 83910ad3f51fb ("drm/omap: Move most omap_dss_driver operations to omap_dss_device_ops") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Tony Lindgren <tony@atomide.com> [tomi.valkeinen@ti.com: dropped the safeguard] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121160916.22017-5-sebastian.reichel@collabora.com
2018-09-03drm/omap: Don't call .set_timings() operation recursivelyLaurent Pinchart1-12/+8
Instead of calling the .set_timings() operation recursively from the display device backwards, iterate over the devices manually in the DRM encoder code. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Call dispc timings check operation directlyLaurent Pinchart1-5/+13
Instead of call the dispc timings check function dispc_mgr_timings_ok() from the internal encoders .check_timings() operation, expose it through the dispc ops (after renaming it to check_timings) and call it directly from omapdrm. This allows removal of now empty omap_dss_device .check_timings() operations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Split mode fixup and mode set from encoder enableLaurent Pinchart1-69/+79
The encoder enable operation currently performs mode fixup and mode setting for all omap_dss_device instances in the display pipeline. There are dedicated encoder operations for those operations (respectively .atomic_check() and .mode_set()), but they are not used for this purpose. Move the mode fixup code to .atomic_check() and the mode set code .mode_set() to better fit the KMS model. The bus flags fixup has to happen at .mode_set() time as there is no place to store the bus flags in the atomic state structures. This could be solved by extending one of the state structures, but as the goal is to replace the fixup by direct usage of bus flags through the driver, that would be pointless. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Move bus flag hack to encoder implementationLaurent Pinchart1-6/+42
The bus flags stored in omap_dss_device instances are used to fixup the video mode before setting it, to honour constraints that can't be expressed through drm_display_mode. The fixup occurs in the CRTC mode set operation and the resulting video mode is stored internally in the CRTC. It is then used next by omap_encoder_enable() to apply mode fixups for the omap_dss_device instances in omap_encoder_update(). Move the hack to the omap_encoder_update() function right before applying the omap_dss_device fixups, in order to group all fixups together. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Don't call .check_timings() operation recursivelyLaurent Pinchart1-7/+13
The .check_timings() operation is called recursively from the display device back to the output device. Most components just forward the operation to the previous component in the chain, resulting in lots of duplicated pass-through functions. To avoid that, iterate over the components manually. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Remove unneeded fallback for missing .check_timings()Laurent Pinchart1-14/+2
The .check_timings() operation is present in all panels and connectors. The fallback that uses .get_timings() in the absence of .check_timings() is thus unneeded. While it could be argued that the fallback implements a useful check that should be extended to cover all fixed-resolution panels, the code is currently unused and gets in the way of the ongoing refactoring. Remove it, a similar feature can always be added later. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Don't call HDMI mode and infoframe operations recursivelyLaurent Pinchart1-1/+1
The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe()) operations are called recursively from the display device back to the HDMI encoder. This isn't required, as all components other than the HDMI encoder just forward the operation to the previous component in the chain. Call the operations directly on the HDMI encoder. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Pass both output and display omap_dss_device to encoder initLaurent Pinchart1-7/+10
The drm_encoder implementation requires access to the omap_dss_device corresponding to the display, which is passed to its initialization function and stored internally. Clean up of the HDMI mode and infoframe handling will require access to the output omap_dss_device. To prepare for that, pass it to the encoder initialization function and store it internally as well. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Get from CRTC to display device directlyLaurent Pinchart1-7/+0
The CRTC mode set implementation needs to access the omap_dss_device for the pipeline display. To do so, it iterates over all pipelines to find the one that contains an encoder corresponding to the CRTC, and request the display device from the encoder. That's a very complicated dance when the CRTC has a direct pipeline pointer already, and the pipeline contains a pointer to the display device. Replace the convoluted code with direct access. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: Move most omap_dss_driver operations to omap_dss_device_opsLaurent Pinchart1-14/+11
omap_dss_device instances have two ops structures, omap_dss_driver and omap_dss_device_ops. The former is used for devices at the end of the pipeline (a.k.a. display devices), and the latter for intermediate devices. Having two sets of operations isn't convenient as code that iterates over omap_dss_device instances need to take them both into account. There's currently a reasonably small amount of such code, but more will be introduced to move the driver away from recursive operations. To simplify current and future code, move all operations that are not specific to the display device to the omap_dss_device_ops. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-09-03drm/omap: dss: Constify omap_dss_driver operations structureLaurent Pinchart1-3/+3
The structure contains function pointers that don't need to be modified. Make all its instances const to improve security. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2017-12-19drm: omapdrm: Remove filename from header and fix copyright tagAndrew F. Davis1-3/+1
Having the filename in the header serves little purpose and is often wrong after renames as it is here in several places, just drop it from all omapdrm files. While we are here unify the copyright tags to the TI recommended style. Signed-off-by: Andrew F. Davis <afd@ti.com>
2017-07-14drm: handle HDMI 2.0 VICs in AVI info-framesShashank Sharma1-1/+2
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. This patch touches all drm drivers, who are callers of this function drm_hdmi_avi_infoframe_from_display_mode but to make sure there is no change in current behavior, is_hdmi2 is kept as false. In case of I915 driver, this patch: - checks if the connected display is HDMI 2.0. - HDMI infoframes carry one of this two type of information: - VIC for 4K modes for HDMI 1.4 sinks - S3D information for S3D modes As CEA-861-F has already defined VICs for 4K videomodes, this patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks, until the mode is 3D. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Vetter <daniel.vetter@intel.com> PS: This patch touches a few lines in few files, which were already above 80 char, so checkpatch gives 80 char warning again. - gpu/drm/omapdrm/omap_encoder.c - gpu/drm/i915/intel_sdvo.c V2: Rebase, Added r-b from Andrzej V3: Addressed review comment from Ville: - Do not send VICs in both AVI-IF and HDMI-IF send only one of it. V4: Rebase V5: Added r-b from Neil. Addressed review comments from Ville - Do not block HDMI vendor IF, instead check for VIC while handling AVI infoframes V6: Rebase V7: Rebase Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-12-19drm: omapdrm: Use sizeof(*var) instead of sizeof(type) for structuresLaurent Pinchart1-1/+1
By linking the sizeof to a variable type the code will be less prone to bugs due to future type changes of variables. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-11-02drm/omap: Use consistent name for struct videomodePeter Ujfalusi1-4/+4
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or something else. The code will be easier to follow if we use consistent names. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-11-02drm/omap: Replace struct omap_video_timings with videomodePeter Ujfalusi1-3/+3
omap_video_timings can be replaced with the generic videomode in omapdrm and the omap_video_timings can be removed. This patch will replace the omap_video_timings with videomode. With the change we no longer need the functions to convert to/from videomode and drm_display_mode to omap_video_timings, these can be removed as well. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-03-03drm/omap: print an error if display enable failsTomi Valkeinen1-1/+6
If the panel's enable fails, omap_encoder silently ignores the failure. omapdrm should really handle the failure, but unfortunately the whole encoder enable codepath is expected to always succeed. So for now, catch the enable failure and print an error. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-12-31drm/omap: remove obsolete manager assignmentTomi Valkeinen1-2/+0
omap_encoder_update() assigns an overlay manager to dssdev->src->manager. This assignment is not needed, as the connections in the display chain have already been made at connect step. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-12-11drm: Pass 'name' to drm_encoder_init()Ville Syrjälä1-1/+1
Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. @@ identifier dev, encoder, funcs; @@ int drm_encoder_init(struct drm_device *dev, struct drm_encoder *encoder, const struct drm_encoder_funcs *funcs, int encoder_type + ,const char *name, int DOTDOTDOT ) { ... } @@ identifier dev, encoder, funcs; @@ int drm_encoder_init(struct drm_device *dev, struct drm_encoder *encoder, const struct drm_encoder_funcs *funcs, int encoder_type + ,const char *name, int DOTDOTDOT ); @@ expression E1, E2, E3, E4; @@ drm_encoder_init(E1, E2, E3, E4 + ,NULL ) v2: Add ', or NULL...' to @name kernel doc (Jani) Annotate the function with __printf() attribute (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449670818-2966-1-git-send-email-ville.syrjala@linux.intel.com
2015-06-12drm: omapdrm: Move encoder setup to encoder operationsLaurent Pinchart1-48/+31
Now that the driver is fully converted to atomic operations, and that the atomic helpers call the operations in the right order, we can move encoder setup to where it belongs, in the encoder operations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-28 19:28:53 +0000