#
46876af3 |
| 23-Jan-2024 |
Jani Nikula <jani.nikula@intel.com> |
drm/omap/hdmi5: switch to ->edid_read callback
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Neil Armstrong <neil.ar
drm/omap/hdmi5: switch to ->edid_read callback
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/da96653c111a7f989c7c804923968fa5f47c6b5a.1706038510.git.jani.nikula@intel.com
show more ...
|
#
c2807ecb |
| 07-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
drm/omap: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error hand
drm/omap: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert the omap drm driver from always returning zero in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230507162616.1368908-35-u.kleine-koenig@pengutronix.de
show more ...
|
#
255490f9 |
| 14-Jun-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Drop drm_edid.h from drm_crtc.h
drm_crtc.h has no need for drm_edid.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_edid.h.
Quite a few placs do curren
drm: Drop drm_edid.h from drm_crtc.h
drm_crtc.h has no need for drm_edid.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_edid.h.
Quite a few placs do currently depend on drm_edid.h without actually including it directly. All of those need to be fixed up.
v2: Fix up i915 and msm some more v3: Fix alphabetical ordering (Sam)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220614090245.30283-1-ville.syrjala@linux.intel.com Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Jani Nikula <jani.nikula@intel.com>
show more ...
|
#
96f44185 |
| 15-Dec-2020 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
drm/omap: drop unused owner field
dssdev->owner is set, but never used. We can drop the field.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@
drm/omap: drop unused owner field
dssdev->owner is set, but never used. We can drop the field.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-53-tomi.valkeinen@ti.com
show more ...
|
#
a5d704d3 |
| 22-Aug-2020 |
Dinghao Liu <dinghao.liu@zju.edu.cn> |
drm/omap: Fix runtime PM imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. However, users of its direct wrappers in omapdrm assume
drm/omap: Fix runtime PM imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. However, users of its direct wrappers in omapdrm assume that PM usage counter will not change on error. Thus a pairing decrement is needed on the error handling path for these wrappers to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200822065743.13671-1-dinghao.liu@zju.edu.cn
show more ...
|
#
1b409fda |
| 13-Jul-2020 |
Alexander A. Klimov <grandmaster@al2klimov.de> |
drm: omapdrm: Replace HTTP links with HTTPS ones
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
drm: omapdrm: Replace HTTP links with HTTPS ones
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
show more ...
|
#
35201cc1 |
| 26-Jun-2020 |
Linus Walleij <linus.walleij@linaro.org> |
drm: omapdrm: Delete surplus GPIO includes
The OMAP DRM driver includes <linux/gpio.h> into the two hdmi4.c and hdmi5.c files but does not use any symbols from these files. Drop the includes.
Cc: T
drm: omapdrm: Delete surplus GPIO includes
The OMAP DRM driver includes <linux/gpio.h> into the two hdmi4.c and hdmi5.c files but does not use any symbols from these files. Drop the includes.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Jyri Sarha <jsarha@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626220606.340937-1-linus.walleij@linaro.org
show more ...
|
#
b6067da4 |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: hdmi5: Simplify EDID read
Now that the omap_dss_device EDID read operation has been removed, simplify the bridge-based EDID access by merging multiple functions together.
Signed-off-by: L
drm/omap: hdmi5: Simplify EDID read
Now that the omap_dss_device EDID read operation has been removed, simplify the bridge-based EDID access by merging multiple functions together.
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-45-laurent.pinchart@ideasonboard.com
show more ...
|
#
a559b440 |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: hdmi: Remove omap_dss_device operations
Now that the HDMI outputs are driven fully through the drm_bridge API their omap_dss_device operations are not used anymore. Remove them.
Signed-of
drm/omap: hdmi: Remove omap_dss_device operations
Now that the HDMI outputs are driven fully through the drm_bridge API their omap_dss_device 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-42-laurent.pinchart@ideasonboard.com
show more ...
|
#
75fb968b |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Remove HPD, detect and EDID omapdss operations
Due to the removal of several omapdrm display drivers, the omapdss HPD, detected and EDID operations are not used anymore. Remove them and al
drm/omap: Remove HPD, detect and EDID omapdss operations
Due to the removal of several omapdrm display drivers, the omapdss HPD, detected and EDID operations are not used anymore. Remove them and all related code.
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-41-laurent.pinchart@ideasonboard.com
show more ...
|
#
e7e67d9a |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Switch the HDMI and VENC outputs to drm_bridge
The TPD12S015, OPA362 and analog and HDMI connectors are now supported by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be ha
drm/omap: Switch the HDMI and VENC outputs to drm_bridge
The TPD12S015, OPA362 and analog and HDMI connectors are now supported by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be handled through the drm_bridge API. Switch the outputs to drm_bridge by making the next bridge mandatory and removing the related omapdrm-specific display drivers.
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-40-laurent.pinchart@ideasonboard.com
show more ...
|
#
615de6ce |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: hdmi5: Move mode set, enable and disable operations to bridge
Move the omap_dss_device .set_timings(), .enable() and .disable() operations to the drm_bridge functions. As the drm_bridge fo
drm/omap: hdmi5: Move mode set, enable and disable operations to bridge
Move the omap_dss_device .set_timings(), .enable() and .disable() operations to the drm_bridge functions. As the drm_bridge for the HDMI encoder is unconditionally registered and attached, those operations will be called at the appropriate time.
The omapdss device .set_infoframe() and .set_hdmi_mode() operations have no equivalent in drm_bridge. Thir content is thus moved to the bridge .enable() operation as the data they store is not needed before the HDMI encoder gets enabled.
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-35-laurent.pinchart@ideasonboard.com
show more ...
|
#
6c623d6b |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: hdmi5: Register a drm_bridge for EDID read
In order to integrate with a chain of drm_bridge, the internal HDMI5 encoder has to expose the EDID read operation through the drm_bridge API. Re
drm/omap: hdmi5: Register a drm_bridge for EDID read
In order to integrate with a chain of drm_bridge, the internal HDMI5 encoder has to expose the EDID read operation through the drm_bridge API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the HDMI output is still based on omap_dss_device. The create_connector argument to the bridge attach function is also ignored for the same reason. This will be changed later when removing the related omapdrm-specific display drivers.
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-33-laurent.pinchart@ideasonboard.com
show more ...
|
#
1edc1a1c |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: hdmi5: Rework EDID read to isolate data read
In preparation of adding DRM bridge support to the hdmi5 encoder code, rework the EDID read to isolate data read.
The hdmi_read_edid() functio
drm/omap: hdmi5: Rework EDID read to isolate data read
In preparation of adding DRM bridge support to the hdmi5 encoder code, rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all initialisation steps required prior to reading the EDID (such as ensuring the device is powered on), as well as corresponding cleanup steps afterwards. EDID read itself is handled by hdmi_read_edid_data() that calls the hdmi5_core_ddc_read() function to read individual blocks.
This new code architecture will allow reusing hdmi_read_edid() and hdmi5_core_ddc_read() for the drm_bridge EDID read implementation, while swapping out hdmi_read_edid_data() for the DRM drm_do_get_edid() function.
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-31-laurent.pinchart@ideasonboard.com
show more ...
|
#
0fe37173 |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: hdmi: Allocate EDID in the .read_edid() operation
Bring the omapdss-specific .read_edid() operation in sync with the drm_bridge .get_edid() operation to ease code reuse.
Signed-off-by: La
drm/omap: hdmi: Allocate EDID in the .read_edid() operation
Bring the omapdss-specific .read_edid() operation in sync with the drm_bridge .get_edid() operation to ease code reuse.
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-29-laurent.pinchart@ideasonboard.com
show more ...
|
#
326a1166 |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Add infrastructure to support drm_bridge local to DSS outputs
In order to support drm_bridge-based pipeline, the internal HDMI encoders will need to expose the EDID read operation through
drm/omap: Add infrastructure to support drm_bridge local to DSS outputs
In order to support drm_bridge-based pipeline, the internal HDMI encoders will need to expose the EDID read operation through the drm_bridge API, and thus to expose a drm_bridge instance corresponding to the encoder. The HDMI encoders are however handled as omap_dss_device instances, which conflicts with this requirement.
In order to move forward with the drm_bridge transition, add support for creating drm_bridge instances local to DSS outputs. If a local bridge is passed to the omapdss_device_init_output() function, it is used as the first bridge in the chain, and the omap_dss_device.next_bridge field is set to the next bridge for the use of the internal encoders' bridges.
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-27-laurent.pinchart@ideasonboard.com
show more ...
|
#
c83fefd7 |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: dss: Fix output next device lookup in DT
The DSS core looks up the next device connected to an output by traversing the OF graph. It currently hardcodes the local port number to 0, which b
drm/omap: dss: Fix output next device lookup in DT
The DSS core looks up the next device connected to an output by traversing the OF graph. It currently hardcodes the local port number to 0, which breaks any output with a different port number (SDI on OMAP3 and any DPI output but the first one). Fix this by repurposing the currently unused of_ports bitmask in omap_dss_device with an of_port output port number, and use it to traverse the OF graph.
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-26-laurent.pinchart@ideasonboard.com
show more ...
|
#
caab277b |
| 03-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 234
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 234
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>
show more ...
|
#
0dbfc396 |
| 10-Dec-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Merge omap_dss_device type and output_type fields
The omap_dss_device type and output_type fields differ mostly for historical reasons. The output_type field is required for all devices bu
drm/omap: Merge omap_dss_device type and output_type fields
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>
show more ...
|
#
41322aa6 |
| 21-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()
The omap_dss_device .check_timings() and .set_timings() operations operate on struct videomode, while the DRM API operates on s
drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()
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>
show more ...
|
#
d17eb453 |
| 12-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Factor out common init/cleanup code for output devices
All the internal encoders share common init and cleanup code. Factor it out to separate functions.
Signed-off-by: Laurent Pinchart <
drm/omap: Factor out common init/cleanup code for output devices
All the internal encoders share common init and cleanup code. Factor it out to separate functions.
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>
show more ...
|
#
19b4200d |
| 24-Aug-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Reverse direction of the DSS device enable/disable operations
The omapdrm and omapdss drivers are architectured based on display pipelines made of multiple components handled from sink (di
drm/omap: Reverse direction of the DSS device enable/disable operations
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>
show more ...
|
#
f8a8eabb |
| 04-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Remove connection checks from internal encoders .enable()
The internal encoders return an error from their .enable() handler when their are not connected to a dss manager. As the flag used
drm/omap: Remove connection checks from internal encoders .enable()
The internal encoders return an error from their .enable() handler when their are not connected to a dss manager. As the flag used is set and cleared in the connect and disconnect handlers, this effectively checks whether the omap_dss_device is connected.
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, making it impossible to access the device in that case.
The safety check is thus not needed, remove it.
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>
show more ...
|
#
24ec84e8 |
| 10-Nov-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Move DISPC runtime PM handling to omapdrm
The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers attempt to manage the runtime PM state of the connected DISPC, based on the
drm/omap: Move DISPC runtime PM handling to omapdrm
The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers attempt to manage the runtime PM state of the connected DISPC, based on the rationale that the DISPC providing data to the encoders requires ensuring that the display is active whenever the encoders are active.
While the DISPC provides data to the encoders, it doesn't as such constitute a resource that encoders require in order to be taken out of suspend, contrary to for instance a functional clock or a power supply. Encoders registers can be accessed without the DISPC being active, and while the encoders will not output any video stream without being fed by the DISPC, the DISPC PM state doesn't influence the encoders PM state.
For this reason the DISPC PM state is better managed from the omapdrm driver, in the CRTC enable and disable operations. This allows the encoders PM state to be handled separately from the DISPC, and in particular at times when the DISPC may not be available (for instance at probe due to the DSS probe being deferred, or at remove time du to the DISPC being already removed).
Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind to probe") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.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/20181110111654.4387-5-laurent.pinchart@ideasonboard.com
show more ...
|
#
6ea48430 |
| 07-Jun-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Don't call .set_timings() operation recursively
Instead of calling the .set_timings() operation recursively from the display device backwards, iterate over the devices manually in the DRM
drm/omap: Don't call .set_timings() operation recursively
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>
show more ...
|