Op 26-02-16 om 19:31 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
> v2: check if flags are valid (zero, in this case)
>
> Signed-
Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer allocation. In the new approach the ioctl needs to be called
> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
Op 04-02-16 om 14:05 schreef Gustavo Padovan:
> 2016-02-04 Maarten Lankhorst :
>
>> Op 03-02-16 om 21:09 schreef Gustavo Padovan:
>>> Hi Maarten,
>>>
>>> 2016-02-03 Maarten Lankhorst :
>>>
>>>> Op 03-02-16 om 14:25 schreef Gu
Op 03-02-16 om 21:09 schreef Gustavo Padovan:
> Hi Maarten,
>
> 2016-02-03 Maarten Lankhorst :
>
>> Op 03-02-16 om 14:25 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> Turn sync_fence_info into __u64 type enable us to extend the stru
Op 03-02-16 om 14:25 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Turn sync_fence_info into __u64 type enable us to extend the struct in the
> future without breaking the ABI.
>
> v2: use type __u64 for fence_info
>
> v3: fix commit message to reflect the v2 change
>
> Signed-off-by: Gusta
Op 02-02-16 om 21:28 schreef Gustavo Padovan:
> Hi Maarten,
>
> 2016-02-02 Maarten Lankhorst :
>
>> Op 02-02-16 om 14:23 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> Making fence_info a pointer enables us to extend the struct in the fu
Op 02-02-16 om 14:23 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> As struct sync_pt doesn't exist anymore it is a good idea remove any
> reference to it in the sync_framework. sync_pts were replaced directly by
> fences.
>
rename it to sync_fence_info to prevent polluting the global namesp
Op 02-02-16 om 14:23 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> The len member of struct sync_file_info was returning the size of the whole
> buffer (struct sync_file_info + fence_infos at the of it). This commit
> change it to return only the size of the array of fence_infos.
>
> It als
Op 02-02-16 om 14:23 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Making fence_info a pointer enables us to extend the struct in the future
> without breaking the ABI.
>
> v2: use type __u64 for fence_info
> Signed-off-by: Gustavo Padovan
> ---
> drivers/staging/android/sync.c | 2 +
Op 29-01-16 om 22:20 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Making fence_info a pointer enables us to extend the struct in the future
> without breaking the ABI.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/staging/android/sync.c | 2 +-
> drivers/staging/android/uapi/sy
Op 29-01-16 om 22:20 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
This only helps if you reject flags != 0 in the ioctl, else whe
Hey,
Op 27-01-16 om 14:30 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
> Signed-off-by: Gustavo Padovan
>
Is there a value in keeping the abi unchanged?
If not, then Document
Op 26-01-16 om 15:48 schreef Russell King - ARM Linux:
> On Tue, Jan 26, 2016 at 03:28:34PM +0100, Maarten Lankhorst wrote:
>> Something similar to a segfault. It's trying to call 0x6b6b6b6b6b which
>> is POISON_FREE.
>>
>> mc appears to be freed already, so c
Op 26-01-16 om 15:15 schreef Russell King - ARM Linux:
> On Tue, Jan 26, 2016 at 02:42:16PM +0100, Maarten Lankhorst wrote:
>> Commit ce657b1cddf1f88c56 ("component: add support for releasing match
>> data") causes a general protection fault when unloading snd-hda-inte
Hey,
Commit ce657b1cddf1f88c56 ("component: add support for releasing match data")
causes
a general protection fault when unloading snd-hda-intel with the i915 module
loaded
on a recent skylake machine.
This breaks one of the i915 acceptance tests that performs a module
unload/reload on
snd-hd
e_signal at destroy
> phase
> staging/android: remove sync_fence_create_dma()
>
For whole series:
Reviewed-by: Maarten Lankhorst
Renaming sync_fence to sync_file makes sense, it should hopefully reduce
confusion.
Op 20-01-16 om 15:32 schreef Gustavo Padovan:
> 2016-01-20 Maarten Lankhorst :
>
>> Hey,
>>
>> Op 15-01-16 om 15:55 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> This patch series de-stage the sync framework, and in order to accomp
Op 15-12-15 om 18:19 schreef Dmitry Torokhov:
> On Tue, Dec 15, 2015 at 2:01 AM, Maarten Lankhorst
> wrote:
>> Op 15-12-15 om 02:29 schreef Dmitry Torokhov:
>>> Userspace can close the sync device while there are still active fence
>>> points, in which case kernel
Op 15-12-15 om 02:29 schreef Dmitry Torokhov:
> Userspace can close the sync device while there are still active fence
> points, in which case kernel produces the following warning:
>
> [ 43.853176] [ cut here ]
> [ 43.857834] WARNING: CPU: 0 PID: 892 at
> /mnt/host/sou
Op 08-09-15 om 01:42 schreef Stephen Rothwell:
> Hi all,
>
> On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell
> wrote:
>> After merging the drm-misc tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
>> 'mdp
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 85ac6d85dc39..30e0f54ba19d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6315,9 +6315,6 @@ static void intel_crtc_d
Op 13-07-15 om 14:51 schreef Sergey Senozhatsky:
> 4.2.0-rc2-next-20150713
>
> [ 1239.783862] [ cut here ]
> [ 1239.783892] WARNING: CPU: 0 PID: 364 at
> drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]()
> [ 1239.783894] WARN_ON(new->frontbuffer_bit
Op 13-07-15 om 09:42 schreef Jörg Otte:
> 2015-07-13 9:23 GMT+02:00 Maarten Lankhorst
> :
>> Op 13-07-15 om 08:22 schreef Daniel Vetter:
>>> On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote:
>>>> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte wrote:
&
code is already completely changed in -next again, so any testing done on
> integration trees (like -next or drm-intel-nightly) won't test any patches
> for 4.2.
> -Daniel
>
> Oh and Signed-off-by: Daniel Vetter in case you
> decide to apply this right away.
>
Well your version has the benefit of compiling without errors. :-)
Reviewed-by: Maarten Lankhorst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Op 12-07-15 om 18:52 schreef Linus Torvalds:
> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte wrote:
>> BUG: unable to handle kernel NULL pointer dereference at 0009
>> IP: [] 0xbd3447bb
> Ugh. Please enable KALLSYMS to get sane symbols.
>
> But yes, "crtc_state->base.active" is at
Hey,
Op 15-06-15 om 08:58 schreef Huang Ying:
> FYI, we noticed the below changes on
>
> git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
> commit 7f072451f2d3d53e4f6939440e15ab36afed2051 ("drm/i915: Implement
> intel_crtc_control using atomic state, v4")
>
> Test Environment check:
Hey,
Op 10-03-15 om 16:28 schreef Peter Zijlstra:
> On Tue, Mar 10, 2015 at 03:10:46PM +0100, Maarten Lankhorst wrote:
>> Op 10-03-15 om 13:37 schreef Peter Zijlstra:
>
>>> So IIRC this is the function that checks who gets wounded (and gets to
>>> do the whole retry
Op 10-03-15 om 13:37 schreef Peter Zijlstra:
> On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
>> +static int __sched __mutex_lock_check_stamp(struct rt_mutex *lock,
>> +struct ww_acquire_ctx *ctx)
>> +{
>> +#ifdef CONFIG_WW_MUTEX_R
On 06-03-15 13:14, Sebastian Andrzej Siewior wrote:
> On 03/02/2015 09:46 AM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 02-03-15 om 04:20 schreef Mike Galbraith:
>>> On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
>>>> This patch make
Hey,
Op 02-03-15 om 04:20 schreef Mike Galbraith:
> On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
>> This patch makes it possible to replace the base mutex by a rt_mutex. In
>> general one would not do this.
> I would argue that the thing should be born as a full fledged prim
Assuming it's compile tested, can't really test that here. :)
Reviewed-by: Maarten Lankhorst
I can't review the second or third patch, I don't understand rt mutexes well
enough.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
max_segment_count = (unsigned int)-1;
> + cons->max_segment_size = (unsigned int)-1;
> + cons->segment_boundary_mask = (unsigned long)-1;
> +}
Use DMA_SEGMENTS_MAX_SEG_COUNT or UINT/ULONG_MAX here instead?
Patches look sane,
Reviewed-By: Maarten Lankhorst
> +/*
> + * calc_cons
Op 28-01-15 om 13:54 schreef Sumit Semwal:
> At present, dma_buf_export() takes a series of parameters, which
> makes it difficult to add any new parameters for exporters, if required.
>
> Make it simpler by moving all these parameters into a struct, and pass
> the struct * as parameter to dma_buf_
Op 06-01-15 om 23:21 schreef David Miller:
> From: Maarten Lankhorst
> Date: Mon, 05 Jan 2015 14:52:06 +0100
>
>> This fixes a deadlock with alx_link_check, which takes the rtnl_mutex in
>> a work item to check the link.
>>
>> I have no idea whether alx should be
This fixes a deadlock with alx_link_check, which takes the rtnl_mutex in
a work item to check the link.
I have no idea whether alx should be fixed or ipconfig.c,
but this saves 120 seconds off my boot time. ;-)
Signed-off-by: Maarten Lankhorst
---
diff --git a/net/ipv4/ipconfig.c b/net/ipv4
Hey,
Op 27-11-14 om 02:18 schreef Tobias Klausmann:
>
>
> On 26.11.2014 21:29, Michael Marineau wrote:
>> On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst
>> wrote:
>>> Hey,
>>>
>>> Op 22-11-14 om 21:16 schreef Michael Marineau:
>>
Hey,
Op 22-11-14 om 21:16 schreef Michael Marineau:
> On Nov 22, 2014 11:45 AM, "Michael Marineau" wrote:
>>
>> On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" <
> maarten.lankho...@canonical.com> wrote:
>>> Hey,
>>>
>>> Op 22-1
Hey,
Op 22-11-14 om 01:19 schreef Michael Marineau:
> On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst
> wrote:
>> Op 20-11-14 om 05:06 schreef Michael Marineau:
>>> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
>>> wrote:
>>>> Hey,
>>&
Op 20-11-14 om 05:06 schreef Michael Marineau:
> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> On 19-11-14 07:43, Michael Marineau wrote:
>>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>>> lockups
Op 20-11-14 om 00:08 schreef Tobias Klausmann:
> On 19.11.2014 09:10, Maarten Lankhorst wrote:
>> ...
>> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>>
>> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>>
>>
Hey,
On 19-11-14 07:43, Michael Marineau wrote:
> On 3.18-rc kernel's I have been intermittently experiencing GPU
> lockups shortly after startup, accompanied with one or both of the
> following errors:
>
> nouveau E[ PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
> from PBDMA0/HOST_CPU
Hey,
Op 10-11-14 om 12:01 schreef Jani Nikula:
> On Sat, 08 Nov 2014, Rob Clark wrote:
>> Let's make things a bit easier to debug when things go bad (potentially
>> under console_lock).
>>
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/drm_irq.c | 3 ++-
>> 1 file changed, 2 insertions(+
Op 25-09-14 om 23:10 schreef Peter Hurley:
> On 09/25/2014 04:33 PM, Alex Deucher wrote:
>> On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley
>> wrote:
>>> After several days uptime with a 3.16 kernel (generally running
>>> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
>>> deskto
Hey,
On 25-09-14 20:55, Peter Hurley wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
>
> Mostly the slowdowns are associated with gpu
Hey,
Op 23-09-14 om 15:18 schreef Matt Fleming:
> On Tue, 23 Sep, at 10:18:07AM, Ard Biesheuvel wrote:
>> It will be difficult for me to keep up with this thread over the next
>> days, so I have added Leif and Roy on cc. If you need to make any
>> changes that affect arm64, they should be able to
Hey,
Op 08-09-14 om 14:55 schreef Ard Biesheuvel:
> On 5 September 2014 22:27, Matt Fleming wrote:
>> On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
>>> Thanks Ard, I'll take a look in the morning.
>> Maarten, could you try out this patch?
>>
> Any developments regarding this patch?
> I tried
Op 04-09-14 om 13:19 schreef Ard Biesheuvel:
>
>> On 4 sep. 2014, at 12:48, Maarten Lankhorst
>> wrote:
>>
>> Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
>>> On 3 September 2014 19:59, Matt Fleming wrote:
>>>> On Wed, 03 Sep, at 05:37:2
Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
> On 3 September 2014 19:59, Matt Fleming wrote:
>> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
>>> Will do, thanks.
>>>
>>> @Matt: so there is two ways to fix this, the patch above addressing
>>> this single instance, and alternatively, adding
Op 04-09-14 om 09:40 schreef Matt Fleming:
> On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote:
>> So how about we:
>> - add ASSERT(_got == _egot, "GOT entries not supported in
>> boot/compressed") to the linker script
>> - #define __nogotentry __attribute__((visibility(hidden))) somewhere
>> in
Hey,
Op 03-09-14 om 14:18 schreef Ard Biesheuvel:
> Could you please try adding the visibility attribute lik this instead?
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 044a2fd3c5fe..8725d85f1903 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/
Op 03-09-14 om 08:06 schreef Ard Biesheuvel:
> On 2 September 2014 21:29, Matt Fleming wrote:
>> On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> My macbook pro 8.2 fails to do a efi stub boot with these patches.
>>>
>>>
Hey,
My macbook pro 8.2 fails to do a efi stub boot with these patches.
Commit f23cf8bd5c1f49 "efi/x86: efistub: Move shared dependencies to
"
causes the first break, but this can be averted by changing
struct efi_config *efi_early;
to
struct efi_config *efi_early __attribute__((visibility("h
According to the documentation sync_fence_create takes ownership of the point,
not a reference on the point.
This fixes a memory leak introduced in 3.17's android fence rework.
Signed-off-by: Maarten Lankhorst
Cc: Colin Cross
Cc: Dan Carpenter
---
drivers/staging/android/sync.c | 1 -
1
Hey,
Op 28-08-14 om 13:57 schreef Dan Carpenter:
> On Thu, Aug 28, 2014 at 08:54:05AM +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> On 15-08-14 08:46, Greg Kroah-Hartman wrote:
>>> On Thu, Aug 14, 2014 at 11:54:52AM +0200, Maarten Lankhorst wrote:
>>>> T
Hey,
On 15-08-14 08:46, Greg Kroah-Hartman wrote:
> On Thu, Aug 14, 2014 at 11:54:52AM +0200, Maarten Lankhorst wrote:
>> This allows users of dma fences to create a android fence.
>
> Who is going to use these functions? I need an in-kernel user before I
> can add new api ca
Acked-by: Maarten Lankhorst
On 27-08-14 17:19, Rob Clark wrote:
> We really don't want distro's enabling this in their kernels. Try and
> make that more clear.
>
> Signed-off-by: Rob Clark
> ---
> lib/Kconfig.debug | 4
> 1 file changed, 4 inse
Hey,
Op 18-08-14 om 14:57 schreef Dan Carpenter:
> On Thu, Aug 14, 2014 at 11:53:38AM +0200, Maarten Lankhorst wrote:
>> According to the documentation sync_fence_create takes ownership of the
>> point,
>> not a reference on the point.
>>
> What are the user v
This allows users of dma fences to create a android fence.
Signed-off-by: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jesse Barnes
---
drivers/staging/android/sync.c | 24
drivers/staging/android/sync.h | 11 +++
2 files changed, 31 insertions(+), 4 deletions
According to the documentation sync_fence_create takes ownership of the point,
not a reference on the point.
Signed-off-by: Maarten Lankhorst
Cc: Colin Cross
---
drivers/staging/android/sync.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging
op 05-08-14 16:41, Peter Zijlstra schreef:
> On Tue, Aug 05, 2014 at 08:07:28AM -0600, Shuah Khan wrote:
>> On Tue, Aug 5, 2014 at 7:28 AM, Peter Zijlstra wrote:
>>
>>> Maybe I wasn't clear; but I meant you should extend the lock tests to
>>> cover the full qrwlock semantics.
>>>
>>> That means we
op 04-08-14 19:04, Christian König schreef:
> Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst:
>> op 04-08-14 17:04, Christian König schreef:
>>> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
>>>> op 04-08-14 16:45, Christian König schreef:
>>>&g
op 04-08-14 17:04, Christian König schreef:
> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
>> op 04-08-14 16:45, Christian König schreef:
>>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
>>>> op 04-08-14 16:37, Christian König schreef:
>>>>>&
op 04-08-14 16:45, Christian König schreef:
> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
>> op 04-08-14 16:37, Christian König schreef:
>>>> It'a pain to deal with gpu reset.
>>> Yeah, well that's nothing new.
>>>
>>>> I've
op 04-08-14 16:37, Christian König schreef:
>> It'a pain to deal with gpu reset.
>
> Yeah, well that's nothing new.
>
>> I've now tried other solutions but that would mean reverting to the old
>> style during gpu lockup recovery, and only running the delayed work when
>> !lockup.
>> But this mean
Hey,
op 04-08-14 13:57, Christian König schreef:
> Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
>> op 04-08-14 10:36, Christian König schreef:
>>> Hi Maarten,
>>>
>>> Sorry for the delay. I've got way to much todo recently.
>>>
>>> A
op 04-08-14 10:36, Christian König schreef:
> Hi Maarten,
>
> Sorry for the delay. I've got way to much todo recently.
>
> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>>
>> On 01-08-14 18:35, Christian König wrote:
>>> Am 31.07.2014 um 17:33 schr
On 01-08-14 18:35, Christian König wrote:
> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
>> allowing radeon_fence_driver_check_lockup to take exclusive_
This is the last remaining function that doesn't use the reservation
lock completely to fence off access to a buffer.
---
drivers/gpu/drm/ttm/ttm_bo.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/tt
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_fence.c | 50 -
1 file changed, 30 insertions(+), 20 deletions
op 31-07-14 17:30, Maarten Lankhorst schreef:
> This series applies on top of the driver-core-next branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
>
> Before converting ttm to the new fence interface I had to fix some
> drivers to require a res
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 76 +++---
1 file changed, 13 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9d36cffad3b7..d119ae4419d4 100644
--- a/drivers
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index f0a689ba9685..a43930162eb6 100644
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon_gem.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d09650c1d720..7ba883843668 100644
--- a/drivers/gpu
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +---
drivers/gpu/drm/nouveau/nouveau_fence.h |2
drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++-
drivers/gpu/drm/qxl/qxl_debugfs.c|6 +
drivers/gpu/drm/qxl/qxl_drv
Final driver! \o/
This is not a proper dma_fence because the hardware may never signal
anything, so don't use dma-buf with qxl, ever.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/Makefile |2
drivers/gpu/drm/qxl/qxl_cmd.c |5 -
drivers/gpu/drm/qxl/qxl_debu
Only one type was ever used. This is needed to simplify the fence
support in the next commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 299 ++
drivers/gpu/drm/vmwgfx/vmwgfx_fence.h| 29 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 -
4 files changed, 200
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/core/event.c |4
drivers/gpu/drm/nouveau/nouveau_bo.c |6
drivers/gpu/drm/nouveau/nouveau_display.c |4
drivers/gpu/drm/nouveau/nouveau_fence.c | 435
No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++---
drivers/gpu/drm/nouveau/nouveau_display.c |6
This will ensure we always hold the required lock when calling those functions.
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 17 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouve
This reorders the list to keep track of what buffers are reserved,
so previous members are always unreserved.
This gets rid of some bookkeeping that's no longer needed,
while simplifying the code some.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c |
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
After the switch to rcu the reservation lock will be
removed again.
Signed-off-by: Maarten Lankhorst
It seems some drivers really want this as a parameter,
like vmwgfx.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c|2 +-
drivers/gpu/drm/radeon/radeon_object.c |2 +-
drivers/gpu/drm/radeon/radeon_uvd.c |2 +-
drivers/gpu/drm/radeon/radeon_vm.c
on the global fence_queue to pick up gpu resets.
- Process all fences in radeon_gpu_reset after reset to close a race
with the trylock in enable_signaling.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h | 18 +-
drivers/gpu/drm/radeon/radeon_device.c | 22
Signed-off-by: Maarten Lankhorst
---
V1 had a nasty bug breaking gpu lockup recovery. The fix is not
allowing radeon_fence_driver_check_lockup to take exclusive_lock,
and kill it during lockup recovery instead.
---
drivers/gpu/drm/radeon/radeon.h|3 +
drivers/gpu/drm/radeon
fence_is_signaled callback should support being run in
atomic context, but not in irq context.
Signed-off-by: Maarten Lankhorst
---
include/linux/fence.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
ade things easier for me.
- Added a delayed work for radeon that checks gpu lockups.
- Reworked the radeon fence implementation to remove deadlocks,
and end up slightly cleaner.
---
Maarten Lankhorst (18):
fence: add debugging lines to fence_is_signaled for the callback
dr
fence_is_signaled callback should support being run in
atomic context, but not in irq context.
Signed-off-by: Maarten Lankhorst
---
include/linux/fence.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
op 23-07-14 15:16, Maarten Lankhorst schreef:
> op 23-07-14 14:36, Christian König schreef:
>> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 12:13 PM, Christian König
>>> wrote:
>>>>> And the dma-buf would still have fences bel
op 23-07-14 14:36, Christian König schreef:
> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 12:13 PM, Christian König
>> wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
>>>
>>> Calling fro
op 23-07-14 11:47, Christian König schreef:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>> wrote:
>>> The scheduler needs to keep track of a lot of fences, so I think we'll
>>> have to register callbacks, not a simple wait function. We must kee
op 23-07-14 11:36, Christian König schreef:
> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:27 AM, Christian König
>> wrote:
>>> You submit a job to the hardware and then block the job to wait for radeon
>>> to be finished? Well than this would indeed require a hardware
op 23-07-14 10:20, Christian König schreef:
> Am 23.07.2014 10:07, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:58 AM, Christian König
>> wrote:
>>> Just imagine an application using prime is locking up Radeon and because of
>>> that gets killed by the user. Nothing else in the system would
op 23-07-14 09:37, Christian König schreef:
> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:26 AM, Christian König
>> wrote:
>>> It's not a locking problem I'm talking about here. Radeons lockup handling
>>> kicks in when anything calls into the driver from the outside,
op 23-07-14 09:15, Christian König schreef:
> Am 23.07.2014 09:09, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
>> wrote:
>>>> Can we somehow avoid the need to call fence_signal() at all? The
>>>> interrupts at least on
op 23-07-14 08:52, Christian König schreef:
> Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
>> op 22-07-14 17:59, Christian König schreef:
>>> Am 22.07.2014 17:42, schrieb Daniel Vetter:
>>>> On Tue, Jul 22, 2014 at 5:35 PM, Christian König
>>>> wro
op 22-07-14 17:59, Christian König schreef:
> Am 22.07.2014 17:42, schrieb Daniel Vetter:
>> On Tue, Jul 22, 2014 at 5:35 PM, Christian König
>> wrote:
>>> Drivers exporting fences need to provide a fence->signaled and a fence->wait
>>> function, everything else like fence->enable_signaling or cal
Hey,
op 22-07-14 17:02, Christian König schreef:
> Am 22.07.2014 16:44, schrieb Maarten Lankhorst:
>> op 22-07-14 15:45, Christian König schreef:
>>> Am 22.07.2014 15:26, schrieb Daniel Vetter:
>>>> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian König wr
op 22-07-14 16:39, Christian König schreef:
> Am 22.07.2014 16:27, schrieb Maarten Lankhorst:
>> op 22-07-14 16:24, Christian König schreef:
>>>> No, you really shouldn't be doing much in the check anyway, it's meant to
>>>> be a lightweight check.
101 - 200 of 528 matches
Mail list logo
