1. 28 Nov, 2018 6 commits
    • Y.C. Chen's avatar
      drm/ast: fixed reading monitor EDID not stable issue · 30062562
      Y.C. Chen authored
      v1: over-sample data to increase the stability with some specific monitors
      v2: refine to avoid infinite loop
      v3: remove un-necessary "volatile" declaration
      
      [airlied: fix two checkpatch warnings]
      Signed-off-by: Y.C. Chen's avatarY.C. Chen <yc_chen@aspeedtech.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1542858988-1127-1-git-send-email-yc_chen@aspeedtech.com
      30062562
    • Sam Bobroff's avatar
      drm/ast: Fix incorrect free on ioregs · dc25ab06
      Sam Bobroff authored
      If the platform has no IO space, ioregs is placed next to the already
      allocated regs. In this case, it should not be separately freed.
      
      This prevents a kernel warning from __vunmap "Trying to vfree()
      nonexistent vm area" when unloading the driver.
      
      Fixes: 0dd68309 ("drm/ast: Try to use MMIO registers when PIO isn't supported")
      Signed-off-by: default avatarSam Bobroff <sbobroff@linux.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      dc25ab06
    • Lyude Paul's avatar
      Revert "drm/dp_mst: Skip validating ports during destruction, just ref" · 9765635b
      Lyude Paul authored
      This reverts commit:
      
      c54c7374 ("drm/dp_mst: Skip validating ports during destruction, just ref")
      
      ugh.
      
      In drm_dp_destroy_connector_work(), we have a pretty good chance of
      freeing the actual struct drm_dp_mst_port. However, after destroying
      things we send a hotplug through (*mgr->cbs->hotplug)(mgr) which is
      where the problems start.
      
      For i915, this calls all the way down to the fbcon probing helpers,
      which start trying to access the port in a modeset.
      
      [   45.062001] ==================================================================
      [   45.062112] BUG: KASAN: use-after-free in ex_handler_refcount+0x146/0x180
      [   45.062196] Write of size 4 at addr ffff8882b4b70968 by task kworker/3:1/53
      
      [   45.062325] CPU: 3 PID: 53 Comm: kworker/3:1 Kdump: loaded Tainted: G           O      4.20.0-rc4Lyude-Test+ #3
      [   45.062442] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 ) 09/14/2018
      [   45.062554] Workqueue: events drm_dp_destroy_connector_work [drm_kms_helper]
      [   45.062641] Call Trace:
      [   45.062685]  dump_stack+0xbd/0x15a
      [   45.062735]  ? dump_stack_print_info.cold.0+0x1b/0x1b
      [   45.062801]  ? printk+0x9f/0xc5
      [   45.062847]  ? kmsg_dump_rewind_nolock+0xe4/0xe4
      [   45.062909]  ? ex_handler_refcount+0x146/0x180
      [   45.062970]  print_address_description+0x71/0x239
      [   45.063036]  ? ex_handler_refcount+0x146/0x180
      [   45.063095]  kasan_report.cold.5+0x242/0x30b
      [   45.063155]  __asan_report_store4_noabort+0x1c/0x20
      [   45.063313]  ex_handler_refcount+0x146/0x180
      [   45.063371]  ? ex_handler_clear_fs+0xb0/0xb0
      [   45.063428]  fixup_exception+0x98/0xd7
      [   45.063484]  ? raw_notifier_call_chain+0x20/0x20
      [   45.063548]  do_trap+0x6d/0x210
      [   45.063605]  ? _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
      [   45.063732]  do_error_trap+0xc0/0x170
      [   45.063802]  ? _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
      [   45.063929]  do_invalid_op+0x3b/0x50
      [   45.063997]  ? _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
      [   45.064103]  invalid_op+0x14/0x20
      [   45.064162] RIP: 0010:_GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
      [   45.064274] Code: 00 48 c7 c7 80 fe 53 a0 48 89 e5 e8 5b 6f 26 e1 5d c3 48 8d 0e 0f 0b 48 8d 0b 0f 0b 48 8d 0f 0f 0b 48 8d 0f 0f 0b 49 8d 4d 00 <0f> 0b 49 8d 0e 0f 0b 48 8d 08 0f 0b 49 8d 4d 00 0f 0b 48 8d 0b 0f
      [   45.064569] RSP: 0018:ffff8882b789ee10 EFLAGS: 00010282
      [   45.064637] RAX: ffff8882af47ae70 RBX: ffff8882af47aa60 RCX: ffff8882b4b70968
      [   45.064723] RDX: ffff8882af47ae70 RSI: 0000000000000008 RDI: ffff8882b788bdb8
      [   45.064808] RBP: ffff8882b789ee28 R08: ffffed1056f13db4 R09: ffffed1056f13db3
      [   45.064894] R10: ffffed1056f13db3 R11: ffff8882b789ed9f R12: ffff8882af47ad28
      [   45.064980] R13: ffff8882b4b70968 R14: ffff8882acd86728 R15: ffff8882b4b75dc8
      [   45.065084]  drm_dp_mst_reset_vcpi_slots+0x12/0x80 [drm_kms_helper]
      [   45.065225]  intel_mst_disable_dp+0xda/0x180 [i915]
      [   45.065361]  intel_encoders_disable.isra.107+0x197/0x310 [i915]
      [   45.065498]  haswell_crtc_disable+0xbe/0x400 [i915]
      [   45.065622]  ? i9xx_disable_plane+0x1c0/0x3e0 [i915]
      [   45.065750]  intel_atomic_commit_tail+0x74e/0x3e60 [i915]
      [   45.065884]  ? intel_pre_plane_update+0xbc0/0xbc0 [i915]
      [   45.065968]  ? drm_atomic_helper_swap_state+0x88b/0x1d90 [drm_kms_helper]
      [   45.066054]  ? kasan_check_write+0x14/0x20
      [   45.066165]  ? i915_gem_track_fb+0x13a/0x330 [i915]
      [   45.066277]  ? i915_sw_fence_complete+0xe9/0x140 [i915]
      [   45.066406]  ? __i915_sw_fence_complete+0xc50/0xc50 [i915]
      [   45.066540]  intel_atomic_commit+0x72e/0xef0 [i915]
      [   45.066635]  ? drm_dev_dbg+0x200/0x200 [drm]
      [   45.066764]  ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
      [   45.066898]  ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
      [   45.067001]  drm_atomic_commit+0xc4/0xf0 [drm]
      [   45.067074]  restore_fbdev_mode_atomic+0x562/0x780 [drm_kms_helper]
      [   45.067166]  ? drm_fb_helper_debug_leave+0x690/0x690 [drm_kms_helper]
      [   45.067249]  ? kasan_check_read+0x11/0x20
      [   45.067324]  restore_fbdev_mode+0x127/0x4b0 [drm_kms_helper]
      [   45.067364]  ? kasan_check_read+0x11/0x20
      [   45.067406]  drm_fb_helper_restore_fbdev_mode_unlocked+0x164/0x200 [drm_kms_helper]
      [   45.067462]  ? drm_fb_helper_hotplug_event+0x30/0x30 [drm_kms_helper]
      [   45.067508]  ? kasan_check_write+0x14/0x20
      [   45.070360]  ? mutex_unlock+0x22/0x40
      [   45.073748]  drm_fb_helper_set_par+0xb2/0xf0 [drm_kms_helper]
      [   45.075846]  drm_fb_helper_hotplug_event.part.33+0x1cd/0x290 [drm_kms_helper]
      [   45.078088]  drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper]
      [   45.082614]  intel_fbdev_output_poll_changed+0x9f/0x140 [i915]
      [   45.087069]  drm_kms_helper_hotplug_event+0x67/0x90 [drm_kms_helper]
      [   45.089319]  intel_dp_mst_hotplug+0x37/0x50 [i915]
      [   45.091496]  drm_dp_destroy_connector_work+0x510/0x6f0 [drm_kms_helper]
      [   45.093675]  ? drm_dp_update_payload_part1+0x1220/0x1220 [drm_kms_helper]
      [   45.095851]  ? kasan_check_write+0x14/0x20
      [   45.098473]  ? kasan_check_read+0x11/0x20
      [   45.101155]  ? strscpy+0x17c/0x530
      [   45.103808]  ? __switch_to_asm+0x34/0x70
      [   45.106456]  ? syscall_return_via_sysret+0xf/0x7f
      [   45.109711]  ? read_word_at_a_time+0x20/0x20
      [   45.113138]  ? __switch_to_asm+0x40/0x70
      [   45.116529]  ? __switch_to_asm+0x34/0x70
      [   45.119891]  ? __switch_to_asm+0x40/0x70
      [   45.123224]  ? __switch_to_asm+0x34/0x70
      [   45.126540]  ? __switch_to_asm+0x34/0x70
      [   45.129824]  process_one_work+0x88d/0x15d0
      [   45.133172]  ? pool_mayday_timeout+0x850/0x850
      [   45.136459]  ? pci_mmcfg_check_reserved+0x110/0x128
      [   45.139739]  ? wake_q_add+0xb0/0xb0
      [   45.143010]  ? check_preempt_wakeup+0x652/0x1050
      [   45.146304]  ? worker_enter_idle+0x29e/0x740
      [   45.149589]  ? __schedule+0x1ec0/0x1ec0
      [   45.152937]  ? kasan_check_read+0x11/0x20
      [   45.156179]  ? _raw_spin_lock_irq+0xa3/0x130
      [   45.159382]  ? _raw_read_unlock_irqrestore+0x30/0x30
      [   45.162542]  ? kasan_check_write+0x14/0x20
      [   45.165657]  worker_thread+0x1a5/0x1470
      [   45.168725]  ? set_load_weight+0x2e0/0x2e0
      [   45.171755]  ? process_one_work+0x15d0/0x15d0
      [   45.174806]  ? __switch_to_asm+0x34/0x70
      [   45.177645]  ? __switch_to_asm+0x40/0x70
      [   45.180323]  ? __switch_to_asm+0x34/0x70
      [   45.182936]  ? __switch_to_asm+0x40/0x70
      [   45.185539]  ? __switch_to_asm+0x34/0x70
      [   45.188100]  ? __switch_to_asm+0x40/0x70
      [   45.190628]  ? __schedule+0x7d4/0x1ec0
      [   45.193143]  ? save_stack+0xa9/0xd0
      [   45.195632]  ? kasan_check_write+0x10/0x20
      [   45.198162]  ? kasan_kmalloc+0xc4/0xe0
      [   45.200609]  ? kmem_cache_alloc_trace+0xdd/0x190
      [   45.203046]  ? kthread+0x9f/0x3b0
      [   45.205470]  ? ret_from_fork+0x35/0x40
      [   45.207876]  ? unwind_next_frame+0x43/0x50
      [   45.210273]  ? __save_stack_trace+0x82/0x100
      [   45.212658]  ? deactivate_slab.isra.67+0x3d4/0x580
      [   45.215026]  ? default_wake_function+0x35/0x50
      [   45.217399]  ? kasan_check_read+0x11/0x20
      [   45.219825]  ? _raw_spin_lock_irqsave+0xae/0x140
      [   45.222174]  ? __lock_text_start+0x8/0x8
      [   45.224521]  ? replenish_dl_entity.cold.62+0x4f/0x4f
      [   45.226868]  ? __kthread_parkme+0x87/0xf0
      [   45.229200]  kthread+0x2f7/0x3b0
      [   45.231557]  ? process_one_work+0x15d0/0x15d0
      [   45.233923]  ? kthread_park+0x120/0x120
      [   45.236249]  ret_from_fork+0x35/0x40
      
      [   45.240875] Allocated by task 242:
      [   45.243136]  save_stack+0x43/0xd0
      [   45.245385]  kasan_kmalloc+0xc4/0xe0
      [   45.247597]  kmem_cache_alloc_trace+0xdd/0x190
      [   45.249793]  drm_dp_add_port+0x1e0/0x2170 [drm_kms_helper]
      [   45.252000]  drm_dp_send_link_address+0x4a7/0x740 [drm_kms_helper]
      [   45.254389]  drm_dp_check_and_send_link_address+0x1a7/0x210 [drm_kms_helper]
      [   45.256803]  drm_dp_mst_link_probe_work+0x6f/0xb0 [drm_kms_helper]
      [   45.259200]  process_one_work+0x88d/0x15d0
      [   45.261597]  worker_thread+0x1a5/0x1470
      [   45.264038]  kthread+0x2f7/0x3b0
      [   45.266371]  ret_from_fork+0x35/0x40
      
      [   45.270937] Freed by task 53:
      [   45.273170]  save_stack+0x43/0xd0
      [   45.275382]  __kasan_slab_free+0x139/0x190
      [   45.277604]  kasan_slab_free+0xe/0x10
      [   45.279826]  kfree+0x99/0x1b0
      [   45.282044]  drm_dp_free_mst_port+0x4a/0x60 [drm_kms_helper]
      [   45.284330]  drm_dp_destroy_connector_work+0x43e/0x6f0 [drm_kms_helper]
      [   45.286660]  process_one_work+0x88d/0x15d0
      [   45.288934]  worker_thread+0x1a5/0x1470
      [   45.291231]  kthread+0x2f7/0x3b0
      [   45.293547]  ret_from_fork+0x35/0x40
      
      [   45.298206] The buggy address belongs to the object at ffff8882b4b70968
                      which belongs to the cache kmalloc-2k of size 2048
      [   45.303047] The buggy address is located 0 bytes inside of
                      2048-byte region [ffff8882b4b70968, ffff8882b4b71168)
      [   45.308010] The buggy address belongs to the page:
      [   45.310477] page:ffffea000ad2dc00 count:1 mapcount:0 mapping:ffff8882c080cf40 index:0x0 compound_mapcount: 0
      [   45.313051] flags: 0x8000000000010200(slab|head)
      [   45.315635] raw: 8000000000010200 ffffea000aac2808 ffffea000abe8608 ffff8882c080cf40
      [   45.318300] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
      [   45.320966] page dumped because: kasan: bad access detected
      
      [   45.326312] Memory state around the buggy address:
      [   45.329085]  ffff8882b4b70800: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   45.331845]  ffff8882b4b70880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   45.334584] >ffff8882b4b70900: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb
      [   45.337302]                                                           ^
      [   45.340061]  ffff8882b4b70980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   45.342910]  ffff8882b4b70a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   45.345748] ==================================================================
      
      So, this definitely isn't a fix that we want. This being said; there's
      no real easy fix for this problem because of some of the catch-22's of
      the MST helpers current design. For starters; we always need to validate
      a port with drm_dp_get_validated_port_ref(), but validation relies on
      the lifetime of the port in the actual topology. So once the port is
      gone, it can't be validated again.
      
      If we were to try to make the payload helpers not use port validation,
      then we'd cause another problem: if the port isn't validated, it could
      be freed and we'd just start causing more KASAN issues. There are
      already hacks that attempt to workaround this in
      drm_dp_mst_destroy_connector_work() by re-initializing the kref so that
      it can be used again and it's memory can be freed once the VCPI helpers
      finish removing the port's respective payloads. But none of these really
      do anything helpful since the port still can't be validated since it's
      gone from the topology. Also, that workaround is immensely confusing to
      read through.
      
      What really needs to be done in order to fix this is to teach DRM how to
      track the lifetime of the structs for MST ports and branch devices
      separately from their lifetime in the actual topology. Simply put; this
      means having two different krefs-one that removes the port/branch device
      from the topology, and one that finally calls kfree(). This would let us
      simplify things, since we'd now be able to keep ports around without
      having to keep them in the topology at the same time, which is exactly
      what we need in order to teach our VCPI helpers to only validate ports
      when it's actually necessary without running the risk of trying to use
      unallocated memory.
      
      Such a fix is on it's way, but for now let's play it safe and just
      revert this. If this bug has been around for well over a year, we can
      wait a little while to get an actual proper fix here.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Fixes: c54c7374 ("drm/dp_mst: Skip validating ports during destruction, just ref")
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Sean Paul <sean@poorly.run>
      Cc: Jerry Zuo <Jerry.Zuo@amd.com>
      Cc: Harry Wentland <Harry.Wentland@amd.com>
      Cc: stable@vger.kernel.org # v4.6+
      Acked-by: Sean Paul's avatarSean Paul <sean@poorly.run>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181128210005.24434-1-lyude@redhat.com
      9765635b
    • shaoyunl's avatar
      drm/amdgpu: Add delay after enable RLC ucode · ad97d9de
      shaoyunl authored
      Driver shouldn't try to access any GFX registers until RLC is idle.
      During the test, it took 12 seconds for RLC to clear the BUSY bit
      in RLC_GPM_STAT register which is un-acceptable for driver.
      As per RLC engineer, it would take RLC Ucode less than 10,000 GFXCLK
      cycles to finish its critical section. In a lowest 300M enginer clock
      setting(default from vbios), 50 us delay is enough.
      
      This commit fix the hang when RLC introduce the work around for XGMI
      which requires more cycles to setup more registers than normal
      Signed-off-by: default avatarshaoyunl <shaoyun.liu@amd.com>
      Acked-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      ad97d9de
    • Felix Kuehling's avatar
      drm/amdgpu: Avoid endless loop in GPUVM fragment processing · 1954db15
      Felix Kuehling authored
      Don't bounce back to the root level for fragment processing, because
      huge pages are not supported at that level. This is unlikely to happen
      with the default VM size on Vega, but can be exposed by limiting the
      VM size with the amdgpu.vm_size module parameter.
      Signed-off-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: Christian König's avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      1954db15
    • Felix Kuehling's avatar
      drm/amdgpu: Cast to uint64_t before left shift · 9ce2b991
      Felix Kuehling authored
      Avoid potential integer overflows with left shift in huge-page mapping
      code by casting the operand to uin64_t first.
      Signed-off-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: Christian König's avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      9ce2b991
  2. 26 Nov, 2018 7 commits
    • Christian Hewitt's avatar
      drm/meson: add support for 1080p25 mode · 31e1ab49
      Christian Hewitt authored
      This essential mode for PAL users is missing, so add it.
      
      Fixes: 335e3713 ("drm/meson: Add support for HDMI venc modes and settings")
      Signed-off-by: Christian Hewitt's avatarChristian Hewitt <christianshewitt@gmail.com>
      Acked-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1542793169-13008-1-git-send-email-christianshewitt@gmail.comSigned-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      31e1ab49
    • Lyude Paul's avatar
      drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut() · 97b2a318
      Lyude Paul authored
      Currently on driver bringup with KASAN enabled, meson triggers an OOB
      memory access as shown below:
      
      [  117.904528] ==================================================================
      [  117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
      [  117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
      [  117.904601]
      [  118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
      [  118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [  118.099768] Call trace:
      [  118.102181]  dump_backtrace+0x0/0x3e8
      [  118.105796]  show_stack+0x14/0x20
      [  118.109083]  dump_stack+0x130/0x1c4
      [  118.112539]  print_address_description+0x60/0x25c
      [  118.117214]  kasan_report+0x1b4/0x368
      [  118.120851]  __asan_report_load4_noabort+0x18/0x20
      [  118.125566]  meson_viu_set_osd_lut+0x7a0/0x890
      [  118.129953]  meson_viu_init+0x10c/0x290
      [  118.133741]  meson_drv_bind_master+0x474/0x748
      [  118.138141]  meson_drv_bind+0x10/0x18
      [  118.141760]  try_to_bring_up_master+0x3d8/0x768
      [  118.146249]  component_add+0x214/0x570
      [  118.149978]  meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
      [  118.155404]  platform_drv_probe+0x98/0x138
      [  118.159455]  really_probe+0x2a0/0xa70
      [  118.163070]  driver_probe_device+0x1b4/0x2d8
      [  118.167299]  __driver_attach+0x200/0x280
      [  118.171189]  bus_for_each_dev+0x10c/0x1a8
      [  118.175144]  driver_attach+0x38/0x50
      [  118.178681]  bus_add_driver+0x330/0x608
      [  118.182471]  driver_register+0x140/0x388
      [  118.186361]  __platform_driver_register+0xc8/0x108
      [  118.191117]  meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
      [  118.198022]  do_one_initcall+0x12c/0x3bc
      [  118.201883]  do_init_module+0x1fc/0x638
      [  118.205673]  load_module+0x4b4c/0x6808
      [  118.209387]  __se_sys_init_module+0x2e8/0x3c0
      [  118.213699]  __arm64_sys_init_module+0x68/0x98
      [  118.218100]  el0_svc_common+0x104/0x210
      [  118.221893]  el0_svc_handler+0x48/0xb8
      [  118.225594]  el0_svc+0x8/0xc
      [  118.228429]
      [  118.229887] The buggy address belongs to the variable:
      [  118.235007]  eotf_33_linear_mapping+0x84/0xc0
      [  118.239301]
      [  118.240752] Memory state around the buggy address:
      [  118.245522]  ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.252695]  ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
      [  118.267000]                                ^
      [  118.271222]  ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      [  118.278393]  ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
      [  118.285542] ==================================================================
      [  118.292699] Disabling lock debugging due to kernel taint
      
      It seems that when looping through the OSD EOTF LUT maps, we use the
      same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
      which means that we'll stop out of bounds on the EOTF maps.
      
      But, this whole thing is already confusing enough to read through as-is,
      so let's just replace all of the hardcoded sizes with
      OSD_(OETF/EOTF)_LUT_SIZE / 2.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: <stable@vger.kernel.org> # v4.10+
      Acked-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.comSigned-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      97b2a318
    • Lyude Paul's avatar
      drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config · 995b278e
      Lyude Paul authored
      Seeing as we use this registermap in the context of our IRQ handlers, we
      need to be using spinlocks for reading/writing registers so that we can
      still read them from IRQ handlers without having to grab any mutexes and
      accidentally sleep. We don't currently do this, as pointed out by
      lockdep:
      
      [   18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
      [   18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
      [   18.413864] INFO: lockdep is turned off.
      [   18.417675] irq event stamp: 12
      [   18.420778] hardirqs last  enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
      [   18.429510] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
      [   18.437345] softirqs last  enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
      [   18.446684] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [   18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
      [   18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [   18.480037] Workqueue: hci0 hci_power_on [bluetooth]
      [   18.487138] Call trace:
      [   18.494192]  dump_backtrace+0x0/0x1b8
      [   18.501280]  show_stack+0x14/0x20
      [   18.508361]  dump_stack+0xbc/0xf4
      [   18.515427]  ___might_sleep+0x140/0x1d8
      [   18.522515]  __might_sleep+0x50/0x88
      [   18.529582]  __mutex_lock+0x60/0x870
      [   18.536621]  mutex_lock_nested+0x1c/0x28
      [   18.543660]  regmap_lock_mutex+0x10/0x18
      [   18.550696]  regmap_read+0x38/0x70
      [   18.557727]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
      [   18.564804]  __handle_irq_event_percpu+0xac/0x410
      [   18.571891]  handle_irq_event_percpu+0x34/0x88
      [   18.578982]  handle_irq_event+0x48/0x78
      [   18.586051]  handle_fasteoi_irq+0xac/0x160
      [   18.593061]  generic_handle_irq+0x24/0x38
      [   18.599989]  __handle_domain_irq+0x60/0xb8
      [   18.606857]  gic_handle_irq+0x50/0xa0
      [   18.613659]  el1_irq+0xb4/0x130
      [   18.620394]  debug_lockdep_rcu_enabled+0x2c/0x30
      [   18.627111]  schedule+0x38/0xa0
      [   18.633781]  schedule_timeout+0x3a8/0x510
      [   18.640389]  wait_for_common+0x15c/0x180
      [   18.646905]  wait_for_completion+0x14/0x20
      [   18.653319]  mmc_wait_for_req_done+0x28/0x168
      [   18.659693]  mmc_wait_for_req+0xa8/0xe8
      [   18.665978]  mmc_wait_for_cmd+0x64/0x98
      [   18.672180]  mmc_io_rw_direct_host+0x94/0x130
      [   18.678385]  mmc_io_rw_direct+0x10/0x18
      [   18.684516]  sdio_enable_func+0xe8/0x1d0
      [   18.690627]  btsdio_open+0x24/0xc0 [btsdio]
      [   18.696821]  hci_dev_do_open+0x64/0x598 [bluetooth]
      [   18.703025]  hci_power_on+0x50/0x270 [bluetooth]
      [   18.709163]  process_one_work+0x2a0/0x6e0
      [   18.715252]  worker_thread+0x40/0x448
      [   18.721310]  kthread+0x12c/0x130
      [   18.727326]  ret_from_fork+0x10/0x1c
      [   18.735555] ------------[ cut here ]------------
      [   18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<000000006265ec59>] wait_for_common+0x140/0x180
      [   18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
      [   18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
      btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
      brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
      dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
      leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
      meson_gxbb_wdt pwm_meson efivarfs ipv6
      [   18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
      [   18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [   18.818045] Workqueue: hci0 hci_power_on [bluetooth]
      [   18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
      [   18.829891] pc : __might_sleep+0x7c/0x88
      [   18.835722] lr : __might_sleep+0x7c/0x88
      [   18.841256] sp : ffff000008003cb0
      [   18.846751] x29: ffff000008003cb0 x28: 0000000000000000
      [   18.852269] x27: ffff00000938e000 x26: ffff800010283000
      [   18.857726] x25: ffff800010353280 x24: ffff00000868ef50
      [   18.863166] x23: 0000000000000000 x22: 0000000000000000
      [   18.868551] x21: 0000000000000000 x20: 000000000000038c
      [   18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
      [   18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
      [   18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
      [   18.889239] x13: 0000000000000001 x12: 00000000ffffffff
      [   18.894261] x11: ffff000008adfa48 x10: 0000000000000001
      [   18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
      [   18.904674] x7 : ffff00000812136c x6 : 0000000000000000
      [   18.909895] x5 : 0000000000000000 x4 : 0000000000000001
      [   18.915080] x3 : 0000000000000007 x2 : 0000000000000007
      [   18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
      [   18.925443] Call trace:
      [   18.929904]  __might_sleep+0x7c/0x88
      [   18.934311]  __mutex_lock+0x60/0x870
      [   18.938687]  mutex_lock_nested+0x1c/0x28
      [   18.943076]  regmap_lock_mutex+0x10/0x18
      [   18.947453]  regmap_read+0x38/0x70
      [   18.951842]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
      [   18.956269]  __handle_irq_event_percpu+0xac/0x410
      [   18.960712]  handle_irq_event_percpu+0x34/0x88
      [   18.965176]  handle_irq_event+0x48/0x78
      [   18.969612]  handle_fasteoi_irq+0xac/0x160
      [   18.974058]  generic_handle_irq+0x24/0x38
      [   18.978501]  __handle_domain_irq+0x60/0xb8
      [   18.982938]  gic_handle_irq+0x50/0xa0
      [   18.987351]  el1_irq+0xb4/0x130
      [   18.991734]  debug_lockdep_rcu_enabled+0x2c/0x30
      [   18.996180]  schedule+0x38/0xa0
      [   19.000609]  schedule_timeout+0x3a8/0x510
      [   19.005064]  wait_for_common+0x15c/0x180
      [   19.009513]  wait_for_completion+0x14/0x20
      [   19.013951]  mmc_wait_for_req_done+0x28/0x168
      [   19.018402]  mmc_wait_for_req+0xa8/0xe8
      [   19.022809]  mmc_wait_for_cmd+0x64/0x98
      [   19.027177]  mmc_io_rw_direct_host+0x94/0x130
      [   19.031563]  mmc_io_rw_direct+0x10/0x18
      [   19.035922]  sdio_enable_func+0xe8/0x1d0
      [   19.040294]  btsdio_open+0x24/0xc0 [btsdio]
      [   19.044742]  hci_dev_do_open+0x64/0x598 [bluetooth]
      [   19.049228]  hci_power_on+0x50/0x270 [bluetooth]
      [   19.053687]  process_one_work+0x2a0/0x6e0
      [   19.058143]  worker_thread+0x40/0x448
      [   19.062608]  kthread+0x12c/0x130
      [   19.067064]  ret_from_fork+0x10/0x1c
      [   19.071513] irq event stamp: 12
      [   19.075937] hardirqs last  enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
      [   19.083560] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
      [   19.091401] softirqs last  enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
      [   19.100801] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [   19.108135] ---[ end trace 38c4920787b88c75 ]---
      
      So, fix this by enabling the fast_io option in our regmap config so that
      regmap uses spinlocks for locking instead of mutexes.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Fixes: 3f68be7d ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: <stable@vger.kernel.org> # v4.12+
      Acked-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.comSigned-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      995b278e
    • Neil Armstrong's avatar
      drm/meson: Fixes for drm_crtc_vblank_on/off support · 2bcd3eca
      Neil Armstrong authored
      Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get
      a warning when ctrc is disabled :
      " driver forgot to call drm_crtc_vblank_off()"
      
      But, the vsync IRQ was not totally disabled due the transient hardware
      state and specific interrupt line, thus adding proper IRQ masking from
      the HHI system control registers.
      
      The last change fixes a race condition introduced by calling the added
      drm_crtc_vblank_on/off when an HPD event occurs from the HDMI connector,
      triggering a WARN_ON() in the _atomic_begin() callback when the CRTC
      is disabled, thus also triggering a WARN_ON() in drm_vblank_put() :
      
      WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/meson/meson_crtc.c:157 meson_crtc_atomic_begin+0x78/0x80
      [...]
      Call trace:
        meson_crtc_atomic_begin+0x78/0x80
        drm_atomic_helper_commit_planes+0x140/0x218
        drm_atomic_helper_commit_tail+0x38/0x80
        commit_tail+0x7c/0x80
        drm_atomic_helper_commit+0xdc/0x150
        drm_atomic_commit+0x54/0x60
        restore_fbdev_mode_atomic+0x198/0x238
        restore_fbdev_mode+0x6c/0x1c0
        drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xf0
        drm_fb_helper_set_par+0x34/0x60
        drm_fb_helper_hotplug_event.part.28+0xb8/0xc8
        drm_fbdev_client_hotplug+0xa4/0xe0
        drm_client_dev_hotplug+0x90/0xe0
        drm_kms_helper_hotplug_event+0x3c/0x48
        drm_helper_hpd_irq_event+0x134/0x168
        dw_hdmi_top_thread_irq+0x3c/0x50
      [...]
      WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/drm_vblank.c:1026 drm_vblank_put+0xb4/0xc8
      [...]
       Call trace:
        drm_vblank_put+0xb4/0xc8
        drm_crtc_vblank_put+0x24/0x30
        drm_atomic_helper_wait_for_vblanks.part.9+0x130/0x2b8
        drm_atomic_helper_commit_tail+0x68/0x80
      [...]
      
      The issue is that vblank need to be enabled in any occurrence of :
      - atomic_enable()
      - atomic_begin() and state->enable == true, which was not the case
      
      Moving the CRTC enable code to a common function and calling in one of
      these occurrence solves this race condition and makes sure vblank is
      enabled in each call to _atomic_begin() from the HPD event leading to
      drm_atomic_helper_commit_planes().
      
      To Summarize :
      - Make sure that the CRTC code will call the drm_crtc_vblank_on()/off()
      - *Really* mask the Vsync IRQ
      - Initialize and enable vblank at the first
        atomic_begin()/_atomic_enable()
      
      Cc: stable@vger.kernel.org # 4.17+
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      [fixed typos+added cc for stable]
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181122160103.10993-1-narmstrong@baylibre.comSigned-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      2bcd3eca
    • Sergio Correia's avatar
      drm: set is_master to 0 upon drm_new_set_master() failure · 23a336b3
      Sergio Correia authored
      When drm_new_set_master() fails, set is_master to 0, to prevent a
      possible NULL pointer deref.
      
      Here is a problematic flow: we check is_master in drm_is_current_master(),
      then proceed to call drm_lease_owner() passing master. If we do not restore
      is_master status when drm_new_set_master() fails, we may have a situation
      in which is_master will be 1 and master itself, NULL, leading to the deref
      of a NULL pointer in drm_lease_owner().
      
      This fixes the following OOPS, observed on an ArchLinux running a 4.19.2
      kernel:
      
      [   97.804282] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      [   97.807224] PGD 0 P4D 0
      [   97.807224] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [   97.807224] CPU: 0 PID: 1348 Comm: xfwm4 Tainted: P           OE     4.19.2-arch1-1-ARCH #1
      [   97.807224] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./AB350 Pro4, BIOS P5.10 10/16/2018
      [   97.807224] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
      [   97.807224] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
      [   97.807224] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
      [   97.807224] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
      [   97.807224] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
      [   97.807224] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
      [   97.807224] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
      [   97.807224] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
      [   97.807224] FS:  00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
      [   97.807224] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   97.807224] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
      [   97.807224] Call Trace:
      [   97.807224]  drm_is_current_master+0x1a/0x30 [drm]
      [   97.807224]  drm_master_release+0x3e/0x130 [drm]
      [   97.807224]  drm_file_free.part.0+0x2be/0x2d0 [drm]
      [   97.807224]  drm_open+0x1ba/0x1e0 [drm]
      [   97.807224]  drm_stub_open+0xaf/0xe0 [drm]
      [   97.807224]  chrdev_open+0xa3/0x1b0
      [   97.807224]  ? cdev_put.part.0+0x20/0x20
      [   97.807224]  do_dentry_open+0x132/0x340
      [   97.807224]  path_openat+0x2d1/0x14e0
      [   97.807224]  ? mem_cgroup_commit_charge+0x7a/0x520
      [   97.807224]  do_filp_open+0x93/0x100
      [   97.807224]  ? __check_object_size+0x102/0x189
      [   97.807224]  ? _raw_spin_unlock+0x16/0x30
      [   97.807224]  do_sys_open+0x186/0x210
      [   97.807224]  do_syscall_64+0x5b/0x170
      [   97.807224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   97.807224] RIP: 0033:0x7f4147b07976
      [   97.807224] Code: 89 54 24 08 e8 7b f4 ff ff 8b 74 24 0c 48 8b 3c 24 41 89 c0 44 8b 54 24 08 b8 01 01 00 00 89 f2 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 77 30 44 89 c7 89 44 24 08 e8 a6 f4 ff ff 8b 44
      [   97.807224] RSP: 002b:00007ffcced96ca0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
      [   97.807224] RAX: ffffffffffffffda RBX: 00005619d5037f80 RCX: 00007f4147b07976
      [   97.807224] RDX: 0000000000000002 RSI: 00005619d46b969c RDI: 00000000ffffff9c
      [   98.040039] RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000000
      [   98.040039] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000024
      [   98.040039] R13: 0000000000000012 R14: 00005619d5035950 R15: 0000000000000012
      [   98.040039] Modules linked in: nct6775 hwmon_vid algif_skcipher af_alg nls_iso8859_1 nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common arc4 videodev media snd_usb_audio snd_hda_codec_hdmi snd_usbmidi_lib snd_rawmidi snd_seq_device mousedev input_leds iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec edac_mce_amd kvm_amd snd_hda_core kvm iwlwifi snd_hwdep r8169 wmi_bmof cfg80211 snd_pcm irqbypass snd_timer snd libphy soundcore pinctrl_amd rfkill pcspkr sp5100_tco evdev gpio_amdpt k10temp mac_hid i2c_piix4 wmi pcc_cpufreq acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) msr sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto uas usb_storage dm_crypt hid_generic usbhid hid
      [   98.040039]  dm_mod raid1 md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel aes_x86_64 libata crypto_simd cryptd glue_helper ccp xhci_pci rng_core scsi_mod xhci_hcd nvidia_drm(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart nvidia_uvm(POE) nvidia_modeset(POE) nvidia(POE) ipmi_devintf ipmi_msghandler
      [   98.040039] CR2: 0000000000000080
      [   98.040039] ---[ end trace 3b65093b6fe62b2f ]---
      [   98.040039] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
      [   98.040039] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
      [   98.040039] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
      [   98.040039] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
      [   98.040039] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
      [   98.040039] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
      [   98.040039] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
      [   98.040039] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
      [   98.040039] FS:  00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
      [   98.040039] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   98.040039] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
      Signed-off-by: Sergio Correia's avatarSergio Correia <sergio@correia.cc>
      Cc: stable@vger.kernel.org
      Signed-off-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181122053329.2692-1-sergio@correia.ccSigned-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      23a336b3
    • Lyude Paul's avatar
      drm/dp_mst: Skip validating ports during destruction, just ref · c54c7374
      Lyude Paul authored
      Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
      accidentally introduced into DRM two years ago.
      
      Pretend we have a topology like this:
      
      |- DP-1: mst_primary
         |- DP-4: active display
         |- DP-5: disconnected
         |- DP-6: active hub
            |- DP-7: active display
            |- DP-8: disconnected
            |- DP-9: disconnected
      
      If we unplug DP-6, the topology starting at DP-7 will be destroyed but
      it's payloads will live on in DP-1's VCPI allocations and thus require
      removal. However, this removal currently fails because
      drm_dp_update_payload_part1() will (rightly so) try to validate the port
      before accessing it, fail then abort. If we keep going, eventually we
      run the MST hub out of bandwidth and all new allocations will start to
      fail (or in my case; all new displays just start flickering a ton).
      
      We could just teach drm_dp_update_payload_part1() not to drop the port
      ref in this case, but then we also need to teach
      drm_dp_destroy_payload_step1() to do the same thing, then hope no one
      ever adds anything to the that requires a validated port reference in
      drm_dp_destroy_connector_work(). Kind of sketchy.
      
      So let's go with a more clever solution: any port that
      drm_dp_destroy_connector_work() interacts with is guaranteed to still
      exist in memory until we say so. While said port might not be valid we
      don't really care: that's the whole reason we're destroying it in the
      first place! So, teach drm_dp_get_validated_port_ref() to use the all
      mighty current_work() function to avoid attempting to validate ports
      from the context of mgr->destroy_connector_work. I can't see any
      situation where this wouldn't be safe, and this avoids having to play
      whack-a-mole in the future of trying to work around port validation.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Fixes: 263efde3 ("drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()")
      Reported-by: default avatarJerry Zuo <Jerry.Zuo@amd.com>
      Cc: Jerry Zuo <Jerry.Zuo@amd.com>
      Cc: Harry Wentland <Harry.Wentland@amd.com>
      Cc: <stable@vger.kernel.org> # v4.6+
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-lyude@redhat.comSigned-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      c54c7374
    • Laurent Pinchart's avatar
      drm: rcar-du: Fix DU3 start/stop on M3-N · 0bc3544a
      Laurent Pinchart authored
      Group start/stop is controlled by the DRES and DEN bits of DSYSR0 for
      the first group and DSYSR2 for the second group. On most DU instances,
      this maps to the first CRTC of the group. On M3-N, however, DU2 doesn't
      exist, but DSYSR2 does. There is no CRTC object there that maps to the
      correct DSYSR register.
      
      Commit 9144adc5 ("drm: rcar-du: Cache DSYSR value to ensure known
      initial value") switched group start/stop from using group read/write
      access to DSYSR to a CRTC-based API to cache the DSYSR value. While
      doing so, it introduced a regression on M3-N by accessing DSYSR3 instead
      of DSYSR2 to start/stop the second group.
      
      To fix this, access the DSYSR register directly through group read/write
      if the SoC is missing the first DU channel of the group. Keep using the
      rcar_du_crtc_dsysr_clr_set() function otherwise, to retain the DSYSR
      caching feature.
      
      Fixes: 9144adc5 ("drm: rcar-du: Cache DSYSR value to ensure known initial value")
      Reported-by: default avatarHoan Nguyen An <na-hoan@jinso.co.jp>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Acked-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Tested-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      0bc3544a
  3. 22 Nov, 2018 2 commits
  4. 21 Nov, 2018 7 commits
  5. 20 Nov, 2018 2 commits
  6. 19 Nov, 2018 5 commits
  7. 18 Nov, 2018 1 commit
  8. 15 Nov, 2018 7 commits
  9. 14 Nov, 2018 2 commits
  10. 13 Nov, 2018 1 commit