Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28 |
|
#
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 ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7 |
|
#
d6c75c29 |
| 05-Dec-2021 |
Arnd Bergmann <arnd@arndb.de> |
omapdrm: dss: mark runtime PM functions __maybe_unused
Using the SET_RUNTIME_PM_OPS() macro causes a warning about the referenced functions when they are marked static but not __maybe_unused:
drive
omapdrm: dss: mark runtime PM functions __maybe_unused
Using the SET_RUNTIME_PM_OPS() macro causes a warning about the referenced functions when they are marked static but not __maybe_unused:
drivers/gpu/drm/omapdrm/dss/dss.c:1572:12: error: unused function 'dss_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dss.c:1584:12: error: unused function 'dss_runtime_resume' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4845:12: error: unused function 'dispc_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4860:12: error: unused function 'dispc_runtime_resume' [-Werror,-Wunused-function]
Fixes: b92f7ea556f8 ("drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211205131612.3192652-1-arnd@kernel.org
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62 |
|
#
ed8414ab |
| 31-Aug-2021 |
Cai Huoqing <caihuoqing@baidu.com> |
drm/omap: Make use of the helper function devm_platform_ioremap_resourcexxx()
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_iorema
drm/omap: Make use of the helper function devm_platform_ioremap_resourcexxx()
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210831135707.4676-1-caihuoqing@baidu.com
show more ...
|
Revision tags: v5.14 |
|
#
b92f7ea5 |
| 28-Aug-2021 |
Cai Huoqing <caihuoqing@baidu.com> |
drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIM
drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little clearer, a little more concise.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210828084811.104-1-caihuoqing@baidu.com
show more ...
|
Revision tags: v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
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 ...
|
#
27e1d068 |
| 15-Dec-2020 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
drm/omap: drop DSS ops_flags
The omapdss device's ops_flags field is no longer used and can be dropped.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkei
drm/omap: drop DSS ops_flags
The omapdss device's ops_flags field is no longer used 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-46-tomi.valkeinen@ti.com
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
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 ...
|
#
df561f66 |
| 23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through mar
treewide: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case.
[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
show more ...
|
Revision tags: v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57 |
|
#
227c6d10 |
| 05-Aug-2020 |
Colin Ian King <colin.king@canonical.com> |
drm/omap: fix spelling mistake "propert" -> "property"
There is a spelling mistake in a pr_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Tomi Valkeine
drm/omap: fix spelling mistake "propert" -> "property"
There is a spelling mistake in a pr_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200805102015.14891-1-colin.king@canonical.com
show more ...
|
Revision tags: v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4 |
|
#
ecfdedd7 |
| 18-Jun-2020 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
drm/omap: force runtime PM suspend on system suspend
Use SET_LATE_SYSTEM_SLEEP_PM_OPS in DSS submodules to force runtime PM suspend and resume.
We use suspend late version so that omapdrm's system
drm/omap: force runtime PM suspend on system suspend
Use SET_LATE_SYSTEM_SLEEP_PM_OPS in DSS submodules to force runtime PM suspend and resume.
We use suspend late version so that omapdrm's system suspend callback is called first, as that will disable all the display outputs after which it's safe to force DSS into suspend.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200618095153.611071-1-tomi.valkeinen@ti.com Acked-by: Tony Lindgren <tony@atomide.com> Fixes: cef766300353 ("drm/omap: Prepare DSS for probing without legacy platform data") Cc: stable@vger.kernel.org # v5.7+ Tested-by: Tony Lindgren <tony@atomide.com>
show more ...
|
Revision tags: v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
12c683e1 |
| 25-May-2020 |
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> |
drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()
When validating a mode, bridges may need to do so in the context of a display, as specified by drm_display_info. An example is th
drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()
When validating a mode, bridges may need to do so in the context of a display, as specified by drm_display_info. An example is the meson dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to perform clock calculations.
Bridges that need the display info currently retrieve it from the drm_connector created by the bridge. This gets in the way of moving connector creation out of bridge drivers. To make this possible, pass the drm_display_info to drm_bridge_funcs .mode_valid().
Changes to the bridge drivers have been performed with the following coccinelle semantic patch and have been compile-tested.
@ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .mode_valid = fn };
@ depends on rule1 @ identifier rule1.fn; identifier bridge; identifier mode; @@ enum drm_mode_status fn( struct drm_bridge *bridge, + const struct drm_display_info *info, const struct drm_display_mode *mode ) { ... }
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Guido Günther <agx@sigxcpu.org> # for the nwl-dsi part: Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200526011505.31884-11-laurent.pinchart+renesas@ideasonboard.com
show more ...
|
Revision tags: v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33 |
|
#
44dd0eef |
| 15-Apr-2020 |
YueHaibing <yuehaibing@huawei.com> |
drm/omap: venc: remove unused variable 'venc_config_pal_bdghi'
drivers/gpu/drm/omapdrm/dss/venc.c:211:33: warning: 'venc_config_pal_bdghi' defined but not used [-Wunused-const-variable=] static co
drm/omap: venc: remove unused variable 'venc_config_pal_bdghi'
drivers/gpu/drm/omapdrm/dss/venc.c:211:33: warning: 'venc_config_pal_bdghi' defined but not used [-Wunused-const-variable=] static const struct venc_config venc_config_pal_bdghi = { ^~~~~~~~~~~~~~~~~~~~~
It is never used, remove it.
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415132105.43636-1-yuehaibing@huawei.com
show more ...
|
Revision tags: v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23 |
|
#
96b0a34d |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: venc: Remove omap_dss_device operations
Now that the VENC output is driven fully through the drm_bridge API its omap_dss_device operations are not used anymore. Remove them.
Signed-off-by
drm/omap: venc: Remove omap_dss_device operations
Now that the VENC output is driven fully through the drm_bridge API its 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-43-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 ...
|
#
2f004792 |
| 26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: venc: Register a drm_bridge
In order to integrate with a chain of drm_bridge, the internal VENC encoder has to expose the mode valid, fixup and set, the enable and disable and the get mode
drm/omap: venc: Register a drm_bridge
In order to integrate with a chain of drm_bridge, the internal VENC encoder has to expose the mode valid, fixup and set, the enable and disable and the get modes operations through the drm_bridge API. Register a bridge at initialisation time to do so.
Most of those operations are removed from the omap_dss_device as they are now called through the drm_bridge API by the DRM atomic helpers. The only exception is the .get_modes() operation that is still invoked through the omap_dss_device-based pipeline.
For the time being make the next bridge in the chain optional as the VENC 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-38-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 ...
|
Revision tags: v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7 |
|
#
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 ...
|
Revision tags: v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9 |
|
#
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 ...
|
Revision tags: v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10 |
|
#
b08644a2 |
| 21-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: venc: Use drm_display_mode natively
Replace internal usage of struct videomode with struct drm_display_mode in order to avoid converting needlessly between the data structures.
Signed-off
drm/omap: venc: Use drm_display_mode natively
Replace internal usage of struct videomode with struct drm_display_mode in order to avoid converting needlessly between the data structures.
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 ...
|
#
d60dfaba |
| 19-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: venc: Simplify mode setting by caching configuration
The mode setting handler of the VENC stores the video mode internally, to then convert it to a configuration when programming the hardw
drm/omap: venc: Simplify mode setting by caching configuration
The mode setting handler of the VENC stores the video mode internally, to then convert it to a configuration when programming the hardware. The stored mode is otherwise unused. Cache the configuration directly instead.
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 ...
|
Revision tags: v4.18.9 |
|
#
40e5f937 |
| 12-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: venc: List both PAL and NTSC modes
The TV encoder supports both PAL and NTSC modes, but when queried for the list of modes it supports, only the currently selected mode is reported. Fix it
drm/omap: venc: List both PAL and NTSC modes
The TV encoder supports both PAL and NTSC modes, but when queried for the list of modes it supports, only the currently selected mode is reported. Fix it and report the two modes unconditionally.
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 ...
|
#
46b3847d |
| 12-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Add a dss device operation flag for .get_modes()
Instead of manually iterating over the dss devices in the pipeline to find the first one that implements the .get_modes() operation, add a
drm/omap: Add a dss device operation flag for .get_modes()
Instead of manually iterating over the dss devices in the pipeline to find the first one that implements the .get_modes() operation, add a new operation flag for .get_modes() and use the omap_connector_find_device() helper function to locate the right dss device.
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 ...
|
#
870e19d5 |
| 12-Sep-2018 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/omap: Expose DRM modes instead of timings in display devices
omap_dss_device operations expose fixed video timings through a .get_timings() operation that return a single timing for the device.
drm/omap: Expose DRM modes instead of timings in display devices
omap_dss_device operations expose fixed video timings through a .get_timings() operation that return a single timing for the device. To prepare for the move to drm_bridge, modify the API to instead add DRM modes directly to the connector.
As this puts more burden on display devices, we also create a helper function for panels to add a single DRM mode from the panel video timings.
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 ...
|