- 26 Mar, 2020 14 commits
-
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. v2: After drm_dev_init/drmm_add_final_kfree we need to clean up everything through a drm_dev_put. Rework the unwind code to match that. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@chromium.org> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-14-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. v2: Fix unused variable warning, spotted while applying. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-13-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. Acked-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-12-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. I also noticed that the unwind code is wrong, after drm_dev_init the drm_device owns the v3d allocation, so the kfree(v3d) is a double-free. Reorder the setup to fix this issue. After a bit more prep in drivers and drm core v3d should be able to switch over to devm_drm_dev_init, which should clean this up further. Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-11-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. I also noticed that cirrus forgot to call drm_dev_fini(). v2: Don't call kfree(cirrus) after we've handed overship of that to drm_device and the drmm_ stuff. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-10-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. The mock device in the selftests needed it's pci_device split up from the drm_device. In the future we could simplify this again by allocating the pci_device as a managed allocation too. v2: I overlooked that i915_driver_destroy is also called in the unwind code of the error path. There we need a drm_dev_put. Similar for the mock object. Now the problem with that is that the drm_driver->release callbacks for both the real driver and the mock one assume everything has been set up. Hence going through that path for a partially set up driver will result in issues. Quickest fix is to disable the ->release() hook until the driver is fully initialized, and keep the onion unwinding. Long term would be cleanest to move everything over to drmm_ release actions, but that's a lot of work for a big driver like i915. Plus more core work needed first anyway. v3: Fix i915_drm pointer wrangling in mock_gem_device. Also switch over to start using drm_dev_put() to clean up even on the error path. Aside I think the current error path is leaking the allocation. v4: more fixes for intel-gfx-ci, some if it damage from v3 :-/ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-9-daniel.vetter@ffwll.ch
-
Maarten Lankhorst authored
Requested for getting some i915 fixes back into drm-misc-next by danvet. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-8-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With this we can drop the final kfree from the release function. v2: We need drm_dev_put to unroll the driver creation (once drm_dev_init and drmm_add_final_kfree suceeded), otherwise the drmm_ magic doesn't happen. v3: Actually squash in the fixup (Laurent). Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-7-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
They all share mipi_dbi_release so we need to switch them all together. With this we can drop the final kfree from the release function. Aside, I think we could perhaps have a tiny additional helper for these mipi_dbi drivers, the first few lines around devm_drm_dev_init are all the same (except for the drm_driver pointer). Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Noralf Trønnes <noralf@tronnes.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-6-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I also did a full review of all callers, and only the xen driver forgot to call drm_dev_put in the failure path. Fix that up too. v2: I noticed that xen has a drm_driver.release hook, and uses drm_dev_alloc(). We need to remove the kfree from xen_drm_drv_release(). bochs also has a release hook, but leaked the drm_device ever since commit 0a6659bd Author: Gerd Hoffmann <kraxel@redhat.com> Date: Tue Dec 17 18:04:46 2013 +0100 drm/bochs: new driver This patch here fixes that leak. Same for virtio, started leaking with commit b1df3a2b Author: Gerd Hoffmann <kraxel@redhat.com> Date: Tue Feb 11 14:58:04 2020 +0100 drm/virtio: add drm_driver.release callback. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: xen-devel@lists.xenproject.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: xen-devel@lists.xenproject.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-5-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
We have lots of these. And the cleanup code tends to be of dubious quality. The biggest wrong pattern is that developers use devm_, which ties the release action to the underlying struct device, whereas all the userspace visible stuff attached to a drm_device can long outlive that one (e.g. after a hotunplug while userspace has open files and mmap'ed buffers). Give people what they want, but with more correctness. Mostly copied from devres.c, with types adjusted to fit drm_device and a few simplifications - I didn't (yet) copy over everything. Since the types don't match code sharing looked like a hopeless endeavour. For now it's only super simplified, no groups, you can't remove actions (but kfree exists, we'll need that soon). Plus all specific to drm_device ofc, including the logging. Which I didn't bother to make compile-time optional, since none of the other drm logging is compile time optional either. One tricky bit here is the chicken&egg between allocating your drm_device structure and initiliazing it with drm_dev_init. For perfect onion unwinding we'd need to have the action to kfree the allocation registered before drm_dev_init registers any of its own release handlers. But drm_dev_init doesn't know where exactly the drm_device is emebedded into the overall structure, and by the time it returns it'll all be too late. And forcing drivers to be able clean up everything except the one kzalloc is silly. Work around this by having a very special final_kfree pointer. This also avoids troubles with the list head possibly disappearing from underneath us when we release all resources attached to the drm_device. v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless shuffling while getting everything into shape. v3: Add static to add/del_dr (Neil) Move typo fix to the right patch (Neil) v4: Enforce contract for drmm_add_final_kfree: Use ksize() to check that the drm_device is indeed contained somewhere in the final kfree(). Because we need that or the entire managed release logic blows up in a pile of use-after-frees. Motivated by a discussion with Laurent. v5: Review from Laurent: - %zu instead of casting size_t - header guards - sorting of includes - guarding of data assignment if we didn't allocate it for a NULL pointer - delete spurious newline - cast void* data parameter correctly in ->release call, no idea how this even worked before v6: Review from Sam - Add the kerneldoc for the managed sub-struct back in, even if it doesn't show up in the generated html somehow. - Explain why __always_inline. - Fix bisectability around the final kfree() in drm_dev_relase(). This is just interim code which will disappear again. - Some whitespace polish. - Add debug output when drmm_add_action or drmm_kmalloc fail. v7: My bisectability fix wasn't up to par as noticed by smatch. v8: Remove unecessary {} around if else v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr() helper (Thomas). v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow we need to wrap that in kstrdup_const() too!! Also renumber revision log, I somehow reset it midway thruh. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Neil Armstrong <narmstrong@baylibre.com Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
For two reasons: - The driver core clears this already for us after we're unloaded in __device_release_driver(). - It's way too late, the drm_device ->release callback might massively outlive the underlying physical device, since a drm_device can be kept alive by open drm_file or well really anything else userspace is still hanging onto. So if we clear this ourselves, we should clear it in the pci ->remove callback, not in the drm_device ->release callback. Looking at git history this was fixed in the driver core with commit 0998d063 Author: Hans de Goede <hdegoede@redhat.com> Date: Wed May 23 00:09:34 2012 +0200 device-core: Ensure drvdata = NULL when no driver is bound v2: Cite the core fix in the commit message (Chris). v3: Fix commit message and unused variable warning (Jani). Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
slab does this already, and I want to use this in a memory allocation tracker in drm for stuff that's tied to the lifetime of a drm_device, not the underlying struct device. Kinda like devres, but for drm. Acked-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-2-daniel.vetter@ffwll.ch
-
- 25 Mar, 2020 2 commits
-
-
git://people.freedesktop.org/~sroland/linuxDave Airlie authored
vmwgfx pull for for 5.7. Needed for GL4 functionality. Sync up device headers, add support for new commands, code refactoring around surface definition. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Roland Scheidegger (VMware)" <rscheidegger.oss@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323235434.11780-1-rscheidegger.oss@gmail.com
-
https://git.pengutronix.de/git/lst/linuxDave Airlie authored
- fix for potential out-of-bounds reads in the perfmon ioctl implementation from Christian - override to expose proper feature flags for the GC400 found on the STM32MP1 SoC, also from Christian - Guido fixed an issue where we would spuriously fail to enter runtime suspend due to a new GPU engine status bit on GC7000 - tree-wide change from Gustavo to get rid of zero-length arrays - fix for missed TS cache flush on GC7000, leading to spurious MMU faults from me - request pages from DMA32 zone on systems where we can't address all present memory from me Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/74d9c6d19099fdba6c6795204a6aa445b7930c79.camel@pengutronix.de
-
- 24 Mar, 2020 7 commits
-
-
Jernej Skrabec authored
is_color_space_conversion() is a misnomer. It checks not only if color space conversion is needed, but also if format conversion is needed. This is actually desired behaviour because result of this function determines if CSC block should be enabled or not (CSC block can also do format conversion). In order to clear misunderstandings, let's rework is_color_space_conversion() to do exactly what is supposed to do and add another function which will determine if CSC block must be enabled or not. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-5-jernej.skrabec@siol.net
-
Jernej Skrabec authored
CEA 861 standard requestis that RGB quantization range is "limited" for CEA modes. Support that by adding CSC matrix which downscales values. This allows proper color reproduction on TV and PC monitor at the same time. In future, override property can be added, like "Broadcast RGB" in i915 driver. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-4-jernej.skrabec@siol.net
-
Jonas Karlman authored
Setting scan mode to "none" confuses some TVs like LG B8, which randomly change overscan percentage over time. Digital outputs like HDMI and DVI, handled by this controller, don't really need overscan, so we can always set scan mode to underscan. Actually, this is exactly what drm_hdmi_avi_infoframe_from_display_mode() already does, so we can just remove offending line. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> [updated commit message] Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-3-jernej.skrabec@siol.net
-
Jernej Skrabec authored
sun8i_mixer.h include is misplaced. Move it. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200224173901.174016-8-jernej.skrabec@siol.net
-
Jernej Skrabec authored
Now that de2_fmt_info contains only DRM <-> HW format mapping, it doesn't make sense to return pointer to structure when searching by DRM format. Rework that to return only HW format instead. This doesn't make any functional change. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200224173901.174016-7-jernej.skrabec@siol.net
-
Jernej Skrabec authored
For RGB formats CSC mode is always set to none and for YUV formats almost always set to YUV to RGB. Add a helper function to deduce CSC mode from format. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200224173901.174016-6-jernej.skrabec@siol.net
-
Jernej Skrabec authored
drm_format_info structure already contains information if format is RGB or YUV. Use that instead. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200224173901.174016-5-jernej.skrabec@siol.net
-
- 23 Mar, 2020 17 commits
-
-
Thomas Hellström (VMware) authored
Signed-off-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com> ___ v2: Use 2.18 instead of 2.17
-
Deepak Rawat authored
Add a new param for user-space to determine if kernel module is SM5 capable. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Surface define v4 added new member buffer_byte_stride. With this patch add buffer_byte_stride in surface metadata and create surface using new command if support is available. Also with this patch replace device specific data types with kernel types. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Makes surface_define cleaner by sending vmw_surface_metadata instead of all the arguments individually. v2: fix uninitialized return value, error message Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Create a new structure vmw_surface_metadata representing the metadata used for creating surface. With this can make the surface_define_priv a bit cleaner. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
With SM5 capability a new version of streamoutput is supported by device which need backing mob and a new field. With this change the new command is supported in command buffer. v2: Also track streamoutput context binding in binding manager. v3: Track only one streamoutput as only one can be set to context. v4: Fix comment typos Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Signed-off-by: Neha Bhende <bhenden@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Previous name vmw_ctx_bindinfo_so is misleading because it actually represent so target and stream output is a new resource type that needs tracking for SM5 capable device. Also rename binding type enum and internal functions to reflect these belongs to so targets. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Validate indirect and dispatch commands in command buffer. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Virtual device now support new commands to manage unordered access views. Allow them as part of user-space command buffer. This involves adding UA view cotable, binding tracker info, new view type and command verifier functions. v2: fix comment typo v3: style fixes (don't use deprecated PTR_RET) Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Signed-off-by: Neha Bhende <bhenden@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Virtual device now supports new shader types, allow them as valid shader type in command buffer. Also add per shader bind info in binding manager state for new shader type. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Virtual device added new register for suggested GB memory, read the new register when available. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
A new enum to represent new SM5 graphics context capability in vmwgfx. v2: use new correct cap bits (merged several later commits into it). Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Signed-off-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Get the latest device headers for SM5 and other features development. v2: sync to newer bits (merge later commits) v3: sync to even newer bits Co-developed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Signed-off-by: Neha Bhende <bhenden@vmware.com> Signed-off-by: Charmaine Lee <charmainel@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org>
-
Deepak Rawat authored
Instead of having different bool in device private to represent incremental graphics context capabilities, add a new sm type enum. v2: Use enum instead of bit flag. v3: Incorporated review comments. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Logic ops commands are marked as deprecated by virtual device and were never used by vmwgfx. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
In favor of SM4.1 multisampling capability, virtual device deprecated old multisampling device capability. Mark legacy multisampling device capability as dead. Rename the function that masks legacy multisample capability to reflect that now it is masking a deprecated feature. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-
Deepak Rawat authored
Virtual device consider SVGA_CAP_DX and SVGA3D_DEVCAP_DXCONTEXT independent of each other. Some of the commands in cmd_buf depends on SVGA_CAP_DX, so better to check for that as well. Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
-