linux-imx

// SPDX-License-Identifier: GPL-2.0

/*

 * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.

 * Author: Brian Starkey <brian.starkey@arm.com>

 *

 * This program is free software and is provided to you under the terms of the

 * GNU General Public License version 2 as published by the Free Software

 * Foundation, and any use by you of this program is subject to the terms

 * of such GNU licence.

 */

​

#include <drm/drm_crtc.h>

#include <drm/drm_modeset_helper_vtables.h>

#include <drm/drm_property.h>

#include <drm/drm_writeback.h>

#include <drm/drmP.h>

#include <linux/dma-fence.h>

​

/**

 * DOC: overview

 *

 * Writeback connectors are used to expose hardware which can write the output

 * from a CRTC to a memory buffer. They are used and act similarly to other

 * types of connectors, with some important differences:

 *

 * * Writeback connectors don't provide a way to output visually to the user.

 *

 * * Writeback connectors are visible to userspace only when the client sets

 *   DRM_CLIENT_CAP_WRITEBACK_CONNECTORS.

 *

 * * Writeback connectors don't have EDID.

 *

 * A framebuffer may only be attached to a writeback connector when the

 * connector is attached to a CRTC. The WRITEBACK_FB_ID property which sets the

 * framebuffer applies only to a single commit (see below). A framebuffer may

 * not be attached while the CRTC is off.

 *

 * Unlike with planes, when a writeback framebuffer is removed by userspace DRM

 * makes no attempt to remove it from active use by the connector. This is

 * because no method is provided to abort a writeback operation, and in any

 * case making a new commit whilst a writeback is ongoing is undefined (see

 * WRITEBACK_OUT_FENCE_PTR below). As soon as the current writeback is finished,

 * the framebuffer will automatically no longer be in active use. As it will

 * also have already been removed from the framebuffer list, there will be no

 * way for any userspace application to retrieve a reference to it in the

 * intervening period.

 *

 * Writeback connectors have some additional properties, which userspace

 * can use to query and control them:

 *

 *  "WRITEBACK_FB_ID":

 *  Write-only object property storing a DRM_MODE_OBJECT_FB: it stores the

 *  framebuffer to be written by the writeback connector. This property is

 *  similar to the FB_ID property on planes, but will always read as zero

 *  and is not preserved across commits.

 *  Userspace must set this property to an output buffer every time it

 *  wishes the buffer to get filled.

 *

 *  "WRITEBACK_PIXEL_FORMATS":

 *  Immutable blob property to store the supported pixel formats table. The

 *  data is an array of u32 DRM_FORMAT_* fourcc values.

 *  Userspace can use this blob to find out what pixel formats are supported

 *  by the connector's writeback engine.