On 10/22/19 10:17 PM, Stephen Rothwell wrote:
> Hi all,
>
> n commit
>
> 6fee2a0be0ec ("x86/cpu/vmware: Fix platform detection VMWARE_PORT macro")
>
> Fixes tag
>
> Fixes: b4dd4f6e3648 ("Add a header file for hypercall definitions")
The cited subject is missing a leading "x86/vmware:". Ingo, p
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 6fee2a0be0ecae939d4b6cd8297d88b5cbb61654
Gitweb:
https://git.kernel.org/tip/6fee2a0be0ecae939d4b6cd8297d88b5cbb61654
Author:Thomas Hellstrom
AuthorDate:Mon, 21 Oct 2019 19:24:03 +02:00
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: db633a4e0e6eda69b6065e3e106f9ea13a0676c3
Gitweb:
https://git.kernel.org/tip/db633a4e0e6eda69b6065e3e106f9ea13a0676c3
Author:Thomas Hellstrom
AuthorDate:Mon, 21 Oct 2019 19:24:02 +02:00
On 10/14/19 3:22 PM, Thomas Hellström (VMware) wrote:
> From: Thomas Hellström
>
> Graphics APIs like OpenGL 4.4 and Vulkan require the graphics driver
> to provide coherent graphics memory, meaning that the GPU sees any
> content written to the coherent memory on the next GPU operation that
> tou
Hi,
On 10/9/19 7:17 PM, Linus Torvalds wrote:
> On Wed, Oct 9, 2019 at 10:03 AM Thomas Hellström (VMware)
> wrote:
>> Nope, it handles the hugepages by ignoring them, since they should be
>> read-only, but if pmd_entry() was called with something else than a
>> hugepage, then it requests the fall
On 10/8/19 7:07 PM, Linus Torvalds wrote:
> On Tue, Oct 8, 2019 at 2:15 AM Thomas Hellström (VMware)
> wrote:
>> Add two utilities to 1) write-protect and 2) clean all ptes pointing into
>> a range of an address space.
> The code looks much simpler and easier to understand now, I think, but
> that
^
> LLVM ERROR: Error parsing inline asm
>
> Use the full form of the instruction to fix the build.
>
> Signed-off-by: Sami Tolvanen
Acked-by: Thomas Hellstrom
> ---
> arch/x86/kernel/cpu/vmware.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On 10/2/19 10:28 PM, Linus Torvalds wrote:
> On Wed, Oct 2, 2019 at 12:09 PM Thomas Hellström (VMware)
> wrote:
>> Yes I typically tend towards using a "namespace_object_operation" naming
>> scheme, with "as_dirty" being the namespace here,
> We discourage that kind of mindless namespacing for cor
Hi,
On 9/18/19 7:57 PM, Dave Hansen wrote:
> On 9/17/19 6:01 AM, Thomas Hellström (VMware) wrote:
>> diff --git a/arch/x86/include/asm/pgtable_types.h
>> b/arch/x86/include/asm/pgtable_types.h
>> index b5e49e6bac63..8267dd426b15 100644
>> --- a/arch/x86/include/asm/pgtable_types.h
>> +++ b/arch/x
On Thu, 2019-09-05 at 09:05 +0200, Gerd Hoffmann wrote:
> Add struct drm_vma_offset_manager to vma_private, initialize it and
> pass it to ttm_bo_device_init().
>
> With this in place the last user of ttm's embedded vma offset manager
> is gone and we can remove it (in a separate patch).
>
> Sign
The following commit has been merged into the x86/vmware branch of tip:
Commit-ID: b4dd4f6e3648dfd66576515fd885a9a765c0
Gitweb:
https://git.kernel.org/tip/b4dd4f6e3648dfd66576515fd885a9a765c0
Author:Thomas Hellstrom
AuthorDate:Wed, 28 Aug 2019 10:03:51 +02:00
The following commit has been merged into the x86/vmware branch of tip:
Commit-ID: bac7b4e843232a3a49a042410cf743341eb0887e
Gitweb:
https://git.kernel.org/tip/bac7b4e843232a3a49a042410cf743341eb0887e
Author:Thomas Hellstrom
AuthorDate:Wed, 28 Aug 2019 10:03:50 +02:00
The following commit has been merged into the x86/vmware branch of tip:
Commit-ID: 6abe3778cf5abd59b23b9037796f3eab8b7f1d98
Gitweb:
https://git.kernel.org/tip/6abe3778cf5abd59b23b9037796f3eab8b7f1d98
Author:Thomas Hellstrom
AuthorDate:Wed, 28 Aug 2019 10:03:52 +02:00
The following commit has been merged into the x86/vmware branch of tip:
Commit-ID: f7b15c74cffd760ec9959078982d8268a38456c4
Gitweb:
https://git.kernel.org/tip/f7b15c74cffd760ec9959078982d8268a38456c4
Author:Thomas Hellstrom
AuthorDate:Wed, 28 Aug 2019 10:03:53 +02:00
On 8/8/19 11:56 PM, Christoph Hellwig wrote:
On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
Note that both Thomas and Steven have series touching this area pending,
and there are a couple consumer in flux too - the hmm tree already
conflicts with this series, and I have potentia
on patch from Linus Torvalds.
Signed-off-by: Christoph Hellwig
---
Typo: For the patch title s/seperate/separate/
Otherwise for the series
Reviewed-by: Thomas Hellstrom
/Thomas
Commit-ID: 406de552c2be6ded524c75d14a73cf7f027f587e
Gitweb: https://git.kernel.org/tip/406de552c2be6ded524c75d14a73cf7f027f587e
Author: Thomas Hellstrom
AuthorDate: Thu, 28 Mar 2019 12:06:37 +
Committer: Thomas Gleixner
CommitDate: Wed, 17 Jul 2019 00:42:27 +0200
MAINTAINERS
Commit-ID: 907cb11da7a725445dccc6c2ca2d428739f6cd71
Gitweb: https://git.kernel.org/tip/907cb11da7a725445dccc6c2ca2d428739f6cd71
Author: Thomas Hellstrom
AuthorDate: Thu, 28 Mar 2019 12:06:37 +
Committer: Thomas Gleixner
CommitDate: Tue, 16 Jul 2019 23:13:50 +0200
MAINTAINERS
Thanks, Murray,
I'll include in the next vmwgfx-fixes pull request.
On Mon, 2019-05-20 at 21:57 +1200, Murray McAllister wrote:
> If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
> of SVGA3D_INVALID_ID, and a shader type of
> SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
>
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 the drm minor version to signal the availability of coherent
surfaces.
Signed-off-by: Thomas Hellstrom
a_address() works as expected with all sglists.
>
> A new iterator type is introduced to provide compile-time safety
> against
> wrongly mixing accessors and iterators.
>
> Acked-by: Christoph Hellwig (for scatterlist)
> Signed-off-by: Jason Gunthorpe
>
For the vmwgfx pa
On Mon, 2019-02-04 at 13:11 +0100, Thomas Hellström wrote:
> On Mon, 2019-02-04 at 09:19 +0100, Christoph Hellwig wrote:
> > On Fri, Jan 25, 2019 at 09:12:13AM +0100, Thomas Hellstrom wrote:
> > > -#if !defined(CONFIG_SWIOTLB) && !defined(CONFIG_INTEL_IOMMU)
> > &g
On Thu, 2019-01-17 at 10:30 +0100, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote:
> > The fact is there is 0 industry interest in using RDMA on platforms
> > that can't do HW DMA cache coherency - the kernel syscalls required
> > to
> > do the cache flushing o
ake all modeset locks
> ~/src/linux master git log --pretty=format:%H
> drivers/gpu/drm/drm_modeset_lock.c | grep
> 08295b3b5beec9aac0f7a9db86f0fc3792039da3
> ~/src/linux master 1
>
>
> BR,
> -R
>
>
> On Tue, Jun 19, 2018 at 4:29 AM Thomas Hellstrom <
&g
On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote:
> On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote:
> > Thomas is correct that the interface you propose here doesn't work
> > at
> > all for GPUs.
> >
> > The kernel driver is not informed of flush/sync, but rather just
> > s
Yue,
Thanks,
Reviewed-by: Thomas Hellstrom
Will include in the next -next pull.
/Thomas
On Wed, 2019-01-16 at 01:55 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c: In function
> 'vmw_hw_surface_
On Tue, 2019-01-15 at 16:20 +0100, h...@lst.de wrote:
> On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote:
> > Yeah, indeed. Bounce buffers are an absolute no-go for GPUs.
> >
> > If the DMA API finds that a piece of memory is not directly
> > accessible by
> > the GPU we need to re
Hi, Christoph,
On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > > Changes since the RFC:
> > > - Rework vmwgfx too [CH]
> > > - Use a distinct type for the DMA page iterator [CH]
> > > - Do not have a #ifdef [CH]
> >
On Tue, 2019-01-08 at 14:12 +0100, h...@lst.de wrote:
> On Tue, Jan 08, 2019 at 09:51:45AM +0000, Thomas Hellstrom wrote:
> > Hi, Christoph,
> >
> > On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> > > Hi Thomas,
> > >
> > > vmwgfx
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> Just use a simple if/else chain to select the DMA mode.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 25 ++---
> 1 file cha
Hi,
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
...
> intel_iommu_enabled is defined as always false for
> !CONFIG_INTEL_IOMMU,
> so remove the ifdefs around it.
>
> Signed-off-by: Christoph Hellwig
> ---
>
> -#if !defined(CONFIG_SWIOTLB) && !defined(CONFIG_INTEL_IOMMU)
> -
Reviewed-by: Thomas Hellstrom
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> intel_iommu_enabled is defined as always false for
> !CONFIG_INTEL_IOMMU,
> so remove the ifdefs around it.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/vmw
Hi, Christoph,
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> Hi Thomas,
>
> vmwgfx has been doing some odd checks based on DMA ops which rely
> on deep DMA mapping layer internals, and I think the changes in
> Linux 4.21 finally broke most of these implicit assumptions.
Thanks.
On Mon, 2018-12-10 at 09:26 +, Colin King wrote:
Reviewed-by: Thomas Hellstrom
I'll take this in the next pull request unless I'm told otherwise.
/Thomas
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message, fix this.
>
> Sign
Commit-ID: e13e2366d8415e029fe96a62502955083e272cef
Gitweb: https://git.kernel.org/tip/e13e2366d8415e029fe96a62502955083e272cef
Author: Thomas Hellstrom
AuthorDate: Mon, 3 Sep 2018 16:07:08 +0200
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 10:05:10 +0200
locking/mutex: Fix
On 06/19/2018 11:45 AM, Peter Zijlstra wrote:
I suspect you want this through the DRM tree? Ingo are you OK with that?
Yes, I can ask Dave to pull this. Ingo?
Thanks,
Thomas
On 06/19/2018 11:44 AM, Peter Zijlstra wrote:
On Tue, Jun 19, 2018 at 10:24:43AM +0200, Thomas Hellstrom wrote:
From: Peter Ziljstra
Make the WW mutex code more readable by adding comments, splitting up
functions and pointing out that we're actually using the Wait-Die
algorithm.
Cc:
On 06/14/2018 03:29 PM, Matthew Wilcox wrote:
On Thu, Jun 14, 2018 at 01:54:15PM +0200, Thomas Hellstrom wrote:
On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard reli
h Triplett
Cc: Thomas Gleixner
Cc: Kate Stewart
Cc: Philippe Ombredanne
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Thomas Hellstrom
---
Documentation/locking/ww-mutex-design.txt | 57 ++
d
simultaneous contending transactions is small.
As the number of simultaneous contending threads increases, Wait-Wound
becomes inferior to Wait-Die, probably due to the larger number of held locks
of sleeping transactions.
Update documentation and callers.
Signed-off-by: Thomas Hellstrom
The algorithm used for linux Wound/Wait mutexes, is actually not Wound/Wait
but Wait/Die. See for example
http://www.mathcs.emory.edu/~cheung/Courses/554/Syllabus/8-recv+serial/deadlock-compare.html
Rather than renaming them across the tree to something like Wait/Die mutexes or
Deadlock Avoidance
For modeset locks we don't expect a high number of contending
transactions so change algorithm from Wait-Die to Wound-Wait.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gp
On 04/27/2018 06:56 PM, Robin Murphy wrote:
Hi Thomas,
On 25/04/18 14:21, Thomas Hellstrom wrote:
Hi, Robin,
Thanks for the patch. It was some time since I put together that
code, but I remember hitting something similar to
https://urldefense.proofpoint.com/v2/url?u=https
Hi, Robin,
Thanks for the patch. It was some time since I put together that code,
but I remember hitting something similar to
https://www.linuxquestions.org/questions/linux-kernel-70/%27nents%27-argument-of-dma_unmap_sg-4175621964/
Even if it's clear from the documentation that orig_nents sho
On 04/05/2018 03:47 PM, Daniel Vetter wrote:
On Thu, Apr 05, 2018 at 01:35:25PM +0200, Thomas Hellstrom wrote:
On 04/05/2018 12:03 PM, Daniel Vetter wrote:
On Thu, Apr 05, 2018 at 11:00:15AM +0200, Thomas Hellstrom wrote:
On 04/05/2018 09:35 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at
On 04/04/2018 11:56 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
On 04/04/2018 10:43 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote:
Hi,
On 04/04/2018 08:58 AM, Daniel Vetter wrote:
On Wed, Apr 4, 2018
On 04/05/2018 12:10 PM, Daniel Vetter wrote:
On Thu, Apr 05, 2018 at 10:49:09AM +0200, Thomas Hellstrom wrote:
On 04/05/2018 09:52 AM, Daniel Vetter wrote:
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
On 04/05/2018 12:03 PM, Daniel Vetter wrote:
On the topic of input validation: Should the kernel check in shared code
that all the clip rects are sensible, i.e. within the dimensions of the
fb? Relying on drivers for that seems like a bad idea.
I guess we could do that.
There seems to be diff
On 04/05/2018 12:03 PM, Daniel Vetter wrote:
On Thu, Apr 05, 2018 at 11:00:15AM +0200, Thomas Hellstrom wrote:
On 04/05/2018 09:35 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote:
From: Lukasz Spintzyk
Optional plane property to mark damaged regions on
On 04/05/2018 09:35 AM, Daniel Vetter wrote:
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
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.
/Thomas
On 04/05/2018 09:52 AM, Daniel Vetter wrote:
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 a
On 04/04/2018 12:28 PM, Thomas Hellstrom wrote:
On 04/04/2018 11:56 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
On 04/04/2018 10:43 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote:
Hi,
On 04/04/2018 08
On 04/04/2018 11:56 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
On 04/04/2018 10:43 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote:
Hi,
On 04/04/2018 08:58 AM, Daniel Vetter wrote:
On Wed, Apr 4, 2018
On 04/04/2018 10:43 AM, Daniel Vetter wrote:
On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote:
Hi,
On 04/04/2018 08:58 AM, Daniel Vetter wrote:
On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark wrote:
Add an atomic helper to implement dirtyfb support. This is needed to
support DSI
Hi,
On 04/04/2018 08:58 AM, Daniel Vetter wrote:
On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark wrote:
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).
To
On 04/03/2018 02:33 PM, Chris Wilson wrote:
Quoting Matthew Wilcox (2018-04-02 15:10:58)
Souptick and I have been auditing the various page fault handler routines
and we've noticed that graphics drivers assume that a signal should be
able to interrupt a page fault. In contrast, the page cache t
On 01/19/2018 01:02 AM, Gustavo A. R. Silva wrote:
Return statements in functions returning bool should use
true/false instead of 1/0.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Thomas Hellström
I'll queue this for 4.17.
Thanks,
Tho
Hi, Stephen,
That would be me.
I've historically only added my signed-off-by:s on commits I've (co-)
authored myself, as the committer info is already registered,
But I take it that's not the correct approach?
/Thomas
On 01/18/2018 09:23 PM, Stephen Rothwell wrote:
Hi all,
Commit
8a51
ck and all sorts of fun memory corruption related crashes.
Fixes: d7721ca71126 "drm/vmwgfx: Connector atomic state"
Cc:
Signed-off-by: Rob Clark
Reviewed-by: Thomas Hellstrom
Thanks, Rob!
/Thomas
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx
On 01/17/2018 07:33 AM, Thomas Hellstrom wrote:
Hi, Woody,
On 01/16/2018 10:39 PM, Woody Suwalski wrote:
Thomas, the same way my DRM patch has disappeared:
Date
Tue, 19 Dec 2017 11:50:57 -0800
From Sinclair Yeh <>
Subject Re: [PATCH v.2] 4.15 vmgfx boot warning
This look
Hi, Woody,
On 01/16/2018 10:39 PM, Woody Suwalski wrote:
Thomas, the same way my DRM patch has disappeared:
Date
Tue, 19 Dec 2017 11:50:57 -0800
From Sinclair Yeh <>
Subject Re: [PATCH v.2] 4.15 vmgfx boot warning
This looks okay to me.
Since this is a core DRM patch I think S
Hi, Arnd,
Sinclair's on paternal leave and I thought this patch was already in
drm-next. My bad.
Dave, is it too late to pull this in for the next merge window?
/Thomas
On 01/16/2018 06:18 PM, Arnd Bergmann wrote:
DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLAN
Hi, Colin,
On 09/12/2017 07:35 PM, Colin King wrote:
From: Colin Ian King
mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space.
How are you hitting this? Multiple mappings should be fine as long as
mapping offsets are
On 08/30/2017 10:30 AM, Daniel Vetter wrote:
On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
On 08/30/2017 07:47 AM, Arvind Yadav wrote:
vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . S
eline_name,
.enable_signaling = vmw_fence_enable_signaling,
Reviewed-by: Thomas Hellstrom
ctl(struct drm_device *dev, void
*data,
ttm_read_unlock(&dev_priv->reservation_sem);
out_no_ttm_lock:
- drm_framebuffer_unreference(fb);
+ drm_framebuffer_put(fb);
out_no_fb:
drm_modeset_unlock_all(dev);
out_no_copy:
Apart from the above,
Reviewed-by: Thomas Hell
On 04/04/2017 11:41 AM, Michal Hocko wrote:
> On Thu 30-03-17 17:48:39, Andrey Ryabinin wrote:
>> From: Andrey Ryabinin
>> Subject: mm/vmalloc: allow to call vfree() in atomic context fix
>>
>> Don't spawn worker if we already purging.
>>
>> Signed-off-by: Andrey Ryabinin
> I would rather put thi
On 03/30/2017 04:48 PM, Andrey Ryabinin wrote:
> On 03/30/2017 03:00 PM, Thomas Hellstrom wrote:
>
>>>
>>> if (unlikely(nr_lazy > lazy_max_pages()))
>>> - try_purge_vmap_area_lazy();
>> Perhaps a slight optimization would be to schedule
On 03/30/2017 12:27 PM, Andrey Ryabinin wrote:
> Commit 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem
> as potentially sleeping") added might_sleep() to remove_vm_area() from
> vfree(), and commit 763b218ddfaf ("mm: add preempt points into
> __purge_vmap_area_lazy()") actually made v
: KrishnamRaju raju
Signed-off-by: Thomas Hellstrom
---
Documentation/kref.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/kref.txt b/Documentation/kref.txt
index ddf85a5..d26a27c 100644
--- a/Documentation/kref.txt
+++ b/Documentation/kref.txt
@@ -84,6 +84,7 @@ int my_data_handler
On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes
On 02/21/2017 06:34 AM, David Airlie wrote:
>> No.
>>
>> IMO Not fixing this immediately through stable is out of the question.
>> The deal is that we don't break userspace.
>> Having said that, I'm not against a long term vmwgfx-only solution. But
>> let's fix this now.
>>
>> Admittedly we missed
ease cycles of
open-vm-tools the open-vm-tools version was just about to be released.
It's necessary for non-xorg
/Thomas
On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom wrote:
>> So I think we need a quick revert of this commit o
So I think we need a quick revert of this commit or a quick stable
follow-up to unbreak things on our side.
/Thomas
On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
> Hi!
>
> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
> node to tell DRM about the mo
On 01/27/2017 03:29 AM, Michel Dänzer wrote:
> On 26/01/17 09:46 AM, Sinclair Yeh wrote:
>> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
>>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
>>>> On 01/25/2017 09:21 AM, Michel Dänzer wr
gt;
> BUG_ON(ttm->caching_state != tt_cached);
>
> in ttm_tt_swapout.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michel Dänzer
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
For the vmwgfx part:
Acked-by: Thomas Hellstrom
On 11/05/2016 08:33 AM, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the return
Li,
IIRC This one goes hand in hand with a vmwgfx (the only user) patch.
Please don't apply until I've figured out whether that patch is also in 3.4.
Thanks,
Thomas
On 10/12/2016 02:33 PM, l...@kernel.org wrote:
> From: Thomas Hellstrom
>
> 3.4.113-rc1 review patch.
ason
>
> On Mon, Feb 1, 2016 at 10:53 PM, Jason A. Donenfeld wrote:
>> This was positively reviewed but never picked up. Can someone queue
>> this for rc3?
>>
>> Thanks,
>> Jason
>>
>> On Sun, Oct 11, 2015 at 9:59 PM, Thomas Hellstrom
>> wrote:
Hi!
IMO we shouldn't have maintainer info mentioned in the source files,
since the information is redundant and moreover if we change maintainer
a patch touching multiple files would just look odd, and we'd leave a
lot of stale info in older kernels.
Having the linux git *master* MAINTAINERS file
tch, and perhaps even test
>>>> it?
>>> Test? Nope. Seems obviously correct.
>> This warning still shows up when building v4.7-rc3 for 32 bits x86.
>>
>> Since my previous message an entry for this driver showed up in
>> MAINTAINERS. So I'd guess Sinclair, Thomas, etc want me to resend this
>> small patch. Is that correct?
> Sounds more like maintainers asleep at the helm ;-)
>
> I've applied this to drm-misc, Sinclair can apply polish later on if he
> wants to.
>
> Thanks, Daniel
Thanks for applying this.
FWIW,
Reviewed-by: Thomas Hellstrom
/Thomas
On 06/08/2016 08:13 AM, Shrikrishna Khare wrote:
> The device emulation may send segCnt of 1 for LRO packets.
>
> Signed-off-by: Shrikrishna Khare
> Signed-off-by: Jin Heo
>
> ---
> v2: fix subject line
> ---
> drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
> drivers/net/vmxnet3/vmxnet3_int.h | 4 ++-
On 12/24/2015 04:37 PM, Ben Hutchings wrote:
> 3.2.75-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Thomas Hellstrom
>
> commit a0af2e538c80f3e47f1d6ddf120a153ad909e8ad upstream.
>
> A client calling drmSetMaste
On 12/14/2015 02:12 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
>
> between commit:
>
> 8fbf9d92a7bc ("drm/vmwg
On 12/02/2015 06:26 PM, Dmitry Torokhov wrote:
> On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
>> On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
>>> On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
On Tue, Dec 01, 2015 at 02:54:20PM -0800
On 12/02/2015 01:04 AM, Greg Kroah-Hartman wrote:
> On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
>> Hi,
>>
>> On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
>>> On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh wrote:
Hi,
>>
>>
>> */
>> -#define V
Thanks for reporting!
This fix was already reported by Dan Carpenter and has already been
queued in vmwgfx-fixes-4.4
/Thomas
On 11/25/2015 02:12 PM, Geliang Tang wrote:
> WARN_ON() takes a condition rather than a format string. This patch
> converted WARN_ON() to WARN() instead.
>
> Signed-off-
Kamal,
On 10/27/2015 10:29 PM, Kamal Mostafa wrote:
> 3.19.8-ckt9 -stable review patch. If anyone has any objections, please let
> me know.
>
> --
>
> From: Thomas Hellstrom
>
> commit 54c12bc374408faddbff75dbf1a6167c19af39c4 upstream.
>
Unfortuna
Dan,
On 10/19/2015 11:34 PM, Williams, Dan J wrote:
> On Tue, 2015-10-13 at 20:52 +0200, Thomas Hellstrom wrote:
>>> Ok, I'll make local read_fifo() and write_fifo() macros to make this
>>> explicit. Are these names ok with you?
>> Sure.
>>
> So I ended
On 10/13/2015 08:48 PM, Dan Williams wrote:
> On Tue, Oct 13, 2015 at 11:37 AM, Thomas Hellstrom
> wrote:
>> On 10/13/2015 06:35 PM, Dan Williams wrote:
>>> On Mon, Oct 12, 2015 at 10:18 PM, Thomas Hellstrom
>>> wrote:
>>>> Hi!
>>>>
>
On 10/13/2015 06:35 PM, Dan Williams wrote:
> On Mon, Oct 12, 2015 at 10:18 PM, Thomas Hellstrom
> wrote:
>> Hi!
>>
>> On 10/13/2015 12:35 AM, Dan Williams wrote:
>>> Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
>>
Hi!
On 10/13/2015 12:35 AM, Dan Williams wrote:
> Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
> expects the fifo registers to be cacheable. In preparation for
> deprecating ioremap_cache() convert its usage in vmwgfx to memremap().
>
> Cc: D
Reviewed-by: Thomas Hellstrom
On 10/10/2015 12:56 PM, Jason A. Donenfeld wrote:
> On most platforms, there exists this ifdef:
>
> #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
>
> This makes this patch functionally useless. However, on PPC, there is
> ac
.0.3 build-1895310, on Windows 7
> 64-bit.
> Guest is Fedora 21.
>
> --- Original Message ---
> Sender : Thomas Hellstrom
> Date : 2014-12-17 00:12 (GMT+09:00)
> Title : Re: [3.18+] Can't boot with commit bd809af1 ("x86: Enable PAT to use
> cache mode transla
Jongman, what product (player, ws, esx) and version are you using?
Thanks,
Thomas
On 12/16/2014 02:08 PM, Peter Hurley wrote:
> VMware guys probably already know this but just in case
>
> [ +cc Thomas Hellstrom ]
>
> Jongman - you need to fix your mailer to use plaintext and not
On 12/16/2014 07:18 AM, Thomas Hellstrom wrote:
> On 12/16/2014 01:35 AM, Linus Torvalds wrote:
>> On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>>> i915:
>>> Initial Skylake (SKL) support
>>> gen3/4 reset work
>>> st
On 12/16/2014 01:35 AM, Linus Torvalds wrote:
> On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>> i915:
>> Initial Skylake (SKL) support
>> gen3/4 reset work
>> start of dri1/ums removal
>> infoframe tracking
>> fixes for lots of things.
> So I'm not s
Hi!
Thanks for forwarding. There is a bug on redhat bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1155825
that might be related, but from what I can tell, the possible deadlock
reported there is only hypothetical.
/Thomas
On 10/24/2014 06:13 PM, Dmitry Torokhov wrote:
> Hi Steve,
>
> O
On 09/26/2014 02:28 PM, Rob Clark wrote:
> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
> wrote:
>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
>>> On Fri, 26 Sep 2014 09:15:57 +0200
>>> Thomas Hellstrom wrote:
>>>
>>>> On 09/26/2014 01:5
1 - 100 of 203 matches
Mail list logo
