ixgbevf: Add support for VF API negotiation

This change makes it so that the VF can support the PF/VF API negotiation
protocol.  Specifically in this case we are adding support for API 1.0
which will mean that the VF is capable of cleaning up buffers that span
multiple descriptors without triggering an error.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
ixgbevf: scheduling while atomic in reset hw path

In ixgbevf_reset_hw_vf() msleep is called while holding mbx_lock
resulting in a schedule while atomic bug with trace below.

This patch uses mdelay instead.

BUG: scheduling while atomic: ip/6539/0x00000002
2 locks held by ip/6539:
 #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81419cc3>] rtnl_lock+0x17/0x19
 #1:  (&(&adapter->mbx_lock)->rlock){+.+...}, at: [<ffffffffa0030855>] ixgbevf_reset+0x30/0xc1 [ixgbevf]
Modules linked in: ixgbevf ixgbe mdio libfc scsi_transport_fc 8021q scsi_tgt garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 uinput igb coretemp hwmon crc32c_intel ioatdma i2c_i801 shpchp microcode lpc_ich mfd_core i2c_core joydev dca pcspkr serio_raw pata_acpi ata_generic usb_storage pata_jmicron
Pid: 6539, comm: ip Not tainted 3.6.0-rc3jk-net-next+ #104
Call Trace:
 [<ffffffff81072202>] __schedule_bug+0x6a/0x79
 [<ffffffff814bc7e0>] __schedule+0xa2/0x684
 [<ffffffff8108f85f>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffff814bd0c0>] schedule+0x64/0x66
 [<ffffffff814bb5e2>] schedule_timeout+0xa6/0xca
 [<ffffffff810536b9>] ? lock_timer_base+0x52/0x52
 [<ffffffff812629e0>] ? __udelay+0x15/0x17
 [<ffffffff814bb624>] schedule_timeout_uninterruptible+0x1e/0x20
 [<ffffffff810541c0>] msleep+0x1b/0x22
 [<ffffffffa002e723>] ixgbevf_reset_hw_vf+0x90/0xe5 [ixgbevf]
 [<ffffffffa0030860>] ixgbevf_reset+0x3b/0xc1 [ixgbevf]
 [<ffffffffa0032fba>] ixgbevf_open+0x43/0x43e [ixgbevf]
 [<ffffffff81409610>] ? dev_set_rx_mode+0x2e/0x33
 [<ffffffff8140b0f1>] __dev_open+0xa0/0xe5
 [<ffffffff814097ed>] __dev_change_flags+0xbe/0x142
 [<ffffffff8140b01c>] dev_change_flags+0x21/0x56
 [<ffffffff8141a843>] do_setlink+0x2e2/0x7f4
 [<ffffffff81016e36>] ? native_sched_clock+0x37/0x39
 [<ffffffff8141b0ac>] rtnl_newlink+0x277/0x4bb
 [<ffffffff8141aee9>] ? rtnl_newlink+0xb4/0x4bb
 [<ffffffff812217d1>] ? selinux_capable+0x32/0x3a
 [<ffffffff8104fb17>] ? ns_capable+0x4f/0x67
 [<ffffffff81419cc3>] ? rtnl_lock+0x17/0x19
 [<ffffffff81419f28>] rtnetlink_rcv_msg+0x236/0x253
 [<ffffffff81419cf2>] ? rtnetlink_rcv+0x2d/0x2d
 [<ffffffff8142fd42>] netlink_rcv_skb+0x43/0x94
 [<ffffffff81419ceb>] rtnetlink_rcv+0x26/0x2d
 [<ffffffff8142faf1>] netlink_unicast+0xee/0x174
 [<ffffffff81430327>] netlink_sendmsg+0x26a/0x288
 [<ffffffff813fb04f>] ? rcu_read_unlock+0x56/0x67
 [<ffffffff813f5e6d>] __sock_sendmsg_nosec+0x58/0x61
 [<ffffffff813f81b7>] __sock_sendmsg+0x3d/0x48
 [<ffffffff813f8339>] sock_sendmsg+0x6e/0x87
 [<ffffffff81107c9f>] ? might_fault+0xa5/0xac
 [<ffffffff81402a72>] ? copy_from_user+0x2a/0x2c
 [<ffffffff81402e62>] ? verify_iovec+0x54/0xaa
 [<ffffffff813f9834>] __sys_sendmsg+0x206/0x288
 [<ffffffff810694fa>] ? up_read+0x23/0x3d
 [<ffffffff811307e5>] ? fcheck_files+0xac/0xea
 [<ffffffff8113095e>] ? fget_light+0x3a/0xb9
 [<ffffffff813f9a2e>] sys_sendmsg+0x42/0x60
 [<ffffffff814c5ba9>] system_call_fastpath+0x16/0x1b

CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-By: Robert Garrett <robertx.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drm/i915: placeholder getparam

There are internal patches for a feature which require a parameter to
query whether support exists . These patches cannot be made external
yet. In order to keep existing tests and userspace happy and free from
conflicts, reserve a number for it.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Introduce drm_i915_gem_object_ops

In order to specialise functions depending upon the type of object, we
can attach vfuncs to each object via a new ->ops pointer.

For instance, this will be used in future patches to only bind pages from
a dma-buf for the duration that the object is used by the GPU - and so
prevent them from pinning those pages for the entire of the object.

v2: Bonus comments.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Pin backing pages whilst exporting through a dmabuf vmap

We need to refcount our pages in order to prevent reaping them at
inopportune times, such as when they currently vmapped or exported to
another driver. However, we also wish to keep the lazy deallocation of
our pages so we need to take a pin/unpinned approach rather than a
simple refcount.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Pin backing pages for pwrite

By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
jeneath us, and so we can simplify the code for iterating over the pages.

Note: The old code had such complicated page refcounting since it used
obj->pages as a micro-optimization if it's there, but that could
(before this patch) disappear when we drop the dev->struct_mutex.
Hence some manual page refcounting was required for the slow path,
complicated by the fact that pages returned by shmem_read_mapping_page
already have a pageref, which needs to be dropped again.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added note to explain the question Ben raised in review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Pin backing pages for pread

By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Replace the array of pages with a scatterlist

Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.

One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be up to
a megabyte in size) with a chain of individual pages which helps reduce
memory pressure.

The disadvantage is that we then do not have a simple array to iterate,
or to access randomly. The common case for this is in the relocation
processing, which will typically fit within a single scatterlist page
and so be almost the same cost as the simple array. For iterating over
the array, the extra function call could be optimised away, but in
reality is an insignificant cost of either binding the pages, or
performing the pwrite/pread.

v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
trivial compile error from rebasing.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_set

Because ironlake_crtc_mode_set is a giant function that used to have
404 lines. Let's try to make it less complex/confusing.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_set

Because declaring a variable in the beginning of the function, then
initializing it 100 lines later, then using it 100 lines later does
not make our code look good IMHO.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: extract compute_clocks from ironlake_crtc_mode_set

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: resolved conflicts due to missing some earlier patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: variable renames

Name variables a bit better for copy-pasters. This got turned up as part
of review for upcoming sysfs patches.

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>
drm/i915: #define gpu freq multipler

Magic numbers are bad mmmkay. In this case in particular the value is
especially weird because the docs say multiple things. We'll need this
value for sysfs, so extracting it is useful for that as well.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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>
drm/i915: Add current/max/min GPU freq to sysfs

Userspace applications such as PowerTOP are interesting in being able to
read the current GPU frequency. The patch itself sets up a generic array
for gen6 attributes so we can easily add other items in the future (and
it also happens to be just about the cleanest way to do this).

The patch is a nice addition to
commit 1ac02185dff3afac146d745ba220dc6672d1d162
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 30 13:26:48 2012 +0200

    drm/i915: add a tracepoint for gpu frequency changes

Reading the GPU frequncy can be done by reading a file like:
/sys/class/drm/card0/render_frequency_mhz

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>
drm/i915: POSTING_READ the new rps value

In order to keep our cached values in sync with the hardware, we need a
posting read here.

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>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Error checks in gen6_set_rps

With the new "standardized" sysfs interfaces we need to be a bit more
careful about setting the RPS values.

Because the sysfs code and the rps workqueue can run at the same time,
if the sysfs setter wins the race to the mutex, the workqueue can come
in and set a value which is out of range (ie. we're no longer protecting
by RPINTLIM).

I was not able to actually make this error occur in testing.

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>
drm/i915: rip out early dp port write for gm45/ilk

It's bogus.

If I've followed the history of this piece of code correctly, i.e. the
initial register write with the following vblank wait, this goes all
the way back to the original enabling of DP support in

commit a4fc5ed69817c73e32571ad7837bb707f9890009
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Apr 7 16:16:42 2009 -0700

    drm/i915: Add Display Port support

Unfortunately it seems to be nothing more than glorified duct-tape and
sometimes actively harmful. Adam Jackson noticed this for CPT
platforms with

commit e85194641bec56179dcf5e1704ce5c6bf30340c6
Author: Adam Jackson <ajax@redhat.com>
Date:   Thu Jul 21 17:48:38 2011 -0400

    drm/i915/dp: Don't turn CPT DP ports on too early

Unfortunately this kept the code around for ilk and gm45.

The specific failure case I'm seeing here is that after a dpms off/on
cycle we have the bits from the last link training (hopefully
successful link training) set in intel_dp->DP. This is requiered so
that complete_link_train can enable the port with the right tuning
values.

Unfortunately writing these again to the disabled port at dpms on time
kills the port somehow until it's disabled - dp link training fails in
an endless loop without this patch on my mobile ilk and gm45.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51493
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: add encoder->pre_enable/post_disable

The cpu eDP encoder has some horrible hacks to set up the DP pll at
the right time. To be able to move them to the right place, add some
more encoder callbacks so that this can happen at the right time.

LVDS has some similar funky hacks, but that would require more work
(we need to move around the pll setup a bit). Hence for now only
wire these new callbacks up for ilk+ - we only have cpu eDP on these
platforms.

v2: Bikeshed the vtable ordering, requested by Chris Wilson.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: clean up the cpu edp pll special case

By using the new pre_enable/post_disable functions.

To ensure that we only frob the cpu edp pll while the pipe is off add
the relevant asserts. Thanks to the new output state staging, this is
now really easy.

With this fixed we can now finally rip out the special-case handling
in the dp dpms code and replace it by the common intel_connector_dpms.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: robustify edp_pll_on/off

With the previous patch to clean up where exactly these two functions
are getting called, this patch can tackle the enable/disable code
itself:

- WARN if the port enable bit is in the wrong state or if the edp pll
  bit is in the wrong state, just for paranoia's sake.
- Don't disable the edp pll harder in the modeset functions just for
  fun.
- Don't set the edp pll enable flag in intel_dp->DP in modeset, do
  that while changing the actual hw state. We do the same with the
  actual port enable bit, so this is a bit more consistent.
- Track the current DP register value when setting things up and add
  some comments how intel_dp->DP is used in the disable code.

v2: Be more careful with resetting intel_dp->DP - otherwise dpms
off->on will fail spectacularly, becuase we enable the eDP port when
we should only enable the eDP pll.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>