Reviewed-by: Deepak Rawat
On Tue, 2019-05-21 at 00:35 +0200, Daniel Vetter wrote:
> That's purely for the uapi layer to implement the ALLOW_MODESET flag.
>
> Drivers should instead look at the state, e.g. through
> drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also
> remove
> the c
From: Thomas Hellstrom
Currently we flag resources as dirty (GPU contents not yet read back to
the backing MOB) whenever they have been part of a command stream.
Obviously many resources can't be dirty and others can only be dirty when
written to by the GPU. That is when they are either bound to
From: Chengguang Xu
unlikely has already included in IS_ERR(), so just
remove redundant unlikely annotation.
Signed-off-by: Chengguang Xu
Reviewed-by: Deepak Rawat
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
Now that vmw_cmd_check prints debug message whenever a command verifier
fails, some of debug statements are unnecessary. Also rearranged some
debug print-out with this patch.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 20 -
Whenever FIFO allocation fails an error message is printed to dmesg.
Since this is common operation a lot of similar messages are scattered
everywhere. Use preprocessor macro to remove this cluttering.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_b
Error messages or debugging message reported during user-space command
submission should not be printed to dmesg by default. So add a new
preprocessor define called VMW_DEBUG_USER which translates to
DRM_DEBUG_DRIVER.
v2: Use VMW_DEBUG_USER instead of using DRM_DEBUG_DRIVER directly.
Signed-off-b
Several command verifier function check if context node is present or
not and if not present print an error and return. Use a preprocessor
macro to print the message.
v2: Name-space distinction for preprocessor macro
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_work_func':
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:514:7: warning:
variable 'restart' set but not used [-Wunused-but-set-variable]
It not used any more after commit d
Use preprocessor macro for repetitive device command struct format.
v2: Name-space distinction for preprocessor macro.
v3: Struct name as macro parameter and rebase.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 405 ---
Whenever command verifier function returns with an error, print a debug
message using VMW_DEBUG_USER. This will make sure failing commands can
be easily tracked for debugging purpose.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 7 +
DRM_ERROR overwhelms dmesgi so use VMW_DEBUG_USER instead. Any malformed
command should not really go to device so WARN_ONCE to spot this.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 18 ++
1 file changed, 10 insertions(
No functional change with this change, just fixing formatting and
spaces.
v2: Rebase.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 687 +++-
1 file changed, 302 insertions(+), 385 deletions(-)
diff --git a/drivers/
Hi Daniel/Dave,
The vmwgfx-next changes for 5.2:
Resource dirtying improvement by Thomas,
user-space error logging improvement and
some other minor fixes.
The following changes since commit 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
Merge tag 'drm-misc-next-2019-04-04' of
git://anongit.freedes
Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
user-space, so no point exposing it otherwise.
Signed-off-by: Deepak Rawat
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
---
drivers/gpu/drm/drm_mode_config.c | 5 +++--
1 file changed,
On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> On Mon, Apr 15, 2019 at 05:28:05PM +0000, Deepak Singh Rawat wrote:
> > Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
> > user-space, so no point exposing it otherwise.
> >
> > S
On Tue, 2019-04-16 at 20:15 +0200, Daniel Vetter wrote:
> On Tue, Apr 16, 2019 at 6:21 PM Deepak Singh Rawat > wrote:
> >
> > On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> > > On Mon, Apr 15, 2019 at 05:28:05PM +, Deepak Singh Rawat
> >
> >
> > If you mean ssh on annarchy.freedesktop.org, I already have one
> > with
> > username - drawat
>
> You're added. Please check out the dim toturial and pls ask any
> questions here or on irc or wherever - drm(-misc) maintainers are
> happy to help out.
> -Daniel
>
Hi I followed the inst
It seems this got missed, If no one has any objection I will submit the
patches via drm-mics route.
Deepak
On Tue, 2019-04-09 at 12:49 -0700, Deepak Singh Rawat wrote:
> Hi Daniel/Dave,
>
> The vmwgfx-next changes for 5.2:
> Resource dirtying improvement by Thomas,
> user-spac
Hi Thomas,
With minor comments below
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> This infrastructure will, for coherent resources, make sure that
> from the user-space point of view, data written by the CPU is
> immediately
> automatically available to
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> With emulated coherent memory we need to be able to quickly look up
> a resource from the MOB offset. Instead of traversing a linked list
> with
> O(n) worst case, use an RBtree with O(log n) worst case complex
Minor nits below, otherwise
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> Similar to write-coherent resources, make sure that from the user-
> space
> point of view, GPU rendered contents is automatically available for
> reading by the CPU.
>
> Signed-of
Minor nits below
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 16:04 +, Thomas Hellstrom wrote:
> Add the callbacks necessary to implement emulated coherent memory for
> surfaces. Add a flag to the gb_surface_create ioctl to indicate that
> surface memory should be coherent.
> Also bump th
On Wed, 2019-04-24 at 06:55 +1000, Dave Airlie wrote:
> I'll merge it, but it appears patchwork failed to find this pull
> request.
>
> What version of git was used to generate it?
git version 2.17.1
>
> Dave.
>
> On Sat, 20 Apr 2019 at 03:36, Deepak Singh Rawa
On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying
> resources")
Hi Stephen,
Actully the Signed-off-by: is not missing see
https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/vmwgfx?id=a9f5
On Wed, 2019-04-24 at 11:12 +1000, Stephen Rothwell wrote:
> Hi Deepak,
>
> On Wed, 24 Apr 2019 00:36:19 +0000 Deepak Singh Rawat <
> dra...@vmware.com> wrote:
> >
> > On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> > >
> > > Commit
&
For the series
Reviewed-by: Deepak Rawat
On Tue, 2019-01-29 at 14:35 +0100, Thomas Hellstrom wrote:
> Previously we set only the dma mask and not the coherent mask. Fix
> that.
> Also, for clarity, make sure both are initially set to 64 bits.
>
> Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the drive
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 11:07 +0100, Thomas Hellstrom wrote:
> The function was unconditionally returning 0, and a caller would have
> to
> rely on the returned fence pointer being NULL to detect errors.
> However,
> the function vmw_execbuf_copy_fence_user() would expect
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 10:52 +0100, Thomas Hellstrom wrote:
> if vmw_execbuf_fence_commands() fails, The handle value will be
> uninitialized and a bogus fence handle might be copied to user-space.
>
> Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for
>
On Tue, 2018-12-25 at 07:01 -0800, Thomas Hellstrom wrote:
> On Mon, 2018-12-24 at 11:49 +0100, Daniel Vetter wrote:
> > On Fri, Dec 21, 2018 at 8:56 PM Thomas Hellstrom <
> > thellst...@vmware.com> wrote:
> > > Reviewed-by: Thomas Hellstrom
> > >
> > > Daniel, Dave, could you help try to get thi
On Wed, 2019-01-09 at 18:49 +0100, Noralf Trønnes wrote:
> Hi,
>
> I was really pleased to see that the damage helper had landed. Now I
> can
> do framebuffer flushing solely through the display pipe functions.
> This
> prepares the ground for the removal of struct tinydrm_device in my
> next
> se
Hi Chengguang,
Thanks for doing this. Will include this for vmwgfx-next
Reviewed-by: Deepak Rawat
On Thu, 2019-02-21 at 10:09 +0800, Chengguang Xu wrote:
> unlikely has already included in IS_ERR(), so just
> remove redundant unlikely annotation.
>
> Signed-off-by: Chengguang Xu
> ---
> driv
Hi Nathan,
Thanks for doing this. I will include this in vmwgfx-next.
Reviewed-by: Deepak Rawat
On Thu, 2019-03-07 at 15:26 -0700, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, Clang warns:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3964:7: warning: variable
> 'hand
Hi Colin,
Thanks for doing this.
Reviewed-by: Deepak Rawat
Do you want me to include this in vmwgfx-next or will you submit this
via drm-mics?
On Fri, 2019-06-21 at 23:35 +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently when too many retries have occurred there is a memory
> lea
Hi Sam,
Thanks for doing this.
Reviewed-by: Deepak Rawat
I did some compile/basic run test on your patchs. Things look fine.
Will include this for vmwgfx-next so can run more automated test.
On Sun, 2019-06-23 at 12:23 +0200, Sam Ravnborg wrote:
> In two steps drop the use of drmP.h
> First pa
Hi Colin,
Reviewed-by: Deepak Rawat
Thanks,
Deepak
On Mon, 2019-06-24 at 23:44 +0100, Colin King wrote:
> From: Colin Ian King
>
> Variable sub_res is initialized to a value that is never read and it
> is re-assigned later in a for-loop. The initialization is redundant
> and can be removed.
Hi Thomas,
Thanks for doing this and somehow I missed the last patch, sorry about
that. Have some questions below otherwise the patch looks good to me.
Reviewed-by: Deepak Rawat
I will include your changes in vmwgfx-next and run tests.
On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote
Thanks for doing this.
Reviewed-by: Deepak Rawat
On Sat, 2019-03-23 at 02:46 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: In function 'vmw_fb_init':
> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:645:29: warning:
> variable 'fb_offset'
> Hi Deepak,
>
> As far as I can tell Thomas is on holidays for another 2+ weeks.
>
> Is there anyone else in the team who can review the VMWare patches of
> this series? I tested the lot quickly, but additional confirmation
> would
> be appreciated.
>
> You can find the series via the "VMware G
On Mon, 2019-07-22 at 18:40 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Realistically no drivers, but vmwgfx care about the DRM_AUTH flag
> here.
>
> Follow-up work in this driver will properly isolate primary clients
> from
> different master realms, thus we'll no longer need to parse _
flags.
>
> Until that work lands, add a local workaround.
>
> v2: Use bitwise or (Deepak)
>
> Cc: VMware Graphics
> Cc: Thomas Hellstrom
> Cc: Deepak Singh Rawat
> Signed-off-by: Emil Velikov
> ---
> I'd like to merge this and the next patch hrough the drm-
Hi All,
I need your help in determining the behavior of drmModeSetCrtc when it is
called with a FB and mode. Should it display the content of FB to physical
screen or not?
I ran the program
https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c with Vmware's
vmwgfx drm driver and it w
> On Thu, Sep 27, 2018 at 05:30:07PM -0700, Deepak Rawat wrote:
> > From: Rob Clark
> >
> > Add an atomic helper to implement dirtyfb support. This is needed to
> > support DSI command-mode panels with x11 userspace (ie. when we can't
> > rely on pageflips to trigger a flush to the panel).
> >
>
> drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
> > create mode 100644 drivers/gpu/drm/selftests/test-
> drm_damage_helper.c
> >
> > diff --git a/drivers/gpu/drm/selftests/Makefile
> b/drivers/gpu/drm/selftests/Makefile
> > index 9fc349fa18e9..88ac216f5962 100644
> > --- a/drivers/gpu/dr
> On Wed, Oct 10, 2018 at 05:16:43PM -0700, Deepak Rawat wrote:
> > Selftest for drm damage helper iterator functions.
> >
> > Cc: ville.syrj...@linux.intel.com
> > Cc: Daniel Vetter
> > Cc: Pekka Paalanen
> > Cc: Daniel Stone
> > Cc: intel-...@lists.freedesktop.org
> > Cc: igt-...@lists.freedes
> > > Obviously needs some adjusting on the igt side too, since we seem to be
> > > missing the igt scaffolding for tests-drm-helper.ko.
> > > -Daniel
> >
> > Hi Daniel,
> >
> > Thanks for the review. I am a little confused here. Should we have single
> > kernel module for drm plane helper selftest
>
> On Tue, Oct 16, 2018 at 02:21:17PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 15, 2018 at 04:11:41PM +0000, Deepak Singh Rawat wrote:
> > > > On Wed, Oct 10, 2018 at 05:16:43PM -0700, Deepak Rawat wrote:
> > > > > Selftest for drm damage helper ite
> On Tue, Oct 16, 2018 at 01:46:09PM -0700, Deepak Rawat wrote:
> > Selftest for drm damage helper iterator functions.
> >
> > Cc: Daniel Vetter
> > Cc: alexandru-cosmin.gheor...@arm.com
> > Signed-off-by: Deepak Rawat
> > Reviewed-by: Daniel Vetter
> > Reviewed-by: Thomas Hellstrom
>
> I gues
> Hi Deepak,
>
> Something to consider, with this approach we kind of break the
> following behaviour:
> "Only tests enabled as module parameters are run, if no test is
> explicitly enabled then all of them are run"
>
> What I think we should do is have just one header where we put the
> selftes
>
> On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 07:14:51PM +0000, Deepak Singh Rawat wrote:
> > > This makes sense once we got rid of plane->fb
> > >
> > > Will this go to drm-next?
> >
> > The pl
Looks good to me based on my limited understanding. Thomas/Sinclair can
could you please review and then we can include this in drm-fixes.
Thanks,
Deepak
>
> arg.version is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
Hi, thanks for the patch. Perhaps can get rid of vmw_kms_resume
and vmw_kms_suspend, otherwise looks good to me.
>
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> suspend_state can be removed from vmw_private as
> it will not be used anymore.
>
> >
> > +FB_DAMAGE_CLIPS
> > +~~~
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
> > + :doc: overview
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
> > + :export:
>
> You forgot to include your nice kerneldoc from the header. Please run
>
> $ make
> > #include
> >
> > /**
> > @@ -75,6 +76,11 @@
> > * While kernel does not error for overlapped damage clips, it is
> discouraged.
> > */
> >
> > +static int convert_fixed_to_32(int fixed)
> > +{
> > + return ((fixed >> 15) & 1) + (fixed >> 16);
> > +}
> > +
> > /**
> > * drm_plane_en
> > drivers/gpu/drm/drm_atomic_helper.c | 4
> > include/drm/drm_damage_helper.h | 10 ++
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> > index be83e2763c18..e06d2d5d582f 100644
> > --- a/d
>
> On Wed, Sep 05, 2018 at 04:38:48PM -0700, Deepak Rawat wrote:
> > From: Lukasz Spintzyk
> >
> > FB_DAMAGE_CLIPS is an optional plane property to mark damaged regions
> > on the plane in framebuffer coordinates of the framebuffer attached to
> > the plane.
> >
> > The layout of blob data is si
On Wed, 2018-12-12 at 15:35 +0100, Thomas Hellstrom wrote:
> With the new validation code, a malicious user-space app could
> potentially submit command streams with enough buffer-object and
> resource
> references in them to have the resulting allocated validion nodes and
> relocations make the ke
Reviewed-by: Deepak Rawat
On Wed, 2018-12-12 at 10:38 -0800, Thomas Hellstrom wrote:
> Hi, Deepak,
>
> On Wed, 2018-12-12 at 10:00 -0800, Deepak Singh Rawat wrote:
> > On Wed, 2018-12-12 at 15:35 +0100, Thomas Hellstrom wrote:
> > > With the new validation code, a
>
> On Thu, 6 Sep 2018 21:36:51 +0000
> Deepak Singh Rawat wrote:
>
> > >
> > > - Why no input validation on the damage clips against the framebuffer
> > > size? Ime not validating just leads to funny driver bugs down the road,
> > > so what&
> > > > +#include
> > > > +#include
> > > > +
> > > > +/**
> > > > + * DOC: overview
> > > > + *
> > > > + * FB_DAMAGE_CLIPS is an optional plane property which provides a
> > > means to
> > > > + * specify a list of damage rectangles on a plane in framebuffer
> > > coordinates of
> > > > + * th
Hi Alexandru,
Thanks for the patch, for the vmwgfx part:
Reviewed-by: Deepak Rawat
>
> Signed-off-by: Alexandru Gheorghe cosmin.gheor...@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vm
>
> On Wed, Apr 04, 2018 at 04:49:05PM -0700, Deepak Rawat wrote:
> > Hi All,
> >
> > This is extension to Lukasz Spintzyk earlier draft of damage interface for
> drm.
> > Bascially a new plane property is added called "DAMAGE_CLIPS" which is
> simply
> > an array of drm_rect (exported to userspac
>
> From: Ville Syrjälä
>
> Instead of looking at plane->fb let's look at the proper new
> plane state.
>
> Not that the code makes a ton of sense. It's only going through the
> crtcs in the atomic state, so assuming not all of them are included
> we're not even calculating the total bandwidth
>
> On Thu, Apr 05, 2018 at 08:15:05PM +, Deepak Singh Rawat wrote:
> >
> > >
> > > From: Ville Syrjälä
> > >
> > > Instead of looking at plane->fb let's look at the proper new
> > > plane state.
> > >
> > >
>
> On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote:
> > From: Lukasz Spintzyk
> >
> > Optional plane property to mark damaged regions on the plane in
> > framebuffer coordinates of the framebuffer attached to the plane.
> >
> > The layout of blob data is simply an array of drm_mode_
>
> On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote:
> > With damage property in drm_plane_state, this patch adds helper iterator
> > to traverse the damage clips. Iterator will return the damage rectangles
> > in framebuffer, plane or crtc coordinates as need by driver
> > implementa
>
> On Wed, Apr 04, 2018 at 04:49:08PM -0700, Deepak Rawat wrote:
> > This patch adds a helper which should be called by driver which enable
> > damage (by calling drm_plane_enable_damage_clips) from atomic_check
> > hook. This helper for now set the damage to NULL for the planes on crtc
> > which
> plane damage.
>
> On 04/05/2018 09:52 AM, Daniel Vetter wrote:
> >
> > TYPE_PLANE I have no idea who needs that. I suggest we just drop it.
>
> I'm assuming CRTC plane coordinates here. They are used for uploading
> contents of hardware planes. Like, in the simplest case, cursor images.
Yes th
> >>> 1) Expose a dirty (or content_age property)
> >>> 2) Attach a clip-rect blob property.
> >>> 3) Fake a page-flip by ping-ponging two frame-buffers pointing to the
> >>> same
> >>> underlying buffer object.
> >>>
> >>> Are you saying that people are already using 3) and we should keep
> using
Reviewed-by: Deepak Rawat
>
> From: Ville Syrjälä
>
> The only caller of vmw_kms_update_implicit_fb() is the page_flip
> hook which itself gets called with the plane mutex already held.
> Hence we can look at plane->state safely. Toss in a lockdep assert
> to make the situation more clear.
>
>
> From: Ville Syrjälä
>
> Instead of looking at the (soon to be deprecated) plane->fb we'll
> examing plane->state->fb instead. We can do this because
> vmw_du_crtc_atomic_check() prevents us from enabling a crtc
> without the primary plane also being enabled.
>
> Due to that same reason, I'm
This makes sense once we got rid of plane->fb
Will this go to drm-next? Could you please CC
me so that I can do some testing myself. Thanks.
Reviewed-by: Deepak Rawat
>
> From: Ville Syrjälä
>
> We want to get rid of plane->fb on atomic drivers. Stop setting it.
>
> Cc: Thomas Hellstrom
>
> > > > +void drm_plane_enable_damage_clips(struct drm_plane *plane)
> > > > +{
> > > > + struct drm_device *dev = plane->dev;
> > > > + struct drm_mode_config *config = &dev->mode_config;
> > > > +
> > > > + drm_object_attach_property(&plane->base, config-
> > > >prop_damage_clip
>Hi,
>
>Many thanks that you have picked it up.
>Unfortunately I didn't had time to work on it for a while.
>
>I am ok with what you have done, ihmo the review is going in good direction.
>I will try not to miss your update of it.
>From my side I can say that damage rects with frame-buffer coordina
Hi Michal,
Are you currently working on this feature. I started to look into page flip
with damage for VMware drivers.
Thanks,
Deepak
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Michal Lukaszek
> Sent: Tuesday, September 26, 20
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Thursday, December 21, 2017 5:11 AM
> To: Ville Syrjälä
> Cc: airl...@linux.ie; daniel.vet...@intel.com; dri-
> de...@lists.freedesktop.org; Lukasz Spintzyk
>
> S
Thanks Rob for finding this one.
Reviewed-by: Deepak Rawat
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Rob Clark
> Sent: Wednesday, January 17, 2018 7:16 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Thomas Hellstrom ; Rob Clark
> ; David Airlie ; linux-
>
work.
Thanks,
Deepak
From: Lukasz Spintzyk [mailto:lukasz.spint...@displaylink.com]
Sent: Thursday, January 4, 2018 5:53 AM
To: Thomas Hellstrom ; dri-devel@lists.freedesktop.org;
daniel.vet...@intel.com; gust...@padovan.org; seanp...@chromium.org;
airl...@linux.ie; Deepak Singh Rawat
Subject
Thanks for doing this. Will include this one with next vmwgfx pull
request.
Reviewed-by: Deepak Rawat
On Thu, 2019-02-14 at 02:08 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function
> 'vmw_cmdbuf_work_func':
> drivers
78 matches
Mail list logo
