op 11-04-14 12:11, Thomas Hellstrom schreef:
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of locking inconsistencies.
First, it seems you're use a number of pointers as RCU pointers wi
op 11-04-14 21:30, Thomas Hellstrom schreef:
Hi!
On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
op 11-04-14 12:11, Thomas Hellstrom schreef:
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of
op 11-04-14 21:35, Thomas Hellstrom schreef:
On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
op 11-04-14 12:11, Thomas Hellstrom schreef:
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of locking
allback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.
v5:
- Fix small style issues pointed out by Thomas Hellstrom.
Signed-off-by: Maarten Lankhorst
Acked-by: John Stultz
---
ttm, and
make dealing with rcu less painful.
Patches slightly updated to fix compilation with armada and
new atomic primitives, but otherwise identical.
---
Maarten Lankhorst (8):
fence: dma-buf cross-device synchronization (v17)
seqno-fence: Hardware dma-buf implementation of fencing
.
reservation_object_test_signaled_rcu() will test if all fences of the
reservation_object are signaled without using the ww_mutex.
reservation_object_get_excl() is added because touching the fence_excl
member directly will trigger a sparse warning.
Signed-off-by: Maarten Lankhorst
Reviewed-By: Thomas
This allows reservation objects to be used in dma-buf. it's required
for implementing polling support on the fences that belong to a dma-buf.
Signed-off-by: Maarten Lankhorst
Acked-by: Mauro Carvalho Chehab #drivers/media/v4l2-core/
Acked-by: Thomas Hellstrom #drivers/gpu/drm/ttm
Signed-o
.
reservation_object_add_shared_fence() and
reservation_object_add_excl_fence() are used to assign a new
fence to a reservation_object pointer, to complete a reservation.
Signed-off-by: Maarten Lankhorst
Changes since v1:
- Add reservation_object_get_excl, reorder code a bit.
---
drivers/base/dma-buf.c | 35
Thanks to Fengguang Wu for spotting a missing static cast.
v2:
- Kill unused variable need_shared.
v3:
- Clarify the BUG() in dma_buf_release some more. (Rob Clark)
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-buf.c | 108 +++
include
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark
---
include/linux/reservation.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..f3f57460a205 100644
--- a/include
nce.h
v4: Add spinlock pointer to seqno_fence_init
v5: Add condition member to allow wait for != 0.
Fix small style errors pointed out by checkpatch.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark #v4
---
Documentation/DocBook/device-drivers.tmpl |1
drivers
r discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I remov
op 19-06-14 17:22, Colin Cross schreef:
> On Wed, Jun 18, 2014 at 11:37 PM, Daniel Vetter wrote:
>> On Wed, Jun 18, 2014 at 06:15:56PM -0700, Greg KH wrote:
>>> On Wed, Jun 18, 2014 at 12:37:11PM +0200, Maarten Lankhorst wrote:
>>>> Just to show it's easy.
nce.h
v4: Add spinlock pointer to seqno_fence_init
v5: Add condition member to allow wait for != 0.
Fix small style errors pointed out by checkpatch.
v6: Move to a separate file. Fix up api changes in fences.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark #v4
---
Documentation/D
allback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.
v5:
- Fix small style issues pointed out by Thomas Hellstrom.
v6:
- Fix for updates to fence api.
Signed-off-by: Maarten Lank
Signed-off-by: Maarten Lankhorst
---
Documentation/DocBook/device-drivers.tmpl |3
MAINTAINERS |4
drivers/Makefile |1
drivers/base/Makefile |1
drivers/base/dma-buf.c| 743
Thanks to Fengguang Wu for spotting a missing static cast.
v2:
- Kill unused variable need_shared.
v3:
- Clarify the BUG() in dma_buf_release some more. (Rob Clark)
Signed-off-by: Maarten Lankhorst
---
drivers/dma-buf/dma-buf.c | 108 +
include
at it yet
I feel it should stay in staging, for now.
---
Maarten Lankhorst (9):
dma-buf: move to drivers/dma-buf
fence: dma-buf cross-device synchronization (v18)
seqno-fence: Hardware dma-buf implementation of fencing (v6)
dma-buf: use reservation objects
android: co
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark
---
include/linux/reservation.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..f3f57460a205 100644
--- a/include
is needed,
rcu_dereference followed by fence_get_rcu can be used, if the shared
fences are needed it's recommended to use the supplied functions.
Signed-off-by: Maarten Lankhorst
Reviewed-By: Thomas Hellstrom
---
drivers/dma-buf/dma-buf.c | 47 --
drivers/dma-buf/fence.c |
This allows reservation objects to be used in dma-buf. it's required
for implementing polling support on the fences that belong to a dma-buf.
Signed-off-by: Maarten Lankhorst
Acked-by: Mauro Carvalho Chehab #drivers/media/v4l2-core/
Acked-by: Thomas Hellstrom #drivers/gpu/drm/ttm
Signed-o
.
reservation_object_add_shared_fence() and
reservation_object_add_excl_fence() are used to assign a new
fence to a reservation_object pointer, to complete a reservation.
Signed-off-by: Maarten Lankhorst
Changes since v1:
- Add reservation_object_get_excl, reorder code a bit.
---
Documentation/DocBook/device-drivers.tmpl |1
r discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I remov
op 01-07-14 13:06, Arend van Spriel schreef:
> On 01-07-14 12:57, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
> It would help to use '-M' option with format-patch for this kind of rework.
>
> Regards,
> Arend
>
Thanks, was looking for some
op 02-07-14 07:37, Greg KH schreef:
> On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote:
>> So after some more hacking I've moved dma-buf to its own subdirectory,
>> drivers/dma-buf and applied the fence patches to its new place. I believe
>> that th
available instead, and
the extra reservations can be dropped again. :-)
I've done at least basic testing on all the drivers I've converted
at some point, but more testing is definitely welcomed!
---
Maarten Lankhorst (17):
drm/ttm: add interruptible parameter to ttm_eu_reser
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
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 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 | 60 ++---
1 file changed, 40 insertions(+), 20 deletions
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
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
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60 -
drivers/gpu/drm/radeon/radeon_fence.c | 223 ++--
3 files changed, 248 insertions(+), 50 deletions(-)
diff --git a
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
---
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
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 31c4a6dd722d..6fe1f4bf37ed 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 20a1a866ceeb..79e950df3018 100644
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/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
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
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
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
op 09-07-14 15:09, Mike Lothian schreef:
> Hi Maarten
>
> Will this stop the stuttering I've been seeing with DRI3 and PRIME? Or will
> other patches / plumbing be required
>
No, that testing was with the whole series including the parts where you
synchronized intel with radeon (iirc).
Although it
_DMA1_INDEX: return "radeon.dma1";
>> +case R600_RING_TYPE_UVD_INDEX: return "radeon.uvd";
> Radeon supports vce rings on newer ascis. Probably want to add the case for
> those here too.
>
> Alex
>
Indeed, how about this?
--8<---
Signed-of
Hey,
op 22-07-14 06:05, Dave Airlie schreef:
> On 9 July 2014 22:29, Maarten Lankhorst
> wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/radeon/radeon.h| 15 +-
>> drivers/gpu/drm/radeon/radeon_device.c | 60 -
>> d
ie:
>>>>> On 9 July 2014 22:29, Maarten Lankhorst
>>>>> wrote:
>>>>>> Signed-off-by: Maarten Lankhorst
>>>>>> ---
>>>>>> drivers/gpu/drm/radeon/radeon.h| 15 +-
>&
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. If you're not ready yet because of a lockup simply
>> return not signaled yet.
> It's not only the lockup case from radeon I have in mind here. For u
er wrote:
>>>>> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote:
>>>>>> Am 22.07.2014 06:05, schrieb Dave Airlie:
>>>>>>> On 9 July 2014 22:29, Maarten Lankhorst
>>>>>>> wrote:
>>>>>>>>
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.
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 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
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 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 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 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 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 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 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 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 05-06-14 13:51, Rob Clark schreef:
On Wed, Jun 4, 2014 at 1:49 PM, Greg Kroah-Hartman
wrote:
On Wed, Jun 04, 2014 at 03:28:33PM +0200, Thierry Reding wrote:
On Wed, Jun 04, 2014 at 04:57:07PM +0530, Sumit Semwal wrote:
Hi Greg,
On 30 May 2014 21:38, Greg Kroah-Hartman wrote:
On Fri, Ma
op 20-05-14 17:13, Thomas Hellstrom schreef:
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
op 19-05-14 15:42, Thomas Hellstrom schreef:
Hi, Maarten!
Some nitpicks, and that krealloc within rcu lock still worries me.
Otherwise looks good.
/Thomas
On 04/23/2014 12:15 PM, Maarten
: Thierry Reding
Acked-by: Maarten Lankhorst
I saw the patches, but hard to clean up if it's not in the fences tree
yet. :-)
~maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordom
Changes since v1:
- Fixed interaction with reset handling.
+ Use exclusive_lock, either with trylock or blocking.
+ Bump sw irq refcount in the recovery function to prevent fiddling
with irq registers during gpu recovery.
- Add radeon lockup detection to the default fence wait function.
--
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
---
Splitted out version, I've noticed that I forgot to convert
radeon_fence_wait_empty to long r, fixed.
drivers/gpu/drm/radeon/radeon_fence.c
Signed-off-by: Maarten Lankhorst
---
Oops, changed unsigned long in __radeon_fence_wait to long, fixing a subtle
bug.
drivers/gpu/drm/radeon/radeon.h| 15 +--
drivers/gpu/drm/radeon/radeon_device.c | 60 -
drivers/gpu/drm/radeon/radeon_fence.c | 223
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 | 60 +++
1 file changed, 40 insertions(+), 20 deletions
Hey,
op 20-06-14 22:52, Thierry Reding schreef:
> On Thu, Jun 19, 2014 at 02:28:14PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding
>> wrote:
> With these changes, can we pull the android sync logic out of
> drivers/staging/ now?
Afaik the google guys
op 24-06-14 14:23, Alexandre Courbot schreef:
> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
> wrote:
>> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>
op 27-10-13 18:28, Linus Torvalds schreef:
> On Sat, Oct 26, 2013 at 5:19 AM, Ingo Molnar wrote:
>> This tree fixes a boot crash in CONFIG_DEBUG_MUTEXES=y kernels, on
>> kernels built with GCC 3.x. (There are still such distros.)
> Btw, it's really not just gcc 3.x. That code was (a) incomprehensi
op 27-10-13 20:23, Linus Torvalds schreef:
> On Sun, Oct 27, 2013 at 12:00 PM, Maarten Lankhorst
> wrote:
>> op 27-10-13 18:28, Linus Torvalds schreef:
>>> That expression is largely equivalent to
>>> "__builtin_constant_p(ww_ctx)" (because iff ww_ctx is c
op 27-10-13 20:51, Linus Torvalds schreef:
> On Sun, Oct 27, 2013 at 12:37 PM, Maarten Lankhorst
> wrote:
>> I would love for a compiler to become that smart though, but I do not think
>> it's likely.
> Dammit, even if that is true, then write the conditional *correct
; nvd7_grctx_generate_main(struct nvc0_graph_priv *priv, struct nvc0_grctx
> *info)
> {
> struct nvc0_grctx_oclass *oclass = (void *)nv_engine(priv)->cclass;
Acked-by: Maarten Lankhorst
Building with -Wmissing-prototypes? Good luck fixing radeon! it's a mess. :(
--
To unsubscribe from this
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,
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
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
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
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 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
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 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
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
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,
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
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.
>>>
>>>
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
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
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_
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
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 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
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 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 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 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 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,
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 02-05-16 om 21:25 schreef robert.f...@collabora.com:
> From: Robert Foss
>
> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
> update is requested and there is an earlier update pending".
>
> Signed-off-by: Robert Foss
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++
by: Gustavo Padovan
Acked-by: Maarten Lankhorst
modesets.
>
> Testcase: igt/kms_cursor_legacy
> Signed-off-by: Chris Wilson
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Christian König
> Cc: Maarten Lankhorst
> Cc: linux-kernel@vger.kernel.org
> ---
> kernel/locking/mutex.c | 56
>
301 - 400 of 528 matches
Mail list logo
