This adds the initial driver for panfrost which supports Arm Mali
Midgard and Bifrost family of GPUs. Currently, only the T860 and
T760 Midgard GPUs have been tested.

v2:
- Add GPU reset on job hangs (Tomeu)
- Add RuntimePM and devfreq support (Tomeu)
- Fix T760 support (Tomeu)
- Add a TODO file (Rob, Tomeu)
- Support multiple in fences (Tomeu)
- Drop support for shared fences (Tomeu)
- Fill in MMU de-init (Rob)
- Move register definitions back to single header (Rob)
- Clean-up hardcoded job submit todos (Rob)
- Implement feature setup based on features/issues (Rob)
- Add remaining Midgard DT compatible strings (Rob)

v3:
- Add support for reset lines (Neil)
- Add a MAINTAINERS entry (Rob)
- Call dma_set_mask_and_coherent (Rob)
- Do MMU invalidate on map and unmap. Restructure to do a single
  operation per map/unmap call. (Rob)
- Add a missing explicit padding to struct drm_panfrost_create_bo (Rob)
- Fix 0-day error: "panfrost_devfreq.c:151:9-16: ERROR: PTR_ERR applied after initialization to constant on line 150"
- Drop HW_FEATURE_AARCH64_MMU conditional (Rob)
- s/DRM_PANFROST_PARAM_GPU_ID/DRM_PANFROST_PARAM_GPU_PROD_ID/ (Rob)
- Check drm_gem_shmem_prime_import_sg_table() error code (Rob)
- Re-order power on sequence (Rob)
- Move panfrost_acquire_object_fences() before scheduling job (Rob)
- Add NULL checks on array pointers in job clean-up (Rob)
- Rework devfreq (Tomeu)
- Fix devfreq init with no regulator (Rob)
- Various WS and comments clean-up (Rob)

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: Lyude Paul <lyude@redhat.com>
Reviewed-by: NAlyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NMarty E. Plummer <hanetzer@startmail.com>
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409205427.6943-4-robh@kernel.org

Similar to the single handle drm_gem_object_lookup(),
drm_gem_objects_lookup() takes an array of handles and returns an array
of GEM objects.

v2:
- Take the userspace pointer directly and allocate the array.
- Expand the function documentation.

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>
Acked-by: NAlyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409205427.6943-3-robh@kernel.org

ARM Mali midgard GPU is similar to standard 64-bit stage 1 page tables, but
have a few differences. Add a new format type to represent the format. The
input address size is 48-bits and the output address size is 40-bits (and
possibly less?). Note that the later bifrost GPUs follow the standard
64-bit stage 1 format.

The differences in the format compared to 64-bit stage 1 format are:

The 3rd level page entry bits are 0x1 instead of 0x3 for page entries.

The access flags are not read-only and unprivileged, but read and write.
This is similar to stage 2 entries, but the memory attributes field matches
stage 1 being an index.

The nG bit is not set by the vendor driver. This one didn't seem to matter,
but we'll keep it aligned to the vendor driver.

Cc: Will Deacon <will.deacon@arm.com>
Acked-by: NRobin Murphy <robin.murphy@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: iommu@lists.linux-foundation.org
Acked-by: NAlyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409205427.6943-2-robh@kernel.org

The TFP410 supports 24 bit, single-edge and 12 bit, dual-edge modes.
Depending on how many wires are used (24/12) the driver can set the correct
bus_format.

If the information is not available in DT then assume 24 bit, single-edge
setup.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190401124143.17179-3-peter.ujfalusi@ti.com

tfp410 can be connect to host processor in 24bit, single-edge (24 lines) or
12bit, dual-edge (12 lines).

Add bus-width to the documentation so it can be used to select between the
two connection scheme.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190401124143.17179-2-peter.ujfalusi@ti.com

In case either the HPD gpio is not specified or when the HPD gpio can not
be used as interrupt we should tell the core that the HPD needs to be
polled for detecting hotplug.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190401123342.15767-1-peter.ujfalusi@ti.com

Add comments to the existing feature flags,
documenting which commands belong to them.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190410114227.25846-2-kraxel@redhat.com

Oops, the __iomem annotation was added to the header file only.
Add it to the implementation (and documentation) too.

Fixes: 5c5373b5 ("drm: switch drm_fb_xrgb8888_to_rgb888_dstclip to accept __iomem dst")
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190411044932.13247-1-kraxel@redhat.com

Due to copy/paste error, the fbdev format was changed to 32bpp = XRGB8888
which is an emulated format for the RGB565 drivers. Revert to to using the
fallback which is dev->mode_config.preferred_depth for the drivers that
set it or 32bpp for those that don't (repaper, st7586).

Fixes: 3eba3922 ("drm/tinydrm: Drop using tinydrm_device")
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410124345.25945-1-noralf@tronnes.org

