Just a bit of OCD cleanup on headers - this function isn't the core
interface any more but just a helper for drivers who haven't yet
transitioned to universal planes. Put the declaration at the right
spot and sprinkle necessary #includes over all drivers.

Maybe this helps to encourage driver maintainers to do the switch.

v2: Fix #include ordering for tegra, reported by 0-day builder.

v3: Include required headers, reported by Thierry.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The "Renesas Corporation" listed in the copyright notice doesn't exist.
Replace it with "Renesas Electronics Corporation" and update the
copyright years.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC.  Replace all references to the CRTC fb with the
primary plane's fb.

This patch was generated by the Coccinelle semantic patching tool using
the following rules:

        @@ struct drm_crtc C; @@
        -   (C).fb
        +   C.primary->fb

        @@ struct drm_crtc *C; @@
        -   (C)->fb
        +   C->primary->fb

v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
    moved to a subsequent patch.

v2: Fixup several lingering crtc->fb instances that were missed in the
    first patch iteration.  [Rob Clark]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

When setting a new frame buffer with the mode set base operation the
pitch value might change. Set the hardware plane pitch register at the
same time as the plane base address in the rcar_du_plane_update_base()
function to make sure the pitch value always matches the frame buffer.

Cc: stable@vger.kernel.org
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Reuse the previously cast variable instead.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

This lets drivers see the flags requested by the application

[airlied: fixup for rcar/imx/msm]
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

The R8A7790 includes two internal LVDS encoders. Support them in the DU
driver.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7790 DU variant has a single RGB output called DPAD0 that can be
fed with the output of DU0, DU1 or DU2. Making the routing configurable.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Split the output routing specification between SoC-internal data,
specified in the rcar_du_device_info structure, and board data, passed
through platform data.

The DU has 5 possible outputs (DPAD0/1, LVDS0/1, TCON). SoC-internal
output routing data specify which output are valid, which CRTCs can be
connected to the valid outputs, and the type of in-SoC encoder for the
output.

Platform data then specifies external encoders and the output they are
connected to.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7790 DU has 3 CRTCs, split in two groups. Support them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Output routing is configured in group registers, move the corresponding
code from rcar_du_crtc.c to rcar_du_group.c.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7779 DU is split in per-CRTC resources (scan-out engine, blending
unit, timings generator, ...) and device-global resources (start/stop
control, planes, ...) shared between the two CRTCs.

The R8A7790 introduced a third CRTC with its own set of global resources
This would be modeled as two separate DU device instances if it wasn't
for a handful or resources that are shared between the three CRTCs
(mostly related to input and output routing). For this reason the
R8A7790 DU must be modeled as a single device with three CRTCs, two sets
of "semi-global" resources, and a few device-global resources.

Introduce a new rcar_du_group driver-specific object, without any real
counterpart in the DU documentation, that models those semi-global
resources.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Create a single rcar_du_encoder structure that implements a KMS encoder.
The current implementation is straightforward and only configures CRTC
output routing.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Some of the DU revisions use one clock and IRQ per CRTC instead of one
clock and IRQ per device. Retrieve the correct clock and register the
correct IRQ for each CRTC.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R-Car Display Unit (DU) DRM driver supports both superposition
processors and all eight planes in RGB and YUV formats with alpha
blending.

Only VGA and LVDS encoders and connectors are currently supported.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>