Ramalingam C [Wed, 12 Feb 2020 10:29:38 +0000 (15:59 +0530)]
drm/hdcp: optimizing the srm handling
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
v3:
ptr passing around is fixed with functional testing.
v4:
fix htmldoc [lkp]
video: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
yu kuai [Mon, 20 Jan 2020 06:33:27 +0000 (14:33 +0800)]
video: fbdev: atyfb: remove set but not used variable 'mach64RefFreq'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/mach64_gx.c: In function ‘aty_var_to_pll_8398’:
drivers/video/fbdev/aty/mach64_gx.c:621:36: warning: variable
‘mach64RefFreq’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:19:45 +0000 (20:19 +0800)]
video: fbdev: kyrofb: remove set but not used variable 'ulScaleRight'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/kyro/STG4000OverlayDevice.c: In function
‘SetOverlayViewPort’:
drivers/video/fbdev/kyro/STG4000OverlayDevice.c:334:19: warning:
variable ‘ulScaleRight’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:30 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable 'bytpp'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1660:32: warning:
variable ‘bytpp’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:29 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable '‘cSync’'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:48: warning: variable
‘cSync’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:28 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable 'vSyncPol'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:38: warning: variable
‘vSyncPol’ set but not used [-Wunused-but-set-variable]
yu kuai [Sun, 19 Jan 2020 12:17:27 +0000 (20:17 +0800)]
video: fbdev: radeonfb: remove set but not used variable 'hSyncPol'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:6: warning: variable
‘hSyncPol’ set but not used [-Wunused-but-set-variable]
* Add missing __iomem annotations where needed.
* Make w100fb_probe() static.
* Return NULL pointer (instead of using plain integer) in
w100_get_xtal_tabl().
This patch makes the internal encoder implementation of the simple
KMS helpers available to drivers.
These simple-encoder helpers initialize an encoder with an empty
implementation. This covers the requirements of most of the existing
DRM drivers. A call to drm_simple_encoder_create() allocates and
initializes an encoder instance, a call to drm_simple_encoder_init()
initializes a pre-allocated instance.
v3:
* remove drm_simple_encoder_create(); not required yet
* provide more precise documentation
v2:
* move simple encoder to KMS helpers
* remove name argument; simplifies implementation
* don't allocate with devm_ interfaces; unsafe with DRM
Sam Ravnborg [Sun, 16 Feb 2020 18:15:13 +0000 (19:15 +0100)]
drm/panel: simple: add panel-dpi support
The panel-dpi compatible is a fallback that
allows the DT to specify the timing.
When matching panel-dpi expect the device tree to include the
timing information for the display-panel.
Background for this change:
There are a lot of panels and new models hits the market very often.
It is a lost cause trying to chase them all and users of new panels
will often find them in situations that the panel they ues are not
supported by the kernel.
On top of this a lot of panels are customized based on customer
specifications.
Including the panel timing in the device tree allows for a simple
way to describe the actual HW and use this description in a generic
way in the kernel.
This allows uses of proprietary panels, or panels which are not
included in the kernel, to specify the timing in the device tree
together with all the other HW descriptions.
And thus, using the device tree it is then easy to add support
for an otherwise unknown panel.
The current support expect panels that do not require any
delays for prepare/enable/disable/unprepare.
Oleksandr Suvorov replied:
I've just tested this patch on Apalis iMX6Q and Colibri iMX7D using
panel settings from the following patch:
https://lore.kernel.org/linux-arm-kernel/20200115123401.2264293-4-oleksandr.suvorov@toradex.com/
Sam Ravnborg [Sun, 16 Feb 2020 18:15:12 +0000 (19:15 +0100)]
dt-bindings: display: add data-mapping to panel-dpi
Add data-mapping property that can be used to specify
the media format used for the connection betwwen the
display controller (connector) and the panel.
Sam Ravnborg [Sun, 16 Feb 2020 18:15:11 +0000 (19:15 +0100)]
dt-bindings: display: convert panel-dpi to DT schema
With panel-timing converted, now convert the single
remaining .txt user in panel/ of panel-timing to DT schema.
v2:
- Drop Thierry as maintainer, as this is not a general panel binding
and I have no acks.
- Drop requirement for a panel- specific binding - "panel-dpi" is enough
- Updated example
v3:
- added yaml document terminator "..."
- always require a specific binding - panel-dpi (based on feedback from Rob)
- use "power-supply" for the supply property, and made it mandatory
"power-supply" is the standard property for panels
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-4-sam@ravnborg.org
Sam Ravnborg [Sun, 16 Feb 2020 18:15:10 +0000 (19:15 +0100)]
dt-bindings: display: convert display-timings to DT schema
Add display-timings.yaml - that references panel-timings.yaml.
display-timings.yaml will be used for display bindings
when they are converted to meta-schema format.
For now the old display-timing.txt points to the new
display-timings.yaml - and all users are left as-is.
v2:
- Updated native-mode description
v3:
- Simpler "^timing" pattern (Rob)
- timing node is of type object (Rob)
- added display-timings to panel-common.yaml
- added yaml document terminator "..."
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Cc: devicetree@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-3-sam@ravnborg.org
Sam Ravnborg [Sun, 16 Feb 2020 18:15:09 +0000 (19:15 +0100)]
dt-bindings: display: add panel-timing.yaml
Add meta-schema variant of panel-timing and
reference it from panel-common.yaml.
Part of this came form other files with other
licenses - original commits:
commit cc3f414cf2e4 ("video: add of helper for display timings/videomode")
commit 86f46565dff3 ("dt-bindings: display: display-timing: Add property to configure sync drive edge")
commit 9cad9c95d7e8 ("Documentation: DocBook DRM framework documentation")
The original authors acked the license change to:
(GPL-2.0-only OR BSD-2-Clause)
v2:
- Got OK from original authors for re-license
Huge thanks for the quick replies!
- Typo fixes (Oleksandr)
- Drop -array variant when not needed (Maxime)
- Replace oneOf:... with enum (Maxime)
- Drop type from clock-frequency (Rob)
- Drop "|" when not needed (Rob)
v3:
- Added comment to acks that are only for the license change
- Add yaml document terminator "..."
- Updated description (removed reference to native-mode)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [license change] Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> [license change] Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> [license change] Acked-by: Philipp Zabel <p.zabel@pengutronix.de> [license change] Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: devicetree@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-2-sam@ravnborg.org
Linus Walleij [Sun, 23 Feb 2020 12:18:41 +0000 (13:18 +0100)]
drm/panel: Add driver for Novatek NT35510-based panels
This adds a driver for panels based on the Novatek NT35510
display driver IC, such as the Hydis HVA40WV1 panel found
in the Samsung GT-S7710.
The NT35510 can be used with both internal and external
backlight (such as GPIO backlight) so we support both:
if no external backlight is found, we register a subdriver
for the internal backlight.
Linus Walleij [Sun, 23 Feb 2020 12:18:40 +0000 (13:18 +0100)]
drm/panel: Add DT bindings for Novatek NT35510-based panels
This adds device tree bindings for the Novatek NT35510-based
family of panels. Since several such panels are in existence
we define bindings common for all, and define the compatible
string for one certain panel (Hydis HVA40WV1).
As other panels are discovered and investigated, we can add
more compatibles to the binding using oneOf constructions.
Emmanuel Vadot [Sat, 15 Feb 2020 18:09:10 +0000 (19:09 +0100)]
drm/client: Dual licence the file in GPL-2 and MIT
Contributors for this file are :
Chris Wilson <chris@chris-wilson.co.uk>
Denis Efremov <efremov@linux.com>
Jani Nikula <jani.nikula@intel.com>
Maxime Ripard <mripard@kernel.org>
Noralf Trønnes <noralf@tronnes.org>
Sam Ravnborg <sam@ravnborg.org>
Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Denis Efremov <efremov@linux.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200215180911.18299-2-manu@FreeBSD.org
The old implementation of placing planes on the CRTC while configuring
the planes was naive and relied on the order in which the planes were
configured, enabled, and disabled. The situation where a plane's zpos
was changed on the fly was completely broken. The usual symptoms of
this problem was scrambled display and a flood of sync lost errors,
when a plane was active in two layers at the same time, or a missing
plane, in case when a layer was accidentally disabled.
The rewrite takes a more straight forward approach when HW is
concerned. The plane positioning registers are in the CRTC (or
actually OVR) register space and it is more natural to configure them
in a one go when configuring the CRTC. To do this we need make sure we
have all the planes on the updated CRTCs in the new atomic state. The
untouched planes on CRTCs that need plane position update are added to
the atomic state in tidss_atomic_check().
Christian König [Wed, 19 Feb 2020 12:32:43 +0000 (13:32 +0100)]
dma-buf: make move_notify mandatory if importer_ops are provided
This makes the move_notify callback mandatory when the importer_ops are
provided. Since amdgpu is now migrated it doesn't make much sense
anymore to allow this.
Christian König [Tue, 3 Jul 2018 14:42:26 +0000 (16:42 +0200)]
dma-buf: add dynamic DMA-buf handling v15
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify
v13: add might_lock in appropriate places
v14: rebase on separated locking change
v15: add EXPERIMENTAL flag, some more code comments
Gurchetan Singh [Thu, 27 Feb 2020 00:25:55 +0000 (16:25 -0800)]
drm/virtio: add virtio_gpu_is_shmem helper
The plan is use have both shmem and virtual "vram" running
side-by-side in virtio-gpu. It looks like we'll eventually use
struct drm_gem_object as a base class, and we'll need to convert
to shmem and vram objects on the fly. As a first step, add a
virtio_gpu_is_shmem helper. Thanks to kraxel for suggesting this
approach on Gitlab.
Laurent Pinchart [Wed, 26 Feb 2020 11:25:10 +0000 (13:25 +0200)]
drm/omap: sdi: Register a drm_bridge
In order to integrate with a chain of drm_bridge, the internal SDI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Laurent Pinchart [Wed, 26 Feb 2020 11:25:08 +0000 (13:25 +0200)]
drm/omap: dpi: Register a drm_bridge
In order to integrate with a chain of drm_bridge, the internal DPI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Laurent Pinchart [Wed, 26 Feb 2020 11:25:07 +0000 (13:25 +0200)]
drm/omap: dpi: Simplify clock setting API
The dpi_set_pll_clk() and dpi_set_dispc_clk() return various information
through pointer arguments that are never used by the callers. Remove
them to simplify the clock setting API.
Laurent Pinchart [Wed, 26 Feb 2020 11:25:00 +0000 (13:25 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:59 +0000 (13:24 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:58 +0000 (13:24 +0200)]
drm/omap: Create connector for bridges
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:57 +0000 (13:24 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:54 +0000 (13:24 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:53 +0000 (13:24 +0200)]
drm/omap: hdmi4: 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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:52 +0000 (13:24 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:51 +0000 (13:24 +0200)]
drm/omap: hdmi4: Register a drm_bridge for EDID read
In order to integrate with a chain of drm_bridge, the internal HDMI4
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:50 +0000 (13:24 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:49 +0000 (13:24 +0200)]
drm/omap: hdmi4: Rework EDID read to isolate data read
In preparation of adding DRM bridge support to the hdmi4 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 hdmi4_core_ddc_read() function to read individual blocks.
This new code architecture will allow reusing hdmi_read_edid() and
hdmi4_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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:47 +0000 (13:24 +0200)]
drm/omap: dss: Make omap_dss_device_ops optional
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:46 +0000 (13:24 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:45 +0000 (13:24 +0200)]
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:44 +0000 (13:24 +0200)]
drm/omap: Use the drm_panel_bridge API
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.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:43 +0000 (13:24 +0200)]
drm/omap: Factor out display type to connector type conversion
Move the code that computes the DRM connector type for the
omapdss_device display type to a new omapdss_device_connector_type()
function for later reuse.
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-24-laurent.pinchart@ideasonboard.com
Laurent Pinchart [Wed, 26 Feb 2020 11:24:41 +0000 (13:24 +0200)]
drm/omap: dss: Cleanup DSS ports on initialisation failure
When the DSS initialises its output DPI and SDI ports, failures don't
clean up previous successfully initialised ports. This can lead to
resource leak or memory corruption. Fix it.
Reported-by: Hans Verkuil <hverkuil@xs4all.nl> 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-22-laurent.pinchart@ideasonboard.com
Laurent Pinchart [Wed, 26 Feb 2020 11:24:40 +0000 (13:24 +0200)]
drm: Add helper to create a connector for a chain of bridges
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple components. For instance a
pipeline with a bridge connected to the DDC signals to read EDID data,
and another one connected to the HPD signal to detect connection and
disconnection, will not be possible to support through this model.
- It requires every bridge driver to implement similar connector
handling code, resulting in code duplication.
- It assumes that a bridge will either be wired to a connector or to
another bridge, but doesn't support bridges that can be used in both
positions very well (although there is some ad-hoc support for this in
the analogix_dp bridge driver).
In order to solve these issues, ownership of the connector needs to be
moved to the display controller driver.
To avoid code duplication in display controller drivers, add a new
helper to create and manage a DRM connector backed by a chain of
bridges. All connector operations are delegating to the appropriate
bridge in the chain.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.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-21-laurent.pinchart@ideasonboard.com
Laurent Pinchart [Wed, 26 Feb 2020 11:24:39 +0000 (13:24 +0200)]
drm/bridge: tfp410: Allow operation without drm_connector
The tfp410 driver can operate as part of a pipeline where the
drm_connector is created by the display controller. Enable this mode of
operation by skipping creation of a drm_connector internally.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.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-20-laurent.pinchart@ideasonboard.com
Laurent Pinchart [Wed, 26 Feb 2020 11:24:38 +0000 (13:24 +0200)]
drm/bridge: tfp410: Replace manual connector handling with bridge
Now that a driver is available for display connectors, replace the
manual connector handling code with usage of the DRM bridge API. The
tfp410 driver doesn't deal with the display connector directly anymore,
but still delegates drm_connector operations to the next bridge. This
brings us one step closer to having the tfp410 driver handling the
TFP410 only.
Laurent Pinchart [Wed, 26 Feb 2020 11:24:35 +0000 (13:24 +0200)]
drm/bridge: Add bridge driver for display connectors
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In order to fix this, implement a bridge driver for display connectors.
The driver centralises logic for the DVI, HDMI, VGAn composite and
S-video connectors and exposes corresponding bridge operations.
This driver in itself doesn't solve the issue completely, changes in
bridge and display controller drivers are needed to make use of the new
connector driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.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-16-laurent.pinchart@ideasonboard.com
projects / mirror_ubuntu-jammy-kernel.git / log