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: Ben 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: Ben 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: Ben 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: Ben 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: Ben 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: Ben 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: Ben 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: Ben 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: Ben 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: Ben 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: Ben 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: Dave Airlie <airlied@redhat.com>
This reverts commit 991083ba60.
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: Dave 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: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These two fix the MacBook Pro 2012 Retina display.
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/nouveau/linux-2.6:
drm/nv50-/gpio: initialise to vbios defaults during init
drm/nvd0/disp: hopefully fix selection of 6/8bpc mode on DP outputs
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: Ben 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: Ben Skeggs <bskeggs@redhat.com>
Ben says its just a single fix to avoid the wrong pcopy units being used.
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nvc0/copy: check PUNITS to determine which copy engines are disabled
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: Ben 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: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew 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: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ben 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: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes screen being black after changing performance level.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [3.5+]
Signed-off-by: Ben 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: Ben Skeggs <bskeggs@redhat.com>
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: init vblank requests list
drm/nv50: extend vblank semaphore to generic dmaobj + offset pair
drm/nouveau: mark most of our ioctls as deprecated, move to compat layer
drm/nouveau: move current gpuobj code out of nouveau_object.c
drm/nouveau/gem: fix object reference leak in a failure path
drm/nv50: rename INVALID_QUERY_OR_TEXTURE error to INVALID_OPERATION
drm/nv84: decode PCRYPT errors
drm/nouveau: dcb table quirk for fdo#50830
nouveau: Fix alignment requirements on src and dst addresses
Fixes kernel panic when vblank interrupt triggers before first sync to
vblank request.
(Besides init, remove some relevant leftovers from vblank rework)
Reported-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@vger.kernel.org [3.5]
Signed-off-by: Ben 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: Ben Skeggs <bskeggs@redhat.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: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben 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: Maarten 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.html
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJQAfWKAAoJEHm+PkMAQRiG/DwIAIullMhkDhD/GJcn24ZbUJoa
v6zRPK2hIavuKH/6bUoUiXT346PUYgVnRMhetuYKJFURz6KX/nmlxve/iXNn/WP1
9hnxhE+zcnp2qKI83c3Yok09eed1KnGY5hWQkqXM2gzji/OU0pCKchOcL01l//uz
iiWpNAXEVUnT92CafnHlZ55f/MWVqRFmDKi3Ty1YKSskhojQ6NOPsWCxrTxKVbim
2YPXc3D+xLHzF12ufVgla20AF4KnK8m+tFugniRAqArIagpzBUP1x1wk0RN5PyBD
FTP8lv7bSfBusp41/mPDB66WAe9EfQBoWQY6jloJjp0i8xnMyH5V05pImBV5NwU=
=O+gl
-----END PGP SIGNATURE-----
Merge tag 'v3.5-rc7' into drm-next
Merge Linus tree into drm to fixup conflicts in radeon code for further
testing before upstream merge.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/radeon/radeon_gart.c
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: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The passed mode must not be modified by the operation, make it const.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave 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: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
