1. 27 Oct, 2016 4 commits
  2. 26 Oct, 2016 20 commits
  3. 25 Oct, 2016 16 commits
    • Akash Goel's avatar
      drm/i915/guc: WA to address the Ringbuffer coherency issue · ed4596ea
      Akash Goel authored
      Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
      pinned in mappable aperture portion of GGTT and for ringbuffer pages
      allocated from Stolen memory, access can only be done through GMADR BAR.
      In case of GuC based submission, updates done in ringbuffer via GMADR
      may not get committed to memory by the time the Command streamer starts
      reading them, resulting in fetching of stale data.
      
      For Host based submission, such problem is not there as the write to Ring
      Tail or ELSP register happens from the Host side prior to submission.
      Access to any GFX register from CPU side goes to GTTMMADR BAR and Hw already
      enforces the ordering between outstanding GMADR writes & new GTTMADR access.
      MMIO writes from GuC side do not go to GTTMMADR BAR as GuC communication to
      registers within GT is contained within GT, so ordering is not enforced
      resulting in a race, which can manifest in form of a hang.
      
      To ensure the flush of in-flight GMADR writes, a POSTING READ is done to
      GuC register prior to doorbell ring.
      There is already a similar WA in i915_gem_object_flush_gtt_write_domain(),
      which takes care of GMADR writes from User space to GEM buffers, but not the
      ringbuffer writes from KMD.
      This WA is needed on all recent HW.
      
      v2:
      - Use POSTING_READ_FW instead of POSTING_READ as GuC register do not lie
        in any forcewake domain range and so the overhead of spinlock & search
        in the forcewake table is avoidable. (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1477413323-1880-1-git-send-email-akash.goel@intel.com
      ed4596ea
    • Chris Wilson's avatar
      drm/i915: Include the kernel uptime in the error state · de867c20
      Chris Wilson authored
      As well as knowing when the error occurred, it is more interesting to me
      to know how long after booting the error occurred, and for good measure
      record the time since last hw initialisation.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161025121602.1457-1-chris@chris-wilson.co.uk
      de867c20
    • Akash Goel's avatar
      drm/i915: Mark the GuC log buffer flush interrupts handling WQ as freezable · 7ef54de7
      Akash Goel authored
      The GuC log buffer flush work item has to do a register access to send the
      ack to GuC and this work item, if not synced before suspend, can potentially
      get executed after the GFX device is suspended. This work item function uses
      rpm get/put calls around the Hw access, which covers the rpm suspend case
      but for system suspend a sync would be required as kernel can potentially
      schedule the work items even after some devices, including GFX, have been
      put to suspend. But sync has to be done only for the system suspend case,
      as sync along with rpm get/put can cause a deadlock for rpm suspend path.
      To have the sync, but like a NOOP, for rpm suspend path also this work
      item could have been queued from the irq handler only when the device is
      runtime active & kept active while that work item is pending or getting
      executed but an interrupt can come even after the device is out of use and
      so can potentially lead to missing of this work item.
      
      By marking the workqueue, dedicated for handling GuC log buffer flush
      interrupts, as freezable we don't have to bother about flushing of this
      work item from the suspend hooks, the pending work item if any will be
      either executed before the suspend or scheduled later on resume. This way
      the handling of log buffer flush work item can be kept same between system
      suspend & rpm suspend.
      Suggested-by: default avatarImre Deak <imre.deak@intel.com>
      Cc: Imre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      7ef54de7
    • Akash Goel's avatar
      drm/i915: Early creation of relay channel for capturing boot time logs · 1e6b8b0d
      Akash Goel authored
      As per the current i915 Driver load sequence, debugfs registration is done
      at the end and so the relay channel debugfs file is also created after that
      but the GuC firmware is loaded much earlier in the sequence.
      As a result Driver could miss capturing the boot-time logs of GuC firmware
      if there are flush interrupts from the GuC side.
      Relay has a provision to support early logging where initially only relay
      channel can be created, to have buffers for storing logs, and later on
      channel can be associated with a debugfs file at appropriate time.
      Have availed that, which allows Driver to capture boot time logs also,
      which can be collected once Userspace comes up.
      
      v2:
      - Remove the couple of FIXMEs, as now the relay channel will be created
        early before enabling the flush interrupts, so no possibility of relay
        channel pointer being modified & read at the same time from 2 different
        execution contexts.
      - Rebase.
      
      v3:
      - Add a comment to justiy setting 'is_global' before the NULL check on the
        parent directory dentry pointer.
      Suggested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      1e6b8b0d
    • Akash Goel's avatar
      drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer · 71706590
      Akash Goel authored
      To ensure that we always get the up-to-date data from log buffer, its
      better to access the buffer through an uncached CPU mapping. Also the way
      buffer is accessed from GuC & Host side, manually doing cache flush may
      not be effective always if cached CPU mapping is used. In order to avoid
      any performance drop & have fast reads from the GuC log buffer, used SSE4.1
      movntdqa based memcpy function i915_memcpy_from_wc, as copying using
      movntqda from WC type memory is almost as fast as reading from WB memory.
      This way log buffer sampling time will not get increased and so would be
      able to deal with the flush interrupt storm when GuC is generating logs at
      a very high rate.
      Ideally SSE 4.1 should be present on all chipsets supporting GuC based
      submisssions, but if not then logging will not be enabled.
      
      v2: Rebase.
      
      v3: Squash the WC type vmalloc mapping patch with this patch. (Chris)
      Suggested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      71706590
    • Sagar Arun Kamble's avatar
      drm/i915: Debugfs support for GuC logging control · 685534ef
      Sagar Arun Kamble authored
      This patch provides debugfs interface i915_guc_output_control for
      on the fly enabling/disabling of logging in GuC firmware and controlling
      the verbosity level of logs.
      The value written to the file, should have bit 0 set to enable logging and
      bits 4-7 should contain the verbosity info.
      
      v2: Add a forceful flush, to collect left over logs, on disabling logging.
          Useful for Validation.
      
      v3: Besides minor cleanup, implement read method for the debugfs file and
          set the guc_log_level to -1 when logging is disabled. (Tvrtko)
      
      v4: Minor cleanup & rebase. (Tvrtko)
      
      v5:
      - Lock struct_mutex after the NULL check for guc log buffer vma. (Chris)
      - Rebase.
      Signed-off-by: default avatarSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      685534ef
    • Sagar Arun Kamble's avatar
      drm/i915: Support for forceful flush of GuC log buffer · 896a0cb0
      Sagar Arun Kamble authored
      GuC firmware sends a flush interrupt to Host when the log buffer is half
      full and at that time only it updates the log buffer state.
      But in certain cases, as described below, it could be useful to have all
      that even when log buffer is only partially full. For that there is a force
      log buffer flush Host2GuC action supported by GuC firmware.
      
      For Validation requirements, a forceful flush is needed to collect the
      left over logs on disabling logging. The same can be done before proceeding
      with GPU/GuC reset as there could be some data in log buffer which is yet
      to be captured and those logs would be particularly useful to understand
      that why the reset was initiated.
      Signed-off-by: default avatarSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      896a0cb0
    • Akash Goel's avatar
      drm/i915: Augment i915 error state to include the dump of GuC log buffer · 27b85bea
      Akash Goel authored
      Added the dump of GuC log buffer to i915 error state, as the contents of
      GuC log buffer would also be useful to determine that why the GPU reset
      was triggered.
      
      v2:
      - For uniformity use existing helper function print_error_obj() to
        dump out contents of GuC log buffer, pretty printing is better left
        to userspace. (Chris)
      - Skip the dumping of GuC log buffer when logging is disabled as it
        won't be of any use.
      - Rebase.
      
      v3: Rebase.
      Suggested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      27b85bea
    • Akash Goel's avatar
      drm/i915: Increase GuC log buffer size to reduce flush interrupts · 72c0bc66
      Akash Goel authored
      In cases where GuC generate logs at a very high rate, correspondingly
      the rate of flush interrupts is also very high.
      So far total 8 pages were allocated for storing both ISR & DPC logs.
      As per the half-full draining protocol followed by GuC, by doubling
      the number of pages, the frequency of flush interrupts can be cut down
      to almost half, which then helps in reducing the logging overhead.
      So now allocating 8 pages apiece for ISR & DPC logs.
      This also helps in reducing the output log file size, apart from
      reducing the flush interrupt count. With the original settings,
      44 KB was needed for one snapshot. With modified settings, 76 KB is
      needed for a snapshot which will be equivalent to 2 snapshots of the
      original setting. So 12KB saving, every 88 KB, over the original setting.
      Suggested-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      72c0bc66
    • Akash Goel's avatar
      drm/i915: Optimization to reduce the sampling time of GuC log buffer · 6941f3c9
      Akash Goel authored
      GuC firmware sends an interrupt to flush the log buffer when it becomes
      half full, so Driver doesn't really need to sample the complete buffer
      and can just copy only the newly written data by GuC into the local
      buffer, i.e. as per the read & write pointer values.
      Moreover the flush interrupt would generally come for one type of log
      buffer, when it becomes half full, so at that time the other 2 types of
      log buffer would comparatively have much lesser unread data in them.
      In case of overflow reported by GuC, Driver do need to copy the entire
      buffer as the whole buffer would contain the unread data.
      
      v2: Rebase.
      
      v3: Fix the blooper of doing the copy twice. (Tvrtko)
      
      v4: Add curlies for 'else' case also, matching the 'if'. (Tvrtko)
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      6941f3c9
    • Akash Goel's avatar
      drm/i915: Add stats for GuC log buffer flush interrupts · 5aa1ee4b
      Akash Goel authored
      GuC firmware sends an interrupt to flush the log buffer when it
      becomes half full. GuC firmware also tracks how many times the
      buffer overflowed.
      It would be useful to maintain a statistics of how many flush
      interrupts were received and for which type of log buffer,
      along with the overflow count of each buffer type.
      Augmented i915_log_info debugfs to report back these statistics.
      
      v2:
      - Update the logic to detect multiple overflows between the 2
        flush interrupts and also log a message for overflow (Tvrtko)
      - Track the number of times there was no free sub buffer to capture
        the GuC log buffer. (Tvrtko)
      
      v3:
      - Fix the printf field width for overflow counter, set it to 10 as per the
        max value of u32, which takes 10 digits in decimal form. (Tvrtko)
      
      v4:
      - Move the log buffer overflow handling to a new function for better
        readability. (Tvrtko)
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      5aa1ee4b
    • Akash Goel's avatar
      drm/i915: New lock to serialize the Host2GuC actions · 5dd7989b
      Akash Goel authored
      With the addition of new Host2GuC actions related to GuC logging, there
      is a need of a lock to serialize them, as they can execute concurrently
      with each other and also with other existing actions.
      
      v2: Use mutex in place of spinlock to serialize, as sleep can happen
          while waiting for the action's response from GuC. (Tvrtko)
      
      v3: To conform to the general rules, acquire mutex before taking the
          forcewake. (Tvrtko)
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      5dd7989b
    • Akash Goel's avatar
      drm/i915: Add a relay backed debugfs interface for capturing GuC logs · f8240835
      Akash Goel authored
      Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
      User to capture GuC firmware logs. Availed relay framework to implement
      the interface, where Driver will have to just use a relay API to store
      snapshots of the GuC log buffer in the buffer managed by relay.
      The snapshot will be taken when GuC firmware sends a log buffer flush
      interrupt and up to four snapshots could be stored in the relay buffer.
      The relay buffer will be operated in a mode where it will overwrite the
      data not yet collected by User.
      Besides mmap method, through which User can directly access the relay
      buffer contents, relay also supports the 'poll' method. Through the 'poll'
      call on log file, User can come to know whenever a new snapshot of the
      log buffer is taken by Driver, so can run in tandem with the Driver and
      capture the logs in a sustained/streaming manner, without any loss of data.
      
      v2: Defer the creation of relay channel & associated debugfs file, as
          debugfs setup is now done at the end of i915 Driver load. (Chris)
      
      v3:
      - Switch to no-overwrite mode for relay.
      - Fix the relay sub buffer switching sequence.
      
      v4:
      - Update i915 Kconfig to select RELAY config. (TvrtKo)
      - Log a message when there is no sub buffer available to capture
        the GuC log buffer. (Tvrtko)
      - Increase the number of relay sub buffers to 8 from 4, to have
        sufficient buffering for boot time logs
      
      v5:
      - Fix the alignment, indentation issues and some minor cleanup. (Tvrtko)
      - Update the comment to elaborate on why a relay channel has to be
        associated with the debugfs file. (Tvrtko)
      
      v6:
      - Move the write to 'is_global' after the NULL check on parent directory
        dentry pointer. (Tvrtko)
      
      v7: Add a BUG_ON to validate relay buffer allocation size. (Chris)
      
      Testcase: igt/tools/intel_guc_logger
      Suggested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarSourab Gupta <sourab.gupta@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      f8240835
    • Sagar Arun Kamble's avatar
      drm/i915: Handle log buffer flush interrupt event from GuC · 4100b2ab
      Sagar Arun Kamble authored
      GuC ukernel sends an interrupt to Host to flush the log buffer
      and expects Host to correspondingly update the read pointer
      information in the state structure, once it has consumed the
      log buffer contents by copying them to a file or buffer.
      Even if Host couldn't copy the contents, it can still update the
      read pointer so that logging state is not disturbed on GuC side.
      
      v2:
      - Use a dedicated workqueue for handling flush interrupt. (Tvrtko)
      - Reduce the overall log buffer copying time by skipping the copy of
        crash buffer area for regular cases and copying only the state
        structure data in first page.
      
      v3:
       - Create a vmalloc mapping of log buffer. (Chris)
       - Cover the flush acknowledgment under rpm get & put.(Chris)
       - Revert the change of skipping the copy of crash dump area, as
         not really needed, will be covered by subsequent patch.
      
      v4:
       - Destroy the wq under the same condition in which it was created,
         pass dev_piv pointer instead of dev to newly added GuC function,
         add more comments & rename variable for clarity. (Tvrtko)
      
      v5:
      - Allocate & destroy the dedicated wq, for handling flush interrupt,
        from the setup/teardown routines of GuC logging. (Chris)
      - Validate the log buffer size value retrieved from state structure
        and do some minor cleanup. (Tvrtko)
      - Fix error/warnings reported by checkpatch. (Tvrtko)
      - Rebase.
      
      v6:
       - Remove the interrupts_enabled check from guc_capture_logs_work, need
         to process that last work item also, queued just before disabling the
         interrupt as log buffer flush interrupt handling is a bit different
         case where GuC is actually expecting an ACK from host, which should be
         provided to keep the logging going.
         Sync against the work will be done by caller disabling the interrupt.
       - Don't sample the log buffer size value from state structure, directly
         use the expected value to move the pointer & do the copy and that cannot
         go wrong (out of bounds) as Driver only allocated the log buffer and the
         relay buffers. Driver should refrain from interpreting the log packet,
         as much possible and let Userspace parser detect the anomaly. (Chris)
      
      v7:
      - Use switch statement instead of 'if else' for retrieving the GuC log
        buffer size. (Tvrtko)
      - Refactored the log buffer copying function and shortended the name of
        couple of variables for better readability. (Tvrtko)
      
      v8:
      - Make the dedicated wq as a high priority one to further reduce the
        turnaround time of handing log buffer flush event from GuC.
      Signed-off-by: default avatarSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      4100b2ab
    • Sagar Arun Kamble's avatar
      drm/i915: Support for GuC interrupts · 26705e20
      Sagar Arun Kamble authored
      There are certain types of interrupts which Host can receive from GuC.
      GuC ukernel sends an interrupt to Host for certain events, like for
      example retrieve/consume the logs generated by ukernel.
      This patch adds support to receive interrupts from GuC but currently
      enables & partially handles only the interrupt sent by GuC ukernel.
      Future patches will add support for handling other interrupt types.
      
      v2:
      - Use common low level routines for PM IER/IIR programming (Chris)
      - Rename interrupt functions to gen9_xxx from gen8_xxx (Chris)
      - Replace disabling of wake ref asserts with rpm get/put (Chris)
      
      v3:
      - Update comments for more clarity. (Tvrtko)
      - Remove the masking of GuC interrupt, which was kept masked till the
        start of bottom half, its not really needed as there is only a
        single instance of work item & wq is ordered. (Tvrtko)
      
      v4:
      - Rebase.
      - Rename guc_events to pm_guc_events so as to be indicative of the
        register/control block it is associated with. (Chris)
      - Add handling for back to back log buffer flush interrupts.
      
      v5:
      - Move the read & clearing of register, containing Guc2Host message
        bits, outside the irq spinlock. (Tvrtko)
      
      v6:
      - Move the log buffer flush interrupt related stuff to the following
        patch so as to do only generic bits in this patch. (Tvrtko)
      - Rebase.
      
      v7:
      - Remove the interrupts_enabled check from gen9_guc_irq_handler, want to
        process that last interrupt also before disabling the interrupt, sync
        against the work queued by irq handler will be done by caller disabling
        the interrupt.
      Signed-off-by: default avatarSagar Arun Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      26705e20
    • Akash Goel's avatar
      drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set · f4e9af4f
      Akash Goel authored
      So far PM IER/IIR/IMR registers were being used only for Turbo related
      interrupts. But interrupts coming from GuC also use the same set.
      As a precursor to supporting GuC interrupts, added new low level routines
      so as to allow sharing the programming of PM IER/IIR/IMR registers between
      Turbo & GuC.
      Also similar to PM IMR, maintaining a bitmask for PM IER register, to allow
      easy sharing of it between Turbo & GuC without involving a rmw operation.
      
      v2:
      - For appropriateness & avoid any ambiguity, rename old functions
        enable/disable pm_irq to mask/unmask pm_irq and rename new functions
        enable/disable pm_interrupts to enable/disable pm_irq. (Tvrtko)
      - Use u32 in place of uint32_t. (Tvrtko)
      
      v3:
      - Rename the fields pm_irq_mask & pm_ier_mask and do some cleanup. (Chris)
      - Rebase.
      
      v4: Fix the inadvertent disabling of User interrupt for VECS ring causing
          failure for certain IGTs.
      
      v5: Use dev_priv with HAS_VEBOX macro. (Tvrtko)
      Suggested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarAkash Goel <akash.goel@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      f4e9af4f