Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl+: Use scaling amount for plane data rate calculation (v4)

Reviewed-by: Kumar Mahesh On Friday 20 May 2016 03:33 AM, Matt Roper wrote: From: "Kumar, Mahesh" if downscaling is enabled plane data rate increases according to scaling amount. take scaling amount under consideration while calculating plane

Re: [Intel-gfx] [PATCH 3/4] drm/i915/skl+: calculate plane pixel rate (v4)

Reviewed-by: Kumar Mahesh On Tuesday 17 May 2016 04:22 AM, Matt Roper wrote: From: "Kumar, Mahesh" Don't use pipe pixel rate for plane pixel rate. Calculate plane pixel according to formula adjusted plane_pixel_rate = adjusted

Re: [Intel-gfx] [PATCH 2/4] drm/i915/skl+: calculate ddb minimum allocation (v5)

On Friday 27 May 2016 03:43 AM, Matt Roper wrote: From: "Kumar, Mahesh" don't always use 8 ddb as minimum, instead calculate using proper algorithm. v2: optimizations as per Matt's comments. v3 (by Matt): - Fix boolean logic for !fb test in skl_ddb_min_alloc()

[Intel-gfx] [Regression report] Weekly regression report WW22

This week's regressions +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 95736 | [IVB bisected] *ERROR*

[Intel-gfx] [PATCH 18/26] drm/hisilicon: Implement some semblance of vblank event handling

atomic_flush seems to be the right place, but I'm not entirely sure whether this will catch them all. It could be that when disabling the crtc we'll miss the vblank. While at it nuke the dummy functions. v2: Be more robust and either arm, when the CRTC is on, or just send the event out right

[Intel-gfx] [PATCH 20/26] drm/atomic: kerneldoc for drm_atomic_crtc_needs_modeset

Just a bit of drive-by ocd. Signed-off-by: Daniel Vetter --- include/drm/drm_atomic.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index d9504dfcd1cc..465a1212f4f0 100644 --- a/include/drm/drm_atomic.h

[Intel-gfx] [PATCH 22/26] drm/i915: Signal drm events for atomic

This is part of what atomic must implement. And it's also required to be able to use the helper nonblocking support. v2: Always send out the drm event, remove the planes_changed check. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 13

[Intel-gfx] [PATCH 19/26] drm/sun4i: Implement some semblance of vblank event handling

atomic_flush seems to be the right place, right after we commit the plane updates. Again use the fullproof version, since the pipe might be off. Cc: Boris Brezillon Cc: Maxime Ripard Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 24/26] drm/rockchip: convert to helper nonblocking atomic commit

So totally untested ... v2: Fixes from Tomeu. v3: Send out vblank events correctly when shutting down a crtc for good. This is part of the atomic interface contract. v4: Properly protect vop->event. Cc: Tomeu Vizoso Cc: Mark yao

[Intel-gfx] [PATCH 25/26] drm/rockchip: Nuke pending event handling in preclose

This is now handled by the core, drivers can totally ignore lifetime issues of drm events. Cc: Tomeu Vizoso Cc: Mark yao Signed-off-by: Daniel Vetter --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 22

[Intel-gfx] [PATCH 26/26] drm/virtio: Don't reinvent a flipping wheel

Now that the core helpers support nonblocking atomic commits there's no need to invent that wheel separately (instead of fixing the bug in the atomic implementation of virtio, as it should have been done!). Cc: Gerd Hoffmann Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 16/26] drm/hdlcd: Use helper support for nonblocking commits

Again, just doing them as blocking commits isn't cool. From a cursory check hdlcd does seem to at least try to handle drm_pending_vblank_event, so hopefully this works. Cc: Liviu Dudau Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 10/26] drm: Consolidate crtc arrays in drm_atomic_state

It's silly to have 2 mallocs when we could tie these two together. Also, Gustavo adds another one in his per-crtc out-fence patches. And I want to add more stuff here for nonblocking commit helpers. In the future we can use this to store a pointer to the preceeding state, making an atomic update

[Intel-gfx] [PATCH 05/26] drm/vc4: Use for_each_plane_in_state

We want to hide drm_atomic_stat internals a bit better. Cc: Eric Anholt Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vc4/vc4_kms.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c

[Intel-gfx] [PATCH 04/26] drm/rcar-du: Use for_each_*_in_state

We want to hide drm_atomic_state internals better. Cc: Laurent Pinchart Signed-off-by: Daniel Vetter --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 20 2 files

[Intel-gfx] [PATCH 11/26] drm/fence: add fence to drm_pending_event

From: Gustavo Padovan Now a drm_pending_event can either send a real drm_event or signal a fence, or both. It allow us to signal via fences when the buffer is displayed on the screen. Which in turn means that the previous buffer is not in use anymore and can be

[Intel-gfx] [PATCH 06/26] drm/atomic: Add __drm_atomic_get_current_plane_state

... and use it in msm Again just want to encapsulate drm_atomic_state internals a bit. The const threading is a bit awkward in vc4 since C sucks, but I still think it's worth to enforce this. Eventually I want to make all the obj->state pointers const too, but that's a lot more work ... Cc: Eric

[Intel-gfx] [PATCH 23/26] drm/i915: Roll out the helper nonblock tracking

Right now still all blocking, no worker anywhere to be seen. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH 21/26] drm/atomic-helper: nonblocking commit support

Design ideas: - split up the actual commit into different phases, and have completions for each of them. This will be useful for the future when we want to interleave phases much more aggressively, for e.g. queue depth > 1. For not it's just a minimal optimization compared to current

[Intel-gfx] [PATCH 02/26] drm/i915: Use drm_atomic_get_existing_plane_state

We want to encapsulate the drm_atomic_state internals. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_atomic.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c

[Intel-gfx] [PATCH 09/26] drm: Consolidate plane arrays in drm_atomic_state

It's kinda pointless to have 2 separate mallocs for these. And when we add more per-plane state in the future it's even more pointless. Right now there's no such thing planned, but both Gustavo's per-crtc fence patches, and some nonblocking commit helpers I'm playing around with will add more

[Intel-gfx] [PATCH 17/26] drm/fsl-du: Implement some semblance of vblank event handling

No idea how exactly fsl-du commits hw state changes, but here in flush is probably the safest place. While at it nuke the dummy functions. v2: Be more robust and either arm, when the CRTC is on, or just send the event out right away. Cc: Stefan Agner Signed-off-by: Daniel

[Intel-gfx] [PATCH 13/26] drm/arc: Nuke event_list

This is just used for cleanup in preclose, and with the reworked event handling code this is now done properly by the core. Nuke it! But it also shows that arc totally fails at sending out drm events for flips. Next patch will hack that up. Cc: Carlos Palminha Cc: Alexey

[Intel-gfx] [PATCH 15/26] drm/arc: Implement nonblocking commit correctly

Committing with block it is not. Thanks to the fixed up vblank event handling we can just use the helper support for nonblocking commits now. Cc: Carlos Palminha Cc: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 08/26] drm: Consolidate connector arrays in drm_atomic_state

It's kinda pointless to have 2 separate mallocs for these. And when we add more per-connector state in the future it's even more pointless. Right now there's no such thing planned, but both Gustavo's per-crtc fence patches, and some nonblocking commit helpers I'm playing around with will add more

[Intel-gfx] [PATCH 12/26] drm/atomic-helper: Massage swap_state signature somewhat

- dev is redundant, we have state->atomic - add stall parameter, which must be set when swapping needs to stall for preceeding commits to stop looking at ->state pointers. Currently all drivers need this to be, just prep work for a glorious future. Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 14/26] drm/arc: Actually bother with handling atomic events.

The drm core has a nice ready-made helper for exactly the simple case where it should fire on the next vblank. Note that arming the vblank event in _begin is probably too early, and might easily result in the vblank firing too early, before the new set of planes are actually disabled. But that's

[Intel-gfx] [PATCH 03/26] drm/msm: Use for_each_*_in_state

We want to hide drm_atomic_state internals Cc: Rob Clark Signed-off-by: Daniel Vetter --- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 20 +++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 12 +++---

[Intel-gfx] [PATCH 07/26] drm/exynos: Use for_each_crtc_in_state

We want to hide drm_atomic_state internals better. Cc: Inki Dae Signed-off-by: Daniel Vetter --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 01/26] drm/atomic-helper: use for_each_*_in_state more

This avois leaking drm_atomic_state internals into the helpers. The only place where this still happens after this patch is drm_atomic_helper_swap_state(). It's unavoidable there, and maybe a good indicator we should actually move that function into drm_atomic.c. Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 00/26] RFC: generic nonblocking support in the atomic helpers

Hi all, So I finally unlazied and implemented generic nonblocking atomic commit support in the atomic helpers. Still an early draft, but stopped being a fireworks show on i915 at least. Rockchip still oopses somewhere, virtio conversion is entirely untested. Same for arc/hdlcd/fsl-du/sun4i. All

Re: [Intel-gfx] 4.7-rc0: redshift stopped working on intel display

Could you try to apply the following patch [1], hopefully this fixes the issue for you. [1] https://patchwork.freedesktop.org/patch/89111/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org