OpenCloudOS-Kernel/drivers/gpu/drm/drm_connector.c

2478 lines
83 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.
*/
#include <drm/drm_connector.h>
#include <drm/drm_edid.h>
#include <drm/drm_encoder.h>
#include <drm/drm_utils.h>
#include <drm/drm_print.h>
#include <drm/drm_drv.h>
#include <drm/drm_file.h>
#include <linux/uaccess.h>
#include "drm_crtc_internal.h"
#include "drm_internal.h"
/**
* DOC: overview
*
* In DRM connectors are the general abstraction for display sinks, and include
* als fixed panels or anything else that can display pixels in some form. As
* opposed to all other KMS objects representing hardware (like CRTC, encoder or
* plane abstractions) connectors can be hotplugged and unplugged at runtime.
* Hence they are reference-counted using drm_connector_get() and
* drm_connector_put().
*
* KMS driver must create, initialize, register and attach at a &struct
* drm_connector for each such sink. The instance is created as other KMS
* objects and initialized by setting the following fields. The connector is
* initialized with a call to drm_connector_init() with a pointer to the
* &struct drm_connector_funcs and a connector type, and then exposed to
* userspace with a call to drm_connector_register().
*
* Connectors must be attached to an encoder to be used. For devices that map
* connectors to encoders 1:1, the connector should be attached at
* initialization time with a call to drm_connector_attach_encoder(). The
* driver must also set the &drm_connector.encoder field to point to the
* attached encoder.
*
* For connectors which are not fixed (like built-in panels) the driver needs to
* support hotplug notifications. The simplest way to do that is by using the
* probe helpers, see drm_kms_helper_poll_init() for connectors which don't have
* hardware support for hotplug interrupts. Connectors with hardware hotplug
* support can instead use e.g. drm_helper_hpd_irq_event().
*/
struct drm_conn_prop_enum_list {
int type;
const char *name;
struct ida ida;
};
/*
* Connector and encoder types.
*/
static struct drm_conn_prop_enum_list drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_Unknown, "Unknown" },
{ DRM_MODE_CONNECTOR_VGA, "VGA" },
{ DRM_MODE_CONNECTOR_DVII, "DVI-I" },
{ DRM_MODE_CONNECTOR_DVID, "DVI-D" },
{ DRM_MODE_CONNECTOR_DVIA, "DVI-A" },
{ DRM_MODE_CONNECTOR_Composite, "Composite" },
{ DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO" },
{ DRM_MODE_CONNECTOR_LVDS, "LVDS" },
{ DRM_MODE_CONNECTOR_Component, "Component" },
{ DRM_MODE_CONNECTOR_9PinDIN, "DIN" },
{ DRM_MODE_CONNECTOR_DisplayPort, "DP" },
{ DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
{ DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
{ DRM_MODE_CONNECTOR_TV, "TV" },
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
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-30 00:42:32 +08:00
{ DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{ DRM_MODE_CONNECTOR_SPI, "SPI" },
};
void drm_connector_ida_init(void)
{
int i;
for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
ida_init(&drm_connector_enum_list[i].ida);
}
void drm_connector_ida_destroy(void)
{
int i;
for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
ida_destroy(&drm_connector_enum_list[i].ida);
}
/**
* drm_get_connector_type_name - return a string for connector type
* @type: The connector type (DRM_MODE_CONNECTOR_*)
*
* Returns: the name of the connector type, or NULL if the type is not valid.
*/
const char *drm_get_connector_type_name(unsigned int type)
{
if (type < ARRAY_SIZE(drm_connector_enum_list))
return drm_connector_enum_list[type].name;
return NULL;
}
EXPORT_SYMBOL(drm_get_connector_type_name);
/**
* drm_connector_get_cmdline_mode - reads the user's cmdline mode
* @connector: connector to quwery
*
* The kernel supports per-connector configuration of its consoles through
* use of the video= parameter. This function parses that option and
* extracts the user's specified mode (or enable/disable status) for a
* particular connector. This is typically only used during the early fbdev
* setup.
*/
static void drm_connector_get_cmdline_mode(struct drm_connector *connector)
{
struct drm_cmdline_mode *mode = &connector->cmdline_mode;
char *option = NULL;
if (fb_get_options(connector->name, &option))
return;
if (!drm_mode_parse_command_line_for_connector(option,
connector,
mode))
return;
if (mode->force) {
DRM_INFO("forcing %s connector %s\n", connector->name,
drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
DRM_INFO("cmdline forces connector %s panel_orientation to %d\n",
connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
}
DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
connector->name, mode->name,
mode->xres, mode->yres,
mode->refresh_specified ? mode->refresh : 60,
mode->rb ? " reduced blanking" : "",
mode->margins ? " with margins" : "",
mode->interlace ? " interlaced" : "");
}
static void drm_connector_free(struct kref *kref)
{
struct drm_connector *connector =
container_of(kref, struct drm_connector, base.refcount);
struct drm_device *dev = connector->dev;
drm_mode_object_unregister(dev, &connector->base);
connector->funcs->destroy(connector);
}
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 20:49:36 +08:00
void drm_connector_free_work_fn(struct work_struct *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 20:49:36 +08:00
struct drm_connector *connector, *n;
struct drm_device *dev =
container_of(work, struct drm_device, mode_config.connector_free_work);
struct drm_mode_config *config = &dev->mode_config;
unsigned long flags;
struct llist_node *freed;
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 20:49:36 +08:00
spin_lock_irqsave(&config->connector_list_lock, flags);
freed = llist_del_all(&config->connector_free_list);
spin_unlock_irqrestore(&config->connector_list_lock, flags);
llist_for_each_entry_safe(connector, n, freed, free_node) {
drm_mode_object_unregister(dev, &connector->base);
connector->funcs->destroy(connector);
}
}
/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
* @connector: the connector to init
* @funcs: callbacks for this connector
* @connector_type: user visible type of the connector
*
* Initialises a preallocated connector. Connectors should be
* subclassed as part of driver connector objects.
*
* Returns:
* Zero on success, error code on failure.
*/
int drm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
const struct drm_connector_funcs *funcs,
int connector_type)
{
struct drm_mode_config *config = &dev->mode_config;
int ret;
struct ida *connector_ida =
&drm_connector_enum_list[connector_type].ida;
WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
(!funcs->atomic_destroy_state ||
!funcs->atomic_duplicate_state));
ret = __drm_mode_object_add(dev, &connector->base,
DRM_MODE_OBJECT_CONNECTOR,
false, drm_connector_free);
if (ret)
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
return ret;
connector->base.properties = &connector->properties;
connector->dev = dev;
connector->funcs = funcs;
/* connector index is used with 32bit bitmasks */
ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
if (ret < 0) {
DRM_DEBUG_KMS("Failed to allocate %s connector index: %d\n",
drm_connector_enum_list[connector_type].name,
ret);
goto out_put;
}
connector->index = ret;
ret = 0;
connector->connector_type = connector_type;
connector->connector_type_id =
ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
if (connector->connector_type_id < 0) {
ret = connector->connector_type_id;
goto out_put_id;
}
connector->name =
kasprintf(GFP_KERNEL, "%s-%d",
drm_connector_enum_list[connector_type].name,
connector->connector_type_id);
if (!connector->name) {
ret = -ENOMEM;
goto out_put_type_id;
}
INIT_LIST_HEAD(&connector->probed_modes);
INIT_LIST_HEAD(&connector->modes);
mutex_init(&connector->mutex);
connector->edid_blob_ptr = NULL;
connector->tile_blob_ptr = NULL;
connector->status = connector_status_unknown;
connector->display_info.panel_orientation =
DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
drm_connector_get_cmdline_mode(connector);
/* We should add connectors at the end to avoid upsetting the connector
* index too much. */
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
spin_lock_irq(&config->connector_list_lock);
list_add_tail(&connector->head, &config->connector_list);
config->num_connector++;
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
spin_unlock_irq(&config->connector_list_lock);
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-30 00:42:32 +08:00
if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL &&
connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
drm_connector_attach_edid_property(connector);
drm_object_attach_property(&connector->base,
config->dpms_property, 0);
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
drm_object_attach_property(&connector->base,
config->link_status_property,
0);
drm_object_attach_property(&connector->base,
config->non_desktop_property,
0);
drm_object_attach_property(&connector->base,
config->tile_property,
0);
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
}
connector->debugfs_entry = NULL;
out_put_type_id:
if (ret)
ida_simple_remove(connector_ida, connector->connector_type_id);
out_put_id:
if (ret)
ida_simple_remove(&config->connector_ida, connector->index);
out_put:
if (ret)
drm_mode_object_unregister(dev, &connector->base);
return ret;
}
EXPORT_SYMBOL(drm_connector_init);
/**
* drm_connector_init_with_ddc - Init a preallocated connector
* @dev: DRM device
* @connector: the connector to init
* @funcs: callbacks for this connector
* @connector_type: user visible type of the connector
* @ddc: pointer to the associated ddc adapter
*
* Initialises a preallocated connector. Connectors should be
* subclassed as part of driver connector objects.
*
* Ensures that the ddc field of the connector is correctly set.
*
* Returns:
* Zero on success, error code on failure.
*/
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 ret;
ret = drm_connector_init(dev, connector, funcs, connector_type);
if (ret)
return ret;
/* provide ddc symlink in sysfs */
connector->ddc = ddc;
return ret;
}
EXPORT_SYMBOL(drm_connector_init_with_ddc);
/**
* drm_connector_attach_edid_property - attach edid property.
* @connector: the connector
*
* Some connector types like DRM_MODE_CONNECTOR_VIRTUAL do not get a
* edid property attached by default. This function can be used to
* explicitly enable the edid property in these cases.
*/
void drm_connector_attach_edid_property(struct drm_connector *connector)
{
struct drm_mode_config *config = &connector->dev->mode_config;
drm_object_attach_property(&connector->base,
config->edid_property,
0);
}
EXPORT_SYMBOL(drm_connector_attach_edid_property);
/**
* drm_connector_attach_encoder - attach a connector to an encoder
* @connector: connector to attach
* @encoder: encoder to attach @connector to
*
* This function links up a connector to an encoder. Note that the routing
* restrictions between encoders and crtcs are exposed to userspace through the
* possible_clones and possible_crtcs bitmasks.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_attach_encoder(struct drm_connector *connector,
struct drm_encoder *encoder)
{
/*
* In the past, drivers have attempted to model the static association
* of connector to encoder in simple connector/encoder devices using a
* direct assignment of connector->encoder = encoder. This connection
* is a logical one and the responsibility of the core, so drivers are
* expected not to mess with this.
*
* Note that the error return should've been enough here, but a large
* majority of drivers ignores the return value, so add in a big WARN
* to get people's attention.
*/
if (WARN_ON(connector->encoder))
return -EINVAL;
connector->possible_encoders |= drm_encoder_mask(encoder);
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_encoder);
/**
* drm_connector_has_possible_encoder - check if the connector and encoder are
* associated with each other
* @connector: the connector
* @encoder: the encoder
*
* Returns:
* True if @encoder is one of the possible encoders for @connector.
*/
bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder)
{
return connector->possible_encoders & drm_encoder_mask(encoder);
}
EXPORT_SYMBOL(drm_connector_has_possible_encoder);
static void drm_mode_remove(struct drm_connector *connector,
struct drm_display_mode *mode)
{
list_del(&mode->head);
drm_mode_destroy(connector->dev, mode);
}
/**
* drm_connector_cleanup - cleans up an initialised connector
* @connector: connector to cleanup
*
* Cleans up the connector but doesn't free the object.
*/
void drm_connector_cleanup(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode, *t;
/* The connector should have been removed from userspace long before
* it is finally destroyed.
*/
drm/atomic_helper: Stop modesets on unregistered connectors harder Unfortunately, it appears our fix in: commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Which attempted to work around the problems introduced by: commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Is still not the right solution, as modesets can still be triggered outside of drm_atomic_set_crtc_for_connector(). So in order to fix this, while still being careful that we don't break modesets that a driver may perform before being registered with userspace, we replace connector->registered with a tristate member, connector->registration_state. This allows us to keep track of whether or not a connector is still initializing and hasn't been exposed to userspace, is currently registered and exposed to userspace, or has been legitimately removed from the system after having once been present. Using this info, we can prevent userspace from performing new modesets on unregistered connectors while still allowing the driver to perform modesets on unregistered connectors before the driver has finished being registered. Changes since v1: - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this patchset in igt@drv_module_reload@basic-reload-inject and igt@drv_module_reload@basic-reload by checking if the connector is registered instead of unregistered, as calling drm_connector_cleanup() on a connector that hasn't been registered with userspace yet should stay valid. - Remove unregistered_connector_check(), and just go back to what we were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") except replacing READ_ONCE(connector->registered) with drm_connector_is_unregistered(). This gets rid of the behavior of allowing DPMS On<->Off, but that should be fine as it's more consistent with the UAPI we had before - danvet - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet - Update documentation, fix some typos. Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
if (WARN_ON(connector->registration_state ==
DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
if (connector->tile_group) {
drm_mode_put_tile_group(dev, connector->tile_group);
connector->tile_group = NULL;
}
list_for_each_entry_safe(mode, t, &connector->probed_modes, head)
drm_mode_remove(connector, mode);
list_for_each_entry_safe(mode, t, &connector->modes, head)
drm_mode_remove(connector, mode);
ida_simple_remove(&drm_connector_enum_list[connector->connector_type].ida,
connector->connector_type_id);
ida_simple_remove(&dev->mode_config.connector_ida,
connector->index);
kfree(connector->display_info.bus_formats);
drm_mode_object_unregister(dev, &connector->base);
kfree(connector->name);
connector->name = NULL;
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
spin_lock_irq(&dev->mode_config.connector_list_lock);
list_del(&connector->head);
dev->mode_config.num_connector--;
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
spin_unlock_irq(&dev->mode_config.connector_list_lock);
WARN_ON(connector->state && !connector->funcs->atomic_destroy_state);
if (connector->state && connector->funcs->atomic_destroy_state)
connector->funcs->atomic_destroy_state(connector,
connector->state);
mutex_destroy(&connector->mutex);
memset(connector, 0, sizeof(*connector));
}
EXPORT_SYMBOL(drm_connector_cleanup);
/**
* drm_connector_register - register a connector
* @connector: the connector to register
*
* Register userspace interfaces for a connector. Only call this for connectors
* which can be hotplugged after drm_dev_register() has been called already,
* e.g. DP MST connectors. All other connectors will be registered automatically
* when calling drm_dev_register().
*
* Returns:
* Zero on success, error code on failure.
*/
int drm_connector_register(struct drm_connector *connector)
{
int ret = 0;
if (!connector->dev->registered)
return 0;
mutex_lock(&connector->mutex);
drm/atomic_helper: Stop modesets on unregistered connectors harder Unfortunately, it appears our fix in: commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Which attempted to work around the problems introduced by: commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Is still not the right solution, as modesets can still be triggered outside of drm_atomic_set_crtc_for_connector(). So in order to fix this, while still being careful that we don't break modesets that a driver may perform before being registered with userspace, we replace connector->registered with a tristate member, connector->registration_state. This allows us to keep track of whether or not a connector is still initializing and hasn't been exposed to userspace, is currently registered and exposed to userspace, or has been legitimately removed from the system after having once been present. Using this info, we can prevent userspace from performing new modesets on unregistered connectors while still allowing the driver to perform modesets on unregistered connectors before the driver has finished being registered. Changes since v1: - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this patchset in igt@drv_module_reload@basic-reload-inject and igt@drv_module_reload@basic-reload by checking if the connector is registered instead of unregistered, as calling drm_connector_cleanup() on a connector that hasn't been registered with userspace yet should stay valid. - Remove unregistered_connector_check(), and just go back to what we were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") except replacing READ_ONCE(connector->registered) with drm_connector_is_unregistered(). This gets rid of the behavior of allowing DPMS On<->Off, but that should be fine as it's more consistent with the UAPI we had before - danvet - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet - Update documentation, fix some typos. Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
if (connector->registration_state != DRM_CONNECTOR_INITIALIZING)
goto unlock;
ret = drm_sysfs_connector_add(connector);
if (ret)
goto unlock;
drm_debugfs_connector_add(connector);
if (connector->funcs->late_register) {
ret = connector->funcs->late_register(connector);
if (ret)
goto err_debugfs;
}
drm_mode_object_register(connector->dev, &connector->base);
drm/atomic_helper: Stop modesets on unregistered connectors harder Unfortunately, it appears our fix in: commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Which attempted to work around the problems introduced by: commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Is still not the right solution, as modesets can still be triggered outside of drm_atomic_set_crtc_for_connector(). So in order to fix this, while still being careful that we don't break modesets that a driver may perform before being registered with userspace, we replace connector->registered with a tristate member, connector->registration_state. This allows us to keep track of whether or not a connector is still initializing and hasn't been exposed to userspace, is currently registered and exposed to userspace, or has been legitimately removed from the system after having once been present. Using this info, we can prevent userspace from performing new modesets on unregistered connectors while still allowing the driver to perform modesets on unregistered connectors before the driver has finished being registered. Changes since v1: - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this patchset in igt@drv_module_reload@basic-reload-inject and igt@drv_module_reload@basic-reload by checking if the connector is registered instead of unregistered, as calling drm_connector_cleanup() on a connector that hasn't been registered with userspace yet should stay valid. - Remove unregistered_connector_check(), and just go back to what we were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") except replacing READ_ONCE(connector->registered) with drm_connector_is_unregistered(). This gets rid of the behavior of allowing DPMS On<->Off, but that should be fine as it's more consistent with the UAPI we had before - danvet - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet - Update documentation, fix some typos. Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
connector->registration_state = DRM_CONNECTOR_REGISTERED;
goto unlock;
err_debugfs:
drm_debugfs_connector_remove(connector);
drm_sysfs_connector_remove(connector);
unlock:
mutex_unlock(&connector->mutex);
return ret;
}
EXPORT_SYMBOL(drm_connector_register);
/**
* drm_connector_unregister - unregister a connector
* @connector: the connector to unregister
*
* Unregister userspace interfaces for a connector. Only call this for
* connectors which have registered explicitly by calling drm_dev_register(),
* since connectors are unregistered automatically when drm_dev_unregister() is
* called.
*/
void drm_connector_unregister(struct drm_connector *connector)
{
mutex_lock(&connector->mutex);
drm/atomic_helper: Stop modesets on unregistered connectors harder Unfortunately, it appears our fix in: commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Which attempted to work around the problems introduced by: commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Is still not the right solution, as modesets can still be triggered outside of drm_atomic_set_crtc_for_connector(). So in order to fix this, while still being careful that we don't break modesets that a driver may perform before being registered with userspace, we replace connector->registered with a tristate member, connector->registration_state. This allows us to keep track of whether or not a connector is still initializing and hasn't been exposed to userspace, is currently registered and exposed to userspace, or has been legitimately removed from the system after having once been present. Using this info, we can prevent userspace from performing new modesets on unregistered connectors while still allowing the driver to perform modesets on unregistered connectors before the driver has finished being registered. Changes since v1: - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this patchset in igt@drv_module_reload@basic-reload-inject and igt@drv_module_reload@basic-reload by checking if the connector is registered instead of unregistered, as calling drm_connector_cleanup() on a connector that hasn't been registered with userspace yet should stay valid. - Remove unregistered_connector_check(), and just go back to what we were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") except replacing READ_ONCE(connector->registered) with drm_connector_is_unregistered(). This gets rid of the behavior of allowing DPMS On<->Off, but that should be fine as it's more consistent with the UAPI we had before - danvet - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet - Update documentation, fix some typos. Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
if (connector->registration_state != DRM_CONNECTOR_REGISTERED) {
mutex_unlock(&connector->mutex);
return;
}
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
drm_sysfs_connector_remove(connector);
drm_debugfs_connector_remove(connector);
drm/atomic_helper: Stop modesets on unregistered connectors harder Unfortunately, it appears our fix in: commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Which attempted to work around the problems introduced by: commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Is still not the right solution, as modesets can still be triggered outside of drm_atomic_set_crtc_for_connector(). So in order to fix this, while still being careful that we don't break modesets that a driver may perform before being registered with userspace, we replace connector->registered with a tristate member, connector->registration_state. This allows us to keep track of whether or not a connector is still initializing and hasn't been exposed to userspace, is currently registered and exposed to userspace, or has been legitimately removed from the system after having once been present. Using this info, we can prevent userspace from performing new modesets on unregistered connectors while still allowing the driver to perform modesets on unregistered connectors before the driver has finished being registered. Changes since v1: - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this patchset in igt@drv_module_reload@basic-reload-inject and igt@drv_module_reload@basic-reload by checking if the connector is registered instead of unregistered, as calling drm_connector_cleanup() on a connector that hasn't been registered with userspace yet should stay valid. - Remove unregistered_connector_check(), and just go back to what we were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") except replacing READ_ONCE(connector->registered) with drm_connector_is_unregistered(). This gets rid of the behavior of allowing DPMS On<->Off, but that should be fine as it's more consistent with the UAPI we had before - danvet - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet - Update documentation, fix some typos. Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
2018-10-17 04:39:46 +08:00
connector->registration_state = DRM_CONNECTOR_UNREGISTERED;
mutex_unlock(&connector->mutex);
}
EXPORT_SYMBOL(drm_connector_unregister);
void drm_connector_unregister_all(struct drm_device *dev)
{
struct drm_connector *connector;
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
struct drm_connector_list_iter conn_iter;
drm_connector_list_iter_begin(dev, &conn_iter);
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
drm_for_each_connector_iter(connector, &conn_iter)
drm_connector_unregister(connector);
drm_connector_list_iter_end(&conn_iter);
}
int drm_connector_register_all(struct drm_device *dev)
{
struct drm_connector *connector;
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
struct drm_connector_list_iter conn_iter;
int ret = 0;
drm_connector_list_iter_begin(dev, &conn_iter);
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
drm_for_each_connector_iter(connector, &conn_iter) {
ret = drm_connector_register(connector);
if (ret)
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
break;
}
drm_connector_list_iter_end(&conn_iter);
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
if (ret)
drm_connector_unregister_all(dev);
return ret;
}
/**
* drm_get_connector_status_name - return a string for connector status
* @status: connector status to compute name of
*
* In contrast to the other drm_get_*_name functions this one here returns a
* const pointer and hence is threadsafe.
*/
const char *drm_get_connector_status_name(enum drm_connector_status status)
{
if (status == connector_status_connected)
return "connected";
else if (status == connector_status_disconnected)
return "disconnected";
else
return "unknown";
}
EXPORT_SYMBOL(drm_get_connector_status_name);
/**
* drm_get_connector_force_name - return a string for connector force
* @force: connector force to get name of
*
* Returns: const pointer to name.
*/
const char *drm_get_connector_force_name(enum drm_connector_force force)
{
switch (force) {
case DRM_FORCE_UNSPECIFIED:
return "unspecified";
case DRM_FORCE_OFF:
return "off";
case DRM_FORCE_ON:
return "on";
case DRM_FORCE_ON_DIGITAL:
return "digital";
default:
return "unknown";
}
}
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
#ifdef CONFIG_LOCKDEP
static struct lockdep_map connector_list_iter_dep_map = {
.name = "drm_connector_list_iter"
};
#endif
/**
* drm_connector_list_iter_begin - initialize a connector_list iterator
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
* @dev: DRM device
* @iter: connector_list iterator
*
* Sets @iter up to walk the &drm_mode_config.connector_list of @dev. @iter
* must always be cleaned up again by calling drm_connector_list_iter_end().
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
* Iteration itself happens using drm_connector_list_iter_next() or
* drm_for_each_connector_iter().
*/
void drm_connector_list_iter_begin(struct drm_device *dev,
struct drm_connector_list_iter *iter)
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
{
iter->dev = dev;
iter->conn = NULL;
lock_acquire_shared_recursive(&connector_list_iter_dep_map, 0, 1, NULL, _RET_IP_);
}
EXPORT_SYMBOL(drm_connector_list_iter_begin);
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
/*
* Extra-safe connector put function that works in any context. Should only be
* used from the connector_iter functions, where we never really expect to
* actually release the connector when dropping our final reference.
*/
static void
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 20:49:36 +08:00
__drm_connector_put_safe(struct drm_connector *conn)
{
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 20:49:36 +08:00
struct drm_mode_config *config = &conn->dev->mode_config;
lockdep_assert_held(&config->connector_list_lock);
if (!refcount_dec_and_test(&conn->base.refcount.refcount))
return;
llist_add(&conn->free_node, &config->connector_free_list);
schedule_work(&config->connector_free_work);
}
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
/**
* drm_connector_list_iter_next - return next connector
* @iter: connector_list iterator
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
*
* Returns the next connector for @iter, or NULL when the list walk has
* completed.
*/
struct drm_connector *
drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
{
struct drm_connector *old_conn = iter->conn;
struct drm_mode_config *config = &iter->dev->mode_config;
struct list_head *lhead;
unsigned long flags;
spin_lock_irqsave(&config->connector_list_lock, flags);
lhead = old_conn ? &old_conn->head : &config->connector_list;
do {
if (lhead->next == &config->connector_list) {
iter->conn = NULL;
break;
}
lhead = lhead->next;
iter->conn = list_entry(lhead, struct drm_connector, head);
/* loop until it's not a zombie connector */
} while (!kref_get_unless_zero(&iter->conn->base.refcount));
if (old_conn)
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 20:49:36 +08:00
__drm_connector_put_safe(old_conn);
spin_unlock_irqrestore(&config->connector_list_lock, flags);
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
return iter->conn;
}
EXPORT_SYMBOL(drm_connector_list_iter_next);
/**
* drm_connector_list_iter_end - tear down a connector_list iterator
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
* @iter: connector_list iterator
*
* Tears down @iter and releases any resources (like &drm_connector references)
* acquired while walking the list. This must always be called, both when the
* iteration completes fully or when it was aborted without walking the entire
* list.
*/
void drm_connector_list_iter_end(struct drm_connector_list_iter *iter)
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
{
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 20:49:36 +08:00
struct drm_mode_config *config = &iter->dev->mode_config;
unsigned long flags;
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
iter->dev = NULL;
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 20:49:36 +08:00
if (iter->conn) {
spin_lock_irqsave(&config->connector_list_lock, flags);
__drm_connector_put_safe(iter->conn);
spin_unlock_irqrestore(&config->connector_list_lock, flags);
}
2019-09-20 00:09:40 +08:00
lock_release(&connector_list_iter_dep_map, _RET_IP_);
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
}
EXPORT_SYMBOL(drm_connector_list_iter_end);
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 07:08:06 +08:00
static const struct drm_prop_enum_list drm_subpixel_enum_list[] = {
{ SubPixelUnknown, "Unknown" },
{ SubPixelHorizontalRGB, "Horizontal RGB" },
{ SubPixelHorizontalBGR, "Horizontal BGR" },
{ SubPixelVerticalRGB, "Vertical RGB" },
{ SubPixelVerticalBGR, "Vertical BGR" },
{ SubPixelNone, "None" },
};
/**
* drm_get_subpixel_order_name - return a string for a given subpixel enum
* @order: enum of subpixel_order
*
* Note you could abuse this and return something out of bounds, but that
* would be a caller error. No unscrubbed user data should make it here.
*/
const char *drm_get_subpixel_order_name(enum subpixel_order order)
{
return drm_subpixel_enum_list[order].name;
}
EXPORT_SYMBOL(drm_get_subpixel_order_name);
static const struct drm_prop_enum_list drm_dpms_enum_list[] = {
{ DRM_MODE_DPMS_ON, "On" },
{ DRM_MODE_DPMS_STANDBY, "Standby" },
{ DRM_MODE_DPMS_SUSPEND, "Suspend" },
{ DRM_MODE_DPMS_OFF, "Off" }
};
DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
{ DRM_MODE_LINK_STATUS_GOOD, "Good" },
{ DRM_MODE_LINK_STATUS_BAD, "Bad" },
};
/**
* drm_display_info_set_bus_formats - set the supported bus formats
* @info: display info to store bus formats in
* @formats: array containing the supported bus formats
* @num_formats: the number of entries in the fmts array
*
* Store the supported bus formats in display info structure.
* See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
* a full list of available formats.
*/
int drm_display_info_set_bus_formats(struct drm_display_info *info,
const u32 *formats,
unsigned int num_formats)
{
u32 *fmts = NULL;
if (!formats && num_formats)
return -EINVAL;
if (formats && num_formats) {
fmts = kmemdup(formats, sizeof(*formats) * num_formats,
GFP_KERNEL);
if (!fmts)
return -ENOMEM;
}
kfree(info->bus_formats);
info->bus_formats = fmts;
info->num_bus_formats = num_formats;
return 0;
}
EXPORT_SYMBOL(drm_display_info_set_bus_formats);
/* Optional connector properties. */
static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_NONE, "None" },
{ DRM_MODE_SCALE_FULLSCREEN, "Full" },
{ DRM_MODE_SCALE_CENTER, "Center" },
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
};
static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
};
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 21:59:27 +08:00
static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
{ DRM_MODE_CONTENT_TYPE_NO_DATA, "No Data" },
{ DRM_MODE_CONTENT_TYPE_GRAPHICS, "Graphics" },
{ DRM_MODE_CONTENT_TYPE_PHOTO, "Photo" },
{ DRM_MODE_CONTENT_TYPE_CINEMA, "Cinema" },
{ DRM_MODE_CONTENT_TYPE_GAME, "Game" },
};
static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL, "Normal" },
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down" },
{ DRM_MODE_PANEL_ORIENTATION_LEFT_UP, "Left Side Up" },
{ DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, "Right Side Up" },
};
static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
{ DRM_MODE_SUBCONNECTOR_DVIA, "DVI-A" }, /* DVI-I */
};
DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
{ DRM_MODE_SUBCONNECTOR_DVIA, "DVI-A" }, /* DVI-I */
};
DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
drm_dvi_i_subconnector_enum_list)
static const struct drm_prop_enum_list drm_tv_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_SVIDEO, "SVIDEO" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_Component, "Component" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_SCART, "SCART" }, /* TV-out */
};
DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_SVIDEO, "SVIDEO" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_Component, "Component" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_SCART, "SCART" }, /* TV-out */
};
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
/* Standard Definition Colorimetry based on CEA 861 */
{ DRM_MODE_COLORIMETRY_SMPTE_170M_YCC, "SMPTE_170M_YCC" },
{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
/* Standard Definition Colorimetry based on IEC 61966-2-4 */
{ DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
/* High Definition Colorimetry based on IEC 61966-2-4 */
{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
{ DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
/* Colorimetry based on IEC 61966-2-5 [33] */
{ DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
/* Colorimetry based on IEC 61966-2-5 */
{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
/* Colorimetry based on ITU-R BT.2020 */
{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
/* Colorimetry based on ITU-R BT.2020 */
{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
/* Colorimetry based on ITU-R BT.2020 */
{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
/* Added as part of Additional Colorimetry Extension in 861.G */
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
/*
* As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
* Format Table 2-120
*/
static const struct drm_prop_enum_list dp_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
{ DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
/* Colorimetry based on scRGB (IEC 61966-2-2) */
{ DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point" },
/* Colorimetry based on IEC 61966-2-5 */
{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
/* Colorimetry based on SMPTE RP 431-2 */
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
/* Colorimetry based on ITU-R BT.2020 */
{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
{ DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
/* Standard Definition Colorimetry based on IEC 61966-2-4 */
{ DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
/* High Definition Colorimetry based on IEC 61966-2-4 */
{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
{ DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
/* Colorimetry based on IEC 61966-2-5 [33] */
{ DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
/* Colorimetry based on ITU-R BT.2020 */
{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
/* Colorimetry based on ITU-R BT.2020 */
{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
};
/**
* DOC: standard connector properties
*
* DRM connectors have a few standardized properties:
*
* EDID:
* Blob property which contains the current EDID read from the sink. This
* is useful to parse sink identification information like vendor, model
* and serial. Drivers should update this property by calling
* drm_connector_update_edid_property(), usually after having parsed
* the EDID using drm_add_edid_modes(). Userspace cannot change this
* property.
* DPMS:
* Legacy property for setting the power state of the connector. For atomic
* drivers this is only provided for backwards compatibility with existing
* drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
* connector is linked to. Drivers should never set this property directly,
* it is handled by the DRM core by calling the &drm_connector_funcs.dpms
* callback. For atomic drivers the remapping to the "ACTIVE" property is
* implemented in the DRM core.
*
* Note that this property cannot be set through the MODE_ATOMIC ioctl,
* userspace must use "ACTIVE" on the CRTC instead.
*
* WARNING:
*
* For userspace also running on legacy drivers the "DPMS" semantics are a
* lot more complicated. First, userspace cannot rely on the "DPMS" value
* returned by the GETCONNECTOR actually reflecting reality, because many
* drivers fail to update it. For atomic drivers this is taken care of in
* drm_atomic_helper_update_legacy_modeset_state().
*
* The second issue is that the DPMS state is only well-defined when the
* connector is connected to a CRTC. In atomic the DRM core enforces that
* "ACTIVE" is off in such a case, no such checks exists for "DPMS".
*
* Finally, when enabling an output using the legacy SETCONFIG ioctl then
* "DPMS" is forced to ON. But see above, that might not be reflected in
* the software value on legacy drivers.
*
* Summarizing: Only set "DPMS" when the connector is known to be enabled,
* assume that a successful SETCONFIG call also sets "DPMS" to on, and
* never read back the value of "DPMS" because it can be incorrect.
* PATH:
* Connector path property to identify how this sink is physically
* connected. Used by DP MST. This should be set by calling
* drm_connector_set_path_property(), in the case of DP MST with the
* path property the MST manager created. Userspace cannot change this
* property.
* TILE:
* Connector tile group property to indicate how a set of DRM connector
* compose together into one logical screen. This is used by both high-res
* external screens (often only using a single cable, but exposing multiple
* DP MST sinks), or high-res integrated panels (like dual-link DSI) which
* are not gen-locked. Note that 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. Drivers
* should update this value using drm_connector_set_tile_property().
* Userspace cannot change this property.
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
* link-status:
* Connector link-status property to indicate the status of link. The
* default value of link-status is "GOOD". If something fails during or
* after modeset, the kernel driver may set this to "BAD" and issue a
* hotplug uevent. Drivers should update this value using
* drm_connector_set_link_status_property().
*
* When user-space receives the hotplug uevent and detects a "BAD"
* link-status, the sink doesn't receive pixels anymore (e.g. the screen
* becomes completely black). The list of available modes may have
* changed. User-space is expected to pick a new mode if the current one
* has disappeared and perform a new modeset with link-status set to
* "GOOD" to re-enable the connector.
*
* If multiple connectors share the same CRTC and one of them gets a "BAD"
* link-status, the other are unaffected (ie. the sinks still continue to
* receive pixels).
*
* When user-space performs an atomic commit on a connector with a "BAD"
* link-status without resetting the property to "GOOD", the sink may
* still not receive pixels. When user-space performs an atomic commit
* which resets the link-status property to "GOOD" without the
* ALLOW_MODESET flag set, it might fail because a modeset is required.
*
* User-space can only change link-status to "GOOD", changing it to "BAD"
* is a no-op.
*
* For backwards compatibility with non-atomic userspace the kernel
* tries to automatically set the link-status back to "GOOD" in the
* SETCRTC IOCTL. This might fail if the mode is no longer valid, similar
* to how it might fail if a different screen has been connected in the
* interim.
* non_desktop:
* Indicates the output should be ignored for purposes of displaying a
* standard desktop environment or console. This is most likely because
* the output device is not rectilinear.
2018-01-09 03:55:37 +08:00
* Content Protection:
* This property is used by userspace to request the kernel protect future
* content communicated over the link. When requested, kernel will apply
* the appropriate means of protection (most often HDCP), and use the
* property to tell userspace the protection is active.
*
* Drivers can set this up by calling
* drm_connector_attach_content_protection_property() on initialization.
*
* The value of this property can be one of the following:
*
* DRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0
2018-01-09 03:55:37 +08:00
* The link is not protected, content is transmitted in the clear.
* DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
2018-01-09 03:55:37 +08:00
* Userspace has requested content protection, but the link is not
* currently protected. When in this state, kernel should enable
* Content Protection as soon as possible.
* DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
2018-01-09 03:55:37 +08:00
* Userspace has requested content protection, and the link is
* protected. Only the driver can set the property to this value.
* If userspace attempts to set to ENABLED, kernel will return
* -EINVAL.
*
* A few guidelines:
*
* - DESIRED state should be preserved until userspace de-asserts it by
* setting the property to UNDESIRED. This means ENABLED should only
* transition to UNDESIRED when the user explicitly requests it.
* - If the state is DESIRED, kernel should attempt to re-authenticate the
* link whenever possible. This includes across disable/enable, dpms,
* hotplug, downstream device changes, link status failures, etc..
* - Kernel sends uevent with the connector id and property id through
* @drm_hdcp_update_content_protection, upon below kernel triggered
* scenarios:
*
* - DESIRED -> ENABLED (authentication success)
* - ENABLED -> DESIRED (termination of authentication)
* - Please note no uevents for userspace triggered property state changes,
* which can't fail such as
*
* - DESIRED/ENABLED -> UNDESIRED
* - UNDESIRED -> DESIRED
* - Userspace is responsible for polling the property or listen to uevents
* to determine when the value transitions from ENABLED to DESIRED.
* This signifies the link is no longer protected and userspace should
* take appropriate action (whatever that might be).
*
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 19:41:14 +08:00
* HDCP Content Type:
* This Enum property is used by the userspace to declare the content type
* of the display stream, to kernel. Here display stream stands for any
* display content that userspace intended to display through HDCP
* encryption.
*
* Content Type of a stream is decided by the owner of the stream, as
* "HDCP Type0" or "HDCP Type1".
*
* The value of the property can be one of the below:
* - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
* - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
*
* When kernel starts the HDCP authentication (see "Content Protection"
* for details), it uses the content type in "HDCP Content Type"
* for performing the HDCP authentication with the display sink.
*
* Please note in HDCP spec versions, a link can be authenticated with
* HDCP 2.2 for Content Type 0/Content Type 1. Where as a link can be
* authenticated with HDCP1.4 only for Content Type 0(though it is implicit
* in nature. As there is no reference for Content Type in HDCP1.4).
*
* HDCP2.2 authentication protocol itself takes the "Content Type" as a
* parameter, which is a input for the DP HDCP2.2 encryption algo.
*
* In case of Type 0 content protection request, kernel driver can choose
* either of HDCP spec versions 1.4 and 2.2. When HDCP2.2 is used for
* "HDCP Type 0", a HDCP 2.2 capable repeater in the downstream can send
* that content to a HDCP 1.4 authenticated HDCP sink (Type0 link).
* But if the content is classified as "HDCP Type 1", above mentioned
* HDCP 2.2 repeater wont send the content to the HDCP sink as it can't
* authenticate the HDCP1.4 capable sink for "HDCP Type 1".
*
* Please note userspace can be ignorant of the HDCP versions used by the
* kernel driver to achieve the "HDCP Content Type".
*
* At current scenario, classifying a content as Type 1 ensures that the
* content will be displayed only through the HDCP2.2 encrypted link.
*
* Note that the HDCP Content Type property is introduced at HDCP 2.2, and
* defaults to type 0. It is only exposed by drivers supporting HDCP 2.2
* (hence supporting Type 0 and Type 1). Based on how next versions of
* HDCP specs are defined content Type could be used for higher versions
* too.
*
* If content type is changed when "Content Protection" is not UNDESIRED,
* then kernel will disable the HDCP and re-enable with new type in the
* same atomic commit. And when "Content Protection" is ENABLED, it means
* that link is HDCP authenticated and encrypted, for the transmission of
* the Type of stream mentioned at "HDCP Content Type".
*
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 19:17:02 +08:00
* HDR_OUTPUT_METADATA:
* Connector property to enable userspace to send HDR Metadata to
* driver. This metadata is based on the composition and blending
* policies decided by user, taking into account the hardware and
* sink capabilities. The driver gets this metadata and creates a
* Dynamic Range and Mastering Infoframe (DRM) in case of HDMI,
* SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then
* sent to sink. This notifies the sink of the upcoming frame's Color
* Encoding and Luminance parameters.
*
* Userspace first need to detect the HDR capabilities of sink by
* reading and parsing the EDID. Details of HDR metadata for HDMI
* are added in CTA 861.G spec. For DP , its defined in VESA DP
* Standard v1.4. It needs to then get the metadata information
* of the video/game/app content which are encoded in HDR (basically
* using HDR transfer functions). With this information it needs to
* decide on a blending policy and compose the relevant
* layers/overlays into a common format. Once this blending is done,
* userspace will be aware of the metadata of the composed frame to
* be send to sink. It then uses this property to communicate this
* metadata to driver which then make a Infoframe packet and sends
* to sink based on the type of encoder connected.
*
* Userspace will be responsible to do Tone mapping operation in case:
* - Some layers are HDR and others are SDR
* - HDR layers luminance is not same as sink
*
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 19:17:02 +08:00
* It will even need to do colorspace conversion and get all layers
* to one common colorspace for blending. It can use either GL, Media
* or display engine to get this done based on the capabilties of the
* associated hardware.
*
* Driver expects metadata to be put in &struct hdr_output_metadata
* structure from userspace. This is received as blob and stored in
* &drm_connector_state.hdr_output_metadata. It parses EDID and saves the
* sink metadata in &struct hdr_sink_metadata, as
* &drm_connector.hdr_sink_metadata. Driver uses
* drm_hdmi_infoframe_set_hdr_metadata() helper to set the HDR metadata,
* hdmi_drm_infoframe_pack() to pack the infoframe as per spec, in case of
* HDMI encoder.
*
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-13 02:42:32 +08:00
* max bpc:
* This range property is used by userspace to limit the bit depth. When
* used the driver would limit the bpc in accordance with the valid range
* supported by the hardware and sink. Drivers to use the function
* drm_connector_attach_max_bpc_property() to create and attach the
* property to the connector during initialization.
*
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
* Mode object ID of the &drm_crtc this connector should be connected to.
*
* Connectors for LCD panels may also have one standardized property:
*
* panel orientation:
* On some devices the LCD panel is mounted in the casing in such a way
* that the up/top side of the panel does not match with the top side of
* the device. Userspace can use this property to check for this.
* Note that input coordinates from touchscreens (input devices with
* INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
* coordinates, so if userspace rotates the picture to adjust for
* the orientation it must also apply the same transformation to the
* touchscreen input coordinates. This property is initialized by calling
* drm_connector_set_panel_orientation() or
* drm_connector_set_panel_orientation_with_quirk()
*
* scaling mode:
* This property defines how a non-native mode is upscaled to the native
* mode of an LCD panel:
*
* None:
* No upscaling happens, scaling is left to the panel. Not all
* drivers expose this mode.
* Full:
* The output is upscaled to the full resolution of the panel,
* ignoring the aspect ratio.
* Center:
* No upscaling happens, the output is centered within the native
* resolution the panel.
* Full aspect:
* The output is upscaled to maximize either the width or height
* while retaining the aspect ratio.
*
* This property should be set up by calling
* drm_connector_attach_scaling_mode_property(). Note that drivers
* can also expose this property to external outputs, in which case they
* must support "None", which should be the default (since external screens
* have a built-in scaler).
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
{
struct drm_property *prop;
prop = drm_property_create(dev, DRM_MODE_PROP_BLOB |
DRM_MODE_PROP_IMMUTABLE,
"EDID", 0);
if (!prop)
return -ENOMEM;
dev->mode_config.edid_property = prop;
prop = drm_property_create_enum(dev, 0,
"DPMS", drm_dpms_enum_list,
ARRAY_SIZE(drm_dpms_enum_list));
if (!prop)
return -ENOMEM;
dev->mode_config.dpms_property = prop;
prop = drm_property_create(dev,
DRM_MODE_PROP_BLOB |
DRM_MODE_PROP_IMMUTABLE,
"PATH", 0);
if (!prop)
return -ENOMEM;
dev->mode_config.path_property = prop;
prop = drm_property_create(dev,
DRM_MODE_PROP_BLOB |
DRM_MODE_PROP_IMMUTABLE,
"TILE", 0);
if (!prop)
return -ENOMEM;
dev->mode_config.tile_property = prop;
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
prop = drm_property_create_enum(dev, 0, "link-status",
drm_link_status_enum_list,
ARRAY_SIZE(drm_link_status_enum_list));
if (!prop)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE, "non-desktop");
if (!prop)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
"HDR_OUTPUT_METADATA", 0);
if (!prop)
return -ENOMEM;
dev->mode_config.hdr_output_metadata_property = prop;
return 0;
}
/**
* drm_mode_create_dvi_i_properties - create DVI-I specific connector properties
* @dev: DRM device
*
* Called by a driver the first time a DVI-I connector is made.
*/
int drm_mode_create_dvi_i_properties(struct drm_device *dev)
{
struct drm_property *dvi_i_selector;
struct drm_property *dvi_i_subconnector;
if (dev->mode_config.dvi_i_select_subconnector_property)
return 0;
dvi_i_selector =
drm_property_create_enum(dev, 0,
"select subconnector",
drm_dvi_i_select_enum_list,
ARRAY_SIZE(drm_dvi_i_select_enum_list));
dev->mode_config.dvi_i_select_subconnector_property = dvi_i_selector;
dvi_i_subconnector = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
"subconnector",
drm_dvi_i_subconnector_enum_list,
ARRAY_SIZE(drm_dvi_i_subconnector_enum_list));
dev->mode_config.dvi_i_subconnector_property = dvi_i_subconnector;
return 0;
}
EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
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 21:59:27 +08:00
/**
* DOC: HDMI connector properties
*
* content type (HDMI specific):
* Indicates content type setting to be used in HDMI infoframes to indicate
* content type for the external device, so that it adjusts its display
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 21:59:27 +08:00
* settings accordingly.
*
* The value of this property can be one of the following:
*
* No Data:
* Content type is unknown
* Graphics:
* Content type is graphics
* Photo:
* Content type is photo
* Cinema:
* Content type is cinema
* Game:
* Content type is game
*
* Drivers can set up this property by calling
* drm_connector_attach_content_type_property(). Decoding to
* infoframe values is done through drm_hdmi_avi_infoframe_content_type().
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 21:59:27 +08:00
*/
/**
* drm_connector_attach_content_type_property - attach content-type property
* @connector: connector to attach content type property on.
*
* Called by a driver the first time a HDMI connector is made.
*/
int drm_connector_attach_content_type_property(struct drm_connector *connector)
{
if (!drm_mode_create_content_type_property(connector->dev))
drm_object_attach_property(&connector->base,
connector->dev->mode_config.content_type_property,
DRM_MODE_CONTENT_TYPE_NO_DATA);
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_content_type_property);
/**
* drm_hdmi_avi_infoframe_content_type() - fill the HDMI AVI infoframe
* content type information, based
* on correspondent DRM property.
* @frame: HDMI AVI infoframe
* @conn_state: DRM display connector state
*
*/
void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame,
const struct drm_connector_state *conn_state)
{
switch (conn_state->content_type) {
case DRM_MODE_CONTENT_TYPE_GRAPHICS:
frame->content_type = HDMI_CONTENT_TYPE_GRAPHICS;
break;
case DRM_MODE_CONTENT_TYPE_CINEMA:
frame->content_type = HDMI_CONTENT_TYPE_CINEMA;
break;
case DRM_MODE_CONTENT_TYPE_GAME:
frame->content_type = HDMI_CONTENT_TYPE_GAME;
break;
case DRM_MODE_CONTENT_TYPE_PHOTO:
frame->content_type = HDMI_CONTENT_TYPE_PHOTO;
break;
default:
/* Graphics is the default(0) */
frame->content_type = HDMI_CONTENT_TYPE_GRAPHICS;
}
frame->itc = conn_state->content_type != DRM_MODE_CONTENT_TYPE_NO_DATA;
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_content_type);
/**
* drm_mode_attach_tv_margin_properties - attach TV connector margin properties
* @connector: DRM connector
*
* Called by a driver when it needs to attach TV margin props to a connector.
* Typically used on SDTV and HDMI connectors.
*/
void drm_connector_attach_tv_margin_properties(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
drm_object_attach_property(&connector->base,
dev->mode_config.tv_left_margin_property,
0);
drm_object_attach_property(&connector->base,
dev->mode_config.tv_right_margin_property,
0);
drm_object_attach_property(&connector->base,
dev->mode_config.tv_top_margin_property,
0);
drm_object_attach_property(&connector->base,
dev->mode_config.tv_bottom_margin_property,
0);
}
EXPORT_SYMBOL(drm_connector_attach_tv_margin_properties);
/**
* drm_mode_create_tv_margin_properties - create TV connector margin properties
* @dev: DRM device
*
* Called by a driver's HDMI connector initialization routine, this function
* creates the TV margin properties for a given device. No need to call this
* function for an SDTV connector, it's already called from
* drm_mode_create_tv_properties().
*/
int drm_mode_create_tv_margin_properties(struct drm_device *dev)
{
if (dev->mode_config.tv_left_margin_property)
return 0;
dev->mode_config.tv_left_margin_property =
drm_property_create_range(dev, 0, "left margin", 0, 100);
if (!dev->mode_config.tv_left_margin_property)
return -ENOMEM;
dev->mode_config.tv_right_margin_property =
drm_property_create_range(dev, 0, "right margin", 0, 100);
if (!dev->mode_config.tv_right_margin_property)
return -ENOMEM;
dev->mode_config.tv_top_margin_property =
drm_property_create_range(dev, 0, "top margin", 0, 100);
if (!dev->mode_config.tv_top_margin_property)
return -ENOMEM;
dev->mode_config.tv_bottom_margin_property =
drm_property_create_range(dev, 0, "bottom margin", 0, 100);
if (!dev->mode_config.tv_bottom_margin_property)
return -ENOMEM;
return 0;
}
EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
/**
* drm_mode_create_tv_properties - create TV specific connector properties
* @dev: DRM device
* @num_modes: number of different TV formats (modes) supported
* @modes: array of pointers to strings containing name of each format
*
* Called by a driver's TV initialization routine, this function creates
* the TV specific connector properties for a given device. Caller is
* responsible for allocating a list of format names and passing them to
* this routine.
*/
int drm_mode_create_tv_properties(struct drm_device *dev,
unsigned int num_modes,
const char * const modes[])
{
struct drm_property *tv_selector;
struct drm_property *tv_subconnector;
unsigned int i;
if (dev->mode_config.tv_select_subconnector_property)
return 0;
/*
* Basic connector properties
*/
tv_selector = drm_property_create_enum(dev, 0,
"select subconnector",
drm_tv_select_enum_list,
ARRAY_SIZE(drm_tv_select_enum_list));
if (!tv_selector)
goto nomem;
dev->mode_config.tv_select_subconnector_property = tv_selector;
tv_subconnector =
drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
"subconnector",
drm_tv_subconnector_enum_list,
ARRAY_SIZE(drm_tv_subconnector_enum_list));
if (!tv_subconnector)
goto nomem;
dev->mode_config.tv_subconnector_property = tv_subconnector;
/*
* Other, TV specific properties: margins & TV modes.
*/
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
dev->mode_config.tv_mode_property =
drm_property_create(dev, DRM_MODE_PROP_ENUM,
"mode", num_modes);
if (!dev->mode_config.tv_mode_property)
goto nomem;
for (i = 0; i < num_modes; i++)
drm_property_add_enum(dev->mode_config.tv_mode_property,
i, modes[i]);
dev->mode_config.tv_brightness_property =
drm_property_create_range(dev, 0, "brightness", 0, 100);
if (!dev->mode_config.tv_brightness_property)
goto nomem;
dev->mode_config.tv_contrast_property =
drm_property_create_range(dev, 0, "contrast", 0, 100);
if (!dev->mode_config.tv_contrast_property)
goto nomem;
dev->mode_config.tv_flicker_reduction_property =
drm_property_create_range(dev, 0, "flicker reduction", 0, 100);
if (!dev->mode_config.tv_flicker_reduction_property)
goto nomem;
dev->mode_config.tv_overscan_property =
drm_property_create_range(dev, 0, "overscan", 0, 100);
if (!dev->mode_config.tv_overscan_property)
goto nomem;
dev->mode_config.tv_saturation_property =
drm_property_create_range(dev, 0, "saturation", 0, 100);
if (!dev->mode_config.tv_saturation_property)
goto nomem;
dev->mode_config.tv_hue_property =
drm_property_create_range(dev, 0, "hue", 0, 100);
if (!dev->mode_config.tv_hue_property)
goto nomem;
return 0;
nomem:
return -ENOMEM;
}
EXPORT_SYMBOL(drm_mode_create_tv_properties);
/**
* drm_mode_create_scaling_mode_property - create scaling mode property
* @dev: DRM device
*
* Called by a driver the first time it's needed, must be attached to desired
* connectors.
*
* Atomic drivers should use drm_connector_attach_scaling_mode_property()
* instead to correctly assign &drm_connector_state.picture_aspect_ratio
* in the atomic state.
*/
int drm_mode_create_scaling_mode_property(struct drm_device *dev)
{
struct drm_property *scaling_mode;
if (dev->mode_config.scaling_mode_property)
return 0;
scaling_mode =
drm_property_create_enum(dev, 0, "scaling mode",
drm_scaling_mode_enum_list,
ARRAY_SIZE(drm_scaling_mode_enum_list));
dev->mode_config.scaling_mode_property = scaling_mode;
return 0;
}
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
/**
* DOC: Variable refresh properties
*
* Variable refresh rate capable displays can dynamically adjust their
* refresh rate by extending the duration of their vertical front porch
* until page flip or timeout occurs. This can reduce or remove stuttering
* and latency in scenarios where the page flip does not align with the
* vblank interval.
*
* An example scenario would be an application flipping at a constant rate
* of 48Hz on a 60Hz display. The page flip will frequently miss the vblank
* interval and the same contents will be displayed twice. This can be
* observed as stuttering for content with motion.
*
* If variable refresh rate was active on a display that supported a
* variable refresh range from 35Hz to 60Hz no stuttering would be observable
* for the example scenario. The minimum supported variable refresh rate of
* 35Hz is below the page flip frequency and the vertical front porch can
* be extended until the page flip occurs. The vblank interval will be
* directly aligned to the page flip rate.
*
* Not all userspace content is suitable for use with variable refresh rate.
* Large and frequent changes in vertical front porch duration may worsen
* perceived stuttering for input sensitive applications.
*
* Panel brightness will also vary with vertical front porch duration. Some
* panels may have noticeable differences in brightness between the minimum
* vertical front porch duration and the maximum vertical front porch duration.
* Large and frequent changes in vertical front porch duration may produce
* observable flickering for such panels.
*
* Userspace control for variable refresh rate is supported via properties
* on the &drm_connector and &drm_crtc objects.
*
* "vrr_capable":
* Optional &drm_connector boolean property that drivers should attach
* with drm_connector_attach_vrr_capable_property() on connectors that
* could support variable refresh rates. Drivers should update the
* property value by calling drm_connector_set_vrr_capable_property().
*
* Absence of the property should indicate absence of support.
*
* "VRR_ENABLED":
* Default &drm_crtc boolean property that notifies the driver that the
* content on the CRTC is suitable for variable refresh rate presentation.
* The driver will take this property as a hint to enable variable
* refresh rate support if the receiver supports it, ie. if the
* "vrr_capable" property is true on the &drm_connector object. The
* vertical front porch duration will be extended until page-flip or
* timeout when enabled.
*
* The minimum vertical front porch duration is defined as the vertical
* front porch duration for the current mode.
*
* The maximum vertical front porch duration is greater than or equal to
* the minimum vertical front porch duration. The duration is derived
* from the minimum supported variable refresh rate for the connector.
*
* The driver may place further restrictions within these minimum
* and maximum bounds.
*/
/**
* drm_connector_attach_vrr_capable_property - creates the
* vrr_capable property
* @connector: connector to create the vrr_capable property on.
*
* This is used by atomic drivers to add support for querying
* variable refresh rate capability for a connector.
*
* Returns:
* Zero on success, negative errono on failure.
*/
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_property *prop;
if (!connector->vrr_capable_property) {
prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
"vrr_capable");
if (!prop)
return -ENOMEM;
connector->vrr_capable_property = prop;
drm_object_attach_property(&connector->base, prop, 0);
}
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
/**
* drm_connector_attach_scaling_mode_property - attach atomic scaling mode property
* @connector: connector to attach scaling mode property on.
* @scaling_mode_mask: or'ed mask of BIT(%DRM_MODE_SCALE_\*).
*
* This is used to add support for scaling mode to atomic drivers.
* The scaling mode will be set to &drm_connector_state.picture_aspect_ratio
* and can be used from &drm_connector_helper_funcs->atomic_check for validation.
*
* This is the atomic version of drm_mode_create_scaling_mode_property().
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
u32 scaling_mode_mask)
{
struct drm_device *dev = connector->dev;
struct drm_property *scaling_mode_property;
int i;
const unsigned valid_scaling_mode_mask =
(1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
if (WARN_ON(hweight32(scaling_mode_mask) < 2 ||
scaling_mode_mask & ~valid_scaling_mode_mask))
return -EINVAL;
scaling_mode_property =
drm_property_create(dev, DRM_MODE_PROP_ENUM, "scaling mode",
hweight32(scaling_mode_mask));
if (!scaling_mode_property)
return -ENOMEM;
for (i = 0; i < ARRAY_SIZE(drm_scaling_mode_enum_list); i++) {
int ret;
if (!(BIT(i) & scaling_mode_mask))
continue;
ret = drm_property_add_enum(scaling_mode_property,
drm_scaling_mode_enum_list[i].type,
drm_scaling_mode_enum_list[i].name);
if (ret) {
drm_property_destroy(dev, scaling_mode_property);
return ret;
}
}
drm_object_attach_property(&connector->base,
scaling_mode_property, 0);
connector->scaling_mode_property = scaling_mode_property;
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
/**
* drm_mode_create_aspect_ratio_property - create aspect ratio property
* @dev: DRM device
*
* Called by a driver the first time it's needed, must be attached to desired
* connectors.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
{
if (dev->mode_config.aspect_ratio_property)
return 0;
dev->mode_config.aspect_ratio_property =
drm_property_create_enum(dev, 0, "aspect ratio",
drm_aspect_ratio_enum_list,
ARRAY_SIZE(drm_aspect_ratio_enum_list));
if (dev->mode_config.aspect_ratio_property == NULL)
return -ENOMEM;
return 0;
}
EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
/**
* DOC: standard connector properties
*
* Colorspace:
* This property helps select a suitable colorspace based on the sink
* capability. Modern sink devices support wider gamut like BT2020.
* This helps switch to BT2020 mode if the BT2020 encoded video stream
* is being played by the user, same for any other colorspace. 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.
* - This property is just to inform sink what colorspace
* source is trying to drive.
*
* Because between HDMI and DP have different colorspaces,
* drm_mode_create_hdmi_colorspace_property() is used for HDMI connector and
* drm_mode_create_dp_colorspace_property() is used for DP connector.
*/
/**
* drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
* @connector: connector to create the Colorspace property on.
*
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
* Called by a driver the first time it's needed, must be attached to desired
* HDMI connectors.
*
* Returns:
* Zero on success, negative errono on failure.
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
*/
int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
{
struct drm_device *dev = connector->dev;
if (connector->colorspace_property)
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
return 0;
connector->colorspace_property =
drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
hdmi_colorspaces,
ARRAY_SIZE(hdmi_colorspaces));
if (!connector->colorspace_property)
return -ENOMEM;
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
return 0;
}
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
/**
* drm_mode_create_dp_colorspace_property - create dp colorspace property
* @connector: connector to create the Colorspace property on.
*
* Called by a driver the first time it's needed, must be attached to desired
* DP connectors.
*
* Returns:
* Zero on success, negative errono on failure.
*/
int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
if (connector->colorspace_property)
return 0;
connector->colorspace_property =
drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
dp_colorspaces,
ARRAY_SIZE(dp_colorspaces));
if (!connector->colorspace_property)
return -ENOMEM;
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
return 0;
}
EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
drm: Add HDMI colorspace property Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colorspaces. Also, added a default option for colorspace. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed Default to an unset state where driver will assign the colorspace is not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. v5: Made the property creation helper accept enum list based on platform capabilties as suggested by Shashank. Consolidated HDMI and DP property creation in the common helper. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the commit message to add more details as well kernel docs. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack. v11: Addressed Ville's review comments. Updated the Macro naming and added DCI-P3 colorspace as well, defined in CTA 861.G spec. v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's review comment to be clear and not to be confused with RGB. v13: Reorder the colorspace macros. v14: Removed DP as of now, will be added later once full support is enabled, as per Ville's suggestion. Added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1550596381-993-2-git-send-email-uma.shankar@intel.com
2019-02-20 01:12:59 +08:00
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 21:59:27 +08:00
/**
* drm_mode_create_content_type_property - create content type property
* @dev: DRM device
*
* Called by a driver the first time it's needed, must be attached to desired
* connectors.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_mode_create_content_type_property(struct drm_device *dev)
{
if (dev->mode_config.content_type_property)
return 0;
dev->mode_config.content_type_property =
drm_property_create_enum(dev, 0, "content type",
drm_content_type_enum_list,
ARRAY_SIZE(drm_content_type_enum_list));
if (dev->mode_config.content_type_property == NULL)
return -ENOMEM;
return 0;
}
EXPORT_SYMBOL(drm_mode_create_content_type_property);
/**
* drm_mode_create_suggested_offset_properties - create suggests offset properties
* @dev: DRM device
*
* Create the the suggested x/y offset property for connectors.
*/
int drm_mode_create_suggested_offset_properties(struct drm_device *dev)
{
if (dev->mode_config.suggested_x_property && dev->mode_config.suggested_y_property)
return 0;
dev->mode_config.suggested_x_property =
drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "suggested X", 0, 0xffffffff);
dev->mode_config.suggested_y_property =
drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "suggested Y", 0, 0xffffffff);
if (dev->mode_config.suggested_x_property == NULL ||
dev->mode_config.suggested_y_property == NULL)
return -ENOMEM;
return 0;
}
EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
/**
* drm_connector_set_path_property - set tile property on connector
* @connector: connector to set property on.
* @path: path to use for property; must not be NULL.
*
* This creates a property to expose to userspace to specify a
* connector path. This is mainly used for DisplayPort MST where
* connectors have a topology and we want to allow userspace to give
* them more meaningful names.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_set_path_property(struct drm_connector *connector,
const char *path)
{
struct drm_device *dev = connector->dev;
int ret;
ret = drm_property_replace_global_blob(dev,
&connector->path_blob_ptr,
strlen(path) + 1,
path,
&connector->base,
dev->mode_config.path_property);
return ret;
}
EXPORT_SYMBOL(drm_connector_set_path_property);
/**
* drm_connector_set_tile_property - set tile property on connector
* @connector: connector to set property on.
*
* This looks up the tile information for a connector, and creates a
* property for userspace to parse if it exists. The property is of
* the form of 8 integers using ':' as a separator.
* This is used for dual port tiled displays with DisplayPort SST
* or DisplayPort MST connectors.
*
* Returns:
* Zero on success, errno on failure.
*/
int drm_connector_set_tile_property(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
char tile[256];
int ret;
if (!connector->has_tile) {
ret = drm_property_replace_global_blob(dev,
&connector->tile_blob_ptr,
0,
NULL,
&connector->base,
dev->mode_config.tile_property);
return ret;
}
snprintf(tile, 256, "%d:%d:%d:%d:%d:%d:%d:%d",
connector->tile_group->id, connector->tile_is_single_monitor,
connector->num_h_tile, connector->num_v_tile,
connector->tile_h_loc, connector->tile_v_loc,
connector->tile_h_size, connector->tile_v_size);
ret = drm_property_replace_global_blob(dev,
&connector->tile_blob_ptr,
strlen(tile) + 1,
tile,
&connector->base,
dev->mode_config.tile_property);
return ret;
}
EXPORT_SYMBOL(drm_connector_set_tile_property);
/**
* drm_connector_update_edid_property - update the edid property of a connector
* @connector: drm connector
* @edid: new value of the edid property
*
* This function creates a new blob modeset object and assigns its id to the
* connector's edid property.
* Since we also parse tile information from EDID's displayID block, we also
* set the connector's tile property here. See drm_connector_set_tile_property()
* for more details.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_update_edid_property(struct drm_connector *connector,
const struct edid *edid)
{
struct drm_device *dev = connector->dev;
size_t size = 0;
int ret;
/* ignore requests to set edid when overridden */
if (connector->override_edid)
return 0;
if (edid)
size = EDID_LENGTH * (1 + edid->extensions);
drm: Update edid-derived drm_display_info fields at edid property set [v2] There are a set of values in the drm_display_info structure for each connector which hold information derived from EDID. These are computed in drm_add_display_info. Before this patch, that was only called in drm_add_edid_modes. This meant that they were only set when EDID was present and never reset when EDID was not, as happened when the display was disconnected. One of these fields, non_desktop, is used from drm_mode_connector_update_edid_property, the function responsible for assigning the new edid value to the application-visible property. Various drivers call these two functions (drm_add_edid_modes and drm_mode_connector_update_edid_property) in different orders. This means that even when EDID is present, the drm_display_info fields may not have been computed at the time that drm_mode_connector_update_edid_property used the non_desktop value to set the non_desktop property. I've added a public function (drm_reset_display_info) that resets the drm_display_info field values to default values and then made the drm_add_display_info function public. These two functions are now called directly from drm_mode_connector_update_edid_property so that the drm_display_info fields are always computed from the current EDID information before being used in that function. This means that the drm_display_info values are often computed twice, once when the EDID property it set and a second time when EDID is used to compute modes for the device. The alternative would be to uniformly ensure that the values were computed once before being used, which would require that all drivers reliably invoke the two paths in the same order. The computation is inexpensive enough that it seems more maintainable in the long term to simply compute them in both paths. The API to drm_add_display_info has been changed so that it no longer takes the set of edid-based quirks as a parameter. Rather, it now computes those quirks itself and returns them for further use by drm_add_edid_modes. This patch also includes a number of 'const' additions caused by drm_mode_connector_update_edid_property taking a 'const struct edid *' parameter and wanting to pass that along to drm_add_display_info. v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch> Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and drm_add_display_info. Added FIXME in drm_mode_connector_update_edid_property about potentially merging that with drm_add_edid_modes to avoid the need for two driver calls. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171213084427.31199-1-keithp@keithp.com
2017-12-13 16:44:26 +08:00
/* Set the display info, using edid if available, otherwise
* reseting the values to defaults. This duplicates the work
* done in drm_add_edid_modes, but that function is not
* consistently called before this one in all drivers and the
* computation is cheap enough that it seems better to
* duplicate it rather than attempt to ensure some arbitrary
* ordering of calls.
*/
if (edid)
drm_add_display_info(connector, edid);
else
drm_reset_display_info(connector);
drm_update_tile_info(connector, edid);
drm_object_property_set_value(&connector->base,
dev->mode_config.non_desktop_property,
connector->display_info.non_desktop);
ret = drm_property_replace_global_blob(dev,
&connector->edid_blob_ptr,
size,
edid,
&connector->base,
dev->mode_config.edid_property);
if (ret)
return ret;
return drm_connector_set_tile_property(connector);
}
EXPORT_SYMBOL(drm_connector_update_edid_property);
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
/**
* drm_connector_set_link_status_property - Set link status property of a connector
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
* @connector: drm connector
* @link_status: new value of link status property (0: Good, 1: Bad)
*
* In usual working scenario, this link status property will always be set to
* "GOOD". If something fails during or after a mode set, the kernel driver
* may set this link status property to "BAD". The caller then needs to send a
* hotplug uevent for userspace to re-check the valid modes through
* GET_CONNECTOR_IOCTL and retry modeset.
*
* Note: Drivers cannot rely on userspace to support this property and
* issue a modeset. As such, they may choose to handle issues (like
* re-training a link) without userspace's intervention.
*
* The reason for adding this property is to handle link training failures, but
* it is not limited to DP or link training. For example, if we implement
* asynchronous setcrtc, this property can be used to report any failures in that.
*/
void drm_connector_set_link_status_property(struct drm_connector *connector,
uint64_t link_status)
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
{
struct drm_device *dev = connector->dev;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
connector->state->link_status = link_status;
drm_modeset_unlock(&dev->mode_config.connection_mutex);
}
EXPORT_SYMBOL(drm_connector_set_link_status_property);
drm: Add a new connector atomic property for link status At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows. One idea would be to have setcrtc return a failure. However, it already should not fail as the atomic checks have passed. It would also conflict with the idea of making setcrtc asynchronous in the future, returning before the actual mode setting and link training. Another idea is to train the link "upfront" at hotplug time, before pruning the mode list, so that we can do the pruning based on practical not theoretical capabilities. However, the changes for link training are pretty drastic, all for the sake of error handling and DP compliance, when the most common happy day scenario is the current approach of link training at mode setting time, using the optimal parameters for the mode. It is also not certain all hardware could do this without the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially. Both of the above ideas also fail to address link degradation *during* operation. The solution is to add a new "link-status" connector property in order to address link training failure in a way that: a) changes the current happy day scenario as little as possible, to avoid regressions, b) can be implemented the same way by all drm drivers, c) is still opt-in for the drivers and userspace, and opting out doesn't regress the user experience, d) doesn't prevent drivers from implementing better or alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented. In the usual happy day scenario, this is always "good". If something fails during or after a mode set, the kernel driver can set the link status to "bad" and issue a hotplug uevent for userspace to have it re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that. v7 by Jani: * Rebase, simplify set property while at it, checkpatch fix v6: * Fix a typo in kernel doc (Sean Paul) v5: * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter) v4: * Add comments in kernel-doc format (Daniel Vetter) * Update the kernel-doc for link-status (Sean Paul) v3: * Fixed a build error (Jani Saarinen) v2: * Removed connector->link_status (Daniel Vetter) * Set connector->state->link_status in drm_mode_connector_set_link_status_property (Daniel Vetter) * Set the connector_changed flag to true if connector->state->link_status changed. * Reset link_status to GOOD in update_output_state (Daniel Vetter) * Never allow userspace to set link status from Good To Bad (Daniel Vetter) Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 18:29:06 +08:00
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-13 02:42:32 +08:00
/**
* drm_connector_attach_max_bpc_property - attach "max bpc" property
* @connector: connector to attach max bpc property on.
* @min: The minimum bit depth supported by the connector.
* @max: The maximum bit depth supported by the connector.
*
* This is used to add support for limiting the bit depth on a connector.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
int min, int max)
{
struct drm_device *dev = connector->dev;
struct drm_property *prop;
prop = connector->max_bpc_property;
if (!prop) {
prop = drm_property_create_range(dev, 0, "max bpc", min, max);
if (!prop)
return -ENOMEM;
connector->max_bpc_property = prop;
}
drm_object_attach_property(&connector->base, prop, max);
connector->state->max_requested_bpc = max;
connector->state->max_bpc = max;
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
/**
* drm_connector_set_vrr_capable_property - sets the variable refresh rate
* capable property for a connector
* @connector: drm connector
* @capable: True if the connector is variable refresh rate capable
*
* Should be used by atomic drivers to update the indicated support for
* variable refresh rate over a connector.
*/
void drm_connector_set_vrr_capable_property(
struct drm_connector *connector, bool capable)
{
drm_object_property_set_value(&connector->base,
connector->vrr_capable_property,
capable);
}
EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
/**
* drm_connector_set_panel_orientation - sets the connecter's panel_orientation
* @connector: connector for which to set the panel-orientation property.
* @panel_orientation: drm_panel_orientation value to set
*
* This function sets the connector's panel_orientation and attaches
* a "panel orientation" property to the connector.
*
* Calling this function on a connector where the panel_orientation has
* already been set is a no-op (e.g. the orientation has been overridden with
* a kernel commandline option).
*
* It is allowed to call this function with a panel_orientation of
* DRM_MODE_PANEL_ORIENTATION_UNKNOWN, in which case it is a no-op.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_set_panel_orientation(
struct drm_connector *connector,
enum drm_panel_orientation panel_orientation)
{
struct drm_device *dev = connector->dev;
struct drm_display_info *info = &connector->display_info;
struct drm_property *prop;
/* Already set? */
if (info->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
/* Don't attach the property if the orientation is unknown */
if (panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
info->panel_orientation = panel_orientation;
prop = dev->mode_config.panel_orientation_property;
if (!prop) {
prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
"panel orientation",
drm_panel_orientation_enum_list,
ARRAY_SIZE(drm_panel_orientation_enum_list));
if (!prop)
return -ENOMEM;
dev->mode_config.panel_orientation_property = prop;
}
drm_object_attach_property(&connector->base, prop,
info->panel_orientation);
return 0;
}
EXPORT_SYMBOL(drm_connector_set_panel_orientation);
/**
* drm_connector_set_panel_orientation_with_quirk -
* set the connecter's panel_orientation after checking for quirks
* @connector: connector for which to init the panel-orientation property.
* @panel_orientation: drm_panel_orientation value to set
* @width: width in pixels of the panel, used for panel quirk detection
* @height: height in pixels of the panel, used for panel quirk detection
*
* Like drm_connector_set_panel_orientation(), but with a check for platform
* specific (e.g. DMI based) quirks overriding the passed in panel_orientation.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_set_panel_orientation_with_quirk(
struct drm_connector *connector,
enum drm_panel_orientation panel_orientation,
int width, int height)
{
int orientation_quirk;
orientation_quirk = drm_get_panel_orientation_quirk(width, height);
if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
panel_orientation = orientation_quirk;
return drm_connector_set_panel_orientation(connector,
panel_orientation);
}
EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
int drm_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
{
int ret = -EINVAL;
struct drm_connector *connector = obj_to_connector(obj);
/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
ret = (*connector->funcs->dpms)(connector, (int)value);
} else if (connector->funcs->set_property)
ret = connector->funcs->set_property(connector, property, value);
if (!ret)
drm_object_property_set_value(&connector->base, property, value);
return ret;
}
int drm_connector_property_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
struct drm_mode_connector_set_property *conn_set_prop = data;
struct drm_mode_obj_set_property obj_set_prop = {
.value = conn_set_prop->value,
.prop_id = conn_set_prop->prop_id,
.obj_id = conn_set_prop->connector_id,
.obj_type = DRM_MODE_OBJECT_CONNECTOR
};
/* It does all the locking and checking we need */
return drm_mode_obj_set_property_ioctl(dev, &obj_set_prop, file_priv);
}
static struct drm_encoder *drm_connector_get_encoder(struct drm_connector *connector)
{
/* For atomic drivers only state objects are synchronously updated and
* protected by modeset locks, so check those first. */
if (connector->state)
return connector->state->best_encoder;
return connector->encoder;
}
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
static bool
drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
const struct list_head *export_list,
const struct drm_file *file_priv)
{
/*
* If user-space hasn't configured the driver to expose the stereo 3D
* modes, don't expose them.
*/
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
/*
* If user-space hasn't configured the driver to expose the modes
* with aspect-ratio, don't expose them. However if such a mode
* is unique, let it be exposed, but reset the aspect-ratio flags
* while preparing the list of user-modes.
*/
if (!file_priv->aspect_ratio_allowed) {
struct drm_display_mode *mode_itr;
list_for_each_entry(mode_itr, export_list, export_head)
if (drm_mode_match(mode_itr, mode,
DRM_MODE_MATCH_TIMINGS |
DRM_MODE_MATCH_CLOCK |
DRM_MODE_MATCH_FLAGS |
DRM_MODE_MATCH_3D_FLAGS))
return false;
}
return true;
}
int drm_mode_getconnector(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_mode_get_connector *out_resp = data;
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
int mode_count = 0;
int encoders_count = 0;
int ret = 0;
int copied = 0;
struct drm_mode_modeinfo u_mode;
struct drm_mode_modeinfo __user *mode_ptr;
uint32_t __user *encoder_ptr;
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
LIST_HEAD(export_list);
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
connector = drm_connector_lookup(dev, file_priv, out_resp->connector_id);
if (!connector)
return -ENOENT;
encoders_count = hweight32(connector->possible_encoders);
if ((out_resp->count_encoders >= encoders_count) && encoders_count) {
copied = 0;
encoder_ptr = (uint32_t __user *)(unsigned long)(out_resp->encoders_ptr);
drm_connector_for_each_possible_encoder(connector, encoder) {
if (put_user(encoder->base.id, encoder_ptr + copied)) {
ret = -EFAULT;
goto out;
}
copied++;
}
}
out_resp->count_encoders = encoders_count;
out_resp->connector_id = connector->base.id;
out_resp->connector_type = connector->connector_type;
out_resp->connector_type_id = connector->connector_type_id;
mutex_lock(&dev->mode_config.mutex);
if (out_resp->count_modes == 0) {
connector->funcs->fill_modes(connector,
dev->mode_config.max_width,
dev->mode_config.max_height);
}
out_resp->mm_width = connector->display_info.width_mm;
out_resp->mm_height = connector->display_info.height_mm;
out_resp->subpixel = connector->display_info.subpixel_order;
out_resp->connection = connector->status;
/* delayed so we get modes regardless of pre-fill_modes state */
list_for_each_entry(mode, &connector->modes, head)
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
if (drm_mode_expose_to_userspace(mode, &export_list,
file_priv)) {
list_add_tail(&mode->export_head, &export_list);
mode_count++;
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
}
/*
* This ioctl is called twice, once to determine how much space is
* needed, and the 2nd time to fill it.
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
* The modes that need to be exposed to the user are maintained in the
* 'export_list'. When the ioctl is called first time to determine the,
* space, the export_list gets filled, to find the no.of modes. In the
* 2nd time, the user modes are filled, one by one from the export_list.
*/
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned long)out_resp->modes_ptr;
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
list_for_each_entry(mode, &export_list, export_head) {
drm_mode_convert_to_umode(&u_mode, mode);
drm: Expose modes with aspect ratio, only if requested We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from the drm_mode_get_connector modelist supplied to the user, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. -prepares a list of exposed modes, which is used to find unique modes if aspect-ratio is not allowed. -adds a new list_head 'exposed_head' in drm_mode_display, to traverse the list of exposed modes. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. V12: As suggested by Ville, added another list_head in drm_mode_display to traverse the list of exposed modes and avoided duplication of modes. V13: Minor modifications, as suggested by Ville. v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the pruning logic to avoid any dependency in the order of mode with aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
2018-05-08 19:09:43 +08:00
/*
* Reset aspect ratio flags of user-mode, if modes with
* aspect-ratio are not supported.
*/
if (!file_priv->aspect_ratio_allowed)
u_mode.flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
if (copy_to_user(mode_ptr + copied,
&u_mode, sizeof(u_mode))) {
ret = -EFAULT;
mutex_unlock(&dev->mode_config.mutex);
goto out;
}
copied++;
}
}
out_resp->count_modes = mode_count;
mutex_unlock(&dev->mode_config.mutex);
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
encoder = drm_connector_get_encoder(connector);
if (encoder)
out_resp->encoder_id = encoder->base.id;
else
out_resp->encoder_id = 0;
/* Only grab properties after probing, to make sure EDID and other
* properties reflect the latest status. */
ret = drm_mode_object_get_properties(&connector->base, file_priv->atomic,
(uint32_t __user *)(unsigned long)(out_resp->props_ptr),
(uint64_t __user *)(unsigned long)(out_resp->prop_values_ptr),
&out_resp->count_props);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
out:
drm_connector_put(connector);
return ret;
}
/**
* DOC: Tile group
*
* Tile groups are used to represent tiled monitors with a unique integer
* identifier. Tiled monitors using DisplayID v1.3 have a unique 8-byte handle,
* we store this in a tile group, so we have a common identifier for all tiles
* in a monitor group. The property is called "TILE". Drivers can manage tile
* groups using drm_mode_create_tile_group(), drm_mode_put_tile_group() and
* drm_mode_get_tile_group(). But this is only needed for internal panels where
* the tile group information is exposed through a non-standard way.
*/
static void drm_tile_group_free(struct kref *kref)
{
struct drm_tile_group *tg = container_of(kref, struct drm_tile_group, refcount);
struct drm_device *dev = tg->dev;
mutex_lock(&dev->mode_config.idr_mutex);
idr_remove(&dev->mode_config.tile_idr, tg->id);
mutex_unlock(&dev->mode_config.idr_mutex);
kfree(tg);
}
/**
* drm_mode_put_tile_group - drop a reference to a tile group.
* @dev: DRM device
* @tg: tile group to drop reference to.
*
* drop reference to tile group and free if 0.
*/
void drm_mode_put_tile_group(struct drm_device *dev,
struct drm_tile_group *tg)
{
kref_put(&tg->refcount, drm_tile_group_free);
}
EXPORT_SYMBOL(drm_mode_put_tile_group);
/**
* drm_mode_get_tile_group - get a reference to an existing tile group
* @dev: DRM device
* @topology: 8-bytes unique per monitor.
*
* Use the unique bytes to get a reference to an existing tile group.
*
* RETURNS:
* tile group or NULL if not found.
*/
struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
const char topology[8])
{
struct drm_tile_group *tg;
int id;
mutex_lock(&dev->mode_config.idr_mutex);
idr_for_each_entry(&dev->mode_config.tile_idr, tg, id) {
if (!memcmp(tg->group_data, topology, 8)) {
if (!kref_get_unless_zero(&tg->refcount))
tg = NULL;
mutex_unlock(&dev->mode_config.idr_mutex);
return tg;
}
}
mutex_unlock(&dev->mode_config.idr_mutex);
return NULL;
}
EXPORT_SYMBOL(drm_mode_get_tile_group);
/**
* drm_mode_create_tile_group - create a tile group from a displayid description
* @dev: DRM device
* @topology: 8-bytes unique per monitor.
*
* Create a tile group for the unique monitor, and get a unique
* identifier for the tile group.
*
* RETURNS:
* new tile group or NULL.
*/
struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
const char topology[8])
{
struct drm_tile_group *tg;
int ret;
tg = kzalloc(sizeof(*tg), GFP_KERNEL);
if (!tg)
return NULL;
kref_init(&tg->refcount);
memcpy(tg->group_data, topology, 8);
tg->dev = dev;
mutex_lock(&dev->mode_config.idr_mutex);
ret = idr_alloc(&dev->mode_config.tile_idr, tg, 1, 0, GFP_KERNEL);
if (ret >= 0) {
tg->id = ret;
} else {
kfree(tg);
tg = NULL;
}
mutex_unlock(&dev->mode_config.idr_mutex);
return tg;
}
EXPORT_SYMBOL(drm_mode_create_tile_group);