On Thu, Apr 05, 2018 at 07:49:44AM -0700, Matt Roper wrote:
> On Thu, Apr 05, 2018 at 05:15:13PM +0300, Joonas Lahtinen wrote:
> > + Some more Cc's based on IRC discussion
> >
> > Quoting Joonas Lahtinen (2018-04-05 16:46:51)
> > > + Dave for commenting from DRM subsystem perspective. I strongly b
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop
looking at them.
v2: Catch the plane->crtc case too
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst #v1
---
driver
From: Ville Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop looking at it.
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/sti/sti_gdp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/dri
From: Ville Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop looking at it.
Cc: Boris Brezillon
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hl
From: Ville Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop setting it.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 --
1 file changed, 2
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
v2: Catch a few more cases
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst #v1
---
drivers/gpu/drm/m
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop setting it.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Harry Wentland
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Harry Wen
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
From: Ville Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop setting it.
v2: s/fb/crtc/ in the commit message (Gerd)
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Daniel pointed out that the drm_framebuffer_put() in the plane cleanup
indicates that the driver doesn't shut things down cleanly. To do
that we should be able to just call drm_atomic_helper_shutdown(). No
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
Cc: Eric Anholt
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/vc4/vc4_crtc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b
From: Ville Syrjälä
omap_framebuffer_get_next_connector() uses plane->fb which we want to
deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
is unused just nuke the entire function.
Cc: Tomi Valkeinen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/omapdrm/omap_fb.c | 27
From: Ville Syrjälä
Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any
From: Ville Syrjälä
Clean up the ugly tmp->primary-> stuff in
__drm_mode_set_config_internal() with a local plane variable.
Cc: Daniel Vetter
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 19 ---
1 file changed, 12 insertions(+), 7
On 03/29/2018 09:39 AM, Daniel Vetter wrote:
> On Thu, Mar 29, 2018 at 9:35 AM, Philippe CORNU wrote:
>> Hi Daniel,
>>
>> On 03/27/2018 05:51 PM, Daniel Vetter wrote:
>>> On Mon, Feb 26, 2018 at 01:16:04PM +0100, Philippe Cornu wrote:
This patch clarifies the adjusted_mode documentation
Signed-off-by: Daniel Vetter
Cc: Linus Walleij
---
drivers/gpu/drm/tve200/tve200_display.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tve200/tve200_display.c
b/drivers/gpu/drm/tve200/tve200_display.c
index 108f3b2b5d25..e8723a2412a6 100644
--- a/d
Less hits to go through when I git grep over all drivers. These
callbacks are optional.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 35 ---
1 file changed, 35 deletions(-)
dif
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/pl111/pl111_display.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 1fee578e05b0..19b0d006a54a 100644
--- a/drivers/g
Hi all,
Somewhat motivated (but only really tangentially) by the dirtyfb
discussion with Rob and Thomas I started digging around in the various
driver implementations for implicit vs. explicit fencing.
There's definitely a huge pile of drivers which don't do any implicit
fencing at all - not sure
I've done a lot of history digging. The first signs of this
optimization was introduced in i915:
commit 25067bfc060d1a481584dcb51ef4b5680176ecb6
Author: Gustavo Padovan
Date: Wed Sep 10 12:03:17 2014 -0300
drm/i915: pin sprite fb only if it changed
without much justification. Pinning alre
Signed-off-by: Daniel Vetter
Cc: Marek Vasut
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index b9c7507813db..ffe5137ccaf8 100644
--- a/drivers/gpu/drm/mxsfb
Note that a pile of drivers don't seem to take implicit fencing into
account, or at least don't call drm_atoimc_set_fence_for_plane().
Cc'ing relevant people, or at least some. Some drivers also look like
they don't disable implicit fencing (e.g. amdgpu) because the explicit
fences and implicit fen
There's nothing tinydrm specific to this, and there's a few more
copies of the same in various other drivers.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: David Lechner
Cc: "Noralf Trønnes"
Cc: Daniel Vetter
Cc: Shawn Guo
Cc: Ne
Same justification as for drm_gem_fb_prepare_fb.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_plane.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ce39390be389.
Again same justification as for drm_gem_fb_prepare_fb().
Definitely needs some testing because Rob doesn't remember why he did
this, and Google/git.fd.o or anything also doesn't shed some light on
it.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lis
Just realized Joonas had some other comments down at the bottom that I
missed originally...
On Thu, Apr 05, 2018 at 08:06:23AM -0700, Matt Roper wrote:
> On Thu, Apr 05, 2018 at 07:49:44AM -0700, Matt Roper wrote:
> > On Thu, Apr 05, 2018 at 05:15:13PM +0300, Joonas Lahtinen wrote:
> > > + Some mo
https://bugs.freedesktop.org/show_bug.cgi?id=105869
--- Comment #4 from Lyberta ---
Number of platforms 1
Platform Name Clover
Platform Vendor Mesa
Platform Version
On 2018-03-30 04:51 AM, Chunming Zhou wrote:
> include/drm/amdgpu_drm.h |4
> 1 file changed, 4 insertions(+)
>
> New commits:
> commit 2fa58c77fb9e563219f8ec647b9ddf52f3390ed2
> Author: Rex Zhu
> Date: Tue Mar 20 14:08:09 2018 +0800
>
> headers: sync up amdgpu_drm.h with drm-nex
On Thu, Apr 05, 2018 at 06:13:54PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
> them.
>
> v2: Catch a few more cases
>
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Sig
On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart
wrote:
> Hi Vladimir,
>
> On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
>> On 03/27/2018 01:10 PM, jacopo mondi wrote:
>> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 11:57 AM, jacopo
On Thu, Apr 05, 2018 at 06:13:48PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop
> looking at them.
>
> v2: Catch the plane->crtc case too
>
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedeskto
On Thu, Apr 05, 2018 at 06:13:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->crtc on atomic drivers. Stop looking at it.
>
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
>
On Thu, Apr 05, 2018 at 06:13:50PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->crtc on atomic drivers. Stop looking at it.
>
> Cc: Boris Brezillon
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcd
On Thu, Apr 05, 2018 at 06:13:57PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb on atomic drivers. Stop looking at it.
>
> Daniel pointed out that the drm_framebuffer_put() in the plane cleanup
> indicates that the driver doesn't shut things down cleanly.
On Wed, Apr 04, 2018 at 07:27:21PM -0400, Lyude Paul wrote:
> As it turns out, the aux block being off was not the real problem here,
> as transition from D3 to D0 is mandated by the DP spec to take a maximum
> of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs.
> The real probl
On Thu, Apr 05, 2018 at 06:13:51PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb on atomic drivers. Stop setting it.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Harry Wentland
> Cc: amd-...@lists.freedesktop.org
> S
On Thu, Apr 05, 2018 at 06:13:52PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
> them.
>
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Maarten Lankhorst
There's a bunch more hits I have:
- 2x a coment with "Both c
On Thu, Apr 05, 2018 at 06:13:53PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->crtc on atomic drivers. Stop setting it.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Maarten
On Thu, Apr 05, 2018 at 06:13:55PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->crtc on atomic drivers. Stop setting it.
>
> v2: s/fb/crtc/ in the commit message (Gerd)
>
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.o
On Thu, Apr 05, 2018 at 06:13:56PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
> them.
>
> Cc: Eric Anholt
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
> ---
> driv
On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> omap_framebuffer_get_next_connector() uses plane->fb which we want to
> deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
> is unused just nuke the entire function.
>
> Cc: Tomi Valkeine
On Thu, Apr 05, 2018 at 06:13:59PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Stop playing around with plane->crtc/fb/old_fb with atomic
> drivers. Make life a lot simpler when we don't have to do the
> magic old_fb vs. fb dance around plane updates. That way we
> can't risk plane->fb
On Thu, Apr 05, 2018 at 06:14:00PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Clean up the ugly tmp->primary-> stuff in
> __drm_mode_set_config_internal() with a local plane variable.
>
> Cc: Daniel Vetter
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
I think this c
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
v2: Fix up the comment in intel_crtc_active() and
nuke the rest of the stale comments (Daniel)
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst #v1
Reviewed-by: Dan
On 04/05/2018 05:44 PM, Daniel Vetter wrote:
Less hits to go through when I git grep over all drivers. These
callbacks are optional.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 35 -
https://bugs.freedesktop.org/show_bug.cgi?id=104412
--- Comment #15 from S.H. ---
(In reply to Harry Wentland from comment #13)
> The problem with 4k60 being blocked due to a BIOS bit should be fixed now. I
> recommend trying the drm-next-4.17-wip from
> https://cgit.freedesktop.org/~agd5f/linux
On Thu, 2018-04-05 at 19:38 +0300, Ville Syrjälä wrote:
> On Wed, Apr 04, 2018 at 07:27:21PM -0400, Lyude Paul wrote:
> > As it turns out, the aux block being off was not the real problem here,
> > as transition from D3 to D0 is mandated by the DP spec to take a maximum
> > of 1ms, whereas we're
On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote:
> With damage property in drm_plane_state, this patch adds helper iterator
> to traverse the damage clips. Iterator will return the damage rectangles
> in framebuffer, plane or crtc coordinates as need by driver
> implementation.
>
> Si
On 2018-04-05 12:41 PM, Daniel Vetter wrote:
> On Thu, Apr 05, 2018 at 06:13:51PM +0300, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> We want to get rid of plane->fb on atomic drivers. Stop setting it.
>>
>> Cc: Alex Deucher
>> Cc: "Christian König"
>> Cc: "David (ChunMing) Zhou"
>> Cc:
Hi Mauro,
Thank you for the patch.
On Thursday, 5 April 2018 20:54:15 EEST Mauro Carvalho Chehab wrote:
> Add stubs for omapfb_dss.h, in the case it is included by
> some driver when CONFIG_FB_OMAP2 is not defined.
The omapfb driver doesn't include any asm/ header, so it should probably build
f
>
> On Wed, Apr 04, 2018 at 04:49:05PM -0700, Deepak Rawat wrote:
> > Hi All,
> >
> > This is extension to Lukasz Spintzyk earlier draft of damage interface for
> drm.
> > Bascially a new plane property is added called "DAMAGE_CLIPS" which is
> simply
> > an array of drm_rect (exported to userspac
https://bugs.freedesktop.org/show_bug.cgi?id=105910
Bug ID: 105910
Summary: Graphical artifacts on unresposible surfaces on AMD
Radeon RX 570
Product: Mesa
Version: 17.3
Hardware: x86-64 (AMD64)
OS: Linux (A
https://bugs.freedesktop.org/show_bug.cgi?id=105910
--- Comment #1 from Ivan Chebykin ---
Created attachment 138628
--> https://bugs.freedesktop.org/attachment.cgi?id=138628&action=edit
Artifacts when window is opening
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105910
--- Comment #2 from Ivan Chebykin ---
Created attachment 138629
--> https://bugs.freedesktop.org/attachment.cgi?id=138629&action=edit
Xeyes render artifacts instead of background
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=105910
--- Comment #3 from Ivan Chebykin ---
Created attachment 138630
--> https://bugs.freedesktop.org/attachment.cgi?id=138630&action=edit
dmesg full log
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Rob,
On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote:
> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote:
> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> >> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladim
https://bugs.freedesktop.org/show_bug.cgi?id=105910
--- Comment #4 from Ivan Chebykin ---
Created attachment 138631
--> https://bugs.freedesktop.org/attachment.cgi?id=138631&action=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105910
--- Comment #5 from Ivan Chebykin ---
Created attachment 138632
--> https://bugs.freedesktop.org/attachment.cgi?id=138632&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105912
Bug ID: 105912
Summary: [IGT] gem_exec_reloc@cpu-30 iwlwifi :00:14.3: Scan
failed! ret -110 dmesg-warn
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=105910
Ivan Chebykin changed:
What|Removed |Added
Summary|Graphical artifacts on |Graphical artifacts on
https://bugs.freedesktop.org/show_bug.cgi?id=100105
--- Comment #4 from Jan Vesely ---
Lowering CL requirements combined with the following pull requests:
https://github.com/Theano/libgpuarray/pull/571
https://github.com/Theano/libgpuarray/pull/570
Results in:
Ran 4970 tests in 1158.909s
OK (SK
From: Ville Syrjälä
We want to stop using plane->fb with atomic driver, so stop looking at
it.
I have no idea what this code is trying to achieve. There is no
corresponding check in the enable path. Also since
arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
to assuming that I
From: Ville Syrjälä
The only caller of vmw_kms_update_implicit_fb() is the page_flip
hook which itself gets called with the plane mutex already held.
Hence we can look at plane->state safely. Toss in a lockdep assert
to make the situation more clear.
Cc: Thomas Hellstrom
Cc: Sinclair Yeh
Cc: V
From: Ville Syrjälä
Instead of looking at plane->fb let's look at the proper new
plane state.
Not that the code makes a ton of sense. It's only going through the
crtcs in the atomic state, so assuming not all of them are included
we're not even calculating the total bandwidth here. Also we're
no
From: Ville Syrjälä
Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_upda
From: Ville Syrjälä
plane->fb/old_fb/crtc should no longer be used by atomic
drivers. Stop messing about with them.
TODO: Squash with the core/helper patch?
Cc: Thomas Hellstrom
Cc: Sinclair Yeh
Cc: VMware Graphics
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vmwgfx/
From: Ville Syrjälä
Instead of looking at the (soon to be deprecated) plane->fb we'll
examing plane->state->fb instead. We can do this because
vmw_du_crtc_atomic_check() prevents us from enabling a crtc
without the primary plane also being enabled.
Due to that same reason, I'm actually not sure
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop setting it.
Cc: Thomas Hellstrom
Cc: Sinclair Yeh
Cc: VMware Graphics
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 --
2 f
On Thu, Apr 5, 2018 at 7:06 PM, Thomas Hellstrom wrote:
> On 04/05/2018 05:44 PM, Daniel Vetter wrote:
>>
>> Less hits to go through when I git grep over all drivers. These
>> callbacks are optional.
>>
>> Signed-off-by: Daniel Vetter
>> Cc: VMware Graphics
>> Cc: Sinclair Yeh
>> Cc: Thomas Hel
On Thu, Apr 5, 2018 at 7:02 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
> them.
>
> v2: Fix up the comment in intel_crtc_active() and
> nuke the rest of the stale comments (Daniel)
>
> Cc: Daniel Vetter
> Signed-off-
https://bugs.freedesktop.org/show_bug.cgi?id=105913
Bug ID: 105913
Summary: [IGT] igt@gem_shrink@pread Test assertion failure
function gem_read, file ioctl_wrappers.c
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to stop using plane->fb with atomic driver, so stop looking at
> it.
>
> I have no idea what this code is trying to achieve. There is no
> corresponding check in the enable path. Also since
> arc_pgu
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #6 from Chí-Thanh Christopher Nguyễn ---
It is a notebook and I am using the internal LVDS panel.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel ma
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #7 from Chí-Thanh Christopher Nguyễn ---
The notebook also has HDMI and VGA connectors, but I do not use them currently.
--
You are receiving this mail because:
You are the assignee for the bug._
>
> From: Ville Syrjälä
>
> Instead of looking at plane->fb let's look at the proper new
> plane state.
>
> Not that the code makes a ton of sense. It's only going through the
> crtcs in the atomic state, so assuming not all of them are included
> we're not even calculating the total bandwidth
https://bugs.freedesktop.org/show_bug.cgi?id=105883
--- Comment #6 from Harry Wentland ---
On Ubuntu the kernel log keeps appending to /var/log/kern.log, but that might
look different on different distros.
If you have a luxury of a second system you might be able to ssh into the Ryzen
system and
On 04/05/2018 09:50 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls o
On Thu, Apr 05, 2018 at 10:08:57PM +0200, Daniel Vetter wrote:
> On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We want to stop using plane->fb with atomic driver, so stop looking at
> > it.
> >
> > I have no idea what this code is trying to achiev
On Thu, Apr 05, 2018 at 10:15:57PM +0200, Thomas Hellstrom wrote:
> On 04/05/2018 09:50 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Instead of plane->fb (which we're going to deprecate for atomic drivers)
> > we need to look at plane->state->fb. The maze of code leading to
> > vmw_kms
https://bugs.freedesktop.org/show_bug.cgi?id=105915
Bug ID: 105915
Summary: [IGT] igt@kms_cursor_crc@cursor-128x128-rapid-movement
/ cursor-256x256-rapid-movement igt-debugfs-WARNING:
Warning on condition crc->crc[i] == 0x in
On Thu, Apr 05, 2018 at 08:15:05PM +, Deepak Singh Rawat wrote:
>
> >
> > From: Ville Syrjälä
> >
> > Instead of looking at plane->fb let's look at the proper new
> > plane state.
> >
> > Not that the code makes a ton of sense. It's only going through the
> > crtcs in the atomic state, so
Pulling this out of the shadows again.
We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
from Matt and Dongwong.
At least from the intel side there seems to be the idea to just have 1
special device that can handle cross-gues/host sharing for all kinds
of hypervisors, so I gues
From: Ville Syrjälä
Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_upda
https://bugs.freedesktop.org/show_bug.cgi?id=105913
Chris Wilson changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
When doing a modeset where the sink is transitioning from D3 to D0 , it
would sometimes be possible for the initial power_up_phy() to start
timing out. This would only be observed in the last action before the
sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
originally thought t
> 2018-04-05 13:39 GMT+02:00 Laurent Pinchart <
laurent.pinch...@ideasonboard.com>:
> Hi Andrzej,
>
> On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote:
>> On 05.04.2018 12:28, Laurent Pinchart wrote:
>>> On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote:
> Hi,
>
From: Lin Huang
We need to enable video before analogix_dp_is_video_stream_on(), so
we can get the right video stream status.
We needed to increase the delay in the timeout loop because there is
random "Timeout of video streamclk ok" message happen when debug edp
panel, this time do not define i
From: zain wang
Enhanced mode is required by the eDP 1.2 specification, and not doing it
early could result in a period of time where we have a link transmitting
idle packets without it. Since there is no reason to disable it, we just
enable it at the beginning of link training and then keep it o
Em Thu, 05 Apr 2018 21:41:18 +0300
Laurent Pinchart escreveu:
> Hi Mauro,
>
> Thank you for the patch.
>
> On Thursday, 5 April 2018 20:54:15 EEST Mauro Carvalho Chehab wrote:
> > Add stubs for omapfb_dss.h, in the case it is included by
> > some driver when CONFIG_FB_OMAP2 is not defined.
>
From: zain wang
According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker
must first detect that the HPD signal is asserted high by the Downstream
Device before establishing a link with it.
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: T
From: "Kristian H. Kristensen"
To improve PSR exit latency, we speculatively start exiting when we
receive input events. Occasionally, this may lead to false positives,
but most of the time we get a head start on coming out of PSR. Depending
on how userspace takes to produce a new frame in respon
From: Tomasz Figa
If we change the state first and reschedule later, we might have the
work executed according to previous scheduled time and end up with PSR
re-enabled instantly. Let's cancel the work before changing the state.
While at it, consolidate psr_disable_handler() to just call
rockchi
From: Douglas Anderson
The code in analogix_dp_transfer() that was supposed to print out:
AUX CH error happened
Was actually dead code. That's because the previous check (whether
the interrupt status indicated any errors) would have hit for all
errors anyway.
Let's combine the two error check
Even though msm_gem_put_iova() is currently a NOP function, the caller
should pass in the address space pointer it used to obtain the object.
Other call sites were changed in 8bdcd949bbe7e ("drm/msm: pass
address-space to _get_iova() and friends"), but this one seems to have
been forgotten.
Signe
From: Tomasz Figa
It looks like the driver subsystem detaches devices from power domains
at shutdown without consent of the drivers. This means that we might have
our power domain turned off behind our back and the only way to avoid
problems is to stop doing any hardware programming at some point
From: Tomasz Figa
It is not used anymore after last changes and it was not even correct to
begin with as it assumed a 1:1 relation between a CRTC and encoder,
while in fact a CRTC can be attached to multiple encoders.
Signed-off-by: Tomasz Figa
Signed-off-by: Thierry Escande
Signed-off-by: Enr
From: zain wang
When we enable bridge failed, we have to retry it, otherwise we would get
the abnormal display.
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Balletbo i Serra
Tested-by
From: Lin Huang
When panel is shut down, we should make sure edp can be disabled to avoid
undefined behavior.
Cc: Stéphane Marchesin
Signed-off-by: Lin Huang
Signed-off-by: zain wang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Signed-off-by: Enric Bal
Hi Daniel,
On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote:
> On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
> wrote:
> > Hello,
> >
> > We're trying to use DisplayLink USB2-to-HDMI adapter to render
> > GPU-accelerated graphics.
> > Hardware setup is as simple as a devboard + DisplayLi
From: Lin Huang
There was a 1ms delay to detect the hpd signal, which is too short to
detect a short pulse. This patch extends this delay to 100ms.
Cc: Stéphane Marchesin
Cc: 征增 王
Signed-off-by: Lin Huang
Signed-off-by: Sean Paul
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Si
101 - 200 of 266 matches
Mail list logo
