2016-08-13 04:48:50 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2016 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, distribute, and sell this software and its
|
|
|
|
* documentation for any purpose is hereby granted without fee, provided that
|
|
|
|
* the above copyright notice appear in all copies and that both that copyright
|
|
|
|
* notice and this permission notice appear in supporting documentation, and
|
|
|
|
* that the name of the copyright holders not be used in advertising or
|
|
|
|
* publicity pertaining to distribution of the software without specific,
|
|
|
|
* written prior permission. The copyright holders make no representations
|
|
|
|
* about the suitability of this software for any purpose. It is provided "as
|
|
|
|
* is" without express or implied warranty.
|
|
|
|
*
|
|
|
|
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
|
|
|
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
|
|
|
|
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
|
|
|
|
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
|
|
|
|
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
|
|
|
|
* OF THIS SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __DRM_CONNECTOR_H__
|
|
|
|
#define __DRM_CONNECTOR_H__
|
|
|
|
|
|
|
|
#include <linux/list.h>
|
2017-12-13 20:49:36 +08:00
|
|
|
#include <linux/llist.h>
|
2016-08-13 04:48:50 +08:00
|
|
|
#include <linux/ctype.h>
|
2017-05-01 21:37:53 +08:00
|
|
|
#include <linux/hdmi.h>
|
2021-10-06 04:23:17 +08:00
|
|
|
#include <linux/notifier.h>
|
2016-08-29 16:27:51 +08:00
|
|
|
#include <drm/drm_mode_object.h>
|
2018-09-05 21:57:05 +08:00
|
|
|
#include <drm/drm_util.h>
|
2022-11-30 04:16:31 +08:00
|
|
|
#include <drm/drm_property.h>
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2016-09-01 00:09:05 +08:00
|
|
|
#include <uapi/drm/drm_mode.h>
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_connector_helper_funcs;
|
2017-04-07 02:55:20 +08:00
|
|
|
struct drm_modeset_acquire_ctx;
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_device;
|
|
|
|
struct drm_crtc;
|
|
|
|
struct drm_encoder;
|
2022-06-09 15:27:15 +08:00
|
|
|
struct drm_panel;
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_property;
|
|
|
|
struct drm_property_blob;
|
2016-11-05 23:08:09 +08:00
|
|
|
struct drm_printer;
|
2021-10-06 04:23:17 +08:00
|
|
|
struct drm_privacy_screen;
|
2016-08-13 04:48:50 +08:00
|
|
|
struct edid;
|
2019-07-27 01:22:55 +08:00
|
|
|
struct i2c_adapter;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
|
|
|
enum drm_connector_force {
|
|
|
|
DRM_FORCE_UNSPECIFIED,
|
|
|
|
DRM_FORCE_OFF,
|
|
|
|
DRM_FORCE_ON, /* force on analog part normally */
|
|
|
|
DRM_FORCE_ON_DIGITAL, /* for DVI-I use digital connector */
|
|
|
|
};
|
|
|
|
|
2016-08-13 04:48:53 +08:00
|
|
|
/**
|
|
|
|
* enum drm_connector_status - status for a &drm_connector
|
|
|
|
*
|
|
|
|
* This enum is used to track the connector status. There are no separate
|
|
|
|
* #defines for the uapi!
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
enum drm_connector_status {
|
2016-08-13 04:48:53 +08:00
|
|
|
/**
|
|
|
|
* @connector_status_connected: The connector is definitely connected to
|
|
|
|
* a sink device, and can be enabled.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
connector_status_connected = 1,
|
2016-08-13 04:48:53 +08:00
|
|
|
/**
|
|
|
|
* @connector_status_disconnected: The connector isn't connected to a
|
|
|
|
* sink device which can be autodetect. For digital outputs like DP or
|
|
|
|
* HDMI (which can be realiable probed) this means there's really
|
|
|
|
* nothing there. It is driver-dependent whether a connector with this
|
|
|
|
* status can be lit up or not.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
connector_status_disconnected = 2,
|
2016-08-13 04:48:53 +08:00
|
|
|
/**
|
|
|
|
* @connector_status_unknown: The connector's status could not be
|
|
|
|
* reliably detected. This happens when probing would either cause
|
|
|
|
* flicker (like load-detection when the connector is in use), or when a
|
|
|
|
* hardware resource isn't available (like when load-detection needs a
|
|
|
|
* free CRTC). It should be possible to light up the connector with one
|
|
|
|
* of the listed fallback modes. For default configuration userspace
|
|
|
|
* should only try to light up connectors with unknown status when
|
|
|
|
* there's not connector with @connector_status_connected.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
connector_status_unknown = 3,
|
|
|
|
};
|
|
|
|
|
drm/atomic_helper: Stop modesets on unregistered connectors harder
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
|
|
|
/**
|
2020-11-16 18:18:01 +08:00
|
|
|
* enum drm_connector_registration_state - userspace registration status for
|
drm/atomic_helper: Stop modesets on unregistered connectors harder
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
|
|
|
* a &drm_connector
|
|
|
|
*
|
|
|
|
* This enum is used to track the status of initializing a connector and
|
|
|
|
* registering it with userspace, so that DRM can prevent bogus modesets on
|
|
|
|
* connectors that no longer exist.
|
|
|
|
*/
|
|
|
|
enum drm_connector_registration_state {
|
|
|
|
/**
|
|
|
|
* @DRM_CONNECTOR_INITIALIZING: The connector has just been created,
|
|
|
|
* but has yet to be exposed to userspace. There should be no
|
|
|
|
* additional restrictions to how the state of this connector may be
|
|
|
|
* modified.
|
|
|
|
*/
|
|
|
|
DRM_CONNECTOR_INITIALIZING = 0,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_CONNECTOR_REGISTERED: The connector has been fully initialized
|
|
|
|
* and registered with sysfs, as such it has been exposed to
|
|
|
|
* userspace. There should be no additional restrictions to how the
|
|
|
|
* state of this connector may be modified.
|
|
|
|
*/
|
|
|
|
DRM_CONNECTOR_REGISTERED = 1,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_CONNECTOR_UNREGISTERED: The connector has either been exposed
|
|
|
|
* to userspace and has since been unregistered and removed from
|
|
|
|
* userspace, or the connector was unregistered before it had a chance
|
|
|
|
* to be exposed to userspace (e.g. still in the
|
|
|
|
* @DRM_CONNECTOR_INITIALIZING state). When a connector is
|
|
|
|
* unregistered, there are additional restrictions to how its state
|
|
|
|
* may be modified:
|
|
|
|
*
|
|
|
|
* - An unregistered connector may only have its DPMS changed from
|
|
|
|
* On->Off. Once DPMS is changed to Off, it may not be switched back
|
|
|
|
* to On.
|
|
|
|
* - Modesets are not allowed on unregistered connectors, unless they
|
|
|
|
* would result in disabling its assigned CRTCs. This means
|
|
|
|
* disabling a CRTC on an unregistered connector is OK, but enabling
|
|
|
|
* one is not.
|
|
|
|
* - Removing a CRTC from an unregistered connector is OK, but new
|
|
|
|
* CRTCs may never be assigned to an unregistered connector.
|
|
|
|
*/
|
|
|
|
DRM_CONNECTOR_UNREGISTERED = 2,
|
|
|
|
};
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
enum subpixel_order {
|
|
|
|
SubPixelUnknown = 0,
|
|
|
|
SubPixelHorizontalRGB,
|
|
|
|
SubPixelHorizontalBGR,
|
|
|
|
SubPixelVerticalRGB,
|
|
|
|
SubPixelVerticalBGR,
|
|
|
|
SubPixelNone,
|
2017-03-13 19:24:01 +08:00
|
|
|
|
|
|
|
};
|
|
|
|
|
2022-11-17 17:28:48 +08:00
|
|
|
/**
|
|
|
|
* enum drm_connector_tv_mode - Analog TV output mode
|
|
|
|
*
|
|
|
|
* This enum is used to indicate the TV output mode used on an analog TV
|
|
|
|
* connector.
|
|
|
|
*
|
|
|
|
* WARNING: The values of this enum is uABI since they're exposed in the
|
|
|
|
* "TV mode" connector property.
|
|
|
|
*/
|
|
|
|
enum drm_connector_tv_mode {
|
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_NTSC: CCIR System M (aka 525-lines)
|
|
|
|
* together with the NTSC Color Encoding.
|
|
|
|
*/
|
|
|
|
DRM_MODE_TV_MODE_NTSC,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_NTSC_443: Variant of
|
|
|
|
* @DRM_MODE_TV_MODE_NTSC. Uses a color subcarrier frequency
|
|
|
|
* of 4.43 MHz.
|
|
|
|
*/
|
|
|
|
DRM_MODE_TV_MODE_NTSC_443,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_NTSC_J: Variant of @DRM_MODE_TV_MODE_NTSC
|
|
|
|
* used in Japan. Uses a black level equals to the blanking
|
|
|
|
* level.
|
|
|
|
*/
|
|
|
|
DRM_MODE_TV_MODE_NTSC_J,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_PAL: CCIR System B together with the PAL
|
|
|
|
* color system.
|
|
|
|
*/
|
|
|
|
DRM_MODE_TV_MODE_PAL,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_PAL_M: CCIR System M (aka 525-lines)
|
|
|
|
* together with the PAL color encoding
|
|
|
|
*/
|
|
|
|
DRM_MODE_TV_MODE_PAL_M,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_PAL_N: CCIR System N together with the PAL
|
|
|
|
* color encoding. It uses 625 lines, but has a color subcarrier
|
|
|
|
* frequency of 3.58MHz, the SECAM color space, and narrower
|
|
|
|
* channels compared to most of the other PAL variants.
|
|
|
|
*/
|
|
|
|
DRM_MODE_TV_MODE_PAL_N,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_SECAM: CCIR System B together with the
|
|
|
|
* SECAM color system.
|
|
|
|
*/
|
|
|
|
DRM_MODE_TV_MODE_SECAM,
|
|
|
|
|
2023-05-04 20:34:44 +08:00
|
|
|
/**
|
|
|
|
* @DRM_MODE_TV_MODE_MAX: Number of analog TV output modes.
|
|
|
|
*
|
|
|
|
* Internal implementation detail; this is not uABI.
|
|
|
|
*/
|
2022-11-17 17:28:48 +08:00
|
|
|
DRM_MODE_TV_MODE_MAX,
|
|
|
|
};
|
|
|
|
|
2017-03-13 19:24:02 +08:00
|
|
|
/**
|
|
|
|
* struct drm_scrambling: sink's scrambling support.
|
|
|
|
*/
|
|
|
|
struct drm_scrambling {
|
|
|
|
/**
|
|
|
|
* @supported: scrambling supported for rates > 340 Mhz.
|
|
|
|
*/
|
|
|
|
bool supported;
|
|
|
|
/**
|
|
|
|
* @low_rates: scrambling supported for rates <= 340 Mhz.
|
|
|
|
*/
|
|
|
|
bool low_rates;
|
|
|
|
};
|
|
|
|
|
2017-03-13 19:24:01 +08:00
|
|
|
/*
|
|
|
|
* struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
|
|
|
|
*
|
|
|
|
* Provides SCDC register support and capabilities related information on a
|
|
|
|
* HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
|
|
|
|
*/
|
|
|
|
struct drm_scdc {
|
|
|
|
/**
|
|
|
|
* @supported: status control & data channel present.
|
|
|
|
*/
|
|
|
|
bool supported;
|
|
|
|
/**
|
|
|
|
* @read_request: sink is capable of generating scdc read request.
|
|
|
|
*/
|
|
|
|
bool read_request;
|
2017-03-13 19:24:02 +08:00
|
|
|
/**
|
|
|
|
* @scrambling: sink's scrambling capabilities
|
|
|
|
*/
|
|
|
|
struct drm_scrambling scrambling;
|
2017-03-13 19:24:01 +08:00
|
|
|
};
|
|
|
|
|
2020-12-18 18:37:11 +08:00
|
|
|
/**
|
|
|
|
* struct drm_hdmi_dsc_cap - DSC capabilities of HDMI sink
|
|
|
|
*
|
|
|
|
* Describes the DSC support provided by HDMI 2.1 sink.
|
|
|
|
* The information is fetched fom additional HFVSDB blocks defined
|
|
|
|
* for HDMI 2.1.
|
|
|
|
*/
|
|
|
|
struct drm_hdmi_dsc_cap {
|
|
|
|
/** @v_1p2: flag for dsc1.2 version support by sink */
|
|
|
|
bool v_1p2;
|
|
|
|
|
|
|
|
/** @native_420: Does sink support DSC with 4:2:0 compression */
|
|
|
|
bool native_420;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
|
|
|
|
* compressed formats
|
|
|
|
*/
|
|
|
|
bool all_bpp;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @bpc_supported: compressed bpc supported by sink : 10, 12 or 16 bpc
|
|
|
|
*/
|
|
|
|
u8 bpc_supported;
|
|
|
|
|
|
|
|
/** @max_slices: maximum number of Horizontal slices supported by */
|
|
|
|
u8 max_slices;
|
|
|
|
|
|
|
|
/** @clk_per_slice : max pixel clock in MHz supported per slice */
|
|
|
|
int clk_per_slice;
|
|
|
|
|
|
|
|
/** @max_lanes : dsc max lanes supported for Fixed rate Link training */
|
|
|
|
u8 max_lanes;
|
|
|
|
|
|
|
|
/** @max_frl_rate_per_lane : maximum frl rate with DSC per lane */
|
|
|
|
u8 max_frl_rate_per_lane;
|
|
|
|
|
|
|
|
/** @total_chunk_kbytes: max size of chunks in KBs supported per line*/
|
|
|
|
u8 total_chunk_kbytes;
|
|
|
|
};
|
2017-03-13 19:24:02 +08:00
|
|
|
|
2017-03-13 19:24:01 +08:00
|
|
|
/**
|
|
|
|
* struct drm_hdmi_info - runtime information about the connected HDMI sink
|
|
|
|
*
|
|
|
|
* Describes if a given display supports advanced HDMI 2.0 features.
|
|
|
|
* This information is available in CEA-861-F extension blocks (like HF-VSDB).
|
|
|
|
*/
|
|
|
|
struct drm_hdmi_info {
|
2017-03-28 15:06:19 +08:00
|
|
|
/** @scdc: sink's scdc support and capabilities */
|
2017-03-13 19:24:01 +08:00
|
|
|
struct drm_scdc scdc;
|
2017-07-13 23:33:11 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @y420_vdb_modes: bitmap of modes which can support ycbcr420
|
2019-12-11 06:10:48 +08:00
|
|
|
* output only (not normal RGB/YCBCR444/422 outputs). The max VIC
|
|
|
|
* defined by the CEA-861-G spec is 219, so the size is 256 bits to map
|
|
|
|
* up to 256 VICs.
|
2017-07-13 23:33:11 +08:00
|
|
|
*/
|
2019-12-11 06:10:48 +08:00
|
|
|
unsigned long y420_vdb_modes[BITS_TO_LONGS(256)];
|
drm/edid: parse YCBCR420 videomodes from EDID
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
V2: Addressed
Review comments from Emil:
- Use 1ULL<<i instead of 1<<i to make sure the output is 64bit.
- Use the suggested method for updating dbmap.
- Add documentation for YCBCR420_vcb_map to fix kbuild warning.
Review comments from Ville:
- Do not expose the YCBCR420 flags in uabi layer, keep it internal.
- Save a map of YCBCR420 modes for future reference.
- Check db length before trying to parse extended tag.
- Add a warning if there are > 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.
V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmap
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14 18:33:46 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @y420_cmdb_modes: bitmap of modes which can support ycbcr420
|
2019-12-11 06:10:48 +08:00
|
|
|
* output also, along with normal HDMI outputs. The max VIC defined by
|
|
|
|
* the CEA-861-G spec is 219, so the size is 256 bits to map up to 256
|
|
|
|
* VICs.
|
drm/edid: parse YCBCR420 videomodes from EDID
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
V2: Addressed
Review comments from Emil:
- Use 1ULL<<i instead of 1<<i to make sure the output is 64bit.
- Use the suggested method for updating dbmap.
- Add documentation for YCBCR420_vcb_map to fix kbuild warning.
Review comments from Ville:
- Do not expose the YCBCR420 flags in uabi layer, keep it internal.
- Save a map of YCBCR420 modes for future reference.
- Check db length before trying to parse extended tag.
- Add a warning if there are > 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.
V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmap
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14 18:33:46 +08:00
|
|
|
*/
|
2019-12-11 06:10:48 +08:00
|
|
|
unsigned long y420_cmdb_modes[BITS_TO_LONGS(256)];
|
drm/edid: parse YCBCR420 videomodes from EDID
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
V2: Addressed
Review comments from Emil:
- Use 1ULL<<i instead of 1<<i to make sure the output is 64bit.
- Use the suggested method for updating dbmap.
- Add documentation for YCBCR420_vcb_map to fix kbuild warning.
Review comments from Ville:
- Do not expose the YCBCR420 flags in uabi layer, keep it internal.
- Save a map of YCBCR420 modes for future reference.
- Check db length before trying to parse extended tag.
- Add a warning if there are > 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.
V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmap
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14 18:33:46 +08:00
|
|
|
|
2017-07-13 23:33:13 +08:00
|
|
|
/** @y420_dc_modes: bitmap of deep color support index */
|
|
|
|
u8 y420_dc_modes;
|
2020-12-18 18:37:10 +08:00
|
|
|
|
|
|
|
/** @max_frl_rate_per_lane: support fixed rate link */
|
|
|
|
u8 max_frl_rate_per_lane;
|
|
|
|
|
|
|
|
/** @max_lanes: supported by sink */
|
|
|
|
u8 max_lanes;
|
2020-12-18 18:37:11 +08:00
|
|
|
|
|
|
|
/** @dsc_cap: DSC capabilities of the sink */
|
|
|
|
struct drm_hdmi_dsc_cap dsc_cap;
|
2016-08-13 04:48:50 +08:00
|
|
|
};
|
|
|
|
|
drm: Add a new connector atomic property for link status
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requirements of the mode. Black screen follows.
One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would
also conflict with the idea of making setcrtc asynchronous in the
future, returning before the actual mode setting and link training.
Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on
practical not theoretical capabilities. However, the changes for link
training are pretty drastic, all for the sake of error handling and
DP compliance, when the most common happy day scenario is the current
approach of link training at mode setting time, using the optimal
parameters for the mode. It is also not certain all hardware could do
this without the pipe on; not even all our hardware can do this. Some
of this can be solved, but not trivially.
Both of the above ideas also fail to address link degradation *during*
operation.
The solution is to add a new "link-status" connector property in order
to address link training failure in a way that:
a) changes the current happy day scenario as little as possible, to
avoid regressions, b) can be implemented the same way by all drm
drivers, c) is still opt-in for the drivers and userspace, and opting
out doesn't regress the user experience, d) doesn't prevent drivers
from implementing better or alternate approaches, possibly without
userspace involvement. And, of course, handles all the issues presented.
In the usual happy day scenario, this is always "good". If something
fails during or after a mode set, the kernel driver can set the link
status to "bad" and issue a hotplug uevent for userspace to have it
re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
again. If the theoretical capabilities of the link can't be reached,
the mode list is trimmed based on that.
v7 by Jani:
* Rebase, simplify set property while at it, checkpatch fix
v6:
* Fix a typo in kernel doc (Sean Paul)
v5:
* Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
v4:
* Add comments in kernel-doc format (Daniel Vetter)
* Update the kernel-doc for link-status (Sean Paul)
v3:
* Fixed a build error (Jani Saarinen)
v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
|
|
|
/**
|
|
|
|
* enum drm_link_status - connector's link_status property value
|
|
|
|
*
|
|
|
|
* This enum is used as the connector's link status property value.
|
|
|
|
* It is set to the values defined in uapi.
|
2017-03-01 22:45:10 +08:00
|
|
|
*
|
|
|
|
* @DRM_LINK_STATUS_GOOD: DP Link is Good as a result of successful
|
|
|
|
* link training
|
|
|
|
* @DRM_LINK_STATUS_BAD: DP Link is BAD as a result of link training
|
|
|
|
* failure
|
drm: Add a new connector atomic property for link status
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requirements of the mode. Black screen follows.
One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would
also conflict with the idea of making setcrtc asynchronous in the
future, returning before the actual mode setting and link training.
Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on
practical not theoretical capabilities. However, the changes for link
training are pretty drastic, all for the sake of error handling and
DP compliance, when the most common happy day scenario is the current
approach of link training at mode setting time, using the optimal
parameters for the mode. It is also not certain all hardware could do
this without the pipe on; not even all our hardware can do this. Some
of this can be solved, but not trivially.
Both of the above ideas also fail to address link degradation *during*
operation.
The solution is to add a new "link-status" connector property in order
to address link training failure in a way that:
a) changes the current happy day scenario as little as possible, to
avoid regressions, b) can be implemented the same way by all drm
drivers, c) is still opt-in for the drivers and userspace, and opting
out doesn't regress the user experience, d) doesn't prevent drivers
from implementing better or alternate approaches, possibly without
userspace involvement. And, of course, handles all the issues presented.
In the usual happy day scenario, this is always "good". If something
fails during or after a mode set, the kernel driver can set the link
status to "bad" and issue a hotplug uevent for userspace to have it
re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
again. If the theoretical capabilities of the link can't be reached,
the mode list is trimmed based on that.
v7 by Jani:
* Rebase, simplify set property while at it, checkpatch fix
v6:
* Fix a typo in kernel doc (Sean Paul)
v5:
* Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
v4:
* Add comments in kernel-doc format (Daniel Vetter)
* Update the kernel-doc for link-status (Sean Paul)
v3:
* Fixed a build error (Jani Saarinen)
v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
|
|
|
*/
|
|
|
|
enum drm_link_status {
|
|
|
|
DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD,
|
|
|
|
DRM_LINK_STATUS_BAD = DRM_MODE_LINK_STATUS_BAD,
|
|
|
|
};
|
|
|
|
|
2017-11-26 03:35:49 +08:00
|
|
|
/**
|
|
|
|
* enum drm_panel_orientation - panel_orientation info for &drm_display_info
|
|
|
|
*
|
|
|
|
* This enum is used to track the (LCD) panel orientation. There are no
|
|
|
|
* separate #defines for the uapi!
|
|
|
|
*
|
|
|
|
* @DRM_MODE_PANEL_ORIENTATION_UNKNOWN: The drm driver has not provided any
|
|
|
|
* panel orientation information (normal
|
|
|
|
* for non panels) in this case the "panel
|
|
|
|
* orientation" connector prop will not be
|
|
|
|
* attached.
|
|
|
|
* @DRM_MODE_PANEL_ORIENTATION_NORMAL: The top side of the panel matches the
|
|
|
|
* top side of the device's casing.
|
|
|
|
* @DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP: The top side of the panel matches the
|
|
|
|
* bottom side of the device's casing, iow
|
|
|
|
* the panel is mounted upside-down.
|
|
|
|
* @DRM_MODE_PANEL_ORIENTATION_LEFT_UP: The left side of the panel matches the
|
|
|
|
* top side of the device's casing.
|
|
|
|
* @DRM_MODE_PANEL_ORIENTATION_RIGHT_UP: The right side of the panel matches the
|
|
|
|
* top side of the device's casing.
|
|
|
|
*/
|
|
|
|
enum drm_panel_orientation {
|
|
|
|
DRM_MODE_PANEL_ORIENTATION_UNKNOWN = -1,
|
|
|
|
DRM_MODE_PANEL_ORIENTATION_NORMAL = 0,
|
|
|
|
DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP,
|
|
|
|
DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
|
|
|
|
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
|
|
|
|
};
|
|
|
|
|
2020-03-11 07:16:51 +08:00
|
|
|
/**
|
|
|
|
* struct drm_monitor_range_info - Panel's Monitor range in EDID for
|
|
|
|
* &drm_display_info
|
|
|
|
*
|
|
|
|
* This struct is used to store a frequency range supported by panel
|
|
|
|
* as parsed from EDID's detailed monitor range descriptor block.
|
|
|
|
*
|
|
|
|
* @min_vfreq: This is the min supported refresh rate in Hz from
|
|
|
|
* EDID's detailed monitor range.
|
|
|
|
* @max_vfreq: This is the max supported refresh rate in Hz from
|
|
|
|
* EDID's detailed monitor range
|
|
|
|
*/
|
|
|
|
struct drm_monitor_range_info {
|
2022-08-27 05:34:51 +08:00
|
|
|
u16 min_vfreq;
|
|
|
|
u16 max_vfreq;
|
2020-03-11 07:16:51 +08:00
|
|
|
};
|
|
|
|
|
2022-07-19 17:56:58 +08:00
|
|
|
/**
|
|
|
|
* struct drm_luminance_range_info - Panel's luminance range for
|
|
|
|
* &drm_display_info. Calculated using data in EDID
|
|
|
|
*
|
|
|
|
* This struct is used to store a luminance range supported by panel
|
|
|
|
* as calculated using data from EDID's static hdr metadata.
|
|
|
|
*
|
|
|
|
* @min_luminance: This is the min supported luminance value
|
|
|
|
*
|
|
|
|
* @max_luminance: This is the max supported luminance value
|
|
|
|
*/
|
|
|
|
struct drm_luminance_range_info {
|
|
|
|
u32 min_luminance;
|
|
|
|
u32 max_luminance;
|
|
|
|
};
|
|
|
|
|
2021-10-06 04:23:13 +08:00
|
|
|
/**
|
|
|
|
* enum drm_privacy_screen_status - privacy screen status
|
|
|
|
*
|
|
|
|
* This enum is used to track and control the state of the integrated privacy
|
|
|
|
* screen present on some display panels, via the "privacy-screen sw-state"
|
|
|
|
* and "privacy-screen hw-state" properties. Note the _LOCKED enum values
|
|
|
|
* are only valid for the "privacy-screen hw-state" property.
|
|
|
|
*
|
|
|
|
* @PRIVACY_SCREEN_DISABLED:
|
|
|
|
* The privacy-screen on the panel is disabled
|
|
|
|
* @PRIVACY_SCREEN_ENABLED:
|
|
|
|
* The privacy-screen on the panel is enabled
|
|
|
|
* @PRIVACY_SCREEN_DISABLED_LOCKED:
|
|
|
|
* The privacy-screen on the panel is disabled and locked (cannot be changed)
|
|
|
|
* @PRIVACY_SCREEN_ENABLED_LOCKED:
|
|
|
|
* The privacy-screen on the panel is enabled and locked (cannot be changed)
|
|
|
|
*/
|
|
|
|
enum drm_privacy_screen_status {
|
|
|
|
PRIVACY_SCREEN_DISABLED = 0,
|
|
|
|
PRIVACY_SCREEN_ENABLED,
|
|
|
|
PRIVACY_SCREEN_DISABLED_LOCKED,
|
|
|
|
PRIVACY_SCREEN_ENABLED_LOCKED,
|
|
|
|
};
|
|
|
|
|
2023-02-03 10:07:43 +08:00
|
|
|
/**
|
|
|
|
* enum drm_colorspace - color space
|
|
|
|
*
|
|
|
|
* This enum is a consolidated colorimetry list supported by HDMI and
|
drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v13: Reorder the colorspace macros.
v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
|
|
|
* DP protocol standard. The respective connectors will register
|
|
|
|
* a property with the subset of this list (supported by that
|
|
|
|
* respective protocol). Userspace will set the colorspace through
|
|
|
|
* a colorspace property which will be created and exposed to
|
|
|
|
* userspace.
|
2023-02-03 10:07:43 +08:00
|
|
|
*
|
|
|
|
* DP definitions come from the DP v2.0 spec
|
|
|
|
* HDMI definitions come from the CTA-861-H spec
|
|
|
|
*
|
|
|
|
* A note on YCC and RGB variants:
|
|
|
|
*
|
|
|
|
* Since userspace is not aware of the encoding on the wire
|
|
|
|
* (RGB or YCbCr), drivers are free to pick the appropriate
|
|
|
|
* variant, regardless of what userspace selects. E.g., if
|
|
|
|
* BT2020_RGB is selected by userspace a driver will pick
|
|
|
|
* BT2020_YCC if the encoding on the wire is YUV444 or YUV420.
|
|
|
|
*
|
|
|
|
* @DRM_MODE_COLORIMETRY_DEFAULT:
|
|
|
|
* Driver specific behavior.
|
|
|
|
* @DRM_MODE_COLORIMETRY_NO_DATA:
|
|
|
|
* Driver specific behavior.
|
|
|
|
* @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
|
|
|
|
* (HDMI)
|
|
|
|
* SMPTE ST 170M colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_BT709_YCC:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* ITU-R BT.709 colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_XVYCC_601:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* xvYCC601 colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_XVYCC_709:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* xvYCC709 colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_SYCC_601:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* sYCC601 colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_OPYCC_601:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* opYCC601 colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_OPRGB:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* opRGB colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_BT2020_CYCC:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_BT2020_RGB:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* ITU-R BT.2020 R' G' B' colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_BT2020_YCC:
|
|
|
|
* (HDMI, DP)
|
|
|
|
* ITU-R BT.2020 Y' C'b C'r colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
|
|
|
|
* (HDMI)
|
|
|
|
* SMPTE ST 2113 P3D65 colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
|
|
|
|
* (HDMI)
|
|
|
|
* SMPTE ST 2113 P3DCI colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
|
|
|
|
* (DP)
|
|
|
|
* RGB wide gamut fixed point colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
|
|
|
|
* (DP)
|
|
|
|
* RGB wide gamut floating point
|
|
|
|
* (scRGB (IEC 61966-2-2)) colorimetry format
|
|
|
|
* @DRM_MODE_COLORIMETRY_BT601_YCC:
|
|
|
|
* (DP)
|
|
|
|
* ITU-R BT.601 colorimetry format
|
|
|
|
* The DP spec does not say whether this is the 525 or the 625
|
|
|
|
* line version.
|
drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v13: Reorder the colorspace macros.
v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
|
|
|
*/
|
2023-02-03 10:07:42 +08:00
|
|
|
enum drm_colorspace {
|
|
|
|
/* For Default case, driver will set the colorspace */
|
|
|
|
DRM_MODE_COLORIMETRY_DEFAULT = 0,
|
|
|
|
/* CEA 861 Normal Colorimetry options */
|
|
|
|
DRM_MODE_COLORIMETRY_NO_DATA = 0,
|
|
|
|
DRM_MODE_COLORIMETRY_SMPTE_170M_YCC = 1,
|
|
|
|
DRM_MODE_COLORIMETRY_BT709_YCC = 2,
|
|
|
|
/* CEA 861 Extended Colorimetry Options */
|
|
|
|
DRM_MODE_COLORIMETRY_XVYCC_601 = 3,
|
|
|
|
DRM_MODE_COLORIMETRY_XVYCC_709 = 4,
|
|
|
|
DRM_MODE_COLORIMETRY_SYCC_601 = 5,
|
|
|
|
DRM_MODE_COLORIMETRY_OPYCC_601 = 6,
|
|
|
|
DRM_MODE_COLORIMETRY_OPRGB = 7,
|
|
|
|
DRM_MODE_COLORIMETRY_BT2020_CYCC = 8,
|
|
|
|
DRM_MODE_COLORIMETRY_BT2020_RGB = 9,
|
|
|
|
DRM_MODE_COLORIMETRY_BT2020_YCC = 10,
|
|
|
|
/* Additional Colorimetry extension added as part of CTA 861.G */
|
|
|
|
DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 = 11,
|
|
|
|
DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER = 12,
|
|
|
|
/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
|
|
|
|
DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED = 13,
|
|
|
|
DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT = 14,
|
|
|
|
DRM_MODE_COLORIMETRY_BT601_YCC = 15,
|
2022-11-30 04:16:31 +08:00
|
|
|
/* not a valid value; merely used for counting */
|
|
|
|
DRM_MODE_COLORIMETRY_COUNT
|
2023-02-03 10:07:42 +08:00
|
|
|
};
|
drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v13: Reorder the colorspace macros.
v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
|
|
|
|
2019-01-12 08:42:39 +08:00
|
|
|
/**
|
|
|
|
* enum drm_bus_flags - bus_flags info for &drm_display_info
|
|
|
|
*
|
|
|
|
* This enum defines signal polarities and clock edge information for signals on
|
|
|
|
* a bus as bitmask flags.
|
|
|
|
*
|
|
|
|
* The clock edge information is conveyed by two sets of symbols,
|
|
|
|
* DRM_BUS_FLAGS_*_DRIVE_\* and DRM_BUS_FLAGS_*_SAMPLE_\*. When this enum is
|
|
|
|
* used to describe a bus from the point of view of the transmitter, the
|
|
|
|
* \*_DRIVE_\* flags should be used. When used from the point of view of the
|
|
|
|
* receiver, the \*_SAMPLE_\* flags should be used. The \*_DRIVE_\* and
|
|
|
|
* \*_SAMPLE_\* flags alias each other, with the \*_SAMPLE_POSEDGE and
|
|
|
|
* \*_SAMPLE_NEGEDGE flags being equal to \*_DRIVE_NEGEDGE and \*_DRIVE_POSEDGE
|
|
|
|
* respectively. This simplifies code as signals are usually sampled on the
|
|
|
|
* opposite edge of the driving edge. Transmitters and receivers may however
|
|
|
|
* need to take other signal timings into account to convert between driving
|
|
|
|
* and sample edges.
|
|
|
|
*/
|
|
|
|
enum drm_bus_flags {
|
2020-07-01 02:05:45 +08:00
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_DE_LOW:
|
|
|
|
*
|
|
|
|
* The Data Enable signal is active low
|
|
|
|
*/
|
2019-01-12 08:42:39 +08:00
|
|
|
DRM_BUS_FLAG_DE_LOW = BIT(0),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_DE_HIGH:
|
|
|
|
*
|
|
|
|
* The Data Enable signal is active high
|
|
|
|
*/
|
2019-01-12 08:42:39 +08:00
|
|
|
DRM_BUS_FLAG_DE_HIGH = BIT(1),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE:
|
|
|
|
*
|
|
|
|
* Data is driven on the rising edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE = BIT(2),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE:
|
|
|
|
*
|
|
|
|
* Data is driven on the falling edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE = BIT(3),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE:
|
|
|
|
*
|
|
|
|
* Data is sampled on the rising edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE = DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE:
|
|
|
|
*
|
|
|
|
* Data is sampled on the falling edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_DATA_MSB_TO_LSB:
|
|
|
|
*
|
|
|
|
* Data is transmitted MSB to LSB on the bus
|
|
|
|
*/
|
2019-01-12 08:42:39 +08:00
|
|
|
DRM_BUS_FLAG_DATA_MSB_TO_LSB = BIT(4),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_DATA_LSB_TO_MSB:
|
|
|
|
*
|
|
|
|
* Data is transmitted LSB to MSB on the bus
|
|
|
|
*/
|
2019-01-12 08:42:39 +08:00
|
|
|
DRM_BUS_FLAG_DATA_LSB_TO_MSB = BIT(5),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE:
|
|
|
|
*
|
|
|
|
* Sync signals are driven on the rising edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE = BIT(6),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE:
|
|
|
|
*
|
|
|
|
* Sync signals are driven on the falling edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE = BIT(7),
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE:
|
|
|
|
*
|
|
|
|
* Sync signals are sampled on the rising edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE = DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE:
|
|
|
|
*
|
|
|
|
* Sync signals are sampled on the falling edge of the pixel clock
|
|
|
|
*/
|
2020-07-01 02:05:44 +08:00
|
|
|
DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE = DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
|
2020-07-01 02:05:45 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @DRM_BUS_FLAG_SHARP_SIGNALS:
|
|
|
|
*
|
|
|
|
* Set if the Sharp-specific signals (SPL, CLS, PS, REV) must be used
|
|
|
|
*/
|
2019-06-03 23:31:19 +08:00
|
|
|
DRM_BUS_FLAG_SHARP_SIGNALS = BIT(8),
|
2019-01-12 08:42:39 +08:00
|
|
|
};
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* struct drm_display_info - runtime data about the connected sink
|
|
|
|
*
|
|
|
|
* Describes a given display (e.g. CRT or flat panel) and its limitations. For
|
|
|
|
* fixed display sinks like built-in panels there's not much difference between
|
2016-12-30 04:48:26 +08:00
|
|
|
* this and &struct drm_connector. But for sinks with a real cable this
|
2016-08-13 04:48:55 +08:00
|
|
|
* structure is meant to describe all the things at the other end of the cable.
|
|
|
|
*
|
|
|
|
* For sinks which provide an EDID this can be filled out by calling
|
|
|
|
* drm_add_edid_modes().
|
2016-08-13 04:48:50 +08:00
|
|
|
*/
|
|
|
|
struct drm_display_info {
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @width_mm: Physical width in mm.
|
|
|
|
*/
|
2019-03-27 01:33:59 +08:00
|
|
|
unsigned int width_mm;
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @height_mm: Physical height in mm.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
unsigned int height_mm;
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @bpc: Maximum bits per color channel. Used by HDMI and DP outputs.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
unsigned int bpc;
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @subpixel_order: Subpixel order of LCD panels.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
enum subpixel_order subpixel_order;
|
|
|
|
|
|
|
|
#define DRM_COLOR_FORMAT_RGB444 (1<<0)
|
2022-01-20 23:16:13 +08:00
|
|
|
#define DRM_COLOR_FORMAT_YCBCR444 (1<<1)
|
|
|
|
#define DRM_COLOR_FORMAT_YCBCR422 (1<<2)
|
|
|
|
#define DRM_COLOR_FORMAT_YCBCR420 (1<<3)
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2017-11-26 03:35:49 +08:00
|
|
|
/**
|
|
|
|
* @panel_orientation: Read only connector property for built-in panels,
|
|
|
|
* indicating the orientation of the panel vs the device's casing.
|
|
|
|
* drm_connector_init() sets this to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
|
|
|
|
* When not UNKNOWN this gets used by the drm_fb_helpers to rotate the
|
|
|
|
* fb to compensate and gets exported as prop to userspace.
|
|
|
|
*/
|
|
|
|
int panel_orientation;
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @color_formats: HDMI Color formats, selects between RGB and YCrCb
|
|
|
|
* modes. Used DRM_COLOR_FORMAT\_ defines, which are _not_ the same ones
|
|
|
|
* as used to describe the pixel format in framebuffers, and also don't
|
|
|
|
* match the formats in @bus_formats which are shared with v4l.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
u32 color_formats;
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @bus_formats: Pixel data format on the wire, somewhat redundant with
|
|
|
|
* @color_formats. Array of size @num_bus_formats encoded using
|
|
|
|
* MEDIA_BUS_FMT\_ defines shared with v4l and media drivers.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
const u32 *bus_formats;
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @num_bus_formats: Size of @bus_formats array.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
unsigned int num_bus_formats;
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @bus_flags: Additional information (like pixel signal polarity) for
|
2019-01-12 08:42:39 +08:00
|
|
|
* the pixel data on the bus, using &enum drm_bus_flags values
|
|
|
|
* DRM_BUS_FLAGS\_.
|
2016-08-13 04:48:55 +08:00
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
u32 bus_flags;
|
|
|
|
|
2016-09-28 21:51:37 +08:00
|
|
|
/**
|
|
|
|
* @max_tmds_clock: Maximum TMDS clock rate supported by the
|
|
|
|
* sink in kHz. 0 means undefined.
|
|
|
|
*/
|
|
|
|
int max_tmds_clock;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dvi_dual: Dual-link DVI sink?
|
|
|
|
*/
|
|
|
|
bool dvi_dual;
|
|
|
|
|
2020-02-26 19:24:23 +08:00
|
|
|
/**
|
|
|
|
* @is_hdmi: True if the sink is an HDMI device.
|
|
|
|
*
|
|
|
|
* This field shall be used instead of calling
|
|
|
|
* drm_detect_hdmi_monitor() when possible.
|
|
|
|
*/
|
|
|
|
bool is_hdmi;
|
|
|
|
|
2023-05-30 17:08:13 +08:00
|
|
|
/**
|
|
|
|
* @has_audio: True if the sink supports audio.
|
|
|
|
*
|
|
|
|
* This field shall be used instead of calling
|
|
|
|
* drm_detect_monitor_audio() when possible.
|
|
|
|
*/
|
|
|
|
bool has_audio;
|
|
|
|
|
2017-11-14 01:04:19 +08:00
|
|
|
/**
|
|
|
|
* @has_hdmi_infoframe: Does the sink support the HDMI infoframe?
|
|
|
|
*/
|
|
|
|
bool has_hdmi_infoframe;
|
|
|
|
|
2019-01-09 01:28:28 +08:00
|
|
|
/**
|
|
|
|
* @rgb_quant_range_selectable: Does the sink support selecting
|
|
|
|
* the RGB quantization range?
|
|
|
|
*/
|
|
|
|
bool rgb_quant_range_selectable;
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
2022-02-02 17:43:40 +08:00
|
|
|
* @edid_hdmi_rgb444_dc_modes: Mask of supported hdmi deep color modes
|
2022-01-20 23:16:12 +08:00
|
|
|
* in RGB 4:4:4. Even more stuff redundant with @bus_formats.
|
2016-08-13 04:48:55 +08:00
|
|
|
*/
|
2022-01-20 23:16:12 +08:00
|
|
|
u8 edid_hdmi_rgb444_dc_modes;
|
|
|
|
|
|
|
|
/**
|
2022-02-02 17:43:40 +08:00
|
|
|
* @edid_hdmi_ycbcr444_dc_modes: Mask of supported hdmi deep color
|
2022-01-20 23:16:12 +08:00
|
|
|
* modes in YCbCr 4:4:4. Even more stuff redundant with @bus_formats.
|
|
|
|
*/
|
|
|
|
u8 edid_hdmi_ycbcr444_dc_modes;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
/**
|
|
|
|
* @cea_rev: CEA revision of the HDMI sink.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
u8 cea_rev;
|
2017-03-13 19:24:01 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @hdmi: advance features of a HDMI sink.
|
|
|
|
*/
|
|
|
|
struct drm_hdmi_info hdmi;
|
2017-10-16 12:08:09 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @non_desktop: Non desktop display (HMD).
|
|
|
|
*/
|
|
|
|
bool non_desktop;
|
2020-03-11 07:16:51 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @monitor_range: Frequency range supported by monitor range descriptor
|
|
|
|
*/
|
|
|
|
struct drm_monitor_range_info monitor_range;
|
drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO
The VESA Organization Vendor-Specific Data Block, defined in VESA
DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
stream count and segment pixel overlap.
DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
describing how DisplayID sections may be embedded in EDID extension
blocks. DisplayID v2.0 does not have such a section, perhaps implying
that DisplayID v2.0 data should not be included in EDID extensions, but
rather in a "pure" DisplayID structure at its own DDC address pair
A4h/A5h, as described in VESA E-DDC Standard v1.3 chapter 3.
However, in practice, displays out in the field have embedded DisplayID
v2.0 data blocks in EDID extensions, including, in particular, some eDP
MSO displays, where a pure DisplayID structure is not available at all.
Parse the MSO data from the DisplayID data block. Do it as part of
drm_add_display_info(), extending it to parse also DisplayID data to
avoid requiring extra calls to update the information.
v2: Check for VESA OUI (Ville)
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/73ca2887e7b37880690f5c9ba4594c9cd1170669.1630419362.git.jani.nikula@intel.com
2021-08-31 22:17:33 +08:00
|
|
|
|
2022-07-19 17:56:58 +08:00
|
|
|
/**
|
|
|
|
* @luminance_range: Luminance range supported by panel
|
|
|
|
*/
|
|
|
|
struct drm_luminance_range_info luminance_range;
|
|
|
|
|
drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO
The VESA Organization Vendor-Specific Data Block, defined in VESA
DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
stream count and segment pixel overlap.
DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
describing how DisplayID sections may be embedded in EDID extension
blocks. DisplayID v2.0 does not have such a section, perhaps implying
that DisplayID v2.0 data should not be included in EDID extensions, but
rather in a "pure" DisplayID structure at its own DDC address pair
A4h/A5h, as described in VESA E-DDC Standard v1.3 chapter 3.
However, in practice, displays out in the field have embedded DisplayID
v2.0 data blocks in EDID extensions, including, in particular, some eDP
MSO displays, where a pure DisplayID structure is not available at all.
Parse the MSO data from the DisplayID data block. Do it as part of
drm_add_display_info(), extending it to parse also DisplayID data to
avoid requiring extra calls to update the information.
v2: Check for VESA OUI (Ville)
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/73ca2887e7b37880690f5c9ba4594c9cd1170669.1630419362.git.jani.nikula@intel.com
2021-08-31 22:17:33 +08:00
|
|
|
/**
|
|
|
|
* @mso_stream_count: eDP Multi-SST Operation (MSO) stream count from
|
|
|
|
* the DisplayID VESA vendor block. 0 for conventional Single-Stream
|
|
|
|
* Transport (SST), or 2 or 4 MSO streams.
|
|
|
|
*/
|
|
|
|
u8 mso_stream_count;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @mso_pixel_overlap: eDP MSO segment pixel overlap, 0-8 pixels.
|
|
|
|
*/
|
|
|
|
u8 mso_pixel_overlap;
|
2022-10-22 04:37:34 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @max_dsc_bpp: Maximum DSC target bitrate, if it is set to 0 the
|
|
|
|
* monitor's default value is used instead.
|
|
|
|
*/
|
|
|
|
u32 max_dsc_bpp;
|
2023-01-04 18:05:18 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @vics: Array of vics_len VICs. Internal to EDID parsing.
|
|
|
|
*/
|
|
|
|
u8 *vics;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @vics_len: Number of elements in vics. Internal to EDID parsing.
|
|
|
|
*/
|
|
|
|
int vics_len;
|
2023-01-04 18:05:27 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @quirks: EDID based quirks. Internal to EDID parsing.
|
|
|
|
*/
|
|
|
|
u32 quirks;
|
2016-08-13 04:48:50 +08:00
|
|
|
};
|
|
|
|
|
2016-08-13 04:48:55 +08:00
|
|
|
int drm_display_info_set_bus_formats(struct drm_display_info *info,
|
|
|
|
const u32 *formats,
|
|
|
|
unsigned int num_formats);
|
|
|
|
|
2019-06-19 18:17:51 +08:00
|
|
|
/**
|
|
|
|
* struct drm_connector_tv_margins - TV connector related margins
|
|
|
|
*
|
|
|
|
* Describes the margins in pixels to put around the image on TV
|
|
|
|
* connectors to deal with overscan.
|
|
|
|
*/
|
|
|
|
struct drm_connector_tv_margins {
|
|
|
|
/**
|
|
|
|
* @bottom: Bottom margin in pixels.
|
|
|
|
*/
|
|
|
|
unsigned int bottom;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @left: Left margin in pixels.
|
|
|
|
*/
|
|
|
|
unsigned int left;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @right: Right margin in pixels.
|
|
|
|
*/
|
|
|
|
unsigned int right;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @top: Top margin in pixels.
|
|
|
|
*/
|
|
|
|
unsigned int top;
|
|
|
|
};
|
|
|
|
|
2016-12-02 21:48:09 +08:00
|
|
|
/**
|
|
|
|
* struct drm_tv_connector_state - TV connector related states
|
2022-09-30 00:30:59 +08:00
|
|
|
* @select_subconnector: selected subconnector
|
2022-09-30 00:31:00 +08:00
|
|
|
* @subconnector: detected subconnector
|
2019-06-19 18:17:51 +08:00
|
|
|
* @margins: TV margins
|
2022-11-17 17:28:45 +08:00
|
|
|
* @legacy_mode: Legacy TV mode, driver specific value
|
2022-11-17 17:28:48 +08:00
|
|
|
* @mode: TV mode
|
2016-12-02 21:48:09 +08:00
|
|
|
* @brightness: brightness in percent
|
|
|
|
* @contrast: contrast in percent
|
|
|
|
* @flicker_reduction: flicker reduction in percent
|
|
|
|
* @overscan: overscan in percent
|
|
|
|
* @saturation: saturation in percent
|
|
|
|
* @hue: hue in percent
|
|
|
|
*/
|
|
|
|
struct drm_tv_connector_state {
|
2022-09-30 00:30:59 +08:00
|
|
|
enum drm_mode_subconnector select_subconnector;
|
2022-09-30 00:31:00 +08:00
|
|
|
enum drm_mode_subconnector subconnector;
|
2019-06-19 18:17:51 +08:00
|
|
|
struct drm_connector_tv_margins margins;
|
2022-11-17 17:28:45 +08:00
|
|
|
unsigned int legacy_mode;
|
2022-11-17 17:28:48 +08:00
|
|
|
unsigned int mode;
|
2016-12-02 21:48:09 +08:00
|
|
|
unsigned int brightness;
|
|
|
|
unsigned int contrast;
|
|
|
|
unsigned int flicker_reduction;
|
|
|
|
unsigned int overscan;
|
|
|
|
unsigned int saturation;
|
|
|
|
unsigned int hue;
|
|
|
|
};
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
/**
|
|
|
|
* struct drm_connector_state - mutable connector state
|
|
|
|
*/
|
|
|
|
struct drm_connector_state {
|
2018-07-09 16:40:04 +08:00
|
|
|
/** @connector: backpointer to the connector */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_connector *connector;
|
|
|
|
|
2016-09-01 00:09:04 +08:00
|
|
|
/**
|
|
|
|
* @crtc: CRTC to connect connector to, NULL if disabled.
|
|
|
|
*
|
|
|
|
* Do not change this directly, use drm_atomic_set_crtc_for_connector()
|
|
|
|
* instead.
|
|
|
|
*/
|
|
|
|
struct drm_crtc *crtc;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2018-07-09 16:40:04 +08:00
|
|
|
/**
|
|
|
|
* @best_encoder:
|
|
|
|
*
|
|
|
|
* Used by the atomic helpers to select the encoder, through the
|
|
|
|
* &drm_connector_helper_funcs.atomic_best_encoder or
|
|
|
|
* &drm_connector_helper_funcs.best_encoder callbacks.
|
2019-05-06 22:46:29 +08:00
|
|
|
*
|
2019-06-12 04:51:43 +08:00
|
|
|
* This is also used in the atomic helpers to map encoders to their
|
|
|
|
* current and previous connectors, see
|
2019-08-12 22:01:03 +08:00
|
|
|
* drm_atomic_get_old_connector_for_encoder() and
|
|
|
|
* drm_atomic_get_new_connector_for_encoder().
|
2019-06-12 04:51:43 +08:00
|
|
|
*
|
2019-05-06 22:46:29 +08:00
|
|
|
* NOTE: Atomic drivers must fill this out (either themselves or through
|
|
|
|
* helpers), for otherwise the GETCONNECTOR and GETENCODER IOCTLs will
|
|
|
|
* not return correct data to userspace.
|
2018-07-09 16:40:04 +08:00
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_encoder *best_encoder;
|
|
|
|
|
drm: Add a new connector atomic property for link status
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requirements of the mode. Black screen follows.
One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would
also conflict with the idea of making setcrtc asynchronous in the
future, returning before the actual mode setting and link training.
Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on
practical not theoretical capabilities. However, the changes for link
training are pretty drastic, all for the sake of error handling and
DP compliance, when the most common happy day scenario is the current
approach of link training at mode setting time, using the optimal
parameters for the mode. It is also not certain all hardware could do
this without the pipe on; not even all our hardware can do this. Some
of this can be solved, but not trivially.
Both of the above ideas also fail to address link degradation *during*
operation.
The solution is to add a new "link-status" connector property in order
to address link training failure in a way that:
a) changes the current happy day scenario as little as possible, to
avoid regressions, b) can be implemented the same way by all drm
drivers, c) is still opt-in for the drivers and userspace, and opting
out doesn't regress the user experience, d) doesn't prevent drivers
from implementing better or alternate approaches, possibly without
userspace involvement. And, of course, handles all the issues presented.
In the usual happy day scenario, this is always "good". If something
fails during or after a mode set, the kernel driver can set the link
status to "bad" and issue a hotplug uevent for userspace to have it
re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
again. If the theoretical capabilities of the link can't be reached,
the mode list is trimmed based on that.
v7 by Jani:
* Rebase, simplify set property while at it, checkpatch fix
v6:
* Fix a typo in kernel doc (Sean Paul)
v5:
* Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
v4:
* Add comments in kernel-doc format (Daniel Vetter)
* Update the kernel-doc for link-status (Sean Paul)
v3:
* Fixed a build error (Jani Saarinen)
v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
|
|
|
/**
|
|
|
|
* @link_status: Connector link_status to keep track of whether link is
|
|
|
|
* GOOD or BAD to notify userspace if retraining is necessary.
|
|
|
|
*/
|
|
|
|
enum drm_link_status link_status;
|
|
|
|
|
2018-07-09 16:40:04 +08:00
|
|
|
/** @state: backpointer to global drm_atomic_state */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_atomic_state *state;
|
2016-12-02 21:48:09 +08:00
|
|
|
|
2017-09-04 18:48:37 +08:00
|
|
|
/**
|
|
|
|
* @commit: Tracks the pending commit to prevent use-after-free conditions.
|
|
|
|
*
|
|
|
|
* Is only set when @crtc is NULL.
|
|
|
|
*/
|
|
|
|
struct drm_crtc_commit *commit;
|
|
|
|
|
2018-07-09 16:40:04 +08:00
|
|
|
/** @tv: TV connector state */
|
2016-12-02 21:48:09 +08:00
|
|
|
struct drm_tv_connector_state tv;
|
2017-05-01 21:37:53 +08:00
|
|
|
|
2019-06-12 22:50:19 +08:00
|
|
|
/**
|
|
|
|
* @self_refresh_aware:
|
|
|
|
*
|
|
|
|
* This tracks whether a connector is aware of the self refresh state.
|
|
|
|
* It should be set to true for those connector implementations which
|
|
|
|
* understand the self refresh state. This is needed since the crtc
|
|
|
|
* registers the self refresh helpers and it doesn't know if the
|
|
|
|
* connectors downstream have implemented self refresh entry/exit.
|
|
|
|
*
|
|
|
|
* Drivers should set this to true in atomic_check if they know how to
|
|
|
|
* handle self_refresh requests.
|
|
|
|
*/
|
|
|
|
bool self_refresh_aware;
|
|
|
|
|
2017-05-01 21:37:53 +08:00
|
|
|
/**
|
|
|
|
* @picture_aspect_ratio: Connector property to control the
|
|
|
|
* HDMI infoframe aspect ratio setting.
|
|
|
|
*
|
2017-05-01 21:37:54 +08:00
|
|
|
* The %DRM_MODE_PICTURE_ASPECT_\* values much match the
|
2017-05-01 21:37:53 +08:00
|
|
|
* values for &enum hdmi_picture_aspect
|
|
|
|
*/
|
|
|
|
enum hdmi_picture_aspect picture_aspect_ratio;
|
2017-05-01 21:37:54 +08:00
|
|
|
|
2018-05-15 21:59:27 +08:00
|
|
|
/**
|
|
|
|
* @content_type: Connector property to control the
|
|
|
|
* HDMI infoframe content type setting.
|
|
|
|
* The %DRM_MODE_CONTENT_TYPE_\* values much
|
|
|
|
* match the values.
|
|
|
|
*/
|
|
|
|
unsigned int content_type;
|
|
|
|
|
2019-08-01 19:41:14 +08:00
|
|
|
/**
|
|
|
|
* @hdcp_content_type: Connector property to pass the type of
|
|
|
|
* protected content. This is most commonly used for HDCP.
|
|
|
|
*/
|
|
|
|
unsigned int hdcp_content_type;
|
|
|
|
|
2017-05-01 21:37:54 +08:00
|
|
|
/**
|
|
|
|
* @scaling_mode: Connector property to control the
|
|
|
|
* upscaling, mostly used for built-in panels.
|
|
|
|
*/
|
|
|
|
unsigned int scaling_mode;
|
2018-01-09 03:55:37 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @content_protection: Connector property to request content
|
|
|
|
* protection. This is most commonly used for HDCP.
|
|
|
|
*/
|
|
|
|
unsigned int content_protection;
|
2017-03-30 00:42:32 +08:00
|
|
|
|
drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v13: Reorder the colorspace macros.
v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
|
|
|
/**
|
|
|
|
* @colorspace: State variable for Connector property to request
|
|
|
|
* colorspace change on Sink. This is most commonly used to switch
|
|
|
|
* to wider color gamuts like BT2020.
|
|
|
|
*/
|
2023-02-03 10:07:42 +08:00
|
|
|
enum drm_colorspace colorspace;
|
drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v13: Reorder the colorspace macros.
v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
|
|
|
|
2017-03-30 00:42:32 +08:00
|
|
|
/**
|
|
|
|
* @writeback_job: Writeback job for writeback connectors
|
|
|
|
*
|
2017-03-30 00:42:33 +08:00
|
|
|
* Holds the framebuffer and out-fence for a writeback connector. As
|
|
|
|
* the writeback completion may be asynchronous to the normal commit
|
|
|
|
* cycle, the writeback job lifetime is managed separately from the
|
|
|
|
* normal atomic state by this object.
|
2017-03-30 00:42:32 +08:00
|
|
|
*
|
|
|
|
* See also: drm_writeback_queue_job() and
|
|
|
|
* drm_writeback_signal_completion()
|
|
|
|
*/
|
|
|
|
struct drm_writeback_job *writeback_job;
|
2018-10-13 02:42:32 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @max_requested_bpc: Connector property to limit the maximum bit
|
|
|
|
* depth of the pixels.
|
|
|
|
*/
|
|
|
|
u8 max_requested_bpc;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @max_bpc: Connector max_bpc based on the requested max_bpc property
|
|
|
|
* and the connector bpc limitations obtained from edid.
|
|
|
|
*/
|
|
|
|
u8 max_bpc;
|
2019-05-16 22:10:06 +08:00
|
|
|
|
2021-10-06 04:23:13 +08:00
|
|
|
/**
|
|
|
|
* @privacy_screen_sw_state: See :ref:`Standard Connector
|
|
|
|
* Properties<standard_connector_properties>`
|
|
|
|
*/
|
|
|
|
enum drm_privacy_screen_status privacy_screen_sw_state;
|
|
|
|
|
2019-05-16 22:10:06 +08:00
|
|
|
/**
|
|
|
|
* @hdr_output_metadata:
|
|
|
|
* DRM blob property for HDR output metadata
|
|
|
|
*/
|
|
|
|
struct drm_property_blob *hdr_output_metadata;
|
2016-08-13 04:48:50 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct drm_connector_funcs - control connectors on a given device
|
|
|
|
*
|
|
|
|
* Each CRTC may have one or more connectors attached to it. The functions
|
|
|
|
* below allow the core DRM code to control connectors, enumerate available modes,
|
|
|
|
* etc.
|
|
|
|
*/
|
|
|
|
struct drm_connector_funcs {
|
|
|
|
/**
|
|
|
|
* @dpms:
|
|
|
|
*
|
|
|
|
* Legacy entry point to set the per-connector DPMS state. Legacy DPMS
|
|
|
|
* is exposed as a standard property on the connector, but diverted to
|
|
|
|
* this callback in the drm core. Note that atomic drivers don't
|
|
|
|
* implement the 4 level DPMS support on the connector any more, but
|
|
|
|
* instead only have an on/off "ACTIVE" property on the CRTC object.
|
|
|
|
*
|
2017-07-25 20:02:04 +08:00
|
|
|
* This hook is not used by atomic drivers, remapping of the legacy DPMS
|
|
|
|
* property is entirely handled in the DRM core.
|
2016-08-13 04:48:50 +08:00
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* 0 on success or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int (*dpms)(struct drm_connector *connector, int mode);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @reset:
|
|
|
|
*
|
|
|
|
* Reset connector hardware and software state to off. This function isn't
|
|
|
|
* called by the core directly, only through drm_mode_config_reset().
|
|
|
|
* It's not a helper hook only for historical reasons.
|
|
|
|
*
|
|
|
|
* Atomic drivers can use drm_atomic_helper_connector_reset() to reset
|
|
|
|
* atomic state using this hook.
|
|
|
|
*/
|
|
|
|
void (*reset)(struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @detect:
|
|
|
|
*
|
|
|
|
* Check to see if anything is attached to the connector. The parameter
|
|
|
|
* force is set to false whilst polling, true when checking the
|
|
|
|
* connector due to a user request. force can be used by the driver to
|
|
|
|
* avoid expensive, destructive operations during automated probing.
|
|
|
|
*
|
2016-11-30 04:56:30 +08:00
|
|
|
* This callback is optional, if not implemented the connector will be
|
|
|
|
* considered as always being attached.
|
|
|
|
*
|
2016-08-13 04:48:50 +08:00
|
|
|
* FIXME:
|
|
|
|
*
|
|
|
|
* Note that this hook is only called by the probe helper. It's not in
|
|
|
|
* the helper library vtable purely for historical reasons. The only DRM
|
|
|
|
* core entry point to probe connector state is @fill_modes.
|
|
|
|
*
|
2017-04-07 02:55:20 +08:00
|
|
|
* Note that the helper library will already hold
|
|
|
|
* &drm_mode_config.connection_mutex. Drivers which need to grab additional
|
|
|
|
* locks to avoid races with concurrent modeset changes need to use
|
|
|
|
* &drm_connector_helper_funcs.detect_ctx instead.
|
|
|
|
*
|
2021-06-16 22:15:29 +08:00
|
|
|
* Also note that this callback can be called no matter the
|
|
|
|
* state the connector is in. Drivers that need the underlying
|
|
|
|
* device to be powered to perform the detection will first need
|
|
|
|
* to make sure it's been properly enabled.
|
|
|
|
*
|
2016-08-13 04:48:50 +08:00
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* drm_connector_status indicating the connector's status.
|
|
|
|
*/
|
|
|
|
enum drm_connector_status (*detect)(struct drm_connector *connector,
|
|
|
|
bool force);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @force:
|
|
|
|
*
|
|
|
|
* This function is called to update internal encoder state when the
|
|
|
|
* connector is forced to a certain state by userspace, either through
|
|
|
|
* the sysfs interfaces or on the kernel cmdline. In that case the
|
|
|
|
* @detect callback isn't called.
|
|
|
|
*
|
|
|
|
* FIXME:
|
|
|
|
*
|
|
|
|
* Note that this hook is only called by the probe helper. It's not in
|
|
|
|
* the helper library vtable purely for historical reasons. The only DRM
|
|
|
|
* core entry point to probe connector state is @fill_modes.
|
|
|
|
*/
|
|
|
|
void (*force)(struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @fill_modes:
|
|
|
|
*
|
|
|
|
* Entry point for output detection and basic mode validation. The
|
|
|
|
* driver should reprobe the output if needed (e.g. when hotplug
|
2017-01-25 14:26:45 +08:00
|
|
|
* handling is unreliable), add all detected modes to &drm_connector.modes
|
2016-08-13 04:48:50 +08:00
|
|
|
* and filter out any the device can't support in any configuration. It
|
|
|
|
* also needs to filter out any modes wider or higher than the
|
|
|
|
* parameters max_width and max_height indicate.
|
|
|
|
*
|
|
|
|
* The drivers must also prune any modes no longer valid from
|
2017-01-25 14:26:45 +08:00
|
|
|
* &drm_connector.modes. Furthermore it must update
|
|
|
|
* &drm_connector.status and &drm_connector.edid. If no EDID has been
|
|
|
|
* received for this output connector->edid must be NULL.
|
2016-08-13 04:48:50 +08:00
|
|
|
*
|
|
|
|
* Drivers using the probe helpers should use
|
2018-07-09 16:40:05 +08:00
|
|
|
* drm_helper_probe_single_connector_modes() to implement this
|
2016-08-13 04:48:50 +08:00
|
|
|
* function.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
2017-01-25 14:26:45 +08:00
|
|
|
* The number of modes detected and filled into &drm_connector.modes.
|
2016-08-13 04:48:50 +08:00
|
|
|
*/
|
|
|
|
int (*fill_modes)(struct drm_connector *connector, uint32_t max_width, uint32_t max_height);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @set_property:
|
|
|
|
*
|
|
|
|
* This is the legacy entry point to update a property attached to the
|
|
|
|
* connector.
|
|
|
|
*
|
|
|
|
* This callback is optional if the driver does not support any legacy
|
2017-07-25 20:02:04 +08:00
|
|
|
* driver-private properties. For atomic drivers it is not used because
|
|
|
|
* property handling is done entirely in the DRM core.
|
2016-08-13 04:48:50 +08:00
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* 0 on success or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int (*set_property)(struct drm_connector *connector, struct drm_property *property,
|
|
|
|
uint64_t val);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @late_register:
|
|
|
|
*
|
|
|
|
* This optional hook can be used to register additional userspace
|
|
|
|
* interfaces attached to the connector, light backlight control, i2c,
|
|
|
|
* DP aux or similar interfaces. It is called late in the driver load
|
|
|
|
* sequence from drm_connector_register() when registering all the
|
|
|
|
* core drm connector interfaces. Everything added from this callback
|
|
|
|
* should be unregistered in the early_unregister callback.
|
|
|
|
*
|
2017-01-25 14:26:45 +08:00
|
|
|
* This is called while holding &drm_connector.mutex.
|
2016-12-18 21:35:45 +08:00
|
|
|
*
|
2016-08-13 04:48:50 +08:00
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* 0 on success, or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int (*late_register)(struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @early_unregister:
|
|
|
|
*
|
|
|
|
* This optional hook should be used to unregister the additional
|
|
|
|
* userspace interfaces attached to the connector from
|
2016-10-10 01:07:00 +08:00
|
|
|
* late_register(). It is called from drm_connector_unregister(),
|
2016-08-13 04:48:50 +08:00
|
|
|
* early in the driver unload sequence to disable userspace access
|
|
|
|
* before data structures are torndown.
|
2016-12-18 21:35:45 +08:00
|
|
|
*
|
2017-01-25 14:26:45 +08:00
|
|
|
* This is called while holding &drm_connector.mutex.
|
2016-08-13 04:48:50 +08:00
|
|
|
*/
|
|
|
|
void (*early_unregister)(struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @destroy:
|
|
|
|
*
|
|
|
|
* Clean up connector resources. This is called at driver unload time
|
|
|
|
* through drm_mode_config_cleanup(). It can also be called at runtime
|
|
|
|
* when a connector is being hot-unplugged for drivers that support
|
|
|
|
* connector hotplugging (e.g. DisplayPort MST).
|
|
|
|
*/
|
|
|
|
void (*destroy)(struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_duplicate_state:
|
|
|
|
*
|
|
|
|
* Duplicate the current atomic state for this connector and return it.
|
2016-10-10 01:07:00 +08:00
|
|
|
* The core and helpers guarantee that any atomic state duplicated with
|
2016-08-13 04:48:50 +08:00
|
|
|
* this hook and still owned by the caller (i.e. not transferred to the
|
2017-01-25 14:26:45 +08:00
|
|
|
* driver by calling &drm_mode_config_funcs.atomic_commit) will be
|
|
|
|
* cleaned up by calling the @atomic_destroy_state hook in this
|
|
|
|
* structure.
|
2016-08-13 04:48:50 +08:00
|
|
|
*
|
2018-05-25 09:25:55 +08:00
|
|
|
* This callback is mandatory for atomic drivers.
|
|
|
|
*
|
2016-12-30 04:48:26 +08:00
|
|
|
* Atomic drivers which don't subclass &struct drm_connector_state should use
|
2016-08-13 04:48:50 +08:00
|
|
|
* drm_atomic_helper_connector_duplicate_state(). Drivers that subclass the
|
|
|
|
* state structure to extend it with driver-private state should use
|
|
|
|
* __drm_atomic_helper_connector_duplicate_state() to make sure shared state is
|
|
|
|
* duplicated in a consistent fashion across drivers.
|
|
|
|
*
|
2017-01-25 14:26:45 +08:00
|
|
|
* It is an error to call this hook before &drm_connector.state has been
|
2016-08-13 04:48:50 +08:00
|
|
|
* initialized correctly.
|
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* If the duplicate state references refcounted resources this hook must
|
|
|
|
* acquire a reference for each of them. The driver must release these
|
|
|
|
* references again in @atomic_destroy_state.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* Duplicated atomic state or NULL when the allocation failed.
|
|
|
|
*/
|
|
|
|
struct drm_connector_state *(*atomic_duplicate_state)(struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_destroy_state:
|
|
|
|
*
|
|
|
|
* Destroy a state duplicated with @atomic_duplicate_state and release
|
|
|
|
* or unreference all resources it references
|
2018-05-25 09:25:55 +08:00
|
|
|
*
|
|
|
|
* This callback is mandatory for atomic drivers.
|
2016-08-13 04:48:50 +08:00
|
|
|
*/
|
|
|
|
void (*atomic_destroy_state)(struct drm_connector *connector,
|
|
|
|
struct drm_connector_state *state);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_set_property:
|
|
|
|
*
|
|
|
|
* Decode a driver-private property value and store the decoded value
|
|
|
|
* into the passed-in state structure. Since the atomic core decodes all
|
|
|
|
* standardized properties (even for extensions beyond the core set of
|
|
|
|
* properties which might not be implemented by all drivers) this
|
|
|
|
* requires drivers to subclass the state structure.
|
|
|
|
*
|
|
|
|
* Such driver-private properties should really only be implemented for
|
|
|
|
* truly hardware/vendor specific state. Instead it is preferred to
|
|
|
|
* standardize atomic extension and decode the properties used to expose
|
|
|
|
* such an extension in the core.
|
|
|
|
*
|
|
|
|
* Do not call this function directly, use
|
|
|
|
* drm_atomic_connector_set_property() instead.
|
|
|
|
*
|
|
|
|
* This callback is optional if the driver does not support any
|
|
|
|
* driver-private atomic properties.
|
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* This function is called in the state assembly phase of atomic
|
|
|
|
* modesets, which can be aborted for any reason (including on
|
|
|
|
* userspace's request to just check whether a configuration would be
|
|
|
|
* possible). Drivers MUST NOT touch any persistent state (hardware or
|
|
|
|
* software) or data structures except the passed in @state parameter.
|
|
|
|
*
|
|
|
|
* Also since userspace controls in which order properties are set this
|
|
|
|
* function must not do any input validation (since the state update is
|
|
|
|
* incomplete and hence likely inconsistent). Instead any such input
|
|
|
|
* validation must be done in the various atomic_check callbacks.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* 0 if the property has been found, -EINVAL if the property isn't
|
|
|
|
* implemented by the driver (which shouldn't ever happen, the core only
|
|
|
|
* asks for properties attached to this connector). No other validation
|
|
|
|
* is allowed by the driver. The core already checks that the property
|
|
|
|
* value is within the range (integer, valid enum value, ...) the driver
|
|
|
|
* set when registering the property.
|
|
|
|
*/
|
|
|
|
int (*atomic_set_property)(struct drm_connector *connector,
|
|
|
|
struct drm_connector_state *state,
|
|
|
|
struct drm_property *property,
|
|
|
|
uint64_t val);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_get_property:
|
|
|
|
*
|
|
|
|
* Reads out the decoded driver-private property. This is used to
|
|
|
|
* implement the GETCONNECTOR IOCTL.
|
|
|
|
*
|
|
|
|
* Do not call this function directly, use
|
|
|
|
* drm_atomic_connector_get_property() instead.
|
|
|
|
*
|
|
|
|
* This callback is optional if the driver does not support any
|
|
|
|
* driver-private atomic properties.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* 0 on success, -EINVAL if the property isn't implemented by the
|
|
|
|
* driver (which shouldn't ever happen, the core only asks for
|
|
|
|
* properties attached to this connector).
|
|
|
|
*/
|
|
|
|
int (*atomic_get_property)(struct drm_connector *connector,
|
|
|
|
const struct drm_connector_state *state,
|
|
|
|
struct drm_property *property,
|
|
|
|
uint64_t *val);
|
2016-11-05 23:08:09 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_print_state:
|
|
|
|
*
|
2016-12-30 04:48:26 +08:00
|
|
|
* If driver subclasses &struct drm_connector_state, it should implement
|
2016-11-05 23:08:09 +08:00
|
|
|
* this optional hook for printing additional driver specific state.
|
|
|
|
*
|
|
|
|
* Do not call this directly, use drm_atomic_connector_print_state()
|
|
|
|
* instead.
|
|
|
|
*/
|
|
|
|
void (*atomic_print_state)(struct drm_printer *p,
|
|
|
|
const struct drm_connector_state *state);
|
2021-08-18 05:51:57 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @oob_hotplug_event:
|
|
|
|
*
|
|
|
|
* This will get called when a hotplug-event for a drm-connector
|
|
|
|
* has been received from a source outside the display driver / device.
|
|
|
|
*/
|
|
|
|
void (*oob_hotplug_event)(struct drm_connector *connector);
|
2022-02-05 08:13:41 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @debugfs_init:
|
|
|
|
*
|
|
|
|
* Allows connectors to create connector-specific debugfs files.
|
|
|
|
*/
|
|
|
|
void (*debugfs_init)(struct drm_connector *connector, struct dentry *root);
|
2016-08-13 04:48:50 +08:00
|
|
|
};
|
|
|
|
|
2019-06-19 18:17:48 +08:00
|
|
|
/**
|
|
|
|
* struct drm_cmdline_mode - DRM Mode passed through the kernel command-line
|
|
|
|
*
|
|
|
|
* Each connector can have an initial mode with additional options
|
|
|
|
* passed through the kernel command line. This structure allows to
|
|
|
|
* express those parameters and will be filled by the command-line
|
|
|
|
* parser.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_cmdline_mode {
|
2019-06-19 18:17:50 +08:00
|
|
|
/**
|
|
|
|
* @name:
|
|
|
|
*
|
|
|
|
* Name of the mode.
|
|
|
|
*/
|
|
|
|
char name[DRM_DISPLAY_MODE_LEN];
|
|
|
|
|
2019-06-19 18:17:48 +08:00
|
|
|
/**
|
|
|
|
* @specified:
|
|
|
|
*
|
|
|
|
* Has a mode been read from the command-line?
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool specified;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @refresh_specified:
|
|
|
|
*
|
|
|
|
* Did the mode have a preferred refresh rate?
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool refresh_specified;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @bpp_specified:
|
|
|
|
*
|
|
|
|
* Did the mode have a preferred BPP?
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool bpp_specified;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
2022-11-14 21:00:31 +08:00
|
|
|
/**
|
|
|
|
* @pixel_clock:
|
|
|
|
*
|
|
|
|
* Pixel Clock in kHz. Optional.
|
|
|
|
*/
|
|
|
|
unsigned int pixel_clock;
|
|
|
|
|
2019-06-19 18:17:48 +08:00
|
|
|
/**
|
|
|
|
* @xres:
|
|
|
|
*
|
|
|
|
* Active resolution on the X axis, in pixels.
|
|
|
|
*/
|
|
|
|
int xres;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @yres:
|
|
|
|
*
|
|
|
|
* Active resolution on the Y axis, in pixels.
|
|
|
|
*/
|
|
|
|
int yres;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @bpp:
|
|
|
|
*
|
|
|
|
* Bits per pixels for the mode.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
int bpp;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @refresh:
|
|
|
|
*
|
|
|
|
* Refresh rate, in Hertz.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
int refresh;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @rb:
|
|
|
|
*
|
|
|
|
* Do we need to use reduced blanking?
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool rb;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @interlace:
|
|
|
|
*
|
|
|
|
* The mode is interlaced.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool interlace;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @cvt:
|
|
|
|
*
|
|
|
|
* The timings will be calculated using the VESA Coordinated
|
|
|
|
* Video Timings instead of looking up the mode from a table.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool cvt;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @margins:
|
|
|
|
*
|
|
|
|
* Add margins to the mode calculation (1.8% of xres rounded
|
|
|
|
* down to 8 pixels and 1.8% of yres).
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool margins;
|
2019-06-19 18:17:48 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @force:
|
|
|
|
*
|
|
|
|
* Ignore the hotplug state of the connector, and force its
|
|
|
|
* state to one of the DRM_FORCE_* values.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
enum drm_connector_force force;
|
2019-06-19 18:17:51 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @rotation_reflection:
|
|
|
|
*
|
|
|
|
* Initial rotation and reflection of the mode setup from the
|
|
|
|
* command line. See DRM_MODE_ROTATE_* and
|
|
|
|
* DRM_MODE_REFLECT_*. The only rotations supported are
|
|
|
|
* DRM_MODE_ROTATE_0 and DRM_MODE_ROTATE_180.
|
|
|
|
*/
|
|
|
|
unsigned int rotation_reflection;
|
2019-06-19 18:17:51 +08:00
|
|
|
|
2019-11-18 23:51:30 +08:00
|
|
|
/**
|
|
|
|
* @panel_orientation:
|
|
|
|
*
|
|
|
|
* drm-connector "panel orientation" property override value,
|
|
|
|
* DRM_MODE_PANEL_ORIENTATION_UNKNOWN if not set.
|
|
|
|
*/
|
|
|
|
enum drm_panel_orientation panel_orientation;
|
|
|
|
|
2019-06-19 18:17:51 +08:00
|
|
|
/**
|
|
|
|
* @tv_margins: TV margins to apply to the mode.
|
|
|
|
*/
|
|
|
|
struct drm_connector_tv_margins tv_margins;
|
2022-11-17 17:28:51 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @tv_mode: TV mode standard. See DRM_MODE_TV_MODE_*.
|
|
|
|
*/
|
|
|
|
enum drm_connector_tv_mode tv_mode;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @tv_mode_specified:
|
|
|
|
*
|
|
|
|
* Did the mode have a preferred TV mode?
|
|
|
|
*/
|
|
|
|
bool tv_mode_specified;
|
2016-08-13 04:48:50 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct drm_connector - central DRM connector control structure
|
|
|
|
*
|
|
|
|
* Each connector may be connected to one or more CRTCs, or may be clonable by
|
|
|
|
* another connector if they can share a CRTC. Each connector also has a specific
|
|
|
|
* position in the broader display (referred to as a 'screen' though it could
|
|
|
|
* span multiple monitors).
|
|
|
|
*/
|
|
|
|
struct drm_connector {
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @dev: parent DRM device */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_device *dev;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @kdev: kernel device for sysfs attributes */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct device *kdev;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @attr: sysfs attributes */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct device_attribute *attr;
|
2021-08-18 05:51:55 +08:00
|
|
|
/**
|
|
|
|
* @fwnode: associated fwnode supplied by platform firmware
|
|
|
|
*
|
|
|
|
* Drivers can set this to associate a fwnode with a connector, drivers
|
|
|
|
* are expected to get a reference on the fwnode when setting this.
|
|
|
|
* drm_connector_cleanup() will call fwnode_handle_put() on this.
|
|
|
|
*/
|
|
|
|
struct fwnode_handle *fwnode;
|
2018-07-09 16:40:05 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @head:
|
|
|
|
*
|
|
|
|
* List of all connectors on a @dev, linked from
|
|
|
|
* &drm_mode_config.connector_list. Protected by
|
|
|
|
* &drm_mode_config.connector_list_lock, but please only use
|
|
|
|
* &drm_connector_list_iter to walk this list.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
struct list_head head;
|
|
|
|
|
2021-08-18 05:51:56 +08:00
|
|
|
/**
|
|
|
|
* @global_connector_list_entry:
|
|
|
|
*
|
|
|
|
* Connector entry in the global connector-list, used by
|
|
|
|
* drm_connector_find_by_fwnode().
|
|
|
|
*/
|
|
|
|
struct list_head global_connector_list_entry;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @base: base KMS object */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_mode_object base;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @name: human readable name, can be overwritten by the driver */
|
2016-08-13 04:48:50 +08:00
|
|
|
char *name;
|
|
|
|
|
2016-12-18 21:35:45 +08:00
|
|
|
/**
|
|
|
|
* @mutex: Lock for general connector state, but currently only protects
|
2017-01-25 14:26:45 +08:00
|
|
|
* @registered. Most of the connector state is still protected by
|
|
|
|
* &drm_mode_config.mutex.
|
2016-12-18 21:35:45 +08:00
|
|
|
*/
|
|
|
|
struct mutex mutex;
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
/**
|
|
|
|
* @index: Compacted connector index, which matches the position inside
|
|
|
|
* the mode_config.list for drivers not supporting hot-add/removing. Can
|
|
|
|
* be used as an array index. It is invariant over the lifetime of the
|
|
|
|
* connector.
|
|
|
|
*/
|
|
|
|
unsigned index;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @connector_type:
|
|
|
|
* one of the DRM_MODE_CONNECTOR_<foo> types from drm_mode.h
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
int connector_type;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @connector_type_id: index into connector type enum */
|
2016-08-13 04:48:50 +08:00
|
|
|
int connector_type_id;
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @interlace_allowed:
|
|
|
|
* Can this connector handle interlaced modes? Only used by
|
|
|
|
* drm_helper_probe_single_connector_modes() for mode filtering.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool interlace_allowed;
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @doublescan_allowed:
|
|
|
|
* Can this connector handle doublescan? Only used by
|
|
|
|
* drm_helper_probe_single_connector_modes() for mode filtering.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool doublescan_allowed;
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @stereo_allowed:
|
|
|
|
* Can this connector handle stereo modes? Only used by
|
|
|
|
* drm_helper_probe_single_connector_modes() for mode filtering.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
bool stereo_allowed;
|
2017-07-13 23:33:11 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @ycbcr_420_allowed : This bool indicates if this connector is
|
|
|
|
* capable of handling YCBCR 420 output. While parsing the EDID
|
2019-02-02 09:23:26 +08:00
|
|
|
* blocks it's very helpful to know if the source is capable of
|
2017-07-13 23:33:11 +08:00
|
|
|
* handling YCBCR 420 outputs.
|
|
|
|
*/
|
|
|
|
bool ycbcr_420_allowed;
|
|
|
|
|
2016-12-18 21:35:45 +08:00
|
|
|
/**
|
drm/atomic_helper: Stop modesets on unregistered connectors harder
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
|
|
|
* @registration_state: Is this connector initializing, exposed
|
|
|
|
* (registered) with userspace, or unregistered?
|
|
|
|
*
|
2016-12-18 21:35:45 +08:00
|
|
|
* Protected by @mutex.
|
|
|
|
*/
|
drm/atomic_helper: Stop modesets on unregistered connectors harder
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
|
|
|
enum drm_connector_registration_state registration_state;
|
2016-12-14 07:08:10 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @modes:
|
|
|
|
* Modes available on this connector (from fill_modes() + user).
|
2017-01-25 14:26:45 +08:00
|
|
|
* Protected by &drm_mode_config.mutex.
|
2016-12-14 07:08:10 +08:00
|
|
|
*/
|
2017-01-25 14:26:45 +08:00
|
|
|
struct list_head modes;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2016-12-14 07:08:10 +08:00
|
|
|
/**
|
|
|
|
* @status:
|
|
|
|
* One of the drm_connector_status enums (connected, not, or unknown).
|
2017-01-25 14:26:45 +08:00
|
|
|
* Protected by &drm_mode_config.mutex.
|
2016-12-14 07:08:10 +08:00
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
enum drm_connector_status status;
|
|
|
|
|
2016-12-14 07:08:10 +08:00
|
|
|
/**
|
|
|
|
* @probed_modes:
|
|
|
|
* These are modes added by probing with DDC or the BIOS, before
|
2017-01-25 14:26:45 +08:00
|
|
|
* filtering is applied. Used by the probe helpers. Protected by
|
|
|
|
* &drm_mode_config.mutex.
|
2016-12-14 07:08:10 +08:00
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
struct list_head probed_modes;
|
|
|
|
|
2016-08-13 04:48:53 +08:00
|
|
|
/**
|
|
|
|
* @display_info: Display information is filled from EDID information
|
|
|
|
* when a display is detected. For non hot-pluggable displays such as
|
|
|
|
* flat panels in embedded systems, the driver should initialize the
|
2017-01-25 14:26:45 +08:00
|
|
|
* &drm_display_info.width_mm and &drm_display_info.height_mm fields
|
|
|
|
* with the physical size of the display.
|
2016-12-14 07:08:10 +08:00
|
|
|
*
|
2017-01-25 14:26:45 +08:00
|
|
|
* Protected by &drm_mode_config.mutex.
|
2016-08-13 04:48:53 +08:00
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_display_info display_info;
|
2018-07-09 16:40:05 +08:00
|
|
|
|
|
|
|
/** @funcs: connector control functions */
|
2016-08-13 04:48:50 +08:00
|
|
|
const struct drm_connector_funcs *funcs;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @edid_blob_ptr: DRM property containing EDID if present. Protected by
|
|
|
|
* &drm_mode_config.mutex. This should be updated only by calling
|
2018-07-09 16:40:06 +08:00
|
|
|
* drm_connector_update_edid_property().
|
2018-07-09 16:40:05 +08:00
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_property_blob *edid_blob_ptr;
|
2018-07-09 16:40:05 +08:00
|
|
|
|
|
|
|
/** @properties: property tracking for this connector */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_object_properties properties;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @scaling_mode_property: Optional atomic property to control the
|
|
|
|
* upscaling. See drm_connector_attach_content_protection_property().
|
|
|
|
*/
|
2017-05-01 21:37:54 +08:00
|
|
|
struct drm_property *scaling_mode_property;
|
|
|
|
|
2018-09-18 21:55:20 +08:00
|
|
|
/**
|
|
|
|
* @vrr_capable_property: Optional property to help userspace
|
|
|
|
* query hardware support for variable refresh rate on a connector.
|
|
|
|
* connector. Drivers can add the property to a connector by
|
|
|
|
* calling drm_connector_attach_vrr_capable_property().
|
|
|
|
*
|
|
|
|
* This should be updated only by calling
|
|
|
|
* drm_connector_set_vrr_capable_property().
|
|
|
|
*/
|
|
|
|
struct drm_property *vrr_capable_property;
|
|
|
|
|
drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.
v13: Reorder the colorspace macros.
v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
|
|
|
/**
|
|
|
|
* @colorspace_property: Connector property to set the suitable
|
|
|
|
* colorspace supported by the sink.
|
|
|
|
*/
|
|
|
|
struct drm_property *colorspace_property;
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
/**
|
|
|
|
* @path_blob_ptr:
|
|
|
|
*
|
2018-07-09 16:40:05 +08:00
|
|
|
* DRM blob property data for the DP MST path property. This should only
|
2018-07-09 16:40:08 +08:00
|
|
|
* be updated by calling drm_connector_set_path_property().
|
2016-08-13 04:48:50 +08:00
|
|
|
*/
|
|
|
|
struct drm_property_blob *path_blob_ptr;
|
|
|
|
|
2018-10-13 02:42:32 +08:00
|
|
|
/**
|
|
|
|
* @max_bpc_property: Default connector property for the max bpc to be
|
|
|
|
* driven out of the connector.
|
|
|
|
*/
|
|
|
|
struct drm_property *max_bpc_property;
|
|
|
|
|
2021-10-06 04:23:17 +08:00
|
|
|
/** @privacy_screen: drm_privacy_screen for this connector, or NULL. */
|
|
|
|
struct drm_privacy_screen *privacy_screen;
|
|
|
|
|
|
|
|
/** @privacy_screen_notifier: privacy-screen notifier_block */
|
|
|
|
struct notifier_block privacy_screen_notifier;
|
|
|
|
|
2021-10-06 04:23:13 +08:00
|
|
|
/**
|
|
|
|
* @privacy_screen_sw_state_property: Optional atomic property for the
|
|
|
|
* connector to control the integrated privacy screen.
|
|
|
|
*/
|
|
|
|
struct drm_property *privacy_screen_sw_state_property;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @privacy_screen_hw_state_property: Optional atomic property for the
|
|
|
|
* connector to report the actual integrated privacy screen state.
|
|
|
|
*/
|
|
|
|
struct drm_property *privacy_screen_hw_state_property;
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
#define DRM_CONNECTOR_POLL_HPD (1 << 0)
|
|
|
|
#define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
|
|
|
|
#define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
|
|
|
|
|
2016-08-13 04:48:53 +08:00
|
|
|
/**
|
|
|
|
* @polled:
|
|
|
|
*
|
|
|
|
* Connector polling mode, a combination of
|
|
|
|
*
|
|
|
|
* DRM_CONNECTOR_POLL_HPD
|
|
|
|
* The connector generates hotplug events and doesn't need to be
|
|
|
|
* periodically polled. The CONNECT and DISCONNECT flags must not
|
|
|
|
* be set together with the HPD flag.
|
|
|
|
*
|
|
|
|
* DRM_CONNECTOR_POLL_CONNECT
|
|
|
|
* Periodically poll the connector for connection.
|
|
|
|
*
|
|
|
|
* DRM_CONNECTOR_POLL_DISCONNECT
|
2018-07-09 16:40:05 +08:00
|
|
|
* Periodically poll the connector for disconnection, without
|
|
|
|
* causing flickering even when the connector is in use. DACs should
|
|
|
|
* rarely do this without a lot of testing.
|
2016-08-13 04:48:53 +08:00
|
|
|
*
|
|
|
|
* Set to 0 for connectors that don't support connection status
|
|
|
|
* discovery.
|
|
|
|
*/
|
|
|
|
uint8_t polled;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @dpms: Current dpms state. For legacy drivers the
|
|
|
|
* &drm_connector_funcs.dpms callback must update this. For atomic
|
|
|
|
* drivers, this is handled by the core atomic code, and drivers must
|
|
|
|
* only take &drm_crtc_state.active into account.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
int dpms;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @helper_private: mid-layer private data */
|
2016-08-13 04:48:50 +08:00
|
|
|
const struct drm_connector_helper_funcs *helper_private;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @cmdline_mode: mode line parsed from the kernel cmdline for this connector */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_cmdline_mode cmdline_mode;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @force: a DRM_FORCE_<foo> state for forced mode sets */
|
2016-08-13 04:48:50 +08:00
|
|
|
enum drm_connector_force force;
|
2022-10-24 20:33:37 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @edid_override: Override EDID set via debugfs.
|
|
|
|
*
|
|
|
|
* Do not modify or access outside of the drm_edid_override_* family of
|
|
|
|
* functions.
|
|
|
|
*/
|
|
|
|
const struct drm_edid *edid_override;
|
|
|
|
|
2022-06-29 17:27:49 +08:00
|
|
|
/**
|
2022-10-24 20:33:37 +08:00
|
|
|
* @edid_override_mutex: Protect access to edid_override.
|
2022-06-29 17:27:49 +08:00
|
|
|
*/
|
2022-10-24 20:33:37 +08:00
|
|
|
struct mutex edid_override_mutex;
|
|
|
|
|
2020-06-30 08:26:59 +08:00
|
|
|
/** @epoch_counter: used to detect any other changes in connector, besides status */
|
|
|
|
u64 epoch_counter;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
2019-09-14 07:28:57 +08:00
|
|
|
* @possible_encoders: Bit mask of encoders that can drive this
|
|
|
|
* connector, drm_encoder_index() determines the index into the bitfield
|
|
|
|
* and the bits are set with drm_connector_attach_encoder().
|
2018-07-09 16:40:05 +08:00
|
|
|
*/
|
2019-09-14 07:28:57 +08:00
|
|
|
u32 possible_encoders;
|
2018-07-09 16:40:05 +08:00
|
|
|
|
2017-11-09 04:30:07 +08:00
|
|
|
/**
|
|
|
|
* @encoder: Currently bound encoder driving this connector, if any.
|
|
|
|
* Only really meaningful for non-atomic drivers. Atomic drivers should
|
|
|
|
* instead look at &drm_connector_state.best_encoder, and in case they
|
|
|
|
* need the CRTC driving this output, &drm_connector_state.crtc.
|
|
|
|
*/
|
|
|
|
struct drm_encoder *encoder;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
|
|
|
#define MAX_ELD_BYTES 128
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @eld: EDID-like data, if present */
|
2016-08-13 04:48:50 +08:00
|
|
|
uint8_t eld[MAX_ELD_BYTES];
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @latency_present: AV delay info from ELD, if found */
|
2016-08-13 04:48:50 +08:00
|
|
|
bool latency_present[2];
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @video_latency: Video latency info from ELD, if found.
|
|
|
|
* [0]: progressive, [1]: interlaced
|
|
|
|
*/
|
|
|
|
int video_latency[2];
|
|
|
|
/**
|
|
|
|
* @audio_latency: audio latency info from ELD, if found
|
|
|
|
* [0]: progressive, [1]: interlaced
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
int audio_latency[2];
|
2019-07-27 01:22:55 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @ddc: associated ddc adapter.
|
|
|
|
* A connector usually has its associated ddc adapter. If a driver uses
|
|
|
|
* this field, then an appropriate symbolic link is created in connector
|
|
|
|
* sysfs directory to make it easy for the user to tell which i2c
|
|
|
|
* adapter is for a particular display.
|
2019-07-27 01:22:56 +08:00
|
|
|
*
|
|
|
|
* The field should be set by calling drm_connector_init_with_ddc().
|
2019-07-27 01:22:55 +08:00
|
|
|
*/
|
|
|
|
struct i2c_adapter *ddc;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @null_edid_counter: track sinks that give us all zeros for the EDID.
|
|
|
|
* Needed to workaround some HW bugs where we get all 0s
|
|
|
|
*/
|
|
|
|
int null_edid_counter;
|
|
|
|
|
|
|
|
/** @bad_edid_counter: track sinks that give us an EDID with invalid checksum */
|
2016-08-13 04:48:50 +08:00
|
|
|
unsigned bad_edid_counter;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/**
|
|
|
|
* @edid_corrupt: Indicates whether the last read EDID was corrupt. Used
|
|
|
|
* in Displayport compliance testing - Displayport Link CTS Core 1.2
|
|
|
|
* rev1.1 4.2.2.6
|
2016-08-13 04:48:50 +08:00
|
|
|
*/
|
|
|
|
bool edid_corrupt;
|
2020-02-12 00:08:32 +08:00
|
|
|
/**
|
|
|
|
* @real_edid_checksum: real edid checksum for corrupted edid block.
|
|
|
|
* Required in Displayport 1.4 compliance testing
|
|
|
|
* rev1.1 4.2.2.6
|
|
|
|
*/
|
|
|
|
u8 real_edid_checksum;
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @debugfs_entry: debugfs directory for this connector */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct dentry *debugfs_entry;
|
|
|
|
|
2017-03-28 23:53:48 +08:00
|
|
|
/**
|
|
|
|
* @state:
|
|
|
|
*
|
|
|
|
* Current atomic state for this connector.
|
|
|
|
*
|
2018-07-09 16:40:05 +08:00
|
|
|
* This is protected by &drm_mode_config.connection_mutex. Note that
|
2017-03-28 23:53:48 +08:00
|
|
|
* nonblocking atomic commits access the current connector state without
|
|
|
|
* taking locks. Either by going through the &struct drm_atomic_state
|
2017-07-19 22:39:20 +08:00
|
|
|
* pointers, see for_each_oldnew_connector_in_state(),
|
2017-03-28 23:53:48 +08:00
|
|
|
* for_each_old_connector_in_state() and
|
|
|
|
* for_each_new_connector_in_state(). Or through careful ordering of
|
|
|
|
* atomic commit operations as implemented in the atomic helpers, see
|
|
|
|
* &struct drm_crtc_commit.
|
|
|
|
*/
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_connector_state *state;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/* DisplayID bits. FIXME: Extract into a substruct? */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @tile_blob_ptr:
|
|
|
|
*
|
|
|
|
* DRM blob property data for the tile property (used mostly by DP MST).
|
|
|
|
* This is meant for screens which are driven through separate display
|
|
|
|
* pipelines represented by &drm_crtc, which might not be running with
|
|
|
|
* genlocked clocks. For tiled panels which are genlocked, like
|
|
|
|
* dual-link LVDS or dual-link DSI, the driver should try to not expose
|
|
|
|
* the tiling and virtualize both &drm_crtc and &drm_plane if needed.
|
|
|
|
*
|
|
|
|
* This should only be updated by calling
|
2018-07-09 16:40:08 +08:00
|
|
|
* drm_connector_set_tile_property().
|
2018-07-09 16:40:05 +08:00
|
|
|
*/
|
|
|
|
struct drm_property_blob *tile_blob_ptr;
|
|
|
|
|
|
|
|
/** @has_tile: is this connector connected to a tiled monitor */
|
2016-08-13 04:48:50 +08:00
|
|
|
bool has_tile;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @tile_group: tile group for the connected monitor */
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_tile_group *tile_group;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @tile_is_single_monitor: whether the tile is one monitor housing */
|
2016-08-13 04:48:50 +08:00
|
|
|
bool tile_is_single_monitor;
|
|
|
|
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @num_h_tile: number of horizontal tiles in the tile group */
|
|
|
|
/** @num_v_tile: number of vertical tiles in the tile group */
|
2016-08-13 04:48:50 +08:00
|
|
|
uint8_t num_h_tile, num_v_tile;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @tile_h_loc: horizontal location of this tile */
|
|
|
|
/** @tile_v_loc: vertical location of this tile */
|
2016-08-13 04:48:50 +08:00
|
|
|
uint8_t tile_h_loc, tile_v_loc;
|
2018-07-09 16:40:05 +08:00
|
|
|
/** @tile_h_size: horizontal size of this tile. */
|
|
|
|
/** @tile_v_size: vertical size of this tile. */
|
2016-08-13 04:48:50 +08:00
|
|
|
uint16_t tile_h_size, tile_v_size;
|
2017-12-05 04:48:18 +08:00
|
|
|
|
|
|
|
/**
|
2017-12-13 20:49:36 +08:00
|
|
|
* @free_node:
|
2017-12-05 04:48:18 +08:00
|
|
|
*
|
2018-07-09 16:40:05 +08:00
|
|
|
* List used only by &drm_connector_list_iter to be able to clean up a
|
2017-12-13 20:49:36 +08:00
|
|
|
* connector from any context, in conjunction with
|
|
|
|
* &drm_mode_config.connector_free_work.
|
2017-12-05 04:48:18 +08:00
|
|
|
*/
|
2017-12-13 20:49:36 +08:00
|
|
|
struct llist_node free_node;
|
2019-05-16 22:10:06 +08:00
|
|
|
|
2019-06-04 19:17:02 +08:00
|
|
|
/** @hdr_sink_metadata: HDR Metadata Information read from sink */
|
2019-05-16 22:10:06 +08:00
|
|
|
struct hdr_sink_metadata hdr_sink_metadata;
|
2016-08-13 04:48:50 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
#define obj_to_connector(x) container_of(x, struct drm_connector, base)
|
|
|
|
|
|
|
|
int drm_connector_init(struct drm_device *dev,
|
|
|
|
struct drm_connector *connector,
|
|
|
|
const struct drm_connector_funcs *funcs,
|
|
|
|
int connector_type);
|
2019-07-27 01:22:56 +08:00
|
|
|
int drm_connector_init_with_ddc(struct drm_device *dev,
|
|
|
|
struct drm_connector *connector,
|
|
|
|
const struct drm_connector_funcs *funcs,
|
|
|
|
int connector_type,
|
|
|
|
struct i2c_adapter *ddc);
|
2022-07-12 01:38:39 +08:00
|
|
|
int drmm_connector_init(struct drm_device *dev,
|
|
|
|
struct drm_connector *connector,
|
|
|
|
const struct drm_connector_funcs *funcs,
|
|
|
|
int connector_type,
|
|
|
|
struct i2c_adapter *ddc);
|
2018-10-02 19:10:40 +08:00
|
|
|
void drm_connector_attach_edid_property(struct drm_connector *connector);
|
2016-08-13 04:48:50 +08:00
|
|
|
int drm_connector_register(struct drm_connector *connector);
|
|
|
|
void drm_connector_unregister(struct drm_connector *connector);
|
2018-07-09 16:40:07 +08:00
|
|
|
int drm_connector_attach_encoder(struct drm_connector *connector,
|
2016-08-13 04:48:50 +08:00
|
|
|
struct drm_encoder *encoder);
|
|
|
|
|
|
|
|
void drm_connector_cleanup(struct drm_connector *connector);
|
2018-06-27 03:47:10 +08:00
|
|
|
|
|
|
|
static inline unsigned int drm_connector_index(const struct drm_connector *connector)
|
2016-08-13 04:48:50 +08:00
|
|
|
{
|
|
|
|
return connector->index;
|
|
|
|
}
|
|
|
|
|
2018-06-27 03:47:10 +08:00
|
|
|
static inline u32 drm_connector_mask(const struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
return 1 << connector->index;
|
|
|
|
}
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
/**
|
|
|
|
* drm_connector_lookup - lookup connector object
|
|
|
|
* @dev: DRM device
|
2017-11-09 07:35:04 +08:00
|
|
|
* @file_priv: drm file to check for lease against.
|
2016-08-13 04:48:50 +08:00
|
|
|
* @id: connector object id
|
|
|
|
*
|
|
|
|
* This function looks up the connector object specified by id
|
|
|
|
* add takes a reference to it.
|
|
|
|
*/
|
|
|
|
static inline struct drm_connector *drm_connector_lookup(struct drm_device *dev,
|
2017-03-15 14:25:07 +08:00
|
|
|
struct drm_file *file_priv,
|
2016-08-13 04:48:50 +08:00
|
|
|
uint32_t id)
|
|
|
|
{
|
|
|
|
struct drm_mode_object *mo;
|
2017-03-15 14:25:07 +08:00
|
|
|
mo = drm_mode_object_find(dev, file_priv, id, DRM_MODE_OBJECT_CONNECTOR);
|
2016-08-13 04:48:50 +08:00
|
|
|
return mo ? obj_to_connector(mo) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2017-02-28 22:46:39 +08:00
|
|
|
* drm_connector_get - acquire a connector reference
|
|
|
|
* @connector: DRM connector
|
2016-08-13 04:48:50 +08:00
|
|
|
*
|
|
|
|
* This function increments the connector's refcount.
|
|
|
|
*/
|
2017-02-28 22:46:39 +08:00
|
|
|
static inline void drm_connector_get(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
drm_mode_object_get(&connector->base);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_connector_put - release a connector reference
|
|
|
|
* @connector: DRM connector
|
|
|
|
*
|
|
|
|
* This function decrements the connector's reference count and frees the
|
|
|
|
* object if the reference count drops to zero.
|
|
|
|
*/
|
|
|
|
static inline void drm_connector_put(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
drm_mode_object_put(&connector->base);
|
|
|
|
}
|
|
|
|
|
drm/atomic_helper: Stop modesets on unregistered connectors harder
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
|
|
|
/**
|
|
|
|
* drm_connector_is_unregistered - has the connector been unregistered from
|
|
|
|
* userspace?
|
|
|
|
* @connector: DRM connector
|
|
|
|
*
|
|
|
|
* Checks whether or not @connector has been unregistered from userspace.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* True if the connector was unregistered, false if the connector is
|
|
|
|
* registered or has not yet been registered with userspace.
|
|
|
|
*/
|
|
|
|
static inline bool
|
|
|
|
drm_connector_is_unregistered(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
return READ_ONCE(connector->registration_state) ==
|
|
|
|
DRM_CONNECTOR_UNREGISTERED;
|
|
|
|
}
|
|
|
|
|
2021-08-18 05:51:57 +08:00
|
|
|
void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode);
|
2020-02-26 19:24:22 +08:00
|
|
|
const char *drm_get_connector_type_name(unsigned int connector_type);
|
2016-08-13 04:48:50 +08:00
|
|
|
const char *drm_get_connector_status_name(enum drm_connector_status status);
|
|
|
|
const char *drm_get_subpixel_order_name(enum subpixel_order order);
|
|
|
|
const char *drm_get_dpms_name(int val);
|
|
|
|
const char *drm_get_dvi_i_subconnector_name(int val);
|
|
|
|
const char *drm_get_dvi_i_select_name(int val);
|
2022-11-17 17:28:48 +08:00
|
|
|
const char *drm_get_tv_mode_name(int val);
|
2016-08-13 04:48:50 +08:00
|
|
|
const char *drm_get_tv_subconnector_name(int val);
|
|
|
|
const char *drm_get_tv_select_name(int val);
|
2020-04-24 20:50:51 +08:00
|
|
|
const char *drm_get_dp_subconnector_name(int val);
|
2018-01-09 03:55:37 +08:00
|
|
|
const char *drm_get_content_protection_name(int val);
|
2019-08-01 19:41:14 +08:00
|
|
|
const char *drm_get_hdcp_content_type_name(int val);
|
2016-08-13 04:48:50 +08:00
|
|
|
|
2022-11-17 17:28:50 +08:00
|
|
|
int drm_get_tv_mode_from_name(const char *name, size_t len);
|
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
int drm_mode_create_dvi_i_properties(struct drm_device *dev);
|
2020-04-24 20:50:51 +08:00
|
|
|
void drm_connector_attach_dp_subconnector_property(struct drm_connector *connector);
|
|
|
|
|
2018-12-06 22:24:37 +08:00
|
|
|
int drm_mode_create_tv_margin_properties(struct drm_device *dev);
|
2022-11-17 17:28:47 +08:00
|
|
|
int drm_mode_create_tv_properties_legacy(struct drm_device *dev,
|
|
|
|
unsigned int num_modes,
|
|
|
|
const char * const modes[]);
|
2022-11-17 17:28:48 +08:00
|
|
|
int drm_mode_create_tv_properties(struct drm_device *dev,
|
|
|
|
unsigned int supported_tv_modes);
|
2018-12-06 22:24:37 +08:00
|
|
|
void drm_connector_attach_tv_margin_properties(struct drm_connector *conn);
|
2016-08-13 04:48:50 +08:00
|
|
|
int drm_mode_create_scaling_mode_property(struct drm_device *dev);
|
2018-05-15 21:59:27 +08:00
|
|
|
int drm_connector_attach_content_type_property(struct drm_connector *dev);
|
2017-05-01 21:37:54 +08:00
|
|
|
int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
|
|
|
|
u32 scaling_mode_mask);
|
2018-09-18 21:55:20 +08:00
|
|
|
int drm_connector_attach_vrr_capable_property(
|
|
|
|
struct drm_connector *connector);
|
2021-04-30 17:44:50 +08:00
|
|
|
int drm_connector_attach_colorspace_property(struct drm_connector *connector);
|
2021-04-30 17:44:47 +08:00
|
|
|
int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *connector);
|
2021-04-30 17:44:48 +08:00
|
|
|
bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state *old_state,
|
|
|
|
struct drm_connector_state *new_state);
|
2016-08-13 04:48:50 +08:00
|
|
|
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
|
2022-11-30 04:16:31 +08:00
|
|
|
int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
|
|
|
|
u32 supported_colorspaces);
|
|
|
|
int drm_mode_create_dp_colorspace_property(struct drm_connector *connector,
|
|
|
|
u32 supported_colorspaces);
|
2018-05-15 21:59:27 +08:00
|
|
|
int drm_mode_create_content_type_property(struct drm_device *dev);
|
2016-08-13 04:48:50 +08:00
|
|
|
int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
|
|
|
|
|
2018-07-09 16:40:08 +08:00
|
|
|
int drm_connector_set_path_property(struct drm_connector *connector,
|
|
|
|
const char *path);
|
|
|
|
int drm_connector_set_tile_property(struct drm_connector *connector);
|
2018-07-09 16:40:06 +08:00
|
|
|
int drm_connector_update_edid_property(struct drm_connector *connector,
|
|
|
|
const struct edid *edid);
|
2018-07-09 16:40:08 +08:00
|
|
|
void drm_connector_set_link_status_property(struct drm_connector *connector,
|
|
|
|
uint64_t link_status);
|
2018-09-18 21:55:20 +08:00
|
|
|
void drm_connector_set_vrr_capable_property(
|
|
|
|
struct drm_connector *connector, bool capable);
|
2020-01-05 23:51:19 +08:00
|
|
|
int drm_connector_set_panel_orientation(
|
|
|
|
struct drm_connector *connector,
|
|
|
|
enum drm_panel_orientation panel_orientation);
|
|
|
|
int drm_connector_set_panel_orientation_with_quirk(
|
|
|
|
struct drm_connector *connector,
|
|
|
|
enum drm_panel_orientation panel_orientation,
|
|
|
|
int width, int height);
|
2022-06-09 15:27:15 +08:00
|
|
|
int drm_connector_set_orientation_from_panel(
|
|
|
|
struct drm_connector *connector,
|
|
|
|
struct drm_panel *panel);
|
2018-10-13 02:42:32 +08:00
|
|
|
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
|
|
|
|
int min, int max);
|
2021-10-06 04:23:13 +08:00
|
|
|
void drm_connector_create_privacy_screen_properties(struct drm_connector *conn);
|
|
|
|
void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
|
2021-10-06 04:23:17 +08:00
|
|
|
void drm_connector_attach_privacy_screen_provider(
|
|
|
|
struct drm_connector *connector, struct drm_privacy_screen *priv);
|
|
|
|
void drm_connector_update_privacy_screen(const struct drm_connector_state *connector_state);
|
2016-09-01 00:09:04 +08:00
|
|
|
|
2016-11-14 19:58:24 +08:00
|
|
|
/**
|
|
|
|
* struct drm_tile_group - Tile group metadata
|
|
|
|
* @refcount: reference count
|
|
|
|
* @dev: DRM device
|
|
|
|
* @id: tile group id exposed to userspace
|
|
|
|
* @group_data: Sink-private data identifying this group
|
|
|
|
*
|
|
|
|
* @group_data corresponds to displayid vend/prod/serial for external screens
|
|
|
|
* with an EDID.
|
|
|
|
*/
|
|
|
|
struct drm_tile_group {
|
|
|
|
struct kref refcount;
|
|
|
|
struct drm_device *dev;
|
|
|
|
int id;
|
|
|
|
u8 group_data[8];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
|
2020-03-14 00:20:46 +08:00
|
|
|
const char topology[8]);
|
2016-11-14 19:58:24 +08:00
|
|
|
struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
|
2020-03-14 00:20:46 +08:00
|
|
|
const char topology[8]);
|
2016-11-14 19:58:24 +08:00
|
|
|
void drm_mode_put_tile_group(struct drm_device *dev,
|
|
|
|
struct drm_tile_group *tg);
|
|
|
|
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
/**
|
|
|
|
* struct drm_connector_list_iter - connector_list iterator
|
|
|
|
*
|
|
|
|
* This iterator tracks state needed to be able to walk the connector_list
|
|
|
|
* within struct drm_mode_config. Only use together with
|
2017-02-28 22:46:43 +08:00
|
|
|
* drm_connector_list_iter_begin(), drm_connector_list_iter_end() and
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
* drm_connector_list_iter_next() respectively the convenience macro
|
|
|
|
* drm_for_each_connector_iter().
|
2021-06-10 05:24:10 +08:00
|
|
|
*
|
|
|
|
* Note that the return value of drm_connector_list_iter_next() is only valid
|
|
|
|
* up to the next drm_connector_list_iter_next() or
|
|
|
|
* drm_connector_list_iter_end() call. If you want to use the connector later,
|
|
|
|
* then you need to grab your own reference first using drm_connector_get().
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
*/
|
|
|
|
struct drm_connector_list_iter {
|
|
|
|
/* private: */
|
|
|
|
struct drm_device *dev;
|
|
|
|
struct drm_connector *conn;
|
|
|
|
};
|
|
|
|
|
2017-02-28 22:46:43 +08:00
|
|
|
void drm_connector_list_iter_begin(struct drm_device *dev,
|
|
|
|
struct drm_connector_list_iter *iter);
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
struct drm_connector *
|
|
|
|
drm_connector_list_iter_next(struct drm_connector_list_iter *iter);
|
2017-02-28 22:46:43 +08:00
|
|
|
void drm_connector_list_iter_end(struct drm_connector_list_iter *iter);
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
|
2018-06-28 21:13:13 +08:00
|
|
|
bool drm_connector_has_possible_encoder(struct drm_connector *connector,
|
|
|
|
struct drm_encoder *encoder);
|
2022-12-01 05:11:30 +08:00
|
|
|
const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
|
2018-06-28 21:13:13 +08:00
|
|
|
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
/**
|
|
|
|
* drm_for_each_connector_iter - connector_list iterator macro
|
2016-12-30 04:48:26 +08:00
|
|
|
* @connector: &struct drm_connector pointer used as cursor
|
|
|
|
* @iter: &struct drm_connector_list_iter
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
*
|
|
|
|
* Note that @connector is only valid within the list body, if you want to use
|
2017-02-28 22:46:43 +08:00
|
|
|
* @connector after calling drm_connector_list_iter_end() then you need to grab
|
2017-04-21 08:38:19 +08:00
|
|
|
* your own reference first using drm_connector_get().
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
|
|
|
*/
|
|
|
|
#define drm_for_each_connector_iter(connector, iter) \
|
|
|
|
while ((connector = drm_connector_list_iter_next(iter)))
|
|
|
|
|
2018-06-28 21:13:09 +08:00
|
|
|
/**
|
|
|
|
* drm_connector_for_each_possible_encoder - iterate connector's possible encoders
|
|
|
|
* @connector: &struct drm_connector pointer
|
|
|
|
* @encoder: &struct drm_encoder pointer used as cursor
|
|
|
|
*/
|
2019-09-14 07:28:57 +08:00
|
|
|
#define drm_connector_for_each_possible_encoder(connector, encoder) \
|
|
|
|
drm_for_each_encoder_mask(encoder, (connector)->dev, \
|
|
|
|
(connector)->possible_encoders)
|
2018-06-28 21:13:09 +08:00
|
|
|
|
2016-08-13 04:48:50 +08:00
|
|
|
#endif
|