... to avoid reacquiring it to drop the object reference count on
exit. Note we have to make sure we now drop (and reacquire) the lock
around acquiring the mm semaphore on the slow paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After allocation a handle for the fresh object, we know that we can
safely drop the refcnt without triggering a free so we do not need the
mutex. Strangely, this mutex acquisition is the one that appears on
driver profiles.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid an early eviction of the batch buffer into the uncached GTT
domain, and so do the relocation fixup in cacheable memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... perform an access validation check up front instead and copy them in
on-demand, during i915_gem_object_pin_and_relocate(). As around 20% of
the CPU overhead may be spent inside vmalloc for the relocation entries
when submitting an execbuffer [for x11perf -aa10text], the savings are
considerable and result in around a 10% throughput increase [for glyphs].
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rely on monitor's audio capability to turn on audio output for HDMI.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This will turn on DP audio output by checking monitor's audio
capability.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[ickle: rebase onto recent changes and rearranged for clarity]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The time between start of the pixel clock and backlight enable is a basic
panel timing constraint. If the Panel Power On/Off registers are found
to be 0, assume we are booting without VBIOS initialization and set these
registers to something reasonable.
Change-Id: Ibed6cc10d46bf52fd92e0beb25ae3525b5eef99d
Signed-off-by: Bryan Freed <bfreed@chromium.org>
[ickle: rearranged into a separate function to distinguish its role from
simply parsing the VBIOS tables.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If userspace is submitting so many long running batches that the ring
becomes full, throttle by sleeping for a 1ms before checking for free
space. Simply yielding was causing excessive scheduler overhead whilst
making no progress.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In i2c GPIO fallback, index 6 is reserved for nothing.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
FDI_PLL_BIOS_0 register is for Ironlake only, don't apply to
Sandybridge.
Original-patch-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the PLL may still be on, and the training pattern may not be
correct. Fixes suspend/resume on my PCH eDP test system.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: minor merge conflict and silence the compiler]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Freeing the Hardware Status Page was writing to the HWS register in
order to disable the GPU writing to the HWS page. Unfortunately, we were
writing to the mmio register after unmapping the register space, hence
the oops.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 6939a5aca7.
Daniel Vetter supplied a set of fixes for all the module unload bugs he
could trigger on his machines, so let the fun recommence!
The enter argument as implemented by commit 413d45d362 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.
There is no runtime behavior change as a result of this patch.
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever happened.
There is a short cut used by this patch where gamma_store is used as
the save space. If this turns out to be a problem in the future a
pre-allocated chunk of memory will be required for each crtc to save
and restore the LUT information.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit ff773714dd.
A generic solution is needed to save and retore the LUT information.
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
TTM-based DRM drivers need to be able to bind user memory to the AGP
aperture. This patch fixes the "[TTM] AGP Bind memory failed." errors
and the subsequent fallout seen with the nouveau driver.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Grzesiek Sójka <pld@pfu.pl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Function ttm_bo_wait_unreserved can be slightly simplified.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need the unlocked variant for the new codepath introduced to fix the
race condition in master recently.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes cursor corruption in certain cases.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
When a driver module is unloaded and the last still open file is a raw
MIDI device, the card and its devices will be actually freed in the
snd_card_file_remove() call when that file is closed. Afterwards, rmidi
and rmidi->card point into freed memory, so the module pointer is likely
to be garbage.
(This was introduced by commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-by: Krzysztof Foltman <wdev@foltman.com>
Cc: 2.6.30-2.6.35 <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fixes build for me... these are what's tested in byteorder.h...
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit a7f8388e accidentally removed it... Al explains:
"Sorry, reordering breakage. In the signals tree here I have
static inline void sig_set_blocked(struct sigset_t *set)
...
and it's used all over the place (including quite a few places where
we currently have sigprocmask(SIG_SETMASK, set, NULL), which is what
it's equivalent to). With that done, m32r doesn't use _BLOCKABLE
anywhere, so it got removed. And that chunk got picked when I'd been
reordering the queue to pull the arch-specific fixes in front.
Sorry."
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We currently have a kernel internal type called aligned_u64 which aligns
__u64's on 8 bytes boundaries even on systems which would normally align
them on 4 byte boundaries. This patch creates a new type __aligned_u64
which does the same thing but which is exposed to userspace rather than
being kernel internal.
[akpm: merge early as both the net and audit trees want this]
[akpm@linux-foundation.org: enhance the comment describing the reasons for using aligned_u64. Via Andreas and Andi.]
Based-on-patch-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Eric Paris <eparis@redhat.com>
Cc: Jan Engelhardt <jengelh@medozas.de>
Cc: David Miller <davem@davemloft.net>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix a build error introduced by d6d1b650ae ("param: simple
locking for sysfs-writable charp parameters").
CC arch/um/kernel/trap.o
arch/um/drivers/hostaudio_kern.c: In function 'hostaudio_open':
arch/um/drivers/hostaudio_kern.c:204: error: '__param_dsp' undeclared (first use in this function)
arch/um/drivers/hostaudio_kern.c:204: error: (Each undeclared identifier is reported only once
arch/um/drivers/hostaudio_kern.c:204: error: for each function it appears in.)
arch/um/drivers/hostaudio_kern.c: In function 'hostmixer_open_mixdev':
arch/um/drivers/hostaudio_kern.c:265: error: '__param_mixer' undeclared (first use in this function)
arch/um/drivers/hostaudio_kern.c:272: error: '__param_dsp' undeclared (first use in this function)
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Tested-by: Toralf Förster <toralf.foerster@gmx.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sysctl check complains with a WARN() when proc_doulongvec_minmax() or
proc_doulongvec_ms_jiffies_minmax() are used by a vector of longs (with
more than one element), with no min or max value specified.
This is unexpected, given we had a bug on this min/max handling :)
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix SDIO suspend/resume regression introduced by 4c2ef25fe0 "mmc: fix
all hangs related to mmc/sd card insert/removal during suspend/resume":
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
pm_op(): platform_pm_suspend+0x0/0x5c returns -38
PM: Device pxa2xx-mci.0 failed to suspend: error -38
PM: Some devices failed to suspend
4c2ef25fe0 moved the card removal/insertion mechanism out of MMC's
suspend/resume path and into pm notifiers (mmc_pm_notify), and that
broke SDIO's expectation that mmc_suspend_host() will remove the card,
and squash the error, in case -ENOSYS is returned from the bus suspend
handler (mmc_sdio_suspend() in this case).
mmc_sdio_suspend() is using this whenever at least one of the card's SDIO
function drivers does not have suspend/resume handlers - in that case
it is agreed to force removal of the entire card.
This patch fixes this regression by trivially bringing back that part of
mmc_suspend_host(), which was removed by 4c2ef25fe0.
Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: <stable@kernel.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Chris Ball <cjb@laptop.org>
* 'upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: Add Cando touch screen 15.6-inch product id
HID: Add MULTI_INPUT quirk for turbox/mosart touchscreen
HID: hidraw, fix a NULL pointer dereference in hidraw_write
HID: hidraw, fix a NULL pointer dereference in hidraw_ioctl
Commit f81f2f7c (ubd: drop unnecessary rq->sector manipulation)
dropped request->sector manipulation in preparation for global request
handling cleanup; unfortunately, it incorrectly assumed that the
updated sector wasn't being used.
ubd tries to issue as many requests as possible to io_thread. When
issuing fails due to memory pressure or other reasons, the device is
put on the restart list and issuing stops. On IO completion, devices
on the restart list are scanned and IO issuing is restarted.
ubd issues IOs sg-by-sg and issuing can be stopped in the middle of a
request, so each device on the restart queue needs to remember where
to restart in its current request. ubd needs to keep track of the
issue position itself because,
* blk_rq_pos(req) is now updated by the block layer to keep track of
_completion_ position.
* Multiple io_req's for the current request may be in flight, so it's
difficult to tell where blk_rq_pos(req) currently is.
Add ubd->rq_pos to keep track of the issue position and use it to
correctly restart io_req issue.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Richard Weinberger <richard@nod.at>
Tested-by: Richard Weinberger <richard@nod.at>
Tested-by: Chris Frey <cdfrey@foursquare.net>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
If you build aout support as a module, you'll want these exported.
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Tony Luck reports that the addition of the access_ok() check in commit
0eead9ab41 ("Don't dump task struct in a.out core-dumps") broke the
ia64 compile due to missing the necessary header file includes.
Rather than add yet another include (<asm/unistd.h>) to make everything
happy, just uninline the silly core dump helper functions and move the
bodies to fs/exec.c where they make a lot more sense.
dump_seek() in particular was too big to be an inline function anyway,
and none of them are in any way performance-critical. And we really
don't need to mess up our include file headers more than they already
are.
Reported-and-tested-by: Tony Luck <tony.luck@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
ehea: Fix a checksum issue on the receive path
net: allow FEC driver to use fixed PHY support
tg3: restore rx_dropped accounting
b44: fix carrier detection on bind
net: clear heap allocations for privileged ethtool actions
NET: wimax, fix use after free
ATM: iphase, remove sleep-inside-atomic
ATM: mpc, fix use after free
ATM: solos-pci, remove use after free
net/fec: carrier off initially to avoid root mount failure
r8169: use device model DMA API
r8169: allocate with GFP_KERNEL flag when able to sleep
akiphie points out that a.out core-dumps have that odd task struct
dumping that was never used and was never really a good idea (it goes
back into the mists of history, probably the original core-dumping
code). Just remove it.
Also do the access_ok() check on dump_write(). It probably doesn't
matter (since normal filesystems all seem to do it anyway), but he
points out that it's normally done by the VFS layer, so ...
[ I suspect that we should possibly do "vfs_write()" instead of
calling ->write directly. That also does the whole fsnotify and write
statistics thing, which may or may not be a good idea. ]
And just to be anal, do this all for the x86-64 32-bit a.out emulation
code too, even though it's not enabled (and won't currently even
compile)
Reported-by: akiphie <akiphie@lavabit.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
