linux/include/drm/drm_mode_config.h

981 lines
33 KiB
C
Raw Normal View History

/*
* Copyright (c) 2016 Intel Corporation
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting documentation, and
* that the name of the copyright holders not be used in advertising or
* publicity pertaining to distribution of the software without specific,
* written prior permission. The copyright holders make no representations
* about the suitability of this software for any purpose. It is provided "as
* is" without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
* OF THIS SOFTWARE.
*/
#ifndef __DRM_MODE_CONFIG_H__
#define __DRM_MODE_CONFIG_H__
#include <linux/mutex.h>
#include <linux/types.h>
#include <linux/idr.h>
#include <linux/workqueue.h>
drm: rework delayed connector cleanup in connector_iter PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and don't block on anything else. That means a free list plus locking, a standard pattern. v2: - Correctly free connectors only on last ref. Oops (Chris). - use llist_head/node (Chris). v3 - Add init_llist_head (Chris). Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter") Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v4.11+: 613051dac40d ("drm: locking&new iterators for connector_list" Cc: <stable@vger.kernel.org> # v4.11+ Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: David Airlie <airlied@linux.ie> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Mark Brown <broonie@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Thierry Escande <thierry.escande@collabora.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
2017-12-13 12:49:36 +00:00
#include <linux/llist.h>
#include <drm/drm_modeset_lock.h>
struct drm_file;
struct drm_device;
struct drm_atomic_state;
struct drm_mode_fb_cmd2;
struct drm_format_info;
struct drm_display_mode;
/**
* struct drm_mode_config_funcs - basic driver provided mode setting functions
*
* Some global (i.e. not per-CRTC, connector, etc) mode setting functions that
* involve drivers.
*/
struct drm_mode_config_funcs {
/**
* @fb_create:
*
* Create a new framebuffer object. The core does basic checks on the
* requested metadata, but most of that is left to the driver. See
* &struct drm_mode_fb_cmd2 for details.
*
* To validate the pixel format and modifier drivers can use
* drm_any_plane_has_format() to make sure at least one plane supports
* the requested values. Note that the driver must first determine the
* actual modifier used if the request doesn't have it specified,
* ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
*
* IMPORTANT: These implied modifiers for legacy userspace must be
* stored in struct &drm_framebuffer, including all relevant metadata
* like &drm_framebuffer.pitches and &drm_framebuffer.offsets if the
* modifier enables additional planes beyond the fourcc pixel format
* code. This is required by the GETFB2 ioctl.
*
* If the parameters are deemed valid and the backing storage objects in
* the underlying memory manager all exist, then the driver allocates
* a new &drm_framebuffer structure, subclassed to contain
* driver-specific information (like the internal native buffer object
* references). It also needs to fill out all relevant metadata, which
* should be done by calling drm_helper_mode_fill_fb_struct().
*
* The initialization is finalized by calling drm_framebuffer_init(),
* which registers the framebuffer and makes it accessible to other
* threads.
*
* RETURNS:
*
* A new framebuffer with an initial reference count of 1 or a negative
* error code encoded with ERR_PTR().
*/
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd);
/**
* @get_format_info:
*
* Allows a driver to return custom format information for special
* fb layouts (eg. ones with auxiliary compression control planes).
*
* RETURNS:
*
* The format information specific to the given fb metadata, or
* NULL if none is found.
*/
const struct drm_format_info *(*get_format_info)(const struct drm_mode_fb_cmd2 *mode_cmd);
/**
* @output_poll_changed:
*
* Callback used by helpers to inform the driver of output configuration
* changes.
*
* Drivers implementing fbdev emulation use drm_kms_helper_hotplug_event()
* to call this hook to inform the fbdev helper of output changes.
*
* This hook is deprecated, drivers should instead use
* drm_fbdev_generic_setup() which takes care of any necessary
* hotplug event forwarding already without further involvement by
* the driver.
*/
void (*output_poll_changed)(struct drm_device *dev);
/**
* @mode_valid:
*
* Device specific validation of display modes. Can be used to reject
* modes that can never be supported. Only device wide constraints can
* be checked here. crtc/encoder/bridge/connector specific constraints
* should be checked in the .mode_valid() hook for each specific object.
*/
enum drm_mode_status (*mode_valid)(struct drm_device *dev,
const struct drm_display_mode *mode);
/**
* @atomic_check:
*
* This is the only hook to validate an atomic modeset update. This
* function must reject any modeset and state changes which the hardware
* or driver doesn't support. This includes but is of course not limited
* to:
*
* - Checking that the modes, framebuffers, scaling and placement
* requirements and so on are within the limits of the hardware.
*
* - Checking that any hidden shared resources are not oversubscribed.
* This can be shared PLLs, shared lanes, overall memory bandwidth,
* display fifo space (where shared between planes or maybe even
* CRTCs).
*
* - Checking that virtualized resources exported to userspace are not
* oversubscribed. For various reasons it can make sense to expose
* more planes, crtcs or encoders than which are physically there. One
* example is dual-pipe operations (which generally should be hidden
* from userspace if when lockstepped in hardware, exposed otherwise),
* where a plane might need 1 hardware plane (if it's just on one
* pipe), 2 hardware planes (when it spans both pipes) or maybe even
* shared a hardware plane with a 2nd plane (if there's a compatible
* plane requested on the area handled by the other pipe).
*
* - Check that any transitional state is possible and that if
* requested, the update can indeed be done in the vblank period
* without temporarily disabling some functions.
*
* - Check any other constraints the driver or hardware might have.
*
* - This callback also needs to correctly fill out the &drm_crtc_state
* in this update to make sure that drm_atomic_crtc_needs_modeset()
* reflects the nature of the possible update and returns true if and
* only if the update cannot be applied without tearing within one
* vblank on that CRTC. The core uses that information to reject
* updates which require a full modeset (i.e. blanking the screen, or
* at least pausing updates for a substantial amount of time) if
* userspace has disallowed that in its request.
*
* - The driver also does not need to repeat basic input validation
* like done for the corresponding legacy entry points. The core does
* that before calling this hook.
*
* See the documentation of @atomic_commit for an exhaustive list of
* error conditions which don't have to be checked at the in this
* callback.
*
* See the documentation for &struct drm_atomic_state for how exactly
* an atomic modeset update is described.
*
* Drivers using the atomic helpers can implement this hook using
* drm_atomic_helper_check(), or one of the exported sub-functions of
* it.
*
* RETURNS:
*
* 0 on success or one of the below negative error codes:
*
* - -EINVAL, if any of the above constraints are violated.
*
* - -EDEADLK, when returned from an attempt to acquire an additional
* &drm_modeset_lock through drm_modeset_lock().
*
* - -ENOMEM, if allocating additional state sub-structures failed due
* to lack of memory.
*
* - -EINTR, -EAGAIN or -ERESTARTSYS, if the IOCTL should be restarted.
* This can either be due to a pending signal, or because the driver
* needs to completely bail out to recover from an exceptional
* situation like a GPU hang. From a userspace point all errors are
* treated equally.
*/
int (*atomic_check)(struct drm_device *dev,
struct drm_atomic_state *state);
/**
* @atomic_commit:
*
* This is the only hook to commit an atomic modeset update. The core
* guarantees that @atomic_check has been called successfully before
* calling this function, and that nothing has been changed in the
* interim.
*
* See the documentation for &struct drm_atomic_state for how exactly
* an atomic modeset update is described.
*
* Drivers using the atomic helpers can implement this hook using
* drm_atomic_helper_commit(), or one of the exported sub-functions of
* it.
*
* Nonblocking commits (as indicated with the nonblock parameter) must
* do any preparatory work which might result in an unsuccessful commit
* in the context of this callback. The only exceptions are hardware
* errors resulting in -EIO. But even in that case the driver must
* ensure that the display pipe is at least running, to avoid
* compositors crashing when pageflips don't work. Anything else,
* specifically committing the update to the hardware, should be done
* without blocking the caller. For updates which do not require a
* modeset this must be guaranteed.
*
* The driver must wait for any pending rendering to the new
* framebuffers to complete before executing the flip. It should also
* wait for any pending rendering from other drivers if the underlying
* buffer is a shared dma-buf. Nonblocking commits must not wait for
* rendering in the context of this callback.
*
* An application can request to be notified when the atomic commit has
* completed. These events are per-CRTC and can be distinguished by the
* CRTC index supplied in &drm_event to userspace.
*
* The drm core will supply a &struct drm_event in each CRTC's
* &drm_crtc_state.event. See the documentation for
* &drm_crtc_state.event for more details about the precise semantics of
* this event.
*
* NOTE:
*
* Drivers are not allowed to shut down any display pipe successfully
* enabled through an atomic commit on their own. Doing so can result in
* compositors crashing if a page flip is suddenly rejected because the
* pipe is off.
*
* RETURNS:
*
* 0 on success or one of the below negative error codes:
*
* - -EBUSY, if a nonblocking updated is requested and there is
* an earlier updated pending. Drivers are allowed to support a queue
* of outstanding updates, but currently no driver supports that.
* Note that drivers must wait for preceding updates to complete if a
* synchronous update is requested, they are not allowed to fail the
* commit in that case.
*
* - -ENOMEM, if the driver failed to allocate memory. Specifically
* this can happen when trying to pin framebuffers, which must only
* be done when committing the state.
*
* - -ENOSPC, as a refinement of the more generic -ENOMEM to indicate
* that the driver has run out of vram, iommu space or similar GPU
* address space needed for framebuffer.
*
* - -EIO, if the hardware completely died.
*
* - -EINTR, -EAGAIN or -ERESTARTSYS, if the IOCTL should be restarted.
* This can either be due to a pending signal, or because the driver
* needs to completely bail out to recover from an exceptional
* situation like a GPU hang. From a userspace point of view all errors are
* treated equally.
*
* This list is exhaustive. Specifically this hook is not allowed to
* return -EINVAL (any invalid requests should be caught in
* @atomic_check) or -EDEADLK (this function must not acquire
* additional modeset locks).
*/
int (*atomic_commit)(struct drm_device *dev,
struct drm_atomic_state *state,
bool nonblock);
/**
* @atomic_state_alloc:
*
* This optional hook can be used by drivers that want to subclass struct
* &drm_atomic_state to be able to track their own driver-private global
* state easily. If this hook is implemented, drivers must also
* implement @atomic_state_clear and @atomic_state_free.
*
* Subclassing of &drm_atomic_state is deprecated in favour of using
* &drm_private_state and &drm_private_obj.
*
* RETURNS:
*
* A new &drm_atomic_state on success or NULL on failure.
*/
struct drm_atomic_state *(*atomic_state_alloc)(struct drm_device *dev);
/**
* @atomic_state_clear:
*
* This hook must clear any driver private state duplicated into the
* passed-in &drm_atomic_state. This hook is called when the caller
* encountered a &drm_modeset_lock deadlock and needs to drop all
* already acquired locks as part of the deadlock avoidance dance
* implemented in drm_modeset_backoff().
*
* Any duplicated state must be invalidated since a concurrent atomic
* update might change it, and the drm atomic interfaces always apply
* updates as relative changes to the current state.
*
* Drivers that implement this must call drm_atomic_state_default_clear()
* to clear common state.
*
* Subclassing of &drm_atomic_state is deprecated in favour of using
* &drm_private_state and &drm_private_obj.
*/
void (*atomic_state_clear)(struct drm_atomic_state *state);
/**
* @atomic_state_free:
*
* This hook needs driver private resources and the &drm_atomic_state
* itself. Note that the core first calls drm_atomic_state_clear() to
* avoid code duplicate between the clear and free hooks.
*
* Drivers that implement this must call
* drm_atomic_state_default_release() to release common resources.
*
* Subclassing of &drm_atomic_state is deprecated in favour of using
* &drm_private_state and &drm_private_obj.
*/
void (*atomic_state_free)(struct drm_atomic_state *state);
};
/**
* struct drm_mode_config - Mode configuration control structure
* @min_width: minimum fb pixel width on this device
* @min_height: minimum fb pixel height on this device
* @max_width: maximum fb pixel width on this device
* @max_height: maximum fb pixel height on this device
* @funcs: core driver provided mode setting functions
* @poll_enabled: track polling support for this device
* @poll_running: track polling status for this device
* @delayed_event: track delayed poll uevent deliver for this device
* @output_poll_work: delayed work for polling in process context
* @preferred_depth: preferred RBG pixel depth, used by fb helpers
* @prefer_shadow: hint to userspace to prefer shadow-fb rendering
* @cursor_width: hint to userspace for max cursor width
* @cursor_height: hint to userspace for max cursor height
* @helper_private: mid-layer private data
*
* Core mode resource tracking structure. All CRTC, encoders, and connectors
* enumerated by the driver are added here, as are global properties. Some
* global restrictions are also here, e.g. dimension restrictions.
*
* Framebuffer sizes refer to the virtual screen that can be displayed by
* the CRTC. This can be different from the physical resolution programmed.
* The minimum width and height, stored in @min_width and @min_height,
* describe the smallest size of the framebuffer. It correlates to the
* minimum programmable resolution.
* The maximum width, stored in @max_width, is typically limited by the
* maximum pitch between two adjacent scanlines. The maximum height, stored
* in @max_height, is usually only limited by the amount of addressable video
* memory. For hardware that has no real maximum, drivers should pick a
* reasonable default.
*
* See also @DRM_SHADOW_PLANE_MAX_WIDTH and @DRM_SHADOW_PLANE_MAX_HEIGHT.
*/
struct drm_mode_config {
/**
* @mutex:
*
* This is the big scary modeset BKL which protects everything that
* isn't protect otherwise. Scope is unclear and fuzzy, try to remove
* anything from under its protection and move it into more well-scoped
* locks.
*
* The one important thing this protects is the use of @acquire_ctx.
*/
struct mutex mutex;
/**
* @connection_mutex:
*
* This protects connector state and the connector to encoder to CRTC
* routing chain.
*
* For atomic drivers specifically this protects &drm_connector.state.
*/
struct drm_modeset_lock connection_mutex;
/**
* @acquire_ctx:
*
* Global implicit acquire context used by atomic drivers for legacy
* IOCTLs. Deprecated, since implicit locking contexts make it
* impossible to use driver-private &struct drm_modeset_lock. Users of
* this must hold @mutex.
*/
struct drm_modeset_acquire_ctx *acquire_ctx;
/**
* @idr_mutex:
*
* Mutex for KMS ID allocation and management. Protects both @object_idr
* and @tile_idr.
*/
struct mutex idr_mutex;
/**
* @object_idr:
*
* Main KMS ID tracking object. Use this idr for all IDs, fb, crtc,
* connector, modes - just makes life easier to have only one.
*/
struct idr object_idr;
/**
* @tile_idr:
*
* Use this idr for allocating new IDs for tiled sinks like use in some
* high-res DP MST screens.
*/
struct idr tile_idr;
/** @fb_lock: Mutex to protect fb the global @fb_list and @num_fb. */
struct mutex fb_lock;
/** @num_fb: Number of entries on @fb_list. */
int num_fb;
/** @fb_list: List of all &struct drm_framebuffer. */
struct list_head fb_list;
/**
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-13 23:08:06 +00:00
* @connector_list_lock: Protects @num_connector and
drm: rework delayed connector cleanup in connector_iter PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and don't block on anything else. That means a free list plus locking, a standard pattern. v2: - Correctly free connectors only on last ref. Oops (Chris). - use llist_head/node (Chris). v3 - Add init_llist_head (Chris). Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter") Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v4.11+: 613051dac40d ("drm: locking&new iterators for connector_list" Cc: <stable@vger.kernel.org> # v4.11+ Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: David Airlie <airlied@linux.ie> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Mark Brown <broonie@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Thierry Escande <thierry.escande@collabora.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
2017-12-13 12:49:36 +00:00
* @connector_list and @connector_free_list.
drm: locking&new iterators for connector_list The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-6-daniel.vetter@ffwll.ch
2016-12-13 23:08:06 +00:00
*/
spinlock_t connector_list_lock;
/**
* @num_connector: Number of connectors on this device. Protected by
* @connector_list_lock.
*/
int num_connector;
/**
* @connector_ida: ID allocator for connector indices.
*/
struct ida connector_ida;
/**
* @connector_list:
*
* List of connector objects linked with &drm_connector.head. Protected
* by @connector_list_lock. Only use drm_for_each_connector_iter() and
* &struct drm_connector_list_iter to walk this list.
*/
struct list_head connector_list;
drm: rework delayed connector cleanup in connector_iter PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and don't block on anything else. That means a free list plus locking, a standard pattern. v2: - Correctly free connectors only on last ref. Oops (Chris). - use llist_head/node (Chris). v3 - Add init_llist_head (Chris). Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter") Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v4.11+: 613051dac40d ("drm: locking&new iterators for connector_list" Cc: <stable@vger.kernel.org> # v4.11+ Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: David Airlie <airlied@linux.ie> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Mark Brown <broonie@kernel.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matt Hart <matthew.hart@linaro.org> Cc: Thierry Escande <thierry.escande@collabora.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213124936.17914-1-daniel.vetter@ffwll.ch
2017-12-13 12:49:36 +00:00
/**
* @connector_free_list:
*
* List of connector objects linked with &drm_connector.free_head.
* Protected by @connector_list_lock. Used by
* drm_for_each_connector_iter() and
* &struct drm_connector_list_iter to savely free connectors using
* @connector_free_work.
*/
struct llist_head connector_free_list;
/**
* @connector_free_work: Work to clean up @connector_free_list.
*/
struct work_struct connector_free_work;
/**
* @num_encoder:
*
* Number of encoders on this device. This is invariant over the
* lifetime of a device and hence doesn't need any locks.
*/
int num_encoder;
/**
* @encoder_list:
*
* List of encoder objects linked with &drm_encoder.head. This is
* invariant over the lifetime of a device and hence doesn't need any
* locks.
*/
struct list_head encoder_list;
/**
* @num_total_plane:
*
* Number of universal (i.e. with primary/curso) planes on this device.
* This is invariant over the lifetime of a device and hence doesn't
* need any locks.
*/
int num_total_plane;
/**
* @plane_list:
*
* List of plane objects linked with &drm_plane.head. This is invariant
* over the lifetime of a device and hence doesn't need any locks.
*/
struct list_head plane_list;
/**
* @num_crtc:
*
* Number of CRTCs on this device linked with &drm_crtc.head. This is invariant over the lifetime
* of a device and hence doesn't need any locks.
*/
int num_crtc;
/**
* @crtc_list:
*
* List of CRTC objects linked with &drm_crtc.head. This is invariant
* over the lifetime of a device and hence doesn't need any locks.
*/
struct list_head crtc_list;
/**
* @property_list:
*
* List of property type objects linked with &drm_property.head. This is
* invariant over the lifetime of a device and hence doesn't need any
* locks.
*/
struct list_head property_list;
/**
* @privobj_list:
*
* List of private objects linked with &drm_private_obj.head. This is
* invariant over the lifetime of a device and hence doesn't need any
* locks.
*/
struct list_head privobj_list;
int min_width, min_height;
int max_width, max_height;
const struct drm_mode_config_funcs *funcs;
/* output poll support */
bool poll_enabled;
bool poll_running;
bool delayed_event;
struct delayed_work output_poll_work;
/**
* @blob_lock:
*
* Mutex for blob property allocation and management, protects
* @property_blob_list and &drm_file.blobs.
*/
struct mutex blob_lock;
/**
* @property_blob_list:
*
* List of all the blob property objects linked with
* &drm_property_blob.head. Protected by @blob_lock.
*/
struct list_head property_blob_list;
/* pointers to standard properties */
/**
* @edid_property: Default connector property to hold the EDID of the
* currently connected sink, if any.
*/
struct drm_property *edid_property;
/**
* @dpms_property: Default connector property to control the
* connector's DPMS state.
*/
struct drm_property *dpms_property;
/**
* @path_property: Default connector property to hold the DP MST path
* for the port.
*/
struct drm_property *path_property;
/**
* @tile_property: Default connector property to store the tile
* position of a tiled screen, for sinks which need to be driven with
* multiple CRTCs.
*/
struct drm_property *tile_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 10:29:06 +00:00
/**
* @link_status_property: Default connector property for link status
* of a connector
*/
struct drm_property *link_status_property;
/**
* @plane_type_property: Default plane property to differentiate
* CURSOR, PRIMARY and OVERLAY legacy uses of planes.
*/
struct drm_property *plane_type_property;
/**
* @prop_src_x: Default atomic plane property for the plane source
* position in the connected &drm_framebuffer.
*/
struct drm_property *prop_src_x;
/**
* @prop_src_y: Default atomic plane property for the plane source
* position in the connected &drm_framebuffer.
*/
struct drm_property *prop_src_y;
/**
* @prop_src_w: Default atomic plane property for the plane source
* position in the connected &drm_framebuffer.
*/
struct drm_property *prop_src_w;
/**
* @prop_src_h: Default atomic plane property for the plane source
* position in the connected &drm_framebuffer.
*/
struct drm_property *prop_src_h;
/**
* @prop_crtc_x: Default atomic plane property for the plane destination
* position in the &drm_crtc is being shown on.
*/
struct drm_property *prop_crtc_x;
/**
* @prop_crtc_y: Default atomic plane property for the plane destination
* position in the &drm_crtc is being shown on.
*/
struct drm_property *prop_crtc_y;
/**
* @prop_crtc_w: Default atomic plane property for the plane destination
* position in the &drm_crtc is being shown on.
*/
struct drm_property *prop_crtc_w;
/**
* @prop_crtc_h: Default atomic plane property for the plane destination
* position in the &drm_crtc is being shown on.
*/
struct drm_property *prop_crtc_h;
/**
* @prop_fb_id: Default atomic plane property to specify the
* &drm_framebuffer.
*/
struct drm_property *prop_fb_id;
drm/fence: add in-fences support There is now a new property called IN_FENCE_FD attached to every plane state that receives sync_file fds from userspace via the atomic commit IOCTL. The fd is then translated to a fence (that may be a fence_array subclass or just a normal fence) and then used by DRM to fence_wait() for all fences in the sync_file to signal. So it only commits when all framebuffers are ready to scanout. v2: Comments by Daniel Vetter: - remove set state->fence = NULL in destroy phase - accept fence -1 as valid and just return 0 - do not call fence_get() - sync_file_fences_get() already calls it - fence_put() if state->fence is already set, in case userspace set the property more than once. v3: WARN_ON if fence is set but state has no FB v4: Comment from Maarten Lankhorst - allow set fence with no related fb v5: rename FENCE_FD to IN_FENCE_FD v6: Comments by Daniel Vetter: - rename plane_state->in_fence back to "fence" - re-introduce WARN_ON if fence set but no fb - rebase after fence -> dma_fence rename v7: Comments by Brian Starkey - set state->fence to NULL when duplicating the state - fail if IN_FENCE_FD was already set v8: rebase against latest drm-misc Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Tested-by: Robert Foss <robert.foss@collabora.com> [danvet: Rebase onto extracted drm_mode_config.[hc].] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-11-15 13:06:39 +00:00
/**
* @prop_in_fence_fd: Sync File fd representing the incoming fences
* for a Plane.
*/
struct drm_property *prop_in_fence_fd;
drm/fence: add out-fences support Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the out_fence pointer received in the OUT_FENCE_PTR prop to send the sync_file fd back to userspace. The sync_file and fd are allocated/created before commit, but the fd_install operation only happens after we know that commit succeed. v2: Comment by Rob Clark: - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here. Comment by Daniel Vetter: - Add clean up code for out_fences v3: Comments by Daniel Vetter: - create DRM_MODE_ATOMIC_EVENT_MASK - userspace should fill out_fences_ptr with the crtc_ids for which it wants fences back. v4: Create OUT_FENCE_PTR properties and remove old approach. v5: Comments by Brian Starkey: - Remove extra fence_get() in atomic_ioctl() - Check ret before iterating on the crtc_state - check ret before fd_install - set fence_state to NULL at the beginning - check fence_state->out_fence_ptr before put_user() - change order of fput() and put_unused_fd() on failure - Add access_ok() check to the out_fence_ptr received - Rebase after fence -> dma_fence rename - Store out_fence_ptr in the drm_atomic_state - Split crtc_setup_out_fence() - return -1 as out_fence with TEST_ONLY flag v6: Comments by Daniel Vetter - Add prepare/unprepare_crtc_signaling() - move struct drm_out_fence_state to drm_atomic.c - mark get_crtc_fence() as static Comments by Brian Starkey - proper set fence_ptr fence_state array - isolate fence_idx increment - improve error handling v7: Comments by Daniel Vetter - remove prefix from internal functions - make out_fence_ptr an s64 pointer - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail - fix doc issues - filter out OUT_FENCE_PTR == NULL and do not fail in this case - add complete_crtc_signalling() - krealloc fence_state on demand Comment by Brian Starkey - remove unused crtc_state arg from get_out_fence() v8: Comment by Brian Starkey - cancel events before check for !fence_state - convert a few lefovers u64 types for out_fence_ptr - fix memleak by assign fence_state earlier after realloc - proper accout num_fences in case of error v9: Comment by Brian Starkey - memset last position of fence_state after krealloc Comments by Sean Paul - pass install_fds in complete_crtc_signaling() instead of ret - put_user(-1, fence_ptr) when decoding props v10: Comment by Brian Starkey - remove unneeded num_fences increment on error path - kfree fence_state after installing fences fd v11: rebase against latest drm-misc v12: rebase again against latest drm-misc Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Brian Starkey <brian.starkey@arm.com> (v10) Reviewed-by: Sean Paul <seanpaul@chromium.org> Tested-by: Robert Foss <robert.foss@collabora.com> (v10) [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1479301221-13056-1-git-send-email-gustavo@padovan.org
2016-11-16 13:00:21 +00:00
/**
* @prop_out_fence_ptr: Sync File fd pointer representing the
* outgoing fences for a CRTC. Userspace should provide a pointer to a
* value of type s32, and then cast that pointer to u64.
drm/fence: add out-fences support Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the out_fence pointer received in the OUT_FENCE_PTR prop to send the sync_file fd back to userspace. The sync_file and fd are allocated/created before commit, but the fd_install operation only happens after we know that commit succeed. v2: Comment by Rob Clark: - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here. Comment by Daniel Vetter: - Add clean up code for out_fences v3: Comments by Daniel Vetter: - create DRM_MODE_ATOMIC_EVENT_MASK - userspace should fill out_fences_ptr with the crtc_ids for which it wants fences back. v4: Create OUT_FENCE_PTR properties and remove old approach. v5: Comments by Brian Starkey: - Remove extra fence_get() in atomic_ioctl() - Check ret before iterating on the crtc_state - check ret before fd_install - set fence_state to NULL at the beginning - check fence_state->out_fence_ptr before put_user() - change order of fput() and put_unused_fd() on failure - Add access_ok() check to the out_fence_ptr received - Rebase after fence -> dma_fence rename - Store out_fence_ptr in the drm_atomic_state - Split crtc_setup_out_fence() - return -1 as out_fence with TEST_ONLY flag v6: Comments by Daniel Vetter - Add prepare/unprepare_crtc_signaling() - move struct drm_out_fence_state to drm_atomic.c - mark get_crtc_fence() as static Comments by Brian Starkey - proper set fence_ptr fence_state array - isolate fence_idx increment - improve error handling v7: Comments by Daniel Vetter - remove prefix from internal functions - make out_fence_ptr an s64 pointer - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail - fix doc issues - filter out OUT_FENCE_PTR == NULL and do not fail in this case - add complete_crtc_signalling() - krealloc fence_state on demand Comment by Brian Starkey - remove unused crtc_state arg from get_out_fence() v8: Comment by Brian Starkey - cancel events before check for !fence_state - convert a few lefovers u64 types for out_fence_ptr - fix memleak by assign fence_state earlier after realloc - proper accout num_fences in case of error v9: Comment by Brian Starkey - memset last position of fence_state after krealloc Comments by Sean Paul - pass install_fds in complete_crtc_signaling() instead of ret - put_user(-1, fence_ptr) when decoding props v10: Comment by Brian Starkey - remove unneeded num_fences increment on error path - kfree fence_state after installing fences fd v11: rebase against latest drm-misc v12: rebase again against latest drm-misc Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Brian Starkey <brian.starkey@arm.com> (v10) Reviewed-by: Sean Paul <seanpaul@chromium.org> Tested-by: Robert Foss <robert.foss@collabora.com> (v10) [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1479301221-13056-1-git-send-email-gustavo@padovan.org
2016-11-16 13:00:21 +00:00
*/
struct drm_property *prop_out_fence_ptr;
/**
* @prop_crtc_id: Default atomic plane property to specify the
* &drm_crtc.
*/
struct drm_property *prop_crtc_id;
/**
* @prop_fb_damage_clips: Optional plane property to mark damaged
* regions on the plane in framebuffer coordinates of the framebuffer
* attached to the plane.
*
* The layout of blob data is simply an array of &drm_mode_rect. Unlike
* plane src coordinates, damage clips are not in 16.16 fixed point.
*/
struct drm_property *prop_fb_damage_clips;
/**
* @prop_active: Default atomic CRTC property to control the active
* state, which is the simplified implementation for DPMS in atomic
* drivers.
*/
struct drm_property *prop_active;
/**
* @prop_mode_id: Default atomic CRTC property to set the mode for a
* CRTC. A 0 mode implies that the CRTC is entirely disabled - all
* connectors must be of and active must be set to disabled, too.
*/
struct drm_property *prop_mode_id;
/**
* @prop_vrr_enabled: Default atomic CRTC property to indicate
* whether variable refresh rate should be enabled on the CRTC.
*/
struct drm_property *prop_vrr_enabled;
/**
* @dvi_i_subconnector_property: Optional DVI-I property to
* differentiate between analog or digital mode.
*/
struct drm_property *dvi_i_subconnector_property;
/**
* @dvi_i_select_subconnector_property: Optional DVI-I property to
* select between analog or digital mode.
*/
struct drm_property *dvi_i_select_subconnector_property;
drm: report dp downstream port type as a subconnector property Currently, downstream port type is only reported in debugfs. This information should be considered important since it reflects the actual physical connector type. Some userspace (e.g. window compositors) may want to show this info to a user. The 'subconnector' property is already utilized for DVI-I and TV-out for reporting connector subtype. The initial motivation for this feature came from i2c test [1]. It is supposed to be skipped on VGA connectors, but it cannot detect VGA over DP and fails instead. v2: - Ville: utilized drm_dp_is_branch() - Ville: implement DP 1.0 downstream type info - Replaced create_dp_properties with add_dp_subconnector_property - Added dp_set_subconnector_property helper v4: - Ville: add DP1.0 best assumption about subconnector - Ville: assume DVI is DVI-D - Ville: reuse Writeback enum value for Virtual subconnector - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort v5: rebase v6: - Jani Nikula: renamed a function name - Jani Nikula: addressed the issues with documentation [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b@intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev@intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1587732655-17544-1-git-send-email-jeevan.b@intel.com
2020-04-24 12:50:51 +00:00
/**
* @dp_subconnector_property: Optional DP property to differentiate
* between different DP downstream port types.
*/
struct drm_property *dp_subconnector_property;
/**
* @tv_subconnector_property: Optional TV property to differentiate
* between different TV connector types.
*/
struct drm_property *tv_subconnector_property;
/**
* @tv_select_subconnector_property: Optional TV property to select
* between different TV connector types.
*/
struct drm_property *tv_select_subconnector_property;
/**
* @legacy_tv_mode_property: Optional TV property to select
* the output TV mode.
*
* Superseded by @tv_mode_property
*/
struct drm_property *legacy_tv_mode_property;
/**
* @tv_mode_property: Optional TV property to select the TV
* standard output on the connector.
*/
struct drm_property *tv_mode_property;
/**
* @tv_left_margin_property: Optional TV property to set the left
* margin (expressed in pixels).
*/
struct drm_property *tv_left_margin_property;
/**
* @tv_right_margin_property: Optional TV property to set the right
* margin (expressed in pixels).
*/
struct drm_property *tv_right_margin_property;
/**
* @tv_top_margin_property: Optional TV property to set the right
* margin (expressed in pixels).
*/
struct drm_property *tv_top_margin_property;
/**
* @tv_bottom_margin_property: Optional TV property to set the right
* margin (expressed in pixels).
*/
struct drm_property *tv_bottom_margin_property;
/**
* @tv_brightness_property: Optional TV property to set the
* brightness.
*/
struct drm_property *tv_brightness_property;
/**
* @tv_contrast_property: Optional TV property to set the
* contrast.
*/
struct drm_property *tv_contrast_property;
/**
* @tv_flicker_reduction_property: Optional TV property to control the
* flicker reduction mode.
*/
struct drm_property *tv_flicker_reduction_property;
/**
* @tv_overscan_property: Optional TV property to control the overscan
* setting.
*/
struct drm_property *tv_overscan_property;
/**
* @tv_saturation_property: Optional TV property to set the
* saturation.
*/
struct drm_property *tv_saturation_property;
/**
* @tv_hue_property: Optional TV property to set the hue.
*/
struct drm_property *tv_hue_property;
/**
* @scaling_mode_property: Optional connector property to control the
* upscaling, mostly used for built-in panels.
*/
struct drm_property *scaling_mode_property;
/**
* @aspect_ratio_property: Optional connector property to control the
* HDMI infoframe aspect ratio setting.
*/
struct drm_property *aspect_ratio_property;
drm: content-type property for HDMI connector Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-05-15 13:59:27 +00:00
/**
* @content_type_property: Optional connector property to control the
* HDMI infoframe content type setting.
*/
struct drm_property *content_type_property;
/**
* @degamma_lut_property: Optional CRTC property to set the LUT used to
* convert the framebuffer's colors to linear gamma.
*/
struct drm_property *degamma_lut_property;
/**
* @degamma_lut_size_property: Optional CRTC property for the size of
* the degamma LUT as supported by the driver (read-only).
*/
struct drm_property *degamma_lut_size_property;
/**
* @ctm_property: Optional CRTC property to set the
* matrix used to convert colors after the lookup in the
* degamma LUT.
*/
struct drm_property *ctm_property;
/**
* @gamma_lut_property: Optional CRTC property to set the LUT used to
* convert the colors, after the CTM matrix, to the gamma space of the
* connected screen.
*/
struct drm_property *gamma_lut_property;
/**
* @gamma_lut_size_property: Optional CRTC property for the size of the
* gamma LUT as supported by the driver (read-only).
*/
struct drm_property *gamma_lut_size_property;
/**
* @suggested_x_property: Optional connector property with a hint for
* the position of the output on the host's screen.
*/
struct drm_property *suggested_x_property;
/**
* @suggested_y_property: Optional connector property with a hint for
* the position of the output on the host's screen.
*/
struct drm_property *suggested_y_property;
/**
* @non_desktop_property: Optional connector property with a hint
* that device isn't a standard display, and the console/desktop,
* should not be displayed on it.
*/
struct drm_property *non_desktop_property;
/**
* @panel_orientation_property: Optional connector property indicating
* how the lcd-panel is mounted inside the casing (e.g. normal or
* upside-down).
*/
struct drm_property *panel_orientation_property;
drm: Add writeback connector type Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/229037/
2017-03-29 16:42:32 +00:00
/**
* @writeback_fb_id_property: Property for writeback connectors, storing
* the ID of the output framebuffer.
* See also: drm_writeback_connector_init()
*/
struct drm_property *writeback_fb_id_property;
/**
* @writeback_pixel_formats_property: Property for writeback connectors,
* storing an array of the supported pixel formats for the writeback
* engine (read-only).
* See also: drm_writeback_connector_init()
*/
struct drm_property *writeback_pixel_formats_property;
/**
* @writeback_out_fence_ptr_property: Property for writeback connectors,
* fd pointer representing the outgoing fences for a writeback
* connector. Userspace should provide a pointer to a value of type s32,
* and then cast that pointer to u64.
* See also: drm_writeback_connector_init()
*/
struct drm_property *writeback_out_fence_ptr_property;
drm: Add writeback connector type Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/229037/
2017-03-29 16:42:32 +00:00
/**
drm: Fix docbook warnings in hdr metadata helper structures Fixes the following warnings: ./include/drm/drm_mode_config.h:841: warning: Incorrect use of kernel-doc format: * hdr_output_metadata_property: Connector property containing hdr ./include/drm/drm_mode_config.h:918: warning: Function parameter or member 'hdr_output_metadata_property' not described in 'drm_mode_config' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_output_metadata' not described in 'drm_connector' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_sink_metadata' not described in 'drm_connector' Also adds some property documentation for HDR Metadata Connector Property in connector property create function. v2: Fixed Sean Paul's review comments. v3: Fixed Daniel Vetter's review comments, added the UAPI structure definition section in kernel docs. v4: Fixed Daniel Vetter's review comments. v5: Added structure member references as per Daniel's suggestion. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Ville Syrjä" <ville.syrjala@linux.intel.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Reviewed-by: Sean Paul <sean@poorly.run> (v1) Signed-off-by: Uma Shankar <uma.shankar@intel.com> [danvet: Fix up markup: () for functions, & for structs. Style guide also recommends to prepend struct for structures.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1559647022-7336-1-git-send-email-uma.shankar@intel.com
2019-06-04 11:17:02 +00:00
* @hdr_output_metadata_property: Connector property containing hdr
* metatada. This will be provided by userspace compositors based
* on HDR content
*/
struct drm_property *hdr_output_metadata_property;
/**
* @content_protection_property: DRM ENUM property for content
* protection. See drm_connector_attach_content_protection_property().
*/
struct drm_property *content_protection_property;
drm: Add Content protection type property This patch adds a DRM ENUM property to the selected connectors. This property is used for mentioning the protected content's type from userspace to kernel HDCP authentication. Type of the stream is decided by the protected content providers. Type 0 content can be rendered on any HDCP protected display wires. But Type 1 content can be rendered only on HDCP2.2 protected paths. So when a userspace sets this property to Type 1 and starts the HDCP enable, kernel will honour it only if HDCP2.2 authentication is through for type 1. Else HDCP enable will be failed. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: cp_content_type is replaced with content_protection_type [daniel] check at atomic_set_property is removed [Maarten] v3: %s/content_protection_type/hdcp_content_type [Pekka] v4: property is created for the first requested connector and then reused. [Danvet] v5: kernel doc nits addressed [Daniel] Rebased as part of patch reordering. v6: Kernel docs are modified [pekka] v7: More details in Kernel docs. [pekka] v8: Few more clarification into kernel doc of content type [pekka] v9: Small fixes in coding style. v10: Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
2019-08-01 11:41:14 +00:00
/**
* @hdcp_content_type_property: DRM ENUM property for type of
* Protected Content.
*/
struct drm_property *hdcp_content_type_property;
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
/**
* @quirk_addfb_prefer_xbgr_30bpp:
*
* Special hack for legacy ADDFB to keep nouveau userspace happy. Should
* only ever be set by the nouveau kernel driver.
*/
bool quirk_addfb_prefer_xbgr_30bpp;
/**
* @quirk_addfb_prefer_host_byte_order:
*
* When set to true drm_mode_addfb() will pick host byte order
* pixel_format when calling drm_mode_addfb2(). This is how
* drm_mode_addfb() should have worked from day one. It
* didn't though, so we ended up with quirks in both kernel
* and userspace drivers to deal with the broken behavior.
* Simply fixing drm_mode_addfb() unconditionally would break
* these drivers, so add a quirk bit here to allow drivers
* opt-in.
*/
bool quirk_addfb_prefer_host_byte_order;
/**
* @async_page_flip: Does this device support async flips on the primary
* plane?
*/
bool async_page_flip;
/**
* @fb_modifiers_not_supported:
*
* When this flag is set, the DRM device will not expose modifier
* support to userspace. This is only used by legacy drivers that infer
* the buffer layout through heuristics without using modifiers. New
* drivers shall not set fhis flag.
*/
bool fb_modifiers_not_supported;
/**
* @normalize_zpos:
*
* If true the drm core will call drm_atomic_normalize_zpos() as part of
* atomic mode checking from drm_atomic_helper_check()
*/
bool normalize_zpos;
/**
* @modifiers_property: Plane property to list support modifier/format
* combination.
*/
struct drm_property *modifiers_property;
/* cursor size */
uint32_t cursor_width, cursor_height;
/**
* @suspend_state:
*
* Atomic state when suspended.
* Set by drm_mode_config_helper_suspend() and cleared by
* drm_mode_config_helper_resume().
*/
struct drm_atomic_state *suspend_state;
const struct drm_mode_config_helper_funcs *helper_private;
};
drm: Manage drm_mode_config_init with drmm_ drm_mode_config_cleanup is idempotent, so no harm in calling this twice. This allows us to gradually switch drivers over by removing explicit drm_mode_config_cleanup calls. With this step it's now also possible that (at least for simple drivers) automatic resource cleanup can be done correctly without a drm_driver->release hook. Therefore allow this now in devm_drm_dev_init(). Also with drmm_ explicit drm_driver->release hooks are kinda not the best option: Drivers can always just register their current release hook with drmm_add_action, but even better they could split them up to simplify the unwinding for the driver load failure case. So deprecate that hook to discourage future users. v2: Fixup the example in the kerneldoc too. v3: - For paranoia, double check that minor->dev == dev in the release hook, because I botched the pointer math in the drmm library. - Call drm_mode_config_cleanup when drmm_add_action fails, we'd be missing some mutex_destroy and ida_cleanup otherwise (Laurent) v4: Add a drmm_add_action_or_reset (like devm_ has) to encapsulate this pattern (Noralf). v5: Fix oversight in the new drmm_add_action_or_reset macro (Noralf) v4: Review from Sam: - drmm_mode_config_init wrapper (also suggested by Thomas) - improve commit message, explain better why ->relase is deprecated v5: - Make drmm_ the main function, with the old one as compat wrapper (Sam) - Add FIXME comments to drm_mode_config_cleanup/init() that drivers shouldn't use these anymore. - Move drmm_add_action_or_reset helper to an earlier patch. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-27-daniel.vetter@ffwll.ch
2020-03-23 14:49:25 +00:00
int __must_check drmm_mode_config_init(struct drm_device *dev);
/**
* drm_mode_config_init - DRM mode_configuration structure initialization
* @dev: DRM device
*
* This is the unmanaged version of drmm_mode_config_init() for drivers which
* still explicitly call drm_mode_config_cleanup().
*
* FIXME: This function is deprecated and drivers should be converted over to
* drmm_mode_config_init().
*/
static inline int drm_mode_config_init(struct drm_device *dev)
{
return drmm_mode_config_init(dev);
}
void drm_mode_config_reset(struct drm_device *dev);
void drm_mode_config_cleanup(struct drm_device *dev);
#endif