- 05 Sep, 2018 16 commits
-
-
Haneen Mohammed authored
crtc_state is accessed by both vblank_handle() and the ordered work_struct handle vkms_crc_work_handle() to retrieve and or update the frame number for computed CRC. Since work_struct can fail, add frame_end to account for missing frame numbers. Use (frame_[start/end]) for synchronization between hrtimer callback and ordered work_struct handle. This patch passes the following subtests from igt kms_pipe_crc_basic test: bad-source, read-crc-pipe-A, read-crc-pipe-A-frame-sequence, nonblocking-crc-pipe-A, nonblocking-crc-pipe-A-frame-sequence Signed-off-by:
Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180903211743.GA2773@haneenDRM
-
Heiko Stuebner authored
The rk3188 has 2 vops not using iommus which only output directly to a rgb interface per vop. So all other output modes like hdmi are provided by external brige chips. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Sandy Huang <hjc@rock-chips.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180830110937.1739-1-heiko@sntech.de
-
Sandy Huang authored
Add this feature bit indicate px30 vop can directly output parallel or serial rgb data. Signed-off-by:
-
Sandy Huang authored
Some Rockchip CRTCs, like rv1108 and px30, can directly output parallel and serial RGB data to panel or conversion chip. So add a feature-bit for vops to mark the ability for these direct outputs and add an internal encoder in that case, that can attach to bridge chipsor panels. Changes in v7: 1. forget to delete rockchip_rgb_driver and delete it. Changes in v6: 1. Update according to Heiko Stuebner' implemention, rgb output is part of vop's feature, should not register as a independent driver. Changes in v5: 1. add SPDX-License-Identifier tag Changes in v4: 1. add support px30; Changes in v3: 1. update for rgb-mode move to panel node. Changes in v2: 1. add error log when probe failed; 2. update name_to_output_mode() according to sean's suggest; 3. Fix uninitialized use of ret. Signed-off-by:Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Heiko Stuebner authored
To be able to have both internal subdrivers and external bridge drivers as output endpoints of vops, add a function to be able to distinguish these. changes in v8: - improved function documentation - better error handling - put calls for node and pdev references changes in v6: - added function to check subdriver vs. bridge Signed-off-by:
-
Jernej Skrabec authored
Some boards have HDMI VCC pin connected to voltage regulator which may not be turned on by default. Add support for such boards by adding voltage regulator handling code to HDMI driver. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> [Icenowy: change supply name to "hvcc"] Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904044053.15425-11-icenowy@aosc.io
-
Icenowy Zheng authored
Allwiner SoCs with DesignWare HDMI controller all come with a "HVCC" pin, which is the VCC of HDMI part. Add a supply property to specify HVCC's regulator in the device tree. Signed-off-by:
-
Jagan Teki authored
The HDMI controller on Allwinner A64 is similar on the one on H3/H5/A83T (although the PHY is different with A83T). Add A64 compatible and append A83T compatible as fallback. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
-
Jagan Teki authored
Display Engine(DE2) in Allwinner A64 has two mixers and tcons. The routing for mixer0 is through tcon0 and connected to LVDS/RGB/MIPI-DSI controller. The routing for mixer1 is through tcon1 and connected to HDMI. Signed-off-by:
-
Jagan Teki authored
Mixers in Allwinner have similar capabilities as others SoCs with DE2. Add support for them. Signed-off-by:
-
Jagan Teki authored
Allwinner A64 has a DE2 display pipeline. The TCONs are similar to the ones in A83T, but the mixers are new (similar to the later R40 SoC). This patch adds dt-binding documentation for A64 DE2 display pipeline. Signed-off-by:
-
Gustavo A. R. Silva authored
There is a potential execution path in which pointer memfd is NULL when passed as argument to fput(), hence there is a NULL pointer dereference in fput(). Fix this by null checking *memfd* before calling fput(). Addresses-Coverity-ID: 1473174 ("Explicit null dereferenced") Fixes: fbb0de79 ("Add udmabuf misc device") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180904190749.GA9308@embeddedor.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gerd Hoffmann authored
Use the dma mapping api and properly add iommu mappings for objects, unless virtio is in iommu quirk mode. Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180829122026.27012-3-kraxel@redhat.com
-
Gerd Hoffmann authored
The new function balances virtio_gpu_object_attach(). Also make virtio_gpu_cmd_resource_inval_backing() static and switch call sites to the new virtio_gpu_object_attach() function. Signed-off-by:
-
Gerd Hoffmann authored
Track whenever an virtual output (crtc) is enabled or disabled. On atomic updates check for both framebuffer being present and crtc being enabled to figure whenever the output is active or not. Signed-off-by:
-
Peter Wu authored
"crtc->helper_private" is not initialized by the QXL driver and thus the "crtc_funcs->disable" call would crash (resulting in suspend failure). Fix this by converting the suspend/resume functions to use the drm_mode_config_helper_* helpers. Tested system sleep with QEMU 3.0 using "echo mem > /sys/power/state". During suspend the following message is visible from QEMU: spice/server/display-channel.c:2425:display_channel_validate_surface: canvas address is 0x7fd05da68308 for 0 (and is NULL) spice/server/display-channel.c:2426:display_channel_validate_surface: failed on 0 This seems to be triggered by QXL_IO_NOTIFY_CMD after QXL_IO_DESTROY_PRIMARY_ASYNC, but aside from the warning things still seem to work (tested with both the GTK and -spice options). Signed-off-by:Peter Wu <peter@lekensteyn.nl> Link: http://patchwork.freedesktop.org/patch/msgid/20180904202747.14968-1-peter@lekensteyn.nlSigned-off-by:
-
- 04 Sep, 2018 3 commits
-
-
Chris Wilson authored
Using a spinlock to serialize the destroy function, within the destroy function itself does not prevent the buggy driver from shooting themselves in the foot - either way they still have a use-after-free issue. Reported-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Chris Wilson authored
The ioctl arguments are under control of the user and as such we should resist any temptation to flood the kernel logs with their errors. Relegate the DRM_ERROR to a DRM_DEBUG so the user has to opt into hearing of their own mistakes. (One day we will have a small ringbuffer attached to the task, so that the concerned process can inspect its own debug info for EINVAL without them being hitting syslog at all.) Signed-off-by:
-
Souptick Joarder authored
We have introduce new return type vm_fault_t for fault handler. Update the document for the same. Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by:
-
- 03 Sep, 2018 14 commits
-
-
Michał Mirosław authored
Kick out firmware fb when loading Tegra driver. Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Michał Mirosław authored
Use remove_conflicting_framebuffers(NULL) instead of duplicating it. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
-
Michał Mirosław authored
Use remove_conflicting_framebuffers(NULL) instead of open-coding it. Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
-
Michał Mirosław authored
Signed-off-by:
-
Michał Mirosław authored
Remove duplicated call, while at it. Signed-off-by:
-
Michał Mirosław authored
Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
-
Michał Mirosław authored
Signed-off-by:
-
Michał Mirosław authored
Signed-off-by:
-
Michał Mirosław authored
Signed-off-by:
-
Michał Mirosław authored
Almost all PCI drivers using remove_conflicting_framebuffers() wrap it with the same code. v2: add kerneldoc for DRM helper v3: propagate remove_conflicting_framebuffers() return value + move kerneldoc to where function is implemented Signed-off-by:
-
Michał Mirosław authored
Document remove_conflicting_framebuffers() behaviour. Signed-off-by:
-
Michał Mirosław authored
Interpret (otherwise-invalid) NULL apertures argument to mean all-memory range. This will allow to remove several duplicates of this code from drivers in following patches. Signed-off-by:
-
Michał Mirosław authored
Signed-off-by:
-
Gerd Hoffmann authored
A driver to let userspace turn memfd regions into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some day to wayland server for seamless guest window display. qemu test branch: https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf Cc: David Airlie <airlied@linux.ie> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 31 Aug, 2018 6 commits
-
-
Sean Paul authored
Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning found by kbuild test robot: htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or member 'pixel_blend_mode' not described in 'drm_plane_state' Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lowry Li <lowry.li@arm.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Hans Verkuil authored
Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/de9586bb-151e-bae9-b8e3-14db107a60df@xs4all.nl
-
Hans Verkuil authored
Add DisplayPort CEC-Tunneling-over-AUX support to nouveau. Signed-off-by:
Lyude Paul <lyude@redhat.com> Acked-by:
-
Hans Verkuil authored
When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the result is wrong due to a missing idx increment. This was never noticed since DP_REMOTE_DPCD_READ is currently not used, but if you enable it, then it is all wrong. Signed-off-by:
-
Hans Verkuil authored
A big problem with DP CEC-Tunneling-over-AUX is that it is tricky to find adapters with a chipset that supports this AND where the manufacturer actually connected the HDMI CEC line to the chipset. Add a mention of the MegaChips 2900 chipset which seems to support this feature well. Signed-off-by:
-
Hans Verkuil authored
If aux->transfer == NULL, then just return without doing anything. In that case the function is likely called for a non-(e)DP connector. This never happened for the i915 driver, but the nouveau and amdgpu drivers need this check. The alternative would be to add this check in those drivers before every drm_dp_cec call, but it makes sense to check it in the drm_dp_cec functions to prevent a kernel oops. Signed-off-by:
-
- 30 Aug, 2018 1 commit
-
-
Dan Carpenter authored
This doesn't affect runtime because in the current code "idx" is always valid. First, we read from "vgdev->capsets[idx].max_size" before checking whether "idx" is within bounds. And secondly the bounds check is off by one so we could end up reading one element beyond the end of the vgdev->capsets[] array. Fixes: 62fb7a5e ("virtio-gpu: add 3d/virgl support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180704094250.m7sgvvzg3dhcvv3h@kili.mountainSigned-off-by:
-
