]> git.proxmox.com Git - mirror_ubuntu-bionic-kernel.git/log
mirror_ubuntu-bionic-kernel.git
11 years agodrm/i915: Rename hsw_lp_wm_result to intel_wm_level
Ville Syrjälä [Tue, 6 Aug 2013 19:24:05 +0000 (22:24 +0300)]
drm/i915: Rename hsw_lp_wm_result to intel_wm_level

Let's call hsw_lp_wm_result intel_wm_level from now on and move it to
i915_drv.h for later use.

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>
11 years agodrm/i915: Pull watermark level validity check out
Ville Syrjälä [Wed, 7 Aug 2013 10:24:47 +0000 (13:24 +0300)]
drm/i915: Pull watermark level validity check out

Refactor the code a bit to split the watermark level validity check into
a separate function.

Also add hack there that allows us to use it even for LP0 watermarks.
ATM we don't pre-compute/check the LP0 watermarks, so we just have to
clamp them to the maximum and hope things work out.

v2: Add some debug prints when we exceed max WM0
    Kill pointless ret = false' assignment.
    Include the check for the already disabled 'result' which
    got shuffled around when the patchs got reorderd

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>
11 years agodrm/i915: Add vma to list at creation
Ben Widawsky [Thu, 1 Aug 2013 00:00:16 +0000 (17:00 -0700)]
drm/i915: Add vma to list at creation

With the current code there shouldn't be a distinction - however with an
upcoming change we intend to allocate a vma much earlier, before it's
actually bound anywhere.

To do this we have to check node allocation as well for the _bound()
check.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: move list_del(&vma->vma_link) from vma_unbind to vma_destroy,
again fallout from the loss of "rm/i915: Cleanup more of VMA in
destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fixup for drm/i915: Add vma to list at creation

11 years agodrm/i915: Update error capture for VMs
Ben Widawsky [Thu, 1 Aug 2013 00:00:15 +0000 (17:00 -0700)]
drm/i915: Update error capture for VMs

formerly: "drm/i915: Create VMAs (part 4) - Error capture"

Since the active/inactive lists are per VM, we need to modify the error
capture code to be aware of this, and also extend it to capture the
buffers from all the VMs. For now all the code assumes only 1 VM, but it
will become more generic over the next few patches.

NOTE: If the number of VMs in a real world system grows significantly
we'll have to focus on only capturing the guilty VM, or else it's likely
there won't be enough space for error capture.

v2: Squashed in the "part 6" which had dependencies on the mm_list
change. Since I've moved the mm_list change to an earlier point in the
series, we were able to accomplish it here and now.

v3: Rebased over new error capture

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: mm_list is per VMA
Ben Widawsky [Thu, 1 Aug 2013 00:00:14 +0000 (17:00 -0700)]
drm/i915: mm_list is per VMA

formerly: "drm/i915: Create VMAs (part 5) - move mm_list"

The mm_list is used for the active/inactive LRUs. Since those LRUs are
per address space, the link should be per VMx .

Because we'll only ever have 1 VMA before this point, it's not incorrect
to defer this change until this point in the patch series, and doing it
here makes the change much easier to understand.

Shamelessly manipulated out of Daniel:
"active/inactive stuff is used by eviction when we run out of address
space, so needs to be per-vma and per-address space. Bound/unbound otoh
is used by the shrinker which only cares about the amount of memory used
and not one bit about in which address space this memory is all used in.
Of course to actual kick out an object we need to unbind it from every
address space, but for that we have the per-object list of vmas."

v2: only bump GGTT LRU in i915_gem_object_set_to_gtt_domain (Chris)

v3: Moved earlier in the series

v4: Add dropped message from v3

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Frob patch to apply and use vma->node.size directly as
discused with Ben. Also drop a needles BUG_ON before move_to_inactive,
the function itself has the same check.]
[danvet 2nd: Rebase on top of the lost "drm/i915: Cleanup more of VMA
in destroy", specifically unlink the vma from the mm_list in
vma_unbind (to keep it symmetric with bind_to_vm) instead of
vma_destroy.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Fix up map and fenceable for VMA
Ben Widawsky [Thu, 1 Aug 2013 00:00:13 +0000 (17:00 -0700)]
drm/i915: Fix up map and fenceable for VMA

formerly: "drm/i915: Create VMAs (part 3.5) - map and fenceable
tracking"

The map_and_fenceable tracking is per object. GTT mapping, and fences
only apply to global GTT. As such,  object operations which are not
performed on the global GTT should not effect mappable or fenceable
characteristics.

Functionally, this commit could very well be squashed in to a previous
patch which updated object operations to take a VM argument.  This
commit is split out because it's a bit tricky (or at least it was for
me).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Drop the bogus hunk in i915_vma_unbind as discussed with
Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Silence a sparse warning
Ville Syrjälä [Wed, 7 Aug 2013 12:11:52 +0000 (15:11 +0300)]
drm/i915: Silence a sparse warning

drivers/gpu/drm/i915/i915_debugfs.c:2136:3: warning: symbol
'i915_debugfs_files' was not declared. Should it be static?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Rename hsw_data_buf_partitioning to intel_ddb_partitioning
Ville Syrjälä [Tue, 6 Aug 2013 19:24:04 +0000 (22:24 +0300)]
drm/i915: Rename hsw_data_buf_partitioning to intel_ddb_partitioning

We're going to use the 1/2 vs. 5/6 split option already on IVB so the
HSW name is not proper. Just give it an intel_ prefix and move it to
i915_drv.h so that we can use it there later.

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>
11 years agodrm/i915: Kill fbc_enable from hsw_lp_wm_results
Ville Syrjälä [Tue, 6 Aug 2013 19:24:03 +0000 (22:24 +0300)]
drm/i915: Kill fbc_enable from hsw_lp_wm_results

We don't need to store the FBC WM enabled status in each watermark
level. We anyway have to reduce it down to a single boolean, so just
delay checking the FBC WM limit until we're computing the final
value.

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>
11 years agodrm/i915: Split watermark level computation from the code
Ville Syrjälä [Tue, 6 Aug 2013 19:24:02 +0000 (22:24 +0300)]
drm/i915: Split watermark level computation from the code

Refactor the watermarks computation for one level to a separate
function. This function will now set the ->enable flag to true,
even if the watermark level wasn't actually checked yet. In the
future we will delay the checking so we must consider all unchecked
watermarks as possibly valid.

