1. 10 Feb, 2020 1 commit
  2. 09 Feb, 2020 3 commits
  3. 08 Feb, 2020 4 commits
  4. 07 Feb, 2020 15 commits
  5. 06 Feb, 2020 5 commits
  6. 05 Feb, 2020 12 commits
    • Chris Wilson's avatar
      drm/i915: Flush execution tasklets before checking request status · 602ddb41
      Chris Wilson authored
      Rather than flushing the submission tasklets just before we sleep, flush
      before we check the request status. Ideally this gives us a moment to
      process the tasklets after sleeping just before we timeout.
      
      v2: Compromise by pushing the flush prior to the timeout, but after the
      check on completion so that we do not further delay the ready client.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200205095441.1769599-1-chris@chris-wilson.co.uk
      602ddb41
    • Chris Wilson's avatar
      drm/i915: Mark i915.reset as unsigned · aae970d8
      Chris Wilson authored
      We have been using '-1' to mean the maximum i915.reset level in the
      belief that it was unsigned... This turns out to have been a grave
      error, and instead of setting the default reset mechanism in igt,
      we have been disabling reset!
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200205123757.1834947-1-chris@chris-wilson.co.uk
      aae970d8
    • Stanislav Lisovskiy's avatar
      drm/i915: Correctly map DBUF slices to pipes · ff2cd863
      Stanislav Lisovskiy authored
      Added proper DBuf slice mapping to correspondent
      pipes, depending on pipe configuration as stated
      in BSpec.
      
      v2:
          - Remove unneeded braces
          - Stop using macro for DBuf assignments as
            it seems to reduce readability.
      
      v3: Start using enabled slices mask in dev_priv
      
      v4: Renamed "enabled_slices" used in dev_priv
          to "enabled_dbuf_slices_mask"(Matt Roper)
      
      v5: - Removed redundant parameters from
            intel_get_ddb_size function.(Matt Roper)
          - Made i915_possible_dbuf_slices static(Matt Roper)
          - Renamed total_width into total_width_in_range
            so that it now reflects that this is not
            a total pipe width but the one in current
            dbuf slice allowed range for pipe.(Matt Roper)
          - Removed 4th pipe for ICL in DBuf assignment
            table(Matt Roper)
          - Fixed wrong DBuf slice in DBuf table for TGL
            (Matt Roper)
          - Added comment regarding why we currently not
            using pipe ratio for DBuf assignment for ICL
      
      v6: - Changed u32 to unsigned int in
            icl_get_first_dbuf_slice_offset function signature
            (Ville Syrjälä)
          - Changed also u32 to u8 in dbuf slice mask structure
            (Ville Syrjälä)
          - Switched from DBUF_S1_BIT to enum + explicit
            BIT(DBUF_S1) access(Ville Syrjälä)
          - Switched to named initializers in DBuf assignment
            arrays(Ville Syrjälä)
          - DBuf assignment arrays now use autogeneration tool
            from
            https://patchwork.freedesktop.org/series/70493/
            to avoid typos.
          - Renamed i915_find_pipe_conf to *_compute_dbuf_slices
            (Ville Syrjälä)
          - Changed platforms ordering in skl_compute_dbuf_slices
            to be from newest to oldest(Ville Syrjälä)
      
      v7: - Now ORing assigned DBuf slice config always with DBUF_S1
            because slice 1 has to be constantly powered on.
            (Ville Syrjälä)
      
      v8: - Added pipe_name for neater printing(Ville Syrjälä)
          - Renamed width_before_pipe to width_before_pipe_in_range,
            to better reflect that now all the calculations are happening
            inside DBuf range allowed by current pipe configuration mask
            (Ville Syrjälä)
          - Shortened FIXME comment message, regarding constant ORing with
            DBUF_S1(Ville Syrjälä)
          - Added .dbuf_mask named initializer to pipe assignment array
            (Ville Syrjälä)
          - Edited pipe assignment array to use only single DBuf slice
            for gen11 single pipe configurations, until "pipe ratio"
            thing is finally sorted out(Ville Syrjälä)
          - Removed unused parameter crtc_state for now(Ville Syrjälä)
            from icl/tgl_compute_dbuf_slices function
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-7-stanislav.lisovskiy@intel.com
      ff2cd863
    • Stanislav Lisovskiy's avatar
      drm/i915: Manipulate DBuf slices properly · 0f0f9aee
      Stanislav Lisovskiy authored
      Start manipulating DBuf slices as a mask,
      but not as a total number, as current approach
      doesn't give us full control on all combinations
      of slices, which we might need(like enabling S2
      only can't enabled by setting enabled_slices=1).
      
      Removed wrong code from intel_get_ddb_size as
      it doesn't match to BSpec. For now still just
      use DBuf slice until proper algorithm is implemented.
      
      Other minor code refactoring to get prepared
      for major DBuf assignment changes landed:
      - As now enabled slices contain a mask
        we still need some value which should
        reflect how much DBuf slices are supported
        by the platform, now device info contains
        num_supported_dbuf_slices.
      - Removed unneeded assertion as we are now
        manipulating slices in a more proper way.
      
      v2: Start using enabled_slices in dev_priv
      
      v3: "enabled_slices" is now "enabled_dbuf_slices_mask",
          as this now sits in dev_priv independently.
      
      v4: - Fixed debug print formatting to hex(Matt Roper)
          - Optimized dbuf slice updates to be used only
            if slice union is different from current conf(Matt Roper)
          - Fixed some functions to be static(Matt Roper)
          - Created a parameterized version for DBUF_CTL to
            simplify DBuf programming cycle(Matt Roper)
          - Removed unrequred field from GEN10_FEATURES(Matt Roper)
      
      v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä)
          - Started to use parameterized loop for hw readout to get slices
            (Ville Syrjälä)
          - Added back assertion checking amount of DBUF slices enabled
            after DC states 5/6 transition, also added new assertion
            as starting from ICL DMC seems to restore the last DBuf
            power state set, rather than power up all dbuf slices
            as assertion was previously expecting(Ville Syrjälä)
      
      v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä)
          - Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled
            back, as we really need to have a single unified assert here
            however currently enabling always slice 1 is enforced by BSpec,
            so we will have to OR enabled slices mask with 1 in order
            to be consistent with BSpec, that way we can unify that
            assertion and against the actual state from the driver, but
            not some hardcoded value.(concluded with Ville)
          - Remove parameterized DBUF_CTL version, to extract it to another
            patch.(Ville Syrjälä)
      v7:
          - Removed unneeded hardcoded return value for older gens from
            intel_enabled_dbuf_slices_mask - this now is handled in a
            unified manner since device info anyway returns max dbuf slices
            as 1 for older platforms(Matthew Roper)
          - Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead
            of intel_dbuf_max_slices function as it is trivial(Matthew Roper)
      
      v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä)
      
      v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä)
          - Now using power_domain mutex to protect from race condition, which
            can occur because intel_dbuf_slices_update might be running in
            parallel to gen9_dc_off_power_well_enable being called from
            intel_dp_detect for instance, which causes assertion triggered by
            race condition, as gen9_assert_dbuf_enabled might preempt this
            when registers were already updated, while dev_priv was not.
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-6-stanislav.lisovskiy@intel.com
      0f0f9aee
    • Stanislav Lisovskiy's avatar
      drm/i915: Introduce parameterized DBUF_CTL · 2570b7e3
      Stanislav Lisovskiy authored
      Now start using parameterized DBUF_CTL instead
      of hardcoded, this would allow shorter access
      functions when reading or storing entire state.
      
      Tried to implement it in a MMIO_PIPE manner, however
      DBUF_CTL1 address is higher than DBUF_CTL2, which
      implies that we have to now subtract from base
      rather than add.
      
      v2: - Removed unneeded DBUF_CTL_DIST and DBUF_CTL_ADDR
            macros. Started to use _PICK construct as suggested
            by Matt Roper.
      
      v3: - _DBUF_CTL_S* to DBUF_CTL_S*, changed X to "slice"
            in macro(Ville Syrjälä)
          - Introduced enum for enumerating DBUF slices(Ville Syrjälä)
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-5-stanislav.lisovskiy@intel.com
      2570b7e3
    • Stanislav Lisovskiy's avatar
      drm/i915: Update dbuf slices only with full modeset · 85487cf4
      Stanislav Lisovskiy authored
      During full modeset, global state(i.e dev_priv) is protected
      by locking the crtcs in state, otherwise global state is not
      serialized. Also if it is not a full modeset, we anyway
      don't need to change DBuf slice configuration as Pipe configuration
      doesn't change.
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-4-stanislav.lisovskiy@intel.com
      85487cf4
    • Stanislav Lisovskiy's avatar
      drm/i915: Move dbuf slice update to proper place · b06cf595
      Stanislav Lisovskiy authored
      Current DBuf slices update wasn't done in proper
      place, especially its "post" part, which should
      disable those only once vblank had passed and
      all other changes are committed.
      
      v2: Fix to use dev_priv and intel_atomic_state
          instead of skl_ddb_values
          (to be nuked in Villes patch)
      
      v3: Renamed "enabled_slices" to "enabled_dbuf_slices_num"
          (Matt Roper)
      
      v4: - Rebase against drm-tip.
          - Move post_update closer to optimize_watermarks,
            to prevent unneeded noise from underrun reporting
            (Ville Syrjälä)
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-3-stanislav.lisovskiy@intel.com
      b06cf595
    • Stanislav Lisovskiy's avatar
      drm/i915: Remove skl_ddl_allocation struct · 072fcc30
      Stanislav Lisovskiy authored
      Current consensus that it is redundant as
      we already have skl_ddb_values struct out there,
      also this struct contains only single member
      which makes it unnecessary.
      
      v2: As dirty_pipes soon going to be nuked away
          from skl_ddb_values, evacuating enabled_slices
          to safer in dev_priv.
      
      v3: Changed "enabled_slices" to be "enabled_dbuf_slices_num"
          (Matt Roper)
      
      v4: - Wrapped the line getting number of dbuf slices(Matt Roper)
          - Removed indeed redundant skl_ddb_values declaration(Matt Roper)
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-2-stanislav.lisovskiy@intel.com
      072fcc30
    • Chris Wilson's avatar
      drm/i915/display: Be explicit in handling the preallocated vma · 9c4ce97d
      Chris Wilson authored
      As only the display codes tries to pin its preallocated framebuffer into
      an exact location in the GGTT, remove the convenience function and make
      the pin management explicit in the display code. Then throughout the
      display management, we track the framebuffer and its plane->vma; with
      less single purpose code and ready for first class i915_vma.
      
      In doing so, this should fix the BUG_ON(vma->pages) on fi-kbl-soraka.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200204094801.877288-2-chris@chris-wilson.co.uk
      9c4ce97d
    • Chris Wilson's avatar
      drm/i915/display: Explicitly cleanup initial_plane_config · 1586f620
      Chris Wilson authored
      I am about to stuff more objects into the plane_config and would like to
      have it clean up after itself. Move the current framebuffer release into
      a common function so it can be extended with the new object with
      relative ease.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200204094801.877288-1-chris@chris-wilson.co.uk
      1586f620
    • Jani Nikula's avatar
      drm/i915/hdcp: move update pipe code to hdcp · 5758e073
      Jani Nikula authored
      The DDI encoder code shouln't have to know about the guts of
      HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in
      intel_hdcp.c. No functional changes.
      
      Cc: Anshuman Gupta <anshuman.gupta@intel.com>
      Reviewed-by: default avatarAnshuman Gupta <anshuman.gupta@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200128163803.5954-1-jani.nikula@intel.com
      5758e073
    • Lyude Paul's avatar
      drm/amd/dm/mst: Ignore payload update failures · 58fe03d6
      Lyude Paul authored
      Disabling a display on MST can potentially happen after the entire MST
      topology has been removed, which means that we can't communicate with
      the topology at all in this scenario. Likewise, this also means that we
      can't properly update payloads on the topology and as such, it's a good
      idea to ignore payload update failures when disabling displays.
      Currently, amdgpu makes the mistake of halting the payload update
      process when any payload update failures occur, resulting in leaving
      DC's local copies of the payload tables out of date.
      
      This ends up causing problems with hotplugging MST topologies, and
      causes modesets on the second hotplug to fail like so:
      
      [drm] Failed to updateMST allocation table forpipe idx:1
      ------------[ cut here ]------------
      WARNING: CPU: 5 PID: 1511 at
      drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677
      update_mst_stream_alloc_table+0x11e/0x130 [amdgpu]
      Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack
      nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4
      nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc
      vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic
      snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops
      videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul
      snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core
      ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm
      sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd
      wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O)
      rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm
      drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm
      crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core
      rtsx_pci pinctrl_amd
      CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G           O      5.5.0-rc7Lyude-Test+ #4
      Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019
      RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu]
      Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06
      49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9
      2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00
      RSP: 0018:ffffac428127f5b0 EFLAGS: 00010202
      RAX: 0000000000000002 RBX: ffff8d1e166eee80 RCX: 0000000000000000
      RDX: ffffac428127f668 RSI: ffff8d1e166eee80 RDI: ffffac428127f610
      RBP: ffffac428127f640 R08: ffffffffc03d94a8 R09: 0000000000000000
      R10: ffff8d1e24b02000 R11: ffffac428127f5b0 R12: ffff8d1e1b83d000
      R13: ffff8d1e1bea0b08 R14: 0000000000000002 R15: 0000000000000002
      FS:  00007fab23ffcd80(0000) GS:ffff8d1e28b40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f151f1711e8 CR3: 00000005997c0000 CR4: 00000000003406e0
      Call Trace:
       ? mutex_lock+0xe/0x30
       dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu]
       ? dm_read_reg_func+0x39/0xb0 [amdgpu]
       ? core_link_enable_stream+0x656/0x730 [amdgpu]
       core_link_enable_stream+0x656/0x730 [amdgpu]
       dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu]
       ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu]
       ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu]
       dc_commit_state+0x292/0x770 [amdgpu]
       ? add_timer+0x101/0x1f0
       ? ttm_bo_put+0x1a1/0x2f0 [ttm]
       amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu]
       ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu]
       ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu]
       ? ttm_bo_handle_move_mem+0x118/0x570 [ttm]
       ? ttm_bo_validate+0x134/0x150 [ttm]
       ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu]
       ? _cond_resched+0x15/0x30
       ? wait_for_completion_timeout+0x38/0x160
       ? _cond_resched+0x15/0x30
       ? wait_for_completion_interruptible+0x33/0x190
       commit_tail+0x94/0x130 [drm_kms_helper]
       drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper]
       drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper]
       drm_mode_setcrtc+0x194/0x6a0 [drm]
       ? _cond_resched+0x15/0x30
       ? mutex_lock+0xe/0x30
       ? drm_mode_getcrtc+0x180/0x180 [drm]
       drm_ioctl_kernel+0xaa/0xf0 [drm]
       drm_ioctl+0x208/0x390 [drm]
       ? drm_mode_getcrtc+0x180/0x180 [drm]
       amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
       do_vfs_ioctl+0x458/0x6d0
       ksys_ioctl+0x5e/0x90
       __x64_sys_ioctl+0x16/0x20
       do_syscall_64+0x55/0x1b0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fab2121f87b
      Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff
      ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
      f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffd045f9068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00007ffd045f90a0 RCX: 00007fab2121f87b
      RDX: 00007ffd045f90a0 RSI: 00000000c06864a2 RDI: 000000000000000b
      RBP: 00007ffd045f90a0 R08: 0000000000000000 R09: 000055dbd2985d10
      R10: 000055dbd2196280 R11: 0000000000000246 R12: 00000000c06864a2
      R13: 000000000000000b R14: 0000000000000000 R15: 000055dbd2196280
      ---[ end trace 6ea888c24d2059cd ]---
      
      Note as well, I have only been able to reproduce this on setups with 2
      MST displays.
      
      Changes since v1:
      * Don't return false when part 1 or part 2 of updating the payloads
        fails, we don't want to abort at any step of the process even if
        things fail
      Reviewed-by: default avatarMikita Lipski <Mikita.Lipski@amd.com>
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Acked-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      58fe03d6