https://bugzilla.kernel.org/show_bug.cgi?id=194559
--- Comment #4 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 254741
--> https://bugzilla.kernel.org/attachment.cgi?id=254741&action=edit
config of working drm-next kernel
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=194559
Janpieter Sollie (janpieter.sol...@dommel.be) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=194559
--- Comment #5 from fin4...@hotmail.com ---
(In reply to Janpieter Sollie from comment #3)
> it works! attached my config file of your drm-next kernel
> I don't know what needs to be done for you developers to integrate drm-next
> into the mainlin
Hi,
On Mon, Feb 13, 2017 at 06:46:45PM +0200, Priit Laes wrote:
> On Mon, 2017-02-13 at 17:20 +0800, Chen-Yu Tsai wrote:
> > On Mon, Feb 13, 2017 at 5:16 PM, Maxime Ripard
> > wrote:
> > > Hi,
> > >
> > > On Sat, Feb 11, 2017 at 07:43:59PM +0200, Priit Laes wrote:
> > > > Added basic display pip
https://bugzilla.kernel.org/show_bug.cgi?id=194559
--- Comment #6 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to fin4478 from comment #5)
> This and many other amdgpu bug reports prove my point.
Your bug report comments like this one rather indicate that you don't
understand how the ker
https://bugzilla.kernel.org/show_bug.cgi?id=118701
Stuart Foster (smf.li...@ntlworld.com) changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Hi all,
based on my current theory on how a deadlock could happen in the
buffer allocation code, these two patches should fix the deadlock
without having a use-after-free.
I'm still working on a way to clean up the ttm_bo_init sequence
overall, but I'm separating these two out for a hopefully qui
From: Nicolai Hähnle
This reverts commit 38fc4856ad98f230bc91da0421dec69e4aee40f8, which
introduces a use-after-free.
The underlying bug should be properly fixed with "drm/ttm: never add BO
that failed to validate to the LRU list".
Cc: Samuel Pitoiset
Cc: zhoucm1
Signed-off-by: Nicolai Hähnle
From: Nicolai Hähnle
Fixes a potential race condition in amdgpu that looks as follows:
Task 1: attempt ttm_bo_init, but ttm_bo_validate fails
Task 1: add BO to global list anyway
Task 2: grabs hold of the BO, waits on its reservation lock
Task 1: releases its reference of the BO; never gives up
Am 14.02.2017 um 02:44 schrieb Emil Velikov:
On 14 February 2017 at 00:08, Samuel Pitoiset wrote:
Hi,
This series implements a new GPU sensor interface which will allow to
query the current temperature and the shader/memory clocks via the
GALLIUM_HUD. This adds the same functionality as the Ra
Am 14.02.2017 um 07:21 schrieb Julia Lawall:
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
Acked-by: Christian König for this one as
well as the other similar patches.
Thanks f
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #91 from Andreas Hartmetz ---
Steam has now shipped the game side fix as well.
It feels almost like a new game, much much better.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for t
https://bugzilla.kernel.org/show_bug.cgi?id=194579
Christian König (deathsim...@vodafone.de) changed:
What|Removed |Added
CC||deathsim...@vo
https://bugzilla.kernel.org/show_bug.cgi?id=194579
--- Comment #4 from Christian König (deathsim...@vodafone.de) ---
Now back to topic, what code base is this? Could you post the branch you are
using somewhere?
In the upstream kernel the line at ttm_bo.c:388 is just an assignment and can't
cause
On 02/14/2017 10:18 AM, Nicolai Hähnle wrote:
Hi all,
based on my current theory on how a deadlock could happen in the
buffer allocation code, these two patches should fix the deadlock
without having a use-after-free.
I'm still working on a way to clean up the ttm_bo_init sequence
overall, bu
https://bugs.freedesktop.org/show_bug.cgi?id=99552
Vedran Miletić changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 99552, which changed state.
Bug 99552 Summary: Make Advanced Simulation Library (ASL) OpenCL GPU support
work on Clover and RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=99552
What|Removed
We are told not to set plane_state->fb directly, but use
drm_atomic_set_fb_for_plane() instead. Using the helper, means one less
piece of code that needs fixing should the interface change...
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 1 inser
On 02/14/2017 10:43 AM, Christian König wrote:
Am 14.02.2017 um 02:44 schrieb Emil Velikov:
On 14 February 2017 at 00:08, Samuel Pitoiset
wrote:
Hi,
This series implements a new GPU sensor interface which will allow to
query the current temperature and the shader/memory clocks via the
GALLI
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: d892e9398ecf6defc7972a62227b77dad6be20bd
commit: 953c7f82eb890085c60dbe22578e883d6837c674 [11/59] drm/i915: Provide a
hook for selftests
config: x86_64-randconfig-s2-02141638 (attached as .config)
compiler: gcc-4.4 (Debi
From: Nicolai Hähnle
Open-code the initial ttm_bo_validate call, so that we can properly
unlock the reservation lock when it fails. Also, properly destruct
the reservation object when the first part of TTM BO initialization
fails.
Actual deadlocks caused by the missing unlock should have been fi
From: Nicolai Hähnle
As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.
Signed-off-by: Nicolai Hähnle
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/in
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/ttm/ttm_
On 02/14/2017 10:18 AM, Nicolai Hähnle wrote:
Hi all,
based on my current theory on how a deadlock could happen in the
buffer allocation code, these two patches should fix the deadlock
without having a use-after-free.
I'm still working on a way to clean up the ttm_bo_init sequence
overall, bu
On Tuesday, 2017-02-14 10:18:31 +, Chris Wilson wrote:
> We are told not to set plane_state->fb directly, but use
> drm_atomic_set_fb_for_plane() instead. Using the helper, means one less
> piece of code that needs fixing should the interface change...
>
> Signed-off-by: Chris Wilson
Reviewe
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #23 from Marek Olšák ---
You can take the default case statement in the unbyteswap function on LE. That
should safely disable the whole thing on LE.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #24 from Marek Olšák ---
Ah thats what the patch does. I'll reply on mesa-dev.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel
Am 14.02.2017 um 10:18 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Fixes a potential race condition in amdgpu that looks as follows:
Task 1: attempt ttm_bo_init, but ttm_bo_validate fails
Task 1: add BO to global list anyway
Task 2: grabs hold of the BO, waits on its reservation lock
Task 1:
On 14.02.2017 11:38, Christian König wrote:
Am 14.02.2017 um 10:18 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Fixes a potential race condition in amdgpu that looks as follows:
Task 1: attempt ttm_bo_init, but ttm_bo_validate fails
Task 1: add BO to global list anyway
Task 2: grabs hold of t
Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.
Signed-off-
On Tue, Feb 14, 2017 at 06:32:17PM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
> head: d892e9398ecf6defc7972a62227b77dad6be20bd
> commit: 953c7f82eb890085c60dbe22578e883d6837c674 [11/59] drm/i915: Provide a
> hook for selftests
> config
https://bugs.freedesktop.org/show_bug.cgi?id=99484
--- Comment #5 from Timothy Arceri ---
Running Mesa master with llvm 3.8 (instead of 5.0 from git) resolves the
problem.
--
You are receiving this mail because:
You are the assignee for the bug.___
dr
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #28 from alvarex ---
Created attachment 129582
--> https://bugs.freedesktop.org/attachment.cgi?id=129582&action=edit
artifacts on radeon rx460
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #29 from alvarex ---
Hi I think I ve run into the same issue. I'm not quite sure. Firefox and other
elements sometimes present artifacts, and as Reimar suggests with kernel 4.8 it
doesn't happen.
RX460 on Opensuse 42.2.
It seams like
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #30 from alvarex ---
it happens really fast for a fraction of a second and then it draws correctly,
I had to record the desktop and play the video in slow motion to take the
screenshot.
And it's random sometimes it won't happen for a
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #11 from Timothy Arceri ---
The game runs (mostly fine on) i965, and a trace from i965 seem to run without
issue on radeonsi.
However running the radeonsi trace on the nvidia blob results in the same
corruptions.
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=99484
--- Comment #6 from Andreas Boll ---
(In reply to Timothy Arceri from comment #5)
> Running Mesa master with llvm 3.8 (instead of 5.0 from git) resolves the
> problem.
Be aware that llvm 3.8 degrades OpenGL support for radeonsi. Just check your
On 2/9/2017 8:55 PM, Wei Yongjun wrote:
From: Wei Yongjun
Fixes the following sparse warning:
drivers/gpu/drm/bridge/ti-tfp410.c:223:24: warning:
symbol 'tfp410_platform_driver' was not declared. Should it be static?
This was queued to drm-misc-next
Thanks,
Archit
Signed-off-by: Wei Y
From: Nicolai Hähnle
Fix a warning about different types in min() macro in amdgpu:
In file included from ./include/linux/list.h:8:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:32:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function
‘amdgpu_bo_create_restricted’:
./incl
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: d892e9398ecf6defc7972a62227b77dad6be20bd
commit: b348090d6758cc391dc91f8a8233b18f0acc8458 [23/59] drm/i915: Simple
selftest to exercise live requests
config: x86_64-randconfig-s2-02141638 (attached as .config)
compiler:
[ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
(8802538683d0)
[ 236.828642] 42001e7f0008
[ 236.839543] i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u
[ 236.850420]
From: Pierre-Louis Bossart
100% reproducible issue found on SKL SkullCanyon NUC with two external
DP daisy-chained monitors in DP/MST mode. When turning off or changing
the input of the second monitor the machine stops with a kernel
oops. This issue happened with 4.8.8 as well as drm/drm-intel-ni
Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle:
On 14.02.2017 11:49, Christian König wrote:
Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object
Am 14.02.2017 um 12:37 schrieb Nicolai Hähnle:
On 14.02.2017 11:38, Christian König wrote:
Am 14.02.2017 um 10:18 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Fixes a potential race condition in amdgpu that looks as follows:
Task 1: attempt ttm_bo_init, but ttm_bo_validate fails
Task 1: add
Hi Chris,
2017-02-14 Chris Wilson :
> [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> memory (8802538683d0)
> [ 236.828642]
> 42001e7f0008
> [ 236.839543] i i i i u u u u i i i i i i i i u u u u u u u u u u u
On Tue, Feb 14, 2017 at 11:40:38AM -0200, Gustavo Padovan wrote:
> Hi Chris,
>
> 2017-02-14 Chris Wilson :
> > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> > index c769dc653b34..bfead12390f2 100644
> > --- a/drivers/dma-buf/sync_debug.c
> > +++ b/drivers/dma-buf/sync_
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #31 from alvarex ---
I will try to git bisect but last time I tried bisecting the kernel I failed
miserably and it failed compiling several times.
--
You are receiving this mail because:
You are the assignee for the bug.
Am 14.02.2017 um 13:25 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Fix a warning about different types in min() macro in amdgpu:
In file included from ./include/linux/list.h:8:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:32:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: d892e9398ecf6defc7972a62227b77dad6be20bd
commit: 170594502cf591fd0789d7e5239937b1a87af4c6 [31/59] drm/i915: Test
coherency of and barriers between cache domains
config: x86_64-randconfig-s2-02141638 (attached as .config)
2017-02-14 Chris Wilson :
> On Tue, Feb 14, 2017 at 11:40:38AM -0200, Gustavo Padovan wrote:
> > Hi Chris,
> >
> > 2017-02-14 Chris Wilson :
> > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> > > index c769dc653b34..bfead12390f2 100644
> > > --- a/drivers/dma-buf/syn
On Tue, Feb 14, 2017 at 12:22:02PM -0200, Gustavo Padovan wrote:
> 2017-02-14 Chris Wilson :
>
> > On Tue, Feb 14, 2017 at 11:40:38AM -0200, Gustavo Padovan wrote:
> > > Hi Chris,
> > >
> > > 2017-02-14 Chris Wilson :
> > One thing that occurs to me is whether we should be setting the
> > timesta
https://bugzilla.kernel.org/show_bug.cgi?id=194559
--- Comment #7 from fin4...@hotmail.com ---
(In reply to Michel Dänzer from comment #6)
> (In reply to fin4478 from comment #5)
> > This and many other amdgpu bug reports prove my point.
>
> Your bug report comments like this one rather indicate
https://bugzilla.kernel.org/show_bug.cgi?id=194579
--- Comment #5 from fin4...@hotmail.com ---
(In reply to Christian König from comment #3)
> Please ignore the incorrect comment by fin4...@hotmail.com.
>
> The upstream kernel the official base amdgpu driver code. Only a few not
> parts which are
https://bugzilla.kernel.org/show_bug.cgi?id=194559
Christian König (deathsim...@vodafone.de) changed:
What|Removed |Added
CC||deathsim...@vo
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #32 from alvarex ---
I'm sorry but I can't find a consistent way of reproducing the bug. I presumed
that with 4.9 the bug will still be there but right now, no matter how hard I
try I cannot reproduce with 4.9.4, 4.9.9 and 4.9rc1, I t
On Sat, Feb 11, 2017 at 12:48 PM, Noralf Trønnes wrote:
> Display panels can be oriented many ways, especially in the embedded
> world. The rotation property is a way to describe this orientation.
> The counter clockwise direction is chosen because that's what fbdev
> and drm use.
>
> Signed-off-b
On Mon, Feb 13, 2017 at 11:01:14AM -0800, Laura Abbott wrote:
> On 02/13/2017 10:18 AM, Mark Brown wrote:
> > The software defined networking people seemed to think they had a use
> > case for this as well. They're not entirely upstream of course but
> > still...
> This is the first I've heard o
https://bugs.freedesktop.org/show_bug.cgi?id=99815
Bug ID: 99815
Summary: Power management problems & kernel hangs with Cap
Verde
Product: DRI
Version: unspecified
Hardware: Other
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=99801
--- Comment #12 from Harry Wentland ---
We're currently debugging an issue that looks very similar, if not the same.
It's also with a 5k display with two DP input but on a different platform. The
display pipe driving one half of the display is un
Thanks for these fixes. I'll merge them.
Reviewed-by: Harry Wentland
Harry
On 2017-02-14 04:47 AM, Christian König wrote:
Am 14.02.2017 um 07:21 schrieb Julia Lawall:
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia L
Reviewed-by: Harry Wentland
Harry
On 2017-02-14 01:14 AM, Julia Lawall wrote:
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
---
tree: git://people.freedesktop.org/~agd5f/linux.
Reviewed-by: Harry Wentland
Harry
On 2017-02-14 01:13 AM, Julia Lawall wrote:
Remove unneeded semicolons.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
---
tree: git://people.freedesktop.org/~agd5f/linux
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #25 from cosiek...@o2.pl ---
I can do more testing if needed.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop
Reviewed-by: Harry Wentland
Harry
On 2017-02-14 01:19 AM, Julia Lawall wrote:
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
---
tree: git://people.freedesktop.org/~agd5f/linux.
https://bugs.freedesktop.org/show_bug.cgi?id=65968
Andreas Ringlstetter changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=98784
--- Comment #16 from Torbjörn Andersson ---
I can't reproduce the glitch any more. Perhaps today's update of the game fixed
it?
--
You are receiving this mail because:
You are the assignee for the bug.___
Currently the hikey dsi logic cannot generate accurate byte
clocks values for all pixel clock values. Thus if a mode clock
is selected that cannot match the calculated byte clock, the
device will boot with a blank screen.
This patch uses the new mode_valid callback to enforces known
good mode cloc
Currently, on the hikey board, we have the adv7511 bridge wired
up to the kirin ade drm driver. Unfortunately, the kirin ade
core cannot generate accurate byteclocks for all pixel clock
values.
Thus if a mode clock is selected that we cannot calculate a
matching byteclock, the device will boot wit
Currently, on the hikey board, we have the adv7511 bridge wired
up to the kirin ade drm driver. Unfortunately, the kirin ade
core cannot generate accurate byteclocks for all pixel clock
values.
Thus if a mode clock is selected that we cannot calculate a
matching byteclock, the device will boot wit
Hi Benjamin,
Thank you for the patch. I've CC'ed the linux-api mailing list.
On Monday 13 Feb 2017 15:45:05 Benjamin Gaignard wrote:
> This is the core of simple allocator module.
> It aim to offert one common ioctl to allocate specific memory.
>
> version 2:
> - rebased on 4.10-rc7
>
> Signed-
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #33 from Reimar Imhof ---
(In reply to Michel Dänzer from comment #27)
> (In reply to Reimar Imhof from comment #26)
> > Together with comment #24 there is a render bug in kernel 4.8 that shows up
> > at 100% cpu load.
> > With kernel
On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard
wrote:
> This is the core of simple allocator module.
> It aim to offert one common ioctl to allocate specific memory.
>
> version 2:
> - rebased on 4.10-rc7
>
> Signed-off-by: Benjamin Gaignard
Why not ION? It's a bit a broken record question,
From: Chris Chiu
This new graphics card was failing to initialize with nouveau due to
an "unknown chipset" error.
Copy the GP106 configuration and rename for GP107/NV137. We don't
know for certain that this is fully correct, but brief desktop testing
suggests this is working fine.
Signed-off-by
On Tue, Feb 14, 2017 at 8:25 PM, John Stultz wrote:
> Currently, on the hikey board, we have the adv7511 bridge wired
> up to the kirin ade drm driver. Unfortunately, the kirin ade
> core cannot generate accurate byteclocks for all pixel clock
> values.
>
> Thus if a mode clock is selected that we
Hi Daniel,
On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
> > This is the core of simple allocator module.
> > It aim to offert one common ioctl to allocate specific memory.
> >
> > version 2:
> > - rebased on 4.10-rc7
> >
> > Sig
On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
>> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
>> > This is the core of simple allocator module.
>> > It aim to offert one common ioctl to allocate specific
On Tue, Feb 14, 2017 at 11:38 AM, Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 8:25 PM, John Stultz wrote:
>> Currently, on the hikey board, we have the adv7511 bridge wired
>> up to the kirin ade drm driver. Unfortunately, the kirin ade
>> core cannot generate accurate byteclocks for all pixel
On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran
wrote:
> On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
>> Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
>> > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
>> > >
>> > > Dhinakaran Pandiyan schree
On Tue, Feb 14, 2017 at 08:38:40PM +0100, Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 8:25 PM, John Stultz wrote:
> > Currently, on the hikey board, we have the adv7511 bridge wired
> > up to the kirin ade drm driver. Unfortunately, the kirin ade
> > core cannot generate accurate byteclocks for
On Sun, Feb 12, 2017 at 2:57 PM, Noralf Trønnes wrote:
> tinydrm will be merged the way it is now, unless someone points to
> something that is broken. But I collect your comments for a later
> cleanup patchset. It takes a lot of effort for me as an amateur to
> keeps this code up-to-date out-of-t
Hi Daniel,
On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart wrote:
> > On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
> >> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
> >>> This is the core of simple allocator module.
> >>
On Tue, Jan 17, 2017 at 01:55:50AM +0200, Laurent Pinchart wrote:
> Hi Maarten,
>
> Thank you for the patch.
>
> On Monday 16 Jan 2017 10:37:40 Maarten Lankhorst wrote:
>
> Could we please get a description ? Apart from that,
Typed something small and merged the first 3 patches from this series
On Fri, Feb 10, 2017 at 09:29:07AM -0700, Shuah Khan wrote:
> On 02/03/2017 01:06 AM, Daniel Vetter wrote:
> > On Thu, Feb 02, 2017 at 10:25:44AM -0700, Shuah Khan wrote:
> >> On 02/02/2017 01:32 AM, Jani Nikula wrote:
> >>> On Thu, 02 Feb 2017, Shuah Khan wrote:
> Change drm_helper_probe_sin
Hi Daniel,
On Tuesday 14 Feb 2017 21:03:07 Daniel Vetter wrote:
> On Tue, Jan 17, 2017 at 01:55:50AM +0200, Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 10:37:40 Maarten Lankhorst wrote:
> >
> > Could we please get a description ? Apart from that,
>
> Typed something small and merged the fi
On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> Hi Maxime,
>
> On 13 February 2017 at 10:54, Maxime Ripard
> wrote:
> > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> >> > This patch add a config to su
On Thu, Feb 09, 2017 at 09:55:22PM +, Emil Velikov wrote:
> On 9 February 2017 at 20:41, Thierry Reding wrote:
> > On Thu, Feb 09, 2017 at 06:08:10PM +0100, Daniel Vetter wrote:
> >> On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
> >> > On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thi
On Thu, Feb 09, 2017 at 03:19:07PM +, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return error code -ENOMEM from the malloc error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Applied for 4.12 to drm-misc-next, thanks.
-Daniel
> ---
https://bugs.freedesktop.org/show_bug.cgi?id=99815
--- Comment #1 from Klaus Kusche ---
I just checked: It seems that the problem does not depend on two active
outputs.
The gpu consumes roughly the same amount of power with just the laptop display.
--
You are receiving this mail because:
You ar
On Mon, Feb 13, 2017 at 04:47:01PM +, Russell King - ARM Linux wrote:
> On Mon, Feb 13, 2017 at 02:37:31PM +0100, Maarten Lankhorst wrote:
> > All for it, looks sane. The last hunk fails to apply because it's based on
> > an older version of page_flip, but easy enough to fix.
>
> Yes, it's bas
On Tue, Feb 14, 2017 at 11:45:54AM -0800, John Stultz wrote:
> On Tue, Feb 14, 2017 at 11:38 AM, Daniel Vetter wrote:
> > On Tue, Feb 14, 2017 at 8:25 PM, John Stultz wrote:
> >> Currently, on the hikey board, we have the adv7511 bridge wired
> >> up to the kirin ade drm driver. Unfortunately, th
Hi John,
On 14 February 2017 at 19:25, John Stultz wrote:
> +static enum drm_mode_status
> +drm_connector_check_crtc_modes(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + struct drm_device *dev = connector->dev;
> + const struc
I believe what's missing at this point is a mmiotrace of the NVIDIA
driver to make sure that there's nothing different about this GPU. If
you can make one (see https://wiki.ubuntu.com/X/MMIOTracing for a
guide - should end up ~100MB uncompressed), please send a compressed
one to mmio.du...@gmail.co
On Tue, Feb 14, 2017 at 12:22 PM, Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 11:45:54AM -0800, John Stultz wrote:
>>
>> Not following here. What do you mean by "put it into drivers"? Where?
>
> In your driver callback for ->mode_valid, call into a shared function to
> validate CRTC limits. Wh
On Tue, Feb 14, 2017 at 12:32 PM, Daniel Stone wrote:
> Hi John,
>
> On 14 February 2017 at 19:25, John Stultz wrote:
>> +static enum drm_mode_status
>> +drm_connector_check_crtc_modes(struct drm_connector *connector,
>> + struct drm_display_mode *mode)
>> +{
>> +
Hi Daniel,
On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote:
> On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> > On 13 February 2017 at 10:54, Maxime Ripard wrote:
> >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> >>> On Thursday 02 Feb 2017 11:31:56 Maxim
On Fri, Feb 10, 2017 at 11:26:22AM -0500, Harry Wentland wrote:
> Resending with CC to dri-devel as per Alex's suggestions. This
> might be of interest to a wider audience.
>
> These patches are first steps of addressing some of the problems
> in DC's atomic implementation. Please take a look and
The newly added DP driver links against the extcon core, which fails when
extcon is a module and this driver is not:
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_get_port_lanes':
cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x24): undefined reference to
`extcon_get_state'
cdn-dp-core
On Fri, Feb 10, 2017 at 07:07:45PM +0100, Boris Brezillon wrote:
> An HLCDC layers in Atmel's nomenclature is either a DRM plane or a 'Post
> Processing Layer' which can be used to output the results of the HLCDC
> composition in a memory buffer.
>
> atmel_hlcdc_layer.c was designed to be generic
On Mon, Feb 13, 2017 at 12:17:27PM -0500, Sean Paul wrote:
> On Mon, Feb 13, 2017 at 3:59 AM, Chris Wilson
> wrote:
> > On Mon, Feb 13, 2017 at 08:41:10AM +0100, Thierry Reding wrote:
> >> On Fri, Feb 10, 2017 at 07:59:13PM +, Chris Wilson wrote:
> >> > The warnings from parsing the EDID are
On Tue, Feb 14, 2017 at 02:49:21PM +0200, Jani Nikula wrote:
> From: Pierre-Louis Bossart
>
> 100% reproducible issue found on SKL SkullCanyon NUC with two external
> DP daisy-chained monitors in DP/MST mode. When turning off or changing
> the input of the second monitor the machine stops with a
1 - 100 of 127 matches
Mail list logo
