Since switching the I2C-over-AUX helpers, there have been regressions on
some display combinations due to us not having support for "address only"
transactions.

This commits enables support for them for GF119 and newer.

Earlier GPUs have been reverted to a custom I2C-over-AUX algorithm.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Enable stereoscopic output for HDMI and DisplayPort connectors on
NV50+ (G80+) hardware.  We do not enable stereoscopy on older
hardware in case there is some older board that still has HDMI
output but for which we have no logic for setting the Vendor
InfoFrame.

With this, I get an obvious 3D output when using the "testdisplay"
program from intel-gpu-tools with the "-3" parameter and outputting
to a 3D-capable HDMI display, for all available 3D modes (be they
TB, SBSH, or FP) on all four G80+ DISPs.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>

Frame-packing modes add an extra vtotal raster lines to each frame
above and beyond what the basic mode description calls for.
Account for this during scaler configuration (possibly a bit of a
hack), during CRTC configuration (clearly not a hack), and when
checking that a mode is valid for a given connector (cribbed from
the i915 driver).
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Apparently sinks are allows to respond with ACK even if they didn't
fully complete a transaction...  It seems like a missed opportunity
for DEFER to me, but what do I know :)
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.

v2:
Change return type to bool (Ville)
Move the function drm_atomic.h (Daniel)
Fixed comment marker for documentation
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
[danvet: Move back to drmP.h because include hell.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1482396643-32456-1-git-send-email-dhinakaran.pandiyan@intel.com

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Made completely unreachable by atomic commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Made completely unreachable (and broken) by atomic commits.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Sometimes we load with a sink already in MST mode.  If, however, we can't
or don't want to use MST, we need to be able to switch it back to SST.

This commit instantiates a stub topology manager for any output path that
we believe (the detection of this could use some improvement) has support
for MST, and adds the connector detect() logic for detecting sink support
and switching between modes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These will also be used by MST connectors.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This commit implements the atomic property hooks for a connector, and
wraps the legacy interface handling on top of those.

For the moment, a full modeset will be done after any property change
in order to ease subsequent changes.  The optimised behaviour will be
restored for Tesla and later (earlier boards always do full modesets)
once atomic commits are implemented.

Some functions are put under the "nouveau_conn" namespace now, rather
than "nouveau_connector", to distinguish functions that will work for
(upcoming) MST connectors too.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This primarily existed to ensure the DP link got retrained, and is
now unnecessary as that's handled by NVKM already.

For anything beyond that, we send an event to userspace and let it
decide on an appropriate action to take.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes out-of-tree build issue where uapi/drm/nouveau_drm.h gets picked
up instead.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.

Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS
if the vga_switcheroo handler is capable of temporarily switching
the panel's DDC lines to the discrete GPU. This allows us to retrieve
the EDID if the panel is currently muxed to the integrated GPU.
Likewise, ask vga_switcheroo to switch DDC before probing LVDS
connectors.

This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is not capable of
switching AUX separately from the main link on these models.
This will be addressed in later patches.

List of pre-retina MBPs with dual GPUs, either or both Nvidia:
    [MBP  5,1 2008  nvidia MCP79 + G96        pre-retina  15"]
    [MBP  5,2 2009  nvidia MCP79 + G96        pre-retina  17"]
    [MBP  5,3 2009  nvidia MCP79 + G96        pre-retina  15"]
    [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina  15"]
    [MBP  6,1 2010  intel ILK + nvidia GT216  pre-retina  17"]
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

v3: Commit newly added due to introduction of drm_get_edid_switcheroo()
    wrapper which drivers need to opt-in to.

v5: Rebase on "vga_switcheroo: Add handler flags infrastructure",
    i.e. call drm_get_edid_switcheroo() only if the handler
    indicates that DDC is switchable.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/e9466eb3d66b5b30f1e93c3b3da79d8b9ad0830f.1452525860.git.lukas@wunner.de

fdo#93634
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

gcc does this for us, and these hooks will be gone soon.

Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-9-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A variety of tweaks to the NVIF library interfaces, mostly ripping out
things that turned out to be not so useful.

- Removed refcounting from nvif_object, callers are expected to not be
  stupid instead.
- nvif_client is directly reachable from anything derived from nvif_object,
  removing the need for heuristics to locate it
- _new() versions of interfaces, that allocate memory for the object
  they construct, have been removed.  The vast majority of callers used
  the embedded _init() interfaces.
- No longer storing constructor arguments (and the data returned from
  nvkm) inside nvif_object, it's more or less unused and just wastes
  memory.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is required to properly handle failing dpms calls.
When making a wait in i915 interruptible, I've noticed
that the dpms sequence could fail with -ERESTARTSYS because
it was waiting interruptibly for flips. So from now on
allow drivers to fail in their connector dpms callback.

Encoder and crtc dpms callbacks are unaffected.

Changes since v1:
- Update kerneldoc for the drm helper functions.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Resolve conflicts due to different merge order.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They are not to be modified.

Generated using the semantic patch:

@@
@@
(
  const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)

@@
@@
(
  const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)

@@
@@
(
  const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)

@@
@@
(
  const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver.  This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NVKM is having it's namespace switched to nvkm_, which will conflict
with these functions (which are workarounds for the fact that as of
yet, we still aren't able to split DRM and NVKM completely).

A comparison of objdump disassemblies proves no code changes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On NV50 and up, we'll allow fixed panels to use EDID-provided modes
without the GPU scaler, and force scaling (even for NONE) otherwise.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Should be the same defaults as before, just easier to follow.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The hilarious part is that, under X, this won't work anyway because the
server decides to construct its own modes for some reason.

Tested with modetest, which isn't quite as insane.  I'd hope that
wayland is more sensible.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It can help to remove any ambiguity about which options were passed to Nouveau,
especially in case the user had some options set in /etc/modprobe.d/*.conf that
he forgot about, as they won't appear in a dmesg.
Signed-off-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is an attempt at isolating some of the changes necessary to port
to NVIF in a separate commit.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is a lot of prep-work for being able to send event notifications
back to userspace.  Events now contain data, rather than a "something
just happened" signal.

Handler data is now embedded into a containing structure, rather than
being kmalloc()'d, and can optionally have the notify routine handled
in a workqueue.

Various races between suspend/unload with display HPD/DP IRQ handlers
automagically solved as a result.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>