linux/include/drm/drm_connector.h

2374 lines
71 KiB
C
Raw Normal View History

/*
* 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>
drm: rework delayed connector cleanup in connector_iter PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and don't block on anything else. That means a free list plus locking, a standard pattern. v2: - Correctly free connectors only on last ref. Oops (Chris). - use llist_head/node (Chris). v3 - Add init_llist_head (Chris). Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter") Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v4.11+: 613051dac40d ("drm: locking&new iterators for connector_list" Cc: <stable@vger.kernel.org> # v4.11+ Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: David Airlie <airlied@linux.ie> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Mark Brown <broonie@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Thierry Escande <thierry.escande@collabora.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
2017-12-13 12:49:36 +00:00
#include <linux/llist.h>
#include <linux/ctype.h>
#include <linux/hdmi.h>
#include <linux/notifier.h>
#include <drm/drm_mode_object.h>
#include <drm/drm_util.h>
#include <drm/drm_property.h>
#include <uapi/drm/drm_mode.h>
struct drm_connector_helper_funcs;
struct drm_modeset_acquire_ctx;
struct drm_device;
struct drm_crtc;
struct drm_display_mode;
struct drm_encoder;
struct drm_panel;
struct drm_property;
struct drm_property_blob;
struct drm_printer;
struct drm_privacy_screen;
struct edid;
struct i2c_adapter;
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 */
};
/**
* 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!
*/
enum drm_connector_status {
/**
* @connector_status_connected: The connector is definitely connected to
* a sink device, and can be enabled.
*/
connector_status_connected = 1,
/**
* @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.
*/
connector_status_disconnected = 2,
/**
* @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.
*/
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-16 20:39:46 +00: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-16 20:39:46 +00: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,
};
enum subpixel_order {
SubPixelUnknown = 0,
SubPixelHorizontalRGB,
SubPixelHorizontalBGR,
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:01 +00: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,
/**
* @DRM_MODE_TV_MODE_MONOCHROME: Use timings appropriate to
* the DRM mode, including equalizing pulses for a 525-line
* or 625-line mode, with no pedestal or color encoding.
*/
DRM_MODE_TV_MODE_MONOCHROME,
/**
* @DRM_MODE_TV_MODE_MAX: Number of analog TV output modes.
*
* Internal implementation detail; this is not uABI.
*/
DRM_MODE_TV_MODE_MAX,
};
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Addressed review comments from Ville - Add clock rate calculations for 1/10 and 1/40 ratios - Remove leftovers from old patchset V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:02 +00: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;
};
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:01 +00: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;
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Addressed review comments from Ville - Add clock rate calculations for 1/10 and 1/40 ratios - Remove leftovers from old patchset V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:02 +00:00
/**
* @scrambling: sink's scrambling capabilities
*/
struct drm_scrambling scrambling;
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:01 +00: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;
};
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Addressed review comments from Ville - Add clock rate calculations for 1/10 and 1/40 ratios - Remove leftovers from old patchset V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:02 +00:00
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:01 +00: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 {
/** @scdc: sink's scdc support and capabilities */
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:01 +00:00
struct drm_scdc scdc;
/**
* @y420_vdb_modes: bitmap of modes which can support ycbcr420
* 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.
*/
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 10:33:46 +00:00
/**
* @y420_cmdb_modes: bitmap of modes which can support ycbcr420
* 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 10:33:46 +00: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 10:33:46 +00:00
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
/** @max_frl_rate_per_lane: support fixed rate link */
u8 max_frl_rate_per_lane;
/** @max_lanes: supported by sink */
u8 max_lanes;
/** @dsc_cap: DSC capabilities of the sink */
struct drm_hdmi_dsc_cap dsc_cap;
};
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 10:29:06 +00: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.
*
* @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 10:29:06 +00:00
*/
enum drm_link_status {
DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD,
DRM_LINK_STATUS_BAD = DRM_MODE_LINK_STATUS_BAD,
};
/**
* 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,
};
/**
* enum drm_hdmi_broadcast_rgb - Broadcast RGB Selection for an HDMI @drm_connector
*/
enum drm_hdmi_broadcast_rgb {
/**
* @DRM_HDMI_BROADCAST_RGB_AUTO: The RGB range is selected
* automatically based on the mode.
*/
DRM_HDMI_BROADCAST_RGB_AUTO,
/**
* @DRM_HDMI_BROADCAST_RGB_FULL: Full range RGB is forced.
*/
DRM_HDMI_BROADCAST_RGB_FULL,
/**
* @DRM_HDMI_BROADCAST_RGB_LIMITED: Limited range RGB is forced.
*/
DRM_HDMI_BROADCAST_RGB_LIMITED,
};
const char *
drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb);
const char *
drm_hdmi_connector_get_output_format_name(enum hdmi_colorspace fmt);
/**
* 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 {
u16 min_vfreq;
u16 max_vfreq;
};
/**
* 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;
};
drm/connector: Add support for privacy-screen properties (v4) Add support for generic electronic privacy screen properties, that can be added by systems that have an integrated EPS. Changes in v2 (Hans de Goede) - Create 2 properties, "privacy-screen sw-state" and "privacy-screen hw-state", to deal with devices where the OS might be locked out of making state changes - Write kerneldoc explaining how the 2 properties work together, what happens when changes to the state are made outside of the DRM code's control, etc. Changes in v3 (Hans de Goede) - Some small tweaks to the kerneldoc describing the 2 properties Changes in v4 (Hans de Goede) - Change the "Enabled, locked" and "Disabled, locked" hw-state enum value names to "Enabled-locked" and "Disabled-locked". The xrandr command shows all possible enum values separated by commas in its output, so having a comma in an enum name is not a good idea. - Do not add a privacy_screen_hw_state member to drm_connector_state since this property is immutable its value must be directly stored in the obj->properties->values array Signed-off-by: Rajat Jain <rajatja@google.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005202322.700909-2-hdegoede@redhat.com
2021-10-05 20:23:13 +00: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,
};
/**
* 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-19 17:12:59 +00: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.
*
* DP definitions come from the DP v2.0 spec
* HDMI definitions come from the CTA-861-H spec
*
* @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_MODE_COLORIMETRY_COUNT:
* Not a valid value; merely used four counting
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-19 17:12:59 +00: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,
DRM_MODE_COLORIMETRY_COUNT
};
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-19 17:12:59 +00: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 {
/**
* @DRM_BUS_FLAG_DE_LOW:
*
* The Data Enable signal is active low
*/
DRM_BUS_FLAG_DE_LOW = BIT(0),
/**
* @DRM_BUS_FLAG_DE_HIGH:
*
* The Data Enable signal is active high
*/
DRM_BUS_FLAG_DE_HIGH = BIT(1),
/**
* @DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE:
*
* Data is driven on the rising edge of the pixel clock
*/
DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE = BIT(2),
/**
* @DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE:
*
* Data is driven on the falling edge of the pixel clock
*/
DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE = BIT(3),
/**
* @DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE:
*
* Data is sampled on the rising edge of the pixel clock
*/
DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE = DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
/**
* @DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE:
*
* Data is sampled on the falling edge of the pixel clock
*/
DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
/**
* @DRM_BUS_FLAG_DATA_MSB_TO_LSB:
*
* Data is transmitted MSB to LSB on the bus
*/
DRM_BUS_FLAG_DATA_MSB_TO_LSB = BIT(4),
/**
* @DRM_BUS_FLAG_DATA_LSB_TO_MSB:
*
* Data is transmitted LSB to MSB on the bus
*/
DRM_BUS_FLAG_DATA_LSB_TO_MSB = BIT(5),
/**
* @DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE:
*
* Sync signals are driven on the rising edge of the pixel clock
*/
DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE = BIT(6),
/**
* @DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE:
*
* Sync signals are driven on the falling edge of the pixel clock
*/
DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE = BIT(7),
/**
* @DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE:
*
* Sync signals are sampled on the rising edge of the pixel clock
*/
DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE = DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
/**
* @DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE:
*
* Sync signals are sampled on the falling edge of the pixel clock
*/
DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE = DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
/**
* @DRM_BUS_FLAG_SHARP_SIGNALS:
*
* Set if the Sharp-specific signals (SPL, CLS, PS, REV) must be used
*/
DRM_BUS_FLAG_SHARP_SIGNALS = BIT(8),
};
/**
* 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
* this and &struct drm_connector. But for sinks with a real cable this
* 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().
*/
struct drm_display_info {
/**
* @width_mm: Physical width in mm.
*/
unsigned int width_mm;
/**
* @height_mm: Physical height in mm.
*/
unsigned int height_mm;
/**
* @bpc: Maximum bits per color channel. Used by HDMI and DP outputs.
*/
unsigned int bpc;
/**
* @subpixel_order: Subpixel order of LCD panels.
*/
enum subpixel_order subpixel_order;
#define DRM_COLOR_FORMAT_RGB444 (1<<0)
#define DRM_COLOR_FORMAT_YCBCR444 (1<<1)
#define DRM_COLOR_FORMAT_YCBCR422 (1<<2)
#define DRM_COLOR_FORMAT_YCBCR420 (1<<3)
/**
* @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;
/**
* @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.
*/
u32 color_formats;
/**
* @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.
*/
const u32 *bus_formats;
/**
* @num_bus_formats: Size of @bus_formats array.
*/
unsigned int num_bus_formats;
/**
* @bus_flags: Additional information (like pixel signal polarity) for
* the pixel data on the bus, using &enum drm_bus_flags values
* DRM_BUS_FLAGS\_.
*/
u32 bus_flags;
/**
* @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;
/**
* @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;
/**
* @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-13 17:04:19 +00:00
/**
* @has_hdmi_infoframe: Does the sink support the HDMI infoframe?
*/
bool has_hdmi_infoframe;
/**
* @rgb_quant_range_selectable: Does the sink support selecting
* the RGB quantization range?
*/
bool rgb_quant_range_selectable;
/**
* @edid_hdmi_rgb444_dc_modes: Mask of supported hdmi deep color modes
* in RGB 4:4:4. Even more stuff redundant with @bus_formats.
*/
u8 edid_hdmi_rgb444_dc_modes;
/**
* @edid_hdmi_ycbcr444_dc_modes: Mask of supported hdmi deep color
* modes in YCbCr 4:4:4. Even more stuff redundant with @bus_formats.
*/
u8 edid_hdmi_ycbcr444_dc_modes;
/**
* @cea_rev: CEA revision of the HDMI sink.
*/
u8 cea_rev;
drm/edid: detect SCDC support in HF-VSDB This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com
2017-03-13 11:24:01 +00:00
/**
* @hdmi: advance features of a HDMI sink.
*/
struct drm_hdmi_info hdmi;
/**
* @non_desktop: Non desktop display (HMD).
*/
bool non_desktop;
/**
* @monitor_range: Frequency range supported by monitor range descriptor
*/
struct drm_monitor_range_info monitor_range;
/**
* @luminance_range: Luminance range supported by panel
*/
struct drm_luminance_range_info luminance_range;
/**
* @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;
/**
* @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;
/**
* @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;
/**
* @quirks: EDID based quirks. Internal to EDID parsing.
*/
u32 quirks;
/**
* @source_physical_address: Source Physical Address from HDMI
* Vendor-Specific Data Block, for CEC usage.
*
* Defaults to CEC_PHYS_ADDR_INVALID (0xffff).
*/
u16 source_physical_address;
};
int drm_display_info_set_bus_formats(struct drm_display_info *info,
const u32 *formats,
unsigned int num_formats);
/**
* 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;
};
/**
* struct drm_tv_connector_state - TV connector related states
* @select_subconnector: selected subconnector
* @subconnector: detected subconnector
* @margins: TV margins
* @legacy_mode: Legacy TV mode, driver specific value
* @mode: TV mode
* @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 {
enum drm_mode_subconnector select_subconnector;
enum drm_mode_subconnector subconnector;
struct drm_connector_tv_margins margins;
unsigned int legacy_mode;
unsigned int mode;
unsigned int brightness;
unsigned int contrast;
unsigned int flicker_reduction;
unsigned int overscan;
unsigned int saturation;
unsigned int hue;
};
/**
* struct drm_connector_hdmi_infoframe - HDMI Infoframe container
*/
struct drm_connector_hdmi_infoframe {
/**
* @data: HDMI Infoframe structure
*/
union hdmi_infoframe data;
/**
* @set: Is the content of @data valid?
*/
bool set;
};
drm/connector: hdmi: Fix kerneldoc warnings It looks like the documentation for the HDMI-related fields recently added to both the drm_connector and drm_connector_state structures trigger some warnings because of their use of anonymous structures: $ scripts/kernel-doc -none include/drm/drm_connector.h include/drm/drm_connector.h:1138: warning: Excess struct member 'broadcast_rgb' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'infoframes' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'avi' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'hdr_drm' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'spd' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'vendor' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'is_limited_range' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_bpc' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_format' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'tmds_char_rate' description in 'drm_connector_state' include/drm/drm_connector.h:2112: warning: Excess struct member 'vendor' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'product' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'supported_formats' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'infoframes' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'lock' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'audio' description in 'drm_connector' Create some intermediate structures instead of anonymous ones to silence the warnings. Reported-by: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Fixes: 948f01d5e559 ("drm/connector: hdmi: Add support for output format") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610111200.428224-1-mripard@kernel.org
2024-06-10 11:12:00 +00:00
/*
* struct drm_connector_hdmi_state - HDMI state container
*/
struct drm_connector_hdmi_state {
/**
* @broadcast_rgb: Connector property to pass the
* Broadcast RGB selection value.
*/
enum drm_hdmi_broadcast_rgb broadcast_rgb;
/**
* @infoframes: HDMI Infoframes matching that state
*/
struct {
/**
* @avi: AVI Infoframes structure matching our
* state.
*/
struct drm_connector_hdmi_infoframe avi;
/**
* @hdr_drm: DRM (Dynamic Range and Mastering)
* Infoframes structure matching our state.
*/
struct drm_connector_hdmi_infoframe hdr_drm;
/**
* @spd: SPD Infoframes structure matching our
* state.
*/
struct drm_connector_hdmi_infoframe spd;
/**
* @vendor: HDMI Vendor Infoframes structure
* matching our state.
*/
struct drm_connector_hdmi_infoframe hdmi;
} infoframes;
/**
* @is_limited_range: Is the output supposed to use a limited
* RGB Quantization Range or not?
*/
bool is_limited_range;
/**
* @output_bpc: Bits per color channel to output.
*/
unsigned int output_bpc;
/**
* @output_format: Pixel format to output in.
*/
enum hdmi_colorspace output_format;
/**
* @tmds_char_rate: TMDS Character Rate, in Hz.
*/
unsigned long long tmds_char_rate;
};
/**
* struct drm_connector_state - mutable connector state
*/
struct drm_connector_state {
/** @connector: backpointer to the connector */
struct drm_connector *connector;
/**
* @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;
/**
* @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.
*
* This is also used in the atomic helpers to map encoders to their
* current and previous connectors, see
* drm_atomic_get_old_connector_for_encoder() and
* drm_atomic_get_new_connector_for_encoder().
*
* 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.
*/
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 10:29:06 +00: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;
/** @state: backpointer to global drm_atomic_state */
struct drm_atomic_state *state;
2017-09-04 10:48:37 +00:00
/**
* @commit: Tracks the pending commit to prevent use-after-free conditions.
*
* Is only set when @crtc is NULL.
*/
struct drm_crtc_commit *commit;
/** @tv: TV connector state */
struct drm_tv_connector_state tv;
drm: Add helpers to kick off self refresh mode in drivers This patch adds a new drm helper library to help drivers implement self refresh. Drivers choosing to use it will register crtcs and will receive callbacks when it's time to enter or exit self refresh mode. In its current form, it has a timer which will trigger after a driver-specified amount of inactivity. When the timer triggers, the helpers will submit a new atomic commit to shut the refreshing pipe off. On the next atomic commit, the drm core will revert the self refresh state and bring everything back up to be actively driven. From the driver's perspective, this works like a regular disable/enable cycle. The driver need only check the 'self_refresh_active' state in crtc_state. It should initiate self refresh mode on the panel and enter an off or low-power state. Changes in v2: - s/psr/self_refresh/ (Daniel) - integrated the psr exit into the commit that wakes it up (Jose/Daniel) - made the psr state per-crtc (Jose/Daniel) Changes in v3: - Remove the self_refresh_(active|changed) from connector state (Daniel) - Simplify loop in drm_self_refresh_helper_alter_state (Daniel) - Improve self_refresh_aware comment (Daniel) - s/self_refresh_state/self_refresh_data/ (Daniel) Changes in v4: - Move docbook location below panel (Daniel) - Improve docbook with references and more detailed explanation (Daniel) - Instead of register/unregister, use init/cleanup (Daniel) Changes in v5: - Resolved conflict in drm_atomic_helper.c #include block - Resolved conflict in rst with HDCP helper docs Changes in v6: - Fix include ordering, clean up forward declarations (Sam) Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-2-sean@poorly.run Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-1-sean@poorly.run Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-6-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-6-sean@poorly.run Link to v5: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-6-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jose Souza <jose.souza@intel.com> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190612145026.191846-1-sean@poorly.run
2019-06-12 14:50:19 +00: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;
/**
* @picture_aspect_ratio: Connector property to control the
* HDMI infoframe aspect ratio setting.
*
* The %DRM_MODE_PICTURE_ASPECT_\* values much match the
* values for &enum hdmi_picture_aspect
*/
enum hdmi_picture_aspect picture_aspect_ratio;
drm: content-type property for HDMI connector Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-05-15 13:59:27 +00: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;
drm: Add Content protection type property This patch adds a DRM ENUM property to the selected connectors. This property is used for mentioning the protected content's type from userspace to kernel HDCP authentication. Type of the stream is decided by the protected content providers. Type 0 content can be rendered on any HDCP protected display wires. But Type 1 content can be rendered only on HDCP2.2 protected paths. So when a userspace sets this property to Type 1 and starts the HDCP enable, kernel will honour it only if HDCP2.2 authentication is through for type 1. Else HDCP enable will be failed. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: cp_content_type is replaced with content_protection_type [daniel] check at atomic_set_property is removed [Maarten] v3: %s/content_protection_type/hdcp_content_type [Pekka] v4: property is created for the first requested connector and then reused. [Danvet] v5: kernel doc nits addressed [Daniel] Rebased as part of patch reordering. v6: Kernel docs are modified [pekka] v7: More details in Kernel docs. [pekka] v8: Few more clarification into kernel doc of content type [pekka] v9: Small fixes in coding style. v10: Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
2019-08-01 11:41:14 +00: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;
/**
* @scaling_mode: Connector property to control the
* upscaling, mostly used for built-in panels.
*/
unsigned int scaling_mode;
2018-01-08 19:55:37 +00:00
/**
* @content_protection: Connector property to request content
* protection. This is most commonly used for HDCP.
*/
unsigned int content_protection;
drm: Add writeback connector type Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/229037/
2017-03-29 16:42:32 +00: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-19 17:12:59 +00: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.
*/
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-19 17:12:59 +00:00
drm: Add writeback connector type Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/229037/
2017-03-29 16:42:32 +00:00
/**
* @writeback_job: Writeback job for writeback connectors
*
* 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.
drm: Add writeback connector type Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/229037/
2017-03-29 16:42:32 +00:00
*
* See also: drm_writeback_queue_job() and
* drm_writeback_signal_completion()
*/
struct drm_writeback_job *writeback_job;
drm: Add connector property to limit max bpc At times 12bpc HDMI cannot be driven due to faulty cables, dongles level shifters etc. To workaround them we may need to drive the output at a lower bpc. Currently the user space does not have a way to limit the bpc. The default bpc to be programmed is decided by the driver and is run against connector limitations. Creating a new connector property "max bpc" in order to limit the bpc. xrandr can make use of this connector property to make sure that bpc does not exceed the configured value. This property can be used by userspace to set the bpc. V2: Initialize max_bpc to satisfy kms_properties V3: Move the property to drm_connector V4: Split drm and i915 components(Ville) V5: Make the property per connector(Ville) V6: Compare the requested bpc to connector bpc(Daniel) Move the attach_property function to core(Ville) V7: Fix checkpatch warnings V8: Simplify the connector check code(Ville) V9: Const display_info(Ville) V10,V11: Fix CI issues. V12: Add the Kernel documentation(Daniel) V14: Crossreference the function name in the doc(Daniel) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Kishore Kadiyala <kishore.kadiyala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Sunpeng Li <sunpeng.li@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com
2018-10-12 18:42:32 +00: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;
drm/connector: Add support for privacy-screen properties (v4) Add support for generic electronic privacy screen properties, that can be added by systems that have an integrated EPS. Changes in v2 (Hans de Goede) - Create 2 properties, "privacy-screen sw-state" and "privacy-screen hw-state", to deal with devices where the OS might be locked out of making state changes - Write kerneldoc explaining how the 2 properties work together, what happens when changes to the state are made outside of the DRM code's control, etc. Changes in v3 (Hans de Goede) - Some small tweaks to the kerneldoc describing the 2 properties Changes in v4 (Hans de Goede) - Change the "Enabled, locked" and "Disabled, locked" hw-state enum value names to "Enabled-locked" and "Disabled-locked". The xrandr command shows all possible enum values separated by commas in its output, so having a comma in an enum name is not a good idea. - Do not add a privacy_screen_hw_state member to drm_connector_state since this property is immutable its value must be directly stored in the obj->properties->values array Signed-off-by: Rajat Jain <rajatja@google.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005202322.700909-2-hdegoede@redhat.com
2021-10-05 20:23:13 +00:00
/**
* @privacy_screen_sw_state: See :ref:`Standard Connector
* Properties<standard_connector_properties>`
*/
enum drm_privacy_screen_status privacy_screen_sw_state;
/**
* @hdr_output_metadata:
* DRM blob property for HDR output metadata
*/
struct drm_property_blob *hdr_output_metadata;
/**
* @hdmi: HDMI-related variable and properties. Filled by
* @drm_atomic_helper_connector_hdmi_check().
*/
drm/connector: hdmi: Fix kerneldoc warnings It looks like the documentation for the HDMI-related fields recently added to both the drm_connector and drm_connector_state structures trigger some warnings because of their use of anonymous structures: $ scripts/kernel-doc -none include/drm/drm_connector.h include/drm/drm_connector.h:1138: warning: Excess struct member 'broadcast_rgb' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'infoframes' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'avi' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'hdr_drm' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'spd' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'vendor' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'is_limited_range' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_bpc' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_format' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'tmds_char_rate' description in 'drm_connector_state' include/drm/drm_connector.h:2112: warning: Excess struct member 'vendor' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'product' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'supported_formats' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'infoframes' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'lock' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'audio' description in 'drm_connector' Create some intermediate structures instead of anonymous ones to silence the warnings. Reported-by: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Fixes: 948f01d5e559 ("drm/connector: hdmi: Add support for output format") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610111200.428224-1-mripard@kernel.org
2024-06-10 11:12:00 +00:00
struct drm_connector_hdmi_state hdmi;
};
/**
* struct drm_connector_hdmi_funcs - drm_hdmi_connector control functions
*/
struct drm_connector_hdmi_funcs {
/**
* @tmds_char_rate_valid:
*
* This callback is invoked at atomic_check time to figure out
* whether a particular TMDS character rate is supported by the
* driver.
*
* The @tmds_char_rate_valid callback is optional.
*
* Returns:
*
* Either &drm_mode_status.MODE_OK or one of the failure reasons
* in &enum drm_mode_status.
*/
enum drm_mode_status
(*tmds_char_rate_valid)(const struct drm_connector *connector,
const struct drm_display_mode *mode,
unsigned long long tmds_rate);
/**
* @clear_infoframe:
*
* This callback is invoked through
* @drm_atomic_helper_connector_hdmi_update_infoframes during a
* commit to clear the infoframes into the hardware. It will be
* called multiple times, once for every disabled infoframe
* type.
*
* The @clear_infoframe callback is optional.
*
* Returns:
* 0 on success, a negative error code otherwise
*/
int (*clear_infoframe)(struct drm_connector *connector,
enum hdmi_infoframe_type type);
/**
* @write_infoframe:
*
* This callback is invoked through
* @drm_atomic_helper_connector_hdmi_update_infoframes during a
* commit to program the infoframes into the hardware. It will
* be called multiple times, once for every updated infoframe
* type.
*
* The @write_infoframe callback is mandatory.
*
* Returns:
* 0 on success, a negative error code otherwise
*/
int (*write_infoframe)(struct drm_connector *connector,
enum hdmi_infoframe_type type,
const u8 *buffer, size_t len);
};
/**
* 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.
*
* This hook is not used by atomic drivers, remapping of the legacy DPMS
* property is entirely handled in the DRM core.
*
* 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.
*
* This callback is optional, if not implemented the connector will be
* considered as always being attached.
*
* 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.
*
* 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.
*
* 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.
*
* 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
* handling is unreliable), add all detected modes to &drm_connector.modes
* 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
* &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.
*
* Drivers using the probe helpers should use
* drm_helper_probe_single_connector_modes() to implement this
* function.
*
* RETURNS:
*
* The number of modes detected and filled into &drm_connector.modes.
*/
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
* driver-private properties. For atomic drivers it is not used because
* property handling is done entirely in the DRM core.
*
* 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.
*
* This is called while holding &drm_connector.mutex.
*
* 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
* late_register(). It is called from drm_connector_unregister(),
* early in the driver unload sequence to disable userspace access
* before data structures are torndown.
*
* This is called while holding &drm_connector.mutex.
*/
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.
* The core and helpers guarantee that any atomic state duplicated with
* this hook and still owned by the caller (i.e. not transferred to the
* driver by calling &drm_mode_config_funcs.atomic_commit) will be
* cleaned up by calling the @atomic_destroy_state hook in this
* structure.
*
* This callback is mandatory for atomic drivers.
*
* Atomic drivers which don't subclass &struct drm_connector_state should use
* 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.
*
* It is an error to call this hook before &drm_connector.state has been
* 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
*
* This callback is mandatory for atomic drivers.
*/
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);
/**
* @atomic_print_state:
*
* If driver subclasses &struct drm_connector_state, it should implement
* 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);
/**
* @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,
enum drm_connector_status status);
/**
* @debugfs_init:
*
* Allows connectors to create connector-specific debugfs files.
*/
void (*debugfs_init)(struct drm_connector *connector, struct dentry *root);
};
/**
* 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.
*/
struct drm_cmdline_mode {
/**
* @name:
*
* Name of the mode.
*/
char name[DRM_DISPLAY_MODE_LEN];
/**
* @specified:
*
* Has a mode been read from the command-line?
*/
bool specified;
/**
* @refresh_specified:
*
* Did the mode have a preferred refresh rate?
*/
bool refresh_specified;
/**
* @bpp_specified:
*
* Did the mode have a preferred BPP?
*/
bool bpp_specified;
/**
* @pixel_clock:
*
* Pixel Clock in kHz. Optional.
*/
unsigned int pixel_clock;
/**
* @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.
*/
int bpp;
/**
* @refresh:
*
* Refresh rate, in Hertz.
*/
int refresh;
/**
* @rb:
*
* Do we need to use reduced blanking?
*/
bool rb;
/**
* @interlace:
*
* The mode is interlaced.
*/
bool interlace;
/**
* @cvt:
*
* The timings will be calculated using the VESA Coordinated
* Video Timings instead of looking up the mode from a table.
*/
bool cvt;
/**
* @margins:
*
* Add margins to the mode calculation (1.8% of xres rounded
* down to 8 pixels and 1.8% of yres).
*/
bool margins;
/**
* @force:
*
* Ignore the hotplug state of the connector, and force its
* state to one of the DRM_FORCE_* values.
*/
enum drm_connector_force force;
/**
* @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;
/**
* @panel_orientation:
*
* drm-connector "panel orientation" property override value,
* DRM_MODE_PANEL_ORIENTATION_UNKNOWN if not set.
*/
enum drm_panel_orientation panel_orientation;
/**
* @tv_margins: TV margins to apply to the mode.
*/
struct drm_connector_tv_margins tv_margins;
/**
* @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;
};
drm/connector: hdmi: Fix kerneldoc warnings It looks like the documentation for the HDMI-related fields recently added to both the drm_connector and drm_connector_state structures trigger some warnings because of their use of anonymous structures: $ scripts/kernel-doc -none include/drm/drm_connector.h include/drm/drm_connector.h:1138: warning: Excess struct member 'broadcast_rgb' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'infoframes' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'avi' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'hdr_drm' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'spd' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'vendor' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'is_limited_range' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_bpc' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_format' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'tmds_char_rate' description in 'drm_connector_state' include/drm/drm_connector.h:2112: warning: Excess struct member 'vendor' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'product' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'supported_formats' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'infoframes' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'lock' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'audio' description in 'drm_connector' Create some intermediate structures instead of anonymous ones to silence the warnings. Reported-by: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Fixes: 948f01d5e559 ("drm/connector: hdmi: Add support for output format") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610111200.428224-1-mripard@kernel.org
2024-06-10 11:12:00 +00:00
/*
* struct drm_connector_hdmi - DRM Connector HDMI-related structure
*/
struct drm_connector_hdmi {
#define DRM_CONNECTOR_HDMI_VENDOR_LEN 8
/**
* @vendor: HDMI Controller Vendor Name
*/
unsigned char vendor[DRM_CONNECTOR_HDMI_VENDOR_LEN] __nonstring;
#define DRM_CONNECTOR_HDMI_PRODUCT_LEN 16
/**
* @product: HDMI Controller Product Name
*/
unsigned char product[DRM_CONNECTOR_HDMI_PRODUCT_LEN] __nonstring;
/**
* @supported_formats: Bitmask of @hdmi_colorspace
* supported by the controller.
*/
unsigned long supported_formats;
/**
* @funcs: HDMI connector Control Functions
*/
const struct drm_connector_hdmi_funcs *funcs;
/**
* @infoframes: Current Infoframes output by the connector
*/
struct {
/**
* @lock: Mutex protecting against concurrent access to
* the infoframes, most notably between KMS and ALSA.
*/
struct mutex lock;
/**
* @audio: Current Audio Infoframes structure. Protected
* by @lock.
*/
struct drm_connector_hdmi_infoframe audio;
} infoframes;
};
/**
* 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 {
/** @dev: parent DRM device */
struct drm_device *dev;
/** @kdev: kernel device for sysfs attributes */
struct device *kdev;
/** @attr: sysfs attributes */
struct device_attribute *attr;
/**
* @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;
/**
* @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.
*/
struct list_head head;
/**
* @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;
/** @base: base KMS object */
struct drm_mode_object base;
/** @name: human readable name, can be overwritten by the driver */
char *name;
/**
* @mutex: Lock for general connector state, but currently only protects
* @registered. Most of the connector state is still protected by
* &drm_mode_config.mutex.
*/
struct mutex mutex;
/**
* @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;
/**
* @connector_type:
* one of the DRM_MODE_CONNECTOR_<foo> types from drm_mode.h
*/
int connector_type;
/** @connector_type_id: index into connector type enum */
int connector_type_id;
/**
* @interlace_allowed:
* Can this connector handle interlaced modes? Only used by
* drm_helper_probe_single_connector_modes() for mode filtering.
*/
bool interlace_allowed;
/**
* @doublescan_allowed:
* Can this connector handle doublescan? Only used by
* drm_helper_probe_single_connector_modes() for mode filtering.
*/
bool doublescan_allowed;
/**
* @stereo_allowed:
* Can this connector handle stereo modes? Only used by
* drm_helper_probe_single_connector_modes() for mode filtering.
*/
bool stereo_allowed;
/**
* @ycbcr_420_allowed : This bool indicates if this connector is
* capable of handling YCBCR 420 output. While parsing the EDID
* blocks it's very helpful to know if the source is capable of
* handling YCBCR 420 outputs.
*/
bool ycbcr_420_allowed;
/**
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-16 20:39:46 +00:00
* @registration_state: Is this connector initializing, exposed
* (registered) with userspace, or unregistered?
*
* 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-16 20:39:46 +00:00
enum drm_connector_registration_state registration_state;
/**
* @modes:
* Modes available on this connector (from fill_modes() + user).
* Protected by &drm_mode_config.mutex.
*/
struct list_head modes;
/**
* @status:
* One of the drm_connector_status enums (connected, not, or unknown).
* Protected by &drm_mode_config.mutex.
*/
enum drm_connector_status status;
/**
* @probed_modes:
* These are modes added by probing with DDC or the BIOS, before
* filtering is applied. Used by the probe helpers. Protected by
* &drm_mode_config.mutex.
*/
struct list_head probed_modes;
/**
* @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
* &drm_display_info.width_mm and &drm_display_info.height_mm fields
* with the physical size of the display.
*
* Protected by &drm_mode_config.mutex.
*/
struct drm_display_info display_info;
/** @funcs: connector control functions */
const struct drm_connector_funcs *funcs;
/**
* @edid_blob_ptr: DRM property containing EDID if present. Protected by
* &drm_mode_config.mutex.
*
* This must be updated only by calling drm_edid_connector_update() or
* drm_connector_update_edid_property().
*
* This must not be used by drivers directly.
*/
struct drm_property_blob *edid_blob_ptr;
/** @properties: property tracking for this connector */
struct drm_object_properties properties;
/**
* @scaling_mode_property: Optional atomic property to control the
* upscaling. See drm_connector_attach_content_protection_property().
*/
struct drm_property *scaling_mode_property;
/**
* @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-19 17:12:59 +00:00
/**
* @colorspace_property: Connector property to set the suitable
* colorspace supported by the sink.
*/
struct drm_property *colorspace_property;
/**
* @path_blob_ptr:
*
* DRM blob property data for the DP MST path property. This should only
* be updated by calling drm_connector_set_path_property().
*/
struct drm_property_blob *path_blob_ptr;
/**
* @max_bpc: Maximum bits per color channel the connector supports.
*/
unsigned int max_bpc;
drm: Add connector property to limit max bpc At times 12bpc HDMI cannot be driven due to faulty cables, dongles level shifters etc. To workaround them we may need to drive the output at a lower bpc. Currently the user space does not have a way to limit the bpc. The default bpc to be programmed is decided by the driver and is run against connector limitations. Creating a new connector property "max bpc" in order to limit the bpc. xrandr can make use of this connector property to make sure that bpc does not exceed the configured value. This property can be used by userspace to set the bpc. V2: Initialize max_bpc to satisfy kms_properties V3: Move the property to drm_connector V4: Split drm and i915 components(Ville) V5: Make the property per connector(Ville) V6: Compare the requested bpc to connector bpc(Daniel) Move the attach_property function to core(Ville) V7: Fix checkpatch warnings V8: Simplify the connector check code(Ville) V9: Const display_info(Ville) V10,V11: Fix CI issues. V12: Add the Kernel documentation(Daniel) V14: Crossreference the function name in the doc(Daniel) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Kishore Kadiyala <kishore.kadiyala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Sunpeng Li <sunpeng.li@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com
2018-10-12 18:42:32 +00:00
/**
* @max_bpc_property: Default connector property for the max bpc to be
* driven out of the connector.
*/
struct drm_property *max_bpc_property;
/** @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;
drm/connector: Add support for privacy-screen properties (v4) Add support for generic electronic privacy screen properties, that can be added by systems that have an integrated EPS. Changes in v2 (Hans de Goede) - Create 2 properties, "privacy-screen sw-state" and "privacy-screen hw-state", to deal with devices where the OS might be locked out of making state changes - Write kerneldoc explaining how the 2 properties work together, what happens when changes to the state are made outside of the DRM code's control, etc. Changes in v3 (Hans de Goede) - Some small tweaks to the kerneldoc describing the 2 properties Changes in v4 (Hans de Goede) - Change the "Enabled, locked" and "Disabled, locked" hw-state enum value names to "Enabled-locked" and "Disabled-locked". The xrandr command shows all possible enum values separated by commas in its output, so having a comma in an enum name is not a good idea. - Do not add a privacy_screen_hw_state member to drm_connector_state since this property is immutable its value must be directly stored in the obj->properties->values array Signed-off-by: Rajat Jain <rajatja@google.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005202322.700909-2-hdegoede@redhat.com
2021-10-05 20:23:13 +00: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;
/**
* @broadcast_rgb_property: Connector property to set the
* Broadcast RGB selection to output with.
*/
struct drm_property *broadcast_rgb_property;
#define DRM_CONNECTOR_POLL_HPD (1 << 0)
#define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
#define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
/**
* @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
* 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.
*
* Set to 0 for connectors that don't support connection status
* discovery.
*/
uint8_t polled;
/**
* @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.
*/
int dpms;
/** @helper_private: mid-layer private data */
const struct drm_connector_helper_funcs *helper_private;
/** @cmdline_mode: mode line parsed from the kernel cmdline for this connector */
struct drm_cmdline_mode cmdline_mode;
/** @force: a DRM_FORCE_<foo> state for forced mode sets */
enum drm_connector_force force;
/**
* @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;
/**
* @edid_override_mutex: Protect access to edid_override.
*/
struct mutex edid_override_mutex;
/** @epoch_counter: used to detect any other changes in connector, besides status */
u64 epoch_counter;
/**
* @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().
*/
u32 possible_encoders;
/**
* @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;
#define MAX_ELD_BYTES 128
/** @eld: EDID-like data, if present */
uint8_t eld[MAX_ELD_BYTES];
/** @latency_present: AV delay info from ELD, if found */
bool latency_present[2];
/**
* @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
*/
int audio_latency[2];
/**
* @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.
*
* The field should be set by calling drm_connector_init_with_ddc().
*/
struct i2c_adapter *ddc;
/**
* @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 */
unsigned bad_edid_counter;
/**
* @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
*/
bool edid_corrupt;
/**
* @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;
/** @debugfs_entry: debugfs directory for this connector */
struct dentry *debugfs_entry;
/**
* @state:
*
* Current atomic state for this connector.
*
* This is protected by &drm_mode_config.connection_mutex. Note that
* nonblocking atomic commits access the current connector state without
* taking locks. Either by going through the &struct drm_atomic_state
* pointers, see for_each_oldnew_connector_in_state(),
* 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.
*/
struct drm_connector_state *state;
/* 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
* drm_connector_set_tile_property().
*/
struct drm_property_blob *tile_blob_ptr;
/** @has_tile: is this connector connected to a tiled monitor */
bool has_tile;
/** @tile_group: tile group for the connected monitor */
struct drm_tile_group *tile_group;
/** @tile_is_single_monitor: whether the tile is one monitor housing */
bool tile_is_single_monitor;
/** @num_h_tile: number of horizontal tiles in the tile group */
/** @num_v_tile: number of vertical tiles in the tile group */
uint8_t num_h_tile, num_v_tile;
/** @tile_h_loc: horizontal location of this tile */
/** @tile_v_loc: vertical location of this tile */
uint8_t tile_h_loc, tile_v_loc;
/** @tile_h_size: horizontal size of this tile. */
/** @tile_v_size: vertical size of this tile. */
uint16_t tile_h_size, tile_v_size;
/**
drm: rework delayed connector cleanup in connector_iter PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and don't block on anything else. That means a free list plus locking, a standard pattern. v2: - Correctly free connectors only on last ref. Oops (Chris). - use llist_head/node (Chris). v3 - Add init_llist_head (Chris). Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter") Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v4.11+: 613051dac40d ("drm: locking&new iterators for connector_list" Cc: <stable@vger.kernel.org> # v4.11+ Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: David Airlie <airlied@linux.ie> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Mark Brown <broonie@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Thierry Escande <thierry.escande@collabora.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
2017-12-13 12:49:36 +00:00
* @free_node:
*
* List used only by &drm_connector_list_iter to be able to clean up a
drm: rework delayed connector cleanup in connector_iter PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and don't block on anything else. That means a free list plus locking, a standard pattern. v2: - Correctly free connectors only on last ref. Oops (Chris). - use llist_head/node (Chris). v3 - Add init_llist_head (Chris). Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter") Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v4.11+: 613051dac40d ("drm: locking&new iterators for connector_list" Cc: <stable@vger.kernel.org> # v4.11+ Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: David Airlie <airlied@linux.ie> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Mark Brown <broonie@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Thierry Escande <thierry.escande@collabora.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
2017-12-13 12:49:36 +00:00
* connector from any context, in conjunction with
* &drm_mode_config.connector_free_work.
*/
drm: rework delayed connector cleanup in connector_iter PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and don't block on anything else. That means a free list plus locking, a standard pattern. v2: - Correctly free connectors only on last ref. Oops (Chris). - use llist_head/node (Chris). v3 - Add init_llist_head (Chris). Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter") Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v4.11+: 613051dac40d ("drm: locking&new iterators for connector_list" Cc: <stable@vger.kernel.org> # v4.11+ Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: David Airlie <airlied@linux.ie> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Mark Brown <broonie@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Thierry Escande <thierry.escande@collabora.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
2017-12-13 12:49:36 +00:00
struct llist_node free_node;
drm: Fix docbook warnings in hdr metadata helper structures Fixes the following warnings: ./include/drm/drm_mode_config.h:841: warning: Incorrect use of kernel-doc format: * hdr_output_metadata_property: Connector property containing hdr ./include/drm/drm_mode_config.h:918: warning: Function parameter or member 'hdr_output_metadata_property' not described in 'drm_mode_config' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_output_metadata' not described in 'drm_connector' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_sink_metadata' not described in 'drm_connector' Also adds some property documentation for HDR Metadata Connector Property in connector property create function. v2: Fixed Sean Paul's review comments. v3: Fixed Daniel Vetter's review comments, added the UAPI structure definition section in kernel docs. v4: Fixed Daniel Vetter's review comments. v5: Added structure member references as per Daniel's suggestion. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Ville Syrjä" <ville.syrjala@linux.intel.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Reviewed-by: Sean Paul <sean@poorly.run> (v1) Signed-off-by: Uma Shankar <uma.shankar@intel.com> [danvet: Fix up markup: () for functions, & for structs. Style guide also recommends to prepend struct for structures.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1559647022-7336-1-git-send-email-uma.shankar@intel.com
2019-06-04 11:17:02 +00:00
/** @hdr_sink_metadata: HDR Metadata Information read from sink */
struct hdr_sink_metadata hdr_sink_metadata;
/**
* @hdmi: HDMI-related variable and properties.
*/
drm/connector: hdmi: Fix kerneldoc warnings It looks like the documentation for the HDMI-related fields recently added to both the drm_connector and drm_connector_state structures trigger some warnings because of their use of anonymous structures: $ scripts/kernel-doc -none include/drm/drm_connector.h include/drm/drm_connector.h:1138: warning: Excess struct member 'broadcast_rgb' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'infoframes' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'avi' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'hdr_drm' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'spd' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'vendor' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'is_limited_range' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_bpc' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'output_format' description in 'drm_connector_state' include/drm/drm_connector.h:1138: warning: Excess struct member 'tmds_char_rate' description in 'drm_connector_state' include/drm/drm_connector.h:2112: warning: Excess struct member 'vendor' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'product' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'supported_formats' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'infoframes' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'lock' description in 'drm_connector' include/drm/drm_connector.h:2112: warning: Excess struct member 'audio' description in 'drm_connector' Create some intermediate structures instead of anonymous ones to silence the warnings. Reported-by: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Fixes: 948f01d5e559 ("drm/connector: hdmi: Add support for output format") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240610111200.428224-1-mripard@kernel.org
2024-06-10 11:12:00 +00:00
struct drm_connector_hdmi hdmi;
};
#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);
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);
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);
int drmm_connector_hdmi_init(struct drm_device *dev,
struct drm_connector *connector,
const char *vendor, const char *product,
const struct drm_connector_funcs *funcs,
const struct drm_connector_hdmi_funcs *hdmi_funcs,
int connector_type,
struct i2c_adapter *ddc,
unsigned long supported_formats,
unsigned int max_bpc);
void drm_connector_attach_edid_property(struct drm_connector *connector);
int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
int drm_connector_attach_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
void drm_connector_cleanup(struct drm_connector *connector);
static inline unsigned int drm_connector_index(const struct drm_connector *connector)
{
return connector->index;
}
static inline u32 drm_connector_mask(const struct drm_connector *connector)
{
return 1 << connector->index;
}
/**
* drm_connector_lookup - lookup connector object
* @dev: DRM device
* @file_priv: drm file to check for lease against.
* @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,
struct drm_file *file_priv,
uint32_t id)
{
struct drm_mode_object *mo;
mo = drm_mode_object_find(dev, file_priv, id, DRM_MODE_OBJECT_CONNECTOR);
return mo ? obj_to_connector(mo) : NULL;
}
/**
* drm_connector_get - acquire a connector reference
* @connector: DRM connector
*
* This function increments the connector's refcount.
*/
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-16 20:39:46 +00: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;
}
void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
enum drm_connector_status status);
const char *drm_get_connector_type_name(unsigned int connector_type);
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);
const char *drm_get_tv_mode_name(int val);
const char *drm_get_tv_subconnector_name(int val);
const char *drm_get_tv_select_name(int val);
drm: report dp downstream port type as a subconnector property Currently, downstream port type is only reported in debugfs. This information should be considered important since it reflects the actual physical connector type. Some userspace (e.g. window compositors) may want to show this info to a user. The 'subconnector' property is already utilized for DVI-I and TV-out for reporting connector subtype. The initial motivation for this feature came from i2c test [1]. It is supposed to be skipped on VGA connectors, but it cannot detect VGA over DP and fails instead. v2: - Ville: utilized drm_dp_is_branch() - Ville: implement DP 1.0 downstream type info - Replaced create_dp_properties with add_dp_subconnector_property - Added dp_set_subconnector_property helper v4: - Ville: add DP1.0 best assumption about subconnector - Ville: assume DVI is DVI-D - Ville: reuse Writeback enum value for Virtual subconnector - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort v5: rebase v6: - Jani Nikula: renamed a function name - Jani Nikula: addressed the issues with documentation [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b@intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev@intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1587732655-17544-1-git-send-email-jeevan.b@intel.com
2020-04-24 12:50:51 +00:00
const char *drm_get_dp_subconnector_name(int val);
2018-01-08 19:55:37 +00:00
const char *drm_get_content_protection_name(int val);
drm: Add Content protection type property This patch adds a DRM ENUM property to the selected connectors. This property is used for mentioning the protected content's type from userspace to kernel HDCP authentication. Type of the stream is decided by the protected content providers. Type 0 content can be rendered on any HDCP protected display wires. But Type 1 content can be rendered only on HDCP2.2 protected paths. So when a userspace sets this property to Type 1 and starts the HDCP enable, kernel will honour it only if HDCP2.2 authentication is through for type 1. Else HDCP enable will be failed. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: cp_content_type is replaced with content_protection_type [daniel] check at atomic_set_property is removed [Maarten] v3: %s/content_protection_type/hdcp_content_type [Pekka] v4: property is created for the first requested connector and then reused. [Danvet] v5: kernel doc nits addressed [Daniel] Rebased as part of patch reordering. v6: Kernel docs are modified [pekka] v7: More details in Kernel docs. [pekka] v8: Few more clarification into kernel doc of content type [pekka] v9: Small fixes in coding style. v10: Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
2019-08-01 11:41:14 +00:00
const char *drm_get_hdcp_content_type_name(int val);
int drm_get_tv_mode_from_name(const char *name, size_t len);
int drm_mode_create_dvi_i_properties(struct drm_device *dev);
drm: report dp downstream port type as a subconnector property Currently, downstream port type is only reported in debugfs. This information should be considered important since it reflects the actual physical connector type. Some userspace (e.g. window compositors) may want to show this info to a user. The 'subconnector' property is already utilized for DVI-I and TV-out for reporting connector subtype. The initial motivation for this feature came from i2c test [1]. It is supposed to be skipped on VGA connectors, but it cannot detect VGA over DP and fails instead. v2: - Ville: utilized drm_dp_is_branch() - Ville: implement DP 1.0 downstream type info - Replaced create_dp_properties with add_dp_subconnector_property - Added dp_set_subconnector_property helper v4: - Ville: add DP1.0 best assumption about subconnector - Ville: assume DVI is DVI-D - Ville: reuse Writeback enum value for Virtual subconnector - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort v5: rebase v6: - Jani Nikula: renamed a function name - Jani Nikula: addressed the issues with documentation [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b@intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev@intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1587732655-17544-1-git-send-email-jeevan.b@intel.com
2020-04-24 12:50:51 +00:00
void drm_connector_attach_dp_subconnector_property(struct drm_connector *connector);
int drm_mode_create_tv_margin_properties(struct drm_device *dev);
int drm_mode_create_tv_properties_legacy(struct drm_device *dev,
unsigned int num_modes,
const char * const modes[]);
int drm_mode_create_tv_properties(struct drm_device *dev,
unsigned int supported_tv_modes);
void drm_connector_attach_tv_margin_properties(struct drm_connector *conn);
int drm_mode_create_scaling_mode_property(struct drm_device *dev);
drm: content-type property for HDMI connector Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-05-15 13:59:27 +00:00
int drm_connector_attach_content_type_property(struct drm_connector *dev);
int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
u32 scaling_mode_mask);
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
int drm_connector_attach_broadcast_rgb_property(struct drm_connector *connector);
int drm_connector_attach_colorspace_property(struct drm_connector *connector);
int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *connector);
bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
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);
drm: content-type property for HDMI connector Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-05-15 13:59:27 +00:00
int drm_mode_create_content_type_property(struct drm_device *dev);
int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
int drm_connector_set_tile_property(struct drm_connector *connector);
int drm_connector_update_edid_property(struct drm_connector *connector,
const struct edid *edid);
void drm_connector_set_link_status_property(struct drm_connector *connector,
uint64_t link_status);
void drm_connector_set_vrr_capable_property(
struct drm_connector *connector, bool capable);
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);
int drm_connector_set_orientation_from_panel(
struct drm_connector *connector,
struct drm_panel *panel);
drm: Add connector property to limit max bpc At times 12bpc HDMI cannot be driven due to faulty cables, dongles level shifters etc. To workaround them we may need to drive the output at a lower bpc. Currently the user space does not have a way to limit the bpc. The default bpc to be programmed is decided by the driver and is run against connector limitations. Creating a new connector property "max bpc" in order to limit the bpc. xrandr can make use of this connector property to make sure that bpc does not exceed the configured value. This property can be used by userspace to set the bpc. V2: Initialize max_bpc to satisfy kms_properties V3: Move the property to drm_connector V4: Split drm and i915 components(Ville) V5: Make the property per connector(Ville) V6: Compare the requested bpc to connector bpc(Daniel) Move the attach_property function to core(Ville) V7: Fix checkpatch warnings V8: Simplify the connector check code(Ville) V9: Const display_info(Ville) V10,V11: Fix CI issues. V12: Add the Kernel documentation(Daniel) V14: Crossreference the function name in the doc(Daniel) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Kishore Kadiyala <kishore.kadiyala@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Sunpeng Li <sunpeng.li@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com
2018-10-12 18:42:32 +00:00
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
int min, int max);
drm/connector: Add support for privacy-screen properties (v4) Add support for generic electronic privacy screen properties, that can be added by systems that have an integrated EPS. Changes in v2 (Hans de Goede) - Create 2 properties, "privacy-screen sw-state" and "privacy-screen hw-state", to deal with devices where the OS might be locked out of making state changes - Write kerneldoc explaining how the 2 properties work together, what happens when changes to the state are made outside of the DRM code's control, etc. Changes in v3 (Hans de Goede) - Some small tweaks to the kerneldoc describing the 2 properties Changes in v4 (Hans de Goede) - Change the "Enabled, locked" and "Disabled, locked" hw-state enum value names to "Enabled-locked" and "Disabled-locked". The xrandr command shows all possible enum values separated by commas in its output, so having a comma in an enum name is not a good idea. - Do not add a privacy_screen_hw_state member to drm_connector_state since this property is immutable its value must be directly stored in the obj->properties->values array Signed-off-by: Rajat Jain <rajatja@google.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005202322.700909-2-hdegoede@redhat.com
2021-10-05 20:23:13 +00:00
void drm_connector_create_privacy_screen_properties(struct drm_connector *conn);
void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
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);
/**
* 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,
const char topology[8]);
struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
const char topology[8]);
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-13 23:08:06 +00: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
* 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-13 23:08:06 +00:00
* drm_connector_list_iter_next() respectively the convenience macro
* drm_for_each_connector_iter().
*
* 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-13 23:08:06 +00:00
*/
struct drm_connector_list_iter {
/* private: */
struct drm_device *dev;
struct drm_connector *conn;
};
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-13 23:08:06 +00:00
struct drm_connector *
drm_connector_list_iter_next(struct drm_connector_list_iter *iter);
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-13 23:08:06 +00:00
bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
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-13 23:08:06 +00:00
/**
* drm_for_each_connector_iter - connector_list iterator macro
* @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-13 23:08:06 +00:00
*
* Note that @connector is only valid within the list body, if you want to use
* @connector after calling drm_connector_list_iter_end() 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-13 23:08:06 +00:00
*/
#define drm_for_each_connector_iter(connector, iter) \
while ((connector = drm_connector_list_iter_next(iter)))
/**
* drm_connector_for_each_possible_encoder - iterate connector's possible encoders
* @connector: &struct drm_connector pointer
* @encoder: &struct drm_encoder pointer used as cursor
*/
#define drm_connector_for_each_possible_encoder(connector, encoder) \
drm_for_each_encoder_mask(encoder, (connector)->dev, \
(connector)->possible_encoders)
#endif