It is generic code and having it in the helper will let other drivers
benefit from it.

One change was necessary assuming this to be true:
INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190407165243.54043-4-noralf@tronnes.org

This is done to stay consistent with our naming scheme of
_register() = others can start calling us from any thread.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190403125658.32389-1-noralf@tronnes.org

Now that we can express our DMA topology, rely on those property instead of
hardcoding an offset from the dma_addr_t which wasn't really great.

We still need to add some code to deal with the old DT that would lack that
property, but we move the offset to the DRM device dma_pfn_offset to be
able to rely on just the dma_addr_t associated to the GEM object.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5df781318e7e05f780a11ed243dcf2b9fe8a08cb.1554108995.git-series.maxime.ripard@bootlin.com

Finally have a reason for a backmerge other than "it's been a while"!

Backmerging drm-next to -misc-next to facilitate Rob Herring's work on
Panfrost.
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190410074828.10296-1-kraxel@redhat.com

Not all archs have the __io_virt() macro, so cirrus can't simply convert
pointers that way.  The drm format helpers have to use memcpy_toio()
instead.

This patch makes drm_fb_xrgb8888_to_rgb888_dstclip() accept a __iomem
dst pointer and use memcpy_toio() instead of memcpy().  The helper
function (drm_fb_xrgb8888_to_rgb888_line) has been changed to process a
single scanline.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190410063815.17062-4-kraxel@redhat.com

Not all archs have the __io_virt() macro, so cirrus can't simply convert
pointers that way.  The drm format helpers have to use memcpy_toio()
instead.

This patch makes drm_fb_xrgb8888_to_rgb565_dstclip() accept a __iomem
dst pointer and use memcpy_toio() instead of memcpy().  The helper
function (drm_fb_xrgb8888_to_rgb565_line) has been changed to process
a single scanline.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190410063815.17062-3-kraxel@redhat.com

Not all archs have the __io_virt() macro, so cirrus can't simply convert
pointers that way.  The drm format helpers have to use memcpy_toio()
instead.

This patch makes drm_fb_memcpy_dstclip() accept a __iomem dst pointer
and use memcpy_toio() instead of memcpy().  With that separating out the
memcpy loop into the drm_fb_memcpy_lines() helper isn't useful any more,
so move the code back into the calling functins.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190410063815.17062-2-kraxel@redhat.com

To prevent build fail on some platform which does
not have it in the include file chain.
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Suggested-by: NRandy Dunlap <rdunlap@infradead.org>
Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs")
Signed-off-by: NQiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409003617.4470-2-yuq825@gmail.com

Current implementation does not support MMU-less
plarforms.
Suggested-by: NRandy Dunlap <rdunlap@infradead.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs")
Signed-off-by: NQiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409003617.4470-1-yuq825@gmail.com

The Amlogic G12A embeds the same Synopsys DW-HDMI Controller,
but with :
- a "backport" of the HDR signaling registers from more recent
  DW-HDMI controllers, this will need a tweak since it's not
  normally present on this version of the DW-HDMI controller
- A direct mapping of TOP and DW-HDMI registers instead of an
  internal bus accessed using read/write registers
- Support for RX-SENSE, but not yet implemented
- Support for HDMI 2.1 Dynamic HDR, but not yet implemented
- Different registers mapping for the HDMI PHY setup

This patchs adds support for these changes while providing exact
same support as the previous GXBB, GXL & GXM SoCs.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-12-narmstrong@baylibre.com

Finally add the Amlogic G12A SoC compatible for the VPU driver.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-11-narmstrong@baylibre.com

While switching to the Common Clock Framework is still Work In Progress,
this patch adds the corresponding G12A HDMI PLL setup to be on-par
with the other SoCs support.

The G12A has only a single tweak about the high frequency setup,
where the HDMI PLL needs a specific setup to handle correctly the
5.94GHz DCO frequency.

Apart that, it handls ecorrectly all the other HDMI frequencies
and can achieve even better DMT clock frequency precision with
the larger fractional dividier width.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-10-narmstrong@baylibre.com

The Meson G12A SoCs uses the exact same CVBS encoder except a simple
CVBS DAC register offset and settings delta.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed subject typo]
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-9-narmstrong@baylibre.com

This patch adds support for the new OSD+VD Plane blending module
in the CRTC code by adding the G12A code to manage the blending
module and setting the right OSD1 & VD1 plane registers.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-8-narmstrong@baylibre.com

Amlogic G12A SoC supports the same set of Video Planes, but now
are handled by the new OSD plane blender module.

This patch uses the same VD1 plane for G12A, using the exact same scaler
and VD1 setup registers, except using the new blender register to
disable the plane.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
[narmstrong: fix typo in commit log]
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-7-narmstrong@baylibre.com

