- 06 Sep, 2018 7 commits
-
-
Chunming Zhou authored
moved to front of file. stub fence will be used by timeline syncobj as well. Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Chunming Zhou authored
That is certainly totally nonsense. dma_fence_enable_sw_signaling() is the function who is calling this callback. Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
Since this is handling user provided bpp and depth, we need to sanity check and propagate the EINVAL back rather than assume what the insane client intended and fill the logs with DRM_ERROR. v2: Check both bpp and depth match the builtin pixel format, and introduce a canonical DRM_FORMAT_INVALID to reserve 0 against any future fourcc. v3: Mark up DRM_FORMAT_C8 as being {bpp:8, depth:8} Testcase: igt/kms_addfb_basic/legacy-format Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180905153116.28924-1-chris@chris-wilson.co.uk
-
Gerd Hoffmann authored
Userspace on big endian machhines typically expects the ADDFB ioctl returns a big endian framebuffer. drm_mode_addfb() will call drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_* values though, which is wrong. This patch fixes that. Drivers (both kernel and xorg) have quirks in place to deal with the broken drm_mode_addfb() behavior. Because of this we can't just change drm_mode_addfb() behavior for everybody without breaking things. Add the quirk_addfb_prefer_host_byte_order field to mode_config, so drivers can opt-in. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
-
Gerd Hoffmann authored
framebuffer_check() expects that drm_get_format_info() will not fail if the __drm_format_info() call was successful. That'll work only in case both are called with the same pixel_format value, so masking out the DRM_FORMAT_BIG_ENDIAN flag isn't a good idea. Signed-off-by:
-
Gerd Hoffmann authored
Add fourcc variants in host byte order. With these at hand we don't need #ifdefs in drivers which support framebuffers in cpu endianess. Signed-off-by:
-
Gerd Hoffmann authored
Signed-off-by:
-
- 05 Sep, 2018 17 commits
-
-
Heiko Stuebner authored
The newly added internal rgb encoder for Rockchip vops is missing stubs for the case that the rgb output part is not enabled in the kernel config. So add these. Fixes: 1f0f0151 (drm/rockchip: Add support for Rockchip Soc RGB output interface) Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> [seanpaul fixed up checkpatch nits] Signed-off-by:
-
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:
-
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:
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: -
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 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 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 13 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:
-