v2: Preserve comment about latency units

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>
11 years agodrm/i915: Use 'enabled' instead of 'enable' consistently in sprite WM code
Ville Syrjälä [Tue, 6 Aug 2013 19:24:00 +0000 (22:24 +0300)]
drm/i915: Use 'enabled' instead of 'enable' consistently in sprite WM code

Let's be consistent and always call our variables 'enabled' insted of
the occasional 'enable'.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Spelling fix in the commit message, spotted by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/hmdi: Rename set_infoframe() to write_infoframe()
Damien Lespiau [Tue, 6 Aug 2013 19:32:24 +0000 (20:32 +0100)]
drm/i915/hmdi: Rename set_infoframe() to write_infoframe()

set_frame() wraps the write_frame() vfunc. Be consistent and name the
wrapping function like the vfunc being called.

It's doubly confusing as we also have a set_infoframes() vfunc and
set_infoframe() doesn't wrap it.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm: Set aspect ratio fields in the AVI infoframe even for non CEA modes
Damien Lespiau [Tue, 6 Aug 2013 19:32:23 +0000 (20:32 +0100)]
drm: Set aspect ratio fields in the AVI infoframe even for non CEA modes

I cannot find any evidence what we shouldn't try to set those fields
when setting a non-CEA mode on an HDMI sink. So just kill that return.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm: Handle the DBLCLK flag in the common infoframe helper
Damien Lespiau [Tue, 6 Aug 2013 19:32:22 +0000 (20:32 +0100)]
drm: Handle the DBLCLK flag in the common infoframe helper

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Remove the now obsolete infoframe definitions
Damien Lespiau [Tue, 6 Aug 2013 19:32:21 +0000 (20:32 +0100)]
drm/i915: Remove the now obsolete infoframe definitions

All the HDMI infoframe code has been ported to use video/hdmi.c, so it's
time to say bye bye to this code.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/sdvo: Port the infoframe code to the shared infrastructure
Damien Lespiau [Tue, 6 Aug 2013 19:32:20 +0000 (20:32 +0100)]
drm/i915/sdvo: Port the infoframe code to the shared infrastructure

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/hdmi: Port the infoframe code to the common hdmi helpers
Damien Lespiau [Tue, 6 Aug 2013 19:32:19 +0000 (20:32 +0100)]
drm/i915/hdmi: Port the infoframe code to the common hdmi helpers

Let's use the drivers/video/hmdi.c and drm infoframe helpers to build
our infoframes.

v2: Simplify the logic to compute the buffer size. We can just take the
maximum infoframe size rounded to 32, which happens to be what the
hardware let us write anyway.

v3: Remove unnecessary memset() (Ville Syrjälä)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/hdmi: Change the write_infoframe vfunc to take a buffer and a type
Damien Lespiau [Tue, 6 Aug 2013 19:32:18 +0000 (20:32 +0100)]
drm/i915/hdmi: Change the write_infoframe vfunc to take a buffer and a type

First step in the move to the shared infoframe infrastructure, let's
move the different infoframe helpers and the write_infoframe() vfunc to
a type (enum hdmi_infoframe_type) and a buffer + len instead of using
our struct dip_infoframe.

v2: constify the infoframe pointer and don't mix signs (Ville Syrjälä)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm: Don't generate invalid AVI infoframes for CEA modes
Damien Lespiau [Tue, 6 Aug 2013 19:32:17 +0000 (20:32 +0100)]
drm: Don't generate invalid AVI infoframes for CEA modes

From CEA-861:

  Data Byte 1, bit A0 indicates whether Active Format Data is present in
  Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
  any of the AFD bits are set.

ie. if we want to set active_aspect, we need to set the
active_info_valid bit to 1 as well.

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agovideo/hmdi: Clear the whole incoming buffer, not just the infoframe size
Damien Lespiau [Tue, 6 Aug 2013 19:32:16 +0000 (20:32 +0100)]
video/hmdi: Clear the whole incoming buffer, not just the infoframe size

If the user if this API is providing a bigger buffer than the infoframe
size, it could be for a could reason. For instance it could be because
it gives the buffer that will be written to the hardware, up to the
maximum of an infoframe size.

Instead of just zeroing up to the infoframe size, let's zero the whole
incoming buffer as those extra bytes are also used to compute the
ECC and need to be 0.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agovideo/hdmi: Add a macro to return the size of a full infoframe
Damien Lespiau [Tue, 6 Aug 2013 19:32:15 +0000 (20:32 +0100)]
video/hdmi: Add a macro to return the size of a full infoframe

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agovideo/hdmi: Introduce a generic hdmi_infoframe union
Damien Lespiau [Tue, 6 Aug 2013 19:32:14 +0000 (20:32 +0100)]
video/hdmi: Introduce a generic hdmi_infoframe union

And a way to pack hdmi_infoframe generically.

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agovideo/hdmi: Replace the payload length by their defines
Damien Lespiau [Tue, 6 Aug 2013 19:32:13 +0000 (20:32 +0100)]
video/hdmi: Replace the payload length by their defines

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: turn bound_ggtt checks to bound_any
Ben Widawsky [Thu, 1 Aug 2013 00:00:12 +0000 (17:00 -0700)]
drm/i915: turn bound_ggtt checks to bound_any

In some places, we want to know if an object is bound in any address
space, and not just the global GTT. This often applies when there is a
single global resource (object, pages, etc.)

function                             |      reason
--------------------------------------------------
i915_gem_object_is_inactive          | global object
i915_gem_object_put_pages            | object's pages
915_gem_object_unpin                 | global object
i915_gem_execbuffer_unreserve_object | temporary until we plumb vma
pread/pwrite                         | see the note below

Note: set_to_gtt_domain in pwrite/pread is abused as a wait_rendering
call - but that once only worked if the object is bound. We really
should replace this with a plain wait_rendering call, which would have
the upside that in pread it would be clearer that we actually only
wait for oustanding gpu writes.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Explain the set_to_gtt_domain in pwrite/pread and volunteer
Ben to replace those with wait_rendering calls.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use new bind/unbind in eviction code
Ben Widawsky [Thu, 1 Aug 2013 00:00:11 +0000 (17:00 -0700)]
drm/i915: Use new bind/unbind in eviction code

