Using an order 19 drm_ht for the mmap offsets is a little obscene. That
means that will a fully populated GTT with every single object mmaped at
least once in its lifetime, there will be exactly one object in each
bucket.
Typically systems only have at most a few thousand objects, though you
may see a KDE desktop hit 50000. And most of those should never be
mapped... On my systems, just using an order 10 ht would still have an
average occupancy less than 1, so apply a small safety factor and
use an order 12 ht, like the other mmap offset ht.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... and fixup some methods to accept the constant argument.
Now that constant module arrays are loaded into read-only memory, using
const appropriately has some benefits beyond warning the programmer
about likely mistakes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
the texture checking code didn't work for block formats like s3tc,
this overhauls it to work for all types.
v2: add texture array support.
v3: add subsampled formats
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau doesn't have enough information at ttm_backend_func.bind() time
to implement things like tiled GART, or to keep a buffer at a constant
address in the GPU virtual address space no matter where in physical
memory it's placed.
To resolve this, nouveau will handle binding of all buffers to the GPU
itself from the move_notify() hook. This commit ensures it's called
for all buffer moves.
Talked to Dave about the impact on radeon, which uses move_notify, it
doesn't look like anything should break there.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thomas@shipmail.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If there is an alpha channel, need to mask in 1's in the alpha channel
to prevent the fb from being completely transparent.
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds an initial framework to plug USB graphics devices
into the drm/kms subsystem.
I've started writing a displaylink driver using this interface.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This abstracts the pci/platform interface out a step further,
we can go further but this is far enough for now to allow USB
to be plugged in.
The drivers now just call the init code directly for their
device type.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.
It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.
Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.
Signed-off-by: Dave Airlie <airlied@redhat.com>
SMP i810 systems were practically nonexistent and the configuration
was not officially supported by Intel at the time when Pentium-III
was common.
With this change, it is still possible to build a distribution kernel
that has support for SMP and includes the i810 driver without the BKL.
As a precaution, check for the theoretical SMP case at run time and
refuse to load the driver.
We also need to disable CONFIG_PREEMPT builds for this driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This driver is one of the last users of the big kernel
lock, which is going away. All the hardware supported
by this driver also works with the newer i915 driver,
and recent X.org releases only work with that driver
anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (27 commits)
gpu/stub: fix acpi_video build error, fix stub kconfig dependencies
drm/radeon/kms: dynamically allocate power state space
drm/radeon/kms: fix s/r issues with bios scratch regs
agp: ensure GART has an address before enabling it
Revert "agp: AMD AGP is used on UP1100 & UP1500 alpha boxen"
amd-k7-agp: remove non-x86 code
drm/radeon/kms/evergreen: always set certain VGT regs at CP init
drm/radeon/kms: add updated ib_execute function for evergreen
drm/radeon: remove 0x4243 pci id
drm/radeon/kms: Enable new pll calculation for avivo+ asics
drm/radeon/kms: add new pll algo for avivo asics
drm/radeon/kms: add pll debugging output
drm/radeon/kms: switch back to min->max pll post divider iteration
drm/radeon/kms: rv6xx+ thermal sensor fixes
drm/nv50: fix display on 0x50
drm/nouveau: correctly pair hwmon_init and hwmon_fini
drm/i915: Only bind to function 0 of the PCI device
drm/i915: Suppress spurious vblank interrupts
drm: Avoid leak of adjusted mode along quick set_mode paths
drm: Simplify and defend later checks when disabling a crtc
...
In drm_crtc_helper_set_config, instead of always forcing all outputs
to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a
mode set, as any mode set will turn all outputs on.
This fixes https://lkml.org/lkml/2011/1/24/457
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: stable@kernel.org (2.6.37)
Reported-and-tested-by: Carlos R. Mafra <crmafra2@gmail.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We previously used a static array, but some new systems
had more states then we had array space, so dynamically
allocate space based on the number of states in the vbios.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33851
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The accelerate mode bit gets checked by certain atom
command tables to set up some register state. It needs
to be clear when setting modes and set when not.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=26942
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
These should be handled by the clear_state setup, but set them
directly as well just to be sure.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Adds new packet to disable DX9 constant emulation.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Based on the vbios code. This should hopefully
fix the pll problems on a number of avivo asics
once it's enabled.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some fixes to the thermal sensor code:
- handle negative numbers
- properly handle temp calculation on different asics
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915: Only bind to function 0 of the PCI device
drm/i915: Suppress spurious vblank interrupts
drm: Avoid leak of adjusted mode along quick set_mode paths
drm: Simplify and defend later checks when disabling a crtc
drm: Don't switch fb when disabling an output
drm/i915: Reset crtc after resume
drm/i915/crt: Force the initial probe after reset
drm/i915: Reset state after a GPU reset or resume
drm: Add an interface to reset the device
drm/i915/sdvo: If at first we don't succeed in reading the response, wait
Accidently busted a while back. We'll be creating objects that aren't
necessary here, but, they're never used so no harm..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
I broke this with my commit
07cfe0e7a8
This fixes fdo #33434
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Early chipsets (gen2/3) used function 1 as a placeholder for multi-head.
We used to ignore these since they were not assigned to
PCI_CLASS_DISPLAY_VGA. However with 934f992c7 we attempt to bind to all
Intel PCI_CLASS_DISPLAY devices (and functions) to work in multi-gpu
systems. This fails hard on gen2/3.
Reported-by: Ferenc Wágner <wferi@niif.hu>
Tested-by: Ferenc Wágner <wferi@niif.hu>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Hugh Dickins found that characters in xterm were going missing and oft
delayed. Being the curious type, he managed to associate this with the
new high-precision vblank patches; disabling these he found, restored
the orderliness of his characters.
The oddness begins when one realised that Hugh was not using vblanks at
all on his system (fvwm and some xterms). Instead, all he had to go on
were warning of a pipe underrun, curiously enough at around 60Hz. He
poked and found that in addition to the underrun warning, the hardware
was flagging the start of a new frame, a vblank, which in turn was
kicking off the pending vblank processing code.
There is little we can do for the underruns on Hugh's machine, a
Crestline [965GM], which must have its FIFO watermarks set to 8.
However, we do not need to process the vblank if we know that they are
disabled...
Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By setting the FB of a CRTC to NULL, we are turning off the CRTC (and so
disable the unused encoders and connectors). As such we can simplify the
later tests by making sure the set->mode is NULL. Setting the
num_connectors to zero means that we do not need to loop over the unused
connectors.
All current usage appears correct, this only builds additional defense
into the routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=27722
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In drm_crtc_helper_set_config, we call drm_crtc_helper_set_mode which
may return early and do no operation if the crtc is to be disabled. In
this case we merrily swap to the new fb, discarding the old_fb believing
that it has been cleaned up. However, due to the early return, the
old_fb was not presented to the backend for correct reaping, and nor was
the new one - which is about to be reaped via the
drm_helper_disable_unused_functions(), leading to incorrect refcounting
of the pinned objects.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27722
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29230
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This error is reported by cppcheck:
drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over || always evaluates to true. Did you intend to use && instead?
It looks like cppcheck is correct, so fix this. No test was run.
Cc: David Airlie <airlied@linux.ie>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/nv50: fix regression on IGPs
drm/radeon/kms: re-emit full context state for evergreen blits
drm/radeon/kms: release CMASK access in preclose_kms
drm/radeon/kms: fix r6xx+ scanout on BE systems
drm/radeon/kms: clean up some magic numbers
drm/radeon/kms: only enable HDMI mode if radeon audio is enabled
radeon/kms: fix dp displayport mode validation
drm/nvc0/grctx: correct an off-by-one
drm/nv50: Fix race with PFIFO during PGRAPH context destruction.
drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200.
drm/nvc0: implement irq handler for whatever's at 0x14xxxx
drm/nvc0: fix incorrect TPC register setup
drm/nouveau: probe for adt7473 before f75375
drm/nouveau: remove dead function definition
clear state doesn't seem to work properly in some cases
Fixes hangs in heavy 3D on some evergreen cards reported on
IRC.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=33381
possibly others.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
R6xx+ have per-block swappers. BE content in the
framebuffer will now be swapped properly during scanout.
Untested, however, the same code is reported working in
the UMS ddx.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Force DVI mode if the user specifies radeon.audio=0. The driver
doesn't handle HDMI mode properly in some cases.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=27731
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Check if there is a big enough dp clock & enough dp lane to
drive the video mode provided.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-By: Alex Deucher <alexdeucher@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6:
drm/nvc0/grctx: correct an off-by-one
drm/nv50: Fix race with PFIFO during PGRAPH context destruction.
drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200.
drm/nvc0: implement irq handler for whatever's at 0x14xxxx
drm/nvc0: fix incorrect TPC register setup
drm/nouveau: probe for adt7473 before f75375
drm/nouveau: remove dead function definition
The -rt patches change the console_semaphore to console_mutex. As a
result, a quite large chunk of the patches changes all
acquire/release_console_sem() to acquire/release_console_mutex()
This commit makes things use more neutral function names which dont make
implications about the underlying lock.
The only real change is the return value of console_trylock which is
inverted from try_acquire_console_sem()
This patch also paves the way to switching console_sem from a semaphore to
a mutex.
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert]
Signed-off-by: Torben Hohn <torbenh@gmx.de>
Cc: Thomas Gleixner <tglx@tglx.de>
Cc: Greg KH <gregkh@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Based on a patch by Takashi Iwai.
Reported-by: Matthias Hopf <mat@mshopf.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27272
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Upon resume, like after a cold boot, we need to forcibly probe the
analog connector and cannot rely on the hotplug status.
Based on a patch by Takashi Iwai.
Reported-by: Stefan Dirsch <sndirsch@suse.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=26952
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Call drm_mode_config_reset() after an invalidation event to restore any
cached state to unknown.
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Iterate over the attached CRTCs, encoders and connectors and call the
supplied reset vfunc in order to reset any cached state back to unknown.
Useful after an invalidation event such as a GPU reset or resuming.
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were not pausing after detecting the response was pending and so did
not allow the hardware sufficient time to complete before aborting. This
lead to transient failures whilst probing SDVO devices.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30235
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
