For drivers which might want to disable fbdev legacy support.
Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.
v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!
v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The conflict in intel_drv.h tripped me up a bit since a patch in dinq
moves all the functions around, but another one in drm-next removes a
single function. So I'ev figured backing this into a backmerge would
be good.
i915_dma.c is just adjacent lines changed, nothing nefarious there.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_drv.h
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disable MSIs for now until we can fix them up
* nouveau/drm-nouveau-next:
drm/nouveau/mc: disable msi support by default, it's busted in tons of places
We can get the PCI vendor and device IDs via dev->pdev. So we can drop
the duplicated information.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.
The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff the user holds a valid
gem reference. That is, as the gem object holds a reference to the
nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
guaranteed to also hold a gem reference. The gem object might get
destroyed after the last user drops the gem-ref via
drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
gem-reference.
For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
valid. However, this shouldn't be used for real functionality to avoid
gem-internal dependencies.
Note that the implementation follows the previous style. However, we no
longer can check for bo->gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Use 'to_i2c_driver(client->dev.driver)' instead to get direct access to
the i2c_driver struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This field was only accessed by the nouveau driver, but never set. So
concluded we can rid of this one.
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
acpi_has_method() is a new ACPI API introduced to check
the existence of an ACPI control method.
It can be used to replace acpi_get_handle() in the case that
1. the calling function doesn't need the ACPI handle of the control method.
and
2. the calling function doesn't care the reason why the method is unavailable.
Convert acpi_get_handle() to acpi_has_method()
in drivers/gpu/drm/nouveau/nouveau_acpi.c in this patch.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
CC: Ben Skeggs <bskeggs@redhat.com>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
A couple of bios parser fixes (one for ancient chips, another for new ones - important in Optimus configs). Another to make sure KMS is enabled on certain Optimus configs, and a TTM failure path fix.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/ttm: prevent double-free in nouveau_sgdma_create_ttm() failure path
drm/nouveau/bios/init: fix thinko in INIT_CONFIGURE_MEM
drm/nouveau/kms: enable for non-vga pci classes
drm/nouveau/bios/init: stub opcode 0xaa
if we have no crtcs we need to not call the display resume code.
Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I was getting a order 4 allocation failure from kmalloc when testing some
game after a few days uptime with some suspend/resumes.
For big allocations vmalloc should be used instead.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some vbioses have extra useless entries after "the end" of the table. This is
problematic since all of the vbios I found with this issue redefine the
pwm freq divider to insane levels (52750 Hz instead of 2500), thus breaking
fan management.
The first solution to solve this mess would be to change the length of the
table. The solution I choose was simply to avoid setting the pwm freq twice
as the other redefinitions are harmless with our current parser.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Reported-by: Mariusz Bialonczyk <manio@skyboo.net>
Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
v2 (Ben Skeggs): blacklist BR02 boards
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit ea9197cc32 effectively enabled the
use of an improved DAC detection code, but introduced a regression on
the original nv50 chipset, causing a ghost monitor to be detected.
v2 (Ben Skeggs): the offending line was likely a thinko, removed it for
all chipsets (tested nv50 and nve6 to cover entire range) and added
some additional debugging.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67382
Tested-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
i2c_bit_add_bus can call the pre_xfer function, which expects the func
pointer to be set. Pass in func to the port creation logic so that it is
set before i2c_bit_add_bus.
See https://bugs.freedesktop.org/show_bug.cgi?id=68456
Reported-by: Hans-Peter Deifel <hpdeifel@gmx.de>
Tested-by: Hans-Peter Deifel <hpdeifel@gmx.de>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Therm uses 3 ptimer alarms. Two to drive the fan and one for polling the
temperature. When suspending/resuming, alarms will never be fired.
As we are checking if there isn't an alarm pending before rescheduling
another one, we end up never checking temperature or updating the
fan speed.
This commit also adds debug messages to be able to spot more easily
if this case happens again in the future. Sorry for the spam if you
activate the debug level though.
Tested-by: Dash Four <mr.dash.four@googlemail.com>
v2:
- fix temperature polling too
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since alarms don't play well with suspend, it is important every alarm
user cancels his tasks before suspending.
The task should be rescheduled on resume.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Dash Four <mr.dash.four@googlemail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This can be useful if some parts of Nouveau try to calculate the time
between two events. Without this patch, the time difference would be
negative in the case where the computer is suspended/resumed between
two events.
This patch should fix fan speed probing when done while suspending/resuming.
Solve this by saving the current time before suspending and by restoring it
on resume.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If the fan was in manual or auto mode, we should restore the fan speed
that was previously set when resuming.
The initial pwm value is saved when loading the module.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Dash Four <mr.dash.four@googlemail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Martin Peres <martin.peres@labri.fr>
Tested-by: Dash Four <mr.dash.four@googlemail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This was already required before, but no check in the kernel was done
to enforce it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The values are already stored on chipset specific basis in the ctor.
Make the most of them and simplify the code further by using a temporary
variable to avoid code duplication.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the
same way as NVC0, but with a couple of different values. Also make sure
that the PPP engine is handled in the fifo/mc/vm.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex writes:
This is the radeon drm-next request. Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes
[airlied: fix up a bunch of conflicts from drm_order removal]
* 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux: (898 commits)
drm/radeon/dpm: make sure dc performance level limits are valid (CI)
drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2)
drm/radeon: gcc fixes for extended dpm tables
drm/radeon: gcc fixes for kb/kv dpm
drm/radeon: gcc fixes for ci dpm
drm/radeon: gcc fixes for si dpm
drm/radeon: gcc fixes for ni dpm
drm/radeon: gcc fixes for trinity dpm
drm/radeon: gcc fixes for sumo dpm
drm/radeonn: gcc fixes for rv7xx/eg/btc dpm
drm/radeon: gcc fixes for rv6xx dpm
drm/radeon: gcc fixes for radeon_atombios.c
drm/radeon: enable UVD interrupts on CIK
drm/radeon: fix init ordering for r600+
drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled
drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init
drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume
radeon kms: fix uninitialised hotplug work usage in r100_irq_process()
drm/radeon/audio: set up the sads on DCE3.2 asics
drm/radeon: fix handling of variable sized arrays for router objects
...
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_gem_dmabuf.c
drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/radeon/cik.c
drivers/gpu/drm/radeon/ni.c
drivers/gpu/drm/radeon/r600.c
This lets drivers see the flags requested by the application
[airlied: fixup for rcar/imx/msm]
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
This hooks nouveau up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and optimus laptops.
a) rewrite suspend/resume printks to hide them during dynamic s/r
to avoid cluttering logs
b) add runtime pm suspend to irq handler, crtc display, ioctl handler,
connector status,
c) handle hdmi audio dynamic power on/off using magic register.
v0.5:
make sure we hit D3 properly
fix fbdev_set_suspend locking interaction, we only will poweroff if we have no
active crtcs/fbcon anyways.
add reference for active crtcs.
sprinkle mark last busy for autosuspend timeout
v0.6:
allow more flexible debugging - to avoid log spam
add option to enable/disable dynpm
got to D3Cold
v0.7:
add hdmi audio support.
v0.8:
call autosuspend from idle, so pci config space access doesn't go straight
back to sleep, this makes starting X faster.
only signal usage if we actually handle the irq, otherwise usb keeps us awake.
fix nv50 display active powerdown
v0.9:
use masking function to enable hdmi audio
set busy when we fail to suspend
Signed-off-by: Dave Airlie <airlied@redhat.com>
For optimus and powerxpress muxless we really want the GPU
driver deciding when to power up/down the GPU, not userspace.
This adds the ability for a driver to dynamically power up/down
the GPU and remove the switcheroo from controlling it, the
switcheroo reports the dynamic state to userspace also.
It also adds 2 power domains, one for machine where the power
switch is controlled outside the GPU D3 state, so the powerdown
ordering is done correctly, and the second for the hdmi audio
device to make sure it can resume for PCI config space accesses.
v1.1: fix build with switcheroo off
v2: add power domain support for radeon and v1 nvidia dsms
v2.1: fix typo in off case
v3: add audio power domain for hdmi audio + misc audio fixes
v4: use PCI_SLOT macro, drop power reference on hdmi audio resume
failure also.
Signed-off-by: Dave Airlie <airlied@redhat.com>
GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().
TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.
All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).
v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
access was denied.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In commit 77145f1cbd was introduced
error which cause that reclocking on nv40 not working anymore.
There is missing assigment of return value from pll_calc to ret.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Allocating type=0 marks the memory as free. This allows the ltcg memory
to be allocated twice.
Add a BUG_ON in core/mm.c to prevent this ever happening again.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some registers were not initialized in init, this causes them to be
uninitialized after suspend.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit dceef5d87 (drm/nouveau/fb: initialise vram controller as pfb
sub-object) moved some code around and introduced these null derefs.
pfb->ram is set to the new ram object outside of this ctor.
Reported-by: Ronald Uitermark <ronald645@gmail.com>
Tested-by: Ronald Uitermark <ronald645@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.
No merged drm driver has ever done that.
After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:
commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <airlied@linux.ie>
Date: Sun Aug 29 12:04:35 2004 +0000
Drop GAMMA DRM from a great height ...
Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.
So stop this particular cargo-cult and rip it all out.
v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.
v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.
v4: Actually git add ... tsk.
Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Neat that QA (and Ben) keeps on humming along while I'm on vacation, so
you already get the next feature pull request:
- proper eLLC support for HSW from Ben
- more interrupt refactoring
- add w/a tags where we implement them already (Damien)
- hangcheck fixes (Chris) + hangcheck stats (Mika)
- flesh out the new vm structs for ppgtt and ggtt (Ben)
- PSR for Haswell, still disabled by default (Rodrigo et al.)
- pc8+ refclock sequence code from Paulo
- more interrupt refactoring from Paulo, unifying ilk/snb with the ivb/hsw
interrupt code
- full solution for the Haswell concurrent reg access issues (Chris)
- fix racy object accounting, used by some new leak tests
- fix sync polarity settings on ch7xxx dvo encoder
- random bits&pieces, little fixes and better debug output all over
[airlied: fix conflict with drm_mm cleanups]
* tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel: (289 commits)
drm/i915: Do not dereference NULL crtc or fb until after checking
drm/i915: fix pnv display core clock readout out
drm/i915: Replace open-coded offset_in_page()
drm/i915: Retry DP aux_ch communications with a different clock after failure
drm/i915: Add messages useful for HPD storm detection debugging (v2)
drm/i915: dvo_ch7xxx: fix vsync polarity setting
drm/i915: fix the racy object accounting
drm/i915: Convert the register access tracepoint to be conditional
drm/i915: Squash gen lookup through multiple indirections inside GT access
drm/i915: Use the common register access functions for NOTRACE variants
drm/i915: Use a private interface for register access within GT
drm/i915: Colocate all GT access routines in the same file
drm/i915: fix reference counting in i915_gem_create
drm/i915: Use Graphics Base of Stolen Memory on all gen3+
drm/i915: disable stolen mem for OVERLAY_NEEDS_PHYSICAL
drm/i915: add functions to disable and restore LCPLL
drm/i915: disable CLKOUT_DP when it's not needed
drm/i915: extend lpt_enable_clkout_dp
drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
drm/i915: Add some debug breadcrumbs to connector detection
...
There is no need to pass constants via stack. The width may be explicitly
specified in the format.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Because, there is no reason for it not to be const.
v1: original
v2: fix compile break in vmwgfx, and couple related cleanups suggested
by Ville Syrjälä
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Reviwed-by: Rob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Never used to be required, but a recent change made it necessary.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Looks like the rewrite in commit ebb945a94b ("drm/nouveau: port all
engines to new engine module format") missed that one little detail.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Unused and irrelavant since the code move of DP training/linkcontrol interrupt
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commits 0a9e2b959 (drm/nvd0/disp: move HDA codec setup to core) and
a4feaf4ea (drm/nva3/disp: move hda codec handling to core) moved code
around but neglected to fill data up to 0x60 as before. This caused
/proc/asound/cardN/eld#3.0 to show eld_valid as 0. With this patch, that
file is again populated with the correct data.
See https://bugs.freedesktop.org/show_bug.cgi?id=67051
Reported-and-tested-by: Alex <alupu01@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
object->engine is null, which leads to a null deref down the line
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes vgaswitcheroo on a card without display.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since the original merge of nouveau to upstream kernel, we were assuming
that nv90 (and later) cards have 32 lines.
Based on mmio traces of the binary driver, as well as PBUS error messages
during read/write of the e070/e074 registers, we can conclude that nv92
has only 16 lines whereas nv94 (and later) cards have 32.
Reported-and-tested-by: David M. Lloyd <david.lloyd@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Kernel panic caused by list corruption in ltcg seems to indicate a
concurrency issue.
Take mutex of pfb like nv50_ram_put() to eliminate concurrency.
V2: Separate critical section into separate function, avoid taking the
lock twice on NVC0
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The current logic is wrong since we send fw->size >> 8 to the
card. Rounding the size up by 0x100 and 0x1000 didn't seem to help,
the card still hung, so go back to what the blob does -- 0x40000.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the new vma-manager infrastructure. This doesn't change any
implementation details as the vma-offset-manager is nearly copied 1-to-1
from TTM.
The vm_lock is moved into the offset manager so we can drop it from TTM.
During lookup, we use the vma locking helpers to take a reference to the
found object.
In all other scenarios, locking stays the same as before. We always
guarantee that drm_vma_offset_remove() is called only during destruction.
Hence, helpers like drm_vma_node_offset_addr() are always safe as long as
the node has a valid offset.
This also drops the addr_space_offset member as it is a copy of vm_start
in vma_node objects. Use the accessor functions instead.
v4:
- remove vm_lock
- use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock)
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Martin Peres <martin.peres@labri.fr>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The former doesn't do anything without DRIVER_HAVE_DMA (which is
force-disabled for kms drivers anyway). The latter isn't used by the
(kms) nouveau ddx.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The API allows up to 64-bits allocations, but size is handled as int
inside nouveau almost everywhere. Until this is fixed it's better to
prevent negative sizes.
The 256 kB before INT_MAX is paranoia, because of the large page
aligning below that could flip it above INT_MAX.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This prevents 100% cpu usage on fermi cards when the exit interrupt
from the secret scrubber is not acked.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The moves themselves were generally async to graphics previously, with
the exception that if the "main" channel is used to synchronise a
page flip at the same time, it can end up blocked for a noticable amount
of time for large buffer moves.
Not really critical, and there's better ways of handling this, but they
are all rather invasive, so this is fine for now.
Based on a patch by Maarten Lankhorst addressing the same issue.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
calim didn't like 150 seconds timeout, so lower the timeout for him.
15 seconds should still be plenty.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This should no longer be required, and is harmful for framebuffer pinning.
Also add a warning if unpin causes the pin count to drop below 0.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Weren't critical previously, the buffers would go away anyway. But with
recent changes to core drm/ttm lockdep will get pissed off now, so let's
fix it.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
b580c9e2b7 introduced additional problems
while trying to solve issues that became apparent while porting to the
new reservation stuff.
The major problem was that the the previously mentioned patch took the
client mutex earlier than previously, but the pinning of new_bo can
can potentially cause a buffer move, which would result in attempting to
acquire the same mutex again.
This commit attempts to fix that "fix".
Thanks to Maarten for the tips on keeping lockdep happy and cooking :)
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Two minor fixes for regressions.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nvc0/gr: fix gpc firmware regression
drm/nouveau: fix minor thinko causing bo moves to not be async on kepler
"drm/nve0-/gr: some new gpc registers can have multiple copies"
5ee86c4190 caused a regression for nvc0, because the bit indicating last
transfer has occured was no longer set, resulting in random system lockups.
Reported-by: Ronald Uitermark <ronald645@gmail.com>
Tested-by: Ronald Uitermark <ronald645@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
- GF117 acceleration support
- GK110 acceleration-with-blob-ucode support, and initial work towards
fixing our own ucode to be suitable.
- Large cleanups of fermi/kepler context handling
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (22 commits)
drm/nva3/disp: Fix HDMI audio regression
drm/nv50-/disp: Use output specific mask in interrupt
drm/nouveau: use vmalloc for pgt allocation
drm/nvc0-/gr: remove some more of the hardcoded register writes
drm/nvc0-/gr: factor out yet more unknown magic into versioned functions
drm/nvd7/devinit: use fermi class, not tesla
drm/nvf0-/gr: ctxsw scratch reg count got bumped to 16
drm/nvc0-/gr: remove hardcoding of UNK count/mask in GPCCS ucode
drm/nvf0/gr: build cs ucode for GK110
drm/nvc0-/gr: extend one of the magic calculations for >4 GPCs
drm/nvf0/gr: fix ddx shaders locking up on me
drm/nvc0/devinit: minor typo
drm/nvf0/gr: enable support, if external cs ucode is available
drm/nvf0/gr: magic sequence that makes PGRAPH come out of hiding
drm/nvf0/ce: enable support
drm/nvf0/fifo: enable support
drm/nvd7/gr: initial support
drm/nvc0-/gr: generate cs register lists from grctx data
drm/nvc0-/gr: tpc regs a subset of gpc, add separate list for gpc/unk regs
drm/nve0-/gr: some new gpc registers can have multiple copies
...
This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).
Reported-and-tested-by: Max Baldwin <archerseven@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
The commit
commit 476e84e126
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Feb 11 09:24:23 2013 +1000
drm/nv50-/disp: initial supervisor support for off-chip encoders
changed the write mask in one of the interrupt functions for on-chip encoders,
causing a regression in certain VGA dual-head setups. This commit reintroduces
the mask thus resolving the regression
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66129
Reported-and-Tested-by: Yves-Alexis <corsac@debian.org>
Cc: stable@vger.kernel.org [3.9+]
CC: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Page tables on nv50 take 48kB, which can be hard to allocate in one piece.
Let's use vmalloc.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@vger.kernel.org [3.7+]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NVC1/NVD9 are the only chipsets that should have anything different
happen on them after this. We previously weren't doing these
register modifications, and NVIDIA do.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GK110 exposes more than one, and needs to be dealt with in the ctxsw
ucode just like the TPC sets are.
Broadcast is at +0xe00.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
- Various fixes that make surviving concurrent piglit more possible.
- Buffer object deletion no longer synchronous
- Context/register initialisation updates that have been reported to
solve some stability issues (particularly on some problematic GF119
chips)
- Kernel side support for VP2 video decoding engines
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (44 commits)
drm/nvd0-/disp: handle case where display engine is missing/disabled
drm/gr/nvc0-: merge nvc0/nve0 ucode, and use cpp instead of m4
drm/nouveau/bsp/nv84: initial vp2 engine implementation
drm/nouveau/vp/nv84: initial vp2 engine implementation
drm/nouveau/core: xtensa engine base class implementation
drm/nouveau/vdec: fork vp3 implementations from vp2
drm/nouveau/core: move falcon class to engine/
drm/nouveau/kms: don't fail if there's no dcb table entries
drm/nouveau: remove limit on gart
drm/nouveau/vm: perform a bar flush when flushing vm
drm/nvc0/gr: cleanup register lists, and add nvce/nvcf to switches
drm/nvc8/gr: update initial register/context values
drm/nvc4/gr: update initial register/context values
drm/nvc1/gr: update initial register/context values
drm/nvc3/gr: update initial register/context values
drm/nvc0/gr: update initial register/context values
drm/nvd9/gr: update initial register/context values
drm/nve4/gr: update initial register/context values
drm/nvc0-/gr: bump maximum gpc/tpc limits
drm/nvf0/gr: initial register/context setup
...
Not really "core" per-se. About to merge Ilia's work adding another
similar class for the VP2 xtensa engines, so, seems like a good time to
move all these to engine/.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Most graphics cards nowadays have a multiple of this limit as their vram,
so limiting GART doesn't seem to make much sense.
Signed-off-by: Maarten >Lnkhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
internally".
nvidia always seems to do this flush after writing values.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvc0_vm_flush() accesses the pgd list, which will soon be able to race
with vm_unlink() during channel destruction.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These operations can take quite some time, and we really don't want to
have to hold a spinlock for too long.
Now that the lock ordering for vm and the gr/nv84 hw bug workaround has
been reversed, it's possible to use a mutex here.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Helps us to get identical numbers to the binary driver for (at least)
Kepler memory PLLs, and fixes a rounding error.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
And, will depend on FB/VOLT/DAEMON being ready when it gets initialised
so that it can set/restore clocks.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These are pretty much useless for reclocking purposes. Lets make it
clearer what they're for and move them to DEVINIT to signify they're
for the very simple PLL setting requirements of running the init
tables.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Now that the code is compatible in semantics, flip the switch.
Use ww_mutex instead of the homegrown implementation.
ww_mutex uses -EDEADLK to signal that the caller has to back off,
and -EALREADY to indicate this buffer is already held by the caller.
ttm used -EAGAIN and -EDEADLK for those, respectively. So some changes
were needed to handle this correctly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
cli->mutex was inverted with reservations, and multiple reservations were
used without a ticket, fix both. This commit had to be done after the previous
commit, because otherwise ttm_eu_* calls would use a different seqno counter..
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit converts the source of the val_seq counter to
the ww_mutex api. The reservation objects are converted later,
because there is still a lockdep splat in nouveau that has to
resolved first.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Having nouveau builtin would still allow ACPI_VIDEO to be used as external module
if some of the deps for acpi_video have not been met, which would result in a linking
failure. Solve this by selecting all dependencies as well.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