Eviction code, like the rest of the converted code needs to be aware of
the address space for which it is evicting (or the everything case, all
addresses). With the updated bind/unbind interfaces of the last patch,
we can now safely move the eviction code over.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: plumb VM into bind/unbind code
Ben Widawsky [Thu, 1 Aug 2013 00:00:10 +0000 (17:00 -0700)]
drm/i915: plumb VM into bind/unbind code

As alluded to in several patches, and it will be reiterated later... A
VMA is an abstraction for a GEM BO bound into an address space.
Therefore it stands to reason, that the existing bind, and unbind are
the ones which will be the most impacted. This patch implements this,
and updates all callers which weren't already updated in the series
(because it was too messy).

This patch represents the bulk of an earlier, larger patch. I've pulled
out a bunch of things by the request of Daniel. The history is preserved
for posterity with the email convention of ">" One big change from the
original patch aside from a bunch of cropping is I've created an
i915_vma_unbind() function. That is because we always have the VMA
anyway, and doing an extra lookup is useful. There is a caveat, we
retain an i915_gem_object_ggtt_unbind, for the global cases which might
not talk in VMAs.

> drm/i915: plumb VM into object operations
>
> This patch was formerly known as:
> "drm/i915: Create VMAs (part 3) - plumbing"
>
> This patch adds a VM argument, bind/unbind, and the object
> offset/size/color getters/setters. It preserves the old ggtt helper
> functions because things still need, and will continue to need them.
>
> Some code will still need to be ported over after this.
>
> v2: Fix purge to pick an object and unbind all vmas
> This was doable because of the global bound list change.
>
> v3: With the commit to actually pin/unpin pages in place, there is no
> longer a need to check if unbind succeeded before calling put_pages().
> Make put_pages only BUG() after checking pin count.
>
> v4: Rebased on top of the new hangcheck work by Mika
> plumbed eb_destroy also
> Many checkpatch related fixes
>
> v5: Very large rebase
>
> v6:
> Change BUG_ON to WARN_ON (Daniel)
> Rename vm to ggtt in preallocate stolen, since it is always ggtt when
> dealing with stolen memory. (Daniel)
> list_for_each will short-circuit already (Daniel)
> remove superflous space (Daniel)
> Use per object list of vmas (Daniel)
> Make obj_bound_any() use obj_bound for each vm (Ben)
> s/bind_to_gtt/bind_to_vm/ (Ben)
>
> Fixed up the inactive shrinker. As Daniel noticed the code could
> potentially count the same object multiple times. While it's not
> possible in the current case, since 1 object can only ever be bound into
> 1 address space thus far - we may as well try to get something more
> future proof in place now. With a prep patch before this to switch over
> to using the bound list + inactive check, we're now able to carry that
> forward for every address space an object is bound into.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
in destroy".]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Rework __i915_gem_shrink
Ben Widawsky [Thu, 1 Aug 2013 00:00:01 +0000 (17:00 -0700)]
drm/i915: Rework __i915_gem_shrink

In order to do this for all VMs, it's convenient to rework the logic a
bit. This should have no functional impact.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Improve VMA comments
Ben Widawsky [Thu, 1 Aug 2013 00:00:08 +0000 (17:00 -0700)]
drm/i915: Improve VMA comments

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Export intel_framebuffer_fini
Chris Wilson [Tue, 6 Aug 2013 16:43:07 +0000 (17:43 +0100)]
drm/i915: Export intel_framebuffer_fini

Rather than open-code the teardown of a framebuffer, export the routine
from intel_display.c. This then make intel_fbdev symmetric in its use of
the common intel_framebuffer routines to initialise and clean up the
struct intel_framebuffer. (And new features need only be added in one
location!)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Rename I915_CACHE_MLC_LLC to L3_LLC for Ivybridge
Chris Wilson [Tue, 6 Aug 2013 12:17:02 +0000 (13:17 +0100)]
drm/i915: Rename I915_CACHE_MLC_LLC to L3_LLC for Ivybridge

MLC_LLC was never validated for Sandybridge and was superseded by a new
level of cacheing for the GPU in Ivybridge. Update our names to be
consistent with usage, and in the process stop setting the unwanted bit
on Sandybridge.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/BUG/WARN_ON(1) bikeshed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: remove use_fdi_mode argument from intel_prepare_ddi_buffers
Paulo Zanoni [Mon, 5 Aug 2013 20:25:56 +0000 (17:25 -0300)]
drm/i915: remove use_fdi_mode argument from intel_prepare_ddi_buffers

We set the mode based on the port, and we already pass the port as an
argument.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: silence useless messages about DDI buffer translation
Paulo Zanoni [Mon, 5 Aug 2013 20:25:55 +0000 (17:25 -0300)]
drm/i915: silence useless messages about DDI buffer translation

These messages are not really useful since it's very easy to check
which mode is used for each port: The values programmed are based on
the port type, then assigned to the ddi_translations variable.
Currently we use DP mode for ports A-D and FDI mode for port E.

Also, when we add the code to enable/disable PC8+,
intel_prepare_ddi_buffers will be called more often and will eat your
dmesg buffers.

While at it, fix the coding style of the "for" statement above.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Pimp commit message with Paulo's more detailed explanation of
how the ddi translation buffer settings are computed, to answer a
question from Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: eliminate dead domain clearing on reset
Ben Widawsky [Mon, 5 Aug 2013 16:46:44 +0000 (09:46 -0700)]
drm/i915: eliminate dead domain clearing on reset

The code itself is no longer accurate without updating once we have
multiple address space since clearing the domains of every object
requires scanning the inactive list for all VMs.

"This code is dead. Just remove it rather than port it to vma." - Chris
Wilson

Recommended-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Add comments about units of latency values
Ville Syrjälä [Thu, 1 Aug 2013 13:18:55 +0000 (16:18 +0300)]
drm/i915: Add comments about units of latency values

All the ILK+ WM compute functions take the latency values in 0.1us
units. Add a few comments to remind people about that.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use the watermark latency values from dev_priv for ILK/SNB/IVB too
Ville Syrjälä [Thu, 1 Aug 2013 13:18:54 +0000 (16:18 +0300)]
drm/i915: Use the watermark latency values from dev_priv for ILK/SNB/IVB too

Adjust the current ILK/SNB/IVB watermark codepaths to use the
pre-populated latency values from dev_priv instead of reading
them out from the registers every time.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Disable specific watermark levels when latency is zero
Ville Syrjälä [Thu, 1 Aug 2013 13:18:53 +0000 (16:18 +0300)]
drm/i915: Disable specific watermark levels when latency is zero

