Skip to content

L
linux
Switch branch/tag
  1. 23 Feb, 2015 14 commits
    • Jeff McGee's avatar
      drm/i915: Request full SSEU enablement on Gen9 · 0cea6502
      Jeff McGee authored 
      On Gen9 the render power gating can leave slice/subslice/EU in
a partially enabled state. We must make an explicit request for
full SSEU enablement through the Render Power Clock State
register when resuming render work. This register is save/
restored in the logical ring context image for execlist
submission mode. Initialize its value in each LRC image to
request full enablement according to the device SSEU config.

Thanks to Sharma Ankitprasad and Akash Goel for highlighting the
issue and proposing the initial fix on which this patch is based.

v2: Adjusted the names of the power gating support flags to fit
    update of an earlier patch.
Signed-off-by: default avatarJeff McGee <jeff.mcgee@intel.com>
Reviewed-by: "Akash Goel <akash.goel@intel.com>"
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0cea6502
    • Jeff McGee's avatar
      drm/i915/skl: Add SKL HW status to SSEU status · 7f992aba
      Jeff McGee authored 
      Add a new section to the 'i915_sseu_status' debugfs entry to
report the currently enabled counts of slice, subslice, and
execution units on the device. The count of enabled subslice
per slice represents the most enabled subslice on any one
slice for devices where imbalances may exist. Similarly, the
count of enabled EU per subslice represents the most enabled
EU on any one subslice.

Collect this device status for Skylake by reading the Gen9
power gate control ack message registers. Power gate control
operates on EU in pairs, therefore our reported counts of
enabled EU can be overestimated by one for each pair in which
one EU is fused-off.
Signed-off-by: default avatarJeff McGee <jeff.mcgee@intel.com>
Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7f992aba
    • Jeff McGee's avatar
      drm/i915/skl: Determine SKL slice/subslice/EU info · 3873218f
      Jeff McGee authored 
      Read fuse registers to determine the available slice total,
subslice total, subslice per slice, EU total, and EU per subslice
counts of the SKL device. The EU per subslice attribute is more
precisely defined as the maximum EU available on any one subslice,
since available EU counts may vary across subslices due to fusing.
Set flags indicating the SKL device's slice/subslice/EU (SSEU)
power gating capability. Make all values available via debugfs
entry 'i915_sseu_status'.

v2: Several small clean-ups suggested by Damien. Most notably,
    used smaller types for the new device info fields to reduce
    memory usage and improved the clarity/readability of the
    method used to extract attribute values from the fuse
    registers.
Signed-off-by: default avatarJeff McGee <jeff.mcgee@intel.com>
Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3873218f
    • Damien Lespiau's avatar
      drm/i915/skl: Implement WaDisablePowerCompilerClockGating · d0bbbc4f
      Damien Lespiau authored 
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: default avatarNick Hoath <nicholas.hoath@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d0bbbc4f
    • Vijay Purushothaman's avatar
      drm/i915: Limit max VCO supported in CHV to 6.48GHz · 9505e01a
      Vijay Purushothaman authored 
      As per the recommendation from PHY team, limit the max vco supported in CHV to 6.48 GHz
Signed-off-by: default avatarVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Acked-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9505e01a
    • Vijay Purushothaman's avatar
      drm/i915: Add new PHY reg definitions for lock threshold · d3eee4ba
      Vijay Purushothaman authored 
      Added new PHY register definitions to control TDC buffer calibration and
digital lock threshold.
Signed-off-by: default avatarVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d3eee4ba
    • Chris Wilson's avatar
      drm/i915: Trim the command parser allocations · 17cabf57
      Chris Wilson authored 
      Currently, the command parser tries to create a secondary batch exactly
as large as the original, and vmap both. This is open to abuse by
userspace using extremely large batch objects, but only executing very
short batches. For example, this would be if userspace were to implement
a command submission ringbuffer. However, we only need to allocate pages
for just the contents of the command sequence in the batch - all
relocations copied to the secondary batch will reference the original
batch and so there can be no access to the secondary batch outside of
the explicit execution region.

Testcase: igt/gem_exec_big #ivb,byt,hsw
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88308Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      17cabf57
    • Dave Gordon's avatar
      drm/i915: FIFO space query code refactor · c32e3788
      Dave Gordon authored 
      When querying the GTFIFOCTL register to check the FIFO space, the read value
must be masked. The operation is repeated explicitly in several places. This
change refactors the read-and-mask code into a function call.

v2: rebased on top of Mika's forcewake patch set, specifically:
	[PATCH 8/8] drm/i915: Enum forcewake domains and domain identifiers

Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: default avatarDave Gordon <david.s.gordon@intel.com>
Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c32e3788
    • Daniel Vetter's avatar
      drm: WARN if drm_handle_vblank is called errornously · ee3c7795
      Daniel Vetter authored 
      KMS drivers are in full control of their irq and vblank handling, if
they get a vblank interrupt before drm_vblank_init or after
drm_vblank_cleanup that's just a driver bug.

For ums driver there's only r128 and radeon which support vblank, and
they call drm_vblank_init in their driver load functions. Which again
means that userspace can do whatever it wants with interrupt, vblank
structures will always be there.

So this should never happen, let's catch driver issues with a WARN_ON.
Motivated by some discussions with Imre.

v2: Use WARN_ON_ONCE as suggested by Imre.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Acked-by: default avatarDave Airlie <airlied@redhat.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      ee3c7795
    • Daniel Vetter's avatar
      drm/irq: Don't call ->get_vblank_counter directly from irq_uninstall/cleanup · 3bff93d6
      Daniel Vetter authored 
      The pipe might already have been shut down, and then it's not a good
idea to call hw accessor functions. Instead use the same logic as
drm_vblank_off which has all the necessary checks to avoid troubles or
inconsistency.

Noticed by Imre while reviewing my patches to remove some sanity
checks from ->get_vblank_counter.

v2: Try harder. disable_and_save can still access the vblank stuff
when vblank->enabled isn't set. It has to, since vlbank irq could be
disable but the pipe is still on when being called from
drm_vblank_off. But we still want to use that code for more code
sharing. So add a check for vblank->enabled on top - if that's not set
we shouldn't have anyone waiting for the vblank. If we have that's a
pretty serious bug.

The other issue that Imre spotted is drm_vblank_cleanup. That code
again calls disable_and_save and so suffers from the same issues. But
really drm_irq_uninstall should have cleaned that all up, so replace
the code with WARN_ON. Note that we can't delete the timer cleanup
since drivers aren't required to use drm_irq_install/uninstall, but
can do their own irq handling.

v3: Make it clear that all that gunk in drm_irq_uninstall is really
just bandaids for UMS races between the irq/vblank code. In UMS
userspace is in control of enabling/disabling interrupts in general
and vblanks specifically.

v4: Imre observed that KMS drivers all call drm_vblank_cleanup before
drm_irq_uninstall (as they should), so again the code in there is dead
for KMS (due to dev->num_crtcs == 0 after drm_vblank_cleanup). Or
should be, so only WARN for KMS - with UMS userspace could try to do
evil things.

v5: After more discussion on irc we've gone back to v3: the
del_timer_sync is required in all cases in drm_vblank_cleanup, but
let's restrict the WARN_ON to kms drivers only. Imre was also
concerned that bad things could happen without the disable_and_save
call. But we immediately free vblank structures afterwards which makes
the save useless. And drm_handle_vblank has a check for dev->num_crtcs
to avoid surprises with ums.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Acked-by: default avatarDave Airlie <airlied@redhat.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      3bff93d6
    • Daniel Vetter's avatar
      drm/i915: Switch to drm_crtc variants of vblank functions · 1e3feefd
      Daniel Vetter authored 
      Where possible right now. Just a small step towards nirvana ...

v2: git add. Uggh. Noticed by Imre.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      1e3feefd
    • Daniel Vetter's avatar
      drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c · f3a5c3f6
      Daniel Vetter authored 
      UMS is no more!

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      f3a5c3f6
    • Daniel Vetter's avatar
      drm/i915: Drop pipe_enable checks in vblank funcs · 1efa2e35
      Daniel Vetter authored 
      With Ville's rework to use drm_crtc_vblank_on/off the core will take
care of rejecting drm_vblank_get calls when the pipe is off. Also the
core won't call the get_vblank_counter hooks in that case either. And
since we've dropped ums support recently we can now remove these
hacks, yay!

Noticed while trying to answer questions Laurent had about how the new
atomic helpers work.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      1efa2e35
    • Daniel Vetter's avatar
      drm/irq: Add drm_crtc_vblank_reset · 9625604c
      Daniel Vetter authored 
      At driver load we need to tell the vblank code about the state of the
pipes, so that the logic around reject vblank_get when the pipe is off
works correctly.

Thus far i915 used drm_vblank_off, but one of the side-effects of it
is that it also saves the vblank counter. And for that it calls down
into the ->get_vblank_counter hook. Which isn't really a good idea
when the pipe is off for a few reasons:
- With runtime pm the register might not respond.
- If the pipe is off some datastructures might not be around or
  unitialized.

The later is what blew up on gen3: We look at intel_crtc->config to
compute the vblank counter, and for a disabled pipe at boot-up that's
just not there. Thus far this was papered over by a check for
intel_crtc->active, but I want to get rid of that (since it's fairly
race, vblank hooks are called from all kinds of places).

So prep for that by adding a _reset functions which only does what we
really need to be done at driver load: Mark the vblank pipe as off,
but don't do any vblank counter saving or event flushing - neither of
that is required.

v2: Clarify the code flow slightly as suggested by Ville.

v3: Fix kerneldoc spelling, spotted by Laurent.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v2)
Acked-by: default avatarDave Airlie <airlied@redhat.com>
Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      9625604c
  3. 13 Feb, 2015 26 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7