- 18 Jun, 2019 4 commits
-
-
Boris Brezillon authored
Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter values. There are discussions to expose global performance monitors (those counters that can't be retrieved on a per-job basis) in a consistent way, but this is likely to take time to settle on something that works for various HW/users. The ioctls are marked unstable so we can get rid of them when the time comes. We initally went for a debugfs-based interface, but this was making the transition to per-FD address space more complicated (we need to specify the namespace the GPU has to use when dumping the perf counters), hence the decision to switch back to driver specific ioctls which are passed the FD they operate on and thus will have a dedicated address space attached to them. Other than that, the implementation is pretty simple: it basically dumps all counters and copy the values to a userspace buffer. The parsing is left to userspace which has to know the specific layout that's used by the GPU (layout differs on a per-revision basis). Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Acked-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618081648.17297-5-boris.brezillon@collabora.com
-
Boris Brezillon authored
All models with an ID >= 0x1000 are Bifrost GPUs for now (might change with new gens). Suggested-by:
-
Boris Brezillon authored
We plan to expose performance counters through 2 driver specific ioctls until there's a solution to expose them in a generic way. In order to be able to deprecate those ioctls when this new infrastructure is in place we add an unsafe module parameter that will keep those ioctls hidden unless it's set to true (which also has the effect of tainting the kernel). All unstable ioctl handlers should use panfrost_unstable_ioctl_check() to check whether they're supposed to handle the request or reject it with ENOSYS. Suggested-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
Boris Brezillon authored
So they can be used from other files. Signed-off-by:
-
- 17 Jun, 2019 3 commits
-
-
Daniel Vetter authored
They're purely for internal use, not for drivers. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
We're kinda going in the wrong direction. Spotted while typing better gem/prime docs. Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Maarten Lankhorst authored
Pick up rc3 and rc4 and the merges from the other branches, we're a bit out of date. Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 16 Jun, 2019 2 commits
-
-
Douglas Anderson authored
In vop_crtc_mode_fixup() we fixup the mode to show what we actually will be able to achieve. However we should base our adjustments on any previous adjustments that were made. As an example, the dw_hdmi driver may wish to make some small adjustments to clock rates in its atomic_check() function. If it does, it will update the adjusted_mode. We shouldn't throw away those adjustments. NOTE: the version of the dw_hdmi driver upstream doesn't _actually_ make such adjustments, but downstream in Chrome OS it does. It is plausible that one day we'll figure out how to cleanly make that happen in an upstream-friendly way, so we should prepare by using the right mode. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-2-dianders@chromium.org
-
Douglas Anderson authored
When fixing up the clock in vop_crtc_mode_fixup() we're not doing it quite correctly. Specifically if we've got the true clock 266666667 Hz, we'll perform this calculation: 266666667 / 1000 => 266666 Later when we try to set the clock we'll do clk_set_rate(266666 * 1000). The common clock framework won't actually pick the proper clock in this case since it always wants clocks <= the specified one. Let's solve this by using DIV_ROUND_UP. Fixes: b59b8de3 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by:
Sean Paul <seanpaul@chromium.org> Reviewed-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
-
- 14 Jun, 2019 12 commits
-
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Ville Syrjälä authored
CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly causing i915 to detect it as disconnected. Add a quirk to ignore SINK_COUNT on these devices. Cc: David S. <david@majinbuu.com> Cc: Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Tested-by:
Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105406Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528140650.19230-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc
-
Oleg Vasilev authored
Since we are logging all vblank counter updates 30 lines below, it is also good to have some details whether and how vblank count difference is calculated. Signed-off-by:
Oleg Vasilev <oleg.vasilev@intel.com> Signed-off-by:
-
Rob Herring authored
In order to increase the chances of using 2MB pages, we need to align the GPU VA mapping to 2MB. Only do this if the object size is 2MB or more. Cc: Robin Murphy <robin.murphy@arm.com> Cc: Steven Price <steven.price@arm.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610165806.24854-1-robh@kernel.org
-
Greg Kroah-Hartman authored
As stated before, there is no need to care if a debugfs function succeeds or not, and no code logic in the kernel should ever change based on a debugfs function return value, so make drm_debugfs_create_files() never fail. If it encounters an odd/rare/impossible error (i.e. out of memory, or a duplicate debugfs filename to be created), just keep on moving as if nothing improper had happened. 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: dri-devel@lists.freedesktop.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190614095110.3716-2-gregkh@linuxfoundation.org
-
Sandor Yu authored
The value stored in the rate field of struct drm_dp_link should be the actual link-rate and not the bw_code. Right now the driver stores the code and converts it to the rate. So fixup the driver to store the rate itself. Signed-off-by:
Sandor Yu <Sandor.yu@nxp.com> Signed-off-by:
-
Justin Swartz authored
Like the RK3328, RK322x SoCs offer a Synopsis DesignWare HDMI transmitter and an Innosilicon HDMI PHY. Add a new dw_hdmi_plat_data struct, rk3228_hdmi_drv_data. Assign a set of mostly generic rk3228_hdmi_phy_ops functions. Add dw_hdmi_rk3228_setup_hpd() to enable the HDMI HPD and DDC lines. Signed-off-by:
Justin Swartz <justin.swartz@risingedge.co.za> Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDaniel Vetter authored
drm-misc-next for v5.3: UAPI Changes: Cross-subsystem Changes: - Add code to signal all dma-fences when freed with pending signals. - Annotate reservation object access in CONFIG_DEBUG_MUTEXES Core Changes: - Assorted documentation fixes. - Use irqsave/restore spinlock to add crc entry. - Move code around to drm_client, for internal modeset clients. - Make drm_crtc.h and drm_debugfs.h self-contained. - Remove drm_fb_helper_connector. - Add bootsplash to todo. - Fix lock ordering in pan_display_legacy. - Support pinning buffers to current location in gem-vram. - Remove the now unused locking functions from gem-vram. - Remove the now unused kmap-object argument from vram helpers. - Stop checking return value of debugfs_create. - Add atomic encoder enable/disable helpers. - pass drm_atomic_state to atomic connector check. - Add atomic support for bridge enable/disable. - Add self refresh helpers to core. Driver Changes: - Add extra delay to make MTP SDM845 work. - Small fixes to virtio, vkms, sii902x, sii9234, ast, mcde, analogix, rockchip. - Add zpos and ?BGR8888 support to meson. - More removals of drm_os_linux and drmP headers for amd, radeon, sti, r128, r128, savage, sis. - Allow synopsis to unwedge the i2c hdmi bus. - Add orientation quirks for GPD panels. - Edid cleanups and fixing handling for edid < 1.2. - Add runtime pm to stm. - Handle s/r in dw-hdmi. - Add hooks for power on/off to dsi for stm. - Remove virtio dirty tracking code, done in drm core. - Rework BO handling in ast and mgag200. Tiny conflict in drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c, needed #include <linux/slab.h> to make it compile. Signed-off-by:
-
Greg Hackmann authored
The show_fdinfo handler exports the same information available through debugfs on a per-buffer basis. Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Chenbo Feng <fengc@google.com> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190613223408.139221-4-fengc@google.com
-
Greg Hackmann authored
This patch adds complimentary DMA_BUF_SET_NAME ioctls, which lets userspace processes attach a free-form name to each buffer. This information can be extremely helpful for tracking and accounting shared buffers. For example, on Android, we know what each buffer will be used for at allocation time: GL, multimedia, camera, etc. The userspace allocator can use DMA_BUF_SET_NAME to associate that information with the buffer, so we can later give developers a breakdown of how much memory they're allocating for graphics, camera, etc. Signed-off-by:
-
Greg Hackmann authored
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN can get a lot of fine-grained data about how shmem buffers are shared among processes. stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's size (st_size), and even the number of pages currently charged to the buffer (st_blocks / 512). In contrast, all dma-bufs share the same anonymous inode. So while we can count how many dma-buf fds or mappings a process has, we can't get the size of the backing buffers or tell if two entries point to the same dma-buf. On systems with debugfs, we can get a per-buffer breakdown of size and reference count, but can't tell which processes are actually holding the references to each buffer. Replace the singleton inode with full-fledged inodes allocated by alloc_anon_inode(). This involves creating and mounting a mini-pseudo-filesystem for dma-buf, following the example in fs/aio.c. Signed-off-by:
-
Sean Paul authored
I missed amdgpu in my connnector_helper_funcs->atomic_check conversion, which is understandably causing compilation failures. Fixes: 6f3b6278 ("drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [for rcar lvds] Cc: Sean Paul <seanpaul@chromium.org> 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: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 13 Jun, 2019 19 commits
-
-
Sean Paul authored
Fixes the following warning: ../drivers/gpu/drm/drm_connector.c:981: WARNING: Definition list ends without a blank line; unexpected unindent. Fixes: a09db883 ("drm: Fix docbook warnings in hdr metadata helper structures") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjä <ville.syrjala@linux.intel.com> 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: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Ville Syrjä" <ville.syrjala@linux.intel.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: Sean Paul <sean@poorly.run> (v1) Cc: Uma Shankar <uma.shankar@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Sean Paul authored
Instead of flushing all vops every time we get a dirtyfb call, use the damage helper to kick off an atomic commit. Even though we don't use damage clips, the helper commit will force us through the normal psr_inhibit_get/put sequence. Changes in v3: - Added to the set Changes in v4: - None Changes in v5: - None Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-7-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-7-sean@poorly.runSuggested-by:
Daniel Vetter <daniel@ffwll.ch> Tested-by:
-
Sean Paul authored
This patch adds a new drm helper library to help drivers implement self refresh. Drivers choosing to use it will register crtcs and will receive callbacks when it's time to enter or exit self refresh mode. In its current form, it has a timer which will trigger after a driver-specified amount of inactivity. When the timer triggers, the helpers will submit a new atomic commit to shut the refreshing pipe off. On the next atomic commit, the drm core will revert the self refresh state and bring everything back up to be actively driven. From the driver's perspective, this works like a regular disable/enable cycle. The driver need only check the 'self_refresh_active' state in crtc_state. It should initiate self refresh mode on the panel and enter an off or low-power state. Changes in v2: - s/psr/self_refresh/ (Daniel) - integrated the psr exit into the commit that wakes it up (Jose/Daniel) - made the psr state per-crtc (Jose/Daniel) Changes in v3: - Remove the self_refresh_(active|changed) from connector state (Daniel) - Simplify loop in drm_self_refresh_helper_alter_state (Daniel) - Improve self_refresh_aware comment (Daniel) - s/self_refresh_state/self_refresh_data/ (Daniel) Changes in v4: - Move docbook location below panel (Daniel) - Improve docbook with references and more detailed explanation (Daniel) - Instead of register/unregister, use init/cleanup (Daniel) Changes in v5: - Resolved conflict in drm_atomic_helper.c #include block - Resolved conflict in rst with HDCP helper docs Changes in v6: - Fix include ordering, clean up forward declarations (Sam) Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-2-sean@poorly.run Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-1-sean@poorly.run Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-6-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-6-sean@poorly.run Link to v5: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-6-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jose Souza <jose.souza@intel.com> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Tested-by:
-
Sean Paul authored
Everyone who implements connector_helper_funcs->atomic_check reaches into the connector state to get the atomic state. Instead of continuing this pattern, change the callback signature to just give atomic state and let the driver determine what it does and does not need from it. Eventually all atomic functions should do this, but that's just too much busy work for me. Changes in v3: - Added to the set Changes in v4: - None Changes in v5: - intel_digital_connector_atomic_check declaration moved to i915_atomic.h Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-5-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-5-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Tested-by:
-
Sean Paul authored
This patch adds atomic variants for all of pre_enable/enable/disable/post_disable bridge functions. These will be called from the appropriate atomic helper functions. If the bridge driver doesn't implement the atomic version of the function, we will fall back to the vanilla implementation. Note that some drivers call drm_bridge_disable directly, and these cases are not covered. It's up to the driver to decide whether to implement both atomic_disable and disable, or if it's not necessary. Changes in v3: - Added to the patchset Changes in v4: - Fix up docbook references (Daniel) Changes in v5: - None Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-4-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-4-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Laurent Pinchart authored
Add functions to the atomic core to retrieve the old and new connectors associated with an encoder in a drm_atomic_state. This is useful for encoders and bridges that need to access the connector, for instance for the drm_display_info. The CRTC associated with the encoder can also be retrieved through the connector state, and from it, the old and new CRTC states. Changed in v4: - Added to the set Changed in v5: - Fix up docbook (Daniel & Laurent) Changed in v6: - Updated commit subject (Sam) Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-3-sean@poorly.run Link to v5: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-3-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Tested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> [seanpaul removed WARNs from helpers and added docs to explain why returning NULL might be valid] Signed-off-by:
-
Sean Paul authored
This patch adds atomic_enable and atomic_disable callbacks to the encoder helpers. This will allow encoders to make informed decisions in their start-up/shutdown based on the committed state. Aside from the new hooks, this patch also introduces the new signature for .atomic_* functions going forward. Instead of passing object state (well, encoders don't have atomic state, but let's ignore that), we pass the entire atomic state so the driver can inspect more than what's happening locally. This is particularly important for the upcoming self refresh helpers. Changes in v3: - Added patch to the set Changes in v4: - Move atomic_disable above prepare (Daniel) - Add breadcrumb to .enable() docbook (Daniel) Changes in v5: - None Changes in v6: - Tweak kerneldoc some more (Sam) Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-2-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-2-sean@poorly.run Link to v5: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-2-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Tested-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190613114618.GD13119@kroah.com
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Because there is no need to check these functions, a number of local functions can be made to return void to simplify things as nothing can fail. 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: dri-devel@lists.freedesktop.org Signed-off-by:
-
Linus Walleij authored
This converts the Analogix display port to use GPIO descriptors instead of DT-extracted numbers. Cc: Douglas Anderson <dianders@chromium.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
-
Linus Walleij authored
This include is only used for some gpio drivers and consumers that look up GPIO numbers directly from the device tree. This driver does not use it and only needs <linux/gpio/consumer.h>. Delete the unused include. Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
-
Hariprasad Kelam authored
fix below warning reported by coccicheck ./drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1414:6-8: WARNING: possible condition with no effect (if == else) Signed-off-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: "Guido Günther" <agx@sigxcpu.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Guido Günther <agx@sigxcpu.org> Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Also, because there is no need to save the file dentry, remove the local variable and just recursively delete the whole directory when shutting down. Cc: Lukas Wunner <lukas@wunner.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Thomas Zimmermann authored
The GEM VRAM functions with kmap-object argument are not required any longer. Remove them. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
-
Thomas Zimmermann authored
The lock functions and the locked-pin/unpin functions of GEM VRAM are not required any longer. Remove them. Signed-off-by:
-
Thomas Zimmermann authored
The cursor handling in mgag200 is complicated to understand. It touches a number of different BOs, but doesn't really use all of them. Rewriting the cursor update reduces the amount of cursor state. There are two BOs for double-buffered HW updates. The source BO updates the one that is currently not displayed and then switches buffers. Explicit BO locking has been removed from the code. BOs are simply pinned and unpinned in video RAM. v2: * pin cursor BOs to current location Signed-off-by:
-
Thomas Zimmermann authored
Another explicit lock operation of a GEM VRAM BO is located in mgag200's framebuffer update code. Instead of locking the BO, we pin it to wherever it is. v2: * update with pin flag of 0 Signed-off-by:
-
Thomas Zimmermann authored
Another explicit lock operation of a GEM VRAM BO is located in AST's framebuffer update code. Instead of locking the BO, we pin it to wherever it is. v2: * update with pin flag of 0 Signed-off-by:
-
