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

v2 (Ben Skeggs):
- some fixes for 64KiB PAGE_SIZE
- fix porting issues in (currently unused) nv41/nv44 pciegart code
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Having GPUOBJ and VM intertwined like this makes it *really* hard to
continue porting to the new driver architecture, split it out in
favour of requiring explit maps be the caller.

It's more flexible and obvious this way anyway...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

The partial mapping thing is stupid and pointless...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

These type of fake objects will not be supported for much longer.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A ton of duplication for the moment, will go away when they become subdevs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.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>

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

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

v2:
- make sure not to execute display scripts unless resuming
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Still missing the main bits we use to change performance levels, I'll get
to it after all the hard yakka has been finished.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

v2/v3: Ben Skeggs <bskeggs@redhat.com>
- fix typo in default bus selection
- fix accidental loss of destructor

v4: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
- fix typo causing incorrect default i2c port settings when no BMP data
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

v2: Ben Skeggs <bskeggs@redhat.com>
- rebase on top of v3.6-rc6 with gpio reset patch integrated already
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

v2: Ben Skeggs <bskeggs@redhat.com>
- use unaligned macros to access vbios image
- endianness fixes
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Adds an extra layer of indirection to each register access, but it's not
too bad, and will also go away as pieces are ported.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These currently just call the existing ones in nouveau_drv.c, but will be
extended in upcoming commits.  This needed to be separated from the current
code as there will be some header clashes until things are ported.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This commit provides most of the infrastructure to support a major overhaul
of Nouveau's internals coming in the following commits.  This work aims to
take all the things we've learned over the last several years, and turn that
into a cleaner architecture that's more maintainable going forward.

RAMHT and MM bits of the new core have been left out for the moment, and
will be pulled in as I go through the process of porting the code to
become either subdev or engine modules.

There are several main goals I wanted to achieve through this work:

-- Reduce complexity

The goal here was to make each component of the driver as independent as
possible, which will ease maintainability and readability, and provide a
good base for resetting locked up GPU units in the future.

-- Better tracking of GPU units that are required at any given time

This is for future PM work, we'll be able to tell exactly what parts of the
GPU we need powered at any given point (etc).

-- Expose all available NVIDIA GPUs to the client

In order to support things such as multi-GPU channels, we want to be able
to expose all the NVIDIA GPUs to the client over a single file descriptor
so it can send a single push buffer to multiple GPUs.

-- Untangle the core hardware support code from the DRM implementation

This happened initially as an unexpected side-effect of developing the
initial core infrastructure in userspace, but it turned into a goal of
the whole project.  Initial benefits will be the availablility of a
number of userspace tools and tests using the same code as the driver
itself, but will also be important as I look into some virtualisation
ideas.

v2: Ben Skeggs <bskeggs@redhat.com>
- fix duplicate assignments noticed by clang
- implement some forgotten yelling in error path
- ensure 64-bit engine mask is used everywhere

v3: Marcin Slusarz <marcin.slusarz@gmail.com>
- sparse fixes
- inline nv_printk into nv_assert to prevent recursive inlining issues

v4: Ben Skeggs <bskeggs@redhat.com>
- fixed minor memory leak on gpuobj destruction
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Future work will be headed in the way of separating the policy supplied by
the nouveau drm module from the mechanisms provided by the driver core.

There will be a couple of major classes (subdev, engine) of driver modules
that have clearly defined tasks, and the further directory structure change
is to reflect this.

No code changes here whatsoever, aside from fixing up a couple of include
file pathnames.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Won't necessarily be a drm_mm_node in the future, and I can't think of any
good reason to not use the offset from the bo struct.  There may have been
some reason once apon a time, but, separate commit just in case.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes some unfortunate races on resume.  The G84 version of the code doesn't
need this as "gpuobj"s are automagically suspended/resumed by the core code
whereas pinned buffer objects are not.

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

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>

Otherwise when X starts we commonly get a black screen scanning
out nothing, its wierd dpms on/off from userspace brings it back,

With this on F18, multi-seat works again with my 1920x1200 monitor
which is above the sku limit for the device I have.

Cc: stable@vger.kernel.org
Reviewed-by: NAlex Deucher <alexander.deucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We don't allocate enough data for this struct.  As soon as we start
modifying event->event on the next lines, then we're going beyond the
end of the memory we allocated.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@gmail.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>

Cards typically have 5-7 scratch registers; one of these is reserved for
rdev->rptr_save_reg. Unfortunately the reservation is done in function
r100_cp_init, which is called by all drivers except r600 - and this
function is also invoked on resume from suspend. After several resumes,
no scratch registers are free and graphics acceleration is disabled.

Dmesg then reports either:
   *ERROR* radeon: cp failed to get scratch reg (-22).
   *ERROR* radeon: cp isn't working(-22).
   radeon 0000:01:00.0: failed initializing CP (-22).
or:
   *ERROR* radeon: failed to get scratch reg (-22).
   *ERROR* radeon: failed testing IB on GFX ring (-22).
   *ERROR* ib ring test failed (-22).

The chain of calls on boot for all except r600 is:
radeon_init -> ... -> (rXXX_init) -> rXXX_startup -> r100_cp_init

The chain of calls on resume for all except r600 is:
rXXX_resume -> rXXX_startup -> r100_cp_init.

R600 correctly allocates rptr_save_reg in r600_init (ie once only, not
in resume). However moving the code into the init functions for all
drivers means touching 4 drivers. So instead, this patch just adds a
test in r100_cp_init to avoid reallocating on resume. As the rdev
structure is allocated via kzalloc in radeon_driver_load_kms, and zero
is not a valid registerid, zero safely implies not-yet-allocated.

This issue appears to have been introduced in c7eff978 (3.6.0-rcN)
Signed-off-by: NSimon Kitching <skitching@vonos.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.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>

This reverts commit 985f61f7.

This commit fixed certain cases, but ended up regressing others
due to limitations in the current KMS API.  A proper fix is too
invasive for 3.6.  Push it back to 3.7.
Reported-by: NAndres Freund <andres@anarazel.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.

In intel_hdmi_dpms(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
be set to trigger unsolicated event to notify Alsa driver the change.

intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
remove the hdmi cable, here's debug log:

[  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
[  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0

so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this
cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.

This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:

[  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
[  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pin-leaks persist and we get the perennial bug reports of machine
lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that
the object cannot be pinned at that time it should prevent the driver from
locking up, and hopefully restore a semblance of working whilst still
leaving us a OOPS to debug.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>