1. 24 4月, 2018 1 次提交
  2. 23 4月, 2018 6 次提交
  3. 21 4月, 2018 5 次提交
    • H
      drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2 · 011f22eb
      Hans de Goede 提交于
      Before this commit the WaSkipStolenMemoryFirstPage workaround code was
      skipping the first 4k by passing 4096 as start of the address range passed
      to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
      reserve the firmware framebuffer so that we can inherit it would always
      fail, as the firmware framebuffer starts at address 0.
      
      Commit d4353761 ("drm/i915: skip the first 4k of stolen memory on
      everything >= gen8") says in its commit message: "This is confirmed to fix
      Skylake screen flickering issues (probably caused by the fact that we
      initialized a ring in the first page of stolen, but I didn't 100% confirm
      this theory)."
      
      Which suggests that it is safe to use the first page for a linear
      framebuffer as the firmware is doing (see note below).
      
      This commit always passes 0 as start to drm_mm_init() and works around
      WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
      by insuring the start address passed by to drm_mm_insert_node_in_range()
      is always 4k or more. All entry points to i915_gem_stolen.c go through
      i915_gem_stolen_insert_node_in_range(), so that any newly allocated
      objects such as ring-buffers will not be allocated in the first 4k.
      
      The one exception is i915_gem_object_create_stolen_for_preallocated()
      which directly calls drm_mm_reserve_node() which now will be able to
      use the first 4k.
      
      This fixes the i915 driver no longer being able to inherit the firmware
      framebuffer on gen8+, which fixes the video output changing from the
      vendor logo to a black screen as soon as the i915 driver is loaded
      (on systems without fbcon).
      
      Some notes about the mapping of the BIOS framebuffer:
      
      v1 led to some discussion if the assumption of the intel_display.c code
      that the firmware framebuffer is a linear mapping of the stolen memory
      starting at offset 0 is still correct, because that would mean that the
      GOP does not implement the WaSkipStolenMemoryFirstPage workaround.
      
      To verify this the following code was added at the end of
      i915_gem_object_create_stolen_for_preallocated() :
      
      pr_err("first ggtt entry before bind: 0x%016llx\n",
             readq(dev_priv->ggtt.gsm));
      ret = i915_vma_bind(vma,
                  HAS_LLC(dev_priv) ? I915_CACHE_LLC : I915_CACHE_NONE,
                  PIN_UPDATE);
      pr_err("i915_vma_bind ret %d\n", ret);
      pr_err("first ggtt entry after bind: 0x%016llx\n",
             readq(dev_priv->ggtt.gsm));
      
      Which prints the mapping of the first page, then does a vma_bind() to
      force update the mapping with our linear view of the framebuffer and
      then prints the mapping of the first page again.
      
      On an Asrock B150M Pro4S/D3 mainboard with i5-6500 CPU this prints:
      
      [    1.651141] first ggtt entry before bind: 0x0000000078c00001
      [    1.651151] i915_vma_bind ret 0
      [    1.651152] first ggtt entry after bind: 0x0000000078c00083
      
      And "sudo cat /proc/iomem | grep Stolen" gives:
        78c00000-88bfffff : Graphics Stolen Memory
      
      There are no visual changes with this patch (BIOS vendor logo still
      stays in place when we inherit the BIOS framebuffer), so the vma_bind()
      does not impact which memory is being scanned out.
      
      The address of the first ggtt entry matches with the start of stolen
      and the i915_vma_bind call only changes the first gtt entry's flags,
      or-ing in _PAGE_RW (BIT(1)) and PPAT_CACHED (BIT(7)), which perfectly
      matches what we would expect based on gen8_pte_encode()'s behavior.
      
      So it seems that the GOP indeed does NOT implement the wa and the i915's
      code assuming a linear mapping at the start of stolen for the BIOS fb
      still holds true for gen8+.
      
      I've also tested this on a Cherry Trail based device (a GPD Win)
      with identical results (the flags are 0x1b after the vma_bind
      on CHT, which matches with I915_CACHE_NONE).
      
      Changed in v2: No code changes, extended the commit message with the
      verification that the intel_display.c BIOS framebuffer mapping is still
      correct.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180420095933.16442-1-hdegoede@redhat.com
      011f22eb
    • D
      drm/i915/psr: Timestamps for PSR entry and exit interrupts. · 3f983e54
      Dhinakaran Pandiyan 提交于
      Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
      PSR entry.
      
      v2: Removed seqlock (Ville)
          Removed erroneous warning in irq loop (Chris)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NJose Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-4-dhinakaran.pandiyan@intel.com
      3f983e54
    • D
      drm/i915/psr: Control PSR interrupts via debugfs · 54fd3149
      Dhinakaran Pandiyan 提交于
      Interrupts other than the one for AUX errors are required only for debug,
      so unmask them via debugfs when the user requests debug.
      
      User can make such a request with
      echo 1 > <DEBUG_FS>/dri/0/i915_edp_psr_debug
      
      There are no locks to serialize PSR debug enabling from
      irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
      called only during module initialization/resume and IGT subtests
      aren't expected to modify PSR debug at those times, we should be safe.
      
      v2: Unroll loops (Ville)
          Avoid resetting error mask bits.
      
      v3: Unmask interrupts in postinstall() if debug was still enabled.
          Avoid RMW (Ville)
      
      v4: Avoid extra IMR write introduced in the previous version.(Jose)
          Style changes, renames (Jose).
      
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NJose Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180405013717.24254-1-dhinakaran.pandiyan@intel.com
      54fd3149
    • V
      drm/i915: Enable edp psr error interrupts on bdw+ · e04f7ece
      Ville Syrjälä 提交于
      Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on
      any transcoder in theory, though the we don't currenty enable PSR except
      on the EDP transcoder.
      
      v2: From DK
       * Rebased on drm-tip
      v3: Switched author to Ville based on IRC discussion.
      
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NJose Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-2-dhinakaran.pandiyan@intel.com
      e04f7ece
    • D
      drm/i915: Enable edp psr error interrupts on hsw · fc340442
      Daniel Vetter 提交于
      The definitions for the error register should be valid on bdw/skl too,
      but there we haven't even enabled DE_MISC handling yet.
      
      Somewhat confusing the the moved register offset on bdw is only for
      the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
      on bdw.
      
      v2: Fixes from Ville.
      
      v3: From DK
       * Rebased on drm-tip
       * Removed BDW IIR bit definition, looks like an unintentional change that
      should be in the following patch.
      
      v4: From DK
       * Don't mask REG_WRITE.
      
      References: bspec/11974 [SRD Interrupt Bit Definition DevHSW]
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NJose Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180405220023.9449-1-dhinakaran.pandiyan@intel.com
      fc340442
  4. 20 4月, 2018 2 次提交
  5. 19 4月, 2018 6 次提交
  6. 18 4月, 2018 1 次提交
  7. 17 4月, 2018 1 次提交
  8. 15 4月, 2018 2 次提交
  9. 13 4月, 2018 3 次提交
  10. 12 4月, 2018 5 次提交
    • J
    • J
      drm/i915/bios: filter out invalid DDC pins from VBT child devices · f212bf9a
      Jani Nikula 提交于
      The VBT contains the DDC pin to use for specific ports. Alas, sometimes
      the field appears to contain bogus data, and while we check for it later
      on in intel_gmbus_get_adapter() we fail to check the returned NULL on
      errors. Oops results.
      
      The simplest approach seems to be to catch and ignore the bogus DDC pins
      already at the VBT parsing phase, reverting to fixed per port default
      pins. This doesn't guarantee display working, but at least it prevents
      the oops. And we continue to be fuzzed by VBT.
      
      One affected machine is Dell Latitude 5590 where a BIOS upgrade added
      invalid DDC pins.
      
      Typical backtrace:
      
      [   35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))
      [   35.461432] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
      [   35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted 4.16.0-rc7.x64-g1cda370ffded #1
      [   35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
      [   35.461450] Workqueue: events_unbound async_run_entry_fn
      [   35.461465] RIP: 0010:intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461467] RSP: 0018:ffff9b4e43d47c40 EFLAGS: 00010286
      [   35.461469] RAX: 0000000000000000 RBX: ffff98f90639f800 RCX: ffffffffae051960
      [   35.461471] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000246
      [   35.461472] RBP: ffff98f905410000 R08: 0000004d062a83f6 R09: 00000000000003bd
      [   35.461474] R10: 0000000000000031 R11: ffffffffad4eda58 R12: ffff98f905410000
      [   35.461475] R13: ffff98f9064c1000 R14: ffff9b4e43d47cf0 R15: ffff98f905410000
      [   35.461477] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
      [   35.461479] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   35.461481] CR2: 00007f5682359008 CR3: 00000001b700c005 CR4: 00000000003606e0
      [   35.461483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   35.461484] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   35.461486] Call Trace:
      [   35.461501]  intel_hdmi_set_edid+0x37/0x27f [i915]
      [   35.461515]  intel_hdmi_detect+0x7c/0x97 [i915]
      [   35.461518]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
      [   35.461521]  drm_setup_crtcs+0x129/0xa6a
      [   35.461523]  ? __switch_to_asm+0x34/0x70
      [   35.461525]  ? __switch_to_asm+0x34/0x70
      [   35.461527]  ? __switch_to_asm+0x40/0x70
      [   35.461528]  ? __switch_to_asm+0x34/0x70
      [   35.461529]  ? __switch_to_asm+0x40/0x70
      [   35.461531]  ? __switch_to_asm+0x34/0x70
      [   35.461532]  ? __switch_to_asm+0x40/0x70
      [   35.461534]  ? __switch_to_asm+0x34/0x70
      [   35.461536]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
      [   35.461538]  ? __switch_to_asm+0x40/0x70
      [   35.461541]  ? _cond_resched+0x10/0x33
      [   35.461557]  intel_fbdev_initial_config+0xf/0x1c [i915]
      [   35.461560]  async_run_entry_fn+0x2e/0xf5
      [   35.461563]  process_one_work+0x15b/0x364
      [   35.461565]  worker_thread+0x2c/0x3a0
      [   35.461567]  ? process_one_work+0x364/0x364
      [   35.461568]  kthread+0x10c/0x122
      [   35.461570]  ? _kthread_create_on_node+0x5d/0x5d
      [   35.461572]  ret_from_fork+0x35/0x40
      [   35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d 84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88 ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00
      [   35.461604] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
      [   35.461606] ---[ end trace 4fe1e63e2dd93373 ]---
      [   35.461609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [   35.461613] IP: i2c_transfer+0x4/0x86
      [   35.461614] PGD 0 P4D 0
      [   35.461616] Oops: 0000 [#1] SMP PTI
      [   35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
      [   35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G        W        4.16.0-rc7.x64-g1cda370ffded #1
      [   35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
      [   35.461628] Workqueue: events_unbound async_run_entry_fn
      [   35.461630] RIP: 0010:i2c_transfer+0x4/0x86
      [   35.461631] RSP: 0018:ffff9b4e43d47b30 EFLAGS: 00010246
      [   35.461633] RAX: ffff9b4e43d47b6e RBX: 0000000000000005 RCX: 0000000000000001
      [   35.461635] RDX: 0000000000000002 RSI: ffff9b4e43d47b80 RDI: 0000000000000000
      [   35.461636] RBP: ffff9b4e43d47bd8 R08: 0000004d062a83f6 R09: 00000000000003bd
      [   35.461638] R10: 0000000000000031 R11: ffffffffad4eda58 R12: 0000000000000002
      [   35.461639] R13: 0000000000000001 R14: ffff9b4e43d47b6f R15: ffff9b4e43d47c07
      [   35.461641] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
      [   35.461643] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   35.461645] CR2: 0000000000000010 CR3: 00000001b700c005 CR4: 00000000003606e0
      [   35.461646] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   35.461647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   35.461649] Call Trace:
      [   35.461652]  drm_do_probe_ddc_edid+0xb3/0x128
      [   35.461654]  drm_get_edid+0xe5/0x38d
      [   35.461669]  intel_hdmi_set_edid+0x45/0x27f [i915]
      [   35.461684]  intel_hdmi_detect+0x7c/0x97 [i915]
      [   35.461687]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
      [   35.461689]  drm_setup_crtcs+0x129/0xa6a
      [   35.461691]  ? __switch_to_asm+0x34/0x70
      [   35.461693]  ? __switch_to_asm+0x34/0x70
      [   35.461694]  ? __switch_to_asm+0x40/0x70
      [   35.461696]  ? __switch_to_asm+0x34/0x70
      [   35.461697]  ? __switch_to_asm+0x40/0x70
      [   35.461698]  ? __switch_to_asm+0x34/0x70
      [   35.461700]  ? __switch_to_asm+0x40/0x70
      [   35.461701]  ? __switch_to_asm+0x34/0x70
      [   35.461703]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
      [   35.461705]  ? __switch_to_asm+0x40/0x70
      [   35.461707]  ? _cond_resched+0x10/0x33
      [   35.461724]  intel_fbdev_initial_config+0xf/0x1c [i915]
      [   35.461727]  async_run_entry_fn+0x2e/0xf5
      [   35.461729]  process_one_work+0x15b/0x364
      [   35.461731]  worker_thread+0x2c/0x3a0
      [   35.461733]  ? process_one_work+0x364/0x364
      [   35.461734]  kthread+0x10c/0x122
      [   35.461736]  ? _kthread_create_on_node+0x5d/0x5d
      [   35.461738]  ret_from_fork+0x35/0x40
      [   35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff 0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54 55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65
      [   35.461756] RIP: i2c_transfer+0x4/0x86 RSP: ffff9b4e43d47b30
      [   35.461757] CR2: 0000000000000010
      [   35.461759] ---[ end trace 4fe1e63e2dd93374 ]---
      
      Based on a patch by Fei Li.
      
      v2: s/reverting/sticking/ (Chris)
      
      Cc: stable@vger.kernel.org
      Cc: Fei Li <fei.li@intel.com>
      Co-developed-by: NFei Li <fei.li@intel.com>
      Reported-by: NPavel Nakonechnyi <zorg1331@gmail.com>
      Reported-and-tested-by: NSeweryn Kokot <sewkokot@gmail.com>
      Reported-and-tested-by: NLaszlo Valko <valko@linux.karinthy.hu>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105549
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105961Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180411131519.9091-1-jani.nikula@intel.com
      f212bf9a
    • O
      drm/i915: Split out functions for different kinds of workarounds · 59b449d5
      Oscar Mateo 提交于
      There are different kind of workarounds (those that modify registers that
      live in the context image, those that modify global registers, those that
      whitelist registers, etc...) and they have different requirements in terms
      of where they are applied and how. Also, by splitting them apart, it should
      be easier to decide where a new workaround should go.
      
      v2:
        - Add multiple MISSING_CASE
        - Rebased
      
      v3:
        - Rename mmio_workarounds to gt_workarounds (Chris, Mika)
        - Create empty placeholders for BDW and CHV GT WAs
        - Rebased
      
      v4: Rebased
      
      v5:
       - Rebased
       - FORCE_TO_NONPRIV register exists since BDW, so make a path
         for it to achieve universality, even if empty (Chris)
      Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [ickle: appease checkpatch]
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/1523376767-18480-2-git-send-email-oscar.mateo@intel.com
      59b449d5
    • O
      drm/i915: Move a bunch of workaround-related code to its own file · 7d3c425f
      Oscar Mateo 提交于
      This has grown to be a sizable amount of code, so move it to
      its own file before we try to refactor anything. For the moment,
      we are leaving behind the WA BB code and the WAs that get applied
      (incorrectly) in init_clock_gating, but we will deal with it later.
      
      v2: Use intel_ prefix for code that deals with the hardware (Chris)
      v3: Rebased
      v4:
        - Rebased
        - New license header
      v5:
        - Rebased
        - Added some organisational notes to the file (Chris)
      v6: Include DOC section in the documentation build (Jani)
      Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [ickle: appease checkpatch, mostly]
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/1523376767-18480-1-git-send-email-oscar.mateo@intel.com
      7d3c425f
    • C
      drm/i915/execlists: Set queue priority from secondary port · 15c83c43
      Chris Wilson 提交于
      We can refine our current execlists->queue_priority if we inspect
      ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
      the unsubmitted queue and say that if a subsequent request is more
      important than the current queue, we will rerun the submission tasklet
      to evaluate the need for preemption. However, we only want to preempt if
      we need to jump ahead of a currently executing request in ELSP. The
      second reason for running the submission tasklet is amalgamate requests
      into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
      (Though repeatedly amalgamating requests into the active context and
      triggering many lite-restore is off question gain, the goal really is to
      put a context into ELSP[1] to cover the interrupt.) So if instead of
      looking at the head of the queue, we look at the context in ELSP[1] we
      can answer both of the questions more accurately -- we don't need to
      rerun the submission tasklet unless our new request is important enough
      to feed into, at least, ELSP[1].
      
      v2: Add some comments from the discussion with Tvrtko.
      v3: More commentary to cross-reference queue_request()
      
      References: f6322edd ("drm/i915/preemption: Allow preemption between submission ports")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180411103929.27374-1-chris@chris-wilson.co.uk
      15c83c43
  11. 11 4月, 2018 4 次提交
  12. 10 4月, 2018 3 次提交
  13. 09 4月, 2018 1 次提交