On Mon, Mar 22, 2021 at 4:52 PM Ville Syrjälä
wrote:
>
> On Fri, Mar 19, 2021 at 10:03:12PM +0100, Mario Kleiner wrote:
> > Hi,
> >
> > this patch series adds the fourcc's for 16 bit fixed point unorm
> > framebuffers to the core, and then an implementation
Friendly ping to the AMD people. Nicholas, Harry, Alex, any feedback?
Would be great to get this in sooner than later.
Thanks and have a nice weekend,
-mario
On Fri, Mar 19, 2021 at 10:03 PM Mario Kleiner
wrote:
>
> Hi,
>
> this patch series adds the fourcc's for 16 bit
Hi,
this patch series adds the fourcc's for 16 bit fixed point unorm
framebuffers to the core, and then an implementation for AMD gpu's
with DisplayCore.
This is intended to allow for pageflipping to, and direct scanout of,
Vulkan swapchain images in the format VK_FORMAT_R16G16B16A16_UNORM.
I hav
_UNORM onto
DRM_FORMAT_XBGR16161616.
The old id 22 would cause colorful pixeltrash to be displayed instead.
Tested under DCN-1.0 and DCE-11.2.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c| 2 ++
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
. Otherwise precision gets truncated somewhere
to 10 bpc effective depth.
Strangely this increase was not needed on Polaris11 DCE-11.2 during
testing to get 12 bpc effective precision. It also is not needed for
fp16 framebuffers.
Tested on DCN-1.0 and DCE-11.2.
Signed-off-by: Mario Kleiner
---
drivers
These are 16 bits per color channel unsigned normalized formats.
They are supported by at least AMD display hw, and suitable for
direct scanout of Vulkan swapchain images in the format
VK_FORMAT_R16G16B16A16_UNORM.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_fourcc.c | 4
include
This is needed to avoid warnings with linebuffer depth 36 bpp.
Testing on a Polaris11, DCE-11.2 on a 10 bit HDR-10 monitor
showed no obvious problems, and this 12 bpc limit is consistent
with what other function in the DCE bit depth reduction path use.
Signed-off-by: Mario Kleiner
---
drivers
.
Successfully tested on AMD Polaris11 DCE-11.2 an RavenRidge DCN-1.0
with a HDR-10 monitor over 10 bpc DP output with spatial dithering
enabled by the driver. Picture looks good, and my photometer
measurement procedure confirms an effective 12 bpc color
reproduction.
Signed-off-by: Mario Kleiner
On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
wrote:
>
> On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> > These are 16 bits per color channel unsigned normalized formats.
> > They are supported by at least AMD display hw, and suitable for
> > direct sca
Hi,
these two patches fix non-working HDMI deep color output on DCE-8.3,
AMD Mullins when amdgpu-kms is used with Displaycore force-enabled,
ie. for radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dc=1:
I suspect they might fix similar problems on other older asics of
DCE-11.0 and earlier.
Patch
drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
b/drivers/gpu/dr
y tested
on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI
deep color output with 10 bpc or 12 bpc.
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
---
.../drm/amd/display/dc/bios/command_table.c | 61 +++
On Mon, Jan 4, 2021 at 6:16 PM Alex Deucher wrote:
>
> On Mon, Dec 28, 2020 at 1:51 PM Mario Kleiner
> wrote:
> >
> > Hi and happy post-christmas!
> >
> > I wrote a patch 1/1 that now checks plane scaling factors against
> > the pixel-format specific l
operty")
Signed-off-by: Mario Kleiner
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
---
include/linux/hdmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 9850d59d6f1c..c8ec982ff498 100644
--- a/include/linux/
On Sun, Jan 24, 2021 at 9:15 AM Simon Ser wrote:
> On Sunday, January 24th, 2021 at 5:40 AM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is
> > not 1, but zero, so fix this enum.
> >
>
a bug report as well, under the following link:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3601
Fixes: dff906c3f91c ("drm/tinydrm: Advertise that we can do only
DRM_FORMAT_MOD_LINEAR.")
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
Cc: Noralf Trønnes
Cc: Maxime Rip
On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote:
> On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > But it still needs to be fixed if we want working HDR. I thought
> > libdrm copies the definitions from the kernel p
On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä
wrote:
> On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > The check was introduced to make sure that only the
> > DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
> >
> > However, if .format_mod_su
On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote:
> > This is not an uapi defintion anyway so fixing should be fine.
>
> Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah
> should be completely fine to fix it.
>
Good! The beginning of the end of a sad story ;). So i guess i ca
On Mon, Jan 25, 2021 at 1:09 PM Ville Syrjälä
wrote:
> On Sun, Jan 24, 2021 at 10:04:54PM +0100, Mario Kleiner wrote:
> > On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote:
> >
> > > On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner <
> > &g
On Mon, Jan 25, 2021 at 5:34 PM Ville Syrjälä
wrote:
> On Mon, Jan 25, 2021 at 04:32:48PM +0100, Mario Kleiner wrote:
> > On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Sun, Jan 24, 2021 a
ere a
certain DCE version at which your team starts validating output precision /
HDR etc. on hw?
Thanks,
-mario
On Mon, Jan 25, 2021 at 8:16 PM Kazlauskas, Nicholas <
nicholas.kazlaus...@amd.com> wrote:
> On 2021-01-25 12:57 p.m., Alex Deucher wrote:
> > On Thu, Jan 21, 2021 at 1
On Mon, Jan 25, 2021 at 5:05 PM Simon Ser wrote:
> ‐‐‐ Original Message ‐‐‐
>
> On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote:
> >
> > >
real display hw out there.
thanks,
-mario
On Mon, Jan 25, 2021 at 8:53 PM Mario Kleiner
wrote:
>
>
> On Mon, Jan 25, 2021 at 5:05 PM Simon Ser wrote:
>
>> ‐‐‐ Original Message ‐‐‐
>>
>> On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner <
>
Ping. Any bit of info appreciated wrt. the DCE-11.2+ situation.
-mario
On Mon, Jan 25, 2021 at 8:24 PM Mario Kleiner
wrote:
> Thanks Alex and Nicholas! Brings quite a bit of extra shiny to those older
> asics :)
>
> Nicholas, any thoughts on my cover-letter wrt. why a similar p
On Wed, Feb 10, 2021 at 10:14 PM Simon Ser wrote:
> On Wednesday, February 10th, 2021 at 10:04 PM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > Ping!
>
> I now understand the problem better.
>
> Reviewed-by: Simon Ser
>
> I'll p
On Thu, Feb 11, 2021 at 11:44 AM Simon Ser wrote:
> On Wednesday, February 10th, 2021 at 11:02 PM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > I'll prepare patches with the same fix for libdrm and igt as well soon.
>
> Please don't submit patc
10 bpc DP or HDMI connected
HDR-10 monitor.
Alex suggests this may have been a workaround for some DCE-11.0
Carrizo and Stoney Asics, so lets try to restrict this to DCE 11.0.
Signed-off-by: Mario Kleiner
Cc: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 9 ++---
1 file
On Mon, Feb 15, 2021 at 8:09 PM Alex Deucher wrote:
> On Fri, Feb 12, 2021 at 5:30 PM Mario Kleiner
> wrote:
> >
> > Spatial dithering to 10 bpc depth was disabled for all DCE's.
> > Restrict this to DCE-11.0, but allow it on other DCE's.
> >
> > Te
On Thu, Feb 11, 2021 at 1:29 PM Ville Syrjälä
wrote:
> On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
> > From: Nischal Varide
> >
> > If the panel is 12bpc then Dithering is not enabled in the Legacy
> > dithering block , instead its Enabled after the C1 CC1 pipe post
> > color spa
On Fri, Feb 19, 2021 at 4:22 AM Mario Kleiner
wrote:
>
>
> On Thu, Feb 11, 2021 at 1:29 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
>> On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
>> > From: Nischal Varide
>> >
>
On Wed, Feb 10, 2021 at 10:14 PM Simon Ser wrote:
>
> On Wednesday, February 10th, 2021 at 10:04 PM, Mario Kleiner
> wrote:
>
> > Ping!
>
> I now understand the problem better.
>
> Reviewed-by: Simon Ser
>
> I'll push to drm-misc-next in a few days
On Tue, May 4, 2021 at 9:22 PM Alex Deucher wrote:
>
> On Wed, Apr 28, 2021 at 5:21 PM Alex Deucher wrote:
> >
> > On Tue, Apr 20, 2021 at 5:25 PM Alex Deucher wrote:
> > >
> > > On Fri, Apr 16, 2021 at 12:29 PM Mario Kleiner
> > > wrote:
&g
On Wed, Apr 28, 2021 at 11:22 PM Alex Deucher wrote:
>
> On Tue, Apr 20, 2021 at 5:25 PM Alex Deucher wrote:
> >
> > On Fri, Apr 16, 2021 at 12:29 PM Mario Kleiner
> > wrote:
> > >
> > > Friendly ping to the AMD people. Nicholas, Harry, Alex, any fee
On Thu, May 6, 2021 at 8:37 AM Ville Syrjälä
wrote:
>
> On Sat, Mar 20, 2021 at 04:09:47AM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 10:45:10PM +0100, Mario Kleiner wrote:
> > > On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
> > > wrote:
> > &g
Jonathan Marek (2):
drm/msm: add MSM_BO_CACHED_COHERENT
drm/msm: deprecate MSM_BO_UNCACHED (map as writecombine instead)
Lionel Landwerlin (1):
drm: fix drm_mode_create_blob comment
Mario Kleiner (1):
drm/fourcc: Add 16 bpc fixed point framebuffer formats.
Matthew Auld (5
On Mon, Jul 5, 2021 at 9:39 AM Michel Dänzer wrote:
>
> On 2021-07-03 9:59 p.m., Mario Kleiner wrote:
> > Generated using make headers_install from the drm-next
> > tree - git://anongit.freedesktop.org/drm/drm
> > branch - drm-next
> > commit - 8a02ea42bc1d4c448caf1b
h
high resolutions? Maybe somewhere else in the code something would
need to be adapted? Lacking actual hw docs, my coding here is by
pattern matching against existing DC code, guessing and testing on my
limited hw samples.
Acked-by: Mario Kleiner
-mario
> > ---
> > drivers/gpu
On Tue, Dec 14, 2021 at 3:03 PM Sebastian Andrzej Siewior <
bige...@linutronix.de> wrote:
> From: Mike Galbraith
>
> Mario Kleiner suggest in commit
> ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into
> kms driver.")
>
> a spots w
Hi and happy post-christmas!
I wrote a patch 1/1 that now checks plane scaling factors against
the pixel-format specific limits in the asic specific dc_plane_cap
structures during atomic check and other appropriate places.
This should prevent things like asking for scaling on fp16 framebuffers
if
This takes hw constraints specific to pixel formats into account,
e.g., the inability of older hw to scale fp16 format framebuffers.
It should now allow safely to enable fp16 formats also on DCE-8,
DCE-10, DCE-11.0
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
DCE-8 asic, so i assume that the more
recent DCE-10/11 will work equally well, now that
format-specific plane scaling constraints are properly
enforced, e.g., the inability of fp16 to scale on older
hw like DCE-8 to DCE-11.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/dc/dce100
doesn't show any users of the getfb2 ioctl(), so the need for this
format info assignment seems to be more the exception than the rule?
Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
metadata.")
Cc: Bas Nieuwenhuizen
Cc: Alex Deucher
Signed-off-by: M
y: Set new format info for converted
metadata.")
Cc: Bas Nieuwenhuizen
Cc: Alex Deucher
Cc: David Airlie
Cc: Ville Syrjälä
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_plane.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane
under Mesa if pageflipping isn't used. Also good to test
synchronization on dual-display setups, e.g., for udal-display stereo
presentation.
I was actually surprised that this patch made it through the various
test suites and into drm-next. I thought page-flipping was covered
well e
On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
wrote:
>
> With modifiers one can actually have different format_info structs
> for the same format, which now matters for AMDGPU since we convert
> implicit modifiers to explicit modifiers with multiple planes.
>
> I checked other drivers and it do
On Sat, Jan 2, 2021 at 4:49 PM Bas Nieuwenhuizen
wrote:
>
> On Sat, Jan 2, 2021 at 4:05 PM Mario Kleiner
> wrote:
> >
> > On Sat, Jan 2, 2021 at 3:05 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > I think the problem here is that application A can se
On Sat, Jan 2, 2021 at 7:51 PM Ilia Mirkin wrote:
> On Sat, Jan 2, 2021 at 1:35 PM Mario Kleiner
> wrote:
> > I'm less sure about nouveau. It uses modifiers, but has atomic support
> > only on nv50+ and that atomic support is off by default -- needs a
> > nouveau.no
On Thu, Jan 7, 2021 at 6:21 PM Liu, Zhan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> > -Original Message-
> > From: Liu, Zhan
> > Sent: 2021/January/06, Wednesday 10:04 AM
> > To: Bas Nieuwenhuizen ; Mario Kleiner
> >
On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
> > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > With modifiers one can actually have different format_info structs
On Thu, Jan 7, 2021 at 7:04 PM Daniel Vetter wrote:
> On Thu, Jan 7, 2021 at 7:00 PM Mario Kleiner
> wrote:
> >
> > On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
> >>
> >> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
>
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
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 derive t
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
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 compulsive
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 pa
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 presentation
the bos
domain 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.
Signe
the bos
domain 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.
Signe
t is
stale and needs a refresh 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 s
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 the
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
>>>> scan
Nag nag: The below documentation patch, acked-by Daniel and r-b'd by
Nicholas seems to not have made it into drm-next yet?
thanks,
-mario
On Thu, Apr 18, 2019 at 2:45 PM Kazlauskas, Nicholas
wrote:
>
> On 4/18/19 2:01 AM, Mario Kleiner wrote:
> > As discussed with Nicholas
Helps with debugging issues with low framerate compensation.
Signed-off-by: Mario Kleiner
---
.../amd/display/modules/freesync/freesync.c| 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd
Hi
This patch-series tries to improve amdgpu's below-the-range
behaviour with Freesync, hopefully not only for my use case,
but also for games etc.
Patch 1/4 adds a bit of debug output i found very useful, so maybe
worth adding?
Patch 2/4 fixes a bug i found when reading over the freesync code.
prevents missed vblanks at the border
between non-BTR and BTR.
Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.
Signed-off-by: Mario Kleiner
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
ons
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 ++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/d
behaviour present
in Linux 5.0/5.1.
Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
Link: https://patchwork.freedesktop.org/patch/285333/
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_connector.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drive
On Wed, Apr 24, 2019 at 4:34 PM Kazlauskas, Nicholas
wrote:
>
> On 4/17/19 11:51 PM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some t
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
Updated series. The debug patch is dropped, a r-b by Nicholas is tacked
onto patch 1/3 and patch 3/3 has the locking fix that Nicholas proposed.
In terms of testing 3/3 didn't change anything for the better or worse,
observed behaviour on retested DCN-1 and DCE-8 is the same.
Patch 2/3 is identical
prevents missed vblanks at the border
between non-BTR and BTR.
Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.
Signed-off-by: Mario Kleiner
ons
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.
v2: Fix some wrong locking, as pointed out by Nicholas.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 +--
1 file c
Same as rev 2, except for patch 3/3 v3 to apply Nicholas
latest feedback into account. Retested on DCN1 and DCE8.
thanks,
-mario
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
ons
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.
v2: Fix some wrong locking, as pointed out by Nicholas.
v3: Simplify if-condition in vupdate-irq - nit by Nicholas.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/d
prevents missed vblanks at the border
between non-BTR and BTR.
Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.
Signed-off-by: Mario Kleiner
On Fri, Apr 26, 2019 at 7:12 PM Kazlauskas, Nicholas
wrote:
>
> On 4/26/19 6:50 AM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some t
On Mon, Apr 29, 2019 at 2:51 PM Kazlauskas, Nicholas
wrote:
>
> On 4/26/19 5:40 PM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some t
DPCD caps.
It will use a hard-coded VRR range of 30 Hz - 144 Hz on
other displays without suitable EDID, e.g., standard
DisplayPort, HDMI, DVI monitors.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11
On Tue, Apr 30, 2019 at 2:22 PM Kazlauskas, Nicholas
wrote:
>
> On 4/30/19 3:44 AM, Michel Dänzer wrote:
> > [CAUTION: External Email]
> >
> > On 2019-04-30 9:37 a.m., Mario Kleiner wrote:
> >> Allow to detect any connected display to be marked as
> >> V
m vrr refresh rate.
Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR
properties")
Signed-off-by: Mario Kleiner
Cc:
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Alex Deucher
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
.../gpu/drm/amd/d
exact end time of vblank.
Signed-off-by: Mario Kleiner
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Alex Deucher
---
drivers/gpu/drm/drm_vblank.c | 49 +++-
include/drm/drm_vblank.h | 8 ++
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git
These fix the currently broken vblank timestamping in VRR
mode and broken pageflip timestamping in VRR mode. The unfixed
implementation can provide timestamps that are off by dozens
of milliseconds and thereby make VRR unusable for any application
that needs at least millisecond precision in timing
rrors from potentially dozens of milliseconds
to probably less than 2 msecs in the common case, given the fixed
and short back-porch duration and the usually low interrupt dispatch
delay from pageflip interrupt.
Signed-off-by: Mario Kleiner
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Al
rovide some stable
timestamp for future improvements of the pageflip timestamping under
vrr.
Fixes: 520f08df45fb ("drm/amdgpu: Correct get_crtc_scanoutpos behavior
when vpos >= vtotal")
Signed-off-by: Mario Kleiner
Cc:
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Al
therefore
> cannot be interpreted to mean anything."
>
> And since EDID 1.4 redefines that bit let's consult it only for
> EDID 1.3.
>
> Cc: Mario Kleiner
> Signed-off-by: Ville Syrjälä
Yes. Series is:
Reviewed-by: Mario Kleiner
-mario
On Wed, May 29, 2019 at 3:50 PM Al
Hi
This series implements properly working vblank and pageflip completion
timestamping for amdgpu in VRR / FreeSync mode.
Now pageflip timestamps for pageflip events always carry the
vblank timestamp of the vblank in which the flip completed,
and the vblank timestamp is as accurate as in fixed re
fixed
refresh rate non-VRR mode.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
nk of even after it, without a negative impact on flip
throttling, so followup patches can shift the vblank core
handling trigger point wherever they need it.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu
.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 129 -
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 22
we are in case a) or b),
we check the current scanout position against the boundary of
front-porch. In non-VRR mode we just do what we did in the past.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 ++-
1 file changed, 55 insertions
Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas
wrote:
>
> On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote:
> > On 3/18/19 1:19 PM, Mario Kleiner wrote:
> >> In VRR mode, proper vblank/pageflip t
fixed
refresh rate non-VRR mode.
v2: Make sure transition is also handled if vrr is
disabled and stream gets disabled in the same
atomic commit. Suggested by Nicholas.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 +++
1 file ch
On Mon, Mar 18, 2019 at 6:29 PM Kazlauskas, Nicholas
wrote:
>
> On 3/18/19 1:19 PM, Mario Kleiner wrote:
> > During VRR mode we can not allow vblank irq dis-/enable
> > transitions, as an enable after a disable can happen at
> > an arbitrary time during the video refresh
On Wed, Mar 20, 2019 at 2:11 PM Kazlauskas, Nicholas
wrote:
>
> On 3/20/19 4:12 AM, Mario Kleiner wrote:
> > During VRR mode we can not allow vblank irq dis-/enable
> > transitions, as an enable after a disable can happen at
> > an arbitrary time during the video refresh
On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas
wrote:
>
> On 3/20/19 3:51 AM, Mario Kleiner wrote:
> > Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
> >
> > On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas
> > wrote
nk of even after it, without a negative impact on flip
throttling, so followup patches can shift the vblank core
handling trigger point wherever they need it.
Signed-off-by: Mario Kleiner
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
.../gpu/drm/a
we are in case a) or b),
we check the current scanout position against the boundary of
front-porch. In non-VRR mode we just do what we did in the past.
Signed-off-by: Mario Kleiner
Reviewed-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 +++
1
1 - 100 of 534 matches
Mail list logo
