linux-imx

/*

 * 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 <linux/export.h>

#include <drm/drmP.h>

#include <drm/drm_auth.h>

#include <drm/drm_framebuffer.h>

#include <drm/drm_atomic.h>

#include <drm/drm_atomic_uapi.h>

#include <drm/drm_print.h>

#include <drm/drm_util.h>

​

#include "drm_internal.h"

#include "drm_crtc_internal.h"

​

/**

 * DOC: overview

 *

 * Frame buffers are abstract memory objects that provide a source of pixels to

 * scanout to a CRTC. Applications explicitly request the creation of frame

 * buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and receive an opaque

 * handle that can be passed to the KMS CRTC control, plane configuration and

 * page flip functions.

 *

 * Frame buffers rely on the underlying memory manager for allocating backing

 * storage. When creating a frame buffer applications pass a memory handle

 * (or a list of memory handles for multi-planar formats) through the

 * &struct drm_mode_fb_cmd2 argument. For drivers using GEM as their userspace

 * buffer management interface this would be a GEM handle.  Drivers are however

 * free to use their own backing storage object handles, e.g. vmwgfx directly

 * exposes special TTM handles to userspace and so expects TTM handles in the

 * create ioctl and not GEM handles.

 *

 * Framebuffers are tracked with &struct drm_framebuffer. They are published

 * using drm_framebuffer_init() - after calling that function userspace can use

 * and access the framebuffer object. The helper function

 * drm_helper_mode_fill_fb_struct() can be used to pre-fill the required

 * metadata fields.

 *

 * The lifetime of a drm framebuffer is controlled with a reference count,

 * drivers can grab additional references with drm_framebuffer_get() and drop

 * them again with drm_framebuffer_put(). For driver-private framebuffers for

 * which the last reference is never dropped (e.g. for the fbdev framebuffer

 * when the struct &struct drm_framebuffer is embedded into the fbdev helper