Commit Graph

11931 Commits

Author SHA1 Message Date
Dave Airlie efa27f9cec Merge tag 'drm-intel-next-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Need to get my stuff out the door ;-) Highlights:
- pc8+ support from Paulo
- more vma patches from Ben.
- Kconfig option to enable preliminary support by default (Josh
  Triplett)
- Optimized cpu cache flush handling and support for write-through caching
  of display planes on Iris (Chris)
- rc6 tuning from Stéphane Marchesin for more stability
- VECS seqno wrap/semaphores fix (Ben)
- a pile of smaller cleanups and improvements all over

Note that I've ditched Ben's execbuf vma conversion for 3.12 since not yet
ready. But there's still other vma conversion stuff in here.

* tag 'drm-intel-next-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel: (62 commits)
  drm/i915: Print seqnos as unsigned in debugfs
  drm/i915: Fix context size calculation on SNB/IVB/VLV
  drm/i915: Use POSTING_READ in lcpll code
  drm/i915: enable Package C8+ by default
  drm/i915: add i915.pc8_timeout function
  drm/i915: add i915_pc8_status debugfs file
  drm/i915: allow package C8+ states on Haswell (disabled)
  drm/i915: fix SDEIMR assertion when disabling LCPLL
  drm/i915: grab force_wake when restoring LCPLL
  drm/i915: drop WaMbcDriverBootEnable workaround
  drm/i915: Cleaning up the relocate entry function
  drm/i915: merge HSW and SNB PM irq handlers
  drm/i915: fix how we mask PMIMR when adding work to the queue
  drm/i915: don't queue PM events we won't process
  drm/i915: don't disable/reenable IVB error interrupts when not needed
  drm/i915: add dev_priv->pm_irq_mask
  drm/i915: don't update GEN6_PMIMR when it's not needed
  drm/i915: wrap GEN6_PMIMR changes
  drm/i915: wrap GTIMR changes
  drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq
  ...
2013-08-30 09:47:41 +10:00
Keith Packard 62f2104f3f drm: Advertise async page flip ability through GETCAP ioctl
Let applications know whether the kernel supports asynchronous page
flipping.

Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 09:25:13 +10:00
Keith Packard ed8d19756e drm: Pass page flip ioctl flags to driver
This lets drivers see the flags requested by the application

[airlied: fixup for rcar/imx/msm]

Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 09:24:54 +10:00
Dan Carpenter e1e9c90eef drm/omap: tiler: clear buffer properly
We're taking the sizeof() the wrong thing so it doesn't clear the whole
buffer.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 09:14:41 +10:00
Thierry Reding 9c78485506 drm/prime: Remove PRIME handles only if supported
Drivers that don't support PRIME will not have initialized the PRIME
specific private component of struct drm_file. If called for such
drivers, the drm_gem_remove_prime_handles() function will crash. Fix
it by checking for PRIME support prior to removing the PRIME handles.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 09:11:59 +10:00
Jakob Bornecrantz 6e4dcff3ad drm/vmwgfx: Split GMR2_REMAP commands if they are to large
This fixes the piglit test texturing/max-texture-size
causing the VM to die due to a too large SVGA command.

Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Biran Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 09:03:39 +10:00
Dan Carpenter 0adb23709b drm/prime: double lock typo
There is a typo so deadlocks on error instead of unlocking.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:58:32 +10:00
Wei Yongjun 14bbf20c88 drm/vmwgfx: fix error return code in vmw_driver_load()
Fix to return -ENOMEM in the fence manager init error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:57:51 +10:00
David Herrmann 1793126fce drm: implement experimental render nodes
Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.

Compared to legacy clients, render clients no longer need any
authentication to perform client ioctls. Instead, user-space controls
render/client access to GPUs via filesystem access-modes on the
render-node. Once a render-node was opened, a client has full access to
the client/render operations on the GPU. However, no modesetting or ioctls
that affect global state are allowed on render nodes.

To prevent privilege-escalation, drivers must explicitly state that they
support render nodes. They must mark their render-only ioctls as
DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
support clients without any attached master.

If filesystem access-modes are not enough for fine-grained access control
to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
you may still fall-back to fd-passing from server to client (which allows
arbitrary access-control). However, note that revoking access is
currently impossible and unlikely to get implemented.

Note: Render clients no longer have any associated DRM-Master as they are
supposed to be independent of any server state. DRM core highly depends on
file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
Therefore, drivers must be very careful to not require DRM-Master if they
support DRIVER_RENDER.

So far render-nodes are protected by "drm_rnodes". As long as this
module-parameter is not set to 1, a driver will not create render nodes.
This allows us to experiment with the API a bit before we stabilize it.

v2: drop insecure GEM_FLINK to force use of dmabuf

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-30 08:43:57 +10:00
Lespiau, Damien 6cb3b7f1c0 video/hdmi: Rename HDMI_IDENTIFIER to HDMI_IEEE_OUI
HDMI_IDENTIFIER was felt too generic, rename it to what it is, the IEEE
OUI corresponding to HDMI Licensing, LLC.

http://standards.ieee.org/develop/regauth/oui/oui.txt

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:42:01 +10:00
Lespiau, Damien c8bb75afff drm/i915/hdmi: Write HDMI vendor specific infoframes
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:41:55 +10:00
Lespiau, Damien 83dd000865 drm: Add a helper to forge HDMI vendor infoframes
This can then be used by DRM drivers to setup their vendor infoframes.

v2: Fix hmdi typo (Simon Farnsworth)
v3: Adapt to the hdmi_vendor_infoframe rename

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:41:49 +10:00
Lespiau, Damien ae84b900b0 video/hdmi: Use hdmi_vendor_infoframe for the HDMI specific infoframe
We just got rid of the version of hdmi_vendor_infoframe that had a byte
array for anyone to poke at. It's now time to shuffle around the naming
of hdmi_hdmi_infoframe to make hdmi_vendor_infoframe become the HDMI
vendor specific structure.

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:41:42 +10:00
Lespiau, Damien c782d2e73d drm/edid: Move HDMI_IDENTIFIER to hdmi.h
We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.

(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
details..)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:41:22 +10:00
Lespiau, Damien a26a58e89a gpu: host1x: Port the HDMI vendor infoframe code the common helpers
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.

This changes the length of the infoframe payload from 6 to 5, which is
enough for the "frame packing" stereo format.

v2: Pimp up the commit message with the note about the length
    (Ville Syrjälä)

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Terje Bergström <tbergstrom@nvidia.com>
Cc: linux-tegra@vger.kernel.org

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:41:13 +10:00
Lespiau, Damien a5ad3dcf35 video/hdmi: Don't let the user of this API create invalid infoframes
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:

  Author: Damien Lespiau <damien.lespiau@intel.com>
  Date:   Tue Aug 6 20:32:17 2013 +0100

      drm: Don't generate invalid AVI infoframes for CEA modes

We can do better and derive the _valid bit from the user wanting to set
the active aspect ratio.

v2: Fix multi-lines comment style (Thierry Reding)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:40:29 +10:00
Lespiau, Damien 3f2f653378 drm: Add support for alternate clocks of 4k modes
v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:40:14 +10:00
Lespiau, Damien 7ebe1963a0 drm/edid: Parse the HDMI CEA block and look for 4k modes
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.

With this commit, we now parse this block and expose the 4k modes that
we find there.

v2: Fix the "4096x2160" string (nice catch!), add comments about
    do_hdmi_vsdb_modes() arguments and make it clearer that offset is
    relative to the end of the required fields of the HDMI VSDB
    (Ville Syrjälä)

v3: Fix 'Unknow' typo (Simon Farnsworth)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Tested-by: Cancan Feng <cancan.feng@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:40:06 +10:00
Lespiau, Damien 13ac3f5593 drm/edid: Fix add_cea_modes() style issues
A few styles issues have crept in here, fix them before touching this
code again.

v2: constify arguments that can be (Ville Syrjälä)
v3: constify, but better (Ville Syrjälä)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:40:00 +10:00
Lespiau, Damien d4e4a31da3 drm: Don't export drm_find_cea_extension() any more
This function is only used inside drm_edid.c.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-30 08:39:53 +10:00
Imre Deak 77fa4cbd5f drm/i915: ivb: fix edp voltage swing reg val
Fix the typo introduced in

commit 1a2eb4604b
Author: Keith Packard <keithp@keithp.com>
Date:   Wed Nov 16 16:26:07 2011 -0800

    drm/i915: Hook up Ivybridge eDP

This fixes eDP link-training failures and cases where all voltage swing
/pre-emphasis levels were tried and failed during clock recovery and -
as a fallback - we go on to do channel equalization with the last voltage
swing/pre-emphasis level which will succeed. Both issues can lead to a
blank screen.

v2:
- improve commit message

CC: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880
Tested-by: Jeremy Moles <cubicool@gmail.com>
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>
2013-08-30 00:07:27 +02:00
Dave Airlie 5addcf0a5f nouveau: add runtime PM support (v0.9)
This hooks nouveau up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and optimus laptops.

a) rewrite suspend/resume printks to hide them during dynamic s/r
to avoid cluttering logs
b) add runtime pm suspend to irq handler, crtc display, ioctl handler,
connector status,
c) handle hdmi audio dynamic power on/off using magic register.

v0.5:
make sure we hit D3 properly
fix fbdev_set_suspend locking interaction, we only will poweroff if we have no
active crtcs/fbcon anyways.
add reference for active crtcs.
sprinkle mark last busy for autosuspend timeout

v0.6:
allow more flexible debugging - to avoid log spam
add option to enable/disable dynpm
got to D3Cold

v0.7:
add hdmi audio support.

v0.8:
call autosuspend from idle, so pci config space access doesn't go straight
back to sleep, this makes starting X faster.
only signal usage if we actually handle the irq, otherwise usb keeps us awake.
fix nv50 display active powerdown

v0.9:
use masking function to enable hdmi audio
set busy when we fail to suspend

Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-29 13:30:46 +10:00
Dave Airlie 13bb9cc872 drm: allow open of dynamic off devices.
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-29 13:30:38 +10:00
Dave Airlie 0d69704ae3 gpu/vga_switcheroo: add driver control power feature. (v3)
For optimus and powerxpress muxless we really want the GPU
driver deciding when to power up/down the GPU, not userspace.

This adds the ability for a driver to dynamically power up/down
the GPU and remove the switcheroo from controlling it, the
switcheroo reports the dynamic state to userspace also.

It also adds 2 power domains, one for machine where the power
switch is controlled outside the GPU D3 state, so the powerdown
ordering is done correctly, and the second for the hdmi audio
device to make sure it can resume for PCI config space accesses.

v1.1: fix build with switcheroo off

v2: add power domain support for radeon and v1 nvidia dsms
v2.1: fix typo in off case

v3: add audio power domain for hdmi audio + misc audio fixes

v4: use PCI_SLOT macro, drop power reference on hdmi audio resume
failure also.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-29 13:30:21 +10:00
Dave Airlie e906d7bdd3 Merge branch 'drm-next' of git://people.freedesktop.org/~robclark/linux into drm-next
Merge the MSM driver from Rob Clark
* 'drm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: add basic hangcheck/recovery mechanism
  drm/msm: add a3xx gpu support
  drm/msm: add register definitions for gpu
  drm/msm: basic KMS driver for snapdragon
  drm/msm: add register definitions
2013-08-28 14:27:15 +10:00
Dan Carpenter 745cecc07c gpu: host1x: returning success instead of -ENOMEM
There is a mistake here so it returns PTR_ERR(NULL) which is success
instead of -ENOMEM.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2013-08-27 10:20:12 +02:00
Dan Carpenter f5fda676e9 gpu: host1x: fix an integer overflow check
Tegra is a 32 bit arch.  On 32 bit systems then size_t is 32 bits so
"total" will never be higher than UINT_MAX because of integer overflows.
We need cast to u64 first before doing the math.

Also the addition earlier:

        unsigned int num_unpins = num_cmdbufs + num_relocs;

That can overflow as well, but I think it's still safe because we check
both "num_cmdbufs" and "num_relocs" again in this test.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2013-08-27 10:20:11 +02:00
Mikko Perttunen ccaddfe1a2 drm/tegra: hdmi: Make sure clock is enabled before dumping registers
The debugfs register dumping function did not enable the HDMI clock.
This led to a possible system hang when reading the debugfs entry
while no HDMI cable was connected to the system. This patch makes
sure that the clock is enabled during the read.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2013-08-27 10:19:39 +02:00
David Herrmann acb4652703 drm: verify vma access in TTM+GEM drivers
GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
    access was denied.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-27 11:54:58 +10:00
David Herrmann ca481c9b2a drm/gem: implement vma access management
We implement automatic vma mmap() access management for all drivers using
gem_mmap. We use the vma manager to add each open-file that creates a
gem-handle to the vma-node of the underlying gem object. Once the handle
is destroyed, we drop the open-file again.

This allows us to use drm_vma_node_is_allowed() on _any_ gem object to see
whether an open-file is granted access. In drm_gem_mmap() we use this to
verify that unprivileged users cannot guess gem offsets and map arbitrary
buffers.

Note that this manages access for _all_ gem users (also TTM+GEM), but the
actual access checks are only done for drm_gem_mmap(). TTM drivers use the
TTM mmap helpers, which need to do that separately.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-27 11:54:56 +10:00
David Herrmann 88d7ebe593 drm/vma: add access management helpers
The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.

We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.

We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.

As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
 - Most times only a single filp is added per bo so we could use a static
   "struct file *main_filp" which is checked/added/removed first before we
   fall back to the rbtree+drm_vma_offset_file.
   This could be even done lockless with rcu.
 - Let user-space pass a hint whether mmap() should be supported on the
   bo and avoid access-management if not.
 - .. there are probably more ideas once we have benchmarks ..

v2: add drm_vma_node_verify_access() helper

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-27 11:54:54 +10:00
Rob Clark bd6f82d828 drm/msm: add basic hangcheck/recovery mechanism
A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple.  This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24 14:57:19 -04:00
Rob Clark 7198e6b031 drm/msm: add a3xx gpu support
Add initial support for a3xx 3d core.

So far, with hardware that I've seen to date, we can have:
 + zero, one, or two z180 2d cores
 + a3xx or a2xx 3d core, which share a common CP (the firmware
   for the CP seems to implement some different PM4 packet types
   but the basics of cmdstream submission are the same)

Which means that the eventual complete "class" hierarchy, once
support for all past and present hw is in place, becomes:
 + msm_gpu
   + adreno_gpu
     + a3xx_gpu
     + a2xx_gpu
   + z180_gpu

This commit splits out the parts that will eventually be common
between a2xx/a3xx into adreno_gpu, and the parts that are even
common to z180 into msm_gpu.

Note that there is no cmdstream validation required.  All memory access
from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
to the GPU, there isn't much damage that the GPU can do.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24 14:57:18 -04:00
Rob Clark 902e6eb851 drm/msm: add register definitions for gpu
Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24 14:57:18 -04:00
Rob Clark c8afe684c9 drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version.  (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.

To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.

The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently.  But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge.  This
would remove the 'msm_connector' base class.  But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..

This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24 14:57:07 -04:00
Rob Clark 0cf6c71d70 drm/msm: add register definitions
Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24 14:33:01 -04:00
Ville Syrjälä fb1ae911f4 drm/i915: Print seqnos as unsigned in debugfs
I don't like seeing signed seqnos. Make them unsigned.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:37 +02:00
Ville Syrjälä e801605533 drm/i915: Fix context size calculation on SNB/IVB/VLV
All the different context sizes reported in the CXT_SIZE register
aren't meant to be simply added together.

While BSpec is somewhat unclear on the topic of the actual context
size, empirical tests have now revealed the truth. So let's add a
big fat comment to remind people how it all works.

As a result of correctly interpreting CXT_SIZE, the IVB context
size is reduced from three pages to two, while SNB context size
remains at two pages.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:37 +02:00
Daniel Vetter 35d8f2eb25 drm/i915: Use POSTING_READ in lcpll code
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.

While at it add the missing posting read in the lcpll enable function
that Paulo spotted.

v2: Drop the _NOTRACE changes, tracing such wait_for loops in the modeset
code might actually be rather useful!

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:36 +02:00
Paulo Zanoni e27e9708c4 drm/i915: enable Package C8+ by default
This should be working, so enable it by default. Also easy to revert.

v2: Rebase, s/allow/enable/.

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>
2013-08-23 14:52:35 +02:00
Paulo Zanoni 9005874532 drm/i915: add i915.pc8_timeout function
We currently only enter PC8+ after all its required conditions are
met, there's no rendering, and we stay like that for at least 5
seconds.

I chose "5 seconds" because this value is conservative and won't make
us enter/leave PC8+ thousands of times after the screen is off: some
desktop environments have applications that wake up and do rendering
every 1-3 seconds, even when the screen is off and the machine is
completely idle.

But when I was testing my PC8+ patches I set the default value to
100ms so I could use the bad-behaving desktop environments to
stress-test my patches. I also thought it would be a good idea to ask
our power management team to test different values, but I'm pretty
sure they would ask me for an easy way to change the timeout. So to
help these 2 cases I decided to create an option that would make it
easier to change the default value. I also expect people making
specific products that use our driver could try to find the perfect
timeout for them.

Anyway, fixing the bad-behaving applications will always lead to
better power savings than just changing the timeout value: you need to
stop waking the Kernel, not quickly put it back to sleep again after
you wake it for nothing. Bad sleep leads to bad mood!

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>
2013-08-23 14:52:35 +02:00
Paulo Zanoni 371db66add drm/i915: add i915_pc8_status debugfs file
Make it print the value of the variables on the PC8 struct.

v2: Update to recent renames and add the new fields.

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>
2013-08-23 14:52:34 +02:00
Paulo Zanoni c67a470b1d drm/i915: allow package C8+ states on Haswell (disabled)
This patch allows PC8+ states on Haswell. These states can only be
reached when all the display outputs are disabled, and they allow some
more power savings.

The fact that the graphics device is allowing PC8+ doesn't mean that
the machine will actually enter PC8+: all the other devices also need
to allow PC8+.

For now this option is disabled by default. You need i915.allow_pc8=1
if you want it.

This patch adds a big comment inside i915_drv.h explaining how it
works and how it tracks things. Read it.

v2: (this is not really v2, many previous versions were already sent,
     but they had different names)
    - Use the new functions to enable/disable GTIMR and GEN6_PMIMR
    - Rename almost all variables and functions to names suggested by
      Chris
    - More WARNs on the IRQ handling code
    - Also disable PC8 when there's GPU work to do (thanks to Ben for
      the help on this), so apps can run caster
    - Enable PC8 on a delayed work function that is delayed for 5
      seconds. This makes sure we only enable PC8+ if we're really
      idle
    - Make sure we're not in PC8+ when suspending
v3: - WARN if IRQs are disabled on __wait_seqno
    - Replace some DRM_ERRORs with WARNs
    - Fix calls to restore GT and PM interrupts
    - Use intel_mark_busy instead of intel_ring_advance to disable PC8
v4: - Use the force_wake, Luke!
v5: - Remove the "IIR is not zero" WARNs
    - Move the force_wake chunk to its own patch
    - Only restore what's missing from RC6, not everything

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:33 +02:00
Paulo Zanoni bd633a7c1c drm/i915: fix SDEIMR assertion when disabling LCPLL
This was causing WARNs in one machine, so instead of trying to guess
exactly which hotplug bits should exist, just do the test on the
non-HPD bits. We don't care about the state of the hotplug bits, we
just care about the others, that need to be 1.

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>
2013-08-23 14:52:33 +02:00
Paulo Zanoni 215733fadb drm/i915: grab force_wake when restoring LCPLL
If LCPLL is disabled, there's a chance we might be in package C8 state
or deeper, and we'll get a hard hang when restoring LCPLL (also, a red
led lights up on my motherboard). So grab the force_wake, which will
get us out of RC6 and, as a consequence, out of PC8+ (since we need
RC6 to get into PC8+).

Note: Discussions with hw designers are still ongoing what exactly
goes boom here. But I think we can go ahead and just merge this little
hack for now until it's clear what we actually need.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add small note about the current state of the discussion
around this hack.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:32 +02:00
Jesse Barnes 3414caf634 drm/i915: drop WaMbcDriverBootEnable workaround
Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk hangs or other bad behavior.

Note that this seems to break libva on ChromeOS after resumes (but
strangely _not_ after booting up).

This essentially reverts

commit b4ae3f22d2
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 14 11:04:48 2012 -0700

    drm/i915: load boot context at driver init time

and

commit b3bf076697
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Nov 20 13:27:44 2012 -0200

    drm/i915: implement WaMbcDriverBootEnable on Haswell

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-and-Tested-by: Stéphane Marchesin <marcheu@chromium.org>
[danvet: Add note about impact and regression citation.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:32 +02:00
Rafael Barbalho 5032d871f7 drm/i915: Cleaning up the relocate entry function
As the relocate entry function was getting a bit too big I've moved
the code that used to use either the cpu or the gtt to for the
relocation into two separate functions.

Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:31 +02:00
Paulo Zanoni 1403c0d4d4 drm/i915: merge HSW and SNB PM irq handlers
Because hsw_pm_irq_handler does exactly what gen6_rps_irq_handler does
and also processes the 2 additional VEBOX bits. So merge those
functions and wrap the VEBOX bits on a HAS_VEBOX check. This
check isn't really necessary since the bits are reserved on
SNB/IVB/VLV, but it's a good documentation on who uses them.

v2: - Change IS_HASWELL check to HAS_VEBOX

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:30 +02:00
Paulo Zanoni 4d3b3d5fd7 drm/i915: fix how we mask PMIMR when adding work to the queue
It seems we've been doing this ever since we started processing the
RPS events on a work queue, on commit "drm/i915: move gen6 rps
handling to workqueue", 4912d04193.

The problem is: when we add work to the queue, instead of just masking
the bits we queued and leaving all the others on their current state,
we mask the bits we queued and unmask all the others. This basically
means we'll be unmasking a bunch of interrupts we're not going to
process. And if you look at gen6_pm_rps_work, we unmask back only
GEN6_PM_RPS_EVENTS, which means the bits we unmasked when adding work
to the queue will remain unmasked after we process the queue.

Notice that even though we unmask those unrelated interrupts, we never
enable them on IER, so they don't fire our interrupt handler, they
just stay there on IIR waiting to be cleared when something else
triggers the interrupt handler.

So this patch does what seems to make more sense: mask only the bits
we add to the queue, without unmasking anything else, and so we'll
unmask them after we process the queue.

As a side effect we also have to remove that WARN, because it is not
only making sure we don't mask useful interrupts, it is also making
sure we do unmask useless interrupts! That piece of code should not be
responsible for knowing which bits should be unmasked, so just don't
assert anything, and trust that snb_disable_pm_irq should be doing the
right thing.

With i915.enable_pc8=1 I was getting ocasional "GEN6_PMIIR is not 0"
error messages due to the fact that we unmask those unrelated
interrupts but don't enable them.

Note: if bugs start bisecting to this patch, then it probably means
someone was relying on the fact that we unmask everything by accident,
then we should fix gen5_gt_irq_postinstall or whoever needs the
accidentally unmasked interrupts. Or maybe I was just wrong and we
need to revert this patch :)

Note: This started to be a more real issue with the addition of the
VEBOX support since now we do enable more than just the minimal set of
RPS interrupts in the IER register. Which means after the first rps
interrupt has happened we will never mask the VEBOX user interrupts
again and so will blow through cpu time needlessly when running video
workloads.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add note that this started to matter with VEBOX much more.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:30 +02:00
Paulo Zanoni 60611c1376 drm/i915: don't queue PM events we won't process
On SNB/IVB/VLV we only call gen6_rps_irq_handler if one of the IIR
bits set is part of GEN6_PM_RPS_EVENTS, but at gen6_rps_irq_handler we
add all the enabled IIR bits to the work queue, not only the ones that
are part of GEN6_PM_RPS_EVENTS. But then gen6_pm_rps_work only
processes GEN6_PM_RPS_EVENTS, so it's useless to add anything that's
not GEN6_PM_RPS_EVENTS to the work queue.

As a bonus, gen6_rps_irq_handler looks more similar to
hsw_pm_irq_handler, so we may be able to merge them in the future.

v2: - Add a WARN in case we queued something we're not going to
      process.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:29 +02:00
Paulo Zanoni 333a820416 drm/i915: don't disable/reenable IVB error interrupts when not needed
If the error interrupts are already disabled, don't disable and
reenable them. This is going to be needed when we're in PC8+, where
all the interrupts are disabled so we won't risk re-enabling
DE_ERR_INT_IVB.

v2: Use dev_priv->irq_mask (Chris)

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>
2013-08-23 14:52:28 +02:00
Paulo Zanoni 605cd25b1f drm/i915: add dev_priv->pm_irq_mask
Just like irq_mask and gt_irq_mask, use it to track the status of
GEN6_PMIMR so we don't need to read it again every time we call
snb_update_pm_irq.

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>
2013-08-23 14:52:28 +02:00
Paulo Zanoni f52ecbcf80 drm/i915: don't update GEN6_PMIMR when it's not needed
I did some brief tests and the "new_val = pmimr" condition usually
happens a few times after exiting games.

Note: This is also prep work to track the GEN6_PMIMR register state in
dev_priv->pm_imr. This happens in the next patch.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add note to explain why we want this, as per the discussion
between Chris and Paulo.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:27 +02:00
Paulo Zanoni edbfdb4560 drm/i915: wrap GEN6_PMIMR changes
Just like we're doing with the other IMR changes.

One of the functional changes is that not every caller was doing the
POSTING_READ.

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>
2013-08-23 14:52:26 +02:00
Paulo Zanoni 43eaea1318 drm/i915: wrap GTIMR changes
Just like the functions that touch DEIMR and SDEIMR, but for GTIMR.
The new functions contain a POSTING_READ(GTIMR) which was not present
at the 2 callers inside i915_irq.c.

The implementation is based on ibx_display_interrupt_update.

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>
2013-08-23 14:52:26 +02:00
Paulo Zanoni a40066412c drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq
We already have code to disable LCPLL and switch to FCLK, so we need this too.
We still don't call the code to disable LCPLL, but we'll call it when we add
support for Package C8+.

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>
2013-08-23 14:52:25 +02:00
Jesse Barnes ec013e7f49 drm/i915: Expose energy counter on SNB+ through debugfs
On SNB and IVB, there's an MSR (also exposed through MCHBAR) we can use
to read out the amount of energy used over time.  Expose this in sysfs
to make it easy to do power comparisons with different configurations.

If the platform supports it, the file will show up under the
drm/card0/power subdirectory of the PCI device in sysfs as gt_energy_uJ.
The value in the file is a running total of energy (in microjoules)
consumed by the graphics device.

v2: move to sysfs (Ben, Daniel)
    expose a simple value (Chris)
    drop unrelated hunk (Ben)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

v3: by Ben
Tied it into existing rc6  sysfs entries and named that a more generic
"power attrs." Fixed rebase conflicts.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

v4: Since RAPL is a real driver that already exists to serve power
monitoring, place our entry in debugfs. This gives me a fallback
location for systems that do not expose it otherwise.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:25 +02:00
Damien Lespiau e3ce7633ba drm/i915: Remove I915_READ_{NOPID, SYNC_0, SYNC_1})()
The code directly uses the registers and ring->mmio_base.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:24 +02:00
Damien Lespiau 3abdb33410 drm: Remove IS_IRONLAKE_D()
This define hasn't been used since:

  commit cfdf1fa23f
  Author: Kristian Høgsberg <krh@bitplanet.net>
  Date:   Wed Dec 16 15:16:16 2009 -0500

      drm/i915: Implement IS_* macros using static tables

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:23 +02:00
Damien Lespiau fdaa930bee drm/i915: Remove HAS_PIPE_CONTROL()
The code using this was removed in:

  commit 88f23b8fa3
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Sun Dec 5 15:08:31 2010 +0000

      drm/i915: Avoid using PIPE_CONTROL on Ironlake

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:23 +02:00
Damien Lespiau 8254860096 drm/i915: Remove DSPARB_HWCONTROL()
This define hasn't been used since:

  commit 652c393a33
  Author: Jesse Barnes <jbarnes@virtuousgeek.org>
  Date:   Mon Aug 17 13:31:43 2009 -0700

      drm/i915: add dynamic clock frequency control

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:22 +02:00
Jesse Barnes 139ccd3fb1 drm/i915: make IVB FDI training match spec v3
The existing code was trying different vswing and preemphasis settings
in the wrong place, and wasn't trying them enough.  So add a loop to
walk through them, properly disabling FDI TX and RX in between if a
failure is detected.

v2: remove unneeded reg writes, add delays around bit lock checks (Jesse)
v3: fix TX and RX disable per spec (Paulo)
    fix delays per spec (Paulo)
    make RX symbol lock check match TX bit lock check (Paulo)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51983
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:21 +02:00
Ben Widawsky 8637b407cf drm/i915/vma: Correct use after free in eviction
The vma will [possibly] be destroyed during unbind in eviction.
Immediately after this, we try to delete the list entry.

Chris and Ville did the debug on this before I woke up, I just get to
take credit for the fix :p

For future reference the Oops that Mika reported:

[  403.472448] BUG: unable to handle kernel paging request at 6b6b6b6b
[  403.472473] IP: [<c12c1500>] __list_del_entry+0x20/0xe0
[  403.472514] *pdpt = 000000002e89c001 *pde = 0000000000000000
[  403.472556] Oops: 0000 [#1] SMP
[  403.472582] Modules linked in: mxm_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi psmouse snd_seq_midi_event snd_seq serio_raw snd_timer snd_seq_device snd soundcore snd_page_alloc wmi bnep rfcomm bluetooth mac_hid parport_pc ppdev lp parport usbhid dm_crypt firewire_ohci firewire_core crc_itu_t i915 drm_kms_helper e1000e ptp drm i2c_algo_bit pps_core xhci_hcd video
[  403.472895] CPU: 2 PID: 1940 Comm: Xorg Not tainted 3.11.0-rc2+ #827
[  403.472938] Hardware name:                  /DZ77BH-55K, BIOS BHZ7710H.86A.0070.2012.0416.2117 04/16/2012
[  403.473002] task: ec866c00 ti: ee6a2000 task.ti: ee6a2000
[  403.473039] EIP: 0060:[<c12c1500>] EFLAGS: 00013202 CPU: 2
[  403.473078] EIP is at __list_del_entry+0x20/0xe0
[  403.473109] EAX: f016d9bc EBX: f016d9bc ECX: 6b6b6b6b EDX: 6b6b6b6b
[  403.473151] ESI: 00000000 EDI: ee6a3c90 EBP: ee6a3c60 ESP: ee6a3c48
[  403.473193]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  403.473230] CR0: 80050033 CR2: 6b6b6b6b CR3: 2ec43000 CR4: 001407f0
[  403.473271] Stack:
[  403.473285]  f63b2ff0 f61f98c0 f61f8000 f016d9bc 00000000 f016d9bc ee6a3cac f8519a4a
[  403.473347]  00000000 00000000 10000000 f61f8000 0100a000 10000000 00000001 008ca000
[  403.473410]  f64ee840 f61f98c0 f016d9bc f016dcec ee6a3c98 ee6a3c98 f61f98c0 dcc58f00
[  403.473472] Call Trace:
[  403.473509]  [<f8519a4a>] i915_gem_evict_something+0x17a/0x2d0 [i915]
[  403.473567]  [<f8516ed1>] i915_gem_object_pin+0x271/0x660 [i915]
[  403.473622]  [<f851c740>] ? i915_ggtt_clear_range+0x20/0x20 [i915]
[  403.473676]  [<f8517afa>] i915_gem_object_pin_to_display_plane+0xda/0x190 [i915]
[  403.473742]  [<f852d9fa>] intel_pin_and_fence_fb_obj+0xba/0x140 [i915]
[  403.473800]  [<f852db40>] intel_gen7_queue_flip+0x30/0x1c0 [i915]
[  403.473856]  [<f85337b0>] intel_crtc_page_flip+0x1a0/0x320 [i915]
[  403.473911]  [<f847b549>] ? drm_framebuffer_reference+0x39/0x80 [drm]
[  403.473965]  [<f847f9fb>] drm_mode_page_flip_ioctl+0x28b/0x320 [drm]
[  403.474018]  [<f846fec8>] drm_ioctl+0x4b8/0x560 [drm]
[  403.474064]  [<f847f770>] ? drm_mode_gamma_get_ioctl+0xd0/0xd0 [drm]
[  403.474113]  [<c1140f8a>] ? do_sync_read+0x6a/0xa0
[  403.474154]  [<f846fa10>] ? drm_copy_field+0x80/0x80 [drm]
[  403.474193]  [<c115134c>] do_vfs_ioctl+0x7c/0x5b0
[  403.474228]  [<c1141d2f>] ? vfs_read+0xef/0x160
[  403.474263]  [<c108dcbb>] ? ktime_get_ts+0x4b/0x120
[  403.474298]  [<c1151917>] SyS_ioctl+0x97/0xa0
[  403.474330]  [<c1590bc1>] sysenter_do_call+0x12/0x22
[  403.474364] Code: 55 f4 8b 45 f8 e9 75 ff ff ff 90 55 89 e5 53 83 ec 14 8b 08 8b 50 04 81 f9 00 01 10 00 74 24 81 fa 00 02 20 00 0f 84 8e 00 00 00 <8b> 1a 39 d8 75 62 8b 59 04 39 d8 75 35 89 51 04 89 0a 83 c4 14
[  403.474566] EIP: [<c12c1500>] __list_del_entry+0x20/0xe0 SS:ESP 0068:ee6a3c48
[  403.476513] CR2: 000000006b6b6b6b

v2: Missed the drm_object_unreference use after free (Ville)
Daniel Vetter <daniel@ffwll.ch> writes:

Reported-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add the Oops from Mika to the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-23 14:52:21 +02:00
Dave Airlie 4dd17ee957 Merge tag 'drm-intel-fixes-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Just one patch that soaked for quite a bit to fix a resume issue,
resulting in gpu hangs (or worse) due to tlb containing garbage.

* tag 'drm-intel-fixes-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Invalidate TLBs for the rings after a reset
2013-08-23 18:52:37 +10:00
Wolfram Sang 687b81d083 i2c: move OF helpers into the core
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child nodes in the core instead of doing this manually
in each driver. So, fix the drivers and documentation, too.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-23 10:22:20 +02:00
Ben Widawsky accfef2e5a drm/i915: prepare bind_to_vm for preallocated vma
In the new execbuf code we want to track buffers using the vmas even
before they're all properly mapped. Which means that bind_to_vm needs
to deal with buffers which have preallocated vmas which aren't yet
bound.

This patch implements this prep work and adjusts our WARN/BUG checks.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Split out from Ben's big execbuf patch. Also move one BUG
back to its original place to deflate the diff a notch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:53 +02:00
Ben Widawsky 82a55ad1a0 drm/i915: Switch eviction code to use vmas
The execbuf wants to do relocations usings vmas, so we need a
vma->exec_list. The eviction code also uses the old obj execbuf list
for it's own book-keeping, but would really prefer to deal in vmas
only. So switch it over to the new list.

Again this is just a prep patch for the big execbuf vma conversion.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Split out from Ben's big execbuf vma patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:52 +02:00
Ben Widawsky b25cb2f882 drm/i915: s/obj->exec_list/obj->obj_exec_link in debugfs
To convert the execbuf code over to use vmas natively we need to
shuffle the exec_list a bit. This patch here just prepares things with
the debugfs code, which also uses the old exec_list list_head, newly
called obj_exec_link.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Split out from Ben's big patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:51 +02:00
Josh Triplett 99486b8e61 i915: Add a Kconfig option to turn on i915.preliminary_hw_support by default
When building kernels for a preliminary hardware target, having to add a
kernel command-line option can prove inconvenient.  Add a Kconfig option
that changes the default of this option to 1.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Pimp the Kconfig help text a bit as suggested by Damien in
his 2nd review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:51 +02:00
Paulo Zanoni 79f8dea133 drm/i915: enable the power well before module unload
Our driver initialization doesn't seem to be ready to load when the
power well is disabled: we hit a few "Unclaimed register" messages. So
do just like we already do for the suspend/resume path: enable the
power well before unloading.

At some point we'll want to be able to survive suspend/resume and
load/unload with the power well disabled, but for now let's just fix
the regression.

Regression introduced by the following commit:

commit bf51d5e2cd
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Wed Jul 3 17:12:13 2013 -0300
    drm/i915: switch disable_power_well default value to 1

Bug can be reproduced by running the "module_reload" script from
intel-gpu-tools.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:50 +02:00
Daniel Vetter 608806a549 drm/i915: explicit store base gem object in dma_buf->priv
Makes it more obviously correct what tricks we play by reusing the drm
prime release helper.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:49 +02:00
Daniel Vetter f214266c0d drm/i915: unpin backing storage in dmabuf_unmap
This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.

v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces for our own, reimported buffers. But it's still easy to
blow up and anger lockdep, but that's already the case with our ->map
implementation. Fixing this for real will involve per dma-buf ww mutex
locking by the callers. And lots of fun. So go with the duct-tape
approach for now.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Armin K. <krejzi@email.com> (v1)
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:49 +02:00
Vinit Azad fd547d25a8 drm/i915: Only unmask required PM interrupts
Un-masking all PM interrupts causes hardware to generate
interrupts regardless of whether the interrupts are enabled
on the DE side. Since turbo only need up/down threshold and
rc6 timeout interrupt, mask all other interrupts bits to avoid
unnecessary overhead/wake up.

Note that our interrupt handler isn't being fired since we do set the
IER bits properly (IIR bits aren't set). The overhead isn't because
our driver is reacting to these interrupts, but because hardware keeps
generating internal messages when PMINTRMSK doesn't mask out the
up/down EI interrupts (which happen periodically).

Change-Id: I6c947df6fd5f60584d39b9e8b8c89faa51a5e827
Signed-off-by: Vinit Azad <vinit.azad@intel.com>
[danvet: Add follow-up explanation of the precise effects from Vinit
as a note to the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:48 +02:00
Paulo Zanoni 6aedd1f539 drm/i915: clarify Haswell power well bit names
Whenever I need to work with the HSW_PWER_WELL_* register bits I have
to look at the documentation to find out which bit is to request the
power well and which one shows its current state. Rename the bits so I
won't need to look the docs every time.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:48 +02:00
Paulo Zanoni 8dc8a27c97 drm/i915: check the power well when redisabling VGA
If the power well is disabled VGA is guaranteed to be disabled.

This fixes unclaimed register messages that happen on suspend/resume.

v2: Check the actual hw power well state instead of our own tracking
to make sure VGA is _really_ off (in case the BIOS/KVMr has just its
own request bit set). Requested by Ville.

Note: Ville suggested whether it wouldn't be better to just enable the
power well over a slightly longer time in our resume code, since we
already do that. I tend to agree, but there's also the modeset force
code in the lid notifier which _also_ eventually calls redisable_vga.
We shouldn't ever need this on somewhat modern hw (everything with
opregion essentially) but the code to bail out isn't there. Hence
stick with this simple approach here for now.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67517
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Summarize the discussion around the resume sequence and lid
notifier a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:47 +02:00
Chris Wilson 4b6d846e9a drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
By our earlier reckoning, move from a snooped/llc setting to an uncached
setting, leaves the CPU cache in a consistent state irrespective of our
domain tracking - so we can forgo the warning about the lack of
invalidation. Similarly for any writes posted to the snooped CPU domain,
we know will be safely clflushed to the uncached PTEs after forcing the
domain change.

This WARN started to pop up with

commit d46f1c3f13
Author:     Chris Wilson <chris@chris-wilson.co.uk>
AuthorDate: Thu Aug 8 14:41:06 2013 +0100

    drm/i915: Allow the GPU to cache stolen memory

Ville brought up a scenario where the interaction of a set_caching
ioctl call from userspace on a scanout buffer (i.e. obj->pin_display
is set) resulted in the code getting confused and not properly
flushing stale cpu cachelines. Luckily we already prevent this by
rejecting caching changes when obj->pin_count is set.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68040
Tested-by: cancan,feng <cancan.feng@intel.com>
[danvet: Add buglink, bisect result and explain why Ville's scenario
is already taken care of.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:46 +02:00
Ben Widawsky 3ef80a818b drm: WARN when removing unallocated node
The conditional is usually a recoverable driver bug, and so WARNing, and
preventing the drm_mm code from doing potential damage (BUG) is
desirable.

This issue was hit and fixed twice while developing the i915 multiple
address space code. The first fix is the patch just before this, and is
hit on an not frequently occuring error path. Another was fixed during
patch iteration, so it's hard to see from the patch:

commit c6cfb32567
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Jul 5 14:41:06 2013 -0700

    drm/i915: Embed drm_mm_node in i915 gem obj

From the intel-gfx mailing list, we discussed this:
References: <20130705191235.GA3057@bwidawsk.net>

Cc: Dave Airlie <airlied@redhat.com>
CC: <dri-devel@lists.freedesktop.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:46 +02:00
Daniel Vetter 49987099e2 drm/i915: use vma->node directly and rewrap map&fence in bind
Use () to make for neater alignment of the split lines, too. With this
we ditch another jump through the obj_gtt_size/offset indirection
maze.

Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:45 +02:00
Ben Widawsky 4bd561b3e8 drm/i915: cleanup map&fence in bind
Cleanup the map and fenceable setting during bind to make more sense,
and not check i915_is_ggtt() 2 unnecessary times

v2: Move the bools into the if block (Chris) - There are ways to tidy
this function (fence calculations for instance) even further, but they
are quite invasive, so I am punting on those unless specifically asked.

v3: Add newline between variable declaration and logic (Chris)

Recommended-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-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>
2013-08-22 13:31:45 +02:00
Ben Widawsky 433544bd25 drm/i915: Remove node only when allocated
VMAs can be created and not bound. One may think of it as lazy cleanup,
and safely gloss over the conditions which manufacture it. In either
case, when the object backing the i915 vma is destroyed, we must cleanup
the vma without stumbling into a bunch of pitfalls that assume the vma
is bound.

NOTE: I was pretty certain the above condition could only happen when we
introduced the use of VMAs being looked up at execbuf, and already
existing. Paulo has hit this though, so I must be missing something. As
I believe the patch is correct anyway, therefore I won't scratch my head
too hard.

v2: use goto destroy as a compromise (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
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>
2013-08-22 13:31:44 +02:00
Daniel Vetter 4a025e26a2 drm/i915: clarify error paths in create_stolen_for_preallocated
Use the standard inversely ordered goto label stack for everything.
Spotted while reviewing place where we might need to to call
vma_destroy but failed to do so.

Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:43 +02:00
Ben Widawsky 4e5aabfd31 drm/i915: Get VECS semaphore info on error
Ideally we could use for_each_ring with the ring flags as I've done a
couple times
(http://lists.freedesktop.org/archives/intel-gfx/2013-June/029450.html).
Until Daniel merges that patch though, we can just use this.

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:43 +02:00
Ben Widawsky 5020150b3b drm/i915: Initialize seqno for VECS too
We require n-1 mailboxes for proper semaphore synchronization. All
semaphore synchronization code relies on proper values in these
mailboxes. The fact that we failed to touch the vebox ring by itself
was unlikely to be an issue since the HW should be initializing the
values to 0. However the error framework for testing seqno wrap
introduced by Mika, in addition to the hangcheck via seqno, and
i915_error_first_batchbuffer() combined caused a nice explosion.

The problem is caused by seqno wrap because the wrap condition is not
properly setup. The wrap code attempts to set the sync mailboxes all
to 0, and then set the current seqno to one less than 0. In all cases,
the vebox mailbox wasn't properly being initialized. This caused a
wrap to not occur. When hangcheck kicks in with the bogus seqno
values, the rest just doesn't work. It makes me wonder if we shouldn't
consider a dumber version of hangcheck...

How we messed this up: VECS support was written before the
aforementioned other features. Upon VECS being rebased, these facts
were missed.

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:42 +02:00
Stéphane Marchesin 351aa5666d drm/i915: tune the RC6 threshold for stability
It's basically the same deal as the RC6+ issues on ivy bridge
except this time with RC6 on sandy bridge. Like last time the
core of the issue is that the timings don't work 100% with our
voltage regulator. So from time to time, the kernel will print
a warning message about the GPU not getting out of RC6. In
particular, I found this fairly easy to reproduce during
suspend/resume.

Changing the threshold to 125000 instead of 50000 seems to fix
the issue. The previous patch used 150000 but as it turns out
this doesn't work everywhere. After getting such a machine, I
bisected the highest value which works, which is 125000, so here
it is.

I also measured the idle power usage before/after this patch and
didn't see a difference on a sandy bridge laptop. On haswell and
up, it makes a big difference, so we want to keep it at 50k
there. It also seems like haswell doesn't have the RC6 issues
that sandy bridge has so the 50k value is fine.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:41 +02:00
Paulo Zanoni ed1c9e2cf4 drm/i915: print a message when we detect an early Haswell SDV
The machines that fall in this category are the SDVs that have a PCI
ID starting with 0x0C. These are very early pre-production machines
and may not fully work. Other Haswell SDVs have PCI IDs that match the
real Haswell machines and we expect them to work better.

Even though they have problems, they still mostly work so I don't see
a reason to refuse loading our driver. But I do see a reason to reject
bug reports from these machines, so the message should help the bug
triagers.

As far as I know, we don't implement some workarounds that are
specific to these machines and suspend/resume may not work on most of
them, but besides this, they may work.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61508
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>
2013-08-22 13:31:41 +02:00
Chris Wilson a1d95703b7 drm/i915: Print the changes required for modeset
After computing the stage changes for the set_config, record those in
the debug log.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:40 +02:00
Paulo Zanoni f3f08572fc drm/i915: remove set but unused variables
Caught by "make W=1 drivers/gpu/drm/i915/".

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:39 +02:00
Chris Wilson 4257d3ba3b drm/i915: Allow the user to set bo into the DISPLAY cache domain
This is primarily for the benefit of the create2 ioctl so that the
caller can avoid the later step of rebinding the bo with new PTE bits.
After introducing WT (and possibly GFDT) cacheing for display targets,
not everything in the display is earmarked as UC, and more importantly
what is is controlled by the kernel.

Note that set_cache_level/get_cache_level for DISPLAY is not necessarily
idempotent; get_cache_level may return UC for architectures that have no
special cache domain for the display engine.

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>
2013-08-22 13:31:39 +02:00
Chris Wilson 651d794fae drm/i915: Use Write-Through cacheing for the display plane on Iris
Haswell GT3e has the unique feature of supporting Write-Through cacheing
of objects within the eLLC/LLC. The purpose of this is to enable the display
plane to remain coherent whilst objects lie resident in the eLLC/LLC - so
that we, in theory, get the best of both worlds, perfect display and fast
access.

However, we still need to be careful as the CPU does not see the WT when
accessing the cache. In particular, this means that we need to flush the
cache lines after writing to an object through the CPU, and on
transitioning from a cached state to WT.

v2: Actually do the clflush on transition to WT, nagging by Ville.
v3: Flush the CPU cache after writes into WT objects.
v4: Rease onto LLC updates and report WT as "uncached" for
get_cache_level_ioctl to remain symmetric with set_cache_level_ioctl.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:38 +02:00
Jani Nikula ea04cb31d5 drm/i915: drop unnecessary local variable to suppress build warning
Although I could not reproduce this (different compiler version,
perhaps), reportedly we get:

drivers/gpu/drm/i915/i915_irq.c:1943:27: warning: ‘score’ may be used
uninitialized in this function [-Wuninitialized]

Drop the 'score' variable altogether as it's not really needed.

Reported-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:38 +02:00
Jani Nikula f2f4d82faf drm/i915: give more distinctive names to ring hangcheck action enums
The short lowercase names are bound to collide. The default warnings
don't even warn about shadowing.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:37 +02:00
Jani Nikula c8b5018b22 drm/i915: remove unused leftover variable irq_received
It's been there since i8xx_irq_handler() was added in
commit c2798b19ba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Apr 22 21:13:57 2012 +0100

    drm/i915: i8xx interrupt handler

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:36 +02:00
Guillaume Clement 1ad87e72b5 i915: Fix SDVO potentially turning off randomly
Some Poulsbo cards seem to incorrectly report
SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of
SDVO_CMD_STATUS_PENDING, which causes the display to be turned off.

This could also happen to i915.

Signed-off-by: Guillaume Clement <gclement@baobob.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:36 +02:00
Ben Widawsky 7ace7ef2f5 drm/i915: WARN_ON failed map_and_fenceable
I just noticed in our code we don't really check the assertion, and
given some of the code I am changing in this area, I feel a WARN is very
nice to have.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: s/&/&&/ to fix typo on the check.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:35 +02:00
Chris Wilson 000433b67e drm/i915: Only do a chipset flush after a clflush
Now that we skip clflushes more often, return a boolean indicating
whether the clflush was actually performed, and only if it was do the
chipset flush. (Though on most of the architectures where the clflush will
be skipped, the chipset flush is a no-op!)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-22 13:31:34 +02:00
Dave Airlie 291d284c60 Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next
Here's some gma500 unifying and cleanups for drm-next. There is more stuff in
the pipe for 3.12 but I'd like to get these out of the way first.

* 'gma500-next' of git://github.com/patjak/drm-gma500: (35 commits)
  drm/gma500/cdv: Add and hook up chip op for disabling sr
  drm/gma500/cdv: Add and hook up chip op for watermarks
  drm/gma500: Rename psb_intel_encoder to gma_encoder
  drm/gma500: Rename psb_intel_connector to gma_connector
  drm/gma500: Rename psb_intel_crtc to gma_crtc
  drm/gma500/cdv: Convert to generic set_config()
  drm/gma500/psb: Convert to generic set_config()
  drm/gma500: Add generic set_config() function
  drm/gma500/cdv: Convert to generic save/restore
  drm/gma500/psb: Convert to generic save/restore
  drm/gma500: Add generic crtc save/restore funcs
  drm/gma500: Convert to generic encoder funcs
  drm/gma500: Add generic encoder functions
  drm/gma500/psb: Convert to generic cursor funcs
  drm/gma500/cdv: Convert to generic cursor funcs
  drm/gma500: Add generic cursor functions
  drm/gma500/psb: Convert to generic crtc->destroy
  drm/gma500/mdfld: Use identical generic crtc funcs
  drm/gma500/oak: Use identical generic crtc funcs
  drm/gma500/psb: Convert to gma_crtc_dpms()
  ...
2013-08-22 10:38:28 +10:00
Guillaume Clement 6f1e120438 gma500: Fix SDVO turning off randomly
Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, which causes the display to be turned off.

Signed-off-by: Guillaume Clement <gclement@baobob.org>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-22 10:37:49 +10:00
Dave Airlie 317b07b58c Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
regression fixes and null derefs and oops fixes.

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nv04/disp: fix framebuffer pin refcounting
  drm/nouveau/mc: fix race condition between constructor and request_irq()
  drm/nouveau: fix reclocking on nv40
  drm/nouveau/ltcg: fix allocating memory as free
  drm/nouveau/ltcg: fix ltcg memory initialization after suspend
  drm/nouveau/fb: fix null derefs in nv49 and nv4e init
2013-08-22 10:34:58 +10:00
Daniel Vetter d0b2c5334f drm/prime: Always add exported buffers to the handle cache
... not only when the dma-buf is freshly created. In contrived
examples someone else could have exported/imported the dma-buf already
and handed us the gem object with a flink name. If such on object gets
reexported as a dma_buf we won't have it in the handle cache already,
which breaks the guarantee that for dma-buf imports we always hand
back an existing handle if there is one.

This is exercised by igt/prime_self_import/with_one_bo_two_files

Now if we extend the locked sections just a notch more we can also
plug th racy buf/handle cache setup in handle_to_fd:

If evil userspace races a concurrent gem close against a prime export
operation we can end up tearing down the gem handle before the dma buf
handle cache is set up. When handle_to_fd gets around to adding the
handle to the cache there will be no one left to clean it up,
effectily leaking the bo (and the dma-buf, since the handle cache
holds a ref on the dma-buf):

Thread A			Thread B

handle_to_fd:

lookup gem object from handle
creates new dma_buf

				gem_close on the same handle
				obj->dma_buf is set, but file priv buf
				handle cache has no entry

				obj->handle_count drops to 0

drm_prime_add_buf_handle sets up the handle cache

-> We have a dma-buf reference in the handle cache, but since the
handle_count of the gem object already dropped to 0 no on will clean
it up. When closing the drm device fd we'll hit the WARN_ON in
drm_prime_destroy_file_private.

The important change is to extend the critical section of the
filp->prime.lock to cover the gem handle lookup. This serializes with
a concurrent gem handle close.

This leak is exercised by igt/prime_self_import/export-vs-gem_close-race

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 13:05:03 +10:00
Daniel Vetter de9564d8b9 drm/prime: make drm_prime_lookup_buf_handle static
... and move it to the top of the function to avoid a forward
declaration.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 13:00:31 +10:00
Daniel Vetter 838cd4455e drm/prime: Simplify drm_gem_remove_prime_handles
with the reworking semantics and locking of the obj->dma_buf pointer
this pointer is always set as long as there's still a gem handle
around and a dma_buf associated with this gem object.

Also, the per file-priv lookup-cache for dma-buf importing is also
unified between foreign and native objects.

Hence we don't need to special case the clean any more and can simply
drop the clause which only runs for foreing objects, i.e. with
obj->import_attach set.

Note that with this change (actually with the previous one to always
set up obj->dma_buf even for foreign objects) it is no longer required
to set obj->import_attach when importing a foreing object. So update
comments accordingly, too.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:58:18 +10:00
Daniel Vetter 319c933c71 drm/prime: proper locking+refcounting for obj->dma_buf link
The export dma-buf cache is semantically similar to an flink name. So
semantically it makes sense to treat it the same and remove the name
(i.e. the dma_buf pointer) and its references when the last gem handle
disappears.

Again we need to be careful, but double so: Not just could someone
race and export with a gem close ioctl (so we need to recheck
obj->handle_count again when assigning the new name), but multiple
exports can also race against each another. This is prevented by
holding the dev->object_name_lock across the entire section which
touches obj->dma_buf.

With the new scheme we also need to reinstate the obj->dma_buf link at
import time (in case the only reference userspace has held in-between
was through the dma-buf fd and not through any native gem handle). For
simplicity we don't check whether it's a native object but
unconditionally set up that link - with the new scheme of removing the
obj->dma_buf reference when the last handle disappears we can do that.

To make it clear that this is not just for exported buffers anymore
als rename it from export_dma_buf to dma_buf.

To make sure that now one can race a fd_to_handle or handle_to_fd with
gem_close we use the same tricks as in flink of extending the
dev->object_name_locking critical section. With this change we finally
have a guaranteed 1:1 relationship (at least for native objects)
between gem objects and dma-bufs, even accounting for races (which can
happen since the dma-buf itself holds a reference while in-flight).

This prevent igt/prime_self_import/export-vs-gem_close-race from
Oopsing the kernel. There is still a leak though since the per-file
priv dma-buf/handle cache handling is racy. That will be fixed in a
later patch.

v2: Remove the bogus dma_buf_put from the export_and_register_object
failure path if we've raced with the handle count dropping to 0.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:58:17 +10:00
Daniel Vetter 20228c4478 drm/gem: completely close gem_open vs. gem_close races
The gem flink name holds a reference onto the object itself, and this
self-reference would prevent an flink'ed object from every being
freed. To break that loop we remove the flink name when the last
userspace handle disappears, i.e. when obj->handle_count reaches 0.

Now in gem_open we drop the dev->object_name_lock between the flink
name lookup and actually adding the handle. This means a concurrent
gem_close of the last handle could result in the flink name getting
reaped right inbetween, i.e.

Thread 1		Thread 2
gem_open		gem_close

flink -> obj lookup
			handle_count drops to 0
			remove flink name
create_handle
handle_count++

If someone now flinks this object again, we'll get a new flink name.

We can close this race by removing the lock dropping and making the
entire lookup+handle_create sequence atomic. Unfortunately to still be
able to share the handle_create logic this requires a
handle_create_tail function which drops the lock - we can't hold the
object_name_lock while calling into a driver's ->gem_open callback.

Note that for flink fixing this race isn't really important, since
racing gem_open against gem_close is clearly a userspace bug. And no
matter how the race ends, we won't leak any references.

But with dma-buf where the userspace dma-buf fd itself is refcounted
this is a valid sequence and hence we should fix it. Therefore this
patch here is just a warm-up exercise (and for consistency between
flink buffer sharing and dma-buf buffer sharing with self-imports).

Also note that this extension of the critical section in gem_open
protected by dev->object_name_lock only works because it's now a
mutex: A spinlock would conflict with the potential memory allocation
in idr_preload().

This is exercises by igt/gem_flink_race/flink_name.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:58:17 +10:00
Daniel Vetter cd4f013f3a drm/gem: switch dev->object_name_lock to a mutex
I want to wrap the creation of a dma-buf from a gem object in it,
so that the obj->export_dma_buf cache can be atomically filled in.

Instead of creating a new mutex just for that variable I've figured
I can reuse the existing dev->object_name_lock, especially since
the new semantics will exactly mirror the flink obj->name already
protected by that lock.

v2: idr_preload/idr_preload_end is now an atomic section, so need to
move the mutex locking outside.

[airlied: fix up conflict with patch to make debugfs use lock]

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:58:01 +10:00
Daniel Vetter 84341c280a drm/prime: clarify logic a bit in drm_gem_prime_fd_to_handle
if (!ret) implies that ret == 0, so no need to clear it again. And
explicitly check for ret == 0 to indicate that we're checking an errno
integer.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:53:46 +10:00
Daniel Vetter bdf655de47 drm/prime: shrink critical section protected by prime lock
When exporting a gem object as a dma-buf the critical section for the
per-fd prime lock is just the adding (and in case of errors, removing)
of the handle to the per-fd lookup cache.

So restrict the critical section to just that part of the function.

This simplifies later reordering.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:53:46 +10:00
Daniel Vetter 4332bf438b drm/prime: use proper pointer in drm_gem_prime_handle_to_fd
Part of the function uses the properly-typed dmabuf variable, the
other an untyped void *buf. Kill the later.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:53:46 +10:00
Daniel Vetter becee2a57f drm/gem: make drm_gem_object_handle_unreference_unlocked static
No one outside of drm should use this, the official interfaces are
drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
is purely an implementation detail of gem.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:53:46 +10:00
Daniel Vetter 730c4ff95e drm/prime: fix error path in drm_gem_prime_fd_to_handle
handle_unreference only clears up the obj->name and the reference,
but would leave a dangling handle in the idr. The right thing
to do is to call handle_delete.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:53:46 +10:00
Daniel Vetter a8e11d1c43 drm/gem: fix up flink name create race
This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:

http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html

The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a zero handle
count, but an flink name (and it's corresponding reference). Which
results in a neat space leak.

In my first attempt I've solved this by rechecking the handle count.
But fundamentally the issue is that ->handle_count isn't your usual
refcount - it can be resurrected from 0 among other things.

For those special beasts atomic_t often suggest way more ordering that
it actually guarantees. To prevent being tricked by those hairy
semantics take the easy way out and simply protect the handle with the
existing dev->object_name_lock.

With that change implemented it's dead easy to fix the flink vs. gem
close reace: When we try to create the name we simply have to check
whether there's still officially a gem handle around and if not refuse
to create the flink name. Since the handle count decrement and flink
name destruction is now also protected by that lock the reace is gone
and we can't ever leak the flink reference again.

Outside of the drm core only the exynos driver looks at the handle
count, and tbh I have no idea why (it's just for debug dmesg output
luckily).

I've considered inlining the drm_gem_object_handle_free, but I plan to
add more name-like things (like the exported dma_buf) to this scheme,
so it's clearer to leave the handle freeing in its own function.

This is exercised by the new gem_flink_race i-g-t testcase, which on
my snb leaks gem objects at a rate of roughly 1k objects/s.

v2: Fix up the error path handling in handle_create and make it more
robust by simply calling object_handle_unreference.

v3: Fix up the handle_unreference logic bug - atomic_dec_and_test
retursn 1 for 0. Oops.

v4: Squash in inlining of drm_gem_object_handle_reference as suggested
by Dave Airlie and add a note that we now have a testcase.

Cc: Dave Airlie <airlied@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:53:45 +10:00
Dave Airlie 9712def2b3 Merge tag 'drm-intel-next-2013-08-09' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:
New pile of stuff for -next:
- Cleanup of the old crtc helper callbacks, all encoders are now converted
  to the i915 modeset infrastructure.
- Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is
  prep work to eventually get things going for nuclear pageflips where we
  need to adjust watermarks on the fly.
- More vm/vma patches from Ben. This refactoring isn't yet fully rolled
  out, we miss the execbuf conversion and some of the low-level
  bind/unbind support code.
- Convert our hdmi infoframe code to use the new common helper functions
  (Damien). This contains some bugfixes for the common infoframe helpers.
- Some cruft removal from Damien.
- Various smaller bits&pieces all over, as usual.

* tag 'drm-intel-next-2013-08-09' of git://people.freedesktop.org/~danvet/drm-intel: (105 commits)
  drm/i915: Fix FB WM for HSW
  drm/i915: expose HDMI connectors on port C on BYT
  drm/i915: fix a limit check in hsw_compute_wm_results()
  drm/i915: unbreak i915_gem_object_ggtt_unbind()
  drm/i915: Make intel_set_mode() static
  drm/i915: Remove intel_modeset_disable()
  drm/i915: Make intel_encoder_dpms() static
  drm/i915: Make i915_hangcheck_elapsed() static
  drm/i915: Fix #endif comment
  drm/i915: Remove i915_gem_object_check_coherency()
  drm/i915: Remove stale prototypes
  drm/i915: List objects allocated from stolen memory in debugfs
  drm/i915: Always call intel_update_sprite_watermarks() when disabling a plane
  drm/i915: Pass plane and crtc to intel_update_sprite_watermarks
  drm/i915: Don't try to disable plane if it's already disabled
  drm/i915: Pass crtc to our update/disable_plane hooks
  drm/i915: Split plane watermark parameters into a separate struct
  drm/i915: Pull some watermarks state into a separate structure
  drm/i915: Calculate max watermark levels for ILK+
  drm/i915: Rename hsw_lp_wm_result to intel_wm_level
  ...
2013-08-21 12:48:59 +10:00
Lespiau, Damien 66cc8b6b8b drm: Make drm_get_platform_dev() static
It's only used in drm_platform.c.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:47:56 +10:00
Lespiau, Damien 2c9c52e853 drm: Make drm_fb_cma_describe() static
This function is only used in drm_fb_cma_helper.c.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:47:41 +10:00
Lespiau, Damien 86f422d5be drm: Make drm_mode_remove() static
It's only used in drm_crtc.c.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:47:29 +10:00
Lespiau, Damien 67587e8689 drm: Remove drm_mode_list_concat()
The last user was removed in

  commit 575dc34ee0
  Author: Dave Airlie <airlied@redhat.com>
  Date:   Mon Sep 7 18:43:26 2009 +1000

      drm/kms: remove old std mode fallback code.

      The new code adds modes in the helper, which makes more sense
      I disliked the non-driver code adding modes.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:47:24 +10:00
Lespiau, Damien ddecb10cf4 drm: Remove drm_mode_create_dithering_property()
This was last used by nouveau, replaced by a driver-specific property
in:

  commit de69185573
  Author: Ben Skeggs <bskeggs@redhat.com>
  Date:   Mon Oct 17 12:23:41 2011 +1000

      drm/nouveau: improve dithering properties, and implement proper auto mode

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21 12:47:19 +10:00
Ben Skeggs 78ae0ad403 drm/nv04/disp: fix framebuffer pin refcounting
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-08-21 11:36:21 +10:00
Ben Skeggs 6ff8c76a56 drm/nouveau/mc: fix race condition between constructor and request_irq()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-08-21 11:36:20 +10:00
Pali Rohár 0ff42c5af6 drm/nouveau: fix reclocking on nv40
In commit 77145f1cbd was introduced
error which cause that reclocking on nv40 not working anymore.
There is missing assigment of return value from pll_calc to ret.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-08-21 11:36:08 +10:00
Maarten Lankhorst 18902bbf06 drm/nouveau/ltcg: fix allocating memory as free
Allocating type=0 marks the memory as free. This allows the ltcg memory
to be allocated twice.

Add a BUG_ON in core/mm.c to prevent this ever happening again.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-08-21 11:35:53 +10:00
Maarten Lankhorst 52f9a4d71b drm/nouveau/ltcg: fix ltcg memory initialization after suspend
Some registers were not initialized in init, this causes them to be
uninitialized after suspend.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-08-21 11:35:53 +10:00
Ilia Mirkin 6284bf41b9 drm/nouveau/fb: fix null derefs in nv49 and nv4e init
Commit dceef5d87 (drm/nouveau/fb: initialise vram controller as pfb
sub-object) moved some code around and introduced these null derefs.
pfb->ram is set to the new ram object outside of this ctor.

Reported-by: Ronald Uitermark <ronald645@gmail.com>
Tested-by: Ronald Uitermark <ronald645@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-08-21 11:35:53 +10:00
Michael Witten 0dc5d4f708 Docs: Comment: Fixed egregious typos
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-08-20 12:44:51 +02:00
Daniel Vetter f336ab7600 drm: move dev data clearing from drm_setup to lastclose
We kzalloc this structure, and for real kms devices we should never
loose track of things really.

But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
conditionalize the code on !DRIVER_MODESET.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:29:41 +10:00
Daniel Vetter cb6458f97b drm: remove procfs code, take 2
So almost two years ago I've tried to nuke the procfs code already
once before:

http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html

The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging it turned out that the drmstat tool in libdrm is still using
those files (but only when certain options are set). So we've decided
to keep profcs.

But I when I've started to dig around again what exactly this tool
does I've noticed that it tries to read the "mem", "vm", and "vma"
files from procfs. Now as far my git history digging shows "mem" never
did anything useful (at least in the version that first showed up in
upstream history in 2004) and the file was remove in

commit 955b12def4
Author: Ben Gamari <bgamari@gmail.com>
Date:   Tue Feb 17 20:08:49 2009 -0500

    drm: Convert proc files to seq_file and introduce debugfs

Which means that for over 4 years drmstat has been broken, and no one
cared. In my opinion that's proof enough that no one is actually using
drmstat, and so that we can savely nuke the procfs support from drm.

While at it fix up the error case cleanup for debugfs in drm_get_minor.

v2: Fix dates, libdrm stopped relying on procfs for drm node detection
in 2001.

v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by
Fengguang Wu.

Cc: kbuild test robot <fengguang.wu@intel.com>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:29:24 +10:00
Daniel Vetter 7d14bb6b53 drm: don't call ->firstopen for KMS drivers
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.

v2: Don't forget to update DocBook.

v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:28:46 +10:00
Daniel Vetter 0faa4a8777 drm/vmwgfx: remove ->firstopen callback
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
  radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)

In short besides the semantically important vga switcheroo stuff they
all try very hard to keep fbcon working in case X dies.

But none of them try to not do this at driver unload time safe for
vmwgfx, and digging through logs I couldn't find any reason for why
vmwgfx is special.

Since ->firstopen has lots of potential for abuse with kms drivers
(like delaying driver setup to pamper over races in the load sequence)
it's imo very much worth it to remove this logic so that we can
stop using the ->firstopen callback for kms drivers.

Also module unloading is rather a debug feature and developers should
know how to restore the display to a sane configuration.

Cc: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:28:07 +10:00
Kristian Høgsberg 24f4003267 drm: fix minor number range calculation
Currently, both ranges overlap. Fix the limits so both ranges are mutually
exclusive. Also use the occasion to convert whitespaces to tabs.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
(fixed up tabs and adjust commit-msg accordingly)
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:22:29 +10:00
Daniel Vetter 90254ac084 drm: fix locking in gem debugfs/procfs file
The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:16:47 +10:00
Daniel Vetter 6eb9278ada drm: remove the dma_ioctl special-case
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.

To make really sure no mis-guided user in a kms driver pops up again
explicitly check for that in the new ioctl implementation.

v2: Drop the unused variable I've accidentally left in the code,
spotted by David Herrmann.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:15:50 +10:00
Daniel Vetter 281856477c drm: rip out drm_core_has_MTRR checks
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.

David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected drivers. David helped a lot in that. Quoting our mail
discussion:

On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>>> -#if __OS_HAS_MTRR
>>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>>> -{
>>>> -       return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>>> -}
>>>> -#else
>>>> -#define drm_core_has_MTRR(dev) (0)
>>>> -#endif
>>>> -
>>>
>>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting
>>> it in .driver_features). Any reason to keep it around?
>>
>> Yeah, I guess we could rip things out. Which will also force me to
>> properly audit drivers for the eventual behaviour change this could
>> entail (in case there's an x86 driver which did not ask for an mtrr,
>> but iirc there isn't).
>
> david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
> test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
> fi ; done
> drivers/gpu/drm/exynos
> drivers/gpu/drm/gma500
> drivers/gpu/drm/i2c
> drivers/gpu/drm/nouveau
> drivers/gpu/drm/omapdrm
> drivers/gpu/drm/qxl
> drivers/gpu/drm/rcar-du
> drivers/gpu/drm/shmobile
> drivers/gpu/drm/tilcdc
> drivers/gpu/drm/ttm
> drivers/gpu/drm/udl
> drivers/gpu/drm/vmwgfx
> david@david-mb ~/dev/kernel/linux $
>
> So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
> But I cannot tell whether they break if we call arch_phys_wc_add/del,
> anyway. At least nouveau seemed to work here, but it doesn't use AGP
> or drm_bufs, I guess.

Cool, thanks a lot for stitching together the list of drivers to look
at. So for real KMS drivers it's the drives responsibility to add an
mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
already. Somehow the savage driver also ends up doing that, I have no
idea why.

Note that gma500 as a pure KMS driver doesn't need MTRR setup since
the platforms that it supports all support PAT. So no MTRRs needed to
get wc iomappings.

The mtrr support in the drm core is all for legacy mappings of garts,
framebuffers and registers. All legacy drivers set the USE_MTRR flag,
so we're good there.

All in all I think we can really just ditch this

/endquote

v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann

v3: Rebase on top of David Herrmann's agp setup/cleanup changes.

Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 14:11:44 +10:00
Dave Airlie 3387ed8394 Merge tag 'drm-intel-fixes-2013-08-15' of git://people.freedesktop.org/~danvet/drm-intel
* tag 'drm-intel-fixes-2013-08-15' of git://people.freedesktop.org/~danvet/drm-intel: (153 commits)
  drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code
2013-08-19 13:49:20 +10:00
Daniel Vetter eb91626ac4 drm/i915: unpin backing storage in dmabuf_unmap
This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.

v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces for our own, reimported buffers. But it's still easy to
blow up and anger lockdep, but that's already the case with our ->map
implementation. Fixing this for real will involve per dma-buf ww mutex
locking by the callers. And lots of fun. So go with the duct-tape
approach for now.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Armin K. <krejzi@email.com> (v1)
Tested-by: Dave Airlie <airlied@redhat.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-19 13:24:54 +10:00
Daniel Vetter 1216f73237 drm/gem: WARN about unbalanced handle refcounts
Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.

So scream into dmesg with a big WARN in case that ever happens.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:47:37 +10:00
Daniel Vetter 6bc505b86a drm/gem: remove bogus NULL check from drm_gem_object_handle_unreference_unlocked
Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:47:13 +10:00
Daniel Vetter 36da5908a2 drm/gem: move drm_gem_object_handle_unreference_unlocked into drm_gem.c
We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.

Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and remove the unused EXPORT_SYMBOL). To
avoid a forward declaration move it (and drm_gem_object_free_bug) up a
bit.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:46:56 +10:00
Daniel Vetter 01ce605a7b drm/prime: remove cargo-cult locking from map_sg helper
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).

Only the grabbing of the underlying page array is anything we need to
be concerned about, and either those pages are pinned independently,
or we're screwed no matter what.

And indeed, nouveau/radeon pin the backing storage in their
attach/detach functions.

Since I've created this patch cma prime support for dma_buf was added.
drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps
the sg table with dma_get_sgtable. It doesn't touch any gem object
state otherwise. So the cma helpers also look safe.

The only thing we might claim it does is prevent concurrent mapping of
dma_buf attachments. But a) that's not allowed and b) the current code
is racy already since it checks whether the sg mapping exists _before_
grabbing the lock.

So the dev->struct_mutex locking here does absolutely nothing useful,
but only distracts. Remove it.

This should also help Maarten's work to eventually pin the backing
storage more dynamically by preventing locking inversions around
dev->struct_mutex.

v2: Add analysis for recently added cma helper prime code.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:46:16 +10:00
Inki Dae d0ed8d27fa drm/exynos: explicit store base gem object in dma_buf->priv
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:45:38 +10:00
Daniel Vetter c1d6798d20 drm: use common drm_gem_dmabuf_release in i915/exynos drivers
Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.

To use the release helper we need to export it, too.

Cc: Inki Dae <inki.dae@samsung.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:44:58 +10:00
David Herrmann 2bc7b0ca8c drm/host1x: stop casting VMA offsets to 32bit
VMA offsets are 64bit so do not cast them to "unsigned int". Also remove
the (now useless) offset-retrieval helper. The VMA manager provides simple
enough helpers.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: "Terje Bergström" <tbergstrom@nvidia.com>
Cc: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:40:46 +10:00
Ilia Mirkin b21e3afe23 drm: use ida to allocate connector ids
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:40:31 +10:00
Rob Clark ddcd09d62b drm/omap: kill omap_gem_helpers.c
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:36:16 +10:00
Rob Clark 5dc9e1e872 drm/udl: use gem get/put page helpers
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:36:12 +10:00
Rob Clark 8b9ba7a38c drm/gma500: use gem get/put page helpers
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:36:08 +10:00
Rob Clark bcc5c9d50e drm/gem: add shmem get/put page helpers
Basically just extracting some code duplicated in gma500, omapdrm, udl,
and upcoming msm driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:36:04 +10:00
Rob Clark 367bbd4920 drm/gem: add drm_gem_create_mmap_offset_size()
Variant of drm_gem_create_mmap_offset() which doesn't make the
assumption that virtual size and physical size (obj->size) are the same.
This is needed in omapdrm to deal with tiled buffers.  And lets us get
rid of a duplicated and slightly modified version of
drm_gem_create_mmap_offset() in omapdrm.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:34:43 +10:00
Rob Clark 5833bd2fe1 drm/omap: use flip-work helper
And simplify how we hold a ref+pin to what is being scanned out by using
fb refcnt'ing.  The previous logic pre-dated fb refcnt, and as a result
was less straightforward than it could have been.  By holding a ref to
the fb, we don't have to care about how many plane's there are and
holding a ref to each color plane's bo.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:33:39 +10:00
Rob Clark a464d618c7 drm/tilcdc: use flip-work helper
Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:33:36 +10:00
Rob Clark cabaafc789 drm: add flip-work helper
A small helper to queue up work to do, from workqueue context, after a
flip.  Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.

v1: original
v2: wire up docbook + couple docbook fixes

Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:32:26 +10:00
Stéphane Marchesin b17df86ece drm: Remove drm_mode_validate_clocks
This function is unused.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:30:11 +10:00
Daniel Vetter d79cdc8312 drm: no-op out GET_STATS ioctl
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.

So I don't see any use for this stat gathering complexity at all.

To be able to gradually drop things start with ripping out the
interfaces to it, here the ioctl.

To prevent dristat from eating its own stack garbage we can't use the
drm_noop ioctl though, since we need to clear the return data with a
memset.

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:06:24 +10:00
Daniel Vetter 719524df4a drm: hollow-out GET_CLIENT ioctl
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.

I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tests/dristat.c and drm/tests/getclients.c. The later
is a testcase for the ioctl itself since up to

commit b018fcdaa5
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Nov 22 18:46:54 2007 +1000

    drm: Make DRM_IOCTL_GET_CLIENT return EINVAL when it can't find client #idx

there was actually no way at all for userspace to enumerate all
clients since the kernel just wouldn't tell it when to stop. Which
completely broke it's only user, dristat -c.

So obviously that ioctl wasn't much use for debugging. Hence I don't
see any point in keeping support for a tool which was pretty obviously
never really used, and while we have good replacements in the form of
equivalent debugfs files.

Still, to keep dristat -c from looping forever again stop it early by
returning an unconditional -EINVAL. Also add a comment in the code
about why.

v2: Slightly less hollowed-out implementation. libva uses GET_CLIENTS
to figure out whether the fd it has is already authenticated or not.
So we need to keep that part of things working. Simplest way is to
just return one entry to keep va_drm_is_authenticated in
libva/va/drm/va_drm_auth.c working.

This is exercised by igt/drm_get_client_auth which contains a
copypasta of the libva auth check code.

Cc: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:05:54 +10:00
Daniel Vetter d678959f0a drm/memory: don't export agp helpers
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.

I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that upper-case P sometimes ;-) But that's all stuff for future patch
bombs.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:05:53 +10:00
Daniel Vetter 74867e3d53 drm: rip out a few unused DRIVER flags
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:05:28 +10:00
Daniel Vetter 687fbb2e4f drm: rip out DRIVER_FB_DMA and related code
No driver ever sets that flag, so good riddance!

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:05:19 +10:00
Daniel Vetter b0e898ac55 drm: remove FASYNC support
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.

First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...

Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.

No merged drm driver has ever done that.

After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:

commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <airlied@linux.ie>
Date:   Sun Aug 29 12:04:35 2004 +0000

    Drop GAMMA DRM from a great height ...

Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.

So stop this particular cargo-cult and rip it all out.

v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.

v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.

v4: Actually git add ... tsk.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:05:17 +10:00
Daniel Vetter 5bbd533248 drm/vmwgfx: remove redundant clearing of driver->dma_quiescent
It's kzalloced ...

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:05:04 +10:00
Daniel Vetter 7c510133d9 drm: mark context support as a legacy subsystem
So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).

Also add the drm_legacy prefix for functions which are called from
common code. To further reduce the impact on common code also extract
all the ctx release handling into a function (instead of only
releasing individual handles) and make ctxbitmap_cleanup return void -
it can never fail.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:04:48 +10:00
Daniel Vetter 8d38c4b437 drm: disallow legacy dma ioctls for modesetting drivers
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature
flag set, so strictly speaking the modesetting check is redundant. But
adding it has the upside that it makes it very clear that the dma
support is legacy stuff.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:04:34 +10:00
Daniel Vetter e2e99a8206 drm: mark dma setup/teardown as legacy systems
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:04:21 +10:00
Daniel Vetter 8e194bbf96 drm: disallow legacy sg ioctls for modesetting drivers
Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.

So we can safely disallow these pair of ioctls for modesetting
drivers.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:04:06 +10:00
Daniel Vetter 3d914e8357 drm: hide legacy sg cleanup better from common code
I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:03:49 +10:00
Daniel Vetter 45886af246 drm: kill dev->driver->set_version
Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:03:26 +10:00
Daniel Vetter d8ed16884a drm/radeon: kill firstopen callback for kms driver
Again, it does nothing.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 10:03:15 +10:00
Daniel Vetter 161695bf64 drm/omap: kill firstopen callback
KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:40:01 +10:00
Maarten Lankhorst 5c692948d8 drm/ttm: kill unused functions
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:36:12 +10:00
David Herrmann e552df37ad drm/radeon: remove stale gem->driver_private access
This field is never read. No need to set it in radeon. Besides, DRM gem
core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:34:47 +10:00
David Herrmann f547b22aaf drm/qxl: remove unused object_pin/unpin() helpers
These two helpers are unused. Remove them. They rely on
gem_obj->driver_private, which is set to NULL during setup. As this field
isn't used by the driver, anymore, we can remove this assignment as well.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:34:41 +10:00
David Herrmann 23a9a2e075 drm/cirrus: remove unused driver_private access
gem_bo->driver_private is never read by cirrus nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:34:38 +10:00
David Herrmann 7d2e968e2b drm/mgag200: remove unused driver_private access
gem_bo->driver_private is never read by mgag200 nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:34:35 +10:00
David Herrmann 7e0e6cbd03 drm/ast: remove unused driver_private access
gem_bo->driver_private is never read by ast nor DRM core. No need to set
it. Besides, drm core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:34:30 +10:00
Dave Airlie 1dda8d02ac Merge remote-tracking branch 'pfdo/drm-rcar-for-v3.12' into drm-next
Merge the rcar stable branch that is being shared with the arm-soc tree.

Signed-off-by: Dave Airlie <airlied@redhat.com>
* pfdo/drm-rcar-for-v3.12: (220 commits)
  drm/rcar-du: Add FBDEV emulation support
  drm/rcar-du: Add internal LVDS encoder support
  drm/rcar-du: Configure RGB output routing to DPAD0
  drm/rcar-du: Rework output routing support
  drm/rcar-du: Add support for DEFR8 register
  drm/rcar-du: Add support for multiple groups
  drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU
  drm/rcar-du: Add support for the R8A7790 DU
  drm/rcar-du: Move output routing configuration to group
  drm/rcar-du: Remove register definitions for the second channel
  drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size
  drm/rcar-du: Introduce CRTCs groups
  drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*
  drm/rcar-du: Create rcar_du_planes structure
  drm/rcar-du: Rename platform data fields to match what they describe
  drm/rcar-du: Merge LVDS and VGA encoder code
  drm/rcar-du: Split VGA encoder and connector
  drm/rcar-du: Split LVDS encoder and connector
  drm/rcar-du: Clarify comment regarding plane Y source coordinate
  drm/rcar-du: Support per-CRTC clock and IRQ
  ...

Conflicts:
	drivers/gpu/drm/i915/i915_dma.c
	drivers/gpu/drm/i915/intel_pm.c
	drivers/gpu/drm/qxl/qxl_release.c
2013-08-19 09:24:13 +10:00
Darren Etheridge a976718867 drm/tilcdc fixup mode to workaround sync for tda998x
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.

Signed-off-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:54 +10:00
Sebastian Hesselbarth 179f1aa407 drm/i2c: tda998x: prepare for broken sync workaround
Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.

Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:48 +10:00
Sebastian Hesselbarth 088d61d1fd drm/i2c: tda998x: fix sync generation and calculation
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:38 +10:00
Russell King c4c11dd160 drm/i2c: tda998x: add video and audio input configuration
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:32 +10:00
Russell King 5e74c22cd1 drm/i2c: tda998x: prepare for video input configuration
The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:19 +10:00
Russell King 20c17675fe drm/i2c: tda998x: fix npix/nline programming
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:13 +10:00
Russell King bcb2481df0 drm/i2c: tda998x: ensure VIP output mux is properly set
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation.  One such case encountered is the VIP output
mux register.  This defaults to 0x24 on powerup, but other drivers may
set this to 0x12.  This results in incorrect colours.

Fix this by ensuring that the register is always set to the power on
default setting.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:07 +10:00
Russell King 063b472fbb drm/i2c: tda998x: fix EDID reading on TDA19988 devices
TDA19988 devices need their RAM enabled in order to read EDID
information.  Add support for this.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:10:00 +10:00
Geert Uytterhoeven cc6a36f2fe drm: DRM should depend on HAS_DMA
If NO_DMA=y:

drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_gem_unmap_dma_buf':
drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `drm_gem_map_dma_buf':
drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg'

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19 09:09:10 +10:00
Chris Wilson 884020bf3d drm/i915: Invalidate TLBs for the rings after a reset
After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write the shadow registers and
breadcrumbs into the old physical address (now used by something
completely different, scary). Whereas the driver would read the new
status page and never see any progress, it would appear that the GPU
hung immediately upon resume.

Based on a patch by naresh kumar kachhi <naresh.kumar.kacchi@intel.com>

Reported-by: Thiago Macieira <thiago@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thiago Macieira <thiago@kde.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-18 19:37:41 +02:00
Rafał Miłecki d43a93c8d9 drm/radeon: fix WREG32_OR macro setting bits in a register
This bug (introduced in 3.10) in WREG32_OR made
commit d3418eacad
"drm/radeon/evergreen: setup HDMI before enabling it"
cause a regression. Sometimes audio over HDMI wasn't working, sometimes
display was corrupted.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60687
https://bugzilla.kernel.org/show_bug.cgi?id=60709
https://bugs.freedesktop.org/show_bug.cgi?id=67767

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-15 12:59:45 -04:00
Patrik Jakobsson 75346fe9bc drm/gma500/cdv: Add and hook up chip op for disabling sr
Add a callback hook to the chip ops struct to allow chips to have their
specific self-refresh function. Currently only used by cdv.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-08-15 00:54:44 +02:00
Alex Deucher 022374c02e drm/radeon/r7xx: fix copy paste typo in golden register setup
Uses the wrong array size for some asics which can lead
to garbage getting written to registers.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60674

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2013-08-14 18:03:40 -04:00
Patrik Jakobsson 28a8194c12 drm/gma500/cdv: Add and hook up chip op for watermarks
Add a callback hook to the chip ops struct to allow chips to have their
specific fifo watermark update function. Currently only cdv actually
tries to set wms based on crtc configuration but if/when the other chips
needs it we can attach a callback for them as well.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-08-14 20:44:52 +02:00
Chris Wilson 63b66e5ba5 drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code
If we get an error event really early in the driver setup sequence,
which gen3 is especially prone to with various display GTT faults we
Oops. So try to avoid this.

Additionally with Haswell the transcoders are a separate bank of
registers from the pipes (4 transcoders, 3 pipes). In event of an
error, we want to be sure we have a complete and accurate picture of
the machine state, so record all the transcoders in addition to all
the active pipes.

This regression has been introduced in

commit 702e7a56af
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Oct 23 18:29:59 2012 -0200

    drm/i915: convert PIPECONF to use transcoder instead of pipe

Based on the patch "drm/i915: Dump all transcoder registers on error"
from Chris Wilson:

v2: Rebase so that we don't try to be clever and try to figure out the
cpu transcoder from hw state. That exercise should be done when we
analyze the error state offline.

The actual bugfix is to not call intel_pipe_to_cpu_transcoder in the
error state capture code in case the pipes aren't fully set up yet.

v3: Simplifiy the err->num_transcoders computation a bit. While at it
make the error capture stuff save on systems without a display block.

v4: Fix fail, spotted by Jani.

v5: Completely new commit message, cc: stable.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60021
Cc: stable@vger.kernel.org
Tested-by: Dustin King <daking@rescomp.stanford.edu>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-14 20:26:49 +02:00
Christian König 112a6d0c07 drm/radeon: fix UVD message buffer validation
When the message buffer is currently moving block until it is idle again.

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-12 10:46:02 -04:00
Chris Wilson d46f1c3f13 drm/i915: Allow the GPU to cache stolen memory
As a corollary to reviewing the interaction between LLC and our cache
domains, the GPU PTE bits are independent of the CPU PAT bits. As such
we can set the cache level on stolen memory based on how we wish the GPU
to cache accesses to it. So we are free to set the same default cache
levels as for normal bo, i.e. enable LLC cacheing by default where
appropriate.

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>
2013-08-10 11:24:18 +02:00
Chris Wilson 2c22569bba drm/i915: Update rules for writing through the LLC with the cpu
As mentioned in the previous commit, reads and writes from both the CPU
and GPU go through the LLC. This gives us coherency between the CPU and
GPU irrespective of the attribute settings either device sets. We can
use to avoid having to clflush even uncached memory.

Except for the scanout.

The scanout resides within another functional block that does not use
the LLC but reads directly from main memory. So in order to maintain
coherency with the scanout, writes to uncached memory must be flushed.
In order to optimize writes elsewhere, we start tracking whether an
framebuffer is attached to an object.

v2: Use pin_display tracking rather than fb_count (to ensure we flush
cursors as well etc) and only force the clflush along explicit writes to
the scanout paths (i.e. pin_to_display_plane and pwrite into scanout).

v3: Force the flush after hitting the slowpath in pwrite, as after
dropping the lock the object's cache domain may be invalidated. (Ville)

Based on a patch by Ville Syrjälä.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-10 11:20:49 +02:00
Chris Wilson cc98b413c1 drm/i915: Track when an object is pinned for use by the display engine
The display engine has unique coherency rules such that it requires
special handling to ensure that all writes to cursors, scanouts and
sprites are clflushed. This patch introduces the infrastructure to
simply track when an object is being accessed by the display engine.

v2: Explain the is_pin_display() magic as the sources for obj->pin_count
and their individual rules is not obvious. (Ville)

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>
2013-08-10 11:19:51 +02:00
Chris Wilson c76ce038e3 drm/i915: Update rules for reading cache lines through the LLC
The LLC is a fun device. The cache is a distinct functional block within
the SA that arbitrates access from both the CPU and GPU cores. As such
all writes to memory land first in the LLC before further action is
taken. For example, an uncached write from either the CPU or GPU will
then proceed to memory and evict the cacheline from the LLC. This means that
a read from the LLC always returns the correct information even if the PTE
bit in the GPU differs from the PAT bit in the CPU. For the older
snooping architecture on non-LLC, the fundamental principle still holds
except that some coordination is required between the CPU and GPU to
explicitly perform the snooping (which is handled by our request
tracking).

The upshot of this is that we know that we can issue a read from either
LLC devices or snoopable memory and trust the contents of the cache -
i.e. we can forgo a clflush before a read in these circumstances.
Writing to memory from the CPU is a little more tricky as we have to
consider that the scanout does not read from the CPU cache at all, but
from main memory. So we have to currently treat all requests to write to
uncached memory as having to be flushed to main memory for coherency
with all consumers.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-10 11:19:50 +02:00
Laurent Pinchart 3864c6f446 drm/rcar-du: Add FBDEV emulation support
Use the FB CMA helpers to implement FBDEV emulation support. The VGA
connector status must be reported as connector_status_connected instead
of connector_status_unknown to be usable by the emulation layer.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:54 +02:00
Laurent Pinchart 90374b5c25 drm/rcar-du: Add internal LVDS encoder support
The R8A7790 includes two internal LVDS encoders. Support them in the DU
driver.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:53 +02:00
Laurent Pinchart 7cbc05cb51 drm/rcar-du: Configure RGB output routing to DPAD0
The R8A7790 DU variant has a single RGB output called DPAD0 that can be
fed with the output of DU0, DU1 or DU2. Making the routing configurable.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:52 +02:00
Laurent Pinchart ef67a902e9 drm/rcar-du: Rework output routing support
Split the output routing specification between SoC-internal data,
specified in the rcar_du_device_info structure, and board data, passed
through platform data.

The DU has 5 possible outputs (DPAD0/1, LVDS0/1, TCON). SoC-internal
output routing data specify which output are valid, which CRTCs can be
connected to the valid outputs, and the type of in-SoC encoder for the
output.

Platform data then specifies external encoders and the output they are
connected to.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:52 +02:00
Laurent Pinchart 38b62fb380 drm/rcar-du: Add support for DEFR8 register
The R8A7790 DU has a new extended function control register. Support it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:51 +02:00
Laurent Pinchart a5f0ef593c drm/rcar-du: Add support for multiple groups
The R8A7790 DU has 3 CRTCs, split in two groups. Support them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:50 +02:00
Laurent Pinchart 9e2d2de9e8 drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU
The R8A7790 DU seems to require a 128 bytes pitch alignment, even though
the documentation only mentions a 16 pixels alignement as for the
R8A7779 DU. Make this configurable through a device flag.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:49 +02:00
Laurent Pinchart ef2d84bec6 drm/rcar-du: Add support for the R8A7790 DU
The DU revision in the R8A7790 SoC uses one IRQ and clock per CRTC. Add
a corresponding entry in the module platform ID table.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:49 +02:00
Laurent Pinchart 2fd22dba23 drm/rcar-du: Move output routing configuration to group
Output routing is configured in group registers, move the corresponding
code from rcar_du_crtc.c to rcar_du_group.c.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:48 +02:00
Laurent Pinchart 660bab56aa drm/rcar-du: Remove register definitions for the second channel
Channels are accessed through a global channel memory offset, there's no
need to define register addresses for the second channel.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:47 +02:00
Laurent Pinchart 990d07a5a9 drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size
The rcar_du_device structure contains a field that stores the number of
CRTCs, use it instead of the CRTCs array size. This prepares the driver
to support a variable number of CRTCs.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:47 +02:00
Laurent Pinchart cb2025d250 drm/rcar-du: Introduce CRTCs groups
The R8A7779 DU is split in per-CRTC resources (scan-out engine, blending
unit, timings generator, ...) and device-global resources (start/stop
control, planes, ...) shared between the two CRTCs.

The R8A7790 introduced a third CRTC with its own set of global resources
This would be modeled as two separate DU device instances if it wasn't
for a handful or resources that are shared between the three CRTCs
(mostly related to input and output routing). For this reason the
R8A7790 DU must be modeled as a single device with three CRTCs, two sets
of "semi-global" resources, and a few device-global resources.

Introduce a new rcar_du_group driver-specific object, without any real
counterpart in the DU documentation, that models those semi-global
resources.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:46 +02:00
Laurent Pinchart 7fe99fda5f drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*
The functions initialize or register all planes, rename them
accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:45 +02:00
Laurent Pinchart ae425b6a77 drm/rcar-du: Create rcar_du_planes structure
Move the plane-related fields of struct rcar_du_device to their own
structure.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:45 +02:00
Laurent Pinchart 9194731c5f drm/rcar-du: Rename platform data fields to match what they describe
The struct rcar_du_encoder_data encoder::field describes the encoder
type, and the rcar_du_encoder_lvds_data and rcar_du_encoder_vga_data
structures describe connector properties. Rename them accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:44 +02:00
Laurent Pinchart 6978f12377 drm/rcar-du: Merge LVDS and VGA encoder code
Create a single rcar_du_encoder structure that implements a KMS encoder.
The current implementation is straightforward and only configures CRTC
output routing.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:43 +02:00
Laurent Pinchart 9e8be27233 drm/rcar-du: Split VGA encoder and connector
This prepares for the encoders rework.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:43 +02:00
Laurent Pinchart 56c5dd00f8 drm/rcar-du: Split LVDS encoder and connector
This prepares for the encoders rework.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:42 +02:00
Laurent Pinchart 9e7db06d3a drm/rcar-du: Clarify comment regarding plane Y source coordinate
The R8A7790 DU documentation contains further information regarding the
plane Y source coordinate. Update the comment accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:42 +02:00
Laurent Pinchart f66ee304ae drm/rcar-du: Support per-CRTC clock and IRQ
Some of the DU revisions use one clock and IRQ per CRTC instead of one
clock and IRQ per device. Retrieve the correct clock and register the
correct IRQ for each CRTC.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:41 +02:00
Laurent Pinchart 481d342e35 drm/rcar-du: Add platform module device table
The platform device id driver data field points to a device information
structure that only contains a (currently empty) features field for now.
Support for additional model-dependent features will be added later.

Only the R8A7779 variant is currently supported.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:40 +02:00
Laurent Pinchart d5b6dcc459 drm/rcar-du: Use devm_ioremap_resource()
Replace the devm_request_mem_region() and devm_ioremap_nocache() calls
with devm_ioremap_resource().

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:39 +02:00
Laurent Pinchart 6811b1bea9 drm/rcar-du: Add missing alpha plane register definitions
Several alpha plane register definitions are missing, add them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-09 23:17:39 +02:00
Ville Syrjälä 5c536613d8 drm/i915: Fix FB WM for HSW
Due to a misplaced memset(), we never actually enabled the FBC WM on HSW.
Move the memset() to happen a bit earlier, so that it won't clobber
results->enable_fbc_wm.

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>
2013-08-09 20:27:43 +02:00
Jesse Barnes 6f6005a52b drm/i915: expose HDMI connectors on port C on BYT
Ryan noticed that on his board, HDMI was wired up to port C but not
exposed by the kernel, which had only expected DP on that port.  Fix
that up by enumerating both ports if possible.

Tested-by: "Matsumura, Ryan" <ryan.matsumura@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fix up the whitespace fail. Tsk.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 19:02:27 +02:00
Dan Carpenter 16e54061ec drm/i915: fix a limit check in hsw_compute_wm_results()
The '!' here was not intended.  Since '!' has higher precedence than
compare, it means the check is never true.

This regression was introduced in

commit 71fff20ff1
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Aug 6 22:24:03 2013 +0300

    drm/i915: Kill fbc_enable from hsw_lp_wm_results

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 18:26:47 +02:00
Dan Carpenter 58e73e1570 drm/i915: unbreak i915_gem_object_ggtt_unbind()
There is an extra semi-colon here so we just leak and never unbind
anything.

This regression has been introduced 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

Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 12:04:53 +02:00
Damien Lespiau e7457a9a33 drm/i915: Make intel_set_mode() static
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 10:46:15 +02:00
Damien Lespiau 1414f6c049 drm/i915: Remove intel_modeset_disable()
Caught by the dead code police!

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 10:46:10 +02:00
Damien Lespiau 9237329d83 drm/i915: Make intel_encoder_dpms() static
And also fix a small typo in the intel_encoder_dpms() comment.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 10:46:03 +02:00
Damien Lespiau a658b5d20d drm/i915: Make i915_hangcheck_elapsed() static
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 10:45:57 +02:00
Damien Lespiau c55651b39a drm/i915: Fix #endif comment
Did you say OCD?

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 10:45:52 +02:00
Damien Lespiau ac44bfac5b drm/i915: Remove i915_gem_object_check_coherency()
This code was dead since:

  commit 432e58edc9
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Thu Nov 25 19:32:06 2010 +0000

      drm/i915: Avoid allocation for execbuffer object list

so just put it to rest for good.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 10:45:45 +02:00
Damien Lespiau a2367166fb drm/i915: Remove stale prototypes
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-09 10:45:40 +02:00
Dave Airlie e42f581421 Merge tag 'drm-intel-fixes-2013-08-08' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Daniel writes:
A few bugfixes for serious stuff and regressions. Highlight is the
reinstated hack to keep the i915 backlight on when running on an optimus
machine, this prevents black screens especially with some radeon muxed
platforms. And the patch to quiet dmesg on Linus' old mac mini ;-)

* tag 'drm-intel-fixes-2013-08-08' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: do not disable backlight on vgaswitcheroo switch off
  drm/i915: Don't call encoder's get_config unless encoder is active
  drm/i915: avoid brightness overflow when doing scale
  drm/i915: update last_vblank when disabling the power well
  drm/i915: fix gen4 digital port hotplug definitions
2013-08-09 09:09:37 +10:00
Chris Wilson 6d2b888569 drm/i915: List objects allocated from stolen memory in debugfs
I was curious as to what objects were currently allocated from stolen
memory, and so exported it from debugfs.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-08 14:11:15 +02:00
Ville Syrjälä a95fd8cae0 drm/i915: Always call intel_update_sprite_watermarks() when disabling a plane
ILK and VLV codepaths didn't update sprite watermarks when disabling a
sprite. Make them do that.

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>
2013-08-08 14:11:15 +02:00
Ville Syrjälä adf3d35e4a drm/i915: Pass plane and crtc to intel_update_sprite_watermarks
We're going to want to know the crtc in the watermark code to avoid
doing more work than we have to. We should also pass the plane we're
disabling so that we know where to stick our watermark parameters
without having to go look the plane up.

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>
2013-08-08 14:11:14 +02:00
Ville Syrjälä 88a94a58a0 drm/i915: Don't try to disable plane if it's already disabled
Check plane->fb in intel_disable_plane() to determine if the plane
is already disabled.

If the plane has an fb, then it must also have a crtc, so we can drop
the plane->crtc check and just call intel_enable_primary() directly.

v2: WARN and bail if the plane doesn't have a crtc when it should

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-08 14:11:13 +02:00
Ville Syrjälä b39d53f624 drm/i915: Pass crtc to our update/disable_plane hooks
We're going to want to know which CRTC we're dealing with, so pass it
down to the update/disable_plane hooks.

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>
2013-08-08 14:11:13 +02:00
Ville Syrjälä c35426d2bc drm/i915: Split plane watermark parameters into a separate struct
Give a name to the plane watermark related data we have currently
stored under intel_plane->wm.

We also observe that this data is more or less the same that we have
in the hsw_pipe_wm_parameters structure, so use it there as well.

v2: Make pahole happier

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>
2013-08-08 14:11:12 +02:00
Ville Syrjälä 240264f49e drm/i915: Pull some watermarks state into a separate structure
There is a bunch of global state that needs to be considered when
checking watermarks for validity. Move most of that to a new
structure intel_wm_config, to avoid having to pass around so
many variables.

One notable thing left out is the DDB partitioning information,
since we often anyway need to check the same watermarks against
both 1/2 and 5/6 DDB partitioning layouts.

v2: s/pipes_active/num_pipes_active

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>
2013-08-08 14:11:12 +02:00
Ville Syrjälä 158ae64f82 drm/i915: Calculate max watermark levels for ILK+
There are quite a few variables we need to take into account to
determine the maximum watermark levels, so it feels a bit cleaner
to calculate those rather than just have a bunch of what look like
magic numbers.

v2: s/pipes_active/num_pipes_active
    s/othwewise/otherwise

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>
2013-08-08 14:11:11 +02:00
Ville Syrjälä 1fd527cc34 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>
2013-08-08 14:11:10 +02:00
Ville Syrjälä a9786a119d 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>
2013-08-08 14:11:10 +02:00
Ben Widawsky 8b9c2b9411 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
2013-08-08 14:10:20 +02:00
Ben Widawsky 95f5301dd8 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>
2013-08-08 14:08:37 +02:00
Ben Widawsky ca191b1313 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>
2013-08-08 14:06:58 +02:00
Ben Widawsky 5cacaac77c 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>
2013-08-08 14:04:55 +02:00
Ville Syrjälä 2b4bd0e065 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>
2013-08-08 14:04:55 +02:00
Ville Syrjälä 77c122bcc4 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>
2013-08-08 14:04:54 +02:00
Ville Syrjälä 71fff20ff1 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>
2013-08-08 14:04:53 +02:00
Ville Syrjälä 6f5ddd1704 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>
2013-08-08 14:04:53 +02:00
Ville Syrjälä 39db4a4d7f 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>
2013-08-08 14:04:52 +02:00
Damien Lespiau 9198ee5b90 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>
2013-08-08 14:04:51 +02:00
Damien Lespiau 15747638e6 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>
2013-08-08 14:04:51 +02:00
Damien Lespiau bf02db9938 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>
2013-08-08 14:04:50 +02:00
Damien Lespiau c5022bb9ff 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>
2013-08-08 14:04:49 +02:00
Damien Lespiau 15dcd35021 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>
2013-08-08 14:04:49 +02:00
Damien Lespiau 5adaea799c 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>
2013-08-08 14:04:48 +02:00
Damien Lespiau 178f736ab9 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>
2013-08-08 14:04:47 +02:00
Damien Lespiau 03a7a189c2 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>
2013-08-08 14:04:47 +02:00
Ben Widawsky 9843877d10 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>
2013-08-08 14:04:43 +02:00
Ben Widawsky f6cd1f15d3 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>
2013-08-08 14:04:43 +02:00
Ben Widawsky 07fe0b1280 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>
2013-08-08 14:04:20 +02:00
Ben Widawsky 80dcfdbd68 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>
2013-08-08 14:02:41 +02:00
Michel Dänzer e91abf80a0 drm: Don't pass negative delta to ktime_sub_ns()
It takes an unsigned value. This happens not to blow up on 64-bit
architectures, but it does on 32-bit, causing
drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
timestamps for vblank events. Which in turn causes e.g. gnome-shell to
hang after a DPMS off cycle with current xf86-video-ati Git.

[airlied: regression introduced in drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos]

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59836
Tested-by: shui yangwei <yangweix.shui@intel.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-08 09:50:25 +10:00
Dave Airlie 16d5b27250 Merge branch 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux
Some more radeon fixes.  Mostly dpm and uvd fixes.  Fixes hangs
with dpm on more rv6xx asics, and fixes suspend and resume with UVD.

* 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: make missing smc ucode non-fatal
  drm/radeon/dpm: require rlc for dpm
  drm/radeon/cik: use a mutex to properly lock srbm instanced registers
  drm/radeon: remove unnecessary unpin
  drm/radeon: add more UVD CS checking
  drm/radeon: stop sending invalid UVD destroy msg
  drm/radeon: only save UVD bo when we have open handles
  drm/radeon: always program the MC on startup
  drm/radeon: fix audio dto calculation on DCE3+ (v3)
  drm/radeon/dpm: disable sclk ss on rv6xx
  drm/radeon: fix halting UVD
  drm/radeon/dpm: adjust power state properly for UVD on SI
  drm/radeon/dpm: fix spread spectrum setup (v2)
  drm/radeon/dpm: adjust thermal protection requirements
  drm/radeon: select audio dto based on encoder id for DCE3
  drm/radeon: properly handle pm on gpu reset
2013-08-08 09:47:02 +10:00
Alex Deucher 8a53fa23fd drm/radeon: make missing smc ucode non-fatal
The smc ucode is required for dpm (dynamic power
management), but if it's missing just skip dpm setup
and don't disable acceleration.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=67876

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:19 -04:00
Alex Deucher 761bfb9998 drm/radeon/dpm: require rlc for dpm
The rlc is required for dpm to work properly, so if
the rlc ucode is missing, don't enable dpm.  Enabling
dpm without the rlc enabled can result in hangs.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:19 -04:00
Alex Deucher f61d5b4677 drm/radeon/cik: use a mutex to properly lock srbm instanced registers
We need proper locking in the driver when accessing instanced
registers on CIK.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:18 -04:00
Christian König 3744b248f9 drm/radeon: remove unnecessary unpin
We don't pin the BO on allocation, so don't unpin it on free.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:17 -04:00
Christian König 56cc2c1538 drm/radeon: add more UVD CS checking
Improve error handling in case userspace sends us
an invalid command buffer.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:16 -04:00
Christian König 641a00593f drm/radeon: stop sending invalid UVD destroy msg
We also need to check the handle.

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:15 -04:00
Christian König 4ad9c1c774 drm/radeon: only save UVD bo when we have open handles
Otherwise just reinitialize from scratch on resume,
and so make it more likely to succeed.

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:15 -04:00
Alex Deucher 6fab3febf6 drm/radeon: always program the MC on startup
For r6xx+ asics.  This mirrors the behavior of pre-r6xx
asics.  We need to program the MC even if something
else in startup() fails.  Failure to do so results in
an unusable GPU.

Based on a fix from: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2013-08-07 17:37:14 -04:00
Alex Deucher 1518dd8efd drm/radeon: fix audio dto calculation on DCE3+ (v3)
Need to set the wallclock ratio and adjust the phase
and module registers appropriately.  May fix problems
with audio timing at certain display timings.

v2: properly handle clocks below 24mhz
v3: rebase r600 changes

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:13 -04:00
Alex Deucher ce149a9406 drm/radeon/dpm: disable sclk ss on rv6xx
Enabling spread spectrum on the engine clock
leads to hangs on some asics.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66963

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:12 -04:00
Christian König 2858c00d28 drm/radeon: fix halting UVD
Removing the clock/power or resetting the VCPU can cause
hangs if that happens in the middle of a register write.

Stall the memory and register bus before putting the VCPU
into reset. Keep it in reset when unloading the module or
suspending.

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:11 -04:00
Alex Deucher 797f203f62 drm/radeon/dpm: adjust power state properly for UVD on SI
There are some hardware issue with reclocking on SI when
UVD is active, so use a stable power state when UVD is
active.  Fixes possible hangs and performance issues when
using UVD on SI.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:11 -04:00
Alex Deucher b841ce7b41 drm/radeon/dpm: fix spread spectrum setup (v2)
Need to check for engine and memory clock ss separately
and only enable dynamic ss if either of them are found.

This should fix systems which have a ss table, but do
not have entries for engine or memory.  On those systems
we may enable dynamic spread spectrum without enabling
it on the engine or memory clocks which can lead to a
hang in some cases.

fixes some systems reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=66963

v2: fix typo

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:10 -04:00
Alex Deucher fda837241f drm/radeon/dpm: adjust thermal protection requirements
On rv770 and newer, clock gating is not required
for thermal protection.  The only requirement is that
the design utilizes a thermal sensor.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:09 -04:00
Alex Deucher e1accbf054 drm/radeon: select audio dto based on encoder id for DCE3
There are two audio dtos on radeon asics that you can
select between.  Normally, dto0 is used for hdmi and
dto1 for DP, but it seems that the dto is somehow
tied to the encoders on DCE3 asics.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=67435

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2013-08-07 17:37:08 -04:00
Alex Deucher 95f595097b drm/radeon: properly handle pm on gpu reset
When we reset the GPU, we need to properly tear
down power management before reseting the GPU and then
set it back up again after reset.  Add the missing
radeon_pm_[suspend|resume] calls to the gpu reset
function.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-07 17:37:07 -04:00
Jani Nikula 3f577573cd drm/i915: do not disable backlight on vgaswitcheroo switch off
On muxed systems, the other vgaswitcheroo client may depend on i915 to
handle the backlight. We began switching off the backlight since

commit a261b246eb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 26 19:21:47 2012 +0200

    drm/i915: disable all crtcs at suspend time

breaking backlight on discreet graphics in (some) muxed systems.

Keep the backlight on when the state is changed through vgaswitcheroo.

Note: The alternative would be to add a quirk table to achieve the same
based on system identifiers, but AFAICS it would asymptotically approach
effectively the same as this patch as more IDs are added, but with the
maintenance burden of the quirk table.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55311
Tested-by: Fede <fedevx@yahoo.com>
Tested-by: Aximab <laurent.debian@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59785
Tested-by: sfievet <sebastien.fievet@free.fr>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-07 11:57:09 +02:00
Ville Syrjälä 3eaba51cd3 drm/i915: Don't call encoder's get_config unless encoder is active
The SDVO code tries to compare the encoder's and crtc's idea of the
pixel_multiplier. Normally they have to match, but when transitioning
to DPMS off, we turn off the pipe before reading out the pipe_config,
so the pixel_multiplier in the pipe_config will be 0, whereas the
encoder will still have its pixel_multiplier set to whatever value we
were using when the display was active. This leads to a warning
from intel_modeset_check_state().

WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378 intel_sdvo_get_config+0x158/0x160()
SDVO pixel multiplier mismatch, port: 0, encoder: 1
Modules linked in: snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep
CPU: 1 PID: 2846 Comm: Xorg Not tainted 3.11.0-rc3-00208-gbe1e8d7-dirty #19
Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS  MM11.88Z.0055.B03.0604071521 04/07/06
 00000000 00000000 ef0afa54 c1597bbb c1737ea4 ef0afa84 c10392ca c1737e6c
 ef0afab0 00000b1e c1737ea4 00000562 c12dfbe8 c12dfbe8 ef0afb14 00000000
 f697ec00 ef0afa9c c103936e 00000009 ef0afa94 c1737e6c ef0afab0 ef0afadc
Call Trace:
 [<c1597bbb>] dump_stack+0x41/0x56
 [<c10392ca>] warn_slowpath_common+0x7a/0xa0
 [<c103936e>] warn_slowpath_fmt+0x2e/0x30
 [<c12dfbe8>] intel_sdvo_get_config+0x158/0x160
 [<c12c3220>] check_crtc_state+0x1e0/0xb10
 [<c12cdc7d>] intel_modeset_check_state+0x29d/0x7c0
 [<c12dfe5c>] intel_sdvo_dpms+0x5c/0xa0
 [<c12985de>] drm_mode_obj_set_property_ioctl+0x40e/0x420
 [<c1298625>] drm_mode_connector_property_set_ioctl+0x35/0x40
 [<c1289294>] drm_ioctl+0x3e4/0x540
 [<c10fc1a2>] do_vfs_ioctl+0x72/0x570
 [<c10fc72f>] SyS_ioctl+0x8f/0xa0
 [<c159b7fa>] sysenter_do_call+0x12/0x22
---[ end trace 7ce940aff1366d60 ]---

Fix the problem by skipping the encoder get_config() function for
inactive encoders.

Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-07 11:57:09 +02:00
Aaron Lu 22505b82a2 drm/i915: avoid brightness overflow when doing scale
Some card's max brightness level is pretty large, e.g. on Acer Aspire
4732Z, the max level is 989910. If user space set a large enough level
then the current scale done in intel_panel_set_backlight will cause an
integer overflow and the scaled level will be mistakenly small, leaving
user with an almost black screen. This patch fixes this problem.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
[danvet: Add a comment to explain what's going on.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-07 11:57:08 +02:00
Paulo Zanoni 9dbd8febb4 drm/i915: update last_vblank when disabling the power well
The DRM layer keeps track of our vblanks and it assumes our vblank
counters only go back to zero when they overflow. The problem is that
when we disable the power well our counters also go to zero, but it
doesn't mean they did overflow. So on this patch we grab the lock and
update last_vblank so the DRM layer won't think our counters
overflowed.

This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblank

Regression introduced by the following commit:

commit bf51d5e2cd
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Wed Jul 3 17:12:13 2013 -0300
    drm/i915: switch disable_power_well default value to 1

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Added a comment that this might be better done in
drm_vblank_post_modeset in general.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-07 11:57:06 +02:00
Daniel Vetter 0ce99f749b drm/i915: fix gen4 digital port hotplug definitions
Apparently Bspec is wrong in this case here even for gm45. Note that
Bspec is horribly misguided on i965g/gm, so we don't have any other
data points besides that it seems to make machines work better.

With this changes all the bits in PORT_HOTPLUG_STAT for the digital
ports are ordered the same way. This seems to agree with what register
dumps from the hpd storm handling code shows, where the LIVE bit and
the short/long pulse STATUS bits light up at the same time with this
enumeration (but no with the one from Bspec).

Also tested on my gm45 which has two DP+ ports, and everything seems
to still work as expected.

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html
Cc: Egbert Eich <eich@suse.com>
Cc: Jan Niggemann <jn@hz6.de>
Tested-by: Jan Niggemann <jn@hz6.de>
[danvet: Add a big warning that Bspec seems to be wrong for these
bits, suggested by Jani.]
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-07 11:57:06 +02:00
Dave Airlie 32c913e436 Merge tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Neat that QA (and Ben) keeps on humming along while I'm on vacation, so
you already get the next feature pull request:
- proper eLLC support for HSW from Ben
- more interrupt refactoring
- add w/a tags where we implement them already (Damien)
- hangcheck fixes (Chris) + hangcheck stats (Mika)
- flesh out the new vm structs for ppgtt and ggtt (Ben)
- PSR for Haswell, still disabled by default (Rodrigo et al.)
- pc8+ refclock sequence code from Paulo
- more interrupt refactoring from Paulo, unifying ilk/snb with the ivb/hsw
  interrupt code
- full solution for the Haswell concurrent reg access issues (Chris)
- fix racy object accounting, used by some new leak tests
- fix sync polarity settings on ch7xxx dvo encoder
- random bits&pieces, little fixes and better debug output all over

[airlied: fix conflict with drm_mm cleanups]

* tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel: (289 commits)
  drm/i915: Do not dereference NULL crtc or fb until after checking
  drm/i915: fix pnv display core clock readout out
  drm/i915: Replace open-coded offset_in_page()
  drm/i915: Retry DP aux_ch communications with a different clock after failure
  drm/i915: Add messages useful for HPD storm detection debugging (v2)
  drm/i915: dvo_ch7xxx: fix vsync polarity setting
  drm/i915: fix the racy object accounting
  drm/i915: Convert the register access tracepoint to be conditional
  drm/i915: Squash gen lookup through multiple indirections inside GT access
  drm/i915: Use the common register access functions for NOTRACE variants
  drm/i915: Use a private interface for register access within GT
  drm/i915: Colocate all GT access routines in the same file
  drm/i915: fix reference counting in i915_gem_create
  drm/i915: Use Graphics Base of Stolen Memory on all gen3+
  drm/i915: disable stolen mem for OVERLAY_NEEDS_PHYSICAL
  drm/i915: add functions to disable and restore LCPLL
  drm/i915: disable CLKOUT_DP when it's not needed
  drm/i915: extend lpt_enable_clkout_dp
  drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
  drm/i915: Add some debug breadcrumbs to connector detection
  ...
2013-08-07 18:11:35 +10:00
David Herrmann abf190351b drm/ttm: inline drm_bo_setup_vm()
This helper is used only once and just wraps a call to
drm_vma_offset_add(). Remove this unneeded indirection to safe 10 lines of
code.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-08-07 18:08:05 +10:00
David Herrmann c700c67bae drm/mm: remove unused API
We used to pre-allocate drm_mm nodes and save them in a linked list for
later usage so we always have spare ones in atomic contexts. However, this
is really racy if multiple threads are in an atomic context at the same
time and we don't have enough spare nodes. Moreover, all remaining users
run in user-context and just lock drm_mm with a spinlock. So we can easily
preallocate the node, take the spinlock and insert the node.

This may have worked well with BKL in place, however, with today's
infrastructure it really doesn't make any sense. Besides, most users can
easily embed drm_mm_node into their objects so no allocation is needed at
all.

Thus, remove the old pre-alloc API and all the helpers that it provides.
Drivers have already been converted and we should not use the old API for
new code, anymore.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:16:50 +10:00
David Herrmann 06e78edff1 drm/i915: pre-alloc instead of drm_mm search/get_block
i915 is the last user of the weird search+get_block drm_mm API. Convert it
to an explicit kmalloc()+insert_node(). This drops the last user of the
node-cache in drm_mm. We can remove it now in a follow-up patch.

v2:
 - simplify error path in i915_setup_compression()
v3:
 - simplify error path even more

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:16:26 +10:00
David Herrmann 78af329a85 drm/ttm: replace drm_mm_pre_get() by direct alloc
Instead of calling drm_mm_pre_get() in a row, we now preallocate the node
and then use the atomic insertion functions. This has the exact same
semantics and there is no reason to use the racy pre-allocations.

Note that ttm_bo_man_get_node() does not run in atomic context. Nouveau
already uses GFP_KERNEL alloc in nouveau/nouveau_ttm.c in
nouveau_gart_manager_new(). So we can do the same in
ttm_bo_man_get_node().

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:15:29 +10:00
David Herrmann 28ec711cd4 drm/agp: move AGP cleanup paths to drm_agpsupport.c
Introduce two new helpers, drm_agp_clear() and drm_agp_destroy() which
clear all AGP mappings and destroy the AGP head. This allows to reduce the
AGP code in core DRM and move it all to drm_agpsupport.c.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:14:24 +10:00
Andy Shevchenko 08fcd72b14 drm: don't push static constants on stack for %*ph
There is no need to pass constants via stack. The width may be explicitly
specified in the format.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:10:58 +10:00
Rob Clark baa7094355 drm: const'ify ioctls table (v2)
Because, there is no reason for it not to be const.

v1: original
v2: fix compile break in vmwgfx, and couple related cleanups suggested
    by Ville Syrjälä

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:10:02 +10:00
David Herrmann 31e5d7c67b drm/mm: add "best_match" flag to drm_mm_insert_node()
Add a "best_match" flag similar to the drm_mm_search_*() helpers so we
can convert TTM to use them in follow up patches. We can also inline the
non-generic helpers and move them into the header to allow compile-time
optimizations.

To make calls to drm_mm_{search,insert}_node() more readable, this
converts the boolean argument to a flagset. There are pending patches that
add additional flags for top-down allocators and more.

v2:
 - use flag parameter instead of boolean "best_match"
 - convert *_search_free() helpers to also use flags argument

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:08:58 +10:00
Dave Airlie 3ac6525932 drm/ast: invalidate page tables when pinning a BO
same fix as cirrus and mgag200.

Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:01:56 +10:00
Egbert Eich ecaac1c866 drm/mgag200: Invalidate page tables when pinning a BO
When a BO gets pinned the placement may get changed. If the memory is
mapped into user space and user space has already accessed the mapped
range the page tables are set up but now point to the wrong memory.
Set bo.mdev->dev_mapping in mgag200_bo_create() to make sure that
ttm_bo_unmap_virtual() called from ttm_bo_handle_move_mem() will take
care of this.

v2: Don't call ttm_bo_unmap_virtual() in mgag200_bo_pin(), fix comment.

Signed-off-by: Egbert Eich <eich@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:01:01 +10:00
Michal Srb 109a515988 drm/cirrus: Invalidate page tables when pinning a BO
This is a cirrus version of Egbert Eich's patch for mgag200.

Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked
called from ttm_bo_handle_move_mem returns with no effect. If any
application accessed the memory before it was moved, it will
access wrong memory next time. This causes crashes when changing
resolution down.

Signed-off-by: Michal Srb <msrb@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 10:00:45 +10:00
Daniel Vetter 43387b37fa drm/gem: create drm_gem_dumb_destroy
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.

So give it to them and roll it out in all drivers.

This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.

Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Reviwed-by: Rob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 09:59:24 +10:00
Ben Widawsky 0b02e798ff drm/i915: Improve VMA comments
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-06 20:14:46 +02:00
Chris Wilson ddfe15677d 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>
2013-08-06 20:08:50 +02:00
Chris Wilson 350ec881d9 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>
2013-08-06 16:35:30 +02:00
Paulo Zanoni ad8d270c21 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>
2013-08-06 08:33:40 +02:00
Paulo Zanoni f72d19f069 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>
2013-08-06 08:32:26 +02:00
Ben Widawsky 637efacf8f 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>
2013-08-05 19:12:25 +02:00