- some more ppgtt prep patches from Ben
- a few fbc fixes from Ville
- power well rework from Imre
- vlv forcewake improvements from Deepak S, Ville and Jesse
- a few smaller things all over
[airlied: fixup forwcewake conflict]
* tag 'drm-intel-next-2013-11-29' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits)
drm/i915: Fix port name in vlv_wait_port_ready() timeout warning
drm/i915: Return a drm_mode_status enum in the mode_valid vfuncs
drm/i915: add intel_display_power_enabled_sw() for use in atomic ctx
drm/i915: drop DRM_ERROR in intel_fbdev init
drm/i915/vlv: use parallel context restore when coming out of RC6
drm/i915/vlv: use a lower RC6 timeout on VLV
drm/i915/sdvo: Fix up debug output to not split lines
drm/i915: make sparse happy for the new vlv mmio read function
drm/i915: drop the right force-wake engine in the vlv mmio funcs
drm/i915: Fix GT wake FIFO free entries for VLV
drm/i915: Report all GTFIFODBG errors
drm/i915: Enabling DebugFS for valleyview forcewake counts
drm/i915/vlv: Valleyview support for forcewake Individual power wells.
drm/i915: Add power well arguments to force wake routines.
drm/i915: Do not attempt to re-enable an unconnected primary plane
drm/i915: add a debugfs entry for power domain info
drm/i915: add a default always-on power well
drm/i915: don't do BDW/HSW specific powerdomains init on other platforms
drm/i915: protect HSW power well check with IS_HASWELL in redisable_vga
drm/i915: use IS_HASWELL/BROADWELL instead of HAS_POWER_WELL
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Some additional fixes for 3.13. Regression fixes for audio and hw_i2c,
vram fix for some SI PX cards, race fix in the hwmon code, and a few other
odds and ends.
* 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/atom: fix bus probes when hw_i2c is set (v2)
drm/radeon: fix null pointer dereference in dce6+ audio code
drm/radeon: fixup bad vram size on SI
drm/radeon: fix VGT_GS_INSTANCE_CNT register
drm/radeon: Fix a typo in Cayman and Evergreen registers
drm/radeon/dpm: simplify state adjust logic for NI
drm/radeon: add radeon_vm_bo_update trace point
drm/radeon: add VMID allocation trace point
drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
drm/radeon: program DCE2 audio dto just like DCE3
drm/radeon: fix typo in fetching mpll params
Ensure the side-by-side (half) flag is added to any existing flags when
adding modes from 3D_Structure_ALL.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some boards seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Just flushing out my pile of bugfixes, most of them for regressions/cc:
stable. Nothing really serious going on.
For outstanding issues we still have the S4 fun due to the hsw S4
duct-tape pending (seems like I need to switch into angry maintainer mode
on that one). And there's the mode merging revert to make my g33 work
again still pending for drm core. For that one I don't have any more clue
(and it looks like no one else has a good idea either). And apparently the
locking WARN fix in here also needs to be replicated for boot, still
confirming that one though.
* tag 'drm-intel-fixes-2013-12-02' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Pin pages whilst allocating for dma-buf vmap()
drm/i915: MI_PREDICATE_RESULT_2 is HSW only
drm/i915: Make the DERRMR SRM target global GTT
drm/i915: use the correct force_wake function at the PC8 code
drm/i915: Fix pipe CSC post offset calculation
drm/i915: Simplify DP vs. eDP detection
drm/i915: Check VBT for eDP ports on VLV
drm/i915: use crtc_htotal in watermark calculations to match fastboot v2
drm/i915: Pin relocations for the duration of constructing the execbuffer
drm/i915: take mode config lock around crtc disable at suspend
drm/i915: Prefer setting PTE cache age to 3
drm/i915/ddi: set sink to power down mode on dp disable
This assortment of patches fix a few build and sparse warnings and make
sure to always return -EFAULT on copy_from_user() failures. Finally the
upcasting from struct drm_crtc to struct tegra_dc is made safer to
prevent potential segmentation faults.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSnaLrAAoJEN0jrNd/PrOhm+YP/jXPCBWuyMzbw6Sld0U9gs7c
xjxBuH7CwU5CCEA1OzBoQOf5ANrlbZ7rnbNoJzqPktss1TWADhBs8Yvn/SsOClwe
L+5yiVZ21pKXPOXpX2e4NlIrNqyq+USb+Ve3SfhNoWIcZyIjKosy66sQJBijo5ap
Kz+EpFcGjYePt3zhyIR4JOEtfjJd0gk2e72MBPFUtnteS9ecNt+ZGZaTse27xVn3
ogyvef7Vp2r097OO5QS9PnohPQffJMmU36dzfzzKIcvn7vg+3xuO7sZdzdEvErHh
eNXXJoFIpUA1xbrmrNLl0HcnCkwun+nrpEd29ceszqd0Pspz6TUdTj6Og5vjbCrZ
LhVBZQydTpQQoMmI9l12GmePvEhjgWDc68bRCjhuIlRa84+nXWglJ29cgrvEdBJA
/V1dRE1WAL+TkBK83LcjiwihrM/KKqILjgl8ta6D6Jyi0JGEjUQBY2JEYedt2/T6
y9nhZ8pwI/rbROS71AXWgMjHoKhS/D939jwCMo+3bLjn2Vi4QyyDJeahbVsiGNze
kUCcKVvWh3eJNSZYEnpWPNFQaFDxZhFPtr+kPCG9AB1w3yji/dluEOe8r/pUvHnn
KK87Jfcu8UaiusILW/k6h9skZAPbC/t8I9S50JgSeO1jDVMN8lqlv1IP32cGFVXm
j9ZbTEyeJN8VFVMs5r2E
=Du68
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.13-rc3' of git://anongit.freedesktop.org/tegra/linux into drm-fixes
drm/tegra: Fixes for v3.13-rc3
This assortment of patches fix a few build and sparse warnings and make
sure to always return -EFAULT on copy_from_user() failures. Finally the
upcasting from struct drm_crtc to struct tegra_dc is made safer to
prevent potential segmentation faults.
* tag 'drm/for-3.13-rc3' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: return -EFAULT if copy_from_user() fails
gpu: host1x: Fix a few sparse warnings
drm/tegra: Force cast to __iomem to make sparse happy
drm/tegra: Make tegra_drm_driver static
drm/tegra: Fix address space mismatches
drm/tegra: Tightly bind RGB output to DC
drm/tegra: Make CRTC upcasting safer
gpu: host1x: Silence a few warnings with LPAE=y
5dc9e1e8 was a bit over-ambitious, and accidentially removed handling
for imported prime buffers.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix some pageflip, oopses and some better clock support for some chipsets
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv50/disp: min/max are reversed in nv50_crtc_gamma_set()
drm/nouveau/sw: fix oops if gpu has its display block disabled
drm/nouveau: unreference fence after syncing
drm/nouveau/kms: send timestamp data for correct head in flip completion events
drm/nouveau/clk: Add support for NVAA/NVAC
drm/nouveau/fifo: Hook up pause and resume for NV50 and NV84+
drm/nv10/plane: some chipsets don't support NV12
drm/nv10/plane: add downscaling restrictions
drm/nv10/plane: fix format computation
drm/nv04-nv30/clk: provide an empty domain list
Some user-space apps expects to find them there.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Also request kernel ttm_buffer objects for buffer objects that obviously
aren't visible to user-space, and save some device address space.
The accounting was broken in a couple of ways:
1) We did not differentiate between user dma buffers and kernel dma buffers.
2) The ttm_bo_acc_size function is broken in that it
a) Doesn't take into account the size of the optional dma address array,
b) Doesn't take into account the fact that drivers typically embed the
ttm_tt structure.
This needs to be fixed in ttm, but meanwhile provide a vmwgfx-specific
function to do the job.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Allocation was duplicating code. Comments were missing.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Failure to do this would make the drm_mode_get_crtc ioctl return
without crtc mode info, indicating that no mode was set.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
We should be taking the minimum here instead of the max. It could lead
to a buffer overflow.
Fixes: 438d99e3b1 ('drm/nvd0/disp: initial crtc object implementation')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
a/drm/nv50_display.c b/drm/nv50_display.c
index f8e66c08b11a..4e384a2f99c3 100644
Otherwise none of the format checks pass, since the width was still in
16.16 encoding.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
copy_from_user() returns the number of bytes remaining if it fails, but
we want to return -EFAULT here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Include the bus.h header, so that various function declarations are
visible in the source file that implements those functions. This keeps
sparse from suggesting that they should be made static.
Make the host1x_bus_type variable static since it isn't used globally.
Finally replace the slightly unsafe dev_set_name(dev, name) by the more
secure dev_set_name(dev, "%s", name).
Signed-off-by: Thierry Reding <treding@nvidia.com>
The fbdev screen memory pointer is annotated __iomem, so cast the kernel
virtual address to that address space to make the warning go away.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Previously the association to a DC was done via the encoder's .crtc
field. That has the disadvantage that when an encoder is detached from
its CRTC, that field is set to NULL, leading to situations where it is
impossible to access the DC registers required by the RGB output.
However, the coupling between DC and RGB output is really fixed on
Tegra. While they can be detached logically in DRM, the RGB output can
rely on the DC's existence.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When upcasting a NULL CRTC object, propagate the NULL pointer instead of
some invalid pointer. This allows subsequent code to check that the cast
object is valid.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This register was incorrect for evergreen and cayman.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
According to documentation, 0x00008A60 should be PA_SU_LINE_STIPPLE_VALUE.
Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is based on a similar patch from Alexandre Demers.
While fixing up some warnings with that patch I saw some
additional cleanups that could be applied. This patch
simplifies the logic for patching the power state.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Alexandre Demers <alexandre.f.demers@gmail.com>
Also rename the function to better reflect what it is doing.
agd5f: fix argument size warning
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Simplify the code and fix race condition seen because
attribute files were created after hwmon device registration.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copy-paste typo. Value should be 0-2, not 0-1.
Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This patch resolves a dead lock issue that could be incurred when
exynos_drm_crtc_dpms function was called.
The exynos_drm_crtc_dpms function waits for the completion of pended
page flip events. However, preclose callback - this releases all unhandled
page flip events - is called prior to the exynos_drm_crtc_dpms function call
when drm is closed. So at this time, this will make the exynos_drm_crtc_dpms
to wait infiniately for the completion of the page flip events.
This patch releases the unhandled page flip events at postclose instead
of preclose so that exynos_drm_crtc_dpms function can be waked up.
Changelog v2:
- fix a memory leak when drm is closed.
. it has a memory leak when a requeste page flip is handled after
drm_events_release() is called and before drm_fb_release()
is called. At this time, a drm_pending_event will not be freed.
So also this chage releases the drm_pending_event at postclose().
And it calls drm_vblank_put() for pair if there is any unhandled page
flip event.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
During the vmap() routine for the dma-buf, we first grab the pages and
then try to allocate a temporary array to pass to the vmap(). However,
the shrinker can and will reap any object that is unbound if the
allocation for the array first fails. This includes the object which we
are attempting to vmap(). The solution is to mark the object's pages as
pinned whilst we try the allocation to prevent the use-after-free
introduced by the potential shrinkage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're currently misprinting the port name when vlv_wait_port_ready()
times out. Fix it by using port_name().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The MI_PREDICATE_RESULT_2 register exits only on HSW. On other
platforms the same offset is either reserved, or contains some
other register. So write the register only on HSW.
This regression has been introduced in
commit 9435373ef8
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date: Wed Aug 28 16:45:46 2013 -0300
drm/i915: Report enabled slices on Haswell GT3
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add regression notice.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ring scratch pages don't have a PPGTT mapping, so the DERRM SRM
should target the global GTT instead.
v2: Add MI_SRM_LRM_GLOBAL_GTT define for -fixes
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
a second version of the patch to correct this problem. The problem is
that v1 was merged instead of v2.
I was able to notice the problem when running the
debugfs-forcewake-user subtest of pm_pc8 from intel-gpu-tools.
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
wow no idea how I got this far without seeing this,
leaking the entries in the list makes kmalloc-64 slab grow.
References: https://bugzilla.kernel.org/show_bug.cgi?id=65121
Cc: stable@vger.kernel.org
Reported-by: Matthew Stapleton <matthew4196@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were miscalculating the pipe CSC post offset for the full->limited
range conversion. The resulting post offset was double what it was
supposed to be, which caused blacks to come out grey when using
limited range output on HSW+.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769
Cc: stable@vger.kernel.org
Tested-by: Lauri Mylläri <lauri.myllari@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We had some mode_valid() vfuncs returning an int, others the enum. Let's
use the latter everywhere.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When building with LPAE=y (64-bit dma_addr_t), the following warnings are seen:
drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects
argument of type 'unsigned int', but argument 5 has type 'dma_addr_t'
drivers/gpu/host1x/hw/debug_hw.c:167:10: warning: format '%x' expects
argument of type 'unsigned int', but argument 3 has type 'dma_addr_t'
The agreed-to solution for this is upcast to u64 and using %llx.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Atm we call intel_display_power_enabled() from
i915_capture_error_state() in IRQ context and then take a mutex. To fix
this add a new intel_display_power_enabled_sw() which returns the domain
state based on software tracking as opposed to reading the actual HW
state.
Since we use domain_use_count for this without locking on the reader
side make sure we increase the counter only after enabling all required
power wells and decrease it before disabling any of these power wells.
Regression introduced in
commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Sep 24 16:17:09 2013 +0300
drm/i915: support for multiple power wells
Note that atm we depend on the value returned by
intel_display_power_enabled_sw() in i915_capture_error_state() to avoid
unclaimed register access reports. This was never guaranteed though,
since another thread can disable the power concurrently. If this is a
problem we need another explicit way to disable the reporting during
error captures.
v2:
- remove barriers as the caller can't depend on the value
returned from i915_capture_error_state_sw() anyway (Ville)
- dump the state of pipe/transcoder power domain state (Daniel)
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should just be a debug. Add another debug msg to the inherit path
while we're at it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72098
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reduce the eDP detection to just checking if it's port A, or if
the VBT tells us that the port is eDP for the other ports.
Suggested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV can have eDP on either port B or C, or even both. Based on the
VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we
check the correct ports.
So instead of hardcoding port D, rename the function to
intel_dp_is_edp() and pass the port as a parameter, and use it
on VLV ports B and C.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051
Tested-by: Robert Hooker <robert.hooker@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Wrestle the patch to apply and compile properly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Setting this bit restores all ring contexts in parallel rather than
serially. Matches current BWG recommendations.
Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Deepak S <deepak.s@inel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use timeout mode, and we need to lower the timeout to get good RC6
residency when loads are running. This gets me from 0% residency during
glxgears to 77%, which is a pretty good improvement. This value also
matches the current BWG recommentations.
Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Deepak S <deepak.s@inel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It leads to a big mess when stuff interleaves. Especially with the new
patch I've submitted for the drm core to no longer artificially split
up debug messages.
v2: The size parameter to snprintf includes the terminating 0, but the
return value does not. Adjust the logic accordingly. Spotted by Mika.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It doesn't like that we assign 0 to a pointer, it wants the real NULL.
On closer look that initialization is actually bogus, and the compiler
can easily see that we never use it unitialized. So let's just drop
this.
Cc: Deepak S <deepak.s@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was fumbled in the conversion to per-engine forcewake.
Cc: Deepak S <deepak.s@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV the GTFIFOCTL register has other bits besides the number of free
entries in the GT wake FIFO. Apply a mask when we read th register to
make sure we don't misinterpret the number of free FIFO entries.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: There's some unclarity about hsw, but brushed off as todays'
Bspec just acting up a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV GTFIFODBG has more bits. Just report them all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Forcewake counts for valleyview are not exposed throgh DebugFS.
Exposing with this change.
Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split vlv force wake routines to help individually control Media/Render
well based on the register access.
We've seen power savings in the lower sub-1W range on workloads that
only need on of the power wells, e.g. glbenchmark, media playback
Note: The same split isn't there for the forcewake queue, only the
forcwake domains are split.
Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Rebase on top of the removed forcewake hack in the ring irq
get/put code and add a note to add Deepak's answer to Chris question.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added power well arguments to all the force wake routines
to help us individually control power well based on the
scenario.
Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict with the removed forcewake hack and drop one
spurious hunk Jesse noticed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Jim Davis <jim.epost@gmail.com>
Tested-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Copy/Paste typo.. we need to test for ->kdev instead of ->dev.
Reported-by: Juha Leppänen <juha_efku@dnainternet.net>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This value is more correct, and matches what we read out in the fastboot
code. Without this, the watermark code will panic after the first mode
setting activity after a fastboot.
v2: fix up HSW ->clock usage too (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to user fudging (for instance using video=VGA-1:e with FBDEV=n) we can
attempt to reset an inconsistent CRTC that is marked as active but has
no assigned fb. It would be wise to fix this earlier, but the long
term plan is to have primary and secondary planes associated with a
CRTC, in which crtc->fb being NULL will be expected. So for a quick
short term fix with pretensions of grandeur, just check for a NULL fb
during GPU reset and ignore the plane restoration.
This fixes a potential hard hang (a panic in the panic handler)
following a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Add a corresponding fixme comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As the execbuffer dispatch grows ever more complex and involves multiple
stages of moving objects into the aperture, we need to take greater care
that we do not evict our execbuffer objects prior to dispatch. This is
relatively simple as we can just keep the objects pinned for not just
the relocation but until we are finished.
One such example is the possibility of the context switch causing an
eviction or hitting the shrinker in order to fit its object into the
aperture.
Link: http://lists.freedesktop.org/archives/intel-gfx/2013-November/036166.html
Reported-by: "Siluvery, Arun" <arun.siluvery@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add the additional explanations from Chris to the commit
message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a debugfs entry showing the use-count for all power domains of each
power well.
v3: address comments from Paulo:
- simplify power_domain_str() by using a switch table
- move power_well::domain_count to power_domains
- WARN_ON decrementing a 0 refcount
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far we distinguished platforms without a dynamic power well with
the HAS_POWER_WELL macro and for such platforms we didn't call any power
domain functions. Instead of doing this check we can add an always-on
power well for these platforms and call the power domain functions
unconditionally. For always-on power wells we only increase/decrease
their refcounts, otherwise they are nop.
This makes high level driver code more readable and as a bonus provides
some idea of the current power domains state for all platforms (once
the relevant debugfs entry is added).
v3: rename intel_power_wells to i9xx_always_on_power_well (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This may need work if other platforms do the same thing, but in the
meantime we should avoid looking at HSW specific bits in this generic
function.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[added IS_BROADWELL too as that needs the same handling (Imre)]
Signed-off-by: Imre Deak <imre.deak@intel.com>
[danvet: Add Imre's missing sob.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In intel_display_capture_error_state we use HAS_POWER_WELL to check if
we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER
which is specific to these platforms. Future platforms with power wells
don't have this register, so HAS_POWER_WELL won't work there any more.
Use IS_HASWELL/IS_BROADWELL instead.
v3: fix using logical || instead of bitwise | (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of using a separate function to check whether a power domain is
is always on, add an always-on power well covering all these power
domains and do the usual get/put on these unconditionally. Since we
don't assign a .set handler for these the get/put won't have any effect
besides the adjusted refcount.
This makes the code more readable and provides debug info also on the
use of always-on power wells (once the relevant debugfs entry is added.)
v3: make is_always_on to be bool instead of a bit field (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HW generations so far had only one always-on power well and optionally
one dynamic power well. Upcoming HW gens may have multiple dynamic power
wells, so add some infrastructure to support them.
The idea is to keep the existing power domain API used by the rest of
the driver and create a mapping between these power domains and the
underlying power wells. This mapping can differ from one HW to another
but high level driver code doesn't need to know about this. Through the
existing get/put API it would just ask for a given power domain and the
power domain framework would make sure the relevant power wells get
enabled in the right order.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This way the code is simpler and can also be used for other platforms
where the audio power domain->power well mapping is different.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is just a theoretical issue, but we need to do this to prevent the
WARN in pipe_from_connector at suspend time.
This regression has been introduce in
commit 7bd688cd66
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Nov 8 16:48:56 2013 +0200
drm/i915: handle backlight through chip specific functions
https://bugs.freedesktop.org/show_bug.cgi?id=71978
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we use a stolen buffer, our probe callback shouldn't allocate a new
buffer; we should re-use the one from the BIOS instead if possible.
v2: fix locking (Jesse)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I believe, and an evening of i-g-t, that our original workaround for the
missed interrupts on Sandybridge, that of holding forcewake whilst we
wait for an interrupts, is no longer required. This leaves us dependent
on the second workaround of forcing an UC read of the ACTHD before
reading back the seqno from the snooped HWS. Dropping the forcewake
should allow us to conserve a little power, not much as the GPU is meant
to be busy whilst we wait for it!
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our VM code already has a cleanup function, and this is a nice place to
put the drm_mm_takedown. This should have no functional impact, it just
leaves the unload function a bit cleaer, and is more logical IMO
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This belonged in
commit 07fe0b1280
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Jul 31 17:00:10 2013 -0700
drm/i915: plumb VM into bind/unbind code
But it was somehow missed along the way.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_gem_execbuffer_relocate became defunct in:
commit 27173f1f95
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Aug 14 11:38:36 2013 +0200
drm/i915: Convert execbuf code to use vmas
eb_create: never used?
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: The lingering vm parameter to eb_create might have been back
from the days where we didn't yet keep both vmas and obj lists in the
eb struct. But I didn't check really.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Many tests call this ad naseum now (in an infinite loop, very often).
It clutters the logs. Actually, I'd rather drop it completely...
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This would have never worked.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should really have been added in BDW integration, as well as:
commit 93bd8649db
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue Jul 16 16:50:06 2013 -0700
drm/i915: Put the mm in the parent address space
It didn't really matter before, but it will in the future.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we fail for some reason on loading the PDPs, it would be wise to
disable the PPGTT in the ring registers. If we do not do this, we have
undefined results.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have conflicting benchmark data that suggest either age 0 or age 3 is
better. However, the earlier benchmark on which we based the switch to
age 0
(commit 0d8ff15e9a
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Thu Jul 4 11:02:03 2013 -0700
drm/i915/hsw: Set correct Haswell PTE encodings)
actually seems to prefer the default PTE encoding as age 3. Presumably,
this is in part due to the use of MOCS to override the PTE encodings
when appropriate.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69870
Tested-by: mengmeng.meng@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eric Anholt <eric@anholt.net
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SNB has another register where the actual FBC CPU fence number is
stored. The documenation explicitly states that the fence number
in DPFC_CTL must be 0 on SNB. And in fact when it's not zero,
the GTT tracking simply doesn't work.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oops, makes testing early boot failures in i915.ko a bit more pain, so
let's fix it.
v2: We already have a bit of static storage to track this (Chris).
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gcc complains that:
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’:
drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ‘val’ was declared here
but it can't see that we're going to use val only in the success case.
So shut it up.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to
commit fdbc3b1f63
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Nov 12 17:10:13 2013 +0200
drm/i915/dp: set sink to power down mode on dp disable
but for DDI, where we've never done this.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
airlied:
The lifetime changes introduced in 5bdebb183c
tried to use device_create, however that led to the regression where dev->type
wasn't getting set correctly. First attempt at fixing it would have led to
a race, so this undoes the device_createa work and does it all manually
making sure the dev->type is setup before we register the device.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch releases a vma object when cleaning up userptr resources.
A new vma object was allocated and copied when getting userptr pages
so the new vma object should be freed properly if the userptr pages
aren't used anymore.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The set_need_resched() removal fix and yet another fix in
ttm_bo_move_memcpy().
* 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux:
drm/ttm: Remove set_need_resched from the ttm fault handler
drm/ttm: Don't move non-existing data
Dave Airlie