Return UINT_MAX for the calculated WM level if the latency is zero.
This will lead to marking the WM level as disabled.

I'm not sure if latency==0 should mean that we want to disable the
level. But that's the implication I got from the fact that we don't
even enable the watermark code of the SSKDP register is 0.

v2: Use WARN() to scare people

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Print the watermark latencies during init
Ville Syrjälä [Thu, 1 Aug 2013 13:18:52 +0000 (16:18 +0300)]
drm/i915: Print the watermark latencies during init

Seeing the watermark latency values in dmesg might help sometimes.

v2: Use DRM_ERROR() when expected latency values are missing

Note: We might hit the DRM_ERROR added in this patch and apparently
there's not much we can do about that. But I think it'd be interesting
to figure out whether that actually happens in the real world, so I
didn't apply a s/DRM_ERROR/DRM_DEBUG_KMS/ bikeshed while applying.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add note about new error dmesg output.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use the stored cursor and plane latencies properly
Ville Syrjälä [Thu, 1 Aug 2013 13:18:51 +0000 (16:18 +0300)]
drm/i915: Use the stored cursor and plane latencies properly

Rather than pass around the plane latencies, just grab them from
dev_priv nearer to where they're needed. Do the same for cursor
latencies.

v2: Add some comments about latency units

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Store the watermark latency values in dev_priv
Ville Syrjälä [Thu, 1 Aug 2013 13:18:50 +0000 (16:18 +0300)]
drm/i915: Store the watermark latency values in dev_priv

Rather than having to read the latency values out every time, just
store them in dev_priv.

On ILK and IVB there is a difference between some of the latency
values for different planes, so store the latency values for each
plane type separately, and apply the necesary fixups during init.

v2: Fix some checkpatch complaints

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Add ILK support to intel_read_wm_latency
Ville Syrjälä [Thu, 1 Aug 2013 13:18:49 +0000 (16:18 +0300)]
drm/i915: Add ILK support to intel_read_wm_latency

ILK has a slightly different way to read out the watermark
latency values. On ILK the LP0 latenciy values are in fact
not stored in any register, and instead we must use fixed
values.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: make reset&hangcheck code VM aware
Ben Widawsky [Thu, 1 Aug 2013 00:00:05 +0000 (17:00 -0700)]
drm/i915: make reset&hangcheck code VM aware

Hangcheck, and some of the recent reset code for guilty batches need to
know which address space the object was in at the time of a hangcheck.
This is because we use offsets in the (PP|G)GTT to determine this
information, and those offsets can differ depending on which VM they are
bound into.

Since we still only have 1 VM ever, this code shouldn't yet have any
impact.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: BUG_ON put_pages later
Ben Widawsky [Thu, 1 Aug 2013 00:00:04 +0000 (17:00 -0700)]
drm/i915: BUG_ON put_pages later

With multiple VMs, the eviction code benefits from being able to blindly
put pages without needing to know if there are any entities still
holding on to those pages. As such it's preferable to return the -EBUSY
before the BUG.

Eviction code is the only user for now, but overall it makes sense
anyway, IMO.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: make caching operate on all address spaces
Ben Widawsky [Thu, 1 Aug 2013 00:00:03 +0000 (17:00 -0700)]
drm/i915: make caching operate on all address spaces

For now, objects will maintain the same cache levels amongst all address
spaces. This is to limit the risk of bugs, as playing with cacheability
in the different domains can be very error prone.

In the future, it may be optimal to allow setting domains per VMA (ie.
an object bound into an address space).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: thread address space through execbuf
Ben Widawsky [Thu, 1 Aug 2013 00:00:02 +0000 (17:00 -0700)]
drm/i915: thread address space through execbuf

This represents the first half of hooking up VMs to execbuf. Here we
basically pass an address space all around to the different internal
functions. It should be much more readable, and have less risk than the
second half, which begins switching over to using VMAs instead of an
obj,vm.

The overall series echoes this style of, "add a VM, then make it smart
later"

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Switch a BUG_ON to WARN_ON.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Update describe_obj
Ben Widawsky [Thu, 1 Aug 2013 00:00:00 +0000 (17:00 -0700)]
drm/i915: Update describe_obj

Make it aware of which domain it is bound into GGTT, or PPGTT.

While modifying the function, add a global gtt flag to the object
description. Global is more interesting than aliasing since aliasing is
the default.

v2: Access VMA directly for start/size instead of helpers (Daniel)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use ggtt_vm to save some typing
Ben Widawsky [Wed, 31 Jul 2013 23:59:59 +0000 (16:59 -0700)]
drm/i915: Use ggtt_vm to save some typing

Just some small cleanups, and a rename of vm->ggtt_vm requested by
Daniel.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Add VM to pin
Ben Widawsky [Wed, 31 Jul 2013 23:59:58 +0000 (16:59 -0700)]
drm/i915: Add VM to pin

To verbalize it, one can say, "pin an object into the given address
space." The semantics of pinning remain the same otherwise.

Certain objects will always have to be bound into the global GTT.
Therefore, global GTT is a special case, and keep a special interface
around for it (i915_gem_obj_ggtt_pin).

v2: s/i915_gem_ggtt_pin/i915_gem_obj_ggtt_pin

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use bound list for inactive shrink
Ben Widawsky [Wed, 31 Jul 2013 23:59:57 +0000 (16:59 -0700)]
drm/i915: Use bound list for inactive shrink

Do to the move active/inactive lists, it no longer makes sense to use
them for shrinking, since shrinking isn't VM specific (such a need may
also exist, but doesn't yet).

What we can do instead is use the global bound list to find all objects
which aren't active.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Make proper functions for VMs
Ben Widawsky [Wed, 31 Jul 2013 23:59:56 +0000 (16:59 -0700)]
drm/i915: Make proper functions for VMs

Earlier in the conversion sequence we attempted to quickly wedge in the
transitional interface as static inlines.

Now that we're sure these interfaces are sane, for easier debug and to
decrease code size (since many of these functions may be called quite a
bit), make them real functions

While at it, kill off the set_color interface. We'll always have the
VMA, or easily get to it.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Rework drop caches for checkpatch
Ben Widawsky [Wed, 31 Jul 2013 23:59:55 +0000 (16:59 -0700)]
drm/i915: Rework drop caches for checkpatch

With an upcoming change to bind, to make checkpatch happy and keep the
code clean, we need to rework this code a bit.

