2016-08-13 03:48:50 +07:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2016 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, distribute, and sell this software and its
|
|
|
|
* documentation for any purpose is hereby granted without fee, provided that
|
|
|
|
* the above copyright notice appear in all copies and that both that copyright
|
|
|
|
* notice and this permission notice appear in supporting documentation, and
|
|
|
|
* that the name of the copyright holders not be used in advertising or
|
|
|
|
* publicity pertaining to distribution of the software without specific,
|
|
|
|
* written prior permission. The copyright holders make no representations
|
|
|
|
* about the suitability of this software for any purpose. It is provided "as
|
|
|
|
* is" without express or implied warranty.
|
|
|
|
*
|
|
|
|
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
|
|
|
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
|
|
|
|
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
|
|
|
|
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
|
|
|
|
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
|
|
|
|
* OF THIS SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <drm/drm_connector.h>
|
|
|
|
#include <drm/drm_edid.h>
|
2016-11-29 01:51:09 +07:00
|
|
|
#include <drm/drm_encoder.h>
|
2017-11-26 02:35:49 +07:00
|
|
|
#include <drm/drm_utils.h>
|
2018-09-05 20:57:06 +07:00
|
|
|
#include <drm/drm_print.h>
|
|
|
|
#include <drm/drm_drv.h>
|
|
|
|
#include <drm/drm_file.h>
|
|
|
|
|
|
|
|
#include <linux/uaccess.h>
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
#include "drm_crtc_internal.h"
|
|
|
|
#include "drm_internal.h"
|
|
|
|
|
2016-08-13 03:48:53 +07:00
|
|
|
/**
|
|
|
|
* 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.
|
2017-02-28 21:46:39 +07:00
|
|
|
* Hence they are reference-counted using drm_connector_get() and
|
|
|
|
* drm_connector_put().
|
2016-08-13 03:48:53 +07:00
|
|
|
*
|
2017-01-25 13:26:45 +07:00
|
|
|
* KMS driver must create, initialize, register and attach at a &struct
|
|
|
|
* drm_connector for each such sink. The instance is created as other KMS
|
2017-01-25 13:26:48 +07:00
|
|
|
* 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().
|
2016-08-13 03:48:53 +07:00
|
|
|
*
|
|
|
|
* 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
|
2018-07-09 15:40:07 +07:00
|
|
|
* initialization time with a call to drm_connector_attach_encoder(). The
|
2017-01-25 13:26:45 +07:00
|
|
|
* driver must also set the &drm_connector.encoder field to point to the
|
2016-08-13 03:48:53 +07:00
|
|
|
* 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().
|
|
|
|
*/
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
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" },
|
2017-03-29 23:42:32 +07:00
|
|
|
{ DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
|
2019-07-19 22:59:06 +07:00
|
|
|
{ DRM_MODE_CONNECTOR_SPI, "SPI" },
|
2016-08-13 03:48:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
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_connector_get_cmdline_mode - reads the user's cmdline mode
|
|
|
|
* @connector: connector to quwery
|
|
|
|
*
|
2016-08-13 03:48:53 +07:00
|
|
|
* The kernel supports per-connector configuration of its consoles through
|
2016-08-13 03:48:50 +07:00
|
|
|
* 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) {
|
2017-02-20 15:51:48 +07:00
|
|
|
DRM_INFO("forcing %s connector %s\n", connector->name,
|
|
|
|
drm_get_connector_force_name(mode->force));
|
2016-08-13 03:48:50 +07:00
|
|
|
connector->force = mode->force;
|
|
|
|
}
|
|
|
|
|
2019-06-19 17:17:50 +07:00
|
|
|
DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
|
2019-06-24 15:40:16 +07:00
|
|
|
connector->name, mode->name,
|
2016-08-13 03:48:50 +07:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2017-12-13 19:49:36 +07:00
|
|
|
void drm_connector_free_work_fn(struct work_struct *work)
|
2017-12-05 03:48:18 +07:00
|
|
|
{
|
2017-12-13 19:49:36 +07: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;
|
2017-12-05 03:48:18 +07:00
|
|
|
|
2017-12-13 19:49:36 +07: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);
|
|
|
|
}
|
2017-12-05 03:48:18 +07:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
|
2018-05-25 08:25:55 +07:00
|
|
|
WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
|
|
|
|
(!funcs->atomic_destroy_state ||
|
|
|
|
!funcs->atomic_duplicate_state));
|
|
|
|
|
2017-02-28 21:46:37 +07:00
|
|
|
ret = __drm_mode_object_add(dev, &connector->base,
|
|
|
|
DRM_MODE_OBJECT_CONNECTOR,
|
|
|
|
false, drm_connector_free);
|
2016-08-13 03:48:50 +07:00
|
|
|
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 06:08:06 +07:00
|
|
|
return ret;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
connector->base.properties = &connector->properties;
|
|
|
|
connector->dev = dev;
|
|
|
|
connector->funcs = funcs;
|
|
|
|
|
2018-01-25 20:30:20 +07:00
|
|
|
/* 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);
|
2016-08-13 03:48:50 +07:00
|
|
|
goto out_put;
|
2018-01-25 20:30:20 +07:00
|
|
|
}
|
2016-08-13 03:48:50 +07:00
|
|
|
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);
|
2016-12-18 20:35:45 +07:00
|
|
|
mutex_init(&connector->mutex);
|
2016-08-13 03:48:50 +07:00
|
|
|
connector->edid_blob_ptr = NULL;
|
2019-03-13 09:17:22 +07:00
|
|
|
connector->tile_blob_ptr = NULL;
|
2016-08-13 03:48:50 +07:00
|
|
|
connector->status = connector_status_unknown;
|
2017-11-26 02:35:49 +07:00
|
|
|
connector->display_info.panel_orientation =
|
|
|
|
DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
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 06:08:06 +07:00
|
|
|
spin_lock_irq(&config->connector_list_lock);
|
2016-08-13 03:48:50 +07:00
|
|
|
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 06:08:06 +07:00
|
|
|
spin_unlock_irq(&config->connector_list_lock);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2017-03-29 23:42:32 +07:00
|
|
|
if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL &&
|
|
|
|
connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
|
2018-10-02 18:10:40 +07:00
|
|
|
drm_connector_attach_edid_property(connector);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
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 17:29:06 +07:00
|
|
|
drm_object_attach_property(&connector->base,
|
|
|
|
config->link_status_property,
|
|
|
|
0);
|
|
|
|
|
2017-10-16 11:08:09 +07:00
|
|
|
drm_object_attach_property(&connector->base,
|
|
|
|
config->non_desktop_property,
|
|
|
|
0);
|
2019-03-13 09:17:22 +07:00
|
|
|
drm_object_attach_property(&connector->base,
|
|
|
|
config->tile_property,
|
|
|
|
0);
|
2017-10-16 11:08:09 +07:00
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
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)
|
2016-10-02 13:01:22 +07:00
|
|
|
ida_simple_remove(connector_ida, connector->connector_type_id);
|
2016-08-13 03:48:50 +07:00
|
|
|
out_put_id:
|
|
|
|
if (ret)
|
2016-10-02 13:01:22 +07:00
|
|
|
ida_simple_remove(&config->connector_ida, connector->index);
|
2016-08-13 03:48:50 +07:00
|
|
|
out_put:
|
|
|
|
if (ret)
|
|
|
|
drm_mode_object_unregister(dev, &connector->base);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_connector_init);
|
|
|
|
|
2019-07-27 00:22:56 +07:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
2018-10-02 18:10:40 +07:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
/**
|
2018-07-09 15:40:07 +07:00
|
|
|
* drm_connector_attach_encoder - attach a connector to an encoder
|
2016-08-13 03:48:50 +07:00
|
|
|
* @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.
|
|
|
|
*/
|
2018-07-09 15:40:07 +07:00
|
|
|
int drm_connector_attach_encoder(struct drm_connector *connector,
|
|
|
|
struct drm_encoder *encoder)
|
2016-08-13 03:48:50 +07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
2019-09-14 06:28:57 +07:00
|
|
|
connector->possible_encoders |= drm_encoder_mask(encoder);
|
|
|
|
|
|
|
|
return 0;
|
2016-08-13 03:48:50 +07:00
|
|
|
}
|
2018-07-09 15:40:07 +07:00
|
|
|
EXPORT_SYMBOL(drm_connector_attach_encoder);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2018-06-28 20:13:13 +07:00
|
|
|
/**
|
2019-09-14 06:28:57 +07:00
|
|
|
* drm_connector_has_possible_encoder - check if the connector and encoder are
|
|
|
|
* associated with each other
|
2018-06-28 20:13:13 +07:00
|
|
|
* @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)
|
|
|
|
{
|
2019-09-14 06:28:57 +07:00
|
|
|
return connector->possible_encoders & drm_encoder_mask(encoder);
|
2018-06-28 20:13:13 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_connector_has_possible_encoder);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
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 03:39:46 +07:00
|
|
|
if (WARN_ON(connector->registration_state ==
|
|
|
|
DRM_CONNECTOR_REGISTERED))
|
2016-08-13 03:48:50 +07:00
|
|
|
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);
|
|
|
|
|
2016-10-07 14:27:41 +07:00
|
|
|
ida_simple_remove(&drm_connector_enum_list[connector->connector_type].ida,
|
|
|
|
connector->connector_type_id);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2016-10-07 14:27:41 +07:00
|
|
|
ida_simple_remove(&dev->mode_config.connector_ida,
|
|
|
|
connector->index);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
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 06:08:06 +07:00
|
|
|
spin_lock_irq(&dev->mode_config.connector_list_lock);
|
2016-08-13 03:48:50 +07:00
|
|
|
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 06:08:06 +07:00
|
|
|
spin_unlock_irq(&dev->mode_config.connector_list_lock);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
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);
|
|
|
|
|
2016-12-18 20:35:45 +07:00
|
|
|
mutex_destroy(&connector->mutex);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
memset(connector, 0, sizeof(*connector));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_connector_cleanup);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_connector_register - register a connector
|
|
|
|
* @connector: the connector to register
|
|
|
|
*
|
2019-09-17 19:09:36 +07:00
|
|
|
* 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().
|
2016-08-13 03:48:50 +07:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* Zero on success, error code on failure.
|
|
|
|
*/
|
|
|
|
int drm_connector_register(struct drm_connector *connector)
|
|
|
|
{
|
2016-12-18 20:35:45 +07:00
|
|
|
int ret = 0;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2017-01-12 23:15:56 +07:00
|
|
|
if (!connector->dev->registered)
|
|
|
|
return 0;
|
|
|
|
|
2016-12-18 20:35:45 +07:00
|
|
|
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 03:39:46 +07:00
|
|
|
if (connector->registration_state != DRM_CONNECTOR_INITIALIZING)
|
2016-12-18 20:35:45 +07:00
|
|
|
goto unlock;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
ret = drm_sysfs_connector_add(connector);
|
|
|
|
if (ret)
|
2016-12-18 20:35:45 +07:00
|
|
|
goto unlock;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2019-06-13 20:34:39 +07:00
|
|
|
drm_debugfs_connector_add(connector);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
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 03:39:46 +07:00
|
|
|
connector->registration_state = DRM_CONNECTOR_REGISTERED;
|
2016-12-18 20:35:45 +07:00
|
|
|
goto unlock;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
err_debugfs:
|
|
|
|
drm_debugfs_connector_remove(connector);
|
|
|
|
drm_sysfs_connector_remove(connector);
|
2016-12-18 20:35:45 +07:00
|
|
|
unlock:
|
|
|
|
mutex_unlock(&connector->mutex);
|
2016-08-13 03:48:50 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_connector_register);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_connector_unregister - unregister a connector
|
|
|
|
* @connector: the connector to unregister
|
|
|
|
*
|
2019-09-17 19:09:36 +07:00
|
|
|
* 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.
|
2016-08-13 03:48:50 +07:00
|
|
|
*/
|
|
|
|
void drm_connector_unregister(struct drm_connector *connector)
|
|
|
|
{
|
2016-12-18 20:35:45 +07:00
|
|
|
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 03:39:46 +07:00
|
|
|
if (connector->registration_state != DRM_CONNECTOR_REGISTERED) {
|
2016-12-18 20:35:45 +07:00
|
|
|
mutex_unlock(&connector->mutex);
|
2016-08-13 03:48:50 +07:00
|
|
|
return;
|
2016-12-18 20:35:45 +07:00
|
|
|
}
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
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 03:39:46 +07:00
|
|
|
connector->registration_state = DRM_CONNECTOR_UNREGISTERED;
|
2016-12-18 20:35:45 +07:00
|
|
|
mutex_unlock(&connector->mutex);
|
2016-08-13 03:48:50 +07:00
|
|
|
}
|
|
|
|
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 06:08:06 +07:00
|
|
|
struct drm_connector_list_iter conn_iter;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2017-02-28 21:46:43 +07:00
|
|
|
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 06:08:06 +07:00
|
|
|
drm_for_each_connector_iter(connector, &conn_iter)
|
2016-08-13 03:48:50 +07:00
|
|
|
drm_connector_unregister(connector);
|
2017-02-28 21:46:43 +07:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
2016-08-13 03:48:50 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
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 06:08:06 +07:00
|
|
|
struct drm_connector_list_iter conn_iter;
|
|
|
|
int ret = 0;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2017-02-28 21:46:43 +07:00
|
|
|
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 06:08:06 +07:00
|
|
|
drm_for_each_connector_iter(connector, &conn_iter) {
|
2016-08-13 03:48:50 +07:00
|
|
|
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 06:08:06 +07:00
|
|
|
break;
|
2016-08-13 03:48:50 +07:00
|
|
|
}
|
2017-02-28 21:46:43 +07:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 06:08:06 +07:00
|
|
|
if (ret)
|
|
|
|
drm_connector_unregister_all(dev);
|
2016-08-13 03:48:50 +07:00
|
|
|
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);
|
|
|
|
|
2017-02-20 15:51:48 +07:00
|
|
|
/**
|
|
|
|
* 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 06:08:06 +07:00
|
|
|
#ifdef CONFIG_LOCKDEP
|
|
|
|
static struct lockdep_map connector_list_iter_dep_map = {
|
|
|
|
.name = "drm_connector_list_iter"
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/**
|
2017-02-28 21:46:43 +07:00
|
|
|
* 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 06:08:06 +07:00
|
|
|
* @dev: DRM device
|
|
|
|
* @iter: connector_list iterator
|
|
|
|
*
|
2017-01-25 13:26:45 +07:00
|
|
|
* Sets @iter up to walk the &drm_mode_config.connector_list of @dev. @iter
|
2017-02-28 21:46:43 +07:00
|
|
|
* 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 06:08:06 +07:00
|
|
|
* Iteration itself happens using drm_connector_list_iter_next() or
|
|
|
|
* drm_for_each_connector_iter().
|
|
|
|
*/
|
2017-02-28 21:46:43 +07:00
|
|
|
void drm_connector_list_iter_begin(struct drm_device *dev,
|
|
|
|
struct drm_connector_list_iter *iter)
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 06:08:06 +07:00
|
|
|
{
|
|
|
|
iter->dev = dev;
|
|
|
|
iter->conn = NULL;
|
|
|
|
lock_acquire_shared_recursive(&connector_list_iter_dep_map, 0, 1, NULL, _RET_IP_);
|
|
|
|
}
|
2017-02-28 21:46:43 +07:00
|
|
|
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 06:08:06 +07:00
|
|
|
|
2017-12-05 03:48:18 +07: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
|
2017-12-13 19:49:36 +07:00
|
|
|
__drm_connector_put_safe(struct drm_connector *conn)
|
2017-12-05 03:48:18 +07:00
|
|
|
{
|
2017-12-13 19:49:36 +07: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);
|
2017-12-05 03:48:18 +07:00
|
|
|
}
|
|
|
|
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 06:08:06 +07:00
|
|
|
/**
|
|
|
|
* drm_connector_list_iter_next - return next connector
|
2018-07-17 00:17:11 +07:00
|
|
|
* @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 06:08:06 +07: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)
|
2017-12-13 19:49:36 +07: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 06:08:06 +07:00
|
|
|
|
|
|
|
return iter->conn;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_connector_list_iter_next);
|
|
|
|
|
|
|
|
/**
|
2017-02-28 21:46:43 +07:00
|
|
|
* 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 06:08:06 +07: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.
|
|
|
|
*/
|
2017-02-28 21:46:43 +07:00
|
|
|
void drm_connector_list_iter_end(struct drm_connector_list_iter *iter)
|
drm: locking&new iterators for connector_list
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protection lock, which means that locking context
leaks all over the place. Not pretty - better to deal with zombies
and wrap the locking just around the list_del in the destructor.
- When we walk the list we must _not_ hold the connector list lock. We
walk the connector list at an absolutely massive amounts of places,
if all those places can't ever call drm_connector_unreference the
code would get unecessarily complicated.
- connector_list needs it own lock, again too many places that walk it
that we could reuse e.g. mode_config.mutex without resulting in
inversions.
- Lots of code uses these loops to look-up a connector, i.e. they want
to be able to call drm_connector_reference. But on the other hand we
want connectors to stay on that list until they're dead (i.e.
connector_list can't hold a full reference), which means despite the
"can't hold lock for the loop body" rule we need to make sure a
connector doesn't suddenly become a zombie.
At first Dave&I discussed various horror-show approaches using srcu,
but turns out it's fairly easy:
- For the loop body we always hold an additional reference to the
current connector. That means it can't zombify, and it also means
it'll stay on the list, which means we can use it as our iterator to
find the next connector.
- When we try to find the next connector we only have to jump over
zombies. To make sure we don't chase bad pointers that entire loop
is protected with the new connect_list_lock spinlock. And because we
know that we're starting out with a non-zombie (need to drop our
reference for the old connector only after we have our new one),
we're guranteed to still be on the connector_list and either find
the next non-zombie or complete the iteration.
- Only downside is that we need to make sure that the temporary
reference for the loop body doesn't leak. iter_get/put() functions +
lockdep make sure that's the case.
- To avoid a flag day the new iterator macro has an _iter postfix. We
can rename it back once all the users of the unsafe version are gone
(there's about 100 list walkers for the connector_list).
For now this patch only converts all the list walking in the core,
leaving helpers and drivers for later patches. The nice thing is that
we can now finally remove 2 FIXME comments from the
register/unregister functions.
v2:
- use irqsafe spinlocks, so that we can use this in drm_state_dump
too.
- nuke drm_modeset_lock_all from drm_connector_init, now entirely
cargo-culted nonsense.
v3:
- do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
- pretty kerneldoc
- add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
v4: Change lockdep annotations to only check whether we release the
iter fake lock again (i.e. make sure that iter_put is called), but
not check any locking dependecies itself. That seams to require a
recursive read lock in trylock mode.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-14 06:08:06 +07:00
|
|
|
{
|
2017-12-13 19:49:36 +07: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 06:08:06 +07:00
|
|
|
iter->dev = NULL;
|
2017-12-13 19:49:36 +07: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);
|
|
|
|
}
|
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 06:08:06 +07:00
|
|
|
lock_release(&connector_list_iter_dep_map, 0, _RET_IP_);
|
|
|
|
}
|
2017-02-28 21:46:43 +07: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 06:08:06 +07:00
|
|
|
|
2016-08-13 03:48:50 +07: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 17:29:06 +07: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" },
|
|
|
|
};
|
|
|
|
|
2016-08-13 03:48:55 +07:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
/* 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" },
|
|
|
|
};
|
|
|
|
|
2018-05-15 20:59:27 +07: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" },
|
|
|
|
};
|
|
|
|
|
2017-11-26 02:35:49 +07:00
|
|
|
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" },
|
|
|
|
};
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
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 00:12:59 +07: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" },
|
|
|
|
};
|
|
|
|
|
2019-09-20 02:53:07 +07:00
|
|
|
/*
|
|
|
|
* 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" },
|
|
|
|
};
|
|
|
|
|
2016-11-17 15:56:48 +07:00
|
|
|
/**
|
|
|
|
* 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
|
2018-07-09 15:40:06 +07:00
|
|
|
* drm_connector_update_edid_property(), usually after having parsed
|
2016-11-17 15:56:48 +07:00
|
|
|
* 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,
|
2017-01-25 13:26:45 +07:00
|
|
|
* it is handled by the DRM core by calling the &drm_connector_funcs.dpms
|
2017-07-25 19:02:04 +07:00
|
|
|
* callback. For atomic drivers the remapping to the "ACTIVE" property is
|
|
|
|
* implemented in the DRM core. This is the only standard connector
|
|
|
|
* property that userspace can change.
|
2017-09-21 05:59:57 +07:00
|
|
|
*
|
|
|
|
* 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.
|
2016-11-17 15:56:48 +07:00
|
|
|
* PATH:
|
|
|
|
* Connector path property to identify how this sink is physically
|
|
|
|
* connected. Used by DP MST. This should be set by calling
|
2018-07-09 15:40:08 +07:00
|
|
|
* drm_connector_set_path_property(), in the case of DP MST with the
|
2016-11-17 15:56:48 +07:00
|
|
|
* 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
|
2018-07-09 15:40:08 +07:00
|
|
|
* should update this value using drm_connector_set_tile_property().
|
2016-11-17 15:56:48 +07:00
|
|
|
* 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 17:29:06 +07:00
|
|
|
* link-status:
|
2018-01-09 02:55:35 +07:00
|
|
|
* 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
|
2018-07-09 15:40:08 +07:00
|
|
|
* drm_connector_set_link_status_property().
|
2017-10-16 11:08:09 +07:00
|
|
|
* 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 02:55:37 +07: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:
|
|
|
|
*
|
2018-02-20 05:53:54 +07:00
|
|
|
* DRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0
|
2018-01-09 02:55:37 +07:00
|
|
|
* The link is not protected, content is transmitted in the clear.
|
2018-02-20 05:53:54 +07:00
|
|
|
* DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
|
2018-01-09 02:55:37 +07: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.
|
2018-02-20 05:53:54 +07:00
|
|
|
* DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
|
2018-01-09 02:55:37 +07: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..
|
2019-08-01 18:41:17 +07:00
|
|
|
* - Kernel sends uevent with the connector id and property id through
|
|
|
|
* @drm_hdcp_update_content_protection, upon below kernel triggered
|
|
|
|
* scenarios:
|
2019-08-12 21:01:03 +07:00
|
|
|
*
|
|
|
|
* - DESIRED -> ENABLED (authentication success)
|
|
|
|
* - ENABLED -> DESIRED (termination of authentication)
|
2019-08-01 18:41:17 +07:00
|
|
|
* - Please note no uevents for userspace triggered property state changes,
|
|
|
|
* which can't fail such as
|
2019-08-12 21:01:03 +07:00
|
|
|
*
|
|
|
|
* - DESIRED/ENABLED -> UNDESIRED
|
|
|
|
* - UNDESIRED -> DESIRED
|
2019-08-01 18:41:17 +07:00
|
|
|
* - 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).
|
2016-11-17 15:56:48 +07:00
|
|
|
*
|
2019-08-01 18:41:14 +07: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".
|
|
|
|
*
|
2019-06-04 18:17:02 +07: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
|
2019-06-13 22:17:23 +07:00
|
|
|
*
|
2019-06-04 18:17:02 +07: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.
|
|
|
|
*
|
2018-10-13 01:42:32 +07: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.
|
|
|
|
*
|
2016-11-17 15:56:48 +07:00
|
|
|
* Connectors also have one standardized atomic property:
|
|
|
|
*
|
|
|
|
* CRTC_ID:
|
|
|
|
* Mode object ID of the &drm_crtc this connector should be connected to.
|
2017-11-26 02:35:49 +07:00
|
|
|
*
|
|
|
|
* 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
|
2018-02-20 05:53:54 +07:00
|
|
|
* touchscreen input coordinates. This property is initialized by calling
|
|
|
|
* drm_connector_init_panel_orientation_property().
|
|
|
|
*
|
|
|
|
* 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).
|
2016-11-17 15:56:48 +07:00
|
|
|
*/
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
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 17:29:06 +07: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;
|
|
|
|
|
2017-10-16 11:08:09 +07:00
|
|
|
prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE, "non-desktop");
|
|
|
|
if (!prop)
|
|
|
|
return -ENOMEM;
|
|
|
|
dev->mode_config.non_desktop_property = prop;
|
|
|
|
|
2019-05-16 21:10:06 +07:00
|
|
|
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;
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
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);
|
|
|
|
|
2018-05-15 20:59:27 +07:00
|
|
|
/**
|
|
|
|
* DOC: HDMI connector properties
|
|
|
|
*
|
|
|
|
* content type (HDMI specific):
|
|
|
|
* Indicates content type setting to be used in HDMI infoframes to indicate
|
2019-02-02 08:23:26 +07:00
|
|
|
* content type for the external device, so that it adjusts its display
|
2018-05-15 20:59:27 +07: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
|
2018-07-02 16:10:23 +07:00
|
|
|
* infoframe values is done through drm_hdmi_avi_infoframe_content_type().
|
2018-05-15 20:59:27 +07: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);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
/**
|
2018-12-06 21:24:37 +07:00
|
|
|
* 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);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
/**
|
2018-12-06 21:24:35 +07:00
|
|
|
* drm_mode_create_tv_properties - create TV specific connector properties
|
2016-08-13 03:48:50 +07:00
|
|
|
* @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.
|
|
|
|
*/
|
2018-12-06 21:24:37 +07:00
|
|
|
if (drm_mode_create_tv_margin_properties(dev))
|
2016-08-13 03:48:50 +07:00
|
|
|
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++)
|
2018-03-17 02:04:20 +07:00
|
|
|
drm_property_add_enum(dev->mode_config.tv_mode_property,
|
2016-08-13 03:48:50 +07:00
|
|
|
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.
|
2017-05-01 20:37:54 +07:00
|
|
|
*
|
|
|
|
* Atomic drivers should use drm_connector_attach_scaling_mode_property()
|
|
|
|
* instead to correctly assign &drm_connector_state.picture_aspect_ratio
|
|
|
|
* in the atomic state.
|
2016-08-13 03:48:50 +07:00
|
|
|
*/
|
|
|
|
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);
|
|
|
|
|
2018-10-05 01:38:42 +07:00
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*
|
2019-01-30 23:30:06 +07:00
|
|
|
* "VRR_ENABLED":
|
2018-10-05 01:38:42 +07:00
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2018-09-18 20:55:20 +07:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
2017-05-01 20:37:54 +07:00
|
|
|
/**
|
|
|
|
* 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;
|
2018-03-17 02:04:20 +07:00
|
|
|
int i;
|
2017-05-01 20:37:54 +07:00
|
|
|
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;
|
|
|
|
|
2018-03-17 02:04:20 +07:00
|
|
|
ret = drm_property_add_enum(scaling_mode_property,
|
2017-05-01 20:37:54 +07:00
|
|
|
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);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
/**
|
|
|
|
* 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 00:12:59 +07: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.
|
|
|
|
*
|
2019-09-20 02:53:06 +07:00
|
|
|
* Because between HDMI and DP have different colorspaces,
|
2019-09-20 02:53:07 +07:00
|
|
|
* drm_mode_create_hdmi_colorspace_property() is used for HDMI connector and
|
|
|
|
* drm_mode_create_dp_colorspace_property() is used for DP connector.
|
2019-09-20 02:53:06 +07:00
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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 00:12:59 +07:00
|
|
|
* Called by a driver the first time it's needed, must be attached to desired
|
2019-09-20 02:53:06 +07:00
|
|
|
* 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 00:12:59 +07:00
|
|
|
*/
|
2019-09-20 02:53:06 +07: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 00:12:59 +07:00
|
|
|
{
|
|
|
|
struct drm_device *dev = connector->dev;
|
|
|
|
|
2019-09-20 02:53:06 +07:00
|
|
|
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 00:12:59 +07:00
|
|
|
return 0;
|
|
|
|
|
2019-09-20 02:53:06 +07:00
|
|
|
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 00:12:59 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2019-09-20 02:53:06 +07:00
|
|
|
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 00:12:59 +07:00
|
|
|
|
2019-09-20 02:53:07 +07: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;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
|
|
|
|
|
2018-05-15 20:59:27 +07: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);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
|
|
|
/**
|
2018-07-09 15:40:08 +07:00
|
|
|
* drm_connector_set_path_property - set tile property on connector
|
2016-08-13 03:48:50 +07:00
|
|
|
* @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.
|
|
|
|
*/
|
2018-07-09 15:40:08 +07:00
|
|
|
int drm_connector_set_path_property(struct drm_connector *connector,
|
|
|
|
const char *path)
|
2016-08-13 03:48:50 +07:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
2018-07-09 15:40:08 +07:00
|
|
|
EXPORT_SYMBOL(drm_connector_set_path_property);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
/**
|
2018-07-09 15:40:08 +07:00
|
|
|
* drm_connector_set_tile_property - set tile property on connector
|
2016-08-13 03:48:50 +07:00
|
|
|
* @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.
|
2019-03-13 09:17:22 +07:00
|
|
|
* This is used for dual port tiled displays with DisplayPort SST
|
|
|
|
* or DisplayPort MST connectors.
|
2016-08-13 03:48:50 +07:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* Zero on success, errno on failure.
|
|
|
|
*/
|
2018-07-09 15:40:08 +07:00
|
|
|
int drm_connector_set_tile_property(struct drm_connector *connector)
|
2016-08-13 03:48:50 +07:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
2018-07-09 15:40:08 +07:00
|
|
|
EXPORT_SYMBOL(drm_connector_set_tile_property);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
/**
|
2018-07-09 15:40:06 +07:00
|
|
|
* drm_connector_update_edid_property - update the edid property of a connector
|
2016-08-13 03:48:50 +07:00
|
|
|
* @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.
|
2019-03-13 09:17:22 +07:00
|
|
|
* 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.
|
2016-08-13 03:48:50 +07:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* Zero on success, negative errno on failure.
|
|
|
|
*/
|
2018-07-09 15:40:06 +07:00
|
|
|
int drm_connector_update_edid_property(struct drm_connector *connector,
|
2018-07-09 15:40:08 +07:00
|
|
|
const struct edid *edid)
|
2016-08-13 03:48:50 +07:00
|
|
|
{
|
|
|
|
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);
|
|
|
|
|
2017-12-13 15:44:26 +07: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);
|
|
|
|
|
2017-10-16 11:08:09 +07:00
|
|
|
drm_object_property_set_value(&connector->base,
|
|
|
|
dev->mode_config.non_desktop_property,
|
|
|
|
connector->display_info.non_desktop);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
ret = drm_property_replace_global_blob(dev,
|
|
|
|
&connector->edid_blob_ptr,
|
|
|
|
size,
|
|
|
|
edid,
|
|
|
|
&connector->base,
|
|
|
|
dev->mode_config.edid_property);
|
2019-03-13 09:17:22 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
return drm_connector_set_tile_property(connector);
|
2016-08-13 03:48:50 +07:00
|
|
|
}
|
2018-07-09 15:40:06 +07:00
|
|
|
EXPORT_SYMBOL(drm_connector_update_edid_property);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
drm: Add a new connector atomic property for link status
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requirements of the mode. Black screen follows.
One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would
also conflict with the idea of making setcrtc asynchronous in the
future, returning before the actual mode setting and link training.
Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on
practical not theoretical capabilities. However, the changes for link
training are pretty drastic, all for the sake of error handling and
DP compliance, when the most common happy day scenario is the current
approach of link training at mode setting time, using the optimal
parameters for the mode. It is also not certain all hardware could do
this without the pipe on; not even all our hardware can do this. Some
of this can be solved, but not trivially.
Both of the above ideas also fail to address link degradation *during*
operation.
The solution is to add a new "link-status" connector property in order
to address link training failure in a way that:
a) changes the current happy day scenario as little as possible, to
avoid regressions, b) can be implemented the same way by all drm
drivers, c) is still opt-in for the drivers and userspace, and opting
out doesn't regress the user experience, d) doesn't prevent drivers
from implementing better or alternate approaches, possibly without
userspace involvement. And, of course, handles all the issues presented.
In the usual happy day scenario, this is always "good". If something
fails during or after a mode set, the kernel driver can set the link
status to "bad" and issue a hotplug uevent for userspace to have it
re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
again. If the theoretical capabilities of the link can't be reached,
the mode list is trimmed based on that.
v7 by Jani:
* Rebase, simplify set property while at it, checkpatch fix
v6:
* Fix a typo in kernel doc (Sean Paul)
v5:
* Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
v4:
* Add comments in kernel-doc format (Daniel Vetter)
* Update the kernel-doc for link-status (Sean Paul)
v3:
* Fixed a build error (Jani Saarinen)
v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net> (for the -modesetting patch)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com
2016-12-16 17:29:06 +07:00
|
|
|
/**
|
2018-07-09 15:40:08 +07: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 17:29:06 +07: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.
|
|
|
|
*/
|
2018-07-09 15:40:08 +07:00
|
|
|
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 17:29:06 +07: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);
|
|
|
|
}
|
2018-07-09 15:40:08 +07:00
|
|
|
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 17:29:06 +07:00
|
|
|
|
2018-10-13 01:42:32 +07: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);
|
|
|
|
|
2018-09-18 20:55:20 +07:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
2017-11-26 02:35:49 +07:00
|
|
|
/**
|
|
|
|
* drm_connector_init_panel_orientation_property -
|
|
|
|
* initialize the connecters panel_orientation property
|
|
|
|
* @connector: connector for which to init the panel-orientation property.
|
|
|
|
* @width: width in pixels of the panel, used for panel quirk detection
|
|
|
|
* @height: height in pixels of the panel, used for panel quirk detection
|
|
|
|
*
|
|
|
|
* This function should only be called for built-in panels, after setting
|
|
|
|
* connector->display_info.panel_orientation first (if known).
|
|
|
|
*
|
|
|
|
* This function will check for platform specific (e.g. DMI based) quirks
|
|
|
|
* overriding display_info.panel_orientation first, then if panel_orientation
|
|
|
|
* is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
|
|
|
|
* "panel orientation" property to the connector.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* Zero on success, negative errno on failure.
|
|
|
|
*/
|
|
|
|
int drm_connector_init_panel_orientation_property(
|
|
|
|
struct drm_connector *connector, int width, int height)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = connector->dev;
|
|
|
|
struct drm_display_info *info = &connector->display_info;
|
|
|
|
struct drm_property *prop;
|
|
|
|
int orientation_quirk;
|
|
|
|
|
|
|
|
orientation_quirk = drm_get_panel_orientation_quirk(width, height);
|
|
|
|
if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
|
|
|
|
info->panel_orientation = orientation_quirk;
|
|
|
|
|
|
|
|
if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
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_init_panel_orientation_property);
|
|
|
|
|
2018-07-09 15:40:08 +07:00
|
|
|
int drm_connector_set_obj_prop(struct drm_mode_object *obj,
|
2016-08-13 03:48:50 +07:00
|
|
|
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);
|
|
|
|
|
2017-07-25 19:02:04 +07:00
|
|
|
if (!ret)
|
2016-08-13 03:48:50 +07:00
|
|
|
drm_object_property_set_value(&connector->base, property, value);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-07-09 15:40:08 +07:00
|
|
|
int drm_connector_property_set_ioctl(struct drm_device *dev,
|
|
|
|
void *data, struct drm_file *file_priv)
|
2016-08-13 03:48:50 +07:00
|
|
|
{
|
|
|
|
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 18:09:43 +07: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)
|
2016-08-13 03:48:50 +07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* 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 18:09:43 +07: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;
|
|
|
|
}
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
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 18:09:43 +07:00
|
|
|
LIST_HEAD(export_list);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
if (!drm_core_check_feature(dev, DRIVER_MODESET))
|
2018-09-14 02:20:50 +07:00
|
|
|
return -EOPNOTSUPP;
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
|
|
|
|
|
2017-03-15 13:25:07 +07:00
|
|
|
connector = drm_connector_lookup(dev, file_priv, out_resp->connector_id);
|
2016-12-14 06:08:10 +07:00
|
|
|
if (!connector)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2019-09-14 06:28:57 +07:00
|
|
|
encoders_count = hweight32(connector->possible_encoders);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
2016-12-14 06:08:10 +07:00
|
|
|
if ((out_resp->count_encoders >= encoders_count) && encoders_count) {
|
|
|
|
copied = 0;
|
|
|
|
encoder_ptr = (uint32_t __user *)(unsigned long)(out_resp->encoders_ptr);
|
2018-06-28 20:13:09 +07:00
|
|
|
|
2019-09-14 06:28:57 +07:00
|
|
|
drm_connector_for_each_possible_encoder(connector, encoder) {
|
2018-06-28 20:13:09 +07:00
|
|
|
if (put_user(encoder->base.id, encoder_ptr + copied)) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto out;
|
2016-12-14 06:08:10 +07:00
|
|
|
}
|
2018-06-28 20:13:09 +07:00
|
|
|
copied++;
|
2016-12-14 06:08:10 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
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);
|
2016-08-13 03:48:50 +07:00
|
|
|
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;
|
|
|
|
|
2016-12-14 06:08:10 +07:00
|
|
|
/* 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 18:09:43 +07:00
|
|
|
if (drm_mode_expose_to_userspace(mode, &export_list,
|
|
|
|
file_priv)) {
|
|
|
|
list_add_tail(&mode->export_head, &export_list);
|
2016-12-14 06:08:10 +07:00
|
|
|
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 18:09:43 +07:00
|
|
|
}
|
2016-08-13 03:48:50 +07: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 18:09:43 +07: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.
|
2016-08-13 03:48:50 +07:00
|
|
|
*/
|
|
|
|
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 18:09:43 +07:00
|
|
|
list_for_each_entry(mode, &export_list, export_head) {
|
2016-08-13 03:48:50 +07:00
|
|
|
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 18:09:43 +07: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;
|
2016-08-13 03:48:50 +07:00
|
|
|
if (copy_to_user(mode_ptr + copied,
|
|
|
|
&u_mode, sizeof(u_mode))) {
|
|
|
|
ret = -EFAULT;
|
2017-06-21 03:28:37 +07:00
|
|
|
mutex_unlock(&dev->mode_config.mutex);
|
|
|
|
|
2016-08-13 03:48:50 +07:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
copied++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
out_resp->count_modes = mode_count;
|
|
|
|
mutex_unlock(&dev->mode_config.mutex);
|
2017-06-21 03:28:37 +07:00
|
|
|
|
|
|
|
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:
|
2017-02-28 21:46:39 +07:00
|
|
|
drm_connector_put(connector);
|
2016-08-13 03:48:50 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-11-14 18:58:24 +07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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,
|
|
|
|
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:
|
2018-12-17 14:00:38 +07:00
|
|
|
* new tile group or NULL.
|
2016-11-14 18:58:24 +07:00
|
|
|
*/
|
|
|
|
struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
|
|
|
|
char topology[8])
|
|
|
|
{
|
|
|
|
struct drm_tile_group *tg;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
tg = kzalloc(sizeof(*tg), GFP_KERNEL);
|
|
|
|
if (!tg)
|
2018-12-17 14:00:38 +07:00
|
|
|
return NULL;
|
2016-11-14 18:58:24 +07:00
|
|
|
|
|
|
|
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);
|
2018-12-17 14:00:38 +07:00
|
|
|
tg = NULL;
|
2016-11-14 18:58:24 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&dev->mode_config.idr_mutex);
|
|
|
|
return tg;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_mode_create_tile_group);
|