1. 23 Oct, 2018 7 commits
  2. 22 Oct, 2018 21 commits
  3. 19 Oct, 2018 1 commit
    • Xiong Zhang's avatar
      drm/i915: Add ppgtt to GVT GEM context · 4f15665c
      Xiong Zhang authored
      Currently the guest couldn't boot up under GVT-g environment as the
      following call trace exists:
      [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
      [  272.504834] Call Trace:
      [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
      [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
      [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
      [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
      [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
      [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
      [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
      [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
      [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
      
      GVT GEM context is created by i915_gem_context_create_gvt() which
      doesn't allocate ppgtt. So GVT GEM context structure doesn't have
      a valid i915_hw_ppgtt.
      
      This patch create ppgtt table at GVT GEM context creation, then assign
      shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
      be used on GPU. So GVT GEM context has valid ppgtt address. But note
      that this ppgtt only contain valid ppgtt root table address, the table
      entry in this ppgtt structure are invalid.
      
      Fixes:4a3d3f67("drm/i915: Match code to comment and enforce ppgtt for execlists")
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      Reviewed-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/1539841231-3157-1-git-send-email-xiong.y.zhang@intel.com
      4f15665c
  4. 18 Oct, 2018 10 commits
  5. 17 Oct, 2018 1 commit
    • Lyude Paul's avatar
      drm/atomic_helper: Stop modesets on unregistered connectors harder · 39b50c60
      Lyude Paul authored
      Unfortunately, it appears our fix in:
      commit b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes
      for unregistered connectors")
      
      Which attempted to work around the problems introduced by:
      commit 4d802739 ("drm/atomic_helper: Disallow new modesets on
      unregistered connectors")
      
      Is still not the right solution, as modesets can still be triggered
      outside of drm_atomic_set_crtc_for_connector().
      
      So in order to fix this, while still being careful that we don't break
      modesets that a driver may perform before being registered with
      userspace, we replace connector->registered with a tristate member,
      connector->registration_state. This allows us to keep track of whether
      or not a connector is still initializing and hasn't been exposed to
      userspace, is currently registered and exposed to userspace, or has been
      legitimately removed from the system after having once been present.
      
      Using this info, we can prevent userspace from performing new modesets
      on unregistered connectors while still allowing the driver to perform
      modesets on unregistered connectors before the driver has finished being
      registered.
      
      Changes since v1:
      - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
        patchset in igt@drv_module_reload@basic-reload-inject and
        igt@drv_module_reload@basic-reload by checking if the connector is
        registered instead of unregistered, as calling drm_connector_cleanup()
        on a connector that hasn't been registered with userspace yet should
        stay valid.
      - Remove unregistered_connector_check(), and just go back to what we
        were doing before in commit 4d802739 ("drm/atomic_helper: Disallow
        new modesets on unregistered connectors") except replacing
        READ_ONCE(connector->registered) with drm_connector_is_unregistered().
        This gets rid of the behavior of allowing DPMS On<->Off, but that should
        be fine as it's more consistent with the UAPI we had before - danvet
      - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
      - Update documentation, fix some typos.
      
      Fixes: b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: stable@vger.kernel.org
      Cc: David Airlie <airlied@linux.ie>
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
      39b50c60