1. 05 1月, 2017 1 次提交
  2. 26 11月, 2016 1 次提交
  3. 15 9月, 2016 1 次提交
  4. 18 5月, 2016 1 次提交
  5. 05 4月, 2016 2 次提交
    • D
      drm/i915/guc: always reset GuC before loading firmware · d761701c
      Dave Gordon 提交于
      After a suspend-resume cycle, the resumed kernel has no idea what the
      booted kernel may have done to the GuC before replacing itself with the
      resumed image. In particular, it may have already loaded the GuC with
      firmware, which will then cause this kernel's attempt to (re)load the
      firmware to fail (GuC program memory is write-once!). The symptoms
      (GuC firmware reload fails after hibernation) are further described
      in the Bugzilla reference below.
      
      So let's *always* reset the GuC just before (re)loading the firmware;
      the hardware should then be in a well-known state, and we may even
      avoid some of the issues arising from unpredictable timing.
      
      Also added some more fields & values to the definition of the GUC_STATUS
      register, which is the key diagnostic indicator if the GuC load fails.
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Cc: Alex Dai <yu.dai@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94390Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      d761701c
    • A
      drm/i915/guc: reset GuC and retry on firmware load failure · 6b332fa2
      Arun Siluvery 提交于
      Due to timing issues in the HW, some of the status bits required for GuC
      authentication occasionally don't get set; when that happens, the GuC
      cannot be initialized and we will be left with a wedged GPU. The W/A
      suggested is to perform a soft reset of the GuC and attempt to reload
      the F/W again for few times before giving up.
      
      As the failure is dependent on timing, tests performed by triggering
      manual full gpu reset (i915_wedged) showed that we could sometimes hit
      this after several thousand iterations, but sometimes tests ran even
      longer without any issues. Reset and reload mechanism proved helpful
      when we indeed hit f/w load failure, so it is better to include this
      to improve driver stability.
      
      This change implements the following WAs,
      
      	WaEnableuKernelHeaderValidFix:skl,bxt
      	WaEnableGuCBootHashCheckNotSet:skl,bxt
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      6b332fa2
  6. 05 1月, 2016 1 次提交
  7. 18 11月, 2015 1 次提交
    • V
      drm/i915: Type safe register read/write · f0f59a00
      Ville Syrjälä 提交于
      Make I915_READ and I915_WRITE more type safe by wrapping the register
      offset in a struct. This should eliminate most of the fumbles we've had
      with misplaced parens.
      
      This only takes care of normal mmio registers. We could extend the idea
      to other register types and define each with its own struct. That way
      you wouldn't be able to accidentally pass the wrong thing to a specific
      register access function.
      
      The gpio_reg setup is probably the ugliest thing left. But I figure I'd
      just leave it for now, and wait for some divine inspiration to strike
      before making it nice.
      
      As for the generated code, it's actually a bit better sometimes. Eg.
      looking at i915_irq_handler(), we can see the following change:
        lea    0x70024(%rdx,%rax,1),%r9d
        mov    $0x1,%edx
      - movslq %r9d,%r9
      - mov    %r9,%rsi
      - mov    %r9,-0x58(%rbp)
      - callq  *0xd8(%rbx)
      + mov    %r9d,%esi
      + mov    %r9d,-0x48(%rbp)
       callq  *0xd8(%rbx)
      
      So previously gcc thought the register offset might be signed and
      decided to sign extend it, just in case. The rest appears to be
      mostly just minor shuffling of instructions.
      
      v2: i915_mmio_reg_{offset,equal,valid}() helpers added
          s/_REG/_MMIO/ in the register defines
          mo more switch statements left to worry about
          ring_emit stuff got sorted in a prep patch
          cmd parser, lrc context and w/a batch buildup also in prep patch
          vgpu stuff cleaned up and moved to a prep patch
          all other unrelated changes split out
      v3: Rebased due to BXT DSI/BLC, MOCS, etc.
      v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
      f0f59a00
  8. 21 10月, 2015 1 次提交
    • A
      drm/i915/guc: Add GuC css header parser · feda33ef
      Alex Dai 提交于
      The size / offset information of all firmware ingredients are
      now caculated from header. Driver will validate the header and
      rsa key size. If any component is out of boundary, driver will
      reject the loading too.
      
      v6: Clean up warnings from make docs
      
      v5: Tidy up GuC titles in kernel/Doc
      
      v4: Now using 'size_dw' for those defined in css_header
      
      v3: 1) Move DOC to intel_guc_fwif.h right before css_header
      definition. Add more comments.
          2) Change 'size' to 'len' or 'length' to avoid confusion.
          3) Add UOS_RSA_SCRATCH_MAX_COUNT according to BSpec. And
      driver validate size of RSA key now.
          4) Add fw component size/offset info to intel_guc_fw.
      
      v2: Add indent into DOC to make fixed-width format rather than
      change the tmpl.
      
      v1: 1) guc_css_header is defined as __packed now
          2) Add and correct GuC related topics in kernel/Doc
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Reviewed-by: NDave Gordon <david.s.gordon@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      feda33ef
  9. 30 9月, 2015 2 次提交
  10. 23 9月, 2015 1 次提交
  11. 15 8月, 2015 1 次提交
    • A
      drm/i915: GuC-specific firmware loader · 33a732f4
      Alex Dai 提交于
      This fetches the required firmware image from the filesystem,
      then loads it into the GuC's memory via a dedicated DMA engine.
      
      This patch is derived from GuC loading work originally done by
      Vinit Azad and Ben Widawsky.
      
      v2:
          Various improvements per review comments by Chris Wilson
      
      v3:
          Removed 'wait' parameter to intel_guc_ucode_load() as firmware
              prefetch is no longer supported in the common firmware loader,
      	per Daniel Vetter's request.
          Firmware checker callback fn now returns errno rather than bool.
      
      v4:
          Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
          Don't keep the driver working (by falling back to execlist mode)
              if GuC firmware loading fails [Daniel Vetter]
      
      v5:
          Clarify WOPCM-related #defines [Tom O'Rourke]
          Delete obsolete code no longer required with current h/w & f/w
              [Tom O'Rourke]
          Move the call to intel_guc_ucode_init() later, so that it can
              allocate GEM objects, and have it fetch the firmware; then
      	intel_guc_ucode_load() doesn't need to fetch it later.
              [Daniel Vetter].
      
      v6:
          Update comment describing intel_guc_ucode_load() [Tom O'Rourke]
      
      Issue: VIZ-4884
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      33a732f4
  12. 21 7月, 2015 1 次提交