-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=No
uveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mario.
kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170311Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
LGTM. This one is
Reviewed-by: Mario Kleiner
-mario
On Mon, Feb 27, 2023 at 8:36 PM Rob Clark wrote:
> From: Rob Clark
>
> Will be used in the next commit to set a deadline on fences that an
> atomic update is waiting on.
>
> v2: Calculate time at *start* of vblank pe
t words") depth 30 should hopefully fix all known problems
without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on
top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs")
Signed-off-by
On Fri, Feb 11, 2022 at 9:44 AM Sebastian Andrzej Siewior
wrote:
>
> On 2022-01-27 00:29:37 [+0100], Mario Kleiner wrote:
> > Hi, first thank you for implementing these preempt disables according to
> Hi Mario,
>
> > the markers i left long ago. And sorry for the rather l
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 spot
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/drm/amd/display/dc/core/
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 - 8a02ea42bc
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 Thu, Jun 10, 2021 at 9:55 AM Pekka Paalanen wrote:
>
> On Tue, 8 Jun 2021 19:43:15 +0200
> Werner Sembach wrote:
>
> > Add a new general drm property "active bpc" which can be used by graphic
> > drivers
> > to report the applied bit depth per pixel back to userspace.
> >
Maybe "bit depth
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
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,
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
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 fixed
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 for
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
.
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
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
. 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
M 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
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
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 if no
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 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
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.
> >
> > Testing on D
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 changed, 6
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 patches for
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 push t
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
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 <
>
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:
> >
> > >
. Is there 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:17 A
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
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 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
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
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
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 Ripard
---
drive
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.
> >
>
t;)
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/hdmi.h
+++
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
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 ++
: 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/drm/amd/disp
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.
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:
>
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 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 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.nouveau
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 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
ood 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 enough somewhere.
Happy new year!
-mario
>
>
at 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.c b/drivers/gp
esn'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: Mario Kleiner
-
on a 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
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
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
Assuming the hw supports fp16, this would be also
useful for standard dynamic range displays, not
only for HDR use cases, because it would allow
to get more precise color reproduction with about
~11 bpc linear precision in the unorm range
0.0 -1.0.
Signed-off-by: Mario Kleiner
---
drivers/gpu
So i'm sending these on the off-chance that DCE-8/10 do
support fp16 scanout without hw bugs. Would be nice to
enable this if it is supported, even if the hw can't do
HDR. This is also useful for non-HDR to get effectively
11 bpc precision from the fb to the display outputs for
more precise color
Assuming the hw supports fp16, this would be also
useful for standard dynamic range displays, not
only for HDR use cases, because it would allow
to get more precise color reproduction with about
~11 bpc linear precision in the unorm range
0.0 -1.0.
Signed-off-by: Mario Kleiner
---
drivers/gpu
On Wed, May 20, 2020 at 9:07 PM Kazlauskas, Nicholas <
nicholas.kazlaus...@amd.com> wrote:
> On 2020-05-20 2:44 p.m., Mario Kleiner wrote:
> > On Wed, May 20, 2020 at 8:25 PM Alex Deucher > <mailto:alexdeuc...@gmail.com>> wrote:
> >
> > On Wed,
On Wed, May 20, 2020 at 8:25 PM Alex Deucher wrote:
> On Wed, May 20, 2020 at 12:39 PM Harry Wentland wrote:
> >
> > On 2020-05-15 1:19 a.m., Mario Kleiner wrote:
> > > Testing on a Polaris11 gpu with DCE-11.2 suggests that it
> > > seems to work fin
Testing on a Polaris11 gpu with DCE-11.2 suggests that it
seems to work fine there, so optimistically enable it for
DCE-11 and later.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2
Hi,
two patches. The first one adds the xBGR ordered variants of fp16
in addition to the xRGB ordered variants that were merged just
very recently.
These variants are required for direct scanout of OpenGL and Vulkan
rendered content, as both OpenGL (GL_RGBA16F) and Vulkan
Expose support for DRM_FORMAT_ABGR16161616F and
DRM_FORMAT_XBGR16161616F to the DRM core, complementing
the already existing xRGB ordered fp16 formats.
These are especially useful for creating presentable
swapchains in Vulkan for VK_FORMAT_R16G16B16A16_SFLOAT.
Signed-off-by: Mario Kleiner
m-tip, as of 16-March-2020. Adapt
to new edid_quirks parameter of drm_dp_has_quirk().
Signed-off-by: Mario Kleiner
Tested-by: Mario Kleiner
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
include/drm/drm_dp_hel
On Fri, Mar 13, 2020 at 5:02 PM Michel Dänzer wrote:
> On 2020-03-13 1:35 p.m., Kazlauskas, Nicholas wrote:
> > On 2020-03-12 10:32 a.m., Alex Deucher wrote:
> >> On Thu, Mar 5, 2020 at 4:21 PM Mario Kleiner
> >> wrote:
> >>>
> >>> Commit '1
Just as a comment, u8 for max_vfreq in struct drm_adaptive_sync_info
might be not very future proof?
I just read that ASUS announced a "TUF Gaming VG259QM" monitor which
seems to have an adaptive sync range of 48 Hz to 280 Hz, exceeding the
max 255 Hz of u8?
-mario
On Fri, Mar 6, 2020 at 4:02
On Mon, Mar 2, 2020 at 2:57 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-03-02 1:17 a.m., Mario Kleiner wrote:
> > Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
> > events at vsartup for DCN")' introduces a new way of pageflip
> > completion
lay: Send vblank and user events at vsartup
for DCN")
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 80 ---
1 file changed, 67 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers
On Wed, Mar 4, 2020 at 4:32 PM Jani Nikula wrote:
>
> On Sat, 29 Feb 2020, Mario Kleiner wrote:
> > This fixes a problem found on the MacBookPro 2017 Retina panel.
> >
> > The panel reports 10 bpc color depth in its EDID, and the
> > firmware chooses link setting
link rate during
edp setup.
Link to previous discussion of a different attempted fix
with Ville and Jani:
https://patchwork.kernel.org/patch/11325935/
v2: Follow Jani's proposal of defining quirk_rates[] instead
of just appending 324000. This for better clarity.
Signed-off-by: Mario Kleiner
T
al commit
tried to address, as i don't know what the test scenario was. It
does fix the observed too early pageflip events though and points
out the problem introduced.
Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup
for DCN")
Signed-off-by: Mario Kleiner
--
link rate during
edp setup.
Link to previous discussion of a different attempted fix
with Ville and Jani:
https://patchwork.kernel.org/patch/11325935/
Signed-off-by: Mario Kleiner
Cc: Ville Syrjälä
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/di
On Thu, Feb 27, 2020 at 8:11 PM Mario Kleiner
wrote:
>
> Hi Harry
>
> Ok, back from various other emergencies and deadlines, sorry for the
> late reply. I also fixed my e-mail address - it was mistyped, causing
> all these delivery failures :/
>
> On Thu, Jan 9, 2020 at
dark.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.
Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.
Signed-off-by:
Hi Harry
Ok, back from various other emergencies and deadlines, sorry for the
late reply. I also fixed my e-mail address - it was mistyped, causing
all these delivery failures :/
On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote:
>
> On 2020-01-09 4:13 p.m., Mario Kleiner wrote:
>
On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote:
>
>
> On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
>
> On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher wrote:
>
>> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
>> wrote:
>> >
>> > On Th
On Fri, Jan 10, 2020 at 2:32 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 09:19:07PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 a
On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland wrote:
> On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> > If the current eDP link settings, as read from hw, provide a higher
> > bandwidth than the verified_link_cap ones (= reported_link_cap), then
> > override verified_
On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher wrote:
> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
> wrote:
> >
> > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
> wrote:
> >>
> >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >> wrote:
> &
On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 a
On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 a
On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher wrote:
> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> wrote:
> >
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current lin
On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > fir
On Thu, Jan 9, 2020 at 4:27 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to
Hi and happy new year!
Since i now have a MBP 2017 to play with, with a 10 bit Retina panel,
and Polaris gpu, i'm trying to get it to get 10 bits, and found one
small bug [fix: patch1], and a quirk of Apples Retina eDP sink, for
which i propose patch2 as solution. I sent a similar patch to i915
-by: Mario Kleiner
Cc: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 5ea4a1675259..f3acdb8fead5 100644
read_current_link_settings_on_detect() on eDP 1.4+ may use the
edp_supported_link_rates table which is set up by
detect_edp_sink_caps(), so that function needs to be called first.
Signed-off-by: Mario Kleiner
Cc: Martin Leung
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
1 file
the full color
depth of the panel. With this commit, we can use firmware setting
and get the full 10 bpc advertised by the Retina panel.
Signed-off-by: Mario Kleiner
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
1 file changed, 23 insertions(+)
diff
: Daniel Vetter
> > Cc: Nicholas Kazlauskas
> > Cc: Leo Li
> > Cc: Harry Wentland
> > Cc: David Francis
> > Cc: Mario Kleiner
> > Cc: Bhawanpreet Lakha
> > Cc: Ben Skeggs
> > Cc: "Christian König"
> > Cc: Ilia Mirkin
> >
and 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 Alex De
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 and D
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
> >&g
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 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
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
and 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.
v3: Simplify if-condition in vupdate-irq - nit by Nicholas.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/d
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
1 - 100 of 524 matches
Mail list logo
