1. 03 6月, 2021 10 次提交
  2. 21 5月, 2021 9 次提交
  3. 20 5月, 2021 11 次提交
  4. 13 5月, 2021 6 次提交
  5. 06 5月, 2021 2 次提交
    • B
      drm/amdgpu: Use device specific BO size & stride check. · 234055fd
      Bas Nieuwenhuizen 提交于
      The builtin size check isn't really the right thing for AMD
      modifiers due to a couple of reasons:
      
      1) In the format structs we don't do set any of the tilesize / blocks
      etc. to avoid having format arrays per modifier/GPU
      2) The pitch on the main plane is pixel_pitch * bytes_per_pixel even
      for tiled ...
      3) The pitch for the DCC planes is really the pixel pitch of the main
      surface that would be covered by it ...
      
      Note that we only handle GFX9+ case but we do this after converting
      the implicit modifier to an explicit modifier, so on GFX9+ all
      framebuffers should be checked here.
      
      There is a TODO about DCC alignment, but it isn't worse than before
      and I'd need to dig a bunch into the specifics. Getting this out in
      a reasonable timeframe to make sure it gets the appropriate testing
      seemed more important.
      
      Finally as I've found that debugging addfb2 failures is a pita I was
      generous adding explicit error messages to every failure case.
      
      Fixes: f258907f ("drm/amdgpu: Verify bo size can fit framebuffer size on init.")
      Tested-by: NSimon Ser <contact@emersion.fr>
      Signed-off-by: NBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      234055fd
    • B
      drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. · 8bf073ca
      Bas Nieuwenhuizen 提交于
      Otherwise tiling modes that require the values form this field
      (In particular _*_X) would be corrupted upon video decode.
      
      Copied from the VCN v2 code.
      
      Fixes: 99541f39 ("drm/amdgpu: add mc resume DPG mode for VCN3.0")
      Reviewed-and-Tested by: Leo Liu <leo.liu@amd.com>
      Signed-off-by: NBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      8bf073ca
  6. 05 5月, 2021 2 次提交
    • T
      drm/amd/pm: initialize variable · 8651fcb9
      Tom Rix 提交于
      Static analysis reports this problem
      
      amdgpu_pm.c:478:16: warning: The right operand of '<' is a garbage value
        for (i = 0; i < data.nums; i++) {
                      ^ ~~~~~~~~~
      
      In some cases data is not set.  Initialize to 0 and flag not setting
      data as an error with the existing check.
      Signed-off-by: NTom Rix <trix@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      8651fcb9
    • R
      drm/amd/display: Fix two cursor duplication when using overlay · 16e9b3e5
      Rodrigo Siqueira 提交于
      Our driver supports overlay planes, and as expected, some userspace
      compositor takes advantage of these features. If the userspace is not
      enabling the cursor, they can use multiple planes as they please.
      Nevertheless, we start to have constraints when userspace tries to
      enable hardware cursor with various planes. Basically, we cannot draw
      the cursor at the same size and position on two separated pipes since it
      uses extra bandwidth and DML only run with one cursor.
      
      For those reasons, when we enable hardware cursor and multiple planes,
      our driver should accept variations like the ones described below:
      
        +-------------+   +--------------+
        | +---------+ |   |              |
        | |Primary  | |   | Primary      |
        | |         | |   | Overlay      |
        | +---------+ |   |              |
        |Overlay      |   |              |
        +-------------+   +--------------+
      
      In this scenario, we can have the desktop UI in the overlay and some
      other framebuffer attached to the primary plane (e.g., video). However,
      userspace needs to obey some rules and avoid scenarios like the ones
      described below (when enabling hw cursor):
      
                                            +--------+
                                            |Overlay |
       +-------------+    +-----+-------+ +-|        |--+
       | +--------+  | +--------+       | | +--------+  |
       | |Overlay |  | |Overlay |       | |             |
       | |        |  | |        |       | |             |
       | +--------+  | +--------+       | |             |
       | Primary     |    | Primary     | | Primary     |
       +-------------+    +-------------+ +-------------+
      
       +-------------+   +-------------+
       |     +--------+  |  Primary    |
       |     |Overlay |  |             |
       |     |        |  |             |
       |     +--------+  | +--------+  |
       | Primary     |   | |Overlay |  |
       +-------------+   +-|        |--+
                           +--------+
      
      If the userspace violates some of the above scenarios, our driver needs
      to reject the commit; otherwise, we can have unexpected behavior. Since
      we don't have a proper driver validation for the above case, we can see
      some problems like a duplicate cursor in applications that use multiple
      planes. This commit fixes the cursor issue and others by adding adequate
      verification for multiple planes.
      
      Change since V1 (Harry and Sean):
      - Remove cursor verification from the equation.
      
      Cc: Louis Li <Ching-shih.Li@amd.com>
      Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
      Cc: Harry Wentland <Harry.Wentland@amd.com>
      Cc: Hersen Wu <hersenxs.wu@amd.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      16e9b3e5