Skip to content

L
linux
Switch branch/tag
  1. 19 Nov, 2014 11 commits
    • Daniel Vetter's avatar
      Merge tag 'drm-intel-fixes-2014-11-19' into drm-intel-next-queued · 54499b2a
      Daniel Vetter authored 
      So with all the code movement and extraction in intel_pm.c in -next
git is hopelessly confused with

commit 2208d655
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Nov 14 09:25:29 2014 +0100

    drm/i915: drop WaSetupGtModeTdRowDispatch:snb

from -fixes. Worse even small changes in -next move around the
conflict context so rerere is equally useless. Let's just backmerge
and be done with it.

Conflicts:
	drivers/gpu/drm/i915/i915_drv.c
	drivers/gpu/drm/i915/intel_pm.c

Except for git getting lost no tricky conflicts really.
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      54499b2a
    • Imre Deak's avatar
      drm/i915: disable rps irqs earlier during suspend/unload · 2eb5252e
      Imre Deak authored 
      After the previous patch RPS disabling doesn't depend any more on the
first level interrupts being disabled, so we can move it everywhere
earlier. Doing so let's us think about the uninitialization steps
afterwards independently of any asynchronous RPS events that can happen
atm. It also makes the system/runtime suspend time RPS disabling more
uniform. Finally this gets rid of the WARN in
intel_suspend_gt_powersave(), which we can hit if a final RPS work runs
after we disabled the first level interrupts.

Testcase: igt/pm_rpm
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2eb5252e
    • Imre Deak's avatar
      drm/i915: sanitize rps irq disabling · d4d70aa5
      Imre Deak authored 
      When disabling the RPS interrupts there is a tricky dependency between
the thread disabling the interrupts, the RPS interrupt handler and the
corresponding RPS work. The RPS work can reenable the interrupts, so
there is no straightforward order in the disabling thread to (1) make
sure that any RPS work is flushed and to (2) disable all RPS
interrupts. Currently this is solved by masking the interrupts using two
separate mask registers (first level display IMR and PM IMR) and doing
the disabling when all first level interrupts are disabled.

This works, but the requirement to run with all first level interrupts
disabled is unnecessary making the suspend / unload time ordering of RPS
disabling wrt. other unitialization steps difficult and error prone.
Removing this restriction allows us to disable RPS early during suspend
/ unload and forget about it for the rest of the sequence. By adding a
more explicit method for avoiding the above race, it also becomes easier
to prove its correctness. Finally currently we can hit the WARN in
snb_update_pm_irq(), when a final RPS work runs with the first level
interrupts already disabled. This won't lead to any problem (due to the
separate interrupt masks), but with the change in this and the next
patch we can get rid of the WARN, while leaving it in place for other
scenarios.

To address the above points, add a new RPS interrupts_enabled flag and
use this during RPS disabling to avoid requeuing the RPS work and
reenabling of the RPS interrupts. Since the interrupt disabling happens
now in intel_suspend_gt_powersave(), we will disable RPS interrupts
explicitly during suspend (and not just through the first level mask),
but there is no problem doing so, it's also more consistent and allows
us to unify more of the RPS disabling during suspend and unload time in
the next patch.

v2/v3:
- rebase on patch "drm/i915: move rps irq disable one level up" in the
  patchset
Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d4d70aa5
    • Imre Deak's avatar
      drm/i915: sanitize rps irq enabling · 3cc134e3
      Imre Deak authored 
      Atm we first enable the RPS interrupts then we clear any pending ones.
By this we could lose an interrupt arriving after we unmasked it. This
may not be a problem as the caller should handle such a race, but logic
still calls for the opposite order. Also we can delay enabling the
interrupts until after all the RPS initialization is ready with the
following order:

1. disable left-over RPS (earlier via intel_uncore_sanitize)
2. clear any pending RPS interrupts
3. initialize RPS
4. enable RPS interrupts

This also allows us to do the 2. and 4. step the same way for all
platforms, so let's follow this order to simplifying things.

Also make sure any queued interrupts are also cleared.

v2:
- rebase on the GEN9 patches where we don't support RPS yet, so we
  musn't enable RPS interrupts on it (Paulo)