Amlogic G12A SoC supports now up to 3 OSD planes (1 more than the
previous SoCs) and a brand new OSD plane blender module.

This patch uses the same OSD1 plane for G12A, using the exact same scaler
and OSD1 setup registers, except using the new blender register to
disable the plane.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed typo in commit log]
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-6-narmstrong@baylibre.com

Amlogic G12A SoC needs a different VIU setup code,
handle it.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-5-narmstrong@baylibre.com

Amlogic G12A needs a different VPP setup code, handle it here.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-4-narmstrong@baylibre.com

This patch adds the new VPU registers added since the
Amlogic GXM SoCs.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-3-narmstrong@baylibre.com

On Amlogic G12A SoC, the 2,97GHz PLL frequency is not stable enough
to provide a correct 297MHz pixel clock, so switch the PLL base
frequency with a /2 OD when the 297MHz pixel clock is requested.

This solves the issue on G12A and also works fine on GXBB, GXL & GXM.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-2-narmstrong@baylibre.com

The Amlogic G12A SoC has a slighly modified DW-HDMI Glue with
support for HDMI 2.1 and a different DW-HDMI register access.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190313141030.5958-3-narmstrong@baylibre.com

The Amlogic G12A VPU is very similar to the Amlogic GXM VPU but with :
- an enhanced plane blender, with up to 3 OSD planes
- support for AFBC 1.2 decoder (for Bifrost GPU)
- support display mode up to 4k60@75Hz
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190313141030.5958-2-narmstrong@baylibre.com

Add the bindings for the Bifrost family of ARM Mali GPUs.

The Bifrost GPU architecture is similar to the Midgard family,
but with a different Shader Core & Execution Engine structures.

Bindings are based on the Midgard family bindings, but the inner
architectural changes makes it a separate family needing separate
bindings.

The Bifrost GPUs are present in a number of recent SoCs, like the
Amlogic G12A Family, and many other vendors.
The Amlogic vendor specific compatible is added to handle the
specific IP integration differences and dependencies.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NRob Herring <robh@kernel.org>
[narmstrong: fixed small typo in compatible description]
Link: https://patchwork.freedesktop.org/patch/msgid/20190401080949.14550-1-narmstrong@baylibre.com

Note that the lima mailing list is moderated.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Qiang Yu <yuq825@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: lima@lists.freedesktop.org
Signed-off-by: NQiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9138d8e8-5390-0650-9bc3-050b869e978c@infradead.orgReviewed-by: NNeil Armstrong <narmstrong@baylibre.com>

Time to kill some bad sample code people are copying from ;)

This is a complete rewrite of the cirrus driver.  The cirrus_mode_set()
function is pretty much the only function which is carried over largely
unmodified.  Everything else is upside down.

It is a single monster patch.  But given that it does some pretty
fundamental changes to the drivers workflow and also reduces the code
size by roughly 70% I think it'll still be alot easier to review than a
longish baby-step patch series.

Changes summary:
 - Given the small amout of video memory (4 MB) the cirrus device has
   the rewritten driver doesn't try to manage buffers there.  Instead
   it will blit (memcpy) the active framebuffer to video memory.
 - All gem objects are stored in main memory and are manged using the
   new shmem helpers.  ttm is out.
 - It supports RG16, RG24 and XR24 formats.  XR24 gets converted to RG24
   or RG16 at blit time if needed, to avoid the pitch becoming larger
   than what the cirrus hardware can handle.
 - The simple display pipeline is used.
 - The generic fbdev emulation is used.
 - It's a atomic driver now.
 - It runs wayland.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-6-kraxel@redhat.com

Simliar to drm_fb_xrgb8888_to_rgb565_dstclip() but converts to rgb888
instead of rgb565.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-5-kraxel@redhat.com

It is a drm_fb_xrgb8888_to_rgb565() variant which checks the clip
rectangle for the destination too.

Common code between drm_fb_xrgb8888_to_rgb565() and
drm_fb_xrgb8888_to_rgb565_dstclip() was factored out into the
drm_fb_xrgb8888_to_rgb565_lines() helper function.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-4-kraxel@redhat.com

It is a drm_fb_memcpy() variant which checks the clip rectangle for the
destination too.

Common code between drm_fb_memcpy() and drm_fb_memcpy_dstclip() was
factored out into the drm_fb_memcpy_lines() helper function.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-3-kraxel@redhat.com

Also rename them from tinydrm_* to drm_fb_*
Pure code motion, no functional change.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-2-kraxel@redhat.com

The file was removed in the below patch and is causing this error:
WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function Canvas ../drivers/gpu/drm/meson/meson_canvas.c' failed with return code

Fixes: 2bf6b5b0 ("drm/meson: exclusively use the canvas provider module")
Cc: Maxime Jourdan <mjourdan@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190403205652.183496-1-sean@poorly.run