Add the support for audio clients to VGA-switcheroo for handling the
HDMI audio controller together with VGA switching. The id of the
audio controller should be given explicitly at registration time
unlike the video controller.
This changes the API as a clean-up. Instead of passing multiple
function pointers at each time, introduce a new struct holding the
whole callback functions and pass it to the registration.
The same struct will be used for the upcoming audio client
registration, too.
Dave Airlie [Fri, 11 May 2012 16:41:58 +0000 (17:41 +0100)]
Merge tag 'drm-intel-next-2012-05-06-merged' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
Daniel says
Highlights:
- sparse fixes from Ben.
- tons of little cleanups from Chris all over: tiling_changed
clarification, deferred_free list removal, ...
- fix up irq handler on gen2 & gen3 + related cleanups from Chris
- prep work for wait_rendering_timeout from Ben with some nice
refactorings
- first set of infoframe fixes from Paulo for doubleclocked CEA modes
- improve pch pll handling from Jesse and Chris
- gpu hangman, this also contains the reset fix for gen4
- rps sanity check from Chris - this papers over issues when the gpu fails
to clock up on snb/ivb, and it is shockingly easy to hit. The code
prints a big WARN backtrace and restores the hw to a sane state. The
real fix is still in the works.
Atm I'm aware of 2 regressions in -next:
- One of the gmbus patches (not gmbus itself) regressed lvds detection on
a MacbookPro. I've analyzed the bug already and I think I know what's
going on, patch is awaiting test feedback.
- Just today QA reported that DP on ilk regressed. That bug is fresh of
the press and still awaiting detailed logfiles and the bisect result.
The only thing that's clear atm is that -fixes works and -next doesn't.
Rob Clark [Tue, 1 May 2012 16:04:51 +0000 (11:04 -0500)]
drm: pass dev to drm_vm_{open,close}_locked()
Previously these functions would assume that vma->vm_file was the
drm_file. Although if in some cases if the drm driver needs to use
something else for the backing file (such as the tmpfs filp) then this
assumption is no longer true. But vma->vm_private_data is still the
GEM object.
With this change, now the drm_device comes from the GEM object rather
than the drm_file so the driver is more free to play with vma->vm_file.
The scenario where this comes up is for mmap'ing of cached dmabuf's
for non-coherent systems, where the driver needs to use fault handling
and PTE shootdown to simulate coherency. We can't use the vma->vm_file
of the dmabuf, which is using anon_inode's address_space. The most
straightforward thing to do is to use the GEM object's obj->filp for
vma->vm_file in all cases, for which we need this patch.
Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alan Cox [Fri, 11 May 2012 10:32:46 +0000 (11:32 +0100)]
cdv: Add all cedarview pci ids
Cover all D2xxx/N2xxx chips.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[Hand applied to upstream driver] Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alan Cox [Fri, 11 May 2012 10:30:53 +0000 (11:30 +0100)]
gma500: introduce some register maps
All the conditional ugly register selection really wants to be
cleaned up. Use a struct describing each pipe and its registers.
This will also let us hide some of the oddments between platforms
for any future merging of bits together. In particular the way the
DPLL and FP registers randomly wander around.
Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Wed, 9 May 2012 16:27:29 +0000 (17:27 +0100)]
drm/radeon/kms: fix warning on 32-bit in atomic fence printing
/ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c: In function ‘radeon_debugfs_fence_info’:
/ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c:606:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘long long int’ [-Wformat]
Jerome Glisse [Wed, 9 May 2012 13:35:02 +0000 (15:35 +0200)]
drm/radeon: make the ib an inline object
No need to malloc it any more.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Wed, 9 May 2012 13:34:58 +0000 (15:34 +0200)]
drm/radeon: rip out the ib pool
It isn't necessary any more and the suballocator seems to perform
even better.
Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Wed, 9 May 2012 13:34:57 +0000 (15:34 +0200)]
drm/radeon: simplify semaphore handling v2
Directly use the suballocator to get small chunks of memory.
It's equally fast and doesn't crash when we encounter a GPU reset.
v2: rebased on new SA interface.
Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 9 May 2012 13:34:56 +0000 (15:34 +0200)]
drm/radeon: multiple ring allocator v3
A startover with a new idea for a multiple ring allocator.
Should perform as well as a normal ring allocator as long
as only one ring does somthing, but falls back to a more
complex algorithm if more complex things start to happen.
We store the last allocated bo in last, we always try to allocate
after the last allocated bo. Principle is that in a linear GPU ring
progression was is after last is the oldest bo we allocated and thus
the first one that should no longer be in use by the GPU.
If it's not the case we skip over the bo after last to the closest
done bo if such one exist. If none exist and we are not asked to
block we report failure to allocate.
If we are asked to block we wait on all the oldest fence of all
rings. We just wait for any of those fence to complete.
v2: We need to be able to let hole point to the list_head, otherwise
try free will never free the first allocation of the list. Also
stop calling radeon_fence_signalled more than necessary.
v3: Don't free allocations without considering them as a hole,
otherwise we might lose holes. Also return ENOMEM instead of ENOENT
when running out of fences to wait for. Limit the number of holes
we try for each ring to 3.
Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Wed, 9 May 2012 13:34:55 +0000 (15:34 +0200)]
drm/radeon: use one wait queue for all rings add fence_wait_any v2
Use one wait queue for all rings. When one ring progress, other
likely does to and we are not expecting to have a lot of waiter
anyway.
Also add a fence_wait_any that will wait until the first fence
in the fence array (one fence per ring) is signaled. This allow
to wait on all rings.
v2: some minor cleanups and improvements.
Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 9 May 2012 13:34:54 +0000 (15:34 +0200)]
drm/radeon: define new SA interface v3
Define the interface without modifying the allocation
algorithm in any way.
v2: rebase on top of fence new uint64 patch
v3: add ring to debugfs output
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 9 May 2012 13:34:48 +0000 (15:34 +0200)]
drm/radeon: rework locking ring emission mutex in fence deadlock detection v2
Some callers illegal called fence_wait_next/empty
while holding the ring emission mutex. So don't
relock the mutex in that cases, and move the actual
locking into the fence code.
v2: Don't try to unlock the mutex if it isn't locked.
Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Wed, 9 May 2012 13:34:47 +0000 (15:34 +0200)]
drm/radeon: rework fence handling, drop fence list v7
Using 64bits fence sequence we can directly compare sequence
number to know if a fence is signaled or not. Thus the fence
list became useless, so does the fence lock that mainly
protected the fence list.
Things like ring.ready are no longer behind a lock, this should
be ok as ring.ready is initialized once and will only change
when facing lockup. Worst case is that we return an -EBUSY just
after a successfull GPU reset, or we go into wait state instead
of returning -EBUSY (thus delaying reporting -EBUSY to fence
wait caller).
v2: Remove left over comment, force using writeback on cayman and
newer, thus not having to suffer from possibly scratch reg
exhaustion
v3: Rebase on top of change to uint64 fence patch
v4: Change DCE5 test to force write back on cayman and newer but
also any APU such as PALM or SUMO family
v5: Rebase on top of new uint64 fence patch
v6: Just break if seq doesn't change any more. Use radeon_fence
prefix for all function names. Even if it's now highly optimized,
try avoiding polling to often.
v7: We should never poll the last_seq from the hardware without
waking the sleeping threads, otherwise we might lose events.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Wed, 9 May 2012 13:34:46 +0000 (15:34 +0200)]
drm/radeon: convert fence to uint64_t v4
This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.
Tested with and without writeback using 0xFFFFF000 as initial
fence sequence and thus allowing to test the wrap around from
32bits to 64bits.
v2: Add comment about possible race btw CPU & GPU, add comment
stressing that we need 2 dword aligned for R600_WB_EVENT_OFFSET
Read fence sequenc in reverse order of GPU write them so we
mitigate the race btw CPU and GPU.
v3: Drop the need for ring to emit the 64bits fence, and just have
each ring emit the lower 32bits of the fence sequence. We
handle the wrap over 32bits in fence_process.
v4: Just a small optimization: Don't reread the last_seq value
if loop restarts, since we already know its value anyway.
Also start at zero not one for seq value and use pre instead
of post increment in emmit, otherwise wait_empty will deadlock.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Wed, 9 May 2012 13:34:44 +0000 (15:34 +0200)]
drm/radeon: fix possible lack of synchronization btw ttm and other ring
We need to sync with the GFX ring as ttm might have schedule bo move
on it and new command scheduled for other ring need to wait for bo
data to be in place.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Tue, 8 May 2012 11:39:59 +0000 (13:39 +0200)]
Merge remote-tracking branch 'airlied/drm-core-next' into drm-intel-next-queued
Backmerge of drm-next to resolve a few ugly conflicts and to get a few
fixes from 3.4-rc6 (which drm-next has already merged). Note that this
merge also restricts the stencil cache lra evict policy workaround to
snb (as it should) - I had to frob the code anyway because the
CM0_MASK_SHIFT define died in the masked bit cleanups.
We need the backmerge to get Paulo Zanoni's infoframe regression fix
for gm45 - further bugfixes from him touch the same area and would
needlessly conflict.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 7 May 2012 09:30:46 +0000 (11:30 +0200)]
Merge tag 'v3.4-rc6' into drm-intel-next
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Ok, this is a fun story of git totally messing things up. There
/shouldn't/ be any conflict in here, because the fixes in -rc6 do only
touch functions that have not been changed in -next.
The offending commits in drm-next are 14415745b2..1fa611065 which
simply move a few functions from intel_display.c to intel_pm.c. The
problem seems to be that git diff gets completely confused:
Unfortunately there seems to be no way to teach similar smarts to the
merge diff and conflict generation code, because with the minimal diff
there really shouldn't be any conflicts. For added hilarity, every
time something in that area changes the + and - lines in the diff move
around like crazy, again resulting in new conflicts. So I fear this
mess will stay with us for a little longer (and might result in
another backmerge down the road).
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gma500: mid-bios: rewrite VBT/GCT handling in a cleaner way
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
cc1: warning: include/drm: No such file or directory [enabled by default]
It's reproducible if you build with O=/some/obj/dir and W=1.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
gma500: cdv_intel_lvds: mark cdv_intel_lvds_enc_funcs as static
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
gma500: oaktrail_hdmi_i2c_handler(): base should be __iomem
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
This was mostly already fixed but this one change is needed to match Kirill's
original submission
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
gma500: framebuffer: mark psb_fb_helper_funcs as static
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alan Cox [Thu, 3 May 2012 14:06:18 +0000 (15:06 +0100)]
gma500: opregion and ACPI
Add the opregion support and bring us in line with the opregion functionality in the
reference driver code. We can't share this with i915 currently because there are
hardcoded assumptions about dev_priv etc in both versions.
[airlied: include opregion.h fix]
Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Linus Torvalds [Sun, 6 May 2012 19:19:38 +0000 (12:19 -0700)]
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes form Peter Anvin
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver
x86, relocs: Remove an unused variable
asm-generic: Use __BITS_PER_LONG in statfs.h
x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it
Linus Torvalds [Sun, 6 May 2012 17:20:07 +0000 (10:20 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
Pull btrfs fixes from Chris Mason:
"The big ones here are a memory leak we introduced in rc1, and a
scheduling while atomic if the transid on disk doesn't match the
transid we expected. This happens for corrupt blocks, or out of date
disks.
It also fixes up the ioctl definition for our ioctl to resolve logical
inode numbers. The __u32 was a merging error and doesn't match what
we ship in the progs."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: avoid sleeping in verify_parent_transid while atomic
Btrfs: fix crash in scrub repair code when device is missing
btrfs: Fix mismatching struct members in ioctl.h
Btrfs: fix page leak when allocing extent buffers
Btrfs: Add properly locking around add_root_to_dirty_list
Al Viro [Sun, 6 May 2012 16:20:00 +0000 (17:20 +0100)]
x86: fix broken TASK_SIZE for ia32_aout
Setting TIF_IA32 in load_aout_binary() used to be enough; these days
TASK_SIZE is controlled by TIF_ADDR32 and that one doesn't get set
there. Switch to use of set_personality_ia32()...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chris Wilson [Wed, 2 May 2012 08:52:12 +0000 (09:52 +0100)]
drm/i915: Support pageflipping interrupts for all 3-pipes on IVB
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Mason [Sun, 6 May 2012 11:23:47 +0000 (07:23 -0400)]
Btrfs: avoid sleeping in verify_parent_transid while atomic
verify_parent_transid needs to lock the extent range to make
sure no IO is underway, and so it can safely clear the
uptodate bits if our checks fail.
But, a few callers are using it with spinlocks held. Most
of the time, the generation numbers are going to match, and
we don't want to switch to a blocking lock just for the error
case. This adds an atomic flag to verify_parent_transid,
and changes it to return EAGAIN if it needs to block to
properly verifiy things.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Linus Torvalds [Sat, 5 May 2012 23:34:38 +0000 (16:34 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha
Pull alpha fixes from Matt Turner:
"My alpha tree is back up (after taking quite some time to get my GPG
key signed). It contains just some simple fixes."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha:
alpha: silence 'const' warning in sys_marvel.c
alpha: include module.h to fix modpost on Tsunami
alpha: properly define get/set_rtc_time on Marvel/SMP
alpha: VGA_HOSE depends on VGA_CONSOLE
Jiri Slaby [Sat, 5 May 2012 20:49:10 +0000 (22:49 +0200)]
TTY: pdc_cons, fix regression in close
The test in pdc_console_tty_close '!tty->count' was always wrong
because tty->count is decremented after tty->ops->close is called and
thus can never be zero. Hence the 'then' branch was never executed and
the timer never deleted.
This did not matter until commit 5dd5bc40f3b6 ("TTY: pdc_cons, use
tty_port"). There we needed to set TTY in tty_port to NULL, but this
never happened due to the bug above.
So change the test to really trigger at the last close by changing the
condition to 'tty->count == 1'.
Well, the driver should not touch tty->count at all. It should use
tty_port->count and count open count there itself.
Daniel Vetter [Fri, 27 Apr 2012 13:17:46 +0000 (15:17 +0200)]
drm/i915: remove modeset reset from i915_reset
On gen4+ we don't reset the display unit, so resetting the complete
modeset state should not be necessary.
We can't do reset on gen3 anyway, which leaves us with gen2 reset:
According to Chris Wilson, that doesn't work so great, so he suggested
we just ignore that. If the need ever arrises, we can re-add it later
on.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 27 Apr 2012 13:17:43 +0000 (15:17 +0200)]
drm/i915: make gpu hangman more resilient
- reset the stop_rings infrastructure while resetting the hw to
avoid angering the hangcheck right away (and potentially declaring
the gpu permanently wedged).
- ignore reset failures when hanging due to the hangman - we don't
have reset code for all generations.
v2: Ensure that we only ignore reset failures when the hw reset is not
implemented and not when it failed.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 27 Apr 2012 13:17:40 +0000 (15:17 +0200)]
drm/i915: allow the existing error_state to be destroyed
... by writing (anything) to i915_error_state.
This way we can simulate a bunch of gpu hangs and run the error_state
capture code every time (without the need to reload the module).
To make that happen we need to abandon the simple seq_file wrappers
provided by the drm core. While at it put the new error_state
refcounting to some good use and associated the error_state to the
debugfs when opening the file. Otherwise the error_state could change
while someone is reading it. This should help greatly when we finally
get around to split up the giant single seq_file block that the
error_state file currently is into smaller parts.
v2: Actually squash all the fixes into the patch ...
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 27 Apr 2012 13:17:39 +0000 (15:17 +0200)]
drm/i915: rework dev->first_error locking
- reduce the irq disabled section, even for a debugfs file this was
way too long.
- always disable irqs when taking the lock.
v2: Thou shalt not mistake locking for reference counting, so:
- reference count the error_state to protect from concurent freeeing.
This will be only really used in the next patch.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 3 May 2012 12:48:16 +0000 (14:48 +0200)]
drm/i915: add interface to simulate gpu hangs
gpu reset is a very important piece of our infrastructure.
Unfortunately we only really it test by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one of the rather complicated pieces of code we
have, consisting of
- hang detection
- error capture
- actual gpu reset
- reset of all the gem bookkeeping
- reinitialition of the entire gpu
This patch adds a debugfs to selectively stopping rings by ceasing to
update the hw tail pointer, which will result in the gpu no longer
updating it's head pointer and eventually to the hangcheck firing.
This way we can exercise the gpu hang code under controlled conditions
without a dying gpu taking down the entire systems.
Patch motivated by me forgetting to properly reinitialize ppgtt after
a gpu reset.
Usage:
echo $((1 << $ringnum)) > i915_ring_stop # stops one ring
echo 0xffffffff > i915_ring_stop # stops all, future-proof version
then run whatever testload is desired. i915_ring_stop automatically
resets after a gpu hang is detected to avoid hanging the gpu to fast
and declaring it wedged.
v2: Incorporate feedback from Chris Wilson.
v3: Add the missing cleanup.
v4: Fix up inconsistent size of ring_stop_read vs _write, noticed by
Eugeni Dodonov.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Linus Torvalds [Sat, 5 May 2012 17:07:06 +0000 (10:07 -0700)]
Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound sound fixes from Takashi Iwai:
"As good as nothing exciting here; just a few trivial fixes for various
ASoC stuff."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: omap-pcm: Free dma buffers in case of error.
ASoC: s3c2412-i2s: Fix dai registration
ASoC: wm8350: Don't use locally allocated codec struct
ASoC: tlv312aic23: unbreak resume
ASoC: bf5xx-ssm2602: Set DAI format
ASoC: core: check of_property_count_strings failure
ASoC: dt: sgtl5000.txt: Add description for 'reg' field
ASoC: wm_hubs: Make sure we don't disable differential line outputs
Sasha Levin [Sat, 5 May 2012 15:06:35 +0000 (17:06 +0200)]
init: don't try mounting device as nfs root unless type fully matches
Currently, we'll try mounting any device who's major device number is
UNNAMED_MAJOR as NFS root. This would happen for non-NFS devices as
well (such as 9p devices) but it wouldn't cause any issues since
mounting the device as NFS would fail quickly and the code proceeded to
doing the proper mount:
[ 101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[ 101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries
when mounting NFS root, which means that now we don't immediately fail
and instead it takes an additional 90+ seconds until we stop retrying,
which has revealed the issue this patch fixes.
This meant that it would take an additional 90 seconds to boot when
we're not using a device type which gets detected in order before NFS.
This patch modifies the NFS type check to require device type to be
'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR
major. This makes boot process cleaner since we now won't go through
the NFS mounting code at all when the device isn't an NFS root
("/dev/nfs").
Lin Ming [Mon, 23 Apr 2012 01:03:49 +0000 (09:03 +0800)]
ACPI: Fix D3hot v D3cold confusion
Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot
in some places, but D3cold in other places.
After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD;
and all references to D3hot use ACPI_STATE_D3_HOT.
ACPI's _PR3 method is used to enter both D3hot and D3cold states.
What distinguishes D3hot from D3cold is the presence _PR3
(Power Resources for D3hot) If these resources are all ON,
then the state is D3hot. If _PR3 is not present,
or all _PR0 resources for the devices are OFF,
then the state is D3cold.
This patch applies after Linux-3.4-rc1.
A future syntax cleanup may remove ACPI_STATE_D3
to emphasize that it always means ACPI_STATE_D3_COLD.
Signed-off-by: Lin Ming <ming.m.lin@intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Reviewed-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Len Brown <len.brown@intel.com>
Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few
potential buffer overflows in the hfs filesystem. But as Timo Warns
pointed out, these changes also need to be made on the hfsplus
filesystem as well.
Reported-by: Timo Warns <warns@pre-sense.de> Acked-by: WANG Cong <amwang@redhat.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Sage Weil <sage@newdream.net> Cc: Eugene Teo <eteo@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Dave Anderson <anderson@redhat.com> Cc: stable <stable@vger.kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 4 May 2012 22:34:21 +0000 (15:34 -0700)]
Merge git://git.samba.org/sfrench/cifs-2.6
Pull CIFS fixes from Steve French.
* git://git.samba.org/sfrench/cifs-2.6:
fs/cifs: fix parsing of dfs referrals
cifs: make sure we ignore the credentials= and cred= options
[CIFS] Update cifs version to 1.78
cifs - check S_AUTOMOUNT in revalidate
cifs: add missing initialization of server->req_lock
cifs: don't cap ra_pages at the same level as default_backing_dev_info
CIFS: Fix indentation in cifs_show_options
Dave Jones [Fri, 4 May 2012 16:04:17 +0000 (12:04 -0400)]
CPU frequency drivers MAINTAINERS update
Remove myself as cpufreq maintainer.
x86 driver changes can go through the regular x86/ACPI trees.
ARM driver changes through the ARM trees.
cpufreq core changes are rare these days, and can just go to lkml/direct.
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 4 May 2012 22:13:54 +0000 (15:13 -0700)]
seqlock: add 'raw_seqcount_begin()' function
The normal read_seqcount_begin() function will wait for any current
writers to exit their critical region by looping until the sequence
count is even.
That "wait for sequence count to stabilize" is the right thing to do if
the read-locker will just retry the whole operation on contention: no
point in doing a potentially expensive reader sequence if we know at the
beginning that we'll just end up re-doing it all.
HOWEVER. Some users don't actually retry the operation, but instead
will abort and do the operation with proper locking. So the sequence
count case may be the optimistic quick case, but in the presense of
writers you may want to do full locking in order to guarantee forward
progress. The prime example of this would be the RCU name lookup.
And in that case, you may well be better off without the "retry early",
and are in a rush to instead get to the failure handling. Thus this
"raw" interface that just returns the sequence number without testing it
- it just forces the low bit to zero so that read_seqcount_retry() will
always fail such a "active concurrent writer" scenario.
Linus Torvalds [Fri, 4 May 2012 21:46:02 +0000 (14:46 -0700)]
Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read
We really need to use a ACCESS_ONCE() on the sequence value read in
__read_seqcount_begin(), because otherwise the compiler might end up
reloading the value in between the test and the return of it. As a
result, it might end up returning an odd value (which means that a write
is in progress).
If the reader is then fast enough that that odd value is still the
current one when the read_seqcount_retry() is done, we might end up with
a "successful" read sequence, even despite the concurrent write being
active.
In practice this probably never really happens - there just isn't
anything else going on around the read of the sequence count, and the
common case is that we end up having a read barrier immediately
afterwards.
So the code sequence in which gcc might decide to reaload from memory is
small, and there's no reason to believe it would ever actually do the
reload. But if the compiler ever were to decide to do so, it would be
incredibly annoying to debug. Let's just make sure.
Yong Wang [Fri, 4 May 2012 21:02:44 +0000 (14:02 -0700)]
intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
So that the power button still wakes up the platform.
Signed-off-by: Pierre Tardy <pierre.tardy@intel.com> Link: http://lkml.kernel.org/r/20120504210244.F2EA5A018B@akpm.mtv.corp.google.com Tested-by: Kangkai Yin <kangkai.yin@intel.com> Tested-by: Yong Wang <yong.y.wang@intel.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver
It seems that there was an error with the active_low = 1 for the
LED, since it should be set to 0 (meaning that active is high,
since 0 is false, hence the confusion.
The wiki article about it confuses it, since it contradicts itself,
regarding what turns on the LED.
I have tested 3.4-rc2 on my net5501 with this patch, and it makes the LED
behave correctly, where "none" turns it off, and "default-on" turns it on,
when echoed onto the trigger "file" in /sys/class/leds.
Signed-off-by: Bjarke Istrup Pedersen <gurligebis@gentoo.org> Link: http://lkml.kernel.org/r/20120504210146.62186A018B@akpm.mtv.corp.google.com Cc: Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Stefan Behrens [Fri, 4 May 2012 19:16:07 +0000 (15:16 -0400)]
Btrfs: fix crash in scrub repair code when device is missing
Fix that when scrub tries to repair an I/O or checksum error and one of
the devices containing the mirror is missing, it crashes in bio_add_page
because the bdev is a NULL pointer for missing devices.
Reported-by: Marco L. Crociani <marco.crociani@gmail.com> Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: Chris Mason <chris.mason@oracle.com>
Alexander Block [Fri, 4 May 2012 19:16:06 +0000 (15:16 -0400)]
btrfs: Fix mismatching struct members in ioctl.h
Fix the size members of btrfs_ioctl_ino_path_args and
btrfs_ioctl_logical_ino_args. The user space btrfs-progs utilities used
__u64 and the kernel headers used __u32 before.
Signed-off-by: Alexander Block <ablock84@googlemail.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
Josef Bacik [Fri, 4 May 2012 19:16:06 +0000 (15:16 -0400)]
Btrfs: fix page leak when allocing extent buffers
If we happen to alloc a extent buffer and then alloc a page and notice that
page is already attached to an extent buffer, we will only unlock it and
free our existing eb. Any pages currently attached to that eb will be
properly freed, but we don't do the page_cache_release() on the page where
we noticed the other extent buffer which can cause us to leak pages and I
hope cause the weird issues we've been seeing in this area. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
Linus Torvalds [Fri, 4 May 2012 14:57:13 +0000 (07:57 -0700)]
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Some minor fixes from Intel and a radeon fix.
I have the nouveau fix for the i2c regression queued for next week,
its mostly a revert and seems to work on the system it was originally
introduced for thanks to some i2c core changes."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: clarify and extend wb setup on APUs and NI+ asics
drm/i915: enable dip before writing data on gen4
fixing dmi match for hp t5745 and hp st5747 thin client
drm/i915: Only enable IPS polling for gen5
drm/i915: Do not read non-existent DPLL registers on PCH hardware
Linus Torvalds [Fri, 4 May 2012 14:50:50 +0000 (07:50 -0700)]
Merge branch 'fix-unmapped-word-at-a-time'
Jana Saout confirmed that this fixes the page faults he saw.
His problem was triggered by ocfs2 and autofs symlink lookups, where the
symlink allocation was at the end of a page. But the deeper reason
seems to be the use of Xen-PV, which is what then causes him to have all
these unmapped pages, which is what then makes it a problem when the
unaligned word-at-a-time code fetches data past the end of a page.
* fix-unmapped-word-at-a-time:
vfs: make word-at-a-time accesses handle a non-existing page
ASoC: omap-pcm: Free dma buffers in case of error.
Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@ti.com>
Daniel Vetter [Tue, 24 Apr 2012 16:27:57 +0000 (18:27 +0200)]
drm/i915: use mode values consistently when converting to sdvo dtd
The drm_mode->dtd conversion used the crtc timings, whereas the
dtd->drm_mod did not set these. Use the standard mode information, not
the crtc timings, in both cases to make these two functions proper
inverses of each another.
Note that this also kills the risk that we handle interlaced timings
inconsistently because the drm core uses half-frames for crtc timings,
whereas we need full frames. But interlaced support is pretty decently
broken anyway for sdvo encoders, so no big deal.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: fixup overlay checks for interlaced modes
the only places we actually need the crtc timings is in the mode_set
function.
I guess the idea of the drm core is that every time it creates a drm
mode, it also sets the timings. But afaics it never uses them, safe
for the precise vblank timestamp code (but that can only run on active
modes, i.e. after our mode_fixup functions have been called). The
problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the
timings are pretty much bogus for us anyway (at least with interlaced
support).
So I guess it's the drivers job that every active modes needs to have
crtc timings that suits it, and with these patches we should have
that. drm core doesn't seem to care about modes that just get passed
around. Hence we can now safely rip out all the remaining calls to
set_crtcinfo left in the driver and clean up this confusion.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Alex Deucher [Thu, 3 May 2012 21:06:28 +0000 (17:06 -0400)]
drm/radeon: clarify and extend wb setup on APUs and NI+ asics
Use family rather than DCE check for clarity, also always use
wb on APUs, there will never be AGP variants.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
NeilBrown [Fri, 4 May 2012 07:03:18 +0000 (17:03 +1000)]
md/bitmap: fix calculation of 'chunks' - missing shift.
commit 61a0d80c "md/bitmap: discard CHUNK_BLOCK_SHIFT macro"
replaced CHUNK_BLOCK_RATIO() by the same text that was
replacing CHUNK_BLOCK_SHIFT() - which is clearly wrong.
The result is that 'chunks' is often too small by 1,
which can sometimes result in a crash (not sure how).
So use the correct replacement, and get rid of CHUNK_BLOCK_RATIO
which is no longe used.
Reported-by: Karl Newman <siliconfiend@gmail.com> Tested-by: Karl Newman <siliconfiend@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
The problem was that the first referral was parsed more than once
and so the caller tried the same referrals multiple times.
The problem was introduced partly by commit 066ce6899484d9026acd6ba3a8dbbedb33d7ae1b,
where 'ref += le16_to_cpu(ref->Size);' got lost,
but that was also wrong...
Cc: <stable@vger.kernel.org> Signed-off-by: Stefan Metzmacher <metze@samba.org> Tested-by: Björn Jacke <bj@sernet.de> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
Matthew Garrett [Thu, 3 May 2012 20:50:46 +0000 (16:50 -0400)]
efivars: Improve variable validation
Ben Hutchings pointed out that the validation in efivars was inadequate -
most obviously, an entry with size 0 would server as a DoS against the
kernel. Improve this based on his suggestions.
Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 4 May 2012 00:16:52 +0000 (17:16 -0700)]
Merge tag 'tag/upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
Pull libata fixes from Jeff Garzik:
1) Fix regression that could cause a misdiagnosis, which in turn could
lead to an erroneous 3.0 Gbps -> 1.5 downshift, particularly when hotplug
and suspend/resume is involved.
2) Fix a regression that led to ata%d controller ids being numbered one
larger than in <= 3.4-rc3 (oh, the horror!). Controller ids should now be
as expected.
3) add some DT, PCI id's
4) ata/pata_arasan_cf: minor cpp fixing/cleaning
* tag 'tag/upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
ata: ahci_platform: Add synopsys ahci controller in DT's compatible list
ata/pata_arasan_cf: Move arasan_cf_pm_ops out of #ifdef, #endif macros
libata: init ata_print_id to 0
ahci: Detect Marvell 88SE9172 SATA controller
libata: skip old error history when counting probe trials
projects / linux-beck.git / log