This should have no functional impact.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add the newline Chris requested.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Create an init vm
Ben Widawsky [Wed, 31 Jul 2013 23:59:54 +0000 (16:59 -0700)]
drm/i915: Create an init vm

Move all the similar address space (VM) initialization code to one
function. Until we have multiple VMs, there should only ever be 1 VM.
The aliasing ppgtt is a special case without it's own VM (since it
doesn't need it's own address space management).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/hsw: Change default LLC age to 3
Ben Widawsky [Mon, 5 Aug 2013 06:47:29 +0000 (23:47 -0700)]
drm/i915/hsw: Change default LLC age to 3

The default LLC age was changed:
commit 0d8ff15e9a15f2b393e53337a107b7a1e5919b6d
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Thu Jul 4 11:02:03 2013 -0700

drm/i915/hsw: Set correct Haswell PTE encodings.

On the surface it would seem setting a default age wouldn't matter
because all GEM BOs are aged similarly, so the order in which objects
are evicted would not be subject to aging. The current working theory as
to why this caused a regression though is that LLC is a bit special in
that it is shared with the CPU. Presumably (not verified) the CPU
fetches cachelines with age 3, and therefore recently cached GPU objects
would be evicted before similar CPU object first when the LLC is full.
It stands to reason therefore that this would negatively impact CPU
bound benchmarks - but those seem to be low on the priority list.

eLLC OTOH does not have this same property as LLC. It should be used
entirely for the GPU, and so the age really shouldn't matter.
Furthermore, we have no evidence to suggest one is better than another
on eLLC. Since we've never properly supported eLLC before no, there
should be no regression. If the GPU client really wants "younger"
objects, they should use MOCS.

v2: Drop the extra #define (Chad)

v3: Actually git add

v4: Pimped commit message

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67062
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agoi915: fix ACPI _DSM warning
Peter Wu [Thu, 1 Aug 2013 16:21:28 +0000 (18:21 +0200)]
i915: fix ACPI _DSM warning

Since commit 29a241c (ACPICA: Add argument typechecking for all
predefined ACPI names), _DSM parameters are validated which trigger the
following warning:

    ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
    ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)

As the Intel _DSM method seems to ignore this parameter, let's comply to
the ACPI spec and use a Package instead.

Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32602
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: make user mode sync polarity setting explicit
Imre Deak [Tue, 30 Jul 2013 10:36:32 +0000 (13:36 +0300)]
drm/i915: make user mode sync polarity setting explicit

Userspace can pass a mode with an unspecified vsync/hsync polarity
setting. All encoders in the Intel driver take this to mean a negative
polarity setting. The HW readout/state checker code on the other hand
needs these flags to be explicitly set, otherwise the state checker will
WARN about the mismatch.

Get rid of the WARN by making the polarity setting explicit in the
adjusted mode flags based on the requested mode flags. This will keep
the existing behavior otherwise.

Note that we could guess from the other timing parameters whether the
user wanted a VESA or other standard mode and set the polarity
accordingly. This is what the NV driver does
(drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
exact and would change the existing behavior of the Intel driver.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: cancan,feng <cancan.feng@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: move encoder->enable callback later in VLV crtc enable
Jani Nikula [Tue, 30 Jul 2013 09:20:32 +0000 (12:20 +0300)]
drm/i915: move encoder->enable callback later in VLV crtc enable

VLV wants encoder enabling before the pipe is up. With the previously
rearranged VLV DP and HDMI ->pre_enable and ->enable callbacks in place,
this no longer depends on the early ->enable hook call. Move the
->enable call at the end of the sequence, similar to the crtc enable on
other platforms. This will be needed e.g. for moving the eDP backlight
enabling to the right place in the sequence, currently done too early on
VLV.

There should be no functional changes.

v2: Rebase.

v3: Explain why this is needed in the commit message (Chris).

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: rearrange vlv hdmi enable and pre_enable callbacks
Jani Nikula [Tue, 30 Jul 2013 09:20:31 +0000 (12:20 +0300)]
drm/i915: rearrange vlv hdmi enable and pre_enable callbacks

VLV wants encoder enabling before the pipe is up. This is currently
achieved through calling the ->enable callback early, right after the
->pre_enable callback, in valleyview_crtc_enable(). This loses both the
distinction between ->pre_enable and ->enable on VLV and the possibility
to use a hook at the end of the modeset sequence.

Rearrange the HDMI callbacks to make it possible to move ->enable call
later. Basically do everything in ->pre_enable on VLV, and make ->enable
a NOP.

There should be no functional changes.

v2: Rebase.

v3: Explain why this is needed in the commit message (Chris).

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: rearrange vlv dp enable and pre_enable callbacks
Jani Nikula [Tue, 30 Jul 2013 09:20:30 +0000 (12:20 +0300)]
drm/i915: rearrange vlv dp enable and pre_enable callbacks

VLV wants encoder enabling before the pipe is up. This is currently
achieved through calling the ->enable callback early, right after the
->pre_enable callback, in valleyview_crtc_enable(). This loses both the
distinction between ->pre_enable and ->enable on VLV and the possibility
to use a hook at the end of the modeset sequence.

Rearrange the DP callbacks to make it possible to move ->enable call
later. Basically do everything in ->pre_enable on VLV, and make ->enable
a NOP.

There should be no functional changes.

v2: Rebase.

v3: Explain why this is needed in the commit message (Chris).

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMI
Chris Wilson [Fri, 26 Jul 2013 18:57:35 +0000 (19:57 +0100)]
drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMI

Otherwise we get flooded by the kernel warning us that we are doing
long sequences of IO without serialisation. For example,

 WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef()
 Modules linked in:
 CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G        W    3.11.0-rc2+ #4
 Call Trace:
  [<c2028564>] ?  warn_slowpath_common+0x63/0x78
  [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
  [<c20285dd>] ?  warn_slowpath_null+0xf/0x13
  [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
  [<c227b060>] ?  vlv_dpio_write+0x1c/0x21
  [<c2262b3b>] ?  intel_dp_set_signal_levels+0x24a/0x385
  [<c2264909>] ?  intel_dp_complete_link_train+0x25/0x1d1
  [<c2264c55>] ?  intel_dp_check_link_status+0xf7/0x106
  [<c2238ced>] ?  i915_hotplug_work_func+0x17b/0x221
  [<c203a204>] ?  process_one_work+0x12e/0x210
  [<c203a5e4>] ?  worker_thread+0x116/0x1ad
  [<c203a4ce>] ?  rescuer_thread+0x1cb/0x1cb
  [<c203d8f5>] ?  kthread+0x67/0x6c
  [<c2457ebb>] ?  ret_from_kernel_thread+0x1b/0x30
  [<c203d88e>] ?  init_completion+0x18/0x18

v2: Retire the locking in vlv_crtc_enable() and do it close to the meat.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Squash in a s/mutex_lock/mutex_unlock/ fixup spotted by the 0
day kernel build/coccinelle and reported by Dan Carpenter.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: enable IPS for bpp <= 24
Jesse Barnes [Thu, 25 Jul 2013 17:06:50 +0000 (10:06 -0700)]
drm/i915: enable IPS for bpp <= 24

Art confirms that this should work fine.  Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Add SNB/IVB support to intel_read_wm_latency
Ville Syrjälä [Fri, 5 Jul 2013 08:57:23 +0000 (11:57 +0300)]
drm/i915: Add SNB/IVB support to intel_read_wm_latency

SNB and IVB have slightly a different way to read out the
watermark latency values.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Don't multiply the watermark latency values too early
Ville Syrjälä [Fri, 5 Jul 2013 08:57:22 +0000 (11:57 +0300)]
drm/i915: Don't multiply the watermark latency values too early

The LP1+ watermark latency values need to be multiplied by 5 to
make them suitable for watermark calculations. However on pre-HSW
platforms we're going to need the raw value later when we have to
write it to the WM_LPn registers' latency field. So delay the
multiplication until it's needed.

Note: Paulo complains that the units of wm (now in 100ns) aren't
really clear and I agree. But that can be fixed later on ...

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add a comment about the unit obfuscation.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Split out reading of HSW watermark latency values
Ville Syrjälä [Fri, 5 Jul 2013 08:57:21 +0000 (11:57 +0300)]
drm/i915: Split out reading of HSW watermark latency values

Move parsing of MCH_SSKPD to a separate function, we'll add other
platforms there later.

Note: Chris spotted an empty struct initializer and wondered whether
that is hiding a compilier warning. Ville explained that it should
have been part of the patch that extends this function to snb/ivb,
which don't have all levels hsw has. I've figured it's ok to keep it
here with a small note.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add note about the ominous struct initializer.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Change the watermark latency type to uint16_t
Ville Syrjälä [Fri, 5 Jul 2013 08:57:20 +0000 (11:57 +0300)]
drm/i915: Change the watermark latency type to uint16_t

The latency values fit in uint16_t, so let's save a few bytes.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Don't pass "mem_value" to ilk_compute_fbc_wm
Ville Syrjälä [Fri, 5 Jul 2013 08:57:19 +0000 (11:57 +0300)]
drm/i915: Don't pass "mem_value" to ilk_compute_fbc_wm

The FBC watermark doesn't depend on the latency value, so no point in
passing it in.

Note: It actually depends upon the latency, but only through priv_val
...

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add review comment from Paulo to the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Rename most wm compute functions to ilk_ prefix
Ville Syrjälä [Fri, 5 Jul 2013 08:57:17 +0000 (11:57 +0300)]
drm/i915: Rename most wm compute functions to ilk_ prefix

These functions are appropriate for everything since ILK.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Rename hsw_wm_get_pixel_rate to ilk_pipe_pixel_rate
Ville Syrjälä [Fri, 5 Jul 2013 08:57:16 +0000 (11:57 +0300)]
drm/i915: Rename hsw_wm_get_pixel_rate to ilk_pipe_pixel_rate

hsw_wm_get_pixel_rate() isn't specific to HSW. In fact it should be made
to handle all gens, but for now it depends on the PCH panel fitter
state, so give it an ilk_ prefix.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Calculate the sprite WM based on the source width instead of the destinatio...
Ville Syrjälä [Fri, 5 Jul 2013 08:57:15 +0000 (11:57 +0300)]
drm/i915: Calculate the sprite WM based on the source width instead of the destination width

Using the destination width in the sprite WM calculations isn't correct.
We should be using the source width.

Note: This doesn't affect hsw since it does not support sprite
scaling.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add review note from Paulo to the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Pass the actual sprite width to watermarks functions
Ville Syrjälä [Fri, 5 Jul 2013 08:57:14 +0000 (11:57 +0300)]
drm/i915: Pass the actual sprite width to watermarks functions

Don't subtract one from the sprite width before watermark calculations.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Add scaled paramater to update_sprite_watermarks()
Ville Syrjälä [Fri, 5 Jul 2013 08:57:13 +0000 (11:57 +0300)]
drm/i915: Add scaled paramater to update_sprite_watermarks()

For calculating watermarks we want to know whether sprites are
scaled. Pass that information to update_sprite_watermarks() so that
eventually we may do some watermark pre-computing.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Tidy the macro casting by using an inline function
Chris Wilson [Thu, 1 Aug 2013 17:39:55 +0000 (18:39 +0100)]
drm/i915: Tidy the macro casting by using an inline function

Some of our macros we trying to convert from an drm_device to a
drm_i915_private and then use the pointer inline. This is not only
cumbersome but prone to error. Replacing it with a typesafe function
should help catch those errors in future.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Squash in fixup to correctly order static vs. inline
qualifiers, static comes first. Also fix up another offender.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Remove useless define
Stéphane Marchesin [Wed, 31 Jul 2013 07:11:07 +0000 (00:11 -0700)]
drm/i915: Remove useless define

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use the same pte_encoding for ppgtt as for gtt
Chris Wilson [Tue, 30 Jul 2013 18:04:37 +0000 (19:04 +0100)]
drm/i915: Use the same pte_encoding for ppgtt as for gtt

The PTE layouts are the same for both ppgtt and gtt, so we can simplify
the setup for ppgtt by copying the encoding function pointer from gtt.
This prevents bugs where we update one function pointer, but forget the
other.

For instance,

commit 4d15c145a6234d999c0452eec0d275c1fbf0688c
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Jul 4 11:02:06 2013 -0700

    drm/i915: Use eLLC/LLC by default when available

only extends the gtt to use eLLC/LLC cacheing and forgets to also update
the ppgtt function pointer.

v2: Actually mention the bug being fixed (Kenneth)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Squelch repeated reasoning for why FBC cannot be activated
Chris Wilson [Sat, 27 Jul 2013 16:23:55 +0000 (17:23 +0100)]
drm/i915: Squelch repeated reasoning for why FBC cannot be activated

Almost invariably the reason why FBC cannot be turned on is the same
every time (disabled via parameter, too many pipes, pipe too large etc)
as modesetting and framebuffer configuration changes less frequently
than trying to enable FBC.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: clean up crtc timings computation
Daniel Vetter [Sun, 21 Jul 2013 19:37:09 +0000 (21:37 +0200)]
drm/i915: clean up crtc timings computation

In the old days of the crtc helpers we've only had the encoder and
crtc ->mode_fixup callbacks. So when the lvds connector wanted to
adjust the crtc timings it had to set a driver-private mode flag to
tell the crtc mode fixup code to not overwrite them with the generic
ones.

When converting things to the new infrastructure I've kept the entire
logic and only moved the flag to pipe_config->timings_set. But this
logic is pretty tricky and already caused regressions:

commit 21d8a4756af5fdf4a42e79a77cf3b6f52678d443
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jul 12 08:07:30 2013 +0200

    drm/i915: fix pfit regression for non-autoscaled resolutions

So take advantage of the flexibility our own modeset infrastructure
affords us and prefill default crtc timings. This allows us to rip out
->timings_set. Note that we overwrite things again when retrying the
pipe config computation due to bandwidth constraints to avoid bogus
crtc timings if the encoder only does relative adjustments (which is
how the pfit code works). Only a theoretical concern though since
platforms where we retry (pch-split platforms) do not need
adjustements (since only the old gmch pfit needs that). But let's
better be safe than sorry.

Since we now initialize the crtc timings before calling the
encoder->compute_config functions the crtc initialization in the gmch
pfit code is now redudant and so can be removed.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add a paragraph to the commit message to explain why we can
ditch the crtc timings initialization call from the gmch pfit code, to
answer a question from Rodrigo's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: rip out legacy encoder->mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:08 +0000 (21:37 +0200)]
drm/i915: rip out legacy encoder->mode_set callback

The encoder->mode_set callback from the crtc helpers is now completely
unused in our driver. Good riddance!

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/ddi: use the native encoder ->mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:07 +0000 (21:37 +0200)]
drm/i915/ddi: use the native encoder ->mode_set callback

Same conversion as for hdmi/dp.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/lvds: use the native encoder ->mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:06 +0000 (21:37 +0200)]
drm/i915/lvds: use the native encoder ->mode_set callback

Does nothing, so trivial conversion. But update the outdated comment
while at it.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/dp: use native encoder ->mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:05 +0000 (21:37 +0200)]
drm/i915/dp: use native encoder ->mode_set callback

Usual drill applies. Again I've not switched the upcast helpers to use
intel_encoder instead of drm_encoder since that's much more invasive
and will change also the hdmi and ddi encoders.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/hdmi: use native encoder mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:04 +0000 (21:37 +0200)]
drm/i915/hdmi: use native encoder mode_set callback

Again drop the intel_ prefix from the intel_crtc local variable to
save a bit of space. But here I didn't switch the upcast macros to
intel_encoder since all our infoframe interfaces still use
drm_encoder. That needs to be changed first.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/crt: use native encoder->mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:03 +0000 (21:37 +0200)]
drm/i915/crt: use native encoder->mode_set callback

Also drop the intel_ prefix from the local intel_crtc variable and
reorder the upcast macros a bit for more reuse.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/tv: Use native encoder->mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:02 +0000 (21:37 +0200)]
drm/i915/tv: Use native encoder->mode_set callback

Also switch to intel_encoder for the upcast helper while at it.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/sdvo: use intel_encoder for upcast helper
Daniel Vetter [Sun, 21 Jul 2013 19:37:01 +0000 (21:37 +0200)]
drm/i915/sdvo: use intel_encoder for upcast helper

It's what all callers (except for the destroy callback which is called
from drm core) actually want.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/dvo: use native encoder ->mode_set callback
Daniel Vetter [Sun, 21 Jul 2013 19:37:00 +0000 (21:37 +0200)]
drm/i915/dvo: use native encoder ->mode_set callback

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: rip out legacy encoder->mode_fixup logic
Daniel Vetter [Sun, 21 Jul 2013 19:36:59 +0000 (21:36 +0200)]
drm/i915: rip out legacy encoder->mode_fixup logic

Everyone is now using our own ->compute_config callback, which means
we can now also make that callback mandatory.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/dvo: switch ->mode_fixup to ->compute_config
Daniel Vetter [Sun, 21 Jul 2013 19:36:58 +0000 (21:36 +0200)]
drm/i915/dvo: switch ->mode_fixup to ->compute_config

This is the last encoder ->mode_fixup callback we have left, so
convert it.

Note that we want to only rip out the encoder->mode_fixup callback.
But we still have the dvo_slave->mode_fixup callback. dvo is gen2
only, so we won't ever touch this again. Hence why I didn't go through
all 6-7 dvo slave drivers and give them the same treatment. I'll add a
note to the commit message about this when merging, presuming there's
nothing else in the patch that needs to be fixed up.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add note about why we keep the dvo->mode_fixup callback to
answer a question from Rodrigo's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915/dvo: use intel_encoder to the upcast macro
Daniel Vetter [Sun, 21 Jul 2013 19:36:57 +0000 (21:36 +0200)]
drm/i915/dvo: use intel_encoder to the upcast macro

More natural and will soon be even better!

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Do not dereference NULL crtc or fb until after checking
Chris Wilson [Fri, 2 Aug 2013 19:39:49 +0000 (20:39 +0100)]
drm/i915: Do not dereference NULL crtc or fb until after checking

Fixes regression from
commit 4906557eb37b7fef84fad4304acef6dedf919880
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Thu Jul 11 18:45:05 2013 -0300

    drm/i915: Hook PSR functionality

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67526
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: fix pnv display core clock readout out
Daniel Vetter [Fri, 26 Jul 2013 06:35:42 +0000 (08:35 +0200)]
drm/i915: fix pnv display core clock readout out

We need the correct clock to accurately assess whether we need to
enable the double wide pipe mode or not.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Stuart Abercrombie <sabercrombie@google.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Replace open-coded offset_in_page()
Chris Wilson [Sun, 21 Jul 2013 16:23:11 +0000 (17:23 +0100)]
drm/i915: Replace open-coded offset_in_page()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Retry DP aux_ch communications with a different clock after failure
Chris Wilson [Sun, 21 Jul 2013 15:00:03 +0000 (16:00 +0100)]
drm/i915: Retry DP aux_ch communications with a different clock after failure

The w/a db makes the recommendation to both use a non-default value for
the initial clock and then to retry with an alternative clock for
Haswell with the Lakeport PCH.

"On LPT:H, use a divider value of 63 decimal (03Fh). If there is a
failure, retry at least three times with 63, then retry at least three
times with 72 decimal (048h)."

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Add messages useful for HPD storm detection debugging (v2)
Egbert Eich [Fri, 26 Jul 2013 12:14:24 +0000 (14:14 +0200)]
drm/i915: Add messages useful for HPD storm detection debugging (v2)

For HPD storm detection we now mask out individual interrupt source
bits. We have already seen a case where HPD interrupt enable bits
were assigned to the wrong pins. To track these conditions more
easily add some debugging messages.

v2: Spelling fixes as suggested by Jani Nikula <jani.nikula@linux.intel.com>

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: dvo_ch7xxx: fix vsync polarity setting
Imre Deak [Thu, 25 Jul 2013 13:22:31 +0000 (16:22 +0300)]
drm/i915: dvo_ch7xxx: fix vsync polarity setting

This fixes a typo which set the wrong vsync and possibly also hsync
polarity for any modes with positive vsync polarity.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: fix the racy object accounting
Daniel Vetter [Wed, 24 Jul 2013 20:40:23 +0000 (22:40 +0200)]
drm/i915: fix the racy object accounting

Just use a spinlock to protect them.

v2: Rebase onto the new object create refcount fix patch.

v3: Don't kill dev_priv->mm.object_memory as requested by Chris and
hence just use a spinlock instead of atomic_t.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67287
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Convert the register access tracepoint to be conditional
Chris Wilson [Fri, 19 Jul 2013 19:36:56 +0000 (20:36 +0100)]
drm/i915: Convert the register access tracepoint to be conditional

The TRACE_EVENT_CONDITION is supposed to generate more efficient code
than if (cond) trace(), which is what we are currently using inside the
register access functions.

v2: Rebase onto uncore

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Squash gen lookup through multiple indirections inside GT access
Chris Wilson [Fri, 19 Jul 2013 19:36:55 +0000 (20:36 +0100)]
drm/i915: Squash gen lookup through multiple indirections inside GT access

The INTEL_INFO() macro extracts the dev_private pointer from the device,
so passing in the dev_private->dev is a long winded circumlocution.

v2: rebase onto uncore

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use the common register access functions for NOTRACE variants
Chris Wilson [Fri, 19 Jul 2013 19:36:54 +0000 (20:36 +0100)]
drm/i915: Use the common register access functions for NOTRACE variants

Detangle the confusion that NOTRACE variants of the register read/write
routines were directly using the raw register access. We need for those
routines to reuse the common code for serializing register access and
ensuring the correct register power states. This is only possible now
that the only routines that required raw access use their own API.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Use a private interface for register access within GT
Chris Wilson [Fri, 19 Jul 2013 19:36:53 +0000 (20:36 +0100)]
drm/i915: Use a private interface for register access within GT

The GT functions for enabling register access also need to occasionally
write to and read from registers. To avoid the potential recursion as we
modify the public interface to be stricter, introduce a private register
access API for the GT functions.

v2: Rebase
v3: Rebase onto uncore
v4: Use raw interfaces consistently so that we only use the low-level
    readN functions from a single location.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: Colocate all GT access routines in the same file
Chris Wilson [Fri, 19 Jul 2013 19:36:52 +0000 (20:36 +0100)]
drm/i915: Colocate all GT access routines in the same file

Currently, the register access code is split between i915_drv.c and
intel_pm.c. It only bares a superficial resemblance to the reset of the
powermanagement code, so move it all into its own file. This is to ease
further patches to enforce serialised register access.

v2: Scan for random abuse of I915_WRITE_NOTRACE
v3: Take the opportunity to rename the GT functions as uncore. Uncore is
the term used by the hardware design (and bspec) for all functions
outside of the GPU (and CPU) cores in what is also known as the System
Agent.
v4: Rebase onto SNB rc6 fixes

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Wrestle patch into applying and inline
intel_uncore_early_sanitize (plus move the old comment to the new
function). Also keep the _santize postfix for intel_uncore_sanitize.]
[danvet: Squash in fixup spotted by Chris on irc: We need to call
intel_pm_init before intel_uncore_sanitize since the later will call
cancel_work on the delayed rps setup work the former initializes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agoMerge commit 'Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux'
Daniel Vetter [Thu, 25 Jul 2013 07:41:59 +0000 (09:41 +0200)]
Merge commit 'Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux'

This backmerges Linus' merge commit of the latest drm-fixes pull:

commit 549f3a1218ba18fcde11ef0e22b07e6365645788
Merge: 42577ca 058ca4a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Jul 23 15:47:08 2013 -0700

    Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

We've accrued a few too many conflicts, but the real reason is that I
want to merge the 100% solution for Haswell concurrent registers
writes into drm-intel-next. But that depends upon the 90% bandaid
merged into -fixes:

commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 19 20:36:51 2013 +0100

    drm/i915: Serialize almost all register access

Also, we can roll up on accrued conflicts.

Usually I'd backmerge a tagged -rc, but I want to get this done before
heading off to vacations next week ;-)

Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_gem.c

v2: For added hilarity we have a init sequence conflict around the
gt_lock, so need to move that one, too. Spotted by Jani Nikula.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11 years agodrm/i915: fix reference counting in i915_gem_create
Daniel Vetter [Wed, 24 Jul 2013 21:25:03 +0000 (23:25 +0200)]
drm/i915: fix reference counting in i915_gem_create

This function is called without the dev->struct_mutex held, hence we
need to use the _unlocked unreference variants.

As soon as the object is registered userspace can sneak in here with a
gem_close ioctl call, so the object can (and with my new evil tests
actually does) get the final unreference in this place. The lack of
locking then results in hilarity and some good leakage.

To fix this we simply need to revert

Chris Wilson <chris@chris-wilson.co.uk>

v2: We need to make the trace call _before_ we drop our ref - the
object might very well be gone by then already.

v3: Just revert the original patch as suggested by Chris Wilson.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Remove the added white line again to tighten the return
block, requested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>