drm/atomic: Create __drm_atomic_helper_crtc_reset() for subclassing crtc_state.
We already have __drm_atomic_helper_connector_reset() and
__drm_atomic_helper_plane_reset(), extend this to crtc as well.
This will allow us to set default values in the crtc_state, without
having to do it in each driver separately.
Of all drivers that need conversion, only nouveau is done in this
commit, because it wrote its own __drm_atomic_helper_crtc_reset(),
clashing with the drm core.
Andreas Pretzsch [Tue, 16 Apr 2019 10:16:30 +0000 (12:16 +0200)]
drm/panel: simple: Add support for EDT ET035012DM6
Add support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT.
The datasheet with all specs can be retrieved online:
https://www.glynshop.com/erp/owweb/Daten/DSS/EDT/Products/ \
Specifications/Active%20Displays/ET035012DM6.pdf
Peter Ujfalusi [Tue, 26 Feb 2019 07:55:23 +0000 (09:55 +0200)]
drm/panel: Add OSD101T2587-53TS driver
The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.
Paweł Chmiel [Fri, 22 Feb 2019 17:51:53 +0000 (18:51 +0100)]
drm/panel: Add driver for Samsung S6E63M0 panel
This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
spi. It's based on already removed, non-device-tree S6E63M0 driver and
panel-samsung-ld9040. It can be found for example in some of Samsung
Aries based phones.
Peter Griffin [Fri, 19 Apr 2019 08:33:01 +0000 (09:33 +0100)]
drm/lima: handle shared irq case for lima_pp_bcast_irq_handler
On Hikey board all lima ip blocks are shared with one irq.
This patch avoids a NULL ptr deref crash on this platform
on startup. Tested with Weston and kmscube.
Philip Yang [Wed, 17 Apr 2019 22:15:19 +0000 (22:15 +0000)]
drm: increase drm mmap_range size to 1TB
After patch "drm: Use the same mmap-range offset and size for GEM and
TTM", application failed to create bo of system memory because drm
mmap_range size decrease to 64GB from original 1TB. This is not big
enough for applications. Increase the drm mmap_range size to 1TB.
Eric Anholt [Tue, 16 Apr 2019 22:58:56 +0000 (15:58 -0700)]
drm/v3d: Add missing implicit synchronization.
It is the expectation of existing userspace (X11 + Mesa, in
particular) that jobs submitted to the kernel against a shared BO will
get implicitly synchronized by their submission order. If we want to
allow clever userspace to disable implicit synchronization, we should
do that under its own submit flag (as amdgpu and lima do).
Note that we currently only implicitly sync for the rendering pass,
not binning -- if you texture-from-pixmap in the binning vertex shader
(vertex coordinate generation), you'll miss out on synchronization.
Fixes flickering when multiple clients are running in parallel,
particularly GL apps and compositors.
v2: Fix a missing refcount on the CSD done fence for L2 cleaning.
Eric Anholt [Tue, 16 Apr 2019 22:58:54 +0000 (15:58 -0700)]
drm/v3d: Add support for compute shader dispatch.
The compute shader dispatch interface is pretty simple -- just pass in
the regs that userspace has passed us, with no CLs to run. However,
with no CL to run it means that we need to do manual cache flushing of
the L2 after the HW execution completes (for SSBO, atomic, and
image_load_store writes that are the output of compute shaders).
This doesn't yet expose the L2 cache's ability to have a region of the
address space not write back to memory (which could be used for
shared_var storage).
So far, the Mesa side has been tested on V3D v4.2 simpenrose (passing
the ES31 tests), and on the kernel side on 7278 (failing atomic
compswap tests in a way that doesn't reproduce on simpenrose).
v2: Fix excessive allocation for the clean_job (reported by Dan
Carpenter). Keep refs on jobs until clean_job is finished, to
avoid spurious MMU errors if the output BOs are freed by userspace
before L2 cleaning is finished.
Eric Anholt [Tue, 16 Apr 2019 22:58:53 +0000 (15:58 -0700)]
drm/v3d: Refactor job management.
The CL submission had two jobs embedded in an exec struct. When I
added TFU support, I had to replicate some of the exec stuff and some
of the job stuff. As I went to add CSD, it became clear that actually
what was in exec should just be in the two CL jobs, and it would let
us share a lot more code between the 4 queues.
v2: Fix missing error path in TFU ioctl's bo[] allocation.
drm/sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS for GEM operations
Our driver makes a typical use of CMA, with GEM object allocated as
GEM CMA objects. Use DRM_GEM_CMA_VMAP_DRIVER_OPS to describe the ops
instead of duplicating them.
Because DRM_GEM_CMA_VMAP_DRIVER_OPS implements a gem_create_object op
which sets per-object funcs (drm_cma_gem_default_funcs), we can also
get rid of free_object_unlocked and gem_vm_ops, which are superseded
by the object funcs.
Steven Price [Wed, 17 Apr 2019 15:29:28 +0000 (16:29 +0100)]
drm/panfrost: depend on !GENERIC_ATOMIC64 when using COMPILE_TEST
Since panfrost has a 'select' on IOMMU_IO_PGTABLE_LPAE we must depend on
the same set of flags. Otherwise IOMMU_IO_PGTABLE_LPAE will be forced on
even though it cannot build (no support for cmpxchg64).
Steven Price [Wed, 17 Apr 2019 14:47:49 +0000 (15:47 +0100)]
drm/panfrost: Add missing include
Fix sparse warnings:
drivers/gpu/drm/panfrost/panfrost_devfreq.c:133:5:
warning: symbol 'panfrost_devfreq_init' was not declared. Should it be static?
drivers/gpu/drm/panfrost/panfrost_devfreq.c:168:6:
warning: symbol 'panfrost_devfreq_resume' was not declared. Should it be static?
drivers/gpu/drm/panfrost/panfrost_devfreq.c:182:6:
warning: symbol 'panfrost_devfreq_suspend' was not declared. Should it be static?
drivers/gpu/drm/panfrost/panfrost_devfreq.c:212:6:
warning: symbol 'panfrost_devfreq_record_transition' was not declared. Should it be static?
As explained by Robin Murphy:
> the IOMMU shutdown disables paging, so if the VOP is still
> scanning out then that will result in whatever IOVAs it was using now going
> straight out onto the bus as physical addresses.
We had a more radical approach before in commit 7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec")
but that resulted in new warnings and oopses on shutdown on rk3399
chromeos devices.
So second try is resurrecting Vicentes shutdown change which should
achieve the same result but in a less drastic way.
Fixes: 63238173b2fa ("Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"") Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Brian Norris <briannorris@chromium.org> Cc: Doug Anderson <dianders@chromium.org> Cc: stable@vger.kernel.org Suggested-by: JeffyChen <jeffy.chen@rock-chips.com> Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vicente Bergas <vicencb@gmail.com>
[adapted commit message to explain the history] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190402113753.10118-1-heiko@sntech.de
Add binding for the LG ACX467AKM-7 4.95" 1080×1920 LCD panel that is
found on the LG Nexus 5 (hammerhead) phone. This appears to be a JDI
panel based on some Internet searches, however a specific model number
could not be found. I disassembled an old Nexus 5 with a broken
screen and the LG part number is the only model number present on the
back of the panel, so I think that is probably the best ID to use.
drivers/gpu/drm/meson/meson_viu.c:93:6: warning: symbol 'meson_viu_set_g12a_osd1_matrix' was not declared. Should it be static?
drivers/gpu/drm/meson/meson_viu.c:121:6: warning: symbol 'meson_viu_set_osd_matrix' was not declared. Should it be static?
drivers/gpu/drm/meson/meson_viu.c:190:6: warning: symbol 'meson_viu_set_osd_lut' was not declared. Should it be static?
drivers/gpu/drm/sun4i/sun8i_tcon_top.c:271:36: warning: symbol 'sun8i_r40_tcon_top_quirks' was not declared. Should it be static?
drivers/gpu/drm/sun4i/sun8i_tcon_top.c:276:36: warning: symbol 'sun50i_h6_tcon_top_quirks' was not declared. Should it be static?
drivers/gpu/drm/sun4i/sun4i_tcon.c:239:6: warning: symbol 'sun4i_tcon_set_mux' was not declared. Should it be static?
Eric Anholt [Mon, 1 Apr 2019 22:26:33 +0000 (15:26 -0700)]
drm: Add helpers for setting up an array of dma_fence dependencies.
I needed to add implicit dependency support for v3d, and Rob Herring
has been working on it for panfrost, and I had recently looked at the
lima implementation so I think this will be a good intersection of
what we all want and simplify our scheduler implementations.
v2: Rebase on xa_limit_32b API change, and tiny checkpatch cleanups on
the way in (unsigned int vs unsigned, extra return before
EXPORT_SYMBOL_GPL)
Joel Stanley [Fri, 5 Apr 2019 08:11:17 +0000 (18:41 +1030)]
drm: aspeed: Clean up Kconfig options
The GFX IP is inside of the ASPEED BMC SoC so there is little use
enabling it on a kernel that does not support ASPEED.
When building with COMPILE_TEST the architecture many not have CMA
support, so to avoid breaking the build we only select these options if
the architecture supports the contiguous allocator.
I suspect the DRM_PANEL came from a cut/paste error.
Fixes: 4f2a8f5898ec ("drm: Add ASPEED GFX driver") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190405081117.27339-1-joel@jms.id.au
Christian König [Mon, 15 Apr 2019 12:46:34 +0000 (14:46 +0200)]
dma-buf: explicitely note that dma-fence-chains use 64bit seqno
Instead of checking the upper values of the sequence number use an explicit
field in the dma_fence_ops structure to note if a sequence should be 32bit
or 64bit.
Rob Herring [Thu, 11 Apr 2019 21:53:13 +0000 (16:53 -0500)]
drm/panfrost: Add support for 2MB page entries
Add support for 2MB sized pages. This will improve our map and unmap
times and save a bit of memory by avoiding 3rd level page tables for
contiguous allocations.
As we use shmem for buffers and huge page allocations for shmem are off
by default, there isn't an improvement out of the box and userspace must
enable THP for shmem.
It's not clear if the h/w can support 1GB page sizes which standard
ARM long format descriptors support. In any case, it is unlikely we'll
see any contiguous 1GB allocations on current h/w.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190411215313.1937-1-robh@kernel.org
Rob Herring [Mon, 10 Sep 2018 19:27:58 +0000 (14:27 -0500)]
drm/panfrost: Add initial panfrost driver
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: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Marty E. Plummer <hanetzer@startmail.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190409205427.6943-4-robh@kernel.org
Rob Herring [Thu, 21 Feb 2019 20:23:25 +0000 (14:23 -0600)]
iommu: io-pgtable: Add ARM Mali midgard MMU page table format
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: Robin Murphy <robin.murphy@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: iommu@lists.linux-foundation.org Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190409205427.6943-2-robh@kernel.org
Peter Ujfalusi [Mon, 1 Apr 2019 12:41:43 +0000 (15:41 +0300)]
drm/bridge: ti-tfp410: Set the bus_format
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.
Peter Ujfalusi [Mon, 1 Apr 2019 12:33:42 +0000 (15:33 +0300)]
drm/bridge: ti-tfp410: Fall back to HPD polling if HPD irq is not available
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.
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).
Maxime Ripard [Mon, 1 Apr 2019 08:56:45 +0000 (10:56 +0200)]
drm/sun4i: Rely on dma interconnect for our RAM offset
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.
drm: switch drm_fb_xrgb8888_to_rgb888_dstclip to accept __iomem dst
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.
drm: switch drm_fb_xrgb8888_to_rgb565_dstclip to accept __iomem dst
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.
drm: switch drm_fb_memcpy_dstclip to accept __iomem dst
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.
Neil Armstrong [Mon, 25 Mar 2019 14:18:24 +0000 (15:18 +0100)]
drm/meson: Add G12A support for the DW-HDMI Glue
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.
Neil Armstrong [Mon, 25 Mar 2019 14:18:22 +0000 (15:18 +0100)]
drm/meson: Add G12A Video Clock setup
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.
Neil Armstrong [Mon, 25 Mar 2019 14:18:20 +0000 (15:18 +0100)]
drm/meson: Add G12A support for plane handling in CRTC driver
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.
Neil Armstrong [Mon, 25 Mar 2019 14:18:19 +0000 (15:18 +0100)]
drm/meson: Add G12A Support for the Overlay video plane
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.
Neil Armstrong [Mon, 25 Mar 2019 14:18:18 +0000 (15:18 +0100)]
drm/meson: Add G12A support for OSD1 Plane
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.
Neil Armstrong [Mon, 25 Mar 2019 14:18:14 +0000 (15:18 +0100)]
drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clock
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.
Neil Armstrong [Wed, 13 Mar 2019 14:10:28 +0000 (15:10 +0100)]
dt-bindings: display: amlogic, meson-vpu: Add G12A compatible and ports
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
Neil Armstrong [Mon, 1 Apr 2019 08:09:49 +0000 (10:09 +0200)]
dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU
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.
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.
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.
Sean Paul [Wed, 3 Apr 2019 20:56:45 +0000 (16:56 -0400)]
Documentation/gpu/meson: Remove link to meson_canvas.c
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: 2bf6b5b0e374 ("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: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190403205652.183496-1-sean@poorly.run
projects / mirror_ubuntu-kernels.git / log