This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid…
The details are mentioned in DP to HDMI2.1 PCON Enum/Config
improvement slide decks:
https://groups.vesa.org/wg/DP/document/folder/1316
This RFC series starts with adding support for FRL (Fixed Rate Link)
Training between the PCON and HDMI2.1 sink.
As per …
[View More]HDMI2.1 specification, a new data-channel or lane is added in
FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher
bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4
lanes).
With these patches, the HDMI2.1 PCON can be configured to achieve FRL
training based on the maximum FRL rate supported by the panel, source
and the PCON.
The approach is to add the support for FRL training between PCON and
HDMI2.1 sink and gradually add other blocks for supporting higher
resolutions and other HDMI2.1 features, that can be supported by pcon
for the sources that do not natively support HDMI2.1.
This is done before the DP Link training between the source and PCON
is started. In case of FRL training is not achieved, the PCON will
work in the regular TMDS mode, without HDMI2.1 feature support.
Any interruption in FRL training between the PCON and HDMI2.1 sink is
notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD
registers are read and FRL training is re-attempted.
Currently, we have tested the FRL training and are able to enable 4K
display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting
panel.
v2: Added patch to capture the PCON FRL caps in downstream facing port
cap structure.
Ankit Nautiyal (4):
drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON
drm/i915: Capture max frl rate for PCON in dfp cap structure
drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
drm/i915: Check for FRL training before DP Link training
Swati Sharma (4):
drm/edid: Add additional HFVSDB fields for HDMI2.1
drm/edid: Parse MAX_FRL field from HFVSDB block
drm/dp_helper: Add support for link status and link recovery
drm/i915: Add support for enabling link status and recovery
drivers/gpu/drm/drm_dp_helper.c | 338 ++++++++++++++++++
drivers/gpu/drm/drm_edid.c | 50 +++
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +
.../drm/i915/display/intel_display_types.h | 7 +
drivers/gpu/drm/i915/display/intel_dp.c | 282 ++++++++++++++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
include/drm/drm_connector.h | 6 +
include/drm/drm_dp_helper.h | 96 +++++
include/drm/drm_edid.h | 30 ++
9 files changed, 808 insertions(+), 5 deletions(-)
--
2.17.1
[View Less]
From: Rob Clark <robdclark(a)chromium.org>
This doesn't remove *all* the struct_mutex, but it covers the worst
of it, ie. shrinker/madvise/free/retire. The submit path still uses
struct_mutex, but it still needs *something* serialize a portion of
the submit path, and lock_stat mostly just shows the lock contention
there being with other submits. And there are a few other bits of
struct_mutex usage in less critical paths (debugfs, etc). But this
seems like a reasonable step in the …
[View More]right direction.
Rob Clark (14):
drm/msm: Use correct drm_gem_object_put() in fail case
drm/msm: Drop chatty trace
drm/msm: Move update_fences()
drm/msm: Add priv->mm_lock to protect active/inactive lists
drm/msm: Document and rename preempt_lock
drm/msm: Protect ring->submits with it's own lock
drm/msm: Refcount submits
drm/msm: Remove obj->gpu
drm/msm: Drop struct_mutex from the retire path
drm/msm: Drop struct_mutex in free_object() path
drm/msm: remove msm_gem_free_work
drm/msm: drop struct_mutex in madvise path
drm/msm: Drop struct_mutex in shrinker path
drm/msm: Don't implicit-sync if only a single ring
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +-
drivers/gpu/drm/msm/msm_debugfs.c | 7 ++
drivers/gpu/drm/msm/msm_drv.c | 15 +---
drivers/gpu/drm/msm/msm_drv.h | 19 +++--
drivers/gpu/drm/msm/msm_gem.c | 76 ++++++------------
drivers/gpu/drm/msm/msm_gem.h | 53 +++++++++----
drivers/gpu/drm/msm/msm_gem_shrinker.c | 58 ++------------
drivers/gpu/drm/msm/msm_gem_submit.c | 17 ++--
drivers/gpu/drm/msm/msm_gpu.c | 96 ++++++++++++++---------
drivers/gpu/drm/msm/msm_gpu.h | 5 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +-
drivers/gpu/drm/msm/msm_ringbuffer.h | 13 ++-
14 files changed, 188 insertions(+), 194 deletions(-)
--
2.26.2
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=209535
Bug ID: 209535
Summary: resume fails after hibernate amdgpu
Product: Drivers
Version: 2.5
Kernel Version: 5.8.11 gentoo
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
Reporter:…
[View More] s7mon(a)web.de
Regression: No
Created attachment 292841
--> https://bugzilla.kernel.org/attachment.cgi?id=292841&action=edit
dmesg with new bios (7C35v1C3)
Resume from hibernate fails with black screen and unresponsive system after
image loading is completed. If my interpretation of dmesg output is correct it
seems to be related to amdgpu (Radeon 5700 Navi 10 ).
Ssh to machine is possible.
Suspend to memory worked so far. As well as testing levels: freezer, devices,
platform, processors, core to /sys/power/pm_test with disk state according to:
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
When triggering hibernation (sys-power/pm-utils-1.4.1-r7) screen goes black but
before power is off it seems to be restored for 1-2 seconds - not sure if that
is normal or important.
I did an update to a newer bios without change of the behavior.
Harware is a MSI X570 board, Ryzen 3700X, 32G and said Radeon RX 5700.
Further details in dmesg and lspci.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
(Including a bunch more emails in the To: that got missed the first time)
Hello everyone!
The X.org board is soliciting proposals to host XDC in 2021. Since
XDC2020 is being held virtually this year, we've decided to host in
either North America or Europe. However, the board is open to other
locations, especially if there's an interesting co-location with another
conference.
Of course though, due to the ongoing COVID-19 pandemic it's not yet
clear whether or not it will be possible to host …
[View More]XDC2021 in person.
Because of this, we would like to make it clear that sponsors should
prepare for both the possibility of an in person conference, and the
possibility of a virtual conference. We will work with organizers on
coming up with a deadline for deciding whether or not we'll be going
virtual, likely sometime around July.
If you're considering hosting XDC, we've assembled a wiki page with
what's generally expected and needed:
https://www.x.org/wiki/Events/RFP/
When submitting your proposal, please make sure to include at least the
key information about the potential location in question, possible dates
along with estimated costs. Proposals can be submitted to board at
foundation.x.org until the deadline of November 1st. Additionally, an
quirk early heads-up to the board if you're considering hosting would be
appreciated, in case we need to adjust the schedule a bit. Also, earlier
is better since there generally will be a bit of Q&A with organizers.
And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
[View Less]
Hi all,
I am trying to convert the upstream tidss drm driver to new
connector model.
The connector is getting created by the tidss driver and bridges are
attached with flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
Here are some questions, regarding this:
1) Most of the info regarding bus_format and bus flags is coming from
the bridges. Is it okay to not populate connector->display_info with
bus_format and flags?
2) The "drm_atomic_bridge_chain_select_bus_fmts" does the format
negotiation. So is it …
[View More]okay for the encoder to simply pick the bus_format
from the first bridge's state?
3) What is the meaning of MEDIA_BUS_FMT_FIXED? Does it mean that the
bridge does not change the format from input to output?
4) The bus_flags are available in bridge->timings->input_bus_flags and
also in bridge_state->input_bus_cfg.flags. Which one should be used?
Regards,
Nikhil D
[View Less]
From: Randy Dunlap <rdunlap(a)infradead.org>
arch/arc/ implements BUG_ON() with BUG(). ARC has its own BUG()
function and that function uses pr_warn() as part of its implementation.
Several (8) files in amd/powerplay/ #undef various pr_xyz() functions so
that they won't be used by these drivers, since dev_() functions are
preferred here and the #undefs make the pr_() functions unavailable.
Hence the following build errors are reported in ARC builds:
../drivers/gpu/drm/amd/amdgpu/../…
[View More]powerplay/navi10_ppt.c: In function 'navi10_fill_i2c_req':
../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function 'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration]
../drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c: In function 'sienna_cichlid_fill_i2c_req':
../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function 'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration]
Fixes: 55084d7f4022 ("drm/amd/powerplay: forbid to use pr_err/warn/info/debug")
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Evan Quan <evan.quan(a)amd.com>
Cc: amd-gfx(a)lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Cc: Vineet Gupta <vgupta(a)synopsys.com>
Cc: linux-snps-arc(a)lists.infradead.org
---
Another alternative is for amd/powerplay/ drivers not to use BUG()
or BUG_ON().
A third alternative is to ask the ARC developers to implement BUG()
without using any pr_() functions.
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- lnx-59-rc7.orig/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ lnx-59-rc7/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -52,7 +52,7 @@
* They are more MGPU friendly.
*/
#undef pr_err
-#undef pr_warn
+//#undef pr_warn
#undef pr_info
#undef pr_debug
--- lnx-59-rc7.orig/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
+++ lnx-59-rc7/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
@@ -54,7 +54,7 @@
* They are more MGPU friendly.
*/
#undef pr_err
-#undef pr_warn
+//#undef pr_warn
#undef pr_info
#undef pr_debug
[View Less]