Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 11月, 2019 1 次提交
    • J
      drm/i915/mst: Check uapi enable not intel one during mst atomic check · c50bb4dd
      由 José Roberto de Souza 提交于 
      When the connector has VCPI allocated and is being moved to another
pipe it causes drm_dp_atomic_release_vcpi_slots() and
drm_dp_atomic_find_vcpi_slots() to be called in the same atomic check
causing the error bellow.
This happens because at this point Intel's hw.enable(and all other
flags in the same struct) is not set but checking to on the uapi one
it have the expected value.

[  580.804430] ------------[ cut here ]------------
[  580.804436] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.804439] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[  580.804462] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G        W         5.4.0-rc7-zeh+ #1226
[  580.804465] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.1909250226 09/25/2019
[  580.804470] Workqueue: events output_poll_execute
[  580.804476] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.804481] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[  580.804484] RSP: 0018:ffffc900009b7ab8 EFLAGS: 00010246
[  580.804488] RAX: ffff88848c04ef50 RBX: ffff88848c04ef40 RCX: 0000000000000214
[  580.804492] RDX: ffff88848c04f5e0 RSI: ffff888486eb2c68 RDI: ffff88848e518800
[  580.804495] RBP: ffff88849d339000 R08: 00000000bc4e1092 R09: 0000000000000000
[  580.804498] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848c04e728
[  580.804501] R13: 0000000000000214 R14: ffff88848c04e720 R15: ffff888486eb2c68
[  580.804504] FS:  0000000000000000(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
[  580.804507] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  580.804510] CR2: 00007ff6bf1ba680 CR3: 0000000005210003 CR4: 0000000000760ef0
[  580.804512] PKRU: 55555554
[  580.804515] Call Trace:
[  580.804574]  intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[  580.804636]  intel_atomic_check+0x10cc/0x20b0 [i915]
[  580.804644]  ? drm_atomic_print_old_state+0xf1/0x130
[  580.804655]  drm_atomic_check_only+0x56a/0x810
[  580.804663]  drm_atomic_commit+0xe/0x50
[  580.804668]  drm_client_modeset_commit_atomic+0x18b/0x220
[  580.804680]  drm_client_modeset_commit_force+0x4d/0x180
[  580.804685]  drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[  580.804689]  drm_fb_helper_set_par+0x27/0x50
[  580.804692]  drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[  580.804696]  drm_kms_helper_hotplug_event+0x21/0x30
[  580.804699]  output_poll_execute+0x1a4/0x1c0
[  580.804706]  process_one_work+0x25b/0x5b0
[  580.804713]  worker_thread+0x4b/0x3b0
[  580.804720]  kthread+0x100/0x140
[  580.804723]  ? process_one_work+0x5b0/0x5b0
[  580.804725]  ? kthread_park+0x80/0x80
[  580.804730]  ret_from_fork+0x24/0x50
[  580.804740] irq event stamp: 40988
[  580.804743] hardirqs last  enabled at (40987): [<ffffffff81128567>] console_unlock+0x437/0x590
[  580.804746] hardirqs last disabled at (40988): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[  580.804749] softirqs last  enabled at (40972): [<ffffffff81c00389>] __do_softirq+0x389/0x47f
[  580.804752] softirqs last disabled at (40959): [<ffffffff810b6f19>] irq_exit+0xa9/0xc0
[  580.804754] ---[ end trace 80052e0c60463c67 ]---
[  580.804758] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:000000007880692e] in the same state
[  580.811370] [drm:intel_dp_hpd_pulse [i915]] got esi2 02 00 00
[  580.817239] [drm:intel_dp_hpd_pulse [i915]] got esi 02 00 00
[  580.817313] ------------[ cut here ]------------
[  580.817318] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.817321] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal
[  580.817412] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on [ENCODER:306:DDI E] - short
[  580.817413]  usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul
[  580.817490] [drm:intel_dp_hpd_pulse [i915]]  is_mst
[  580.817491]  mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[  580.817498] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G        W         5.4.0-rc7-zeh+ #1226
[  580.817503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.1909250226 09/25/2019
[  580.817506] Workqueue: events output_poll_execute
[  580.817511] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.817514] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[  580.817516] RSP: 0018:ffffc900009b7ab8 EFLAGS: 00010246
[  580.817519] RAX: ffff88848c04ef50 RBX: ffff88848c04ef40 RCX: 000000000000018f
[  580.817521] RDX: ffff88848c04f5e0 RSI: ffff888486eb2c68 RDI: ffff88848e518800
[  580.817523] RBP: ffff88849d339000 R08: 00000000bc4e1092 R09: 0000000000000000
[  580.817525] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848c04e728
[  580.817528] R13: 000000000000018f R14: ffff88848c04e720 R15: ffff888486eb2c68
[  580.817532] FS:  0000000000000000(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
[  580.817534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  580.817535] CR2: 00007ff6bf1ba680 CR3: 0000000005210003 CR4: 0000000000760ef0
[  580.817537] PKRU: 55555554
[  580.817538] Call Trace:
[  580.817620]  intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[  580.817690]  intel_atomic_check+0x10cc/0x20b0 [i915]
[  580.817697]  ? drm_atomic_print_old_state+0xf1/0x130
[  580.817711]  drm_atomic_check_only+0x56a/0x810
[  580.817721]  drm_atomic_commit+0xe/0x50
[  580.817726]  drm_client_modeset_commit_atomic+0x18b/0x220
[  580.817744]  drm_client_modeset_commit_force+0x4d/0x180
[  580.817751]  drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[  580.817756]  drm_fb_helper_set_par+0x27/0x50
[  580.817762]  drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[  580.817767]  drm_kms_helper_hotplug_event+0x21/0x30
[  580.817771]  output_poll_execute+0x1a4/0x1c0
[  580.817780]  process_one_work+0x25b/0x5b0
[  580.817791]  worker_thread+0x4b/0x3b0
[  580.817800]  kthread+0x100/0x140
[  580.817804]  ? process_one_work+0x5b0/0x5b0
[  580.817807]  ? kthread_park+0x80/0x80
[  580.817813]  ret_from_fork+0x24/0x50
[  580.817832] irq event stamp: 41028
[  580.817838] hardirqs last  enabled at (41027): [<ffffffff81128567>] console_unlock+0x437/0x590
[  580.817841] hardirqs last disabled at (41028): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[  580.817846] softirqs last  enabled at (41022): [<ffffffff81c00389>] __do_softirq+0x389/0x47f
[  580.817851] softirqs last disabled at (41013): [<ffffffff810b6f19>] irq_exit+0xa9/0xc0
[  580.817854] ---[ end trace 80052e0c60463c68 ]---
[  580.817858] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:000000007880692e] in the same state
[  580.830767] [drm:intel_dp_mst_compute_config [i915]] failed finding vcpi slots:-22
[  580.830821] [drm:intel_atomic_check [i915]] Encoder config failure: -22

