Use kzalloc rather than kcalloc(1,...)
The use of the allocated memory that looks like an array is &p->relocs[0],
but this should be the same as p->relocs.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
@@
- kcalloc(1,
+ kzalloc(
...)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
linux/kernel.h has a "clamp" macro, but r300_cmdbuf also uses a variable
with the same name. Right now it doesn't seem to include the header,
but sooner or later someone will. So better rename the variable
now.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_ioctl is called with the Big Kernel Lock held,
which shows up very high in statistics on vfs_ioctl.
Moving the lock into the drm_ioctl function itself
makes sure we blame the right subsystem and it gets
us one step closer to eliminating the locked version
of fops->ioctl.
Since drm_ioctl does not require the lock itself,
we only need to hold it while calling the specific
handler. The 32 bit conversion handlers do not
interact with any other code, so they don't need
the BKL here either and can just call drm_ioctl.
As a bonus, this cleans up all the other users
of drm_ioctl which now no longer have to find
the inode or call lock_kernel.
[airlied: squashed the non-driver bits
of the second patch in here, this provides
the flag for drivers to use to select unlocked
ioctls - but doesn't modify any drivers].
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.sourceforge.net
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make sure hangcheck timer won't beat us unexpectedly on Ironlake.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This patch changes around our hotplug enable code a bit to only enable
it for ports we actually detect and initialize. This prevents problems
with stuck or spurious interrupts on outputs that aren't actually wired
up, and is generally more correct.
Fixes FDO bug #23183.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Instead of using the IS_I9XX etc macros that expand to a ton of
comparisons, use new struct intel_device_info to capture the
capabilities of the different chipsets. The drm_i915_private struct
will be initialized to point to the device info that correspond to
the actual device and this way, testing for a specific capability is
just a matter of checking a bit field.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
The old include/drm/drm_pciids.h used to be generated from the libdrm
git repo. We don't use that anymore so just use a local list in the
driver like everybody else.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after
close/reopen the LID. And I also reproduce this issue on another laptop.
After some tests and debug, it seems that it is related with that the
LVDS status is not updated in time in course of suspend/resume.
Now the LID state is used to check whether the LVDS is connected or
disconnected. And when the LID is closed, it means that the LVDS is
disconnected. When it is reopened, it means that the LVDS is connected.
At the same time on some distributions the LID event is also used to put
the system into suspend state. When the LID is closed, the system will enter
the suspend state. When the LID is reopened, the system will be resumed.
In such case when the LID is closed, user-space script will receive the LID
notification event and detect the LVDS as disconnected. Then the system will
enter the suspended state. When the LID is reopened, the system will be
resumed. As the LVDS status is not updated in course of resume, it will cause
that the LVDS connector is marked as unused and disabled. After the resume is
finished,user-space script will try to configure the display mode for LVDS.
But unfortunately as the LVDS status is not updated in time and it is still
marked as disconnected, the LVDS and its corresponding CRTC will be disabled
again in the function of drm_helper_disable_unused_functions after changing
mode for LVDS.
So we had better check and update the status of LVDS connector after receiving
the LID notication event. Then after the system is resumed from suspended
state, we can set the display mode for LVDS correctly.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reported-by: Dirk Hohndel <hohndel@infradead.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: stable@kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
The MALATA PC-81005 laptop always reports that the LID status is closed and we
can't use it reliabily for LVDS detection. So add this box into the quirk list.
https://bugs.freedesktop.org/show_bug.cgi?id=25523
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Review-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Hector <hector1987@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
* 'drm-vmware-staging' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/vmwgfx: Add DRM driver for VMware Virtual GPU
drm/vmwgfx: Add svga headers for vmwgfx driver
drm/ttm: Add more driver type enums
* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms: fix r100->r500 CS checker for compressed textures. (v2)
drm/radeon/kms: allow for texture tiling
drm/radeon/kms: init pm on all chipsets
drm/radeon/kms: HDMI support for R600 KMS
drm/radeon/kms: make sure mc is initialized before mapping blit bo
drm/radeon/kms: Return to userspace on ERESTARTSYS
drm/radeon/gem: don't leak a gem object if reserve fails on get tiling (v2)
drm/radeon/kms: don't report allocate failure on ERESTARTSYS
drm/radeon/kms: Check if bo we got from ttm are radeon object or not
drm/radeon/kms: If no placement is supplied fallback to system
drm/ttm: Fix memory type manager debug information printing
drm/ttm: Fix printk format & compute bo->mem.size at bo initialization
drm/ttm: Fix potential ttm_mem_evict_first races.
drm/ttm: Delayed delete fixes.
drm/ttm: fix two bugs in new placement routines.
drm/ttm: fix incorrect logic in ttm_bo_io path
drm/nouveau: remove use of -ERESTART
nouveau: Fix endianness with new context program loader
drm/nouveau: fix build with CONFIG_AGP=n
drm/nouveau: fix ch7006 build
One problem in i915 hibernate with current legacy pci pm ops is
that after we do freeze, we'll be forced to do resume once again,
which re-init some resources and do modesetting again, that is
unnecessary for hibernate. This patch trys to bypass that.
We can't resolve this within legacy pm framework, but can do it
easily with new pm ops. Suspend (S3) process has also been kept
without change.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Checking for the presence of a lid in order to validate whether or not
an LVDS display exists fails on some development platforms that implement
a lid device but allow the LVDS to be disabled. The VBT is correctly
updated, but Linux assumes that an LVDS is still present and lies to
userspace. Remove the lid check and trust the VBT.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
i915_gem_object_unbind had the ordering wrong. The other user,
i915_gem_object_put_fence_reg already has the correct ordering.
Results was usually corrupted pixmaps, especially garbled font glyphs
after a suspend/resume (because this evicts everything).
I'm still waiting for the feedback from the bug-reporters, but
because this obviously fixes a bug (at least for me) I'm already
submitting it.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25406
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
CC: stable@kernel.org
Previously, if there was no firmware available, the DRM would just
disable channel creation from userspace, but still use a single
channel for its own purposes.
With a bit of care it should actually be possible to do this, due
to the DRM's very limited use of the engine. It currently doesn't
work correctly however, resulting in corrupted fbcon and hangs on
a number of cards.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The context programs are *very* simple compared to the ones used by
the binary driver. There's notes in nv40_grctx.c explaining most of
the things we don't implement. If we discover if/why any of it is
required further down the track, we'll handle it then.
The PGRAPH state generated for each chipset should match what NVIDIA
do almost exactly (there's a couple of exceptions). If someone has
a lot of time on their hands, they could figure out the mapping of
object/method to PGRAPH register and demagic the initial state a little,
it's not terribly important however.
At time of commit, confirmed to be working at least well enough for
accelerated X (and where tested, for 3D apps) on NV40, NV43, NV44, NV46,
NV49, NV4A, NV4B and NV4E.
A module option has been added to force the use of external firmware
blobs if it becomes required.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
- Use driver level (0x2) for NV_DEBUG instead of all levels
- Create a NV_DEBUG_KMS for KMS level (0x4) and use them in modesetting code
- Remove a few odd NV_TRACE calls and replace some of them with NV_DEBUG_KMS or
NV_INFO
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This adds support for compressed textures to the r100->r500 CS
checker, it lets me run openarena and the demos in mesa fine.
Thanks to Maciej Cencora for initial comments.
Changes since v1:
fix calculations with Maciej formulas
Reviewed-by: Maciej Cencora <m.cencora@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the relocations for texture tiling for KMS.
Signed-off-by: Maciej Cencora <m.cencora@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next:
drm/nouveau: remove use of -ERESTART
nouveau: Fix endianness with new context program loader
drm/nouveau: fix build with CONFIG_AGP=n
drm/nouveau: fix ch7006 build
Adding basic HDMI support for R600 KMS, ported from radeonhd ddx.
[airlied:- checkpatch cleanups]
Signed-off-by: Christian Koenig <deathsimple@vodafone.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to make sure the the MC is intialized before we map the
blit shader object on r6xx+.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon_object.h wasn't converted to ERESTARTSYS change. No
each time we got an ERESTARTSYS we return to userspace (ie
we were interrupted by a signal and we let the userspace
reschedule the ioctl).
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
if we fail with ERESTARTSYS during alloc, we'll get a retry from
userspace so don't report it in dmesg.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If they are not radeon object don't do anythings special for them,
this avoid rare oops than can happen in a complex use case.
[airlied: additional fixups]
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Do as we did before rework, if no placement is supplied at bo
creation time, fallback to allocating bo from system ram. This
will fix most of the creation failed issue report we got since
the rework get merged.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
System memory type doesn't have a drm_mm manager associated to
it. This patch avoid trying to call drm_mm_debug on unitialized
drm_mm when printing debug info on the system memory manager.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
1) The function was previously called with a potentially empty
LRU list which would have lead to an OOPS or servere corruption.
2) In rare cases, after reservation has succeeded, another process may
already have evicted it or even pinned it. We must revalidate the
buffer status after releasing the lru lock.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
1) Remove from lru before reserving so we avoid competing with
evicting processes.
2) Avoid calling kref_put() on bo::list_kref while spinlocked.
3) Additional refcounting bug-checking.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
a) the loops were going to <= not <, leading to illegal memory access
b) the busy placement checks were using the placement arrays not the
busy placement ones.
Acked-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This path isn't used by radeon yet, but future drivers will want it,
so fix it right.
Reported-by: Luca Barbieri <luca@luca-barbieri.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
