PFIFO_INTR = 0x40000000 appears to be a normal case on nvc0/nve0 PFIFO,
the binary driver appears to completely ignore it in its PFIFO interrupt
handler and even masks off the bit (as we do) in PFIFO_INTR_EN at init
time.

The bits still light up in the hardware sometimes though, so lets just
ignore any bits we haven't explicitely requested.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NVIDIA do that at startup too on Fermi, so perhaps the heap of 0x10
intrs we receive are normal and we can ignore them.

On Kepler NVIDIA *don't* do this, but the hardware appears to come up
with the bit masked off by default - so that's probably why :)

This should silence some interrupt spam seen on Fermi+ boards.

Backported patch from reworked nouveau kernel tree.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

This fixes the gpio reset problem so the Retina MBP works, but avoids
breaking the Dell systems. Ben will work on a better solution for 3.7.

Tested by me on retina MBP.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit 991083ba.

We discovered this causes problem on some Dell eDP laptops, so Apple
lose out for now, I might try and whip up a dmi based workaround for 3.6
but I'm not sure I'll get time.
Signed-off-by: NDave Airlie <airlied@redhat.com>

We noticed a plymouth bug on Fedora 18, and I then
noticed this stupid thinko, fixing it fixed the problem
with plymouth.

Cc: stable@vger.kernel.org
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is required to fix an issue on the Retina MBP where the eDP panel's
AUX channel isn't wired up to the HPD pin for the panel, causing our aux
code to bail out early.

From looking at various traces of the binary driver, it appears NVIDIA do
something very similar on at least all nv50+ chipsets during their
initialisation sequence.  So, hopefully this is safe.

Issue and fix initially tracked down by Ryan Bourgeois on fdo#51971.

Backported fix from reworked nouveau kernel module.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I have a very limited number of traces available for DP on NVD9+, but,
these values produce the same as the binary driver on a confirmed 18-bit
eDP panel and a confirmed 24-bit eDP panel (Retina MBP).

It's interesting that the bitfield values also match the MODE_CTRL values
that control the same thing on nv50:nvd9.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On some Fermi chipsets (NVCE particularly) PCOPY1 doesn't exist.  And if
what I've seen on Kepler is true of Fermi too, chipsets of the same type
can have different PCOPY units available.

This should fix a v3.5 regression reported by a number of people effecting
suspend/resume on NVC8/NVCE chipsets.

Cc: stable@vger.kernel.org [3.5]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This callback is a no-op in nouveau, and the upcoming apple-gmux
switcheroo support won't require it either. Rather than forcing drivers
to stub it out, just make it optional and remove the callback from
nouveau.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

This fix is a backport from the reworked nouveau driver.  It masks off the
engines we're not expecting to use before attempting a channel kickoff.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The copy engine exhibits random memory corruption in at least one case, the
GeForce 320M (nv50, 0xaf) in the MacBookAir3,1.

This patch omits creating the engine for the specific chipset, falling back
to M2MF, which kills the symptoms.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes screen being black after changing performance level.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [3.5+]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

At least partially fixes DP output detection on W530.  Not sure if more
issues remain, or if my adaptor is just behaving weirdly (it does that
sometimes).

In any case, this patch is necessary.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NChristoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

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

Fixes kernel panic when vblank interrupt triggers before first sync to
vblank request.

(Besides init, remove some relevant leftovers from vblank rework)
Reported-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@vger.kernel.org [3.5]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

These will be replaced in the near future, the code isn't yet stable enough
for this merge window however.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I want this file for the new interfaces...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>

Current name is misleading, because this error can be triggered by other
conditions, like changing STRMOUT parameter without disabling STRMOUT first.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Linear copy works by adding the offset to the buffer address,
which may end up not being 16-byte aligned.

Some tests I've written for prime_pcopy show that the engine
allows this correctly, so the restriction on lowest 4 bits of
address can be lifted safely.

The comments added were by envyas, I think because I used
a newer version.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org

Setting dev_mapping (pointer to the address_space structure
used for memory mappings) to the address_space of the first
opener's inode and then failing if other openers come in
through a different inode has a few restrictions that are
eliminated by this patch.

If we already have valid dev_mapping and we spot an opener
with different i_node, we force its i_mapping pointer to the
already established address_space structure (first opener's
inode). This will make all mappings from drm device hang off
the same address_space object.

Some benefits (things that now work and didn't work
before) of this patch are:

 * user space can mknod and use any number of device
   nodes and they will all work fine as long as the major
   device number is that of the drm module.
 * user space can even remove the first opener's device
   nodes and mknod the new one and the applications and
   windowing system will still work.
 * GPU drivers can safely assume that dev->dev_mapping is
   correct address_space and just blindly copy it
   into their (private) bdev.dev_mapping

For reference, some discussion that lead to this patch can
be found here:

http://lists.freedesktop.org/archives/dri-devel/2012-April/022283.htmlSigned-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All leftover users either haven't set DRIVER_HAVE_DMA, in which
case this will never be called, or use the drm_core implementation.

Call that directly in the only callsite.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The passed mode must not be modified by the operation, make it const.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just forgot this when I posted it, and yes I'm the only person
to have changed the file since.
Signed-off-by: NDave Airlie <airlied@redhat.com>

nv_two_heads() was never meant to be used outside of pre-nv50 code.  The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).

The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..

This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Tested sharing to udl.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This just adds a stub until we have some users in place to test
this with.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Currently nouveau only registers as a vga_switcheroo client, but never
unregisters. This patch adds the necessary unregister calls.
Signed-off-by: NAndreas Heider <andreas@meetr.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Currently vga_switcheroo_unregister_handler is called unconditionally when
nouveau is unloaded, even when nouveau never registered a handler. This
interferes with other switcheroo handlers, as vga_switcheroo doesn't check who
called unregister_handler, but simply unregisters the current handler. This
patch adds a check so unregister is only called if a handler was registered by
nouveau before.
Signed-off-by: NAndreas Heider <andreas@meetr.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Bugs me every time I put in the TNT2..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is very annoying sometimes..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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