aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2018-04-17drm/vc4: Move CRTC state to headerStefan Schake2-33/+33
We need to access the channel for configuring our CTM hardware. Signed-off-by: Stefan Schake <stschake@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1523479755-20812-4-git-send-email-stschake@gmail.com
2018-04-17drm/vc4: Expose gamma as atomic propertyStefan Schake1-11/+26
We are an atomic driver so the gamma LUT should also be exposed as a CRTC property through the DRM atomic color management. This will also take care of the legacy path for us. Signed-off-by: Stefan Schake <stschake@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1523479755-20812-3-git-send-email-stschake@gmail.com
2018-04-17drm/vc4: Add some missing HVS register definitions.Eric Anholt1-0/+96
At least the RGBA expand field we should have been setting, because we aren't expanding correctly for 565 -> 8888. Other registers are ones that may be interesting for various projects that have been discussed. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Stefan Schake <stschake@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523479755-20812-2-git-send-email-stschake@gmail.com
2018-04-17drm/rockchip: fix VOP vblank raceJohn Keeping1-1/+1
We have seen a case of a bad reference count for vblanks with the Rockchip VOP: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 383 at drivers/gpu/drm/drm_irq.c:1198 drm_vblank_put+0x40/0xcc Modules linked in: brcmfmac brcmutil CPU: 1 PID: 383 Comm: kworker/u8:2 Not tainted 4.9.75-rt60 #1 Hardware name: Rockchip (Device Tree) Workqueue: events_unbound flip_worker Backtrace: [<c010b7b0>] (dump_backtrace) from [<c010ba4c>] (show_stack+0x18/0x1c) r7:c0b1b13c r6:600b0013 r5:00000000 r4:c0b1b13c [<c010ba34>] (show_stack) from [<c032d248>] (dump_stack+0x78/0x94) [<c032d1d0>] (dump_stack) from [<c011e6e8>] (__warn+0xe4/0x104) r7:00000009 r6:c03cf26c r5:00000000 r4:00000000 [<c011e604>] (__warn) from [<c011e7c0>] (warn_slowpath_null+0x28/0x30) r9:eeb443a0 r8:eeb443c8 r7:ee8a5ec0 r6:ee8a5ec0 r5:edb47f00 r4:ee096200 [<c011e798>] (warn_slowpath_null) from [<c03cf26c>] (drm_vblank_put+0x40/0xcc) [<c03cf22c>] (drm_vblank_put) from [<c03cf310>] (drm_crtc_vblank_put+0x18/0x1c) r5:edb47f00 r4:ee3c8a80 [<c03cf2f8>] (drm_crtc_vblank_put) from [<c03ef9b4>] (vop_fb_unref_worker+0x18/0x24) [<c03ef99c>] (vop_fb_unref_worker) from [<c03df194>] (flip_worker+0x98/0xb4) r5:edb47f00 r4:eeb443a8 [<c03df0fc>] (flip_worker) from [<c0134808>] (process_one_work+0x1a8/0x2fc) r9:00000000 r8:ee807d00 r7:00000000 r6:ee809c00 r5:eeb443a8 r4:edfe5f80 [<c0134660>] (process_one_work) from [<c01358ec>] (worker_thread+0x2ac/0x458) r10:00000088 r9:edfe5f98 r8:ee809c2c r7:c0b04100 r6:ee809c00 r5:ee809c00 r4:edfe5f80 [<c0135640>] (worker_thread) from [<c013a0bc>] (kthread+0xfc/0x10c) r10:00000000 r9:00000000 r8:c0135640 r7:edfe5f80 r6:00000000 r5:edf0e240 r4:ee8a4000 r3:ed194e00 [<c0139fc0>] (kthread) from [<c0107cb8>] (ret_from_fork+0x14/0x3c) r8:00000000 r7:00000000 r6:00000000 r5:c0139fc0 r4:edf0e240 ---[ end trace 0000000000000002 ]--- It seems that this is caused by unfortunate timing between vop_crtc_atomic_flush() and vop_handle_vblank() given the following ordering: atomic_flush handle_vblank ------------ ------------- drm_flip_work_queue set_bit if (test_and_clear_bit(...)) drm_flip_work_commit drm_vblank_get This results in vop_fb_unref_worker (called as flip work) decrementing the vblank refcount before it has been incremented. Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Sandy huang <hjc@rock-chips.com> Signed-off-by: Sandy Huang <hjc@rock-chips.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328160351.23763-1-john@metanate.com
2018-04-16drm/sun4i: Add support for plane alphaMaxime Ripard3-3/+18
Our backend supports a per-plane alpha property. Support it through our new helper. Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/13e89f0d2f2b55752a22eb8c4f37f325246a3a9c.1523432341.git-series.maxime.ripard@bootlin.com
2018-04-16drm/rcar-du: Convert to the new generic alpha propertyMaxime Ripard6-59/+9
Now that we have support for per-plane alpha in the core, let's use it. Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/a343697b87109cd8d9675ea8bce2e561051a696f.1523432341.git-series.maxime.ripard@bootlin.com
2018-04-16drm/atmel-hclcdc: Convert to the new generic alpha propertyMaxime Ripard2-88/+14
Now that we have support for per-plane alpha in the core, let's use it. Acked-by: Boris Brezillon <boris.brezillon@bootlin.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e5e97e2aae129600233e0983b748e4ba51ced239.1523432341.git-series.maxime.ripard@bootlin.com
2018-04-16drm/blend: Add a generic alpha propertyMaxime Ripard3-0/+47
Some drivers duplicate the logic to create a property to store a per-plane alpha. This is especially useful if we ever want to support extra protocols for Wayland like: https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html Let's create a helper in order to move that to the core. Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e1ce0db78fcfc407e94913c64819e65109d034d.1523432341.git-series.maxime.ripard@bootlin.com
2018-04-11drm/sun4i: Tie the DSI controller in the TCONMaxime Ripard2-0/+119
The DSI controller needs a particular interface (CPU aka 8080) with some modifications from the TCON in order to run. Make sure the TCON is able to provide it when we are using the DSI output. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/129f5928113d2ca865bf5269047c2e4ba6fed5e6.1522835818.git-series.maxime.ripard@bootlin.com
2018-04-11drm/sun4i: Add Allwinner A31 MIPI-DSI controller supportMaxime Ripard5-0/+1476
Most of the Allwinner SoCs since the A31 share the same MIPI-DSI controller. While that controller is mostly undocumented, the code is out there and has been cleaned up in order to be integrated into DRM. However, there's still some dark areas that are a bit unclear about how the block exactly operates. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/ad9e6224fced87c0889ddd2765d1942610061f72.1522835818.git-series.maxime.ripard@bootlin.com
2018-04-11drm/sun4i: tcon: Add TRI finish interrupt for vblankMaxime Ripard2-3/+10
The "CPU" (or Intel 8080) interface uses a different interrupt called TRI_FINISH (most likely TRI being for trigger) to notify the end of frames, and hence the VBLANK period. And that interrupt to the possible VBLANK interrupts source. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/de6d6ad8959da77ea3a974a31a4c0c8391178748.1522835818.git-series.maxime.ripard@bootlin.com
2018-04-11Merge tag 'mmio-clk-config' of ↵Maarten Lankhorst1-0/+24
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into drm-misc-next regmap: MMIO regmap clock configuration This patch provides a mechanism for specifying a different clock to be used with the regmap clock integration. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180226131207.GB6681@sirena.org.uk
2018-04-05drm/sti: Depend on OF rather than selecting itOliver O'Halloran1-2/+1
Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") reworked some code inside of this driver and made it select CONFIG_OF. This results in the entire OF layer being enabled when building an allmodconfig on ia64. OF on ia64 is completely unsupported so this isn't a great state of affairs. The 0day robot noticed a link-time failure on ia64 caused by using of_node_to_nid() in an otherwise unrelated driver. The generic fallback for of_node_to_nid() only exists when: defined(CONFIG_OF) && defined(CONFIG_NUMA) == false Since CONFIG_NUMA is usually selected for IA64 we get the link failure. Fix this by making the driver depend on OF rather than selecting it, odds are that was the original intent. Link: https://lists.01.org/pipermail/kbuild-all/2018-March/045172.html Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: linux-ia64@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403053401.30045-1-oohall@gmail.com
2018-04-03drm/xen-front: Add support for Xen PV display frontendOleksandr Andrushchenko19-0/+3185
Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space application and its helper library [2], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [3]. Driver limitations: 1. Only primary plane without additional properties is supported. 2. Only one video mode supported which resolution is configured via XenStore. 3. All CRTCs operate at fixed frequency of 60Hz. 1. Implement Xen bus state machine for the frontend driver according to the state diagram and recovery flow from display para-virtualized protocol: xen/interface/io/displif.h. 2. Read configuration values from Xen store according to xen/interface/io/displif.h protocol: - read connector(s) configuration - read buffer allocation mode (backend/frontend) 3. Handle Xen event channels: - create for all configured connectors and publish corresponding ring references and event channels in Xen store, so backend can connect - implement event channels interrupt handlers - create and destroy event channels with respect to Xen bus state 4. Implement shared buffer handling according to the para-virtualized display device protocol at xen/interface/io/displif.h: - handle page directories according to displif protocol: - allocate and share page directories - grant references to the required set of pages for the page directory - allocate xen balllooned pages via Xen balloon driver with alloc_xenballooned_pages/free_xenballooned_pages - grant references to the required set of pages for the shared buffer itself - implement pages map/unmap for the buffers allocated by the backend (gnttab_map_refs/gnttab_unmap_refs) 5. Implement kernel modesetiing/connector handling using DRM simple KMS helper pipeline: - implement KMS part of the driver with the help of DRM simple pipepline helper which is possible due to the fact that the para-virtualized driver only supports a single (primary) plane: - initialize connectors according to XenStore configuration - handle frame done events from the backend - create and destroy frame buffers and propagate those to the backend - propagate set/reset mode configuration to the backend on display enable/disable callbacks - send page flip request to the backend and implement logic for reporting backend IO errors on prepare fb callback - implement virtual connector handling: - support only pixel formats suitable for single plane modes - make sure the connector is always connected - support a single video mode as per para-virtualized driver configuration 6. Implement GEM handling depending on driver mode of operation: depending on the requirements for the para-virtualized environment, namely requirements dictated by the accompanying DRM/(v)GPU drivers running in both host and guest environments, number of operating modes of para-virtualized display driver are supported: - display buffers can be allocated by either frontend driver or backend - display buffers can be allocated to be contiguous in memory or not Note! Frontend driver itself has no dependency on contiguous memory for its operation. 6.1. Buffers allocated by the frontend driver. The below modes of operation are configured at compile-time via frontend driver's kernel configuration. 6.1.1. Front driver configured to use GEM CMA helpers This use-case is useful when used with accompanying DRM/vGPU driver in guest domain which was designed to only work with contiguous buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can only import contiguous PRIME buffers, thus requiring frontend driver to provide such. In order to implement this mode of operation para-virtualized frontend driver can be configured to use GEM CMA helpers. 6.1.2. Front driver doesn't use GEM CMA If accompanying drivers can cope with non-contiguous memory then, to lower pressure on CMA subsystem of the kernel, driver can allocate buffers from system memory. Note! If used with accompanying DRM/(v)GPU drivers this mode of operation may require IOMMU support on the platform, so accompanying DRM/vGPU hardware can still reach display buffer memory while importing PRIME buffers from the frontend driver. 6.2. Buffers allocated by the backend This mode of operation is run-time configured via guest domain configuration through XenStore entries. For systems which do not provide IOMMU support, but having specific requirements for display buffers it is possible to allocate such buffers at backend side and share those with the frontend. For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting physically contiguous memory, this allows implementing zero-copying use-cases. Note, while using this scenario the following should be considered: a) If guest domain dies then pages/grants received from the backend cannot be claimed back b) Misbehaving guest may send too many requests to the backend exhausting its grant references and memory (consider this from security POV). Note! Configuration options 1.1 (contiguous display buffers) and 2 (backend allocated buffers) are not supported at the same time. 7. Handle communication with the backend: - send requests and wait for the responses according to the displif protocol - serialize access to the communication channel - time-out used for backend communication is set to 3000 ms - manage display buffers shared with the backend [1] https://github.com/xen-troops/displ_be [2] https://github.com/xen-troops/libxenbe [3] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in;h=a699367779e2ae1212ff8f638eff0206ec1a1cc9;hb=refs/heads/master#l1257 Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180403112317.28751-2-andr2000@gmail.com
2018-03-30drm: Reshuffle getfb error returnsDaniel Stone1-16/+18
Make it a little more clear what's going on inside of getfb, and also make it easier to add alternate paths to get a handle in future. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180323134553.15993-3-daniels@collabora.com
2018-03-30Merge airlied/drm-next into drm-misc-nextSean Paul753-6450/+70396
Backmerging to pick up a fix from drm-misc-next-fixes. Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-03-29drm/i915: Make force_load_detect effective even w/ DMI quirks/hotplugVille Syrjälä1-1/+7
When doing forced load detection testing we should totally ignore any hotplug status for the connector. This is mostly relevant for machines where we already ignore the hotplug status based on the DMI quirks. On other machines we would currently skip the force load detection tests on account of the connector already being connected. v2: Drop the other force_load_detect check since it's useless now (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322174135.5982-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm/i915: Restore planes after load detectionVille Syrjälä1-0/+2
Actually turn the planes back on after were done with the load detection. Fixes: 20bdc112bbe4 ("drm/i915: Disable all planes for load detection, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-23-ville.syrjala@linux.intel.com
2018-03-29drm/zte: Stop consulting plane->crtcVille Syrjälä3-4/+6
We want to get rid of plane->crtc on atomic drivers. Stop looking at it. v2: Use old_state->crtc (Maarten) v3: s/fb/crtc/ in commit message to actually match the patch (Shawn) Cc: Shawn Guo <shawnguo@kernel.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180326121442.32009-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm/vmwgfx: Stop consulting plane->fbVille Syrjälä1-3/+3
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-13-ville.syrjala@linux.intel.com Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm/sti: Stop consulting plane->fbVille Syrjälä1-4/+5
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-12-ville.syrjala@linux.intel.com Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm/i915: Stop consulting plane->fbVille Syrjälä2-2/+2
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-10-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm: Use plane->state->fb over plane->fbVille Syrjälä3-8/+24
Stop looking at plane->fb on atomic drivers. Use plane->state->fb instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-9-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm: Make the fb refcount handover less magicVille Syrjälä1-2/+1
Instead of assigning the plane->fb pointer and clearing the fb pointer to hand over the reference, let's just do it by grabbing another referece for plane->fb and let fb keep its original one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-8-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm: Adjust whitespace for legibilityVille Syrjälä2-2/+8
Add a bit of whitespace here and there to make the code look a bit more structured. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-7-ville.syrjala@linux.intel.com Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm: Add local 'plane' variable for primary/cursor planesVille Syrjälä2-27/+37
Make the code a bit more readable by storing the plane pointer in a local variable rather than having to do crtc->{primary,cursor} all the time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-6-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm/atomic-helper: WARN if legacy plane fb pointers are bogus when ↵Ville Syrjälä1-1/+6
committing duplicated state drm_atomic_helper_commit_duplicated_state() should only be called resume/reset/load_detect paths where plane->old_fb should always be NULL and plane->fb should be equal to the new_plane_state->fb. Assert that is indeed the case. Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Cc: Dave Airlie <airlied@gmail.com> (v1) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-5-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm: Clear crtc->primary->crtc when disabling the crtc via setcrtc()Ville Syrjälä1-1/+1
Keep the primary->crtc in sync with the state->crtc (also with primary->fb and state->fb) when disabling the crtc (and thus also the primary) via setcrtc(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-4-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2018-03-29drm/atomic-helper: Drop plane->fb references only for ↵Ville Syrjälä1-39/+39
drm_atomic_helper_shutdown() drm_atomic_helper_shutdown() needs to release the reference held by plane->fb. Since commit 49d70aeaeca8 ("drm/atomic-helper: Fix leak in disable_all") we're doing that by calling drm_atomic_clean_old_fb() in drm_atomic_helper_disable_all(). This also leaves plane->fb == NULL afterwards. However, since drm_atomic_helper_disable_all() is also used by the i915 gpu reset code drm_atomic_helper_commit_duplicated_state() then has to undo the damage and put the correct plane->fb pointers back in (and also adjust the ref counts to match again as well). That approach doesn't work so well for load detection as nothing sets up the plane->old_fb pointers for us. This causes us to leak an extra reference for each plane->fb when drm_atomic_helper_commit_duplicated_state() calls drm_atomic_clean_old_fb() after load detection. To fix this let's call drm_atomic_clean_old_fb() only for drm_atomic_helper_shutdown() as that's the only time we need to actually drop the plane->fb references. In all the other cases (load detection, gpu reset) we want to leave plane->fb alone. v2: Don't inflict the clean_old_fbs bool to drivers (Daniel) v3: Squash in the revert and rewrite the commit msg (Daniel) Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Cc: Dave Airlie <airlied@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322152313.6561-3-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #pre-squash Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-03-29drm: Use srcu to protect drm_device.unpluggedNoralf Trønnes1-5/+49
Use srcu to protect drm_device.unplugged in a race free manner. Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark sections preventing access to device resources that are not available after the device is gone. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Tested-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1522222715-11814-1-git-send-email-andr2000@gmail.com
2018-03-29Merge branch 'drm-misc-next-fixes' of ↵Dave Airlie1-1/+7
git://anongit.freedesktop.org/drm/drm-misc into drm-next - Mask mode type garbage from userspace (Ville) Something went wrong on the misc tree side, but I'll pull the patch directly. * 'drm-misc-next-fixes' of git://anongit.freedesktop.org/drm/drm-misc: drm: Fix uabi regression by allowing garbage mode->type from userspace
2018-03-28drm: add parameter explanation for some gem dmabuf_opsSamuel Li1-0/+13
To reduce some warnings. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Samuel Li <Samuel.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1522092145-12645-1-git-send-email-Samuel.Li@amd.com
2018-03-28drm/tinydrm: Make fb_dirty into a lower level hookVille Syrjälä8-77/+66
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the bowels of the .atomic_enable() hook. That prevents us from taking the plane mutex in fb->dirty() unless we also plumb down the acquire context. Instead it seems simpler to split the fb->dirty() into a tinydrm specific lower level hook that can be called from mipi_dbi_enable_flush() and from a generic higher level tinydrm_fb_dirty() helper. As we don't have a tinydrm specific vfuncs table we'll just stick it into tinydrm_device directly for now. v2: Deal with the fb->dirty() in tinydrm_display_pipe_update() as well (Noralf) Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: David Lechner <david@lechnology.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180323153509.15287-1-ville.syrjala@linux.intel.com Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Noralf Trønnes <noralf@tronnes.org>
2018-03-28drm/simple-kms-helper: Plumb plane state to the enable hookVille Syrjälä9-9/+19
tinydrm enable hook wants to play around with the new fb in .atomic_enable(), thus we'll need access to the plane state. Performed with coccinelle: @r1@ identifier F =~ ".*enable$"; identifier P, CS; @@ F( struct drm_simple_display_pipe *P ,struct drm_crtc_state *CS + ,struct drm_plane_state *plane_state ) { ... } @@ struct drm_simple_display_pipe *P; expression E; @@ { + struct drm_plane *plane; ... + plane = &P->plane; P->funcs->enable(P ,E + ,plane->state ); ... } @@ identifier P, CS; @@ struct drm_simple_display_pipe_funcs { ... void (*enable)(struct drm_simple_display_pipe *P ,struct drm_crtc_state *CS + ,struct drm_plane_state *plane_state ); ... }; v2: Pimp the commit message (David) Cc: Marek Vasut <marex@denx.de> Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322202738.25817-1-ville.syrjala@linux.intel.com Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
2018-03-28drm/udl: Get rid of dev->struct_mutex usageDaniel Vetter5-5/+11
It's only used to protect our page list, and only when we know we have a full reference. This means none of these code paths can ever race with the final unref, and hence we do not need dev->struct_mutex serialization and can simply switch to our own locking. For more context the only magic the locked gem_free_object provides is that it prevents concurrent final unref (and destruction) of gem objects while anyone is holding dev->struct_mutex. This was used by i915 (and other drivers) to implement eviction handling with less headaches. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180327082356.24516-3-daniel.vetter@ffwll.ch
2018-03-28drm/rockchip: fixup comment for gem_free_object_unlockedDaniel Vetter1-2/+2
Just want to clean out all grep hits. gem_free_object is deprecated. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180327082356.24516-2-daniel.vetter@ffwll.ch
2018-03-28staging/vboxvideo: Use gem_free_object_unlockedDaniel Vetter1-1/+1
vboxvideo doesn't use dev->struct_mutex and therefore has no need to use gem_free_object. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Michael Thayer <michael.thayer@oracle.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180327082356.24516-1-daniel.vetter@ffwll.ch
2018-03-28drm/omap: Use normalized zpos for plane placementPeter Ujfalusi2-1/+4
Planes with identical zpos value will result undefined behavior: disappearing planes, screen flickering and it is not supported by the hardware. Use normalized zpos to make sure that we don't encounter invalid configuration. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321102029.15248-7-peter.ujfalusi@ti.com
2018-03-28drm: rcar-du: Let core take care of normalizing the zposPeter Ujfalusi1-9/+2
Set the drm_mode_config->normalize_zpos and call drm_atomic_helper_check() from rcar_du_atomic_check() instead of re implementing the function locally. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321102029.15248-6-peter.ujfalusi@ti.com
2018-03-28drm/sti: Let core take care of normalizing the zposPeter Ujfalusi1-21/+3
Instead of re-implementing the drm_atomic_helper_check() locally with just adding drm_atomic_normalize_zpos() into it, set the drm_mode_config->normalize_zpos. Note: the drm_atomic_helper_check() now includes if (state->legacy_cursor_update) state->async_update = !drm_atomic_helper_async_check(drm, state); which was added after the driver moved away from using it (38d868e41c4b9250d5a115c049dc2d48f4909581 drm: Don't force all planes to be added to the state due to zpos) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: Benjamin Gaignard <benjamin.gaignard@linaro.org> CC: Vincent Abriou <vincent.abriou@st.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321102029.15248-5-peter.ujfalusi@ti.com
2018-03-28drm/tegra: Let core take care of normalizing the zposPeter Ujfalusi1-17/+4
Set the drm_mode_config->normalize_zpos and call the generic drm_atomic_helper_check() instead of duplicating it within tegra_atomic_check(). Call tegra_display_hub_atomic_check() after the drm_atomic_helpre_check() returned without error. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321102029.15248-4-peter.ujfalusi@ti.com
2018-03-28drm/exynos: Let core take care of normalizing the zposPeter Ujfalusi3-22/+3
Instead of re-implementing the drm_atomic_helper_check() locally with just adding drm_atomic_normalize_zpos() into it, set the drm_mode_config->normalize_zpos. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> CC: Inki Dae <inki.dae@samsung.com> CC: Joonyoung Shim <jy0922.shim@samsung.com> CC: Seung-Woo Kim <sw0312.kim@samsung.com> CC: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321102029.15248-3-peter.ujfalusi@ti.com
2018-03-28drm: Add drm_mode_config->normalize_zpos booleanPeter Ujfalusi1-0/+11
Instead of drivers duplicating the drm_atomic_helper_check() code to be able to normalize the zpos they can use the normalize_zpos flag to let the drm core to do it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321102029.15248-2-peter.ujfalusi@ti.com
2018-03-28drm/dp/mst: Fix off-by-one typo when dump payload tableAndy Shevchenko1-4/+5
It seems there is a classical off-by-one typo from the beginning when commit ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") introduced a new helper. Fix a typo by introducing a macro constant. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180319141932.37290-1-andriy.shevchenko@linux.intel.com
2018-03-28Merge tag 'drm-amdkfd-next-2018-03-27' of ↵Dave Airlie18-162/+1279
git://people.freedesktop.org/~gabbayo/linux into drm-next - GPUVM support for dGPUs - KFD events support for dGPUs - Fix live-lock situation when restoring multiple evicted processes - Fix VM page table allocation on large-bar systems - Fix for build failure on frv architecture * tag 'drm-amdkfd-next-2018-03-27' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: Use ordered workqueue to restore processes drm/amdgpu: Fix acquiring VM on large-BAR systems drm/amdkfd: Add module option for testing large-BAR functionality drm/amdkfd: Kmap event page for dGPUs drm/amdkfd: Add ioctls for GPUVM memory management drm/amdkfd: Add TC flush on VMID deallocation for Hawaii drm/amdkfd: Allocate CWSR trap handler memory for dGPUs drm/amdkfd: Add per-process IDR for buffer handles drm/amdkfd: Aperture setup for dGPUs drm/amdkfd: Remove limit on number of GPUs drm/amdkfd: Populate DRM render device minor drm/amdkfd: Create KFD VMs on demand drm/amdgpu: Add kfd2kgd interface to acquire an existing VM drm/amdgpu: Add helper to turn an existing VM into a compute VM drm/amdgpu: Fix initial validation of PD BO for KFD VMs drm/amdgpu: Move KFD-specific fields into struct amdgpu_vm drm/amdkfd: fix uninitialized variable use drm/amdkfd: add missing include of mm.h
2018-03-28Merge tag 'drm-intel-next-fixes-2018-03-27' of ↵Dave Airlie3-26/+19
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Display fixes for booting with MST hub lid closed and display freezing after hibernation (fd.o bugs 105470 & 105196) - Fix for a very rare interrupt handling race resulting in GPU hang * tag 'drm-intel-next-fixes-2018-03-27' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915: Fix hibernation with ACPI S0 target state drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt drm/i915: Specify which engines to reset following semaphore/event lockups drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
2018-03-28Backmerge tag 'v4.16-rc7' into drm-nextDave Airlie607-4593/+6184
Linux 4.16-rc7 This was requested by Daniel, and things were getting a bit hard to reconcile, most of the conflicts were trivial though.
2018-03-27drm/i915: Fix hibernation with ACPI S0 target stateImre Deak2-13/+11
After commit dd9f31c7a3887950cbd0d49eb9d43f7a1518a356 Author: Imre Deak <imre.deak@intel.com> Date: Wed Aug 16 17:46:07 2017 +0300 drm/i915/gen9+: Set same power state before hibernation image save/restore during hibernation/suspend the power domain functionality got disabled, after which resume could leave it incorrectly disabled if the ACPI target state was S0 during suspend and i915 was not loaded by the loader kernel. This was caused by not considering if we resumed from hibernation as the condition for power domains reiniting. Fix this by simply tracking if we suspended power domains during system suspend and reinit power domains accordingly during resume. This will result in reiniting power domains always when resuming from hibernation, regardless of the platform and whether or not i915 is loaded by the loader kernel. The reason we didn't catch this earlier is that the enabled/disabled state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform and kernel config dependent: on my SKL the target state is S4 during PMSG_FREEZE and (with the driver loaded in the loader kernel) S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during PMSG_FREEZE but (contrary to this) power domains are not initialized during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or it's loaded but without the DMC firmware being available. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196 Reported-and-tested-by: amn-bas@hotmail.com Fixes: dd9f31c7a388 ("drm/i915/gen9+: Set same power state before hibernation image save/restore") Cc: amn-bas@hotmail.com Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322143642.26883-1-imre.deak@intel.com (cherry picked from commit 0f90603c33bdf6575cfdc81edd53f3f13ba166fb) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-03-27drm/i915/execlists: Use a locked clear_bit() for synchronisation with interruptChris Wilson1-13/+8
We were relying on the uncached reads when processing the CSB to provide ourselves with the serialisation with the interrupt handler (so we could detect new interrupts in the middle of processing the old one). However, in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP") those uncached reads were eliminated (on one path at least) and along with them our serialisation. The result is that we would very rarely miss notification of a new interrupt and leave a context-switch unprocessed, hanging the GPU. Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321091027.21034-1-chris@chris-wilson.co.uk (cherry picked from commit 9153e6b7c85edbc89e874e5c83f86217c53dcfaf) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-03-27drm/i915: Specify which engines to reset following semaphore/event lockupsChris Wilson1-2/+2
If the GPU is stuck waiting for an event or for a semaphore, we need to reset the GPU in order to recover. We have to tell the reset routine which engines we want reset, but we were still using the old interface and declaring it as "not-fatal". Fixes: 14b730fcb8d9 ("drm/i915/tdr: Prepare error handler to accept mask of hung engines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-1-chris@chris-wilson.co.uk (cherry picked from commit ca98317b89428e6ac17be0938b467ed78654dd56) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Powered by cgit, Gruvboxed by Blaster4385.