1. 06 11月, 2018 1 次提交
  2. 31 10月, 2018 3 次提交
  3. 08 10月, 2018 1 次提交
  4. 18 9月, 2018 4 次提交
    • Z
      drm/i915/gvt: clear ggtt entries when destroy vgpu · 7759ca3a
      Zhipeng Gong 提交于
      When one vgpu is destroyed, its ggtt entries are not cleared.
      This patch clears ggtt entries to avoid information leak.
      
      v2: add 'Fixes' tag (Zhenyu)
      
      Fixes: 2707e444 ("drm/i915/gvt: vGPU graphics memory virtualization")
      Signed-off-by: NZhipeng Gong <zhipeng.gong@intel.com>
      Reviewed-by: NHang Yuan <hang.yuan@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      7759ca3a
    • W
      drm/i915/gvt: request srcu_read_lock before checking if one gfn is valid · a1ac5f09
      Weinan Li 提交于
      Fix the suspicious RCU usage issue in intel_vgpu_emulate_mmio_write.
      Here need to request the srcu read lock of kvm->srcu before doing
      gfn_to_memslot(). The detailed log is as below:
      [  218.710688] =============================
      [  218.710690] WARNING: suspicious RCU usage
      [  218.710693] 4.14.15-dd+ #314 Tainted: G     U
      [  218.710695] -----------------------------
      [  218.710697] ./include/linux/kvm_host.h:575 suspicious rcu_dereference_check() usage!
      [  218.710699]
                     other info that might help us debug this:
      
      [  218.710702]
                     rcu_scheduler_active = 2, debug_locks = 1
      [  218.710704] 1 lock held by qemu-system-x86/2144:
      [  218.710706]  #0:  (&gvt->lock){+.+.}, at: [<ffffffff816a1eea>] intel_vgpu_emulate_mmio_write+0x5a/0x2d0
      [  218.710721]
                     stack backtrace:
      [  218.710724] CPU: 0 PID: 2144 Comm: qemu-system-x86 Tainted: G     U 4.14.15-dd+ #314
      [  218.710727] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.1.1 10/07/2015
      [  218.710729] Call Trace:
      [  218.710734]  dump_stack+0x7c/0xb3
      [  218.710739]  gfn_to_memslot+0x15f/0x170
      [  218.710743]  kvm_is_visible_gfn+0xa/0x30
      [  218.710746]  intel_vgpu_emulate_gtt_mmio_write+0x267/0x3c0
      [  218.710751]  ? __mutex_unlock_slowpath+0x3b/0x260
      [  218.710754]  intel_vgpu_emulate_mmio_write+0x182/0x2d0
      [  218.710759]  intel_vgpu_rw+0xba/0x170 [kvmgt]
      [  218.710763]  intel_vgpu_write+0x14d/0x1a0 [kvmgt]
      [  218.710767]  __vfs_write+0x23/0x130
      [  218.710770]  vfs_write+0xb0/0x1b0
      [  218.710774]  SyS_pwrite64+0x73/0x90
      [  218.710777]  entry_SYSCALL_64_fastpath+0x25/0x9c
      [  218.710780] RIP: 0033:0x7f33e8a91da3
      [  218.710783] RSP: 002b:00007f33dddc8700 EFLAGS: 00000293
      
      v2: add 'Fixes' tag, refine log format.(Zhenyu)
      Fixes: cc753fbe ("drm/i915/gvt: validate gfn before set shadow page")
      Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      a1ac5f09
    • C
      drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handler · d817de3b
      Colin Xu 提交于
      Host prints lots of untracked MMIO at 0x4653c when creating linux guest.
      "gvt: vgpu 2: untracked MMIO 0004653c len 4"
      
      GEN9_CLKGATE_DIS_4 (0x4653c) is accessed by i915 for gmbus clockgating.
      However vgpu doesn't support any clockgating powergating operations
      on related mmio access trap so need add it to default handler.
      GEN9_CLKGATE_DIS_4 is accessed in bxt_gmbus_clock_gating() which only
      applies to GEN9_LP so doens't show the warning on other platforms.
      
      The solution is to add it to default handler init_bxt_mmio_info().
      Reviewed-by: NHe, Min <min.he@intel.com>
      Signed-off-by: NColin Xu <colin.xu@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      d817de3b
    • C
      drm/i915/gvt: Init PHY related registers for BXT · db7c8f1e
      Colin Xu 提交于
      Recent patch fixed the call trace
      "ERROR Port B enabled but PHY powered down? (PHY_CTL 00000000)".
      but introduced another similar call trace shown as:
      "ERROR Port C enabled but PHY powered down? (PHY_CTL 00000200)".
      The call trace will appear when host and guest enabled different ports,
      i.e. host using PORT C or neither PORT is enabled, while guest is always
      using PORT B as simulated by gvt. The issue is actually covered previously
      before the commit and reverals now when the commit do the right thing.
      
      On BXT, some PHY registers are initialized by vbios, before i915 loaded.
      Later i915 will re-program some, or skip some based on the implementation.
      The initialized mmio for guest i915 is done by gvt, based on the snapshot
      taken from host. If host and guest have different PORT enabled, some
      DPIO PHY mmios that gvt initialized for guest i915 will not match the
      simualted monitor for guest, which leads to guest i915 print the calltrace
      when it's trying to enable PHY and PORT.
      
      The solution is to init these DPIO PHY registers to default value, then
      guest i915 will program them to reasonable value based on the default
      powerwell table and enabled PORT. Together with the old patch, all similar
      call trace in guest kernel on BXT can be resolved.
      
      v2: Move PHY register init to intel_vgpu_reset_mmio (Min)
      v3: Do not delete empty line in issue fix patch. (zhenyu)
      
      Fixes: c8ab5ac3 ("drm/i915/gvt: Make correct handling to vreg
      BXT_PHY_CTL_FAMILY")
      Reviewed-by: NHe, Min <min.he@intel.com>
      Signed-off-by: NColin Xu <colin.xu@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      db7c8f1e
  5. 06 9月, 2018 1 次提交
  6. 04 9月, 2018 1 次提交
    • Z
      drm/i915/gvt: Fix life cycle reference on KVM mm · 0a1b60d7
      Zhenyu Wang 提交于
      Handle guest mm access life cycle properly with mmget()/mmput().
      As noted by Linus, use_mm() depends on valid live page table but
      KVM's mmgrab() doesn't guarantee that. As vGPU usage depends on
      guest VM life cycle, need to make sure to use mmget()/mmput() to
      guarantee VM address access.
      
      v3: fix build
      
      v2: v1 caused a weird dependence issue which failed for vfio
      device release, which result invalid mdev vgpu and kvm state
      without proper release taken. This trys to put right reference
      around VM address space access instead.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      0a1b60d7
  7. 03 9月, 2018 1 次提交
    • Z
      drm/i915/gvt: Give new born vGPU higher scheduling chance · 54ff01fd
      Zhenyu Wang 提交于
      This trys to give new born vGPU with higher scheduling chance
      not only with adding to sched list head and also have higher
      priority for workload sched for 2 seconds after starting to
      schedule it. In order for fast GPU execution during VM boot,
      and ensure guest driver setup with required state given in time.
      
      This fixes recent failure seen on one VM with multiple linux VMs
      running on kernel with commit 2621cefa("drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup"),
      which had shorter setup timeout that caused context state init failed.
      
      v2: change to 2s for higher scheduling period
      
      Cc: Yuan Hang <hang.yuan@intel.com>
      Reviewed-by: NHang Yuan <hang.yuan@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      54ff01fd
  8. 30 8月, 2018 5 次提交
    • Z
      drm/i915/gvt: Fix drm_format_mod value for vGPU plane · b244ffa1
      Zhenyu Wang 提交于
      Physical plane's tiling mode value is given directly as
      drm_format_mod for plane query, which is not correct fourcc
      code. Fix it by using correct intel tiling fourcc mod definition.
      
      Current qemu seems also doesn't correctly utilize drm_format_mod
      for plane object setting. Anyway this is required to fix the usage.
      
      v3: use DRM_FORMAT_MOD_LINEAR, fix comment
      
      v2: Fix missed old 'tiled' use for stride calculation
      
      Fixes: e546e281 ("drm/i915/gvt: Dmabuf support for GVT-g")
      Cc: Tina Zhang <tina.zhang@intel.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Colin Xu <Colin.Xu@intel.com>
      Reviewed-by: NColin Xu <Colin.Xu@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      b244ffa1
    • H
      drm/i915/gvt: move intel_runtime_pm_get out of spin_lock in stop_schedule · b2b599fb
      Hang Yuan 提交于
      pm_runtime_get_sync in intel_runtime_pm_get might sleep if i915
      device is not active. When stop vgpu schedule, the device may be
      inactive. So need to move runtime_pm_get out of spin_lock/unlock.
      
      Fixes: b24881e0("drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      b2b599fb
    • C
      drm/i915/gvt: Handle GEN9_WM_CHICKEN3 with F_CMD_ACCESS. · b9b824a5
      Colin Xu 提交于
      Recent patch introduce strict check on scanning cmd:
      Commit 8d458ea0 ("drm/i915/gvt: return error on cmd access")
      
      Before 8d458ea0, if cmd_reg_handler() checks that a cmd access a mmio
      that not marked as F_CMD_ACCESS, it simply returns 0 and log an error.
      Now it will return -EBADRQC which will cause the workload fail to submit.
      
      On BXT, i915 applies WaClearHIZ_WM_CHICKEN3 which will program
      GEN9_WM_CHICKEN3 by LRI when init wa ctx. If it has no F_CMD_ACCESS flag,
      vgpu will fail to start. Also add F_MODE_MASK since it's mode mask reg.
      
      v2: Refresh commit message to elaborate issue symptom in detail.
      v3: Make SKL_PLUS share same handling since GEN9_WM_CHICKEN3 should be
          F_CMD_ACCESS from HW aspect. (yan, zhenyu)
      Signed-off-by: NColin Xu <colin.xu@intel.com>
      Acked-by: NZhao Yan <yan.y.zhao@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      b9b824a5
    • C
      drm/i915/gvt: Make correct handling to vreg BXT_PHY_CTL_FAMILY · c8ab5ac3
      Colin Xu 提交于
      Guest kernel will write to BXT_PHY_CTL_FAMILY to reset DDI PHY
      and pull BXT_PHY_CTL to check PHY status. Previous handling will
      set/reset BXT_PHY_CTL of all PHYs at same time on receiving vreg
      write to some BXT_PHY_CTL_FAMILY. If some BXT_PHY_CTL is already
      enabled, following reset to another BXT_PHY_CTL_FAMILY will clear
      the enabled BXT_PHY_CTL, which result in guest kernel print:
      
      -----------------------------------
      [drm:intel_ddi_get_hw_state [i915]]
      *ERROR* Port B enabled but PHY powered down? (PHY_CTL 00000000)
      -----------------------------------
      
      The correct handling should operate BXT_PHY_CTL_FAMILY and
      BXT_PHY_CTL on the same DDI.
      
      v2: Use correct reg define. The naming looks confusing, however
          current i915_reg.h bind DPIO_PHY0 to _PHY_CTL_FAMILY_DDI and
          bind DPIO_PHY1 to _PHY_CTL_FAMILY_EDP, pairing to
          _BXT_PHY_CTL_DDI_A and _BXT_PHY_CTL_DDI_B respectively.
      v3: v2 incorrectly map _PHY_CTL_FAMILY_EDP to _BXT_PHY_CTL_DDI_A.
          BXT_PHY_CTL() looks up DDI using PORTx but not PHYx. Based on
          DPIO_PHY to DDI mapping, make correct vreg handle to BXT_PHY_CTL
          on receiving vreg write to BXT_PHY_CTL_FAMILY. (He, Min)
      
      Current mapping according to bxt_power_wells:
      dpio-common-a:
          >>> DPIO_PHY1
          >>> BXT_DPIO_CMN_A_POWER_DOMAINS
          >>> POWER_DOMAIN_PORT_DDI_A_LANES
          >>> PORT_A
      
      dpio-common-bc:
          >>> DPIO_PHY0
          >>> BXT_DPIO_CMN_BC_POWER_DOMAINS
          >>> POWER_DOMAIN_PORT_DDI_B_LANES | POWER_DOMAIN_PORT_DDI_C_LANES
          >>> PORT_B or PORT_C
      Signed-off-by: NColin Xu <colin.xu@intel.com>
      Reviewed-by: NHe, Min <min.he@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      c8ab5ac3
    • X
      drm/i915/gvt: emulate gen9 dbuf ctl register access · 9174c1d6
      Xiaolin Zhang 提交于
      there is below call track at boot time when booting guest
      with kabylake vgpu with specifal configuration and this try to fix it.
      
      [drm:gen9_dbuf_enable [i915]] *ERROR* DBuf power enable timeout
      ------------[ cut here ]------------
      WARNING: gen9_dc_off_power_well_enable+0x224/0x230 [i915]
      Unexpected DBuf power power state (0x8000000a)
      Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
      Call Trace:
       [<ffffffff99d24408>] dump_stack+0x19/0x1b
       [<ffffffff996926d8>] __warn+0xd8/0x100
       [<ffffffff9969275f>] warn_slowpath_fmt+0x5f/0x80
       [<ffffffffc07bbae4>] gen9_dc_off_power_well_enable+0x224/0x230 [i915]
       [<ffffffffc07ba9d2>] intel_power_well_enable+0x42/0x50 [i915]
       [<ffffffffc07baa6a>] __intel_display_power_get_domain+0x8a/0xb0 [i915]
       [<ffffffffc07bdb93>] intel_display_power_get+0x33/0x50 [i915]
       [<ffffffffc07bdf95>] intel_display_set_init_power+0x45/0x50 [i915]
       [<ffffffffc07be003>] intel_power_domains_init_hw+0x63/0x8a0 [i915]
       [<ffffffffc07995c3>] i915_driver_load+0xae3/0x1760 [i915]
       [<ffffffff99bd6580>] ? nvmem_register+0x500/0x500
       [<ffffffffc07a476c>] i915_pci_probe+0x2c/0x50 [i915]
       [<ffffffff9999cfea>] local_pci_probe+0x4a/0xb0
       [<ffffffff9999e729>] pci_device_probe+0x109/0x160
       [<ffffffff99a79aa5>] driver_probe_device+0xc5/0x3e0
       [<ffffffff99a79ea3>] __driver_attach+0x93/0xa0
       [<ffffffff99a79e10>] ? __device_attach+0x50/0x50
       [<ffffffff99a77645>] bus_for_each_dev+0x75/0xc0
       [<ffffffff99a7941e>] driver_attach+0x1e/0x20
       [<ffffffff99a78ec0>] bus_add_driver+0x200/0x2d0
       [<ffffffff99a7a534>] driver_register+0x64/0xf0
       [<ffffffff9999df65>] __pci_register_driver+0xa5/0xc0
       [<ffffffffc0929000>] ? 0xffffffffc0928fff
       [<ffffffffc0929059>] i915_init+0x59/0x5c [i915]
       [<ffffffff9960210a>] do_one_initcall+0xba/0x240
       [<ffffffff9971108c>] load_module+0x272c/0x2bc0
       [<ffffffff9997b990>] ? ddebug_proc_write+0xf0/0xf0
       [<ffffffff997115e5>] SyS_init_module+0xc5/0x110
       [<ffffffff99d36795>] system_call_fastpath+0x1c/0x21
      Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      9174c1d6
  9. 17 8月, 2018 2 次提交
  10. 14 8月, 2018 6 次提交
    • Y
      drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() · 7590ebb8
      Yi Wang 提交于
      The 'sparse' variable may leak when return in function
      intel_vgpu_ioctl(), and this patch fix this.
      Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
      Reviewed-by: NJiang Biao <jiang.biao2@zte.com.cn>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      7590ebb8
    • D
      drm/i915/gvt: Off by one in intel_vgpu_write_fence() · 4b25e737
      Dan Carpenter 提交于
      The > should be >= here so that we don't read one element beyond the
      end of the array.
      
      Fixes: 28a60dee ("drm/i915/gvt: vGPU HW resource management")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      4b25e737
    • G
      drm/i915/kvmgt: Fix potential Spectre v1 · de5372da
      Gustavo A. R. Silva 提交于
      info.index can be indirectly controlled by user-space, hence leading
      to a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
      potential spectre issue 'vgpu->vdev.region' [r]
      
      Fix this by sanitizing info.index before indirectly using it to index
      vgpu->vdev.region
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      de5372da
    • Z
      drm/i915/gvt: return error on cmd access · 8d458ea0
      Zhao Yan 提交于
      If a register is not cmd accessible, should not just print error
      message. Return error here so as not to deliver this cmd.
      
      v2: return -EBADRQC to align with return value elsewhere. (kevin tian)
      Signed-off-by: NZhao Yan <yan.y.zhao@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      8d458ea0
    • H
      drm/i915/gvt: initialize dmabuf mutex in vgpu_create · d6c6113b
      Hang Yuan 提交于
      Currently, the mutex used in GVT dmabuf support is not initialized until
      vgpu device is opened. If one vgpu device is opened and then removed, the
      mutex will be used in vgpu remove operation without initialization. This
      patch initializes the mutex in vgpu create operation to avoid the problem.
      
      Fixes: e546e281("drm/i915/gvt: Dmabuf support for GVT-g")
      Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      d6c6113b
    • H
      drm/i915/gvt: fix cleanup sequence in intel_gvt_clean_device · 3fd34ac0
      Hang Yuan 提交于
      Create one vGPU and then unbind IGD device from i915 driver. The following
      oops will happen. This patch will free vgpu resource first and then gvt
      resource to remove these oops.
      
      BUG: unable to handle kernel NULL pointer dereference at       00000000000000a8
        PGD 80000003c9d2c067 P4D 80000003c9d2c067 PUD 3c817c067 P      MD 0
        Oops: 0002 [#1] SMP PTI
        RIP: 0010:down_write+0x1b/0x40
      Call Trace:
        debugfs_remove_recursive+0x46/0x1a0
        intel_gvt_debugfs_remove_vgpu+0x15/0x30 [i915]
        intel_gvt_destroy_vgpu+0x2d/0xf0 [i915]
        intel_vgpu_remove+0x2c/0x30 [kvmgt]
        mdev_device_remove_ops+0x23/0x50 [mdev]
        mdev_device_remove+0xdb/0x190 [mdev]
        mdev_device_remove+0x190/0x190 [mdev]
        device_for_each_child+0x47/0x90
        mdev_unregister_device+0xd5/0x120 [mdev]
        intel_gvt_clean_device+0x91/0x120 [i915]
        i915_driver_unload+0x9d/0x120 [i915]
        i915_pci_remove+0x15/0x20 [i915]
        pci_device_remove+0x3b/0xc0
        device_release_driver_internal+0x157/0x230
        unbind_store+0xfc/0x150
        kernfs_fop_write+0x10f/0x180
        __vfs_write+0x36/0x180
        ? common_file_perm+0x41/0x130
        ? _cond_resched+0x16/0x40
        vfs_write+0xb3/0x1a0
        ksys_write+0x52/0xc0
        do_syscall_64+0x55/0x100
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      BUG: unable to handle kernel NULL pointer dereference at 0      000000000000038
        PGD 8000000405bce067 P4D 8000000405bce067 PUD 405bcd067 PM      D 0
        Oops: 0000 [#1] SMP PTI
        RIP: 0010:hrtimer_active+0x5/0x40
      Call Trace:
        hrtimer_try_to_cancel+0x25/0x120
        ? tbs_sched_clean_vgpu+0x1f/0x50 [i915]
        hrtimer_cancel+0x15/0x20
        intel_gvt_destroy_vgpu+0x4c/0xf0 [i915]
        intel_vgpu_remove+0x2c/0x30 [kvmgt]
        mdev_device_remove_ops+0x23/0x50 [mdev]
        mdev_device_remove+0xdb/0x190 [mdev]
        ? mdev_device_remove+0x190/0x190 [mdev]
        device_for_each_child+0x47/0x90
        mdev_unregister_device+0xd5/0x120 [mdev]
        intel_gvt_clean_device+0x89/0x120 [i915]
        i915_driver_unload+0x9d/0x120 [i915]
        i915_pci_remove+0x15/0x20 [i915]
        pci_device_remove+0x3b/0xc0
        device_release_driver_internal+0x157/0x230
        unbind_store+0xfc/0x150
        kernfs_fop_write+0x10f/0x180
        __vfs_write+0x36/0x180
        ? common_file_perm+0x41/0x130
        ? _cond_resched+0x16/0x40
        vfs_write+0xb3/0x1a0
        ksys_write+0x52/0xc0
        do_syscall_64+0x55/0x100
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: bc7b0be3("drm/i915/gvt: Add basic debugfs infrastructure")
      Fixes: afe04fbe("drm/i915/gvt: create an idle vGPU")
      Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      3fd34ac0
  11. 13 8月, 2018 1 次提交
  12. 08 8月, 2018 1 次提交
    • I
      drm/i915/ddi: Use power well CTL IDX instead of ID · 75e39688
      Imre Deak 提交于
      Similarly to the previous patch use a separate request/status HW flag
      index defined right after the corresponding control registers instead of
      depending for this on the power well IDs. Since the set of
      control/status registers varies among the different power wells (on a
      single platform), also add a new i915_power_well_registers struct that
      we populate and assign to each DDI power well as needed.
      
      Also clarify a bit the code comment describing the function and layout
      of the control registers.
      
      This also fixes a problem on ICL, where we incorrectly read the KVMR
      control register in hsw_power_well_requesters() even for DDI and AUX
      power wells.
      
      v2:
      - Clarify platform range tags in code comments. (Paulo)
      - Fix line over 80 chars checkpatch warning.
      
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com
      75e39688
  13. 07 8月, 2018 5 次提交
  14. 02 8月, 2018 2 次提交
  15. 24 7月, 2018 1 次提交
  16. 10 7月, 2018 1 次提交
  17. 09 7月, 2018 4 次提交