v3:
- avoid enabling RPS interrupts on GEN>9 too (Paulo)
- clarify the RPS init sequence in the log message (Chris)
- add POSTING_READ to gen6_reset_rps_interrupts() (Paulo)
- WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts()
  (Paulo)
Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3cc134e3
    • Imre Deak's avatar
      drm/i915: move rps irq disable one level up · e534770a
      Imre Deak authored 
      We disable the RPS interrupts for all platforms at the same spot, so
move it one level up in the callstack to simplify things.

No functional change.

v2:
- rebase on the GEN9 patches where RPS isn't supported yet, so we don't
  need to disable RPS interrupts on it (Paulo)
v3:
- avoid disabling the interrupts on GEN>9 too (Paulo)
Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e534770a
    • Imre Deak's avatar
      drm/i915: WARN if we receive any rps interrupts on gen>9 · 4a74de82
      Imre Deak authored 
      This extends

commit 132f3f17
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Nov 10 15:34:33 2014 +0200

    drm/i915: WARN if we receive any gen9 rps interrupts

to GEN>9 platforms as suggested by Paulo.
Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4a74de82
    • Matt Roper's avatar
      drm/i915: Don't store panning coordinates as 16.16 fixed point · 9dc806fc
      Matt Roper authored 
      When using the universal plane interface, the source rectangle
coordinates define the panning offset for the primary plane, which needs
to be stored in crtc->{x,y}.  The original universal plane code
negelected to set these panning offset fields, which was partially
remedied in:

        commit ccc759dc
        Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
        Date:   Wed Sep 24 14:20:22 2014 -0300

            drm/i915: Merge of visible and !visible paths for primary planes

However the plane source coordinates are provided in 16.16 fixed point
format and the above commit forgot to convert back to integer
coordinates before saving the values.  When we replace
intel_pipe_set_base() with plane->funcs->update_plane() in a future
patch, this bug becomes visible via the set_config entrypoint as well as
update_plane.

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Testcase: igt/kms_plane
Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9dc806fc
    • Jesse Barnes's avatar
      drm/i915/ddi: set has_infoframe flag on DDI too v2 · f061b9be
      Jesse Barnes authored 
      Just like we do in the HDMI code, set the infoframe flag if we detect
that infoframes are enabled.

v2: check for actual infoframe status as in hdmi code (Daniel)
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f061b9be
    • Tom O'Rourke's avatar
      drm/i915: Extend pcode mailbox interface · 151a49d0
      Tom O'Rourke authored 
      In sandybridge_pcode_read and sandybridge_pcode_write,
extend the mbox parameter from u8 to u32.

On Haswell and Sandybridge, bits 7:0 encode the mailbox
command and bits 28:8 are used for address control for
specific commands.

Based on suggestion from Ville Syrjälä.
Signed-off-by: default avatarTom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      151a49d0
    • Daniel Vetter's avatar
      drm/i915: Tune down sink crc timeout dmesg output · 90bd1f46
      Daniel Vetter authored 
      For whatever reasons this can happen. For real testcases the test will
notice the -EIO and fall over, but we also have some testcases that
just read all debugfs files. And that shouldn't cause dmesg spam.

So tune it down a bit so that we still have the information for
debugging. And change the errno so that real testcases can easily
differentiate.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84890Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      90bd1f46
    • Chris Wilson's avatar
      drm/i915: Don't continually defer the hangcheck · 672e7b7c
      Chris Wilson authored 
      With multiple rings, we may continue to render on the blitter whilst
executing an infinite shader on the render ring. As we currently, rearm
the timer with each execbuf, in this scenario the hangcheck will never
fire and we will never detect the lockup on the render ring. Instead,
only arm the timer once per hangcheck, so that hangcheck runs more
frequently.

v2: Rearrange code to avoid triggering a BUG_ON in add_timer from
softirq context.

Testcase: igt/gem_reset_stats/defer-hangcheck*
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86225Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      672e7b7c
  3. 18 Nov, 2014 4 commits
  5. 17 Nov, 2014 22 commits
  7. 16 Nov, 2014 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7