Cc: Lyude Paul <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115200430.53146-1-jose.souza@intel.com
      c50bb4dd
  3. 13 11月, 2019 1 次提交
  5. 11 11月, 2019 1 次提交
  7. 05 11月, 2019 1 次提交
  9. 01 11月, 2019 3 次提交
  11. 31 10月, 2019 3 次提交
  13. 25 10月, 2019 1 次提交
    • L
      drm/dp_mst: Protect drm_dp_mst_port members with locking · 3f9b3f02
      由 Lyude Paul 提交于 
      This is a complicated one. Essentially, there's currently a problem in the MST
core that hasn't really caused any issues that we're aware of (emphasis on "that
we're aware of"): locking.

When we go through and probe the link addresses and path resources in a
topology, we hold no locks when updating ports with said information. The
members I'm referring to in particular are:

- ldps
- ddps
- mcs
- pdt
- dpcd_rev
- num_sdp_streams
- num_sdp_stream_sinks
- available_pbn
- input
- connector

Now that we're handling UP requests asynchronously and will be using some of
the struct members mentioned above in atomic modesetting in the future for
features such as PBN validation, this is going to become a lot more important.
As well, the next few commits that prepare us for and introduce suspend/resume
reprobing will also need clear locking in order to prevent from additional
racing hilarities that we never could have hit in the past.

So, let's solve this issue by using &mgr->base.lock, the modesetting
lock which currently only protects &mgr->base.state. This works
perfectly because it allows us to avoid blocking connection_mutex
unnecessarily, and we can grab this in connector detection paths since
it's a ww mutex. We start by having drm_dp_mst_handle_up_req() hold this
when updating ports. For drm_dp_mst_handle_link_address_port() things
are a bit more complicated. As I've learned the hard way, we can grab
&mgr->lock.base for everything except for port->connector. See, our
normal driver probing paths end up generating this rather obvious
lockdep chain:

&drm->mode_config.mutex
  -> crtc_ww_class_mutex/crtc_ww_class_acquire
    -> &connector->mutex

However, sysfs grabs &drm->mode_config.mutex in order to protect itself
from connector state changing under it. Because this entails grabbing
kn->count, e.g. the lock that the kernel provides for protecting sysfs
contexts, we end up grabbing kn->count followed by
&drm->mode_config.mutex. This ends up creating an extremely rude chain:

&kn->count
  -> &drm->mode_config.mutex
    -> crtc_ww_class_mutex/crtc_ww_class_acquire
      -> &connector->mutex

I mean, look at that thing! It's just evil!!! This gross thing ends up
making any calls to drm_connector_register()/drm_connector_unregister()
impossible when holding any kind of modesetting lock. This is annoying
because ideally, we always want to ensure that
drm_dp_mst_port->connector never changes when doing an atomic commit or
check that would affect the atomic topology state so that it can
reliably and easily be used from future DRM DP MST helpers to assist
with tasks such as scanning through the current VCPI allocations and
adding connectors which need to have their allocations updated in
response to a bandwidth change or the like.

Being able to hold &mgr->base.lock throughout the entire link probe
process would have been _great_, since we could prevent userspace from
ever seeing any states in-between individual port changes and as a
result likely end up with a much faster probe and more consistent
results from said probes. But without some rework of how we handle
connector probing in sysfs it's not at all currently possible. In the
future, maybe we can try using the sysfs locks to protect updates to
connector probing state and fix this mess.

So for now, to protect everything other than port->connector under
&mgr->base.lock and ensure that we still have the guarantee that atomic
check/commit contexts will never see port->connector change we use a
silly trick. See: port->connector only needs to change in order to
ensure that input ports (see the MST spec) never have a ghost connector
associated with them. But, there's nothing stopping us from simply
throwing the entire port out and creating a new one in order to maintain
that requirement while still keeping port->connector consistent across
the lifetime of the port in atomic check/commit contexts. For all
intended purposes this works fine, as we validate ports in any contexts
we care about before using them and as such will end up reporting the
connector as disconnected until it's port's destruction finalizes. So,
we just do that in cases where we detect port->input has transitioned
from true->false. We don't need to worry about the other direction,
since a port without a connector isn't visible to userspace and as such
doesn't need to be protected by &mgr->base.lock until we finish
registering a connector for it.

For updating members of drm_dp_mst_port other than port->connector, we
simply grab &mgr->base.lock in drm_dp_mst_link_probe_work() for already
registered ports, update said members and drop the lock before
potentially registering a connector and probing the link address of it's
children.

Finally, we modify drm_dp_mst_detect_port() to take a modesetting lock
acquisition context in order to acquire &mgr->base.lock under
&connection_mutex and convert all it's users over to using the
.detect_ctx probe hooks.

With that, we finally have well defined locking.

Changes since v4:
* Get rid of port->mutex, stop using connection_mutex and just use our own
  modesetting lock - mgr->base.lock. Also, add a probe_lock that comes
  before this patch.
* Just throw out ports that get changed from an output to an input, and
  replace them with new ports. This lets us ensure that modesetting
  contexts never see port->connector go from having a connector to being
  NULL.
* Write an extremely detailed explanation of what problems this is
  trying to fix, since there's a _lot_ of context here and I honestly
  forgot some of it myself a couple times.
* Don't grab mgr->lock when reading port->mstb in
  drm_dp_mst_handle_link_address_port(). It's not needed.

Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSean Paul <sean@poorly.run>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-7-lyude@redhat.com
      3f9b3f02
  15. 19 10月, 2019 1 次提交
  17. 04 10月, 2019 1 次提交
  19. 03 10月, 2019 1 次提交
    • M
      drm/i915/dp: Fix dsc bpp calculations, v5. · cffb4c3e
      由 Maarten Lankhorst 提交于 
      There was a integer wraparound when mode_clock became too high,
and we didn't correct for the FEC overhead factor when dividing,
with the calculations breaking at HBR3.

As a result our calculated bpp was way too high, and the link width
limitation never came into effect.

Print out the resulting bpp calcululations as a sanity check, just
in case we ever have to debug it later on again.

We also used the wrong factor for FEC. While bspec mentions 2.4%,
all the calculations use 1/0.972261, and the same ratio should be
applied to data M/N as well, so use it there when FEC is enabled.

This fixes the FIFO underrun we are seeing with FEC enabled.

Changes since v2:
- Handle fec_enable in intel_link_compute_m_n, so only data M/N is adjusted. (Ville)
- Fix initial hardware readout for FEC. (Ville)
Changes since v3:
- Remove bogus fec_to_mode_clock. (Ville)
Changes since v4:
- Use the correct register for icl. (Ville)
- Split hw readout to a separate patch.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: d9218c8f ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
Cc: <stable@vger.kernel.org> # v5.0+
Cc: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190925082110.17439-1-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit ed06efb8)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      cffb4c3e
  21. 02 10月, 2019 1 次提交
  23. 01 10月, 2019 1 次提交
  25. 25 9月, 2019 1 次提交
    • M
      drm/i915/dp: Fix dsc bpp calculations, v5. · ed06efb8
      由 Maarten Lankhorst 提交于 
      There was a integer wraparound when mode_clock became too high,
and we didn't correct for the FEC overhead factor when dividing,
with the calculations breaking at HBR3.

As a result our calculated bpp was way too high, and the link width
limitation never came into effect.

Print out the resulting bpp calcululations as a sanity check, just
in case we ever have to debug it later on again.

We also used the wrong factor for FEC. While bspec mentions 2.4%,
all the calculations use 1/0.972261, and the same ratio should be
applied to data M/N as well, so use it there when FEC is enabled.

This fixes the FIFO underrun we are seeing with FEC enabled.

Changes since v2:
- Handle fec_enable in intel_link_compute_m_n, so only data M/N is adjusted. (Ville)
- Fix initial hardware readout for FEC. (Ville)
Changes since v3:
- Remove bogus fec_to_mode_clock. (Ville)
Changes since v4:
- Use the correct register for icl. (Ville)
- Split hw readout to a separate patch.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: d9218c8f ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
Cc: <stable@vger.kernel.org> # v5.0+
Cc: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190925082110.17439-1-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      ed06efb8
  27. 09 9月, 2019 1 次提交
  29. 06 9月, 2019 1 次提交
  31. 05 9月, 2019 1 次提交
  33. 04 9月, 2019 1 次提交
  35. 02 9月, 2019 1 次提交
  37. 27 8月, 2019 1 次提交
  39. 22 8月, 2019 1 次提交
    • V
      drm/i915: Do not create a new max_bpc prop for MST connectors · 1b9bd096
      由 Ville Syrjälä 提交于 
      We're not allowed to create new properties after device registration
so for MST connectors we need to either create the max_bpc property
earlier, or we reuse one we already have. Let's do the latter apporach
since the corresponding SST connector already has the prop and its
min/max are correct also for the MST connector.

The problem was highlighted by commit 4f5368b5 ("drm/kms:
Catch mode_object lifetime errors") which results in the following
spew:
[ 1330.878941] WARNING: CPU: 2 PID: 1554 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xa0/0xb0 [drm]
...
[ 1330.879008] Call Trace:
[ 1330.879023]  drm_property_create+0xba/0x180 [drm]
[ 1330.879036]  drm_property_create_range+0x15/0x30 [drm]
[ 1330.879048]  drm_connector_attach_max_bpc_property+0x62/0x80 [drm]
[ 1330.879086]  intel_dp_add_mst_connector+0x11f/0x140 [i915]
[ 1330.879094]  drm_dp_add_port.isra.20+0x20b/0x440 [drm_kms_helper]
...

Cc: stable@vger.kernel.org
Cc: Lyude Paul <lyude@redhat.com>
Cc: sunpeng.li@amd.com
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Fixes: 5ca0ef8a ("drm/i915: Add max_bpc property for DP MST")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820161657.9658-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
      1b9bd096
  41. 21 8月, 2019 1 次提交
  43. 17 8月, 2019 1 次提交
  45. 07 8月, 2019 2 次提交
  47. 17 6月, 2019 1 次提交
  49. 14 6月, 2019 1 次提交
  51. 03 5月, 2019 1 次提交
  53. 30 4月, 2019 2 次提交
  55. 12 4月, 2019 1 次提交
  57. 08 4月, 2019 4 次提交
  59. 27 3月, 2019 2 次提交