1. 04 8月, 2016 3 次提交
  2. 20 7月, 2016 1 次提交
  3. 04 7月, 2016 1 次提交
  4. 08 6月, 2016 1 次提交
  5. 11 5月, 2016 1 次提交
  6. 25 4月, 2016 1 次提交
  7. 19 4月, 2016 1 次提交
    • J
      drm/i915: Clean up PCI config register handling · e10fa551
      Joonas Lahtinen 提交于
      Do not use magic numbers, do not prefix stuff with "PCI_", do not
      declare registers in implementation files. Also move the PCI
      registers under correct comment in i915_reg.h.
      
      v2:
      - Consistently use BSM (not BDSM or other variants from PRM) (Chris)
      - Also include register address to help identify the register (Chris)
      v3:
      - Refer to register value as *_val instead of *_reg (Chris)
      v4:
      - Make style checker happy
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      e10fa551
  8. 31 3月, 2016 1 次提交
    • J
      drm/i915: Refer to GGTT {,VM} consistently · 72e96d64
      Joonas Lahtinen 提交于
      Refer to the GGTT VM consistently as "ggtt->base" instead of just "ggtt",
      "vm" or indirectly through other variables like "dev_priv->ggtt.base"
      to avoid confusion with the i915_ggtt object itself and PPGTT VMs.
      
      Refer to the GGTT as "ggtt" instead of indirectly through chaining.
      
      As a bonus gets rid of the long-standing i915_obj_to_ggtt vs.
      i915_gem_obj_to_ggtt conflict, due to removal of i915_obj_to_ggtt!
      
      v2:
      - Added some more after grepping sources with Chris
      
      v3:
      - Refer to GGTT VM through ggtt->base consistently instead of ggtt_vm
        (Chris)
      
      v4:
      - Convert all dev_priv->ggtt->foo accesses to ggtt->foo.
      
      v5:
      - Make patch checker happy
      
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      72e96d64
  9. 18 3月, 2016 1 次提交
  10. 26 2月, 2016 1 次提交
  11. 16 2月, 2016 1 次提交
  12. 06 2月, 2016 1 次提交
    • S
      drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 · 274008e8
      Sagar Arun Kamble 提交于
      RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
      setup registers. If those are not setup Driver should not enable RC6.
      For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
      to know if BIOS has enabled HW/SW RC6.
      This will also enable user to control RC6 using BIOS settings alone.
      RC6 related instability can be avoided by disabling via BIOS settings
      till driver fixes it.
      
      v2: Had placed logic in gen8 function by mistake. Fixed it.
      Ensuring RPM is not enabled in case BIOS disabled RC6.
      
      v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel)
      Runtime PM enabling happens before gen9_enable_rc6.
      Moved the updation of enable_rc6 parameter in intel_uncore_sanitize.
      
      v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt.
          (Imre)
      
      v5: Caching reserved stolen base and size in the driver private data.
          Reorganized RC6 setup check. Moved from gen9_enable_rc6 to
          intel_uncore_sanitize. (Imre)
      
      v6: Rebasing on the patch submitted by Imre that moves gem_init_stolen
          earlier in the load.
      
      v7: Removed PWRCTX_MAXCNT_VCSUNIT1 check as it applies to SKL. (Imre)
      
      v8: Fixed formatting and checkpatch issues. Fixed functional issue where
          RC6 ctx size check was missing. (Imre)
      
      Cc: Imre Deak <imre.deak@intel.com>
      Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1454697809-22113-1-git-send-email-sagar.a.kamble@intel.com
      274008e8
  13. 06 1月, 2016 1 次提交
  14. 22 12月, 2015 1 次提交
  15. 17 12月, 2015 1 次提交
  16. 29 10月, 2015 1 次提交
    • R
      drm/i915/kbl: Introduce Kabylake platform defition. · ef11bdb3
      Rodrigo Vivi 提交于
      Kabylake is a Intel® Processor containing Intel® HD Graphics
      following Skylake.
      
      It is Gen9p5, so it inherits everything from Skylake.
      
      Let's start by adding the platform separated from Skylake
      but reusing most of all features, functions etc. Later we
      rebase the PCI-ID patch without is_skylake=1
      so we don't replace what original Author did there.
      
      Few IS_SKYLAKEs if statements are not being covered by this patch
      on purpose:
         - Workarounds: Kabylake is derivated from Skylake H0 so no
           		  W/As apply here.
         - GuC: A following patch removes Kabylake support with an
           	  explanation: No firmware available yet.
         - DMC/CSR: Done in a separated patch since we need to be carefull
           	      and load the version for revision 7 since
      	      Kabylake is Skylake H0.
      
      v2: relative cleaner commit message and added the missed
          IS_KABYLAKE to intel_i2c.c as pointed out by Jani.
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ef11bdb3
  17. 09 10月, 2015 1 次提交
    • V
      drm/i915: Determine the stolen memory base address on gen2 · 0ad98c74
      Ville Syrjälä 提交于
      There isn't an explicit stolen memory base register on gen2.
      Some old comment in the i915 code suggests we should get it via
      max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
      
      The e820 map in said machine looks like this:
      [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
      [    0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
      [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
      [    0.000000] BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
      [    0.000000] BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
      [    0.000000] BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
      [    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
      
      That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen memory
      would start there would place it on top of some ACPI memory regions.
      So not a good idea as already stated.
      
      The 9MB region after the ACPI regions at 0x1f700000 however looks
      promising given that the macine reports the stolen memory size to be
      8MB. Looking at the PGTBL_CTL register, the GTT entries are at offset
      0x1fee00000, and given that the GTT entries occupy 128KB, it looks like
      the stolen memory could start at 0x1f700000 and the GTT entries would
      occupy the last 128KB of the stolen memory.
      
      After some more digging through chipset documentation, I've determined
      the BIOS first allocates space for something called TSEG (something to
      do with SMM) from the top of memory, and then it allocates the graphics
      stolen memory below that. Accordind to the chipset documentation TSEG
      has a fixed size of 1MB on 855. So that explains the top 1MB in the
      e820 region. And it also confirms that the GTT entries are in fact at
      the end of the the stolen memory region.
      
      Derive the stolen memory base address on gen2 the same as the BIOS does
      (TOM-TSEG_SIZE-stolen_size). There are a few differences between the
      registers on various gen2 chipsets, so a few different codepaths are
      required.
      
      865G is again bit more special since it seems to support enough memory
      to hit 4GB address space issues. This means the PCI allocations will
      also affect the location of the stolen memory. Fortunately there
      appears to be the TOUD register which may give us the correct answer
      directly. But the chipset docs are a bit unclear, so I'm not 100%
      sure that the graphics stolen memory is always the last thing the
      BIOS steals. Someone would need to verify it on a real system.
      
      I tested this on the my 830 and 855 machines, and so far everything
      looks peachy.
      
      v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
      v3: Fix TSEG size for 830
      v4: Add missing 'else' (Chris)
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0ad98c74
  18. 30 9月, 2015 1 次提交
  19. 24 9月, 2015 1 次提交
  20. 23 9月, 2015 2 次提交
  21. 14 9月, 2015 1 次提交
    • V
      drm/i915: Set stolen reserved to 0 for pre-g4x platforms · d7884d69
      Ville Syrjälä 提交于
      This stolen reserved stuff was introduced on g4x, so no need to waste
      stolen on older platforms. Unfortunately configdb is no more so I can't
      look up the right way to detect this stuff. I do have one hint as to
      where the register might be on ctg, but I don't have a ctg to test it,
      and on the elk I have here it doesn't contain sensible looking data.
      For ilk grits suggegsts it might be in the same place as on snb (the
      original PCI reg, not the mirror) but I can't be entirely sure about it
      The register shows a round zero on my ilk.
      
      So when there's no really good data for any of these platforms leave the
      current "assume 1MiB" approach in place.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d7884d69
  22. 26 8月, 2015 1 次提交
  23. 14 8月, 2015 1 次提交
    • P
      drm/i915: fix stolen bios_reserved checks · 3774eb50
      Paulo Zanoni 提交于
      I started digging this when I noticed that the BDW code was just
      reserving 1mb by coincidence since it was reading reserved fields.
      Then I noticed we didn't have any values set for SNB and earlier, and
      that the HSW sizes were wrong. After that, I noticed that the reserved
      area has a specific start, and may not exactly end where the stolen
      memory ends. I also noticed the base pointer can be zero. So I decided
      to just write a single patch fixing everything instead of 20 patches
      that would be much harder to review.
      
      This patch may solve random stolen memory corruption/problems on
      almost all platforms. Notice that since this is always dealing with
      the top of the stolen memory, the problems are not so easy to
      reproduce - especially since FBC is still disabled by default.
      
      One of the major differences of this patch is that we now look at both
      the size and base address. By only looking at the size we were
      assuming that the reserved area was always at the very top of
      stolen, which is not always true.
      
      After we merge the patch series that allows user space to allocate
      stolen memory we'll be able to write IGT tests that maybe catch the
      bugs fixed by this patch.
      
      v2:
        - s/BIOS reserved/stolen reserved/g (Chris)
        - Don't DRM_ERROR if we can't do anything about it (Chris)
        - Improve debug messages (Chris).
        - Use the gen7 version instead of gen6 on HSW. Tom found some
          documentation problems, so I think with gen7 we're on the safer
          side (Tom).
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3774eb50
  24. 14 7月, 2015 1 次提交
  25. 06 7月, 2015 3 次提交
  26. 09 4月, 2015 1 次提交
  27. 24 2月, 2015 2 次提交
  28. 14 2月, 2015 1 次提交
  29. 10 12月, 2014 1 次提交
  30. 04 11月, 2014 1 次提交
  31. 19 9月, 2014 1 次提交
  32. 09 7月, 2014 1 次提交
  33. 03 7月, 2014 2 次提交
    • B
      drm/i915: Try harder to get FBC · 5e59f717
      Ben Widawsky 提交于
      The GEN FBC unit provides the ability to set a low pass on frames it
      attempts to compress. If a frame is less than a certain amount
      compressibility (2:1, 4:1) it will not bother. This allows the driver to
      reduce the size it requests out of stolen memory.
      
      Unluckily, a few months ago, Ville actually began using this feature for
      framebuffers that are 16bpp (not sure why not 8bpp). In those cases, we
      are already using this mechanism for a different purpose, and so we can
      only achieve one further level of compression (2:1 -> 4:1)
      
      FBC GEN1, ie. pre-G45 is ignored.
      
      The cleverness of the patch is Art's. The bugs are mine.
      
      v2: Update message and including missing threshold case 3 (Spotted by Arthur).
      
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      5e59f717
    • B
      drm/i915: Extract CFB threshold calculation · edc0fdbb
      Ben Widawsky 提交于
      Right now, there is no threshold (0 means fail, 1 means 1:1 compression
      limit). This is to split the function/non-functional change of the next
      patch.
      
      The next patch will start to attempt to reduce the amount of CFB space
      we need for dire situations. It will be contained within this function.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      edc0fdbb