On 09/08/2016 08:30 AM, Chris Wilson wrote:
> On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
>> amdgpu-kms uses shared fences for its prime exported dmabufs,
>> instead of an exclusive fence. Therefore we need to wait for
>> all fences of the dmabuf reservat
-kms for correct prime sync during
pageflipping under DRI3/Present.
Should fix https://bugs.freedesktop.org/show_bug.cgi?id=95472
at least for page-flipped presentation.
Suggested-by: Michel Dänzer
Signed-off-by: Mario Kleiner
Cc: Michel Dänzer
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: David
property updates.
Signed-off-by: Mario Kleiner
Cc: Daniel Vetter
Cc: # v4.6+
---
drivers/gpu/drm/drm_atomic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8d2f111..3a985d6 100644
--- a/drivers/gpu/drm
On 08/18/2016 09:21 PM, Marek Olšák wrote:
> On Thu, Aug 18, 2016 at 4:23 AM, Michel Dänzer wrote:
>> Maybe the rasterization as two triangles results in bad PCIe bandwidth
>> utilization. Using the asynchronous DMA engine for these transfers would
>> probably be ideal, but having the 3D
On 08/18/2016 04:32 AM, Michel Dänzer wrote:
> On 18/08/16 08:51 AM, Mario Kleiner wrote:
>>
>> That's what the ati-ddx/amdgpu-ddx does at the moment, as it detects the
>> mismatch in tiling flags and uses the DRI3/Present copy path instead of
>> the pageflip path. The
To pick this up again after a week of manic testing :)
On 08/18/2016 04:23 AM, Michel Dänzer wrote:
> On 18/08/16 01:12 AM, Mario Kleiner wrote:
>>
>> Intel as display gpu + nouveau for render offload worked nicely
>> on intel-ddx with page flipping, proper timing, dmabuf
On 08/17/2016 07:43 PM, Alex Deucher wrote:
> On Wed, Aug 17, 2016 at 12:35 PM, Mario Kleiner
> wrote:
>> On 08/17/2016 06:27 PM, Christian König wrote:
>>>>
>>>> AMD uses copy swaps because radeon/amdgpu kms can't switch the
>>>> scanout m
On 08/17/2016 07:02 PM, Christian König wrote:
> Am 17.08.2016 um 18:35 schrieb Mario Kleiner:
>> On 08/17/2016 06:27 PM, Christian König wrote:
>>>> AMD uses copy swaps because radeon/amdgpu kms can't switch the
>>>> scanout mode from tiled to linear on t
efresh from the up to date dmabuf in system RAM.
Btw. i'll be offline for the next few hours, just wanted to get this out
now.
thanks,
-mario
>
> Regards,
> Christian.
>
> Am 17.08.2016 um 18:12 schrieb Mario Kleiner:
>> Hi,
>>
>> i spent some time playing with DR
back to GTT, then unpinning again, so the
followup pinning into VRAM will actually upload an up
to date display buffer from dmabuf GTT backing store.
During the pinning into GTT, we skip the actual data move
from VRAM to GTT to avoid a needless bo copy of stale
image data.
Signed-off-by: Mario
back to GTT, then unpinning again, so the
followup pinning into VRAM will actually upload an up
to date display buffer from dmabuf GTT backing store.
During the pinning into GTT, we skip the actual data move
from VRAM to GTT to avoid a needless bo copy of stale
image data.
Signed-off-by: Mario
Hi,
i spent some time playing with DRI3/Present + PRIME for testing
how well it works for Optimus/Enduro style setups wrt. page flipping
on the current kernel/mesa/xorg. I want page flipping, because
neuroscience/medical applications need the reliable timing/timestamping
and tear free
Cc'ing Daniel Stone and Pekka Paalanen, because this relates to wayland.
Wrt. having a new pageflip parameter struct, i wonder if it wouldn't
make sense to then already prepare some space in it for specifying an
absolute target time, e.g., in u64 microseconds? Or make this part of
the atomic
Hi Michel,
sorry for the super-late reply, i was just catching up with all the
mails and discussions, starting in June, leading to this patch set.
Looks all pretty good.
I'll look at this radeon patch and 2/6 for amdgpu later this week when i
have a fresh brain and enough "obsessive
On 08/03/2016 02:03 PM, Mario Kleiner wrote:
> On 08/03/2016 08:09 AM, Daniel Vetter wrote:
>> On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote:
>>> On 6 July 2016 at 20:05, Mario Kleiner
>>> wrote:
>>>> For DP sinks which don't expose color depth
On 08/03/2016 08:09 AM, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote:
>> On 6 July 2016 at 20:05, Mario Kleiner wrote:
>>> For DP sinks which don't expose color depth via EDID, use
>>> the drm_dp_sink_bpc() helper to
6 Jul 2016 12:05:43 +0200
From: Mario Kleiner <mario.kleiner...@gmail.com>
To: dri-devel at lists.freedesktop.org
CC: mario.kleiner.de at gmail.com
Updated series to fix the regressions introduced into stable
kernels for active Displayport to dual-link DVI converters and
for active Displa
Add missing drm_crtc_vblank_on/off() calls so vblank irq
handling/updating/timestamping never runs with a crtc shut down
or during its shutdown/startup, as that causes large jumps in
vblank count and trouble for compositors.
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
---
drivers/gpu/drm/vc4
On top of the interlaced video mode fix and with some additional
adjustments, this now works well. It has almost the same accuracy
as on regular progressive scan modes.
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 21 -
1 file changed, 8
We can't handle doublescan modes at the moment, so if
userspace tries to set one, reject the mode set.
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4
the vblank timestamping constants and entries in
the mode->crtc_xxx fields needed for precise vblank timestamping.
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_hdmi.c | 29 +++--
2 fi
We already don't expose such modes to userspace, but make
sure userspace can't sneak some interlaced mode in.
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dpi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers
Hi Eric and all,
this batch prevents setting modes one shouldn't set,
adds precise vblank timestamping for interlaced video
modes, and one fix for vblank en/disable during crtc
en/disable.
All successfully tested, also with timing measurement equipment,
on the RPi 2B.
Thanks,
-mario
it nicely. The patch currently applies cleanly to drm-fixes and
drm-next and is
Reviewed-and-tested-by: Mario Kleiner
When we are at it, could somebody please look at that updated series of
my Displayport color depth fixes ("EDID/DP fixes for proper bpc
detection of displays.") i
On 07/12/2016 05:02 PM, Lionel Landwerlin wrote:
> On 12/07/16 13:11, Mario Kleiner wrote:
>> On 07/12/2016 12:50 PM, Lionel Landwerlin wrote:
>>> Hi Mario,
>>>
>>
>> Hi Lionel,
>>
>>> There was a couple of patch to fix this issue :
>>&g
to be already part of 4.7-rc7, the final rc afaik?
thanks,
-mario
> Cheers,
>
> -
> Lionel
>
> On 12/07/16 11:33, Mario Kleiner wrote:
>> Updating legacy gamma tables, e.g., via RandR doesn't work at all
>> as of Linux 4.7-rc6.
>>
>> Reason seems to
Ironlake to confirm the
fix apparently doesn't break anything under X11.
Signed-off-by: Mario Kleiner
Cc: Maarten Lankhorst
Cc: Lionel Landwerlin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu
Hi Eric,
thanks for all the infos and help! Both your patches look good and i
have successfully tested them on top of with my vblank timestamping patch.
So for both:
Reviewed-and-tested-by: Mario Kleiner
Will you squash 2/2 into my patch or should i resend my patch with yours
squashed
On 07/06/2016 03:05 PM, Chris Wilson wrote:
> On Wed, Jul 06, 2016 at 12:17:55PM +0200, Mario Kleiner wrote:
>> Since i pulled the current drm-next tree i see strong flicker and
>> visual corruption during pageflipping, both in my own app, but also
>> in KDE4 and KDE
A strange one. In Linux 4.7-rc4, at least as build by the Ubuntu
mainline ppa, gamma table updates via RandR don't work. No errors are
reported and the X-Server thinks everything went well, but on Intel
Ironlake and Ivybridge the updates don't have any visual effect.
The same problem doesn't
Since i pulled the current drm-next tree i see strong flicker and visual
corruption during pageflipping, both in my own app, but also in KDE4 and
KDE5 Plasma with desktop composition enabled. This happens on both Intel
HD Ironake mobile (Apple MBP 2010) and HD-4000 Ivybridge mobile (Apple
ill not be enabled on the host"
So if we don't know the bit depth of the display from additional
colorimetry info we should assume 8 bpc / 24 bpp by default.
This patch adds info->bpc = 8 assignement for that case.
Signed-off-by: Mario Kleiner
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Dan
for HDMI, DVI and VGA.
Signed-off-by: Mario Kleiner
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_dp.c | 7 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed,
MiniDP->dual-link DVI
active adapter, and a Apple MiniDP->VGA active adapter.
Signed-off-by: Mario Kleiner
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 90 +
include/drm/drm_dp_helper.h | 6 +++
2 f
nk bpc detection will be handled for future
kernels in a separate series of patches.
Please backport to stable.
Signed-off-by: Mario Kleiner
Acked-by: Jani Nikula
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 20 +---
ng the 6 bpc + dithering
is selected.
This patch should be backported to stable.
Signed-off-by: Mario Kleiner
Cc: stable at vger.kernel.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/
Updated series to fix the regressions introduced into stable
kernels for active Displayport to dual-link DVI converters and
for active Displayport to VGA converters. Also to fix this stuff
better for Linux 4.8.
Patch 1 + 2 are needed to fix the regressions in the stable
kernels. These are meant
On 06/23/2016 09:28 AM, Daniel Vetter wrote:
> On Thu, Jun 23, 2016 at 8:17 AM, Mario Kleiner
> wrote:
>> The following patch implements precise vblank timestamping
>> for RaspberryPi's VC4, at least for standard progressive
>> scan display modes.
>>
>> I
, and hope for the best.
Measurement shows the generated timestamps to be rather precise,
and at least never off more than 1 vblank duration worst-case.
Limitations: Doesn't work well yet for interlaced video modes,
therefore disabled in interlaced mode for now.
Signed-off-by: Mario
The following patch implements precise vblank timestamping
for RaspberryPi's VC4, at least for standard progressive
scan display modes.
It has been tested on the HDMI output with half a dozen different
video modes using special hardware measurement equipment to compare
generated time stamps
Any news on this one?
Thanks a bunch,
-mario
On 06/14/2016 04:12 PM, Mario Kleiner wrote:
> On 06/14/2016 01:05 PM, Daniel Vetter wrote:
>> On Thu, May 26, 2016 at 4:39 PM, Mario Kleiner
>> wrote:
>>> This reverts commit 013dd9e03872
>>> ("drm/i915/dp: fa
On 06/14/2016 01:05 PM, Daniel Vetter wrote:
> On Thu, May 26, 2016 at 4:39 PM, Mario Kleiner
> wrote:
>> This reverts commit 013dd9e03872
>> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
>>
>> This commit introduced a regression into
On 06/14/2016 12:44 PM, Ville Syrjälä wrote:
> On Thu, May 26, 2016 at 04:39:04PM +0200, Mario Kleiner wrote:
>> Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
>> reports that the "AEO model 0" display is driven with 8 bpc
>> without dithering by d
ng the 6 bpc + dithering
is selected.
This patch should be backported to stable.
Signed-off-by: Mario Kleiner
Cc: stable at vger.kernel.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/
nk bpc detection will be handled for future
kernels in a separate series of patches.
Please backport to stable.
Signed-off-by: Mario Kleiner
Acked-by: Jani Nikula
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 20 +---
Following Jani's advice, this series just fixes the stable kernel
regressions for DP color precision on Intel by reverting Jani's
commit and adding the edid 6 bpc quirk for the AEO 0 panel to fix
the original fdo bug that triggered this. Minimal patches to allow
easy backporting to affected stable
t do the local irq disable. I'll give it a test
later this week.
Reviewed-by: Mario Kleiner
Indeed the old inactive @tuebingen.mpg.de is only a forward to the gmail
address, probably with some botched mail filter rules, so they can go
unnoticed quite a while.
thanks,
-mario
-by: Mario Kleiner
Cc: stable at vger.kernel.org
Cc: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index
On 05/13/2016 08:51 PM, Eric Anholt wrote:
> Mario Kleiner writes:
>
>> On 05/09/2016 09:38 PM, Eric Anholt wrote:
>>> Mario Kleiner writes:
>>>
>>>> Hi Eric and all,
>>>>
>>>> two small fixes against vc4 kms, built and tested a
On 05/09/2016 08:11 PM, Daniel Vetter wrote:
> On Mon, May 09, 2016 at 08:16:07PM +0300, Ville Syrjälä wrote:
>> On Mon, May 09, 2016 at 05:08:43PM +0100, Matthew Auld wrote:
>>> This patch aims to replace the roll-your-own seqlock implementation with
>>> full-blown seqlock'. We also remove the
On 05/17/2016 08:51 AM, Daniel Vetter wrote:
> On Thu, May 12, 2016 at 06:43:58PM +0200, Mario Kleiner wrote:
>> This fixes a regression in output precision for DVI and VGA
>> video sinks connected to Intel hw via active DisplayPort->DVI/VGA
>> converters.
>>
&g
the relative timing of
HVS, PV's and trigger points for interrupts, DL updates:
https://lists.freedesktop.org/archives/dri-devel/2016-May/107510.html
Tested on RPi 2B with hardware timing measurement equipment
and shown to no longer complete flips too early or too late.
Signed-off-by: Mario Kleiner
Cc
On 05/09/2016 09:38 PM, Eric Anholt wrote:
> Mario Kleiner writes:
>
>> Hi Eric and all,
>>
>> two small fixes against vc4 kms, built and tested agains the
>> Raspberry Pi foundations 4.4.8 kernel tree on RPi2B.
>>
>> I'm tinkering with a Rpi 2B a bit t
On 05/07/2016 08:15 PM, Ville Syrjälä wrote:
> On Fri, May 06, 2016 at 10:03:06PM +0200, Mario Kleiner wrote:
>> On 05/06/2016 08:27 PM, Ville Syrjälä wrote:
>>> On Mon, Mar 28, 2016 at 01:52:44AM +0200, Mario Kleiner wrote:
>>>> Bugzilla https://bugzilla.ker
Rename intel_dp_legacy_bpc() to intel_dp_sink_bpc().
Signed-off-by: Mario Kleiner
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
drivers/gpu/drm/i915/intel_dp.c | 59
drivers/
On 05/06/2016 08:27 PM, Ville Syrjälä wrote:
> On Mon, Mar 28, 2016 at 01:52:44AM +0200, Mario Kleiner wrote:
>> Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
>>
>> received a potential fix that was backported to stable. While that
>> patch itself is co
Forwarded Message
Subject: [PATCH 3/3] drm/edid: Add 6 bpc quirk for display AEO model 0.
Date: Mon, 28 Mar 2016 01:52:47 +0200
From: Mario Kleiner <mario.kleiner...@gmail.com>
To: dri-devel at lists.freedesktop.org
CC: mario.kleiner.de at gmail.com, Jani Nikula ,
Ville
Forwarded Message
Subject: [PATCH 2/3] drm/i915/dp: Try to find proper bpc for DP->legacy
converters.
Date: Mon, 28 Mar 2016 01:52:46 +0200
From: Mario Kleiner <mario.kleiner...@gmail.com>
To: dri-devel at lists.freedesktop.org
CC: mario.kleiner.de at gmail.com, Ja
Forwarded Message
Subject: [PATCH 1/3] drm/edid: Set 8 bpc color depth for displays with
"DFP 1.x compliant TMDS".
Date: Mon, 28 Mar 2016 01:52:45 +0200
From: Mario Kleiner <mario.kleiner...@gmail.com>
To: dri-devel at lists.freedesktop.org
CC: mario.kleiner
Ping? Could somebody give this a review? Would be good to get the
associated regressions in DVI/VGA output precision fixed in intel
hw, also for stable kernels which regressed.
Resending the three patches...
thanks,
-mario
On 03/28/2016 01:52 AM, Mario Kleiner wrote:
> Bugzilla ht
Raspian kernel 4.4.8 tree on RPi 2B.
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 355ee4b..c3854e2 100644
--- a/drivers/gpu/drm/vc4
tree on RPi 2B.
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index b7d2ff0..962d0d7 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b
Hi Eric and all,
two small fixes against vc4 kms, built and tested agains the
Raspberry Pi foundations 4.4.8 kernel tree on RPi2B.
I'm tinkering with a Rpi 2B a bit to see if your vc4 work can
already make the Pi useful as a device for some serious but low
cost neuro-science applications.
Eric:
Anyway, although i would have liked the stricter check and warning docs,
the v4 patch is ok with me:
Reviewed-by: Mario Kleiner
-mario
On 04/25/2016 08:32 AM, Maarten Lankhorst wrote:
> This function is useful for gen2 intel devices which have no frame
> counter, but need a way to det
is useful.
> - Add a WARN_ON when get_vblank_timestamp is unavailable.
> - Use drm_vblank_count.
>
> Cc: Mario Kleiner
> Cc: Ville Syrjälä
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Ville Syrjälä #v4
> Acked-by: David Airlie #irc, v4
> ---
>
> Unfortunat
On 04/14/2016 07:48 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_send_vblank_event() with the new helper function.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
gt; Changes since v1:
> - Take vblank_time_lock and don't use drm_vblank_count_and_time.
> Changes since v2:
> - Don't return time of last vblank.
> Changes since v3:
> - Change pipe to unsigned int. (Ville)
> - Remove unused documentation for tv_ret. (kbuild)
>
> Cc: Mario Kleiner
>
for regressions caused by that patch are aimed
at stable, this patch should also go to stable to
make everybody happy again.
Signed-off-by: Mario Kleiner
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_edid.c | 8
1 file
ck to 18 bpp" patch was backported to stable we should
include this one also into stable to fix the regression in color depth
for such panels.
Tested with MiniDP->DP adapter, MiniDP->HDMI adapter,
MiniDP->single-link DVI adapter, MiniDP->dual-link DVI active adapter,
and Apple Min
to stable we should include this one
also in stable to fix the regression in color depth for such panels.
Signed-off-by: Mario Kleiner
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_edid.c | 31 ++-
1 file changed, 3
Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
received a potential fix that was backported to stable. While that
patch itself is correct for treating DP video sinks with "unknown
color depth", it uncovered some lack in our general EDID 1.3
handling, and in how we treat DP->DVI/VGA,
positive or
negative effect on display setup on the tested
iMac10,1 so i don't know if backporting to stable
makes sense or not.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/radeon/atombios_encoders.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
s still not work on iMac10,1, whereas external
DVI and HDMI sinks continue to work.
The problem affects at least all tested kernels
since Linux 3.13 - didn't test earlier kernels, so
backporting to stable probably makes sense.
Signed-off-by: Mario Kleiner
Cc:
---
drivers/gpu/drm/radeon/atombios
On 02/29/2016 09:10 PM, Dan Carpenter wrote:
> Hello Mario Kleiner,
>
> The patch e1d09dc0ccc6: "drm/amdgpu: Don't hang in
> amdgpu_flip_work_func on disabled crtc." from Feb 19, 2016, leads to
> the following static checker warning:
>
> drivers/gpu/drm/
ent, so
it can't underflow anymore, but still performs up to
three repetitions - three is the maximum one could
expect in practice.
Move the spin_unlock_irqrestore to where it actually
belongs.
Reported-by: Dan Carpenter
Signed-off-by: Mario Kleiner
Cc: # 4.4+
Cc: Michel Dänzer
Cc: Alex Deu
actually
belongs.
Reported-by: Dan Carpenter
Signed-off-by: Mario Kleiner
Cc: # 4.4+
Cc: Michel Dänzer
Cc: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gp
ug.cgi?id=93746>
Reported-by: Bernd Steinhauser
Signed-off-by: Mario Kleiner
Cc: # 4.4+
Cc: Michel Dänzer
Cc: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
d the display doesn't update its view
of the desktop.
This patch fixes the Linux 4.4 regression from fdo bug #93746
<https://bugs.freedesktop.org/show_bug.cgi?id=93746>
v2: Skip wait immediately if !radeon_crtc->enabled, as
suggested by Michel.
Reported-by: Bernd Steinhauser
Signed
Two more patches for radeon-kms/amdgpu-kms to fix some new
regression introduced into Linux 4.4 by other fixes for
the vblank regressions in 4.4.
These fix fdo bug 93746 filed against Linux 4.4.
thanks,
-mario
hangs on resume, or desktop hangs in the case of composited desktops.
Fix this Linux 4.4 regression by reordering calls accordingly.
Signed-off-by: Mario Kleiner
Cc: # 4.4+
Cc: Ben Skeggs
Cc: ville.syrjala at linux.intel.com
Cc: daniel.vetter at ffwll.ch
Cc: dri-devel at lists.freedesktop.org
Make sure that drm_vblank_get/put() stay balanced in
case drm_vblank_get fails, by skipping the corresponding
put.
Signed-off-by: Mario Kleiner
Reviewed-by: Daniel Vetter
Cc: michel at daenzer.net
Cc: dri-devel at lists.freedesktop.org
Cc: alexander.deucher at amd.com
Cc: christian.koenig
g
some of the semantics of offdelay<0 vs. offdelay==0 vs.
disable_immediate during the review of the series. So yeah, given
how drm_vblank_put() works now, I'd just make this check for
offdelay==0."
Signed-off-by: Mario Kleiner
Reviewed-by: Daniel Vetter
Cc: # 3.18+
Cc: michel at daenz
. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.
Reported-by: Vlastimil Babka
Signed-off-by: Mario Kleiner
Reviewed-by:
to allow concurrent writes and reads for arbitrary
vblank counter increments.
v2: Add code comment that this is essentially a hack and should
be replaced by a full seqlock implementation for caching of
timestamps.
Signed-off-by: Mario Kleiner
Reviewed-by: Daniel Vetter
Cc: # 4.4+
Cc
set().
This fixes a regression caused by the changes made to
drm_update_vblank_count() in Linux 4.4.
v2: Don't no-op on atomic modesetting drivers, per suggestion
of Daniel Vetter.
Signed-off-by: Mario Kleiner
Reviewed-by: Daniel Vetter
Cc: # 4.4+
Cc: michel at daenzer.net
Cc: vba
Here the respin of my series of vblank bug fixes for stable
Linux 4.4/4.5 with all review comments by Daniel and Ville
taken into account and reviewd-by's and tested-by's added.
I've removed the stable patch "drm: Prevent vblank counter jumps
with timestamp based update method." for the moment.
On 02/10/2016 06:17 PM, Daniel Vetter wrote:
> On Wed, Feb 10, 2016 at 5:28 PM, Mario Kleiner
> wrote:
>> There's another scenario where this zero-ts case can be hit. If the driver
>> drm_vblank_init()'s - setting all timestamps to zero - and then code starts
>> using
On 02/09/2016 04:03 PM, Daniel Vetter wrote:
> On Tue, Feb 09, 2016 at 04:11:49PM +0200, Ville Syrjälä wrote:
>> On Tue, Feb 09, 2016 at 02:53:30PM +0100, Mario Kleiner wrote:
>>> On 02/09/2016 11:09 AM, Daniel Vetter wrote:
>>>> On Mon, Feb 08, 2016 at 02:13:2
On 02/09/2016 03:29 PM, Daniel Vetter wrote:
> On Tue, Feb 09, 2016 at 02:39:44PM +0100, Mario Kleiner wrote:
>> On 02/09/2016 11:23 AM, Daniel Vetter wrote:
>>> On Tue, Feb 09, 2016 at 12:07:27PM +0200, Ville Syrjälä wrote:
>>>> On Tue, Feb 09, 2016 at 10:56:3
On 02/09/2016 11:09 AM, Daniel Vetter wrote:
> On Mon, Feb 08, 2016 at 02:13:28AM +0100, Mario Kleiner wrote:
>> The changes to drm_update_vblank_count() in Linux 4.4 added a
>> method to emulate a hardware vblank counter by use of high
>> precision vblank timestamps if a kms
On 02/09/2016 11:23 AM, Daniel Vetter wrote:
> On Tue, Feb 09, 2016 at 12:07:27PM +0200, Ville Syrjälä wrote:
>> On Tue, Feb 09, 2016 at 10:56:38AM +0100, Daniel Vetter wrote:
>>> On Mon, Feb 08, 2016 at 02:13:25AM +0100, Mario Kleiner wrote:
>>>> This fixes a re
On 02/09/2016 12:10 PM, Ville Syrjälä wrote:
> On Tue, Feb 09, 2016 at 11:06:18AM +0100, Daniel Vetter wrote:
>> On Mon, Feb 08, 2016 at 02:13:27AM +0100, Mario Kleiner wrote:
>>> drm_vblank_offdelay can have three different types of values:
>>>
>>> < 0
On 02/09/2016 10:54 AM, Daniel Vetter wrote:
> On Mon, Feb 08, 2016 at 02:13:24AM +0100, Mario Kleiner wrote:
>> Otherwise if a kms driver calls into drm_vblank_off() more than once
>> before calling drm_vblank_on() again, the redundant calls to
>> vblank_disable
On 02/07/2016 12:59 PM, Mario Kleiner wrote:
> I have a few simple patches which after testing seem to work well
> enough and fix additional similar problems with nouveau. Got
> distracted with other stuff last week. I'll try to send them out later
> today when i'm at the machine
Make sure that drm_vblank_get/put() stay balanced in
case drm_vblank_get fails, by skipping the corresponding
put.
Signed-off-by: Mario Kleiner
Cc: michel at daenzer.net
Cc: dri-devel at lists.freedesktop.org
Cc: alexander.deucher at amd.com
Cc: christian.koenig at amd.com
---
drivers/gpu/drm
amp used for this calculations
is zero == invalid. If so, perform a counter increment of +1 to
prevent large counter jumps and reinitialize the timestamps to
sane values.
Signed-off-by: Mario Kleiner
Cc: # 4.4+
Cc: michel at daenzer.net
Cc: vbabka at suse.cz
Cc: ville.syrjala at linux.intel.com
lank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.
Signed-off-by: Mario Kleiner
Cc: # 3.18+
Cc: michel at daenzer.net
Cc: vbabka at suse.cz
Cc: ville.syrjala at linux.intel.com
Cc: daniel.vetter at ffwll.ch
Cc: dri-devel at lists.freedesktop.org
Cc: alexander
. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.
Reported-by: Vlastimil Babka
Signed-off-by: Mario Kleiner
Cc: # 4
than reenabling
vblank irqs, e.g., when regular vblank interrupts get delayed by more
than 1 frame due to long held locks, long irq off periods, realtime
preemption on RT kernels, or system management interrupts.
Signed-off-by: Mario Kleiner
Cc: # 4.4+
Cc: michel at daenzer.net
Cc: vbabka
ned-off-by: Mario Kleiner
Cc: # 4.4+
Cc: michel at daenzer.net
Cc: vbabka at suse.cz
Cc: ville.syrjala at linux.intel.com
Cc: daniel.vetter at ffwll.ch
Cc: dri-devel at lists.freedesktop.org
Cc: alexander.deucher at amd.com
Cc: christian.koenig at amd.com
---
drivers/gpu/drm/drm_irq.c |
201 - 300 of 524 matches
Mail list logo
