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
Wen Yang [Wed, 3 Apr 2019 16:04:13 +0000 (00:04 +0800)]
drm/pl111: fix possible object reference leak
The call to of_find_matching_node_and_match returns a node pointer with
refcount incremented thus it must be explicitly decremented after the
last usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/pl111/pl111_versatile.c:333:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:340:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:346:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:354:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:395:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:402:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Cc: Eric Anholt <eric@anholt.net> (supporter:DRM DRIVER FOR ARM PL111 CLCD) Cc: David Airlie <airlied@linux.ie> (maintainer:DRM DRIVERS) Cc: Daniel Vetter <daniel@ffwll.ch> (maintainer:DRM DRIVERS) Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS) Cc: linux-kernel@vger.kernel.org (open list) Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1554307455-40361-6-git-send-email-wen.yang99@zte.com.cn
Joel Stanley [Wed, 3 Apr 2019 00:19:08 +0000 (10:49 +1030)]
drm: Add ASPEED GFX driver
This driver is for the ASPEED BMC SoC's GFX display hardware. This
driver runs on the ARM based BMC systems, unlike the ast driver which
runs on a host CPU and is is for a PCI graphics device.
Eric Anholt [Mon, 1 Apr 2019 18:35:59 +0000 (11:35 -0700)]
drm/vc4: Disable V3D interactions if the v3d component didn't probe.
One might want to use the VC4 display stack without using Mesa.
Similar to the debugfs fixes for not having all of the possible
display bits enabled, make sure you can't oops in vc4 if v3d isn't
enabled.
v2: Fix matching against other v3d variants (review by Paul), don't
forget to set irq_enabled so that the vblank uapi works
v3: Use -ENODEV instead of -EINVAL on Paul's suggestion.
Eric Anholt [Mon, 1 Apr 2019 18:35:58 +0000 (11:35 -0700)]
drm/vc4: Use common helpers for debugfs setup by the driver components.
The global list of all debugfs entries for the driver was painful: the
list couldn't see into the components' structs, so each component had
its own debugs show function to find the component, then find the
regset and dump it. The components also had to be careful to check
that they were actually registered in vc4 before dereferencing
themselves, in case they weren't probed on a particular platform.
They routinely failed at that.
Instead, we can have the components add their debugfs callbacks to a
little list in vc4 to be registered at drm_dev_register() time, which
gets vc4_debugfs.c out of the business of knowing the whole list of
components.
Thanks to this change, dsi0 (if it existed) would register its node.
v2: Rebase on hvs_underrun addition.
v3: whitespace fixup
Yannick Fertré [Thu, 21 Mar 2019 08:07:26 +0000 (09:07 +0100)]
drm/panel: otm8009a: Set clock to 29.70 Mhz
The panel does not support clock frequency over 30.74 MHz. The clock
rate has been reduced to 29.70 MHz & new timings have been computed to
get a framerate of 50 fps.
Yannick Fertré [Thu, 21 Mar 2019 08:04:05 +0000 (09:04 +0100)]
drm/panel: otm8009a: Add delay at the end of initialization
At the end of initialization, a delay is required by the panel. Without
this delay, the panel could received a frame early & generate a crash of
panel (black screen).
Support Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel. It is a MIPI
DSI video mode panel.
The panel seems to use a Sitronix ST7703 look alike (most of the
commands look similar to the ST7703's data sheet but use a different
number of parameters). The initial version of the DSI init sequence
(including sleeps) were provided by the vendor. Sleeps were reduced
considerably though to speed up initialization.
drm/fb-helper: generic: Call drm_client_add() after setup is done
Hotplug can happen while drm_fbdev_generic_setup() is running so move
drm_client_add() call after setup is done to avoid
drm_fbdev_client_hotplug() running in two threads at the same time.
Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation") Cc: stable@vger.kernel.org Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190401141358.25309-1-noralf@tronnes.org
Noralf Trønnes [Tue, 26 Mar 2019 17:55:31 +0000 (18:55 +0100)]
drm/fb-helper: Remove unused gamma_size variable
The gamma_size variable has not been used since
commit 4abe35204af8 ("drm/kms/fb: use slow work mechanism for normal hotplug also.")
While in the area move a comment back to its code block.
They got separated by
commit d50ba256b5f1 ("drm/kms: start adding command line interface using fb.").
Qiang Yu [Sat, 9 Mar 2019 12:20:12 +0000 (20:20 +0800)]
drm/lima: driver for ARM Mali4xx GPUs
- Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
OpenGL vertex shader processing and PP is for fragment shader
processing. Each processor has its own MMU so prcessors work in
virtual address space.
- There's only one GP but multiple PP (max 4 for mali 400 and 8
for mali 450) in the same mali 4xx GPU. All PPs are grouped
togather to handle a single fragment shader task divided by
FB output tiled pixels. Mali 400 user space driver is
responsible for assign target tiled pixels to each PP, but mali
450 has a HW module called DLBU to dynamically balance each
PP's load.
- User space driver allocate buffer object and map into GPU
virtual address space, upload command stream and draw data with
CPU mmap of the buffer object, then submit task to GP/PP with
a register frame indicating where is the command stream and misc
settings.
- There's no command stream validation/relocation due to each user
process has its own GPU virtual address space. GP/PP's MMU switch
virtual address space before running two tasks from different
user process. Error or evil user space code just get MMU fault
or GP/PP error IRQ, then the HW/SW will be recovered.
- Use GEM+shmem for MM. Currently just alloc and pin memory when
gem object creation. GPU vm map of the buffer is also done in
the alloc stage in kernel space. We may delay the memory
allocation and real GPU vm map to command submission stage in the
furture as improvement.
- Use drm_sched for GPU task schedule. Each OpenGL context should
have a lima context object in the kernel to distinguish tasks
from different user. drm_sched gets task from each lima context
in a fair way.
mesa driver can be found here before upstreamed:
https://gitlab.freedesktop.org/lima/mesa
v8:
- add comments for in_sync
- fix ctx free miss mutex unlock
v7:
- remove lima_fence_ops with default value
- move fence slab create to device probe
- check pad ioctl args to be zero
- add comments for user/kernel interface
v6:
- fix comments by checkpatch.pl
v5:
- export gp/pp version to userspace
- rebase on drm-misc-next
v4:
- use get param interface to get info
- separate context create/free ioctl
- remove unused max sched task param
- update copyright time
- use xarray instead of idr
- stop using drmP.h
v3:
- fix comments from kbuild robot
- restrict supported arch to tested ones
v2:
- fix syscall argument check
- fix job finish fence leak since kernel 5.0
- use drm syncobj to replace native fence
- move buffer object GPU va map into kernel
- reserve syscall argument space for future info
- remove kernel gem modifier
- switch TTM back to GEM+shmem MM
- use time based io poll
- use whole register name
- adopt gem reservation obj integration
- use drm_timeout_abs_to_jiffies
Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh@kernel.org> Cc: Christian König <ckoenig.leichtzumerken@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de> Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Simon Shields <simon@lineageos.org> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Rob Herring <robh@kerrnel.org> Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/291200/
Eric Anholt [Wed, 20 Feb 2019 21:03:42 +0000 (13:03 -0800)]
drm/vc4: Add helpers for pm get/put.
This makes sure the vc4_reset doesn't hit an obscure race with the
GET_PARAM ioctl, fixes a decrement outside of the lock, and prevents
future code from making mistakes with the weird return value of
pm_runtime_get_sync().
Dan Carpenter [Fri, 22 Mar 2019 06:41:25 +0000 (09:41 +0300)]
drm: shmem: Off by one in drm_gem_shmem_fault()
The shmem->pages[] array has "num_pages" elements so the > should be >=
to prevent reading beyond the end of the array. The shmem->pages[]
array is allocated in drm_gem_shmem_prime_import_sg_table().
Eric Anholt [Wed, 20 Feb 2019 21:03:37 +0000 (13:03 -0800)]
drm: Add a helper function for printing a debugfs_regset32.
The debugfs_regset32 is nice to use for reducing boilerplate in
dumping a bunch of regs in debugfs, but we also want to be able to
print to dmesg them at runtime for driver debugging. drm_printer lets
us format debugfs and the printk the same way.
v2: Add some kerneldoc for the function (requested by danvet)
Dan Carpenter [Thu, 21 Mar 2019 06:27:31 +0000 (09:27 +0300)]
drm/v3d: fix a NULL vs error pointer mixup
The drm_gem_shmem_create() returns error pointers and v3d_bo_create() is
also supposed to return error pointers.
Fixes: 40609d4820b2 ("drm/v3d: Use the new shmem helpers to reduce driver boilerplate.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190321062731.GC21489@kadam
Eric Anholt [Wed, 6 Feb 2019 23:25:50 +0000 (15:25 -0800)]
drm/vc4: Make sure to emit a tile coordinates between two MSAA loads.
The HW only executes a load once the tile coordinates packet happens,
and only tracks one at a time, so by emitting our two MSAA loads back
to back we would end up with an undefined color or Z buffer.
drm/syncobj: add timeline signal ioctl for syncobj v5
v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal operation,
so add check condition for that.
v4: remove v3 change and add checking to prevent out-of-order
v5: unify binary and timeline
Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: Tobias Hector <Tobias.Hector@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295792/?series=58813&rev=1
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
v6: add unorder point check
Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: Tobias Hector <Tobias.Hector@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295784/?series=58813&rev=1
drm/syncobj: add support for timeline point wait v8
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for xxx_WAIT_AVAILABLE
v6: rebase and rework on new container
v7: drop _WAIT_COMPLETED, it is the default anyway
v8: correctly handle garbage collected fences
Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: Tobias Hector <Tobias.Hector@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/295782/?series=58813&rev=1
Christian König [Mon, 1 Apr 2019 09:50:55 +0000 (17:50 +0800)]
dma-buf: add new dma_fence_chain container v7
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a chain fence.
v3: use head and iterator for dma_fence_chain_for_each
v4: fix reference count in dma_fence_chain_enable_signaling
v5: fix iteration when walking each chain node
v6: add __rcu for member 'prev' of struct chain node
v7: fix rcu warnings from kernel robot
Mans Rullgard [Thu, 28 Mar 2019 13:02:49 +0000 (13:02 +0000)]
drm/sun4i: hdmi: add support for ddc-i2c-bus property
Sometimes it is desirabled to use a separate i2c controller for ddc
access. This adds support for the ddc-i2c-bus property of the
hdmi-connector node, using the specified controller if provided.
Zheng Yang [Sat, 30 Mar 2019 09:56:36 +0000 (10:56 +0100)]
drm: rockchip: introduce rk3066 hdmi
The RK3066 HDMI TX serves as interface between a LCD Controller and
a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and
one HDMI transmitter PHY. The interface has three (3) 8-bit data channels
which can be configured for a number of bus widths (8/10/12/16/20/24-bit)
and different video formats (RGB, YCbCr).
Features:
HDMI version 1.4a, HDCP revision 1.4 and
DVI version 1.0 compliant transmitter.
Supports DTV resolutions from 480i to 1080i/p HD.
Master I2C interface for a DDC connection.
HDMI TX supports multiple power save modes.
The HDMI TX input can switch between LCDC0 and LCDC1.
(Sound support is not included in this patch)
Urja Rannikko [Mon, 18 Mar 2019 15:44:12 +0000 (15:44 +0000)]
drm/rockchip: vop: Support dithering to RGB666
Splits out the dither register bits and introduces
the same config enumerations as in the rockchip kernel tree.
Tested to fix the banding on my ASUS C201.
Gerd Hoffmann [Mon, 18 Mar 2019 11:33:32 +0000 (12:33 +0100)]
drm/virtio: rework resource creation workflow.
This patch moves the virtio_gpu_cmd_create_resource() call (which
notifies the host about the new resource created) into the
virtio_gpu_object_create() function. That way we can call
virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
already knows about the object when ttm initializes the object and calls
our driver callbacks.
Specifically the object is already created when the
virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(),
so the extra virtio_gpu_object_attach() calls done after
virtio_gpu_object_create() are not needed any more.
The fence support for the create ioctl becomes a bit more tricky though.
The code moved into virtio_gpu_object_create() too. We first submit the
(fenced) virtio_gpu_cmd_create_resource() command, then initialize the
ttm object, and finally attach just created object to the fence for the
command in case it didn't finish yet.
Gerd Hoffmann [Mon, 18 Mar 2019 11:33:30 +0000 (12:33 +0100)]
drm/virtio: params struct for virtio_gpu_cmd_create_resource()
Add format, width and height fields to the virtio_gpu_object_params
struct. With that in place we can use the parameter struct for
virtio_gpu_cmd_create_resource() calls too.
Gerd Hoffmann [Mon, 18 Mar 2019 11:33:29 +0000 (12:33 +0100)]
drm/virtio: use struct to pass params to virtio_gpu_object_create()
Create virtio_gpu_object_params, use that to pass object parameters to
virtio_gpu_object_create. This is just the first step, followup patches
will add more parameters to the struct. The plan is to use the struct
for all object parameters.
Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is
unused and always false.
Also drop "pinned" parameter. virtio-gpu doesn't shuffle around
objects, so effecively they all are pinned anyway. Hardcode
TTM_PL_FLAG_NO_EVICT so ttm knows. Doesn't change much for the moment
as virtio-gpu supports TTM_PL_FLAG_TT only so there is no opportunity to
move around objects. That'll probably change in the future though.
Drop the dummy ttm backend implementation, add a real one for
TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call
virtio_gpu_object_{attach,detach}, to update the object state
on the host side, instead of invoking those calls from the
move_notify() callback.
With that in place the move and move_notify callbacks are not
needed any more, so drop them.
YueHaibing [Mon, 25 Mar 2019 09:26:31 +0000 (09:26 +0000)]
drm/virtio: remove set but not used variable 'vgdev'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_init_mem_type':
drivers/gpu/drm/virtio/virtgpu_ttm.c:117:28: warning:
variable 'vgdev' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_bo_swap_notify':
drivers/gpu/drm/virtio/virtgpu_ttm.c:300:28: warning:
variable 'vgdev' set but not used [-Wunused-but-set-variable]
It is never used since introduction in dc5698e80cf7 ("Add virtio gpu driver.")
Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.
The concensus seems to be that this quirk is a bit misguided
anyway so let's nuke the leftovers.
For posterity here are some links to known cases:
* Proview AY765C
https://bugs.freedesktop.org/show_bug.cgi?id=15160
* Unknown Acer
https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
reference from xf86EdidModes.c)
* Peacock Ergovision 19 (only in xf86EdidModes.c)
https://bugzilla.redhat.com/show_bug.cgi?id=492359
* Philips 107p5 CRT
"Reported on xorg@ with pastebin", didn't find the mail(s)
Ville Syrjälä [Tue, 26 Mar 2019 17:34:01 +0000 (19:34 +0200)]
drm/uapi: Remove unused DRM_DISPLAY_INFO_LEN
Remove the unused DRM_DISPLAY_INFO_LEN from the uapi headers.
I presume the original plan was to expose the display name
via getconnector, but looks like that never happened. So we have
the define for the length of the string but no string anywhere.
A quick scan didn't seem to reveal userspace referencing this
so hopefully we can just nuke it.
Daniel Vetter [Tue, 26 Mar 2019 13:20:01 +0000 (14:20 +0100)]
drm/nouveau: Use drm_fb_helper_fill_info
This changes the fb name from "nouveaufb" to "nouveaudrmfb".
Aside: I wonder whether the in_interrupt() check is good enough for
the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed,
which isn't actually working if you pick a .config without PREEMPT.
For the generic fbdev defio support we've gone with offloading
everything to a worker. For the non-accel callbacks (set_par, blank
and friends) checking for oops_in_progress is good enough to catch all
the evil calling contexts.