https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #164 from Vedran Miletić ---
*** Bug 70779 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=70779
Vedran Miletić changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=72785
Vedran Miletić changed:
What|Removed |Added
Summary|bfgminer --scrypt on 7xxx+ |bfgminer --scrypt OpenCL on
https://bugs.freedesktop.org/show_bug.cgi?id=72785
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||96897
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=96897
Vedran Miletić changed:
What|Removed |Added
Summary|[opencl] clpeak hangs |clpeak OpenCL benchmark
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||100218
Referenced Bugs:
https://bugs.
On 03/22/2017 05:08 PM, Jose Abreu wrote:
> Hi Neil,
>
>
> On 21-03-2017 15:12, Neil Armstrong wrote:
>> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
>> Controller, this patch takes the pixel format from the plat_data if provided.
>>
>> Signed-off-by: Neil Armstrong
On Tue, 2017-03-21 at 16:12 +0100, Neil Armstrong wrote:
> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
> Controller, this patch takes the pixel format from the plat_data if provided.
>
> Signed-off-by: Neil Armstrong
On i.MX6 we could provide RGB/YUV bus formats d
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 94503, which changed state.
Bug 94503 Summary: OpenCL kernel segfaults during compilation on Clover
RadeonSI with Pitcairn GPU
https://bugs.freedesktop.org/show_bug.cgi?id=94503
What|Removed
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||94503
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=94503
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 94040, which changed state.
Bug 94040 Summary: clGetPlatformIDs causes futex race condition
https://bugs.freedesktop.org/show_bug.cgi?id=94040
What|Removed |Added
---
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||93977
Referenced Bugs:
https://bugs.f
On 03/22/2017 05:21 PM, Philipp Zabel wrote:
> On Tue, 2017-03-21 at 16:12 +0100, Neil Armstrong wrote:
>> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
>> Controller, this patch takes the pixel format from the plat_data if provided.
>>
>> Signed-off-by: Neil Armstrong
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||94040
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 90121, which changed state.
Bug 90121 Summary: All OpenCL samples are failing with clGetPlatformID on
Clover with Bonaire
https://bugs.freedesktop.org/show_bug.cgi?id=90121
What|Removed
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||90121
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 78581, which changed state.
Bug 78581 Summary: OpenCL: clBuildProgram prints error messages directly rather
than storing them
https://bugs.freedesktop.org/show_bug.cgi?id=78581
What|Removed
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||78581
Referenced Bugs:
https://bugs.f
On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote:
> Why bother, and why would we want this?
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but
https://bugs.freedesktop.org/show_bug.cgi?id=82717
--- Comment #8 from Christoph Haag ---
To document the current state...
Recently I was getting "unsupported call to function get_global_id" so I
assumed there was some llvm problem. Turns out if this happens you just need to
rebuild libclc for y
https://bugs.freedesktop.org/show_bug.cgi?id=99553
--- Comment #9 from Vedran Miletić ---
I have beeing fishing through the Bugzilla backlog on Clover to see what's
there. Most of the bugs are fixed by now, but a couple are still there. Sorry
for bugspam.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=100239
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.
https://bugs.freedesktop.org/show_bug.cgi?id=100089
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.
https://bugs.freedesktop.org/show_bug.cgi?id=99923
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99762
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=99136
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Summary|Blood Effects
https://bugs.freedesktop.org/show_bug.cgi?id=98996
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Summary|Counter Strike
https://bugs.freedesktop.org/show_bug.cgi?id=98856
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=98238
Vedran Miletić changed:
What|Removed |Added
Blocks||77449
Summary|witcher 2: obj
On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote:
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote:
>> Why bother, and why would we want this?
>> │~
>>
>> First it's written in python, which means the potential developer base
>
On 21 March 2017 at 19:10, Matt Turner wrote:
> On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov
> wrote:
>> On 21 March 2017 at 18:06, Matt Turner wrote:
>>> (1) Non-recursive automake is necessary for parallel build performance
>> Fully agree
>>
>>> (2) Non-recursive automake is intractably unm
On Wed, Mar 22, 2017 at 6:26 PM, Jose Fonseca wrote:
> On 16/03/17 22:36, Marek Olšák wrote:
>>
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect errors in stderr?
>>
>> I'm basi
On Wed, Mar 22, 2017 at 04:05:59PM +0200, Jani Nikula wrote:
> On Wed, 22 Mar 2017, Daniel Vetter wrote:
> > On Wed, Mar 22, 2017 at 12:33:35PM +0200, Jani Nikula wrote:
> >> On Wed, 22 Mar 2017, Daniel Vetter wrote:
> >> > There's really no reason for anything more:
> >> > - Calling this while t
On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > To match the drm_ioctl.c we already have.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 1 +
> > include/drm/drmP.h | 6
From: Thierry Reding
Shutting down a host1x device currently crashes if the device has failed
to probe. The root cause is that the host1x shutdown is implemented as a
struct bus_type callback, but in turn relies on the driver bound to the
device. On failure to probe, no driver will be bound and c
On Wed, Mar 22, 2017 at 06:56:32PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > > To match the drm_ioctl.c we already have.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> >
https://bugs.freedesktop.org/show_bug.cgi?id=96897
--- Comment #4 from Vedran Miletić ---
Not anymore on both LLVM 3.9.1 and LLVM git from today:
input.cl:34:106: error: call to 'mad' is ambiguous
input.cl:30:22: note: expanded from macro 'MAD_64'
input.cl:29:22: note: expanded from macro 'MAD_1
On Wed, Mar 22, 2017 at 09:36:13AM +0100, Daniel Vetter wrote:
> It's overkill to have a flag parameter which is essentially used just
> as a boolean. This takes care of core + adjusting drivers.
>
> Adjusting the scanout position callback is a bit harder, since radeon
> also supplies it's own dri
We were experiencing an infinite loop due to VRAM bos getting added back
to the VRAM lru on eviction via ttm_bo_mem_force_space, and reverting
this commit solves the problem.
Signed-off-by: Zachary Michaels
Signed-off-by: Julien Isorce
---
drivers/gpu/drm/radeon/radeon_ttm.c | 25 +-
Daniel Vetter writes:
> Just drive-by, but we have gsoc running so better to update it now.
>
> Great news is that two entries can be removed because essentially all
> done.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 51
> -
On Tue, Mar 21, 2017 at 01:26:23PM -0700, Ben Widawsky wrote:
> On 17-03-21 20:12:15, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >Allow framebuffers dimesions to be misaligned w.r.t. the subsampling
> >factors. No real reason the core should have to enforce this, and
> >it definitely starts
https://bugs.freedesktop.org/show_bug.cgi?id=100067
--- Comment #3 from Vedran Miletić ---
Created attachment 130386
--> https://bugs.freedesktop.org/attachment.cgi?id=130386&action=edit
Kernel from minimal.cpp
Sorry, that was a false positive, local installation issue. I can't reproduce
it on
https://bugs.freedesktop.org/show_bug.cgi?id=100067
--- Comment #4 from Vedran Miletić ---
Can you provide GDB backtraces of both minimal and mat-mul?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=100239
--- Comment #2 from Ernst Sjöstrand ---
I can't reproduce this with my Fury, and have never seen it, for reference...
Any tweaks like R600_DEBUG etc?
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Jose,
I can't find the other patches of this series in dri patchwork, am I missing
something ?
Also, I am planning to publish a series for YUV 420 handling, where I have
re-used one of your patch to parse YUV 420 block, with some modifications :-).
Regards
Shashank
-Original Message-
These tests depend on tests/util/ headers, but expect the include path
to be tests/.
Signed-off-by: Rob Herring
---
Android.mk| 2 ++
tests/util/Android.mk | 2 ++
2 files changed, 4 insertions(+)
diff --git a/Android.mk b/Android.mk
index 5209059e670f..292be2360263 100644
--- a/And
Disable some more warnings from clang. These don't appear to be warnings
worth fixing.
Signed-off-by: Rob Herring
---
Android.common.mk | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Android.common.mk b/Android.common.mk
index f57b8d378565..35c0f02c213c 100644
--- a/Andro
Daniel Vetter writes:
> It's the default storage class for functions, entirely redundant. And
> a lot of these headers are a bit inconsistent due to organically
> grown.
>
Reviewed-by: Gabriel Krisman Bertazi
--
Gabriel Krisman Bertazi
___
dri-deve
Daniel Vetter writes:
> I've decided to not document drm_debugfs_remove_files, it's on the way
> out.
>
> The biggest part is a huge todor.rst entry with what all should be
> improved.
todo.rst
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-uapi.rst | 9
> Documentat
https://bugs.freedesktop.org/show_bug.cgi?id=100289
omegap...@startmail.com changed:
What|Removed |Added
CC||omegap...@startmail.com
--- Co
On Wed, Mar 22, 2017 at 04:06:32PM +0100, Mario Kleiner wrote:
> On 03/15/2017 10:00 PM, Ville Syrjälä wrote:
> > On Wed, Mar 15, 2017 at 08:40:25PM +, Chris Wilson wrote:
> >> On vblank instant-off systems, we can get into a situation where the cost
> >> of enabling and disabling the vblank IR
On Wed, Mar 22, 2017 at 03:34:10PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:03AM +0100, Daniel Vetter wrote:
> > Doc polish will follow in the next patch.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_debugfs.c | 5 ++-
> > include/drm/drmP.h
On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote:
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson. It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but
On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > To match the drm_ioctl.c we already have.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 1 +
> > include/drm/drmP.h | 6
On Wed, Mar 22, 2017 at 09:15:23PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > > To match the drm_ioctl.c we already have.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> >
On Wed, Mar 22, 2017 at 03:31:00PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter writes:
>
> > Just drive-by, but we have gsoc running so better to update it now.
> >
> > Great news is that two entries can be removed because essentially all
> > done.
> >
> > Signed-off-by: Daniel Vetter
https://bugs.freedesktop.org/show_bug.cgi?id=70199
Jan Vesely changed:
What|Removed |Added
Resolution|WORKSFORME |FIXED
--- Comment #12 from Jan Vesely ---
On Tue, Mar 21, 2017 at 03:38:26PM -0400, Sean Paul wrote:
> On Tue, Mar 21, 2017 at 04:52:28PM +0100, Daniel Vetter wrote:
> > The discussion pretty much concluded without objections, let's
> > document what we agreed on.
> >
> > Cc'ing linux-doc for the new tag in Documentation/process/index.rst
On Wed, Mar 22, 2017 at 01:30:30PM +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
> Is there any issue into attempting to release vcpi slots when they're already
> released? If not, for patches 1-3 5-8
>
> Reviewed-by: Maarten Lankhorst
Merged patches 1-3 to
Doc polish will follow in the next patch.
v2: Put the include guard #endif at the end (Ville).
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs.c | 5 ++-
include/drm/drmP.h| 44 +
include/drm/drm_debugfs.h | 77 +++
I've decided to not document drm_debugfs_remove_files, it's on the way
out.
The biggest part is a huge todo.rst entry with what all should be
improved.
v2: Nits from Gabriel.
Cc: Gabriel Krisman Bertazi
Reviewed-by: Gabriel Krisman Bertazi
Signed-off-by: Daniel Vetter
---
Documentation/gpu/d
To match the drm_ioctl.c we already have.
v2: Remove spurious space (Ville).
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 1 +
include/drm/drmP.h | 61 +-
include/drm/drm_ioctl.h | 102 +
There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
bug. Those places arlready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (callin
drm_crtc_handle_vblank at the wrong time) or a core bug (for
anything else).
Just drive-by, but we have gsoc running so better to update it now.
Great news is that two entries can be removed because essentially all
done.
v2: Keep a bunch of the todos, Gabriel is working on them.
Cc: Gabriel Krisman Bertazi
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst |
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is update already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence th
Quoting Jose Fonseca (2017-03-22 10:59:10)
> On 17/03/17 02:28, Brian Paul wrote:
> >
> > [snip]
> >
> > Sure, I'd like to see one build system instead of two. Meson supports
> > Windows so that's good. But the big issue is our automated build
> > system. Replacing SCons with Meson could be a bi
On Wed, Mar 22, 2017 at 09:53:36PM +0100, Daniel Vetter wrote:
> Doc polish will follow in the next patch.
>
> v2: Put the include guard #endif at the end (Ville).
>
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_debugfs.c | 5 ++-
Quoting Jani Nikula (2017-03-22 01:24:19)
> On Tue, 21 Mar 2017, Dylan Baker wrote:
> > Quoting Jani Nikula (2017-03-21 07:44:55)
> >> How does meson handle build file backwards compatibility between meson
> >> versions? I don't intend to flame, but I've found for some reason many
> >> python proj
On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
[...]
> > @@ -2437,11 +2476,16 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config
On Wed, Mar 22, 2017 at 10:06 PM, Thierry Reding
wrote:
> On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
>> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
> [...]
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> > b/drivers/gpu/drm/drm_fb_helper.c
> [...]
>> >
https://bugs.freedesktop.org/show_bug.cgi?id=97338
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
> Quoting Rob Clark (2017-03-22 10:07:54)
>> I guess an interesting question (from someone who doesn't know meson
>> yet) would be whether meson could slurp in the Makefile.sources type
>> stuff that we have, which are shared so far between
>> an
This is just prep work to get an acquire ctx into every place where we
call ->update_plane or ->disable_plane.
v2: Keep the hidden acquire_ctx pointers valid while transitioning.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 52 -
1 f
Just rolling it out, no code change here.
Cc: Ben Skeggs
Cc: Russell King
Cc: Rob Clark
Cc: Laurent Pinchart
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_overlay.c| 3 ++-
drivers/gpu/drm/drm_atomic_helper.c| 4 +++-
drivers/gpu/drm/drm_plane.c
Nouveau had a few direct calls to ->disable_plane, I replaced those
with drm_plane_force_disable. Same story for shmob.
Otherwise no code changes.
Cc: Ben Skeggs
Cc: Russell King
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_overlay.c| 3 ++-
driver
Hi all,
This is something I kinda had on my todo list ever since atomic landed. The
legacy_backoff() hack really doesn't work if you need to acquire additional
locks, which does restrict drivers in how they handle and protect legacy paths,
and kinda forces us to be overzealous with taking locks fo
This way I can explain why it'll be fine to pass a NULL acquire ctx
here in the next patch.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 8a4e75929810..67119
We can now properly retry at the top level, yay!
v2: Also remove the temporary acquire_ctx hack again, no longer
needed!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 49 ++---
drivers/gpu/drm/drm_plane.c | 2 --
2 files changed,
Again this is an internal helper, not the official way to lock a crtc.
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
It's been around forever, no one bothered to address the FIXME, so I
presume it's all fine.
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/v
Yes the help text is unhelpful, but atomic drivers should never use
this. Just grab the lock without context or anything.
Also an aside: Checking ->active like this doesn't protect against
nonblocking commits, this is rather bogus.
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gp
This is only for legacy paths that need to grab the crtc/plane lock
combo. If you want to lock a crtc, just use drm_modeset_lock().
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 3 +++
drivers/gpu/drm/drm_modeset_lock.c | 14 --
include/drm/drm_modeset_lock
Again just going through the motions, no functional changes in here.
Cc: Gerd Hoffmann
Cc: Ben Skeggs
Cc: Russell King
Cc: Laurent Pinchart
Cc: Eric Anholt
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Daniel Vetter t
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++-
drivers/g
With all the callers of drm_modeset_lock_crtc gone, and all the places
it was formerly used properly wiring the acquire ctx through, we can
remove this.
The only hidden context magic we still have is now the global one.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 14
This is another case where we really can't reconstruct a acquire ctx
in any useful fashion because all the callers are legacy drivers. So
like drm_plane_force_disable simply restrict it to non-atomic drivers
so that it's clear we're ok with passing a NULL ctx.
Signed-off-by: Daniel Vetter
---
dr
Another one bites the dust.
Again let's not forget to remove the temporary hidden acquire_ctx
assignment, now that we pass this all around explicitly it can go
away again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 21 ++---
drivers/gpu/drm/drm_crtc.c
Again just prep work.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 8535dc17db7e..62e833ffeffd 100644
--- a/drivers/gpu/drm/dr
The last user, the cursor ioctl, can just open-code this too. We
simply have to move the acquire ctx dance from the universal function
up into the top-level ioctl handler.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 3 --
drivers/gpu/drm/drm_modeset_lock.c | 67 -
Yay, we can now properly retry in case of deadlocks or whatever!
Also don't forget to remove the transitional crtc->acquire_ctx
assignment again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 40 ++---
drivers/gpu/drm/drm_plane.c
Surprisingly a lot of legacy drivers roll their own, for
runtime pm and because vmwgfx.
Also make nouveau's set_config static while at it.
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Cc: Ben Skeggs
Cc: Patrik Jakobsson
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drive
No need to grab both plane and crtc locks at the same time, we can do
them one after the other. If userspace races it'll get what it
deserves either way.
This removes another user of drm_modeset_lock_crtc. There's only one
left.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 6 ++
Just the groundwork to have something to feed into ->set_config.
Again we need a temporary hack to still fill out the legacy
ctx in mode_config.acquire_ctx.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(
On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker wrote:
> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>
> Notably gnome is moving to meson (and some parts already use it), weston and
> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> can't s
https://bugs.freedesktop.org/show_bug.cgi?id=96897
--- Comment #5 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
With LLVM 4.0.0 I am getting the following results:
$ clinfo
Platform ID: 0x7ff6aaf2ed60
Name: AMD HAWAII (DRM 3.10.0 / 4.11.0-rc2+, LLVM
4.0
Rob Clark writes:
> On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker wrote:
>> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>>
>> Notably gnome is moving to meson (and some parts already use it), weston and
>> libinput have ports, libepoxy uses meson, and gstreamer i
hi,
Could you please give some feedback or review comments for this patch
On 3/14/17, Vinay Simha BN wrote:
> 4 macros already defined in hdmi.h,
> which is not required to redefine in hdmi_audio.c
>
> Signed-off-by: Vinay Simha BN
> ---
> drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 7 ---
> 1
On 16/03/17 22:36, Marek Olšák wrote:
Is there a way not to use ninja with meson, because ninja redirects
all stderr output from gcc to stdout, which breaks many development
environments that expect errors in stderr?
I'm basically saying that if ninja can't keep gcc errors in stderr, I
wouldn't
For drm_of_find_panel_or_bridge() added in the next commit, an empty
version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL.
Signed-off-by: Rob Herring
---
v3:
- rebase to v4.11-rc2
include/drm/drm_panel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm
101 - 200 of 239 matches
Mail list logo
