1. 24 Sep, 2021 1 commit
    • Ville Syrjälä's avatar
      drm/i915/fbc: Rework cfb stride/size calculations · bdc1a2d2
      Ville Syrjälä authored
      The code to calculate the cfb stride/size is a bit of mess.
      The cfb size is getting calculated based purely on the plane
      stride and plane height. That doesn't account for extra
      alignment we want for the cfb stride. The gen9 override
      stride OTOH is just calculated based on the plane width, and
      it does try to make things more aligned but any extra alignment
      added there is not considered in the cfb size calculations.
      So not at all convinced this is working as intended. Additionally
      the compression limit handling is split between the cfb allocation
      code and g4x_dpfc_ctl_limit() (for the 16bpp case), which is just
      confusing.
      
      Let's streamline the whole thing:
      - Start with the plane stride, convert that into cfb stride (cfb is
        always 4 bytes per pixel). All the calculations will assume 1:1
        compression limit since that will give us the max values, and we
        don't yet know how much stolen memory we will be able to allocate
      - Align the cfb stride to 512 bytes on modern platforms. This guarantees
        the 4 line segment will be 512 byte aligned regardles of the final
        compression limit we choose later. The 512 byte alignment for the
        segment is required by at least some of the platforms, and just doing
        it always seems like the easiest option
      - Figure out if we need to use the override stride or not. For X-tiled
        it's never needed since the plane stride is already 512 byte aligned,
        for Y-tiled it will be needed if the plane stride is not a multiple
        of 512 bytes, and for linear it's apparently always needed because the
        hardware miscalculates the cfb stride as PLANE_STRIDE*512 instead of
        the PLANE_STRIDE*64 that it use with linear.
      - The cfb size will be calculated based on the aligned cfb stride to
        guarantee we actually reserved enough stolen memory and the FBC hw
        won't end up scribbling over whatever else is allocated in stolen
      - The compression limit handling we just do fully in the cfb allocation
        code to make things less confusing
      
      v2: Write the min cfb segment stride calculation in a more
          explicit way to make it clear what is going on
      v3: Remeber to update fbc->limit when changing to 16bpp
      
      Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v2
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210923042151.19052-1-ville.syrjala@linux.intel.com
      bdc1a2d2
  2. 23 Sep, 2021 9 commits
  3. 22 Sep, 2021 5 commits
  4. 20 Sep, 2021 12 commits
  5. 17 Sep, 2021 6 commits
  6. 16 Sep, 2021 1 commit
    • Chris Wilson's avatar
      drm/i915: Free all DMC payloads · 064b877d
      Chris Wilson authored
      Free all the DMC payloads, not just DMC_MAIN.
      
      unreferenced object 0xffff88ff32d4d800 (size 1024):
        comm "kworker/1:5", pid 701, jiffies 4294904239 (age 109.736s)
        hex dump (first 32 bytes):
          40 40 00 0c 03 00 00 00 00 00 00 00 00 00 00 00  @@..............
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000ba9d0d95>] dmc_load_work_fn+0x34d/0x510 [i915]
          [<000000001049fcab>] process_one_work+0x261/0x550
          [<00000000eeb995ac>] worker_thread+0x49/0x3c0
          [<0000000021031dc3>] kthread+0x10b/0x140
          [<000000004a0f69ee>] ret_from_fork+0x1f/0x30
      unreferenced object 0xffff88ff0bde4000 (size 1024):
        comm "kworker/0:3", pid 708, jiffies 4294904469 (age 108.816s)
        hex dump (first 32 bytes):
          40 40 00 0c 01 00 00 00 00 00 00 00 00 00 00 00  @@..............
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000ba9d0d95>] dmc_load_work_fn+0x34d/0x510 [i915]
          [<000000001049fcab>] process_one_work+0x261/0x550
          [<00000000eeb995ac>] worker_thread+0x49/0x3c0
          [<0000000021031dc3>] kthread+0x10b/0x140
          [<000000004a0f69ee>] ret_from_fork+0x1f/0x30
      
      Fixes: 3d5928a1 ("drm/i915/xelpd: Pipe A DMC plugging")
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210809194805.3793060-1-lucas.demarchi@intel.com
      064b877d
  7. 15 Sep, 2021 6 commits