drm/vc4: Extend and edit documentation for output from the RST

 *

 * In VC4, the Pixel Valve is what most closely corresponds to the

 * DRM's concept of a CRTC.  The PV generates video timings from the

 * output's clock plus its configuration.  It pulls scaled pixels from

 * encoder's clock plus its configuration.  It pulls scaled pixels from

 * the HVS at that timing, and feeds it to the encoder.

 *

 * However, the DRM CRTC also collects the configuration of all the

 * DRM planes attached to it.  As a result, this file also manages

 * setup of the VC4 HVS's display elements on the CRTC.

 * DRM planes attached to it.  As a result, the CRTC is also

 * responsible for writing the display list for the HVS channel that

 * the CRTC will use.

 *

 * The 2835 has 3 different pixel valves.  pv0 in the audio power

 * domain feeds DSI0 or DPI, while pv1 feeds DS1 or SMI.  pv2 in the

 * DOC: VC4 DPI module

 *

 * The VC4 DPI hardware supports MIPI DPI type 4 and Nokia ViSSI

 * signals, which are routed out to GPIO0-27 with the ALT2 function.

 * signals.  On BCM2835, these can be routed out to GPIO0-27 with the

 * ALT2 function.

 */

#include "drm_atomic_helper.h"

/**

 * DOC: VC4 Falcon HDMI module

 *

 * The HDMI core has a state machine and a PHY.  Most of the unit

 * operates off of the HSM clock from CPRMAN.  It also internally uses

 * the PLLH_PIX clock for the PHY.

 * The HDMI core has a state machine and a PHY.  On BCM2835, most of

 * the unit operates off of the HSM clock from CPRMAN.  It also

 * internally uses the PLLH_PIX clock for the PHY.

 *

 * HDMI infoframes are kept within a small packet ram, where each

 * packet can be individually enabled for including in a frame.

 *

 * HDMI audio is implemented entirely within the HDMI IP block.  A

 * register in the HDMI encoder takes SPDIF frames from the DMA engine

 * and transfers them over an internal MAI (multi-channel audio

 * interconnect) bus to the encoder side for insertion into the video

 * blank regions.

 *

 * The driver's HDMI encoder does not yet support power management.

 * The HDMI encoder's power domain and the HSM/pixel clocks are kept

 * continuously running, and only the HDMI logic and packet ram are

 * powered off/on at disable/enable time.

 *

 * The driver does not yet support CEC control, though the HDMI

 * encoder block has CEC support.

 */

#include "drm_atomic_helper.h"

/**

 * DOC: VC4 HVS module.

 *

 * The HVS is the piece of hardware that does translation, scaling,

 * colorspace conversion, and compositing of pixels stored in

 * framebuffers into a FIFO of pixels going out to the Pixel Valve

 * (CRTC).  It operates at the system clock rate (the system audio

 * clock gate, specifically), which is much higher than the pixel

 * clock rate.

 * The Hardware Video Scaler (HVS) is the piece of hardware that does

 * translation, scaling, colorspace conversion, and compositing of

 * pixels stored in framebuffers into a FIFO of pixels going out to

 * the Pixel Valve (CRTC).  It operates at the system clock rate (the

 * system audio clock gate, specifically), which is much higher than

 * the pixel clock rate.

 *

 * There is a single global HVS, with multiple output FIFOs that can

 * be consumed by the PVs.  This file just manages the resources for

/**

 * DOC: Render command list generation

 *

 * In the V3D hardware, render command lists are what load and store

 * tiles of a framebuffer and optionally call out to binner-generated

 * command lists to do the 3D drawing for that tile.

 *

 * In the VC4 driver, render command list generation is performed by the

 * kernel instead of userspace.  We do this because validating a

 * user-submitted command list is hard to get right and has high CPU overhead,