op 20-02-14 14:06, Fengguang Wu schreef:
Hi Maarten,
We are glad to find that your commit 339a3922f68dcb7d93001f07b7e914d5cf6c066d
("decrease useless padding") increased aim disk_src performance by 4.3%:
74833276be6802b 339a3922f68dcb7d93001f07b
--- -
op 20-02-14 14:06, Fengguang Wu schreef:
Hi Maarten,
We are glad to find that your commit 339a3922f68dcb7d93001f07b7e914d5cf6c066d
(decrease useless padding) increased aim disk_src performance by 4.3%:
74833276be6802b 339a3922f68dcb7d93001f07b
--- -
op 17-02-14 19:41, Christian König schreef:
Am 17.02.2014 19:24, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 12:36 PM, Christian König
wrote:
Am 17.02.2014 18:27, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 11:56 AM, Christian König
wrote:
Am 17.02.2014 16:56, schrieb Maarten Lankhorst
of using common
acpi_check_dsm() interface.
Signed-off-by: Jiang Liu
---
Hi Maarten,
Thanks for bisecting. Could you please help to verify whether
this patch fixes the regression?
Tested-by: Maarten Lankhorst
I was wrong about the operator precedence, seems correct after all
of using common
acpi_check_dsm() interface.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
Hi Maarten,
Thanks for bisecting. Could you please help to verify whether
this patch fixes the regression?
Tested-by: Maarten Lankhorst maarten.lankho...@canonical.com
I was wrong about
17.02.2014 16:56, schrieb Maarten Lankhorst:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) = 0 has been met.
Can't we make that just dma_buf[offset] != 0 instead? As far as I know
this way
nkorst
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 removed dma_fence_cancel_callback and so
Thanks to Fengguang Wu for spotting a missing static cast.
v2:
- Kill unused variable need_shared.
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-buf.c | 101 +++
include/linux/dma-buf.h | 12 ++
2 files changed, 113 insertions
Signed-off-by: Maarten Lankhorst
---
include/linux/reservation.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..92c4851b5a39 100644
--- a/include/linux/reservation.h
+++ b
fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.
Signed-off-by: Maarten Lankhorst
---
drivers/staging/android/Kconfig |1
drivers/staging/android/Makefile |2
drivers/staging/android/sw_sync.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/
---
drivers/base/dma-buf.c | 22
dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst
---
Documentat
some fallout from the rebase, hopefully everything's clean now,
and ready for -next.
---
Maarten Lankhorst (6):
fence: dma-buf cross-device synchronization (v17)
seqno-fence: Hardware dma-buf implementation of fencing (v4)
dma-buf: use reservation objects
android: convert
some fallout from the rebase, hopefully everything's clean now,
and ready for -next.
---
Maarten Lankhorst (6):
fence: dma-buf cross-device synchronization (v17)
seqno-fence: Hardware dma-buf implementation of fencing (v4)
dma-buf: use reservation objects
android: convert
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 maarten.lankho...@canonical.com
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com #drivers/media/v4l2-core
-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst maarten.lankho
fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/staging/android/Kconfig |1
drivers/staging/android/Makefile |2
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
include/linux/reservation.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..92c4851b5a39 100644
--- a/include
Thanks to Fengguang Wu for spotting a missing static cast.
v2:
- Kill unused variable need_shared.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/base/dma-buf.c | 101 +++
include/linux/dma-buf.h | 12 ++
2 files
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 removed dma_fence_cancel_callback and some comments
about checking
op 13-01-14 19:50, Colin Cross schreef:
> On Mon, Jan 13, 2014 at 4:31 AM, Maarten Lankhorst
> wrote:
>> The kernel fence implementation doesn't use event queues, but needs
>> to perform the same wake up. The symbol is not exported, since the
>> fence implementation
op 13-01-14 19:50, Colin Cross schreef:
On Mon, Jan 13, 2014 at 4:31 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
The kernel fence implementation doesn't use event queues, but needs
to perform the same wake up. The symbol is not exported, since the
fence implementation
fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
Signed-off-by: Maarten Lankhorst
---
drivers/staging/android/Kconfig |1
drivers/staging/android/Makefile |2
drivers/staging/android/sw_sync.c|4
drivers/staging/android
Thanks to Fengguang Wu for spotting a missing static cast.
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-buf.c | 102 +++
include/linux/dma-buf.h | 12 ++
2 files changed, 114 insertions(+)
diff --git a/drivers/base/dma-buf.c b
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
---
drivers/base/dma-buf.c | 22 --
drivers/gpu/drm/drm_prime.c
Signed-off-by: Maarten Lankhorst
---
include/linux/reservation.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..92c4851b5a39 100644
--- a/include/linux/reservation.h
+++ b
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 removed dma_fence_cancel_callback and some comments
ab
The following series implements fence and converts dma-buf and
android sync to use it. Patch 6 and 7 add support for polling
to dma-buf, blocking until all fences are signaled.
---
Maarten Lankhorst (7):
sched: allow try_to_wake_up to be used internally outside of core.c
fence: dma
The kernel fence implementation doesn't use event queues, but needs
to perform the same wake up. The symbol is not exported, since the
fence implementation is not built as a module.
Signed-off-by: Maarten Lankhorst
---
include/linux/wait.h |1 +
kernel/sched/core.c |2 +-
2 files
dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst
---
Documentat
-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst maarten.lankho
The kernel fence implementation doesn't use event queues, but needs
to perform the same wake up. The symbol is not exported, since the
fence implementation is not built as a module.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
include/linux/wait.h |1 +
kernel/sched
The following series implements fence and converts dma-buf and
android sync to use it. Patch 6 and 7 add support for polling
to dma-buf, blocking until all fences are signaled.
---
Maarten Lankhorst (7):
sched: allow try_to_wake_up to be used internally outside of core.c
fence: dma
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 removed dma_fence_cancel_callback and some comments
about checking if fence fired
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 maarten.lankho...@canonical.com
---
drivers/base/dma-buf.c | 22 --
drivers
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
include/linux/reservation.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..92c4851b5a39 100644
--- a/include
Thanks to Fengguang Wu for spotting a missing static cast.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/base/dma-buf.c | 102 +++
include/linux/dma-buf.h | 12 ++
2 files changed, 114 insertions(+)
diff --git
fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/staging/android/Kconfig |1
drivers/staging/android/Makefile |2
drivers/staging/android/sw_sync.c
; 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 list
)
{
struct nvc0_grctx_oclass *oclass = (void *)nv_engine(priv)-cclass;
Acked-by: Maarten Lankhorst maarten.lankho...@canonical.com
Building with -Wmissing-prototypes? Good luck fixing radeon! it's a mess. :(
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
op 05-11-13 14:18, Steven Rostedt schreef:
> On Tue, 05 Nov 2013 13:10:44 +0100
> Peter Zijlstra wrote:
>
>> Hi all,
>>
>> During Kernel Summit Dave mentioned that there wasn't a clear maintainer for
>> locking bits.
>>
>> To remedy this Ingo suggested gathering all the various locking primitives
op 05-11-13 14:18, Steven Rostedt schreef:
On Tue, 05 Nov 2013 13:10:44 +0100
Peter Zijlstra pet...@infradead.org wrote:
Hi all,
During Kernel Summit Dave mentioned that there wasn't a clear maintainer for
locking bits.
To remedy this Ingo suggested gathering all the various locking
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
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 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)
op 27-10-13 18:28, Linus Torvalds schreef:
On Sat, Oct 26, 2013 at 5:19 AM, Ingo Molnar mi...@kernel.org 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)
op 27-10-13 20:23, Linus Torvalds schreef:
On Sun, Oct 27, 2013 at 12:00 PM, Maarten Lankhorst
maarten.lankho...@canonical.com 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 constant
op 27-10-13 20:51, Linus Torvalds schreef:
On Sun, Oct 27, 2013 at 12:37 PM, Maarten Lankhorst
maarten.lankho...@canonical.com 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 *correctly
op 18-10-13 15:13, Ingo Molnar schreef:
> * Tetsuo Handa wrote:
>
>> Peter Zijlstra wrote:
>>> On Thu, Oct 17, 2013 at 12:54:21PM +0200, Maarten Lankhorst wrote:
>>>> op 17-10-13 12:52, Peter Zijlstra schreef:
>>>>> On Thu, Oct 17, 2013 at 07:
op 18-10-13 15:13, Ingo Molnar schreef:
* Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp wrote:
Peter Zijlstra wrote:
On Thu, Oct 17, 2013 at 12:54:21PM +0200, Maarten Lankhorst wrote:
op 17-10-13 12:52, Peter Zijlstra schreef:
On Thu, Oct 17, 2013 at 07:45:29PM +0900, Tetsuo Handa wrote
op 17-10-13 12:52, Peter Zijlstra schreef:
> On Thu, Oct 17, 2013 at 07:45:29PM +0900, Tetsuo Handa wrote:
>> Commit 040a0a37 "mutex: Add support for wound/wait style locks" used
>> "!__builtin_constant_p(p == NULL)" but gcc 3.x cannot handle such expression
>> correctly, leading to boot failure
op 17-10-13 12:52, Peter Zijlstra schreef:
On Thu, Oct 17, 2013 at 07:45:29PM +0900, Tetsuo Handa wrote:
Commit 040a0a37 mutex: Add support for wound/wait style locks used
!__builtin_constant_p(p == NULL) but gcc 3.x cannot handle such expression
correctly, leading to boot failure when built
boot service region with kernel text region by:
>>> start+size >= __pa_symbol(_text)
>>> The end of the above region should be start + size - 1 instead.
Acked-by: Maarten Lankhorst
>>> I see this problem in ovmf + Fedora 19 grub boot:
>>> text start:
by:
start+size = __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
Acked-by: Maarten Lankhorst maarten.lankho...@canonical.com
I see this problem in ovmf + Fedora 19 grub boot:
text start: 100 md start: 80 md size: 80
Signed-off-by: Dave Young dyo
hristian König wrote:
>>>>> Am 08.10.2013 16:33, schrieb Jerome Glisse:
>>>>>> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>>>>>>> Allocate and copy all kernel memory before doing reservations. This
>>>>>&g
e Glisse:
>>>>> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>>>>>> Allocate and copy all kernel memory before doing reservations. This
>>>>>> prevents a locking
>>>>>> inversion between mmap_sem and reservat
:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This
prevents a locking
inversion between mmap_sem and reservation_class, and allows us to drop
the trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst
, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This
prevents a locking
inversion between mmap_sem and reservation_class, and allows us to drop
the trylocking
in ttm_bo_vm_fault without
op 08-10-13 16:33, Jerome Glisse schreef:
> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>> Allocate and copy all kernel memory before doing reservations. This prevents
>> a locking
>> inversion between mmap_sem and reservation_class, and allows us to dr
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff
op 08-10-13 16:33, Jerome Glisse schreef:
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This prevents
a locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
Op 24-09-13 12:33, Thomas Hellstrom schreef:
> On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
>> Op 24-09-13 11:36, Daniel Vetter schreef:
>>> On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
>>>> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
&
Op 24-09-13 11:36, Daniel Vetter schreef:
> On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
>> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
>>> Op 24-09-13 09:22, Thomas Hellstrom schreef:
>>>> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
&
Op 24-09-13 11:03, Thomas Hellstrom schreef:
> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
>> Op 24-09-13 09:22, Thomas Hellstrom schreef:
>>> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
>>>> Hey,
>>>>
>>>> Op 13-09-13 11:00, Peter
Op 24-09-13 09:22, Thomas Hellstrom schreef:
> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 13-09-13 11:00, Peter Zijlstra schreef:
>>> On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
>>>> On Fri, Sep 13, 201
Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra pet...@infradead.org
wrote:
On Fri
Op 24-09-13 11:03, Thomas Hellstrom schreef:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter
Op 24-09-13 11:36, Daniel Vetter schreef:
On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra
Op 24-09-13 12:33, Thomas Hellstrom schreef:
On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
Op 24-09-13 11:36, Daniel Vetter schreef:
On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
> On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
>> On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra
>> wrote:
>>> On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
>> if (!bo_tryreserve()) {
>> up_read
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra pet...@infradead.org
wrote:
On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
if (!bo_tryreserve()) {
up_read
Op 13-09-13 10:23, Thomas Hellstrom schreef:
> On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
>> Op 13-09-13 09:46, Thomas Hellstrom schreef:
>>> On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
>>>> Op 13-09-13 08:44, Thomas Hellstrom schreef:
>>>>&
Op 13-09-13 09:46, Thomas Hellstrom schreef:
> On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
>> Op 13-09-13 08:44, Thomas Hellstrom schreef:
>>> On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
>>>> Op 12-09-13 18:44, Thomas Hellstrom schreef:
>>>>&
Op 13-09-13 08:44, Thomas Hellstrom schreef:
> On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
>> Op 12-09-13 18:44, Thomas Hellstrom schreef:
>>> On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
>>>> Op 12-09-13 17:36, Daniel Vetter schreef:
>>>>> On
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet
Op 13-09-13 09:46, Thomas Hellstrom schreef:
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09
Op 13-09-13 10:23, Thomas Hellstrom schreef:
On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
Op 13-09-13 09:46, Thomas Hellstrom schreef:
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09
Op 12-09-13 18:44, Thomas Hellstrom schreef:
> On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
>> Op 12-09-13 17:36, Daniel Vetter schreef:
>>> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra
>>> wrote:
>>>> So I'm poking around the preemption code and s
Op 12-09-13 17:36, Daniel Vetter schreef:
> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
>> So I'm poking around the preemption code and stumbled upon:
>>
>> drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
>> drivers/gpu/drm/ttm/ttm_bo_vm.c:
Op 12-09-13 17:06, Peter Zijlstra schreef:
> Hi Dave,
>
> So I'm poking around the preemption code and stumbled upon:
>
> drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
> drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
>
Op 12-09-13 17:06, Peter Zijlstra schreef:
Hi Dave,
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org
wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm
Op 09-09-13 13:56, Tetsuo Handa schreef:
> Maarten Lankhorst wrote:
>> Almost correct. I meant passing it as parameter to __mutex_lock_common. Your
>> version will still cause an extra pointless null check in the ww_mutex_lock
>> case.
> Ah, I s
Op 09-09-13 13:56, Tetsuo Handa schreef:
Maarten Lankhorst wrote:
Almost correct. I meant passing it as parameter to __mutex_lock_common. Your
version will still cause an extra pointless null check in the ww_mutex_lock
case.
Ah, I see.
--
From
Op 08-09-13 13:53, Tetsuo Handa schreef:
> Hello.
>
> Maarten Lankhorst wrote:
>> if it's broken for your compiler, please add a bool use_ww_ctx or something
>> to __mutex_lock_common that's set directly instead, the __builtin_constant_p
>> trick
>> might be too
Op 08-09-13 09:24, Tetsuo Handa schreef:
> Hello.
>
> Ilia Mirkin wrote:
>>> Commit 040a0a37 "mutex: Add support for wound/wait style locks" used
>>> "!__builtin_constant_p(p == NULL)" which I guess the author meant that
>>> "__builtin_constant_p(p) && p", but gcc 3.x cannot handle such expression
Op 08-09-13 09:24, Tetsuo Handa schreef:
Hello.
Ilia Mirkin wrote:
Commit 040a0a37 mutex: Add support for wound/wait style locks used
!__builtin_constant_p(p == NULL) which I guess the author meant that
__builtin_constant_p(p) p, but gcc 3.x cannot handle such expression
correctly, leading
Op 08-09-13 13:53, Tetsuo Handa schreef:
Hello.
Maarten Lankhorst wrote:
if it's broken for your compiler, please add a bool use_ww_ctx or something
to __mutex_lock_common that's set directly instead, the __builtin_constant_p
trick
might be too gcc version specific.
I see. I tested
Op 20-08-13 11:51, Christian König schreef:
> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
> [SNIP]
>
>>>>>> [SNIP]
>>>>>> +/**
>>>>>> + * radeon_fence_enable_signaling - enable signalling on fence
>>>>>> + * @fenc
Op 20-08-13 10:37, Christian König schreef:
> Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
>> Op 19-08-13 14:35, Christian König schreef:
>>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
>>>> [SNIP]
>>>> @@ -190,25 +225,24 @@ void radeon_fence_pro
Op 20-08-13 10:37, Christian König schreef:
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
Op 19-08-13 14:35, Christian König schreef:
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device
*rdev, int ring
Op 20-08-13 11:51, Christian König schreef:
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a
callback
Op 19-08-13 14:35, Christian König schreef:
> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
>> [SNIP]
>> @@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev,
>> int ring)
>> }
>> } while (atomic64_xchg(>
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9f19259..971284e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
nouveau was a bit tricky, it has no support for interrupts on
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..78714e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -35,88
of
nouveau_event_enable_locked and nouveau_event_disable_locked.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..78714e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9f19259..971284e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -64,6 +64,7 @@
#include linux/wait.h
Op 19-08-13 14:35, Christian König schreef:
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev,
int ring)
}
} while (atomic64_xchg(rdev-fence_drv[ring].last_seq, seq) seq);
-if (wake
601 - 700 of 1046 matches
Mail list logo
