Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 11月, 2022 1 次提交
  3. 11 11月, 2022 1 次提交
    • V
      drm/amdgpu: Use drm_mode_init() for on-stack modes · 0a204ce0
      由 Ville Syrjälä 提交于 
      Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.

Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;

@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(&M, &E);
+
S1

@@
expression decl.E;
@@
- &*E
+ E

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      0a204ce0
  5. 10 11月, 2022 1 次提交
  7. 01 11月, 2022 1 次提交
  9. 28 10月, 2022 5 次提交
  11. 26 10月, 2022 1 次提交
  13. 20 10月, 2022 1 次提交
  15. 15 10月, 2022 1 次提交
    • N
      drm/amd/display: Fix build breakage with CONFIG_DEBUG_FS=n · 2130b87b
      由 Nathan Chancellor 提交于 
      After commit 8799c0be ("drm/amd/display: Fix vblank refcount in vrr
transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
misplaced brace, along the lines of:

  In file included from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_trace.h:39,
                   from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:41:
  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: At top level:
  ./include/drm/drm_atomic.h:864:9: error: expected identifier or ‘(’ before ‘for’
    864 |         for ((__i) = 0;                                                 \
        |         ^~~
  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8317:9: note: in expansion of macro ‘for_each_new_crtc_in_state’
   8317 |         for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~

Move the brace within the #ifdef so that the file can be built with or
without CONFIG_DEBUG_FS.

Fixes: 8799c0be ("drm/amd/display: Fix vblank refcount in vrr transition")
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2130b87b
  17. 11 10月, 2022 1 次提交
    • F
      drm/amd/display: Validate DSC After Enable All New CRTCs · 876fcc42
      由 Fangzhi Zuo 提交于 
      Before enabling new crtc, stream_count in dc_state does not sync with
that in drm_atomic_state. Validating dsc in such case would leave newly
added stream not jointly participating in dsc optimization with existing
streams, but simply using default initialized vcpi all the time which
gives wrong dsc determination decision.

Consider the scenaio where one 4k60 connected to the dock under dp-alt mode.
Since dp-alt mode is 2-lane setup, stream 1 consumes 63 slots with dsc needed.
Then hook up a second 4k60 to the dock.
stream 2 connected with 65 slot initialized by default without dsc.  dsc
pre validate will not jointly optimize stream 2 with stream 1 before
crtc 2 added into the dc_state. That leads to stream 2 not getting dsc
optimization, and trigger atomic_check failure all the time, as 65 > 63
limit.

After getting all new crtcs added into the state, stream_count in
dc_state correctly reflect that in drm_atomic_state which comes up with
correct dsc decision.

Fixes: 71be4b16 ("drm/amd/display: dsc validate fail not pass to atomic check")
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NQingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Tested-by: NMark Broadworth <mark.broadworth@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      876fcc42
  19. 07 10月, 2022 2 次提交
  21. 22 9月, 2022 1 次提交
  23. 20 9月, 2022 1 次提交
  25. 14 9月, 2022 3 次提交
  27. 03 9月, 2022 1 次提交
    • H
      drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration · c0f50c5d
      由 Hans de Goede 提交于 
      Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.

This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.

Add a call to the new acpi_video_register_backlight() when amdgpu skips
registering its own backlight device because of either the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the amdgpu drm_device gets registered with userspace.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      c0f50c5d
  29. 02 9月, 2022 1 次提交
  31. 30 8月, 2022 1 次提交
  33. 26 8月, 2022 1 次提交
  35. 25 8月, 2022 1 次提交
    • H
      drm/amdgpu: Don't register backlight when another backlight should be used (v3) · da11ef83
      由 Hans de Goede 提交于 
      Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.

Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.

Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
  a module, select ACPI_VIDEO and its deps if ACPI is enabled.
  When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
  the stubs from acpi/video.h will be used.

Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
  adjust the Kconfig changes to match this.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      da11ef83
  37. 24 8月, 2022 4 次提交
    • L
      drm/display/dp_mst: Move all payload info into the atomic state · 4d07b0bc
      由 Lyude Paul 提交于 
      Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as there's a lot of duplicated logic that doesn't really need to be
here. As well, this should make introducing features like fallback link
retraining and DSC support far easier.

Since the old payload code was pretty gnarly and there's a Lot of changes
here, I expect this might be a bit difficult to review. So to make things
as easy as possible for reviewers, I'll sum up how both the old and new
code worked here (it took me a while to figure this out too!).

The old MST code basically worked by maintaining two different payload
tables - proposed_vcpis, and payloads. proposed_vcpis would hold the
modified payload we wanted to push to the topology, while payloads held the
payload table that was currently programmed in hardware. Modifications to
proposed_vcpis would be handled through drm_dp_allocate_vcpi(),
drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they
would be pushed via drm_dp_mst_update_payload_step1() and
drm_dp_mst_update_payload_step2().

Furthermore, it's important to note how adding and removing VC payloads
actually worked with drm_dp_mst_update_payload_step1(). When a VC payload
is removed from the VC table, all VC payloads which come after the removed
VC payload's slots must have their time slots shifted towards the start of
the table. The old code handles this by looping through the entire payload
table and recomputing the start slot for every payload in the topology from
scratch. While very much overkill, this ends up doing the right thing
because we always order the VCPIs for payloads from first to last starting
timeslot.

It's important to also note that drm_dp_mst_update_payload_step2() isn't
actually limited to updating a single payload - the driver can use it to
queue up multiple payload changes so that as many of them can be sent as
possible before waiting for the ACT. This is -technically- not against
spec, but as Wayne Lin has pointed out it's not consistently implemented
correctly in hubs - so it might as well be.

drm_dp_mst_update_payload_step2() is pretty self explanatory and basically
the same between the old and new code, save for the fact we don't have a
second step for deleting payloads anymore -and thus rename it to
drm_dp_mst_add_payload_step2().

The new payload code stores all of the current payload info within the MST
atomic state and computes as much of the state as possible ahead of time.
This has the one exception of the starting timeslots for payloads, which
can't be determined at atomic check time since the starting time slots will
vary depending on what order CRTCs are enabled in the atomic state - which
varies from driver to driver. These are still stored in the atomic MST
state, but are only copied from the old MST state during atomic commit
time. Likewise, this is when new start slots are determined.

Adding/removing payloads now works much more closely to how things are
described in the spec. When we delete a payload, we loop through the
current list of payloads and update the start slots for any payloads whose
time slots came after the payload we just deleted. Determining the starting
time slots for new payloads being added is done by simply keeping track of
where the end of the VC table is in
drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting
that we no longer have a single update_payload() function. Instead, we now
have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As
such, it's now left it up to the driver to figure out when to add or remove
payloads. The driver already knows when it's disabling/enabling CRTCs, so
it also already knows when payloads should be added or removed.

Changes since v1:
* Refactor around all of the completely dead code changes that are
  happening in amdgpu for some reason when they really shouldn't even be
  there in the first place… :\
* Remove mention of sending one ACT per series of payload updates. As Wayne
  Lin pointed out, there are apparently hubs on the market that don't work
  correctly with this scheme and require a separate ACT per payload update.
* Fix accidental drop of mst_mgr.lock - Wayne Lin
* Remove mentions of allowing multiple ACT updates per payload change,
  mention that this is a result of vendors not consistently supporting this
  part of the spec and requiring a unique ACT for each payload change.
* Get rid of reference to drm_dp_mst_port in DC - turns out I just got
  myself confused by DC and we don't actually need this.
Changes since v2:
* Get rid of fix for not sending payload deallocations if ddps=0 and just
  go back to wayne's fix
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-18-lyude@redhat.com
      4d07b0bc
    • L
      drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions · a76eb429
      由 Lyude Paul 提交于 
      There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:

* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
  different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
  share no drm resources

We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state. So, let's add some simple helpers
for doing that and hook them up in various drivers.

v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
  CI failures
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-14-lyude@redhat.com
      a76eb429
    • L
      drm/display/dp_mst: Add nonblocking helpers for DP MST · a5c2c0d1
      由 Lyude Paul 提交于 
      As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.

This could potentially cause problems if something like this happens:

* User starts non-blocking commit to disable CRTC-1 on MST topology 1
* User starts non-blocking commit to enable CRTC-2 on MST topology 1

There's no guarantee here that the commit for disabling CRTC-2 will only
occur after CRTC-1 has finished, since neither commit shares a CRTC - only
the private modesetting object for MST. Keep in mind this likely isn't a
problem for blocking modesets, only non-blocking.

So, begin fixing this by keeping track of which CRTCs on a topology have
changed by keeping track of which CRTCs we release or allocate timeslots
on. As well, add some helpers for:

* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state

v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-9-lyude@redhat.com
      a5c2c0d1
    • L
      drm/display/dp_mst: Call them time slots, not VCPI slots · df78f7f6
      由 Lyude Paul 提交于 
      VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.

Now that we actually have consistent access to the DisplayPort spec thanks
to VESA, I now know this isn't actually the proper term - as the
specification refers to these as time slots.

Since we're trying to make this code as easy to figure out as possible,
let's take this opportunity to correct this nomenclature and call them by
their proper name - timeslots. Likewise, we rename various functions
appropriately, along with replacing references in the kernel documentation
and various debugging messages.

It's important to note that this patch series leaves the legacy MST code
untouched for the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.

v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
  the source DP Tx and the immediate downstream DP Rx
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-5-lyude@redhat.com
      df78f7f6
  39. 17 8月, 2022 1 次提交
  41. 12 8月, 2022 1 次提交
  43. 11 8月, 2022 2 次提交
    • A
      drm/amdgpu: Only disable prefer_shadow on hawaii · a6250bdb
      由 Alex Deucher 提交于 
      We changed it for all asics due to a hibernation regression
on hawaii, but the workaround breaks suspend on a polaris12.
Just disable it for hawaii.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216119
Fixes: 3a4b1cc2 ("drm/amdgpu/display: disable prefer_shadow for generic fb helpers")
Reviewed-and-tested-by: NMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      a6250bdb
    • M
      drm/amd/display: set panel orientation before drm_dev_register · acc96ae0
      由 Melissa Wen 提交于 
      To set the panel orientation property with quirk, we need the mode size
provided by EDID. This info is available after EDID is read by dc_link_detect()
and updated by amdgpu_dm_update_connector_after_detect(). The detection
happens at driver load in amdgpu_dm_initialize_drm_device() and,
therefore, we can get modes and set panel orientation before
drm_dev_register() to avoid DRM warns on creating the connector property
after device registration:

[    2.563969] ------------[ cut here ]------------
[    2.563971] WARNING: CPU: 6 PID: 325 at drivers/gpu/drm/drm_mode_object.c:45 drm_mode_object_add+0x72/0x80 [drm]
[    2.563997] Modules linked in: btusb btrtl btbcm btintel btmtk bluetooth rfkill ecdh_generic ecc usbhid crc16 amdgpu(+) drm_ttm_helper ttm agpgart gpu_sched i2c_algo_bit drm_display_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm serio_raw sdhci_pci atkbd libps2 cqhci vivaldi_fmap ccp sdhci i8042 crct10dif_pclmul crc32_pclmul hid_multitouch ghash_clmulni_intel aesni_intel crypto_simd cryptd wdat_wdt mmc_core cec xhci_pci sp5100_tco rng_core xhci_pci_renesas serio 8250_dw i2c_hid_acpi i2c_hid btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_mirror dm_region_hash dm_log dm_mod pkcs8_key_parser crypto_user
[    2.564032] CPU: 6 PID: 325 Comm: systemd-udevd Not tainted 5.18.0-amd-staging-drm-next+ #67
[    2.564034] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0105 03/21/2022
[    2.564036] RIP: 0010:drm_mode_object_add+0x72/0x80 [drm]
[    2.564053] Code: f0 89 c3 85 c0 78 07 89 45 00 44 89 65 04 4c 89 ef e8 e2 99 04 f1 31 c0 85 db 0f 4e c3 5b 5d 41 5c 41 5d c3 80 7f 50 00 74 ac <0f> 0b eb a8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 4c
[    2.564055] RSP: 0018:ffffb2e880413860 EFLAGS: 00010202
[    2.564056] RAX: ffffffffc0ba1440 RBX: ffff99508a860010 RCX: 0000000000000001
[    2.564057] RDX: 00000000b0b0b0b0 RSI: ffff99508c050110 RDI: ffff99508a860010
[    2.564058] RBP: ffff99508c050110 R08: 0000000000000020 R09: ffff99508c292c20
[    2.564059] R10: 0000000000000000 R11: ffff99508c0507d8 R12: 00000000b0b0b0b0
[    2.564060] R13: 0000000000000004 R14: ffffffffc068a4b6 R15: ffffffffc068a47f
[    2.564061] FS:  00007fc69b5f1a40(0000) GS:ffff9953aff80000(0000) knlGS:0000000000000000
[    2.564063] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.564063] CR2: 00007f9506804000 CR3: 0000000107f92000 CR4: 0000000000350ee0
[    2.564065] Call Trace:
[    2.564068]  <TASK>
[    2.564070]  drm_property_create+0xc9/0x170 [drm]
[    2.564088]  drm_property_create_enum+0x1f/0x70 [drm]
[    2.564105]  drm_connector_set_panel_orientation_with_quirk+0x96/0xc0 [drm]
[    2.564123]  get_modes+0x4fb/0x530 [amdgpu]
[    2.564378]  drm_helper_probe_single_connector_modes+0x1ad/0x850 [drm_kms_helper]
[    2.564390]  drm_client_modeset_probe+0x229/0x1400 [drm]
[    2.564411]  ? xas_store+0x52/0x5e0
[    2.564416]  ? kmem_cache_alloc_trace+0x177/0x2c0
[    2.564420]  __drm_fb_helper_initial_config_and_unlock+0x44/0x4e0 [drm_kms_helper]
[    2.564430]  drm_fbdev_client_hotplug+0x173/0x210 [drm_kms_helper]
[    2.564438]  drm_fbdev_generic_setup+0xa5/0x166 [drm_kms_helper]
[    2.564446]  amdgpu_pci_probe+0x35e/0x370 [amdgpu]
[    2.564621]  local_pci_probe+0x45/0x80
[    2.564625]  ? pci_match_device+0xd7/0x130
[    2.564627]  pci_device_probe+0xbf/0x220
[    2.564629]  ? sysfs_do_create_link_sd+0x69/0xd0
[    2.564633]  really_probe+0x19c/0x380
[    2.564637]  __driver_probe_device+0xfe/0x180
[    2.564639]  driver_probe_device+0x1e/0x90
[    2.564641]  __driver_attach+0xc0/0x1c0
[    2.564643]  ? __device_attach_driver+0xe0/0xe0
[    2.564644]  ? __device_attach_driver+0xe0/0xe0
[    2.564646]  bus_for_each_dev+0x78/0xc0
[    2.564648]  bus_add_driver+0x149/0x1e0
[    2.564650]  driver_register+0x8f/0xe0
[    2.564652]  ? 0xffffffffc1023000
[    2.564654]  do_one_initcall+0x44/0x200
[    2.564657]  ? kmem_cache_alloc_trace+0x177/0x2c0
[    2.564659]  do_init_module+0x4c/0x250
[    2.564663]  __do_sys_init_module+0x12e/0x1b0
[    2.564666]  do_syscall_64+0x3b/0x90
[    2.564670]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[    2.564673] RIP: 0033:0x7fc69bff232e
[    2.564674] Code: 48 8b 0d 45 0b 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 12 0b 0c 00 f7 d8 64 89 01 48
[    2.564676] RSP: 002b:00007ffe872ba3e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
[    2.564677] RAX: ffffffffffffffda RBX: 000055873f797820 RCX: 00007fc69bff232e
[    2.564678] RDX: 000055873f7bf390 RSI: 0000000001155e81 RDI: 00007fc699e4d010
[    2.564679] RBP: 00007fc699e4d010 R08: 000055873f7bfe20 R09: 0000000001155e90
[    2.564680] R10: 000000055873f7bf R11: 0000000000000246 R12: 000055873f7bf390
[    2.564681] R13: 000000000000000d R14: 000055873f7c4cb0 R15: 000055873f797820
[    2.564683]  </TASK>
[    2.564683] ---[ end trace 0000000000000000 ]---
[    2.564696] ------------[ cut here ]------------
[    2.564696] WARNING: CPU: 6 PID: 325 at drivers/gpu/drm/drm_mode_object.c:242 drm_object_attach_property+0x52/0x80 [drm]
[    2.564717] Modules linked in: btusb btrtl btbcm btintel btmtk bluetooth rfkill ecdh_generic ecc usbhid crc16 amdgpu(+) drm_ttm_helper ttm agpgart gpu_sched i2c_algo_bit drm_display_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm serio_raw sdhci_pci atkbd libps2 cqhci vivaldi_fmap ccp sdhci i8042 crct10dif_pclmul crc32_pclmul hid_multitouch ghash_clmulni_intel aesni_intel crypto_simd cryptd wdat_wdt mmc_core cec xhci_pci sp5100_tco rng_core xhci_pci_renesas serio 8250_dw i2c_hid_acpi i2c_hid btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_mirror dm_region_hash dm_log dm_mod pkcs8_key_parser crypto_user
[    2.564738] CPU: 6 PID: 325 Comm: systemd-udevd Tainted: G        W         5.18.0-amd-staging-drm-next+ #67
[    2.564740] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0105 03/21/2022
[    2.564741] RIP: 0010:drm_object_attach_property+0x52/0x80 [drm]
[    2.564759] Code: 2d 83 f8 18 74 33 48 89 74 c1 08 48 8b 4f 08 48 89 94 c1 c8 00 00 00 48 8b 47 08 83 00 01 c3 4d 85 d2 75 dd 83 7f 58 01 75 d7 <0f> 0b eb d3 41 80 78 50 00 74 cc 0f 0b eb c8 44 89 ce 48 c7 c7 28
[    2.564760] RSP: 0018:ffffb2e8804138d8 EFLAGS: 00010246
[    2.564761] RAX: 0000000000000010 RBX: ffff99508c1a2000 RCX: ffff99508c1a2180
[    2.564762] RDX: 0000000000000003 RSI: ffff99508c050100 RDI: ffff99508c1a2040
[    2.564763] RBP: 00000000ffffffff R08: ffff99508a860010 R09: 00000000c0c0c0c0
[    2.564763] R10: 0000000000000000 R11: 0000000000000020 R12: ffff99508a860010
[    2.564764] R13: ffff995088733008 R14: ffff99508c1a2000 R15: ffffffffc068a47f
[    2.564765] FS:  00007fc69b5f1a40(0000) GS:ffff9953aff80000(0000) knlGS:0000000000000000
[    2.564766] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.564767] CR2: 00007f9506804000 CR3: 0000000107f92000 CR4: 0000000000350ee0
[    2.564768] Call Trace:
[    2.564769]  <TASK>
[    2.564770]  drm_connector_set_panel_orientation_with_quirk+0x4a/0xc0 [drm]
[    2.564789]  get_modes+0x4fb/0x530 [amdgpu]
[    2.565024]  drm_helper_probe_single_connector_modes+0x1ad/0x850 [drm_kms_helper]
[    2.565036]  drm_client_modeset_probe+0x229/0x1400 [drm]
[    2.565056]  ? xas_store+0x52/0x5e0
[    2.565060]  ? kmem_cache_alloc_trace+0x177/0x2c0
[    2.565062]  __drm_fb_helper_initial_config_and_unlock+0x44/0x4e0 [drm_kms_helper]
[    2.565072]  drm_fbdev_client_hotplug+0x173/0x210 [drm_kms_helper]
[    2.565080]  drm_fbdev_generic_setup+0xa5/0x166 [drm_kms_helper]
[    2.565088]  amdgpu_pci_probe+0x35e/0x370 [amdgpu]
[    2.565261]  local_pci_probe+0x45/0x80
[    2.565263]  ? pci_match_device+0xd7/0x130
[    2.565265]  pci_device_probe+0xbf/0x220
[    2.565267]  ? sysfs_do_create_link_sd+0x69/0xd0
[    2.565268]  really_probe+0x19c/0x380
[    2.565270]  __driver_probe_device+0xfe/0x180
[    2.565272]  driver_probe_device+0x1e/0x90
[    2.565274]  __driver_attach+0xc0/0x1c0
[    2.565276]  ? __device_attach_driver+0xe0/0xe0
[    2.565278]  ? __device_attach_driver+0xe0/0xe0
[    2.565279]  bus_for_each_dev+0x78/0xc0
[    2.565281]  bus_add_driver+0x149/0x1e0
[    2.565283]  driver_register+0x8f/0xe0
[    2.565285]  ? 0xffffffffc1023000
[    2.565286]  do_one_initcall+0x44/0x200
[    2.565288]  ? kmem_cache_alloc_trace+0x177/0x2c0
[    2.565290]  do_init_module+0x4c/0x250
[    2.565291]  __do_sys_init_module+0x12e/0x1b0
[    2.565294]  do_syscall_64+0x3b/0x90
[    2.565296]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[    2.565297] RIP: 0033:0x7fc69bff232e
[    2.565298] Code: 48 8b 0d 45 0b 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 12 0b 0c 00 f7 d8 64 89 01 48
[    2.565299] RSP: 002b:00007ffe872ba3e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
[    2.565301] RAX: ffffffffffffffda RBX: 000055873f797820 RCX: 00007fc69bff232e
[    2.565302] RDX: 000055873f7bf390 RSI: 0000000001155e81 RDI: 00007fc699e4d010
[    2.565303] RBP: 00007fc699e4d010 R08: 000055873f7bfe20 R09: 0000000001155e90
[    2.565303] R10: 000000055873f7bf R11: 0000000000000246 R12: 000055873f7bf390
[    2.565304] R13: 000000000000000d R14: 000055873f7c4cb0 R15: 000055873f797820
[    2.565306]  </TASK>
[    2.565307] ---[ end trace 0000000000000000 ]---

--

v2:
- call amdgpu_dm_connector_get_modes() instead of ddc_get_modes() (Harry)

Fixes: d77de788 ("amd/display: enable panel orientation quirks")
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMelissa Wen <mwen@igalia.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      acc96ae0
  45. 27 7月, 2022 1 次提交
  47. 25 7月, 2022 4 次提交
  49. 21 7月, 2022 1 次提交
  51. 15 7月, 2022 1 次提交