Some DP dongles in particular seem to be fussy about too large
link M/N values. Set specific value for N divider can resolve
this issue per dongle vendor's comment. So configure N as
constant value (0x8000) to instead of reduce M/N formula when
specific DP dongle connected.
v2: add more comments
DP quirk list just compare sink or branch device's OUI so far.
That means particular vendor's products will be applied specific
change. This change would confirm device_id the same or not.
Then driver can implement some changes for branch/sink device
that really need additional WA.
v2: use sizeof
The N value was computed by kernel driver that based on synchronous clock
mode. But only specific N value (0x8000) would be acceptable for
LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode.
With the other N value, Tcon will enter BITS mode and display black screen.
Add this
Only specific N value (0x8000) would be acceptable for LG
LP140WF6-SPM1 eDP panel which is running at asynchronous
clock mode. With the other N value, it will enter BITS mode
and display black screen. This patch series set constant N
value for specific sink/branch device that would cover
similar
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #11 from Timothy Arceri ---
Getting an apitrace [1] of the issues would help with debugging.
[1] https://github.com/apitrace/apitrace/wiki/Steam
--
You are receiving this mail because:
You are the assignee for the
On Wed 9/12/2018 8:12 AM , Dhinakaran Pandiyan wrote:
>> DP quirk list just compare sink or branch device's OUI so far.
>> That means particular vendor's products will be applied specific
>> change. This change would confirm device_id the same or not.
>> Then driver can implement some changes
On Tue, 11 Sep 2018, Jani Nikula wrote:
>> Only specific N value (0x8000) would be acceptable for LG
>> LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode.
>> With the other N value, it will enter BITS mode and display black
>> screen. This patch series set constant N value for
https://bugs.freedesktop.org/show_bug.cgi?id=107898
--- Comment #4 from Felix Kühling ---
Created attachment 141532
--> https://bugs.freedesktop.org/attachment.cgi?id=141532=edit
Add iommu init instrumentation
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107898
--- Comment #3 from Felix Kühling ---
I'm not seeing this problem on my Raven system with 4.19-rc3+ ($ git describe
v4.19-rc3-21-g5e335542de83).
The most likely explanation is that on your system IOMMUv2 is not enabled. That
may be a BIOS
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #21 from madc...@atlas.cz ---
I just tried to run Unigine Superposition with llvm-6.0.1-7 and kernel 4.18.5
as they arrived to F28 and it finished fine twice. Witcher 3 still crashes
though.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=103300
--- Comment #5 from Timothy Arceri ---
(In reply to Ian Bruene from comment #4)
> I tried today and was unable to get a trace I'm afraid.
Looks like the game is 32-bit so a 32bit build of apitrace is needed. 64bit
distros usually only ship a
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #54 from CheatCodesOfLife ---
Oh and my umr spits out a lot of things to stderr as well, with both this and
the MK8 crash. Let me know if you want this.
--
You are receiving this mail because:
You are the assignee for the
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: d8de8260a45aae8f74af77eae9a162bdc0ed48d2
commit: 1c860a022f65224d6e8af71cc9f1411cb779f666 [309/310] drm/amdgpu: add
amdgpu_vm_update_func
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: d8de8260a45aae8f74af77eae9a162bdc0ed48d2
commit: e498eb7136042aa9a352b1039c678537f4694158 [220/310] drm/amd/display: Add
support for hw_state logging via debugfs
coccinelle warnings: (new ones prefixed by >>)
>>
From: kbuild test robot
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c:771:1-3: WARNING:
PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: e498eb713604 ("drm/amd/display: Add support
On Icelake, a separate power well PG2 is created for
VDSC engine used for eDP/MIPI DSI. This patch adds a new
display power domain for Power well 2.
Cc: Rodrigo Vivi
Cc: Imre Deak
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_display.h| 1 +
After encoder->pre_enable() hook, after link training sequence is
completed, PPS registers for DSC encoder are configured using the
DSC state parameters in intel_crtc_state as part of DSC enabling
routine in the source. DSC enabling routine is called after
encoder->pre_enable() before enbaling the
DP 1.4 spec defines DP secondary data packet for DSC
picture parameter set. This patch defines its payload size
according to the DP 1.4 specification.
Signed-off-by: Manasi Navare
Cc: dri-devel@lists.freedesktop.org
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
1. Disable Left/right VDSC branch in DSS Ctrl reg
depending on the number of VDSC engines being used
2. Disable joiner in DSS Ctrl reg
v3 (From Manasi):
* Add Disable PG2 for VDSC on eDP
v2 (From Manasi):
* Use old_crtc_state to find dsc params
* Add a condition to disable only if
dsc state
If a eDP panel supports both PSR2 and VDSC, our HW cannot
support both at a time. Give priority to PSR2 if a requested
resolution can be supported without compression else enable
VDSC and keep PSR2 disabled.
v2:
* Add warning for DSC and PSR2 enabled together (DK)
Cc: Rodrigo Vivi
Cc: Jani
Display Stream Splitter registers need to be programmed to enable
the joiner if two DSC engines are used and also to enable
the left and the right DSC engines. This happens as part of
the DSC enabling routine in the source in atomic commit.
v2:
* Rebase (Manasi)
Cc: Jani Nikula
Cc: Ville
When DSC is supported we need to validate the modes based on the
maximum supported compressed BPP and maximum supported slice count.
This allows us to allow the modes with pixel clock greater than the
available link BW as long as it meets the compressed BPP
and slice count requirements.
v3:
* Use
VESA has developed an industry standard Display Stream Compression(DSC)
for interoperable, visually lossless compression over display links to
address the needs for higher resolution displays.
This patch series enables DSC on Gen 10 eDP and Gen 11 eDP/DP panels.
This implementation is based on
From: Gaurav K Singh
This patch enables decompression support in sink device
before link training and disables the same during the
DDI disabling.
v2:(From Manasi)
* Change the enable/disable function to take crtc_state
instead of intel_dp as an argument (Manasi)
* Use the compression_enable
DSC specification defines linebuf_depth which contains the
line buffer bit depth used to generate the bitstream.
These values are defined as per Table 4.1 in DSC 1.2 spec
v2 (From Manasi):
* Rename as MAX_LINEBUF_DEPTH for DSC 1.1 and DSC 1.2
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Infoframes are used to send secondary data packets. This patch
adds support for DSC Picture parameter set secondary data packets
in the existing write_infoframe helpers.
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
From: "Srivatsa, Anusha"
Add defines for DSS_CTL registers.
These registers specify the big joiner, splitter,
overlap pixels and info regarding display stream
compression enabled on left or right branch.
v3 (From Manasi):
- Change the hex values to lower case (Madhav)
- Use BIT macro (Manasi)
From: Gaurav K Singh
This patches does the following:
1. This patch defines all the DSC parameters as per the VESA
DSC specification. These are stored in the encoder and used
to compute the PPS parameters to be sent to the Sink.
2. Compute all the DSC parameters which are derived from DSC
state
DSC PPS secondary data packet infoframes are filled with
DSC picure parameter set metadata according to the DSC standard.
These infoframes are sent to the sink device and used during DSC
decoding.
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by:
This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
From: Gaurav K Singh
This computation of RC params happens in the atomic commit phase
during compute_config() to validate if display stream compression
can be enabled for the requested mode.
v5 (From Manasi):
* Fix dim checkpatch warnings/checks
v4(From Gaurav):
* No change.Rebase on drm-tip
DSC is supported on eDP starting GEN 10 display (on GLK) and on DP starting
GEN 11.
This patch implements the discovery phase of DSC. On hotplug,
source reads the DSC DPCD register set (0x00060 - 0x0006F) to
read the decompression capabilities of the sink device.
This entire block of registers is
Basic DSC parameters and DSC configuration data needs to be computed
for each of the requested mode during atomic check. This is
required since for certain modes, valid DSC parameters and config
data might not be computed in which case compression cannot be
enabled for that mode.
For that reason
From: "Srivatsa, Anusha"
DSC has some Rate Control values that remain constant
across all configurations. These are as per the DSC
standard.
v3:
* Define them in drm_dsc.h as they are
DSC constants (Manasi)
v2:
* Add DP_DSC_ prefix (Jani Nikula)
Cc: dri-devel@lists.freedesktop.org
Cc: Manasi
This patch adds helpers for calculating the maximum compressed BPP
supported with small joiner.
This also adds a helper for calculating the slice count in case
of small joiner.
These are inside intel_dp since they take into account hardware
limitations.
v6:
* Take mode_clock and mode_hdisplay as
From: Anusha Srivatsa
Add the newly added slice_row_per_frame parameter
in the Picture Parameter Set registers.
This defines the number of vertically stacked slices
in a frame.
Credits to Manasi for noticing bSpec change.
Suggested-by: Manasi Navare
Cc: Manasi Navare
Signed-off-by: Anusha
According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP
This patch defines the DP DSC receiver capability size that gives
total number of DP DSC DPCD registers.
This also adds a missing #defines for DP DSC support missed in the
commit id (ab6a46ea6842ce "Add DPCD definitions for DP 1.4 DSC feature")
v3:
* MIN_SLICE_WIDTH = 2560 (Anusha)
* Define
DSC params like the enable, compressed bpp, slice ocunt and
dsc_split are added to the intel_crtc_state. These parameters
are set based on the requested mode and available link parameters
during the pipe configuration in atomic check phase.
These values are then later used to populate the
From: Gaurav K Singh
This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder
v6: (From Manasi)
* Add a bit mask for RANGE_BPG_OFFSET for 6 bits(Manasi)
v5 (From Manasi)
* Add the RC constants as per the spec
v4 (From Manasi)
* Add the
This patch adds inline functions and helpers for obtaining
DP sink's supported DSC parameters like DSC sink support,
eDP compressed BPP supported, maximum slice count supported
by the sink devices, DSC line buffer bit depth supported on DP sink,
DSC sink maximum color depth by parsing
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_display.h
between commit:
dce888798d3e ("drm/i915: remove confusing GPIO vs PCH_GPIO")
from the drm tree and commit:
d78aa650670d ("drm: Add drm/drm_util.h header file")
from the
On Mon, 2018-09-10 at 14:43 +0300, Jani Nikula wrote:
> On Mon, 10 Sep 2018, "Lee, Shawn C" wrote:
> > The N value was computed by kernel driver that based on synchronous
> > clock
> > mode. But only specific N value (0x8000) would be acceptable for
> > LG LP140WF6-SPM1 eDP panel which is running
https://bugzilla.kernel.org/show_bug.cgi?id=201067
Dave Johnson (d...@locochino.com) changed:
What|Removed |Added
CC||d...@locochino.com
On Mon, 2018-09-10 at 08:26 -0700, Lee, Shawn C wrote:
> DP quirk list just compare sink or branch device's OUI so far.
> That means particular vendor's products will be applied specific
> change. This change would confirm device_id the same or not.
> Then driver can implement some changes for
Hi Marek and Andrzej,
2018년 08월 10일 22:29에 Marek Szyprowski 이(가) 쓴 글:
> From: Andrzej Pietrasiewicz
>
> Add support for 16x16 tiled formats: NV12/NV21, YUYV and YUV420.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Signed-off-by: Marek Szyprowski
> ---
>
On 09/11/2018 01:56 AM, Lee, Shawn C wrote:
Only specific N value (0x8000) would be acceptable for LG
LP140WF6-SPM1 eDP panel which is running at asynchronous
clock mode. With the other N value, it will enter BITS mode
and display black screen. This patch series set constant N
value for
https://bugzilla.kernel.org/show_bug.cgi?id=200621
--- Comment #16 from Jon (jon...@gmail.com) ---
This is what I got upon logging back in:
https://i.imgur.com/g3tLOQr.png
Problem Reporting
Name: kernel-core
Version: 4.17.19-200
First Detected: a minute ago (17:58)
Report: cannot be reported
https://bugs.freedesktop.org/show_bug.cgi?id=107907
--- Comment #1 from David Pinedo ---
Using LLVM 6.0, in case this is relevant.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hi Dave,
Here goes drm-intel-fixes-2018-09-11:
This contains a regression fix for video playbacks on gen 2 hardware,
a IPS timeout error suppression on Broadwell and GVT bucked with
"Most critical one is to fix KVM's mm reference when we access guest memory,
issue was raised by Linus [1], and
https://bugzilla.kernel.org/show_bug.cgi?id=201067
--- Comment #4 from Nick Sarnie (sar...@gentoo.org) ---
Hi Nicholas,
I can also confirm that the second patch fixes the issue.
Tested-by: Nick Sarnie
Please let me know if you need anything else.
Thanks,
Sarnex
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #26 from gr...@sub.red ---
Yes, I'm using DP (required for 144 Hz with WQHD).
However, I just reproduced the issue on a 19" monitor with 1280x1024 at 60 Hz
and with a cheap old mouse with a 100 Hz polling rate. The issue is no
https://bugs.freedesktop.org/show_bug.cgi?id=107907
Bug ID: 107907
Summary: Steam game Medieval II: Total War hangs on Ubuntu
18.04
Product: Mesa
Version: 18.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
Hi YueHaibing,
Thank you for the patch.
On Tuesday, 11 September 2018 15:00:53 EEST YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/omapdrm/dss/dispc.c: In function 'dispc_ovl_setup_common':
> drivers/gpu/drm/omapdrm/dss/dispc.c:2627:19: warning:
>
From: Emil Velikov
They're used internally and never meant to be part of the API.
Add the drm_private notation, which should resolve that.
v2: (Rodrigo) Add missing include.
Cc: Eric Engestrom
Cc: Lucas De Marchi
Cc: Chris Wilson
Cc: Rodrigo Vivi
Fixes: 4e81d4f9c9b ("intel: add generic
Hi Zhong Jiang,
Thank you for the patch.
On Tuesday, 11 September 2018 14:54:35 EEST zhong jiang wrote:
> We prefer to use ERR_CAST to do so.
> The issue is detected with the help of Coccinelle.
>
> Signed-off-by: zhong jiang
Reviewed-by: Laurent Pinchart
I expect Tomi to take this patch in
https://bugs.freedesktop.org/show_bug.cgi?id=107898
--- Comment #2 from Felix Kuehling ---
The AMD-Vi messages in the log look OK. I'm seeing the same on my Raven system
(Ryzen 5 2400G desktop).
I'm currently running a 4.19-rc1+ kernel from Alex Deucher's drm-next-4.20-wip
branch. I haven't
On Tue, Sep 11, 2018 at 10:10 PM, Mark Brown wrote:
> On Tue, Sep 11, 2018 at 08:47:28PM +0100, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 defconfig due to:
>
>> arm64-defconfig
>> ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>>
On Tue, Sep 11, 2018 at 01:33:25PM +0200, Maxime Ripard wrote:
> Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results in
> a link error, as we try to access a symbol from the sun8i_tcon_top.ko module:
>
> ERROR: "sun8i_tcon_top_de_config"
On Tue, Sep 11, 2018 at 08:47:28PM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build an arm64 defconfig due to:
> arm64-defconfig
> ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
> undefined!
> ERROR: "sun8i_tcon_top_set_hdmi_src"
https://bugzilla.kernel.org/show_bug.cgi?id=201015
--- Comment #9 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
Created attachment 278459
--> https://bugzilla.kernel.org/attachment.cgi?id=278459=edit
user log: patched kernel + xorg modesetting, resume failed
сен 12 01:05:22 X299
On Tue, Sep 11, 2018 at 1:59 PM Kazlauskas, Nicholas
wrote:
>
> On 09/11/2018 01:51 PM, Christian König wrote:
> > Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
> >> From: Harry Wentland
> >>
> >> Add the ioctl to enable/disable freesync.
> >
> > Why do we still need this now that we have
https://bugzilla.kernel.org/show_bug.cgi?id=201015
--- Comment #8 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
Created attachment 278457
--> https://bugzilla.kernel.org/attachment.cgi?id=278457=edit
kernel log: patched kernel + xorg modesetting, resume failed
Even with patched kernel,
On Tue, Sep 11, 2018 at 09:15:41AM +0200, Hans de Goede wrote:
> The default settings for Linux vms created in VirtualBox allocate only
> 16M of videomem. When running fullscreen on a 1920x1080 (or bigger) monitor
> this is not a lot.
>
> When using GNOME3 on Wayland we have already been seeing
On 2018-09-11 01:56 PM, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
>> On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
>>> On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #25 from tempel.jul...@gmail.com ---
It doesn't seem to be related to a certain GCN generation, as there are exactly
matching reports of at least Hawaii, Polaris 10/11 and Vega 10 (probably also
Fiji).
It probably neither is related
On Fri, Sep 07, 2018 at 05:24:08PM -0700, Jeykumar Sankaran wrote:
> Based on the comments received for the patch series[1] and to
> make the review process a bit more easy, spliting up the
> patches for cleanup and resource manager refactor. This series
> cleans up and prepares the DPU for
On 09/11/2018 01:56 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
> On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
> > On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> > > > Modern monitor hardware is
On Fri, Sep 07, 2018 at 08:41:36PM +0300, Haneen Mohammed wrote:
> Add an initial kerneldoc entry for vkms with a todo list.
>
> Signed-off-by: Haneen Mohammed
> ---
> Documentation/gpu/drivers.rst | 1 +
> Documentation/gpu/todo.rst | 12
> Documentation/gpu/vkms.rst
https://bugs.freedesktop.org/show_bug.cgi?id=105333
--- Comment #9 from Marek Olšák ---
You can try to set glsl_correct_derivatives_after_discard=true, but I don't
know if that works with nine.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105333
--- Comment #8 from Marek Olšák ---
ac_build_kill used an intrinsic that is no longer in LLVM.
ac_build_kill_if_false replaced it. The behavior should be identical.
--
You are receiving this mail because:
You are the assignee for the
On 09/11/2018 01:51 PM, Christian König wrote:
Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Why do we still need this now that we have the DRM CRTC properties?
These patches were already merged into amd-staging-drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #24 from Jordan L ---
The challenge here is that we still can't seem to reproduce this internally on
any of our setups. Can anyone identify a commonality in setup to help isolate
the reproducing behaviour?
--
You are receiving
On Tue, Sep 11, 2018 at 01:36:01PM -0400, Kazlauskas, Nicholas wrote:
> On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
> > On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> >> On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> >>> Modern monitor hardware is capable
Am 11.09.2018 um 18:13 schrieb Nicholas Kazlauskas:
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Why do we still need this now that we have the DRM CRTC properties?
Christian.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
https://bugzilla.kernel.org/show_bug.cgi?id=201067
Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) changed:
What|Removed |Added
Attachment #278423|0 |1
https://bugzilla.kernel.org/show_bug.cgi?id=200621
--- Comment #15 from Jon (jon...@gmail.com) ---
Last night I installed a new m.2 SSD. Installed a fresh copy of Fedora 28
Workstation and ran all updates then locked the screen. Came back this morning
and computer was frozen again. I will post
On 09/11/2018 12:31 PM, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
Modern monitor hardware is capable of supporting variable refresh rates
and adaptive sync technologies. The
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> > Modern monitor hardware is capable of supporting variable refresh rates
> > and adaptive sync technologies. The properties for querying and
> > controlling
Thanks for the patch, I have meant to send these patches out sitting in
my internal tree but never got to it.
Find my comments below:
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> Modern monitor hardware is capable of supporting variable refresh rates
> and adaptive sync
On Tue, 11 Sep 2018, "Lee, Shawn C" wrote:
> Only specific N value (0x8000) would be acceptable for LG
> LP140WF6-SPM1 eDP panel which is running at asynchronous
> clock mode. With the other N value, it will enter BITS mode
> and display black screen. This patch series set constant N
> value for
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> > Modern monitor hardware is capable of supporting variable refresh rates
> > and adaptive sync technologies. The properties for querying and
> > controlling
On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote:
> Modern monitor hardware is capable of supporting variable refresh rates
> and adaptive sync technologies. The properties for querying and
> controlling these features should be exposed on the DRM connector.
>
> This patch
On Tue, Sep 11, 2018 at 04:48:42PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Tue, Sep 11, 2018 at 04:45:25PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 11, 2018 at 02:20:22PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > > Hi Ville,
> > >
> > > On Tue, Sep 11, 2018 at 03:27:09PM +0300, Ville
With the introduction of new properties in DRM these amdgpu driver
specific ones are no longer necessary.
Change-Id: Idc88f2e3e036aacc8fe726b15db03d900e509e7c
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 12
This is no longer needed with the addition of the DRM properties.
The base driver correctly checks that notify_freesync is non-null before
calling so there shouldn't be any null pointer dereferences as a result
of this.
Change-Id: If0833b201c81303ca4062393e873faf3ef7c143b
Signed-off-by: Nicholas
DRM has built-in support for variable refresh properties on the
connector and CRTC. Make use of these instead of the amdpgu specific
freesync properties.
The connector properties freesync and freesync_capable are replaced with
variable_refresh_enabled and variable_refresh_capable.
The CRTC
From: Harry Wentland
Add the ioctl to enable/disable freesync.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 15 +++
From: Harry Wentland
Add connector properties for controlling freesync.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 4
From: Harry Wentland
Add code to tear down freesync modules when disabled.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 40 ++-
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git
Variable refresh rate algorithms have typically been enabled only
when the display is covered by a single source of content.
This patch introduces a new default CRTC property that helps
hint to the driver when the CRTC composition is suitable for variable
refresh rate algorithms. Userspace can
Modern monitor hardware is capable of supporting variable refresh rates
and adaptive sync technologies. The properties for querying and
controlling these features should be exposed on the DRM connector.
This patch introduces two new properties for variable refresh rate
support:
-
=== Adaptive sync and variable refresh rate ===
Adaptive sync is part of the DisplayPort spec and allows for graphics adapters
to drive displays with varying frame timings.
Variable refresh rate (VRR) is essentially the same, but defined for HDMI.
=== Use cases for variable refresh rate ===
On Tue, Sep 11, 2018 at 04:45:25PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 02:20:22PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > Hi Ville,
> >
> > On Tue, Sep 11, 2018 at 03:27:09PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 10, 2018 at 06:29:46PM +0100, Alexandru Gheorghe
Hi Laurent,
On Tue, Sep 04, 2018 at 03:10:19PM +0300, Laurent Pinchart wrote:
> All Gen3 SoCs supported so far have a fixed association between DPAD0
> and DU channels, which led to hardcoding that association when writing
> the corresponding hardware register. The D3 and E3 will break that
>
Hi Lucas,
Maybe you have any comments or remarks about this patch? And if you don't could
you please apply it.
Thanks!
On Thu, 2018-08-23 at 19:38 +0300, Eugeniy Paltsev wrote:
> As for today etnaviv device doesn't setup dma_mask.
> The etnaviv device is a virtual device not represented in DT
https://bugs.freedesktop.org/show_bug.cgi?id=107880
--- Comment #10 from Marvin Damschen ---
(In reply to jam...@amd.com from comment #9)
> Did you install old AMD ROCm package on this system before?
Yes, I did. I now believe that removing all traces of rocm-dkms eliminated the
root of the
Hi Gerd,
Thank you for the patch.
On Tuesday, 11 September 2018 16:42:15 EEST Gerd Hoffmann wrote:
> Reported-by: Laurent Pinchart
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Laurent Pinchart
> ---
> drivers/dma-buf/udmabuf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Hi Gerd,
Thank you for the patch.
On Tuesday, 11 September 2018 16:42:14 EEST Gerd Hoffmann wrote:
Still no commit message ? :-)
> Reported-by: Laurent Pinchart
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Laurent Pinchart
> ---
> drivers/dma-buf/udmabuf.c | 3 ---
> 1 file changed, 3
1 - 100 of 202 matches
Mail list logo
