13 Aug, 2008
22 commits
-
Specify how much physically continuous, DMA capable memory will be
allocated at driver initialization time. This allow to create framebuffer
device with larger virtual resolution. Combine with y-panning this can be
used to implement double buffering acceleration method.Signed-off-by: Stanislaw Gruszka
Acked-by: Haavard Skinnemoen
Acked-by: Krzysztof Helt
Cc: Nicolas Ferre
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Panning in the y-direction can be done by simply changing the DMA base
address. This code is already in place, but FBIOPAN_DISPLAY will
currently fail because ypanstep is 0.Set ypanstep to 1 to indicate that we do support y-panning and also set
the necessary acceleration flags on AT91 (AVR32 already have them.)Signed-off-by: Haavard Skinnemoen
Acked-by: Krzysztof Helt
Cc: Nicolas Ferre
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The legacy i2c model is going away soon, so switch to the new model.
Signed-off-by: Jean Delvare
Acked-by: Krzysztof Helt
Cc: Petr Vandrovec
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Clean up the use of structure templates in i2c-matroxfb. In this case
it's more efficient to initialize the few fields we need individually.
This makes i2c-matroxfb.ko 16% smaller on my system.Signed-off-by: Jean Delvare
Acked-by: Krzysztof Helt
Cc: Petr Vandrovec
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
I broke an error path with d03c21ec0be7787ff6b75dcf56c0e96209ccbfbd,
sorry about that.The machine will crash if the i2c_attach_client() or maven_init_client()
calls fail, although nobody has yet reported this happening.Signed-off-by: Jean Delvare
Acked-by: Krzysztof Helt
Cc: Petr Vandrovec
Cc: [2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: MinChan Kim
Acked-by: Christoph Lameter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix preprocessor symbol so that sparse sees it and does not generate
errors:drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
drivers/misc/sgi-gru/grutlbpurge.c:185:11: error: undefined identifier 'GRUREGION'
drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"
drivers/misc/sgi-gru/grutables.h:286:2: error: "Unsupported architecture"Signed-off-by: Randy Dunlap
Cc: Jack Steiner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Some chips appear to have the 2D engine hang during screen redraw,
typically in a sequence of copyarea operations. This appear to be
solved by adding a flush of the engine destination pixel cache
and waiting for the engine to be idle before issuing the accel
operation. The performance impact seems to be fairly small.Here is a trace on an RV370 (PCI device ID 0x5b64), it records the
RBBM_STATUS register, then the source x/y, destination x/y, and
width/height used for the copy:----------------------------------------
radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10]
radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10]
radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10]
radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10]
radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10]
radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10]
radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10]
radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10]
radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10]
radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10]
radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10]
----------------------------------------When things are going fine the copies complete before the next ROP is
even issued, but all of a sudden the 2D unit becomes active (bit 17 in
RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit
14) are set as well. The FIFO begins to backup until it becomes full.What happens next is the radeon_fifo_wait() times out, and we access
the chip illegally leading to a bus error which usually wedges the
box. None of this makes it to the console screen, of course :-)
radeon_fifo_wait() should be modified to reset the accelerator when
this timeout happens instead of programming the chip anyways.----------------------------------------
radeonfb: FIFO Timeout !
ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0)
ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601]
ERROR(0): TPC
ERROR(0): M_SYND(0), E_SYND(0), Privileged
ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus"
ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
ERROR(0): E-cache idx[800e40] tag[000000000e049f4c]
ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000]
Ker:xnel panic - not syncing: Irrecoverable deferred error trap.
----------------------------------------Another quirk is that these copyarea calls will not happen until the
first drivers/char/vt.c:redraw_screen() occurs. This will only happen
if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen.This seems to happen because until a redraw_screen() the screen scrolling
method used by fbcon is not finalized yet. I've seen this with other fb
drivers too.So if all you do is boot straight into X you will never see this bug on
the relevant chips.Signed-off-by: David S. Miller
Signed-off-by: Benjamin Herrenschmidt
Cc: [2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
[Andrew this should replace the previous version which did not check
the returns from the region prepare for errors. This has been tested by
us and Gerald and it looks good.Bah, while reviewing the locking based on your previous email I spotted
that we need to check the return from the vma_needs_reservation call for
allocation errors. Here is an updated patch to correct this. This passes
testing here.]Signed-off-by: Andy Whitcroft
Tested-by: Gerald Schaefer
Cc: Mel Gorman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
In the normal case, hugetlbfs reserves hugepages at map time so that the
pages exist for future faults. A struct file_region is used to track when
reservations have been consumed and where. These file_regions are
allocated as necessary with kmalloc() which can sleep with the
mm->page_table_lock held. This is wrong and triggers may-sleep warning
when PREEMPT is enabled.Updates to the underlying file_region are done in two phases. The first
phase prepares the region for the change, allocating any necessary memory,
without actually making the change. The second phase actually commits the
change. This patch makes use of this by checking the reservations before
the page_table_lock is taken; triggering any necessary allocations. This
may then be safely repeated within the locks without any allocations being
required.Credit to Mel Gorman for diagnosing this failure and initial versions of
the patch.Signed-off-by: Andy Whitcroft
Tested-by: Gerald Schaefer
Cc: Mel Gorman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Parag Warudkar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
These attributes are really sysdev class attributes. The incorrect
definition leads to an oops because of recent changes which make sysdev
attributes use a different prototype.Based on Andi's f718cd4add5aea9d379faff92f162571e356cc5f ("sched: make
scheduler sysfs attributes sysdev class devices")Reported-by: Eric Sesterhenn
Signed-off-by: Rabin Vincent
Acked-by: Andi Kleen
Cc: "Li, Shaohua"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Alessandro Zummo
Cc: Herbert Valerio Riedel
Cc: Hartley Sweeten
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
WARNING: vmlinux.o(.text+0x2fdf): Section mismatch in reference from the variable .LM3 to the variable .init.text:___alloc_bootmem
The function .LM3() references
the variable __init ___alloc_bootmem.
This is often because .LM3 lacks a __init
annotation or the annotation of ___alloc_bootmem is wrong.WARNING: vmlinux.o(.text+0x2ff5): Section mismatch in reference from the variable .LM4 to the variable .init.text:___alloc_bootmem
The function .LM4() references
the variable __init ___alloc_bootmem.
This is often because .LM4 lacks a __init
annotation or the annotation of ___alloc_bootmem is wrong.WARNING: vmlinux.o(.text+0x300b): Section mismatch in reference from the variable .LM5 to the variable .init.text:___alloc_bootmem
The function .LM5() references
the variable __init ___alloc_bootmem.
This is often because .LM5 lacks a __init
annotation or the annotation of ___alloc_bootmem is wrong.WARNING: vmlinux.o(.text+0x304b): Section mismatch in reference from the variable .LM10 to the variable .init.text:_free_area_init
The function .LM10() references
the variable __init _free_area_init.
This is often because .LM10 lacks a __init
annotation or the annotation of _free_area_init is wrong.WARNING: vmlinux.o(.text+0x30a3): Section mismatch in reference from the variable .LM17 to the variable .init.text:_free_all_bootmem
The function .LM17() references
the variable __init _free_all_bootmem.
This is often because .LM17 lacks a __init
annotation or the annotation of _free_all_bootmem is wrong.Signed-off-by: Yoshinori Sato
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Revert commit 51a776fa7a7997e726d4a478eda0854c6f9143bd ("rtc: cdev
lock_kernel() pushdown"). The RTC framework does not need BKL
protection.Signed-off-by: David Brownell
Cc: Jonathan Corbet
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Got an oops in mem_cgroup_shrink_usage() when testing loop over tmpfs:
yes, of course, loop0 has no mm: other entry points check but this didn't.Signed-off-by: Hugh Dickins
Cc: KAMEZAWA Hiroyuki
Acked-by: Balbir Singh
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
s390 doesn't support the additional_cpus kernel parameter anymore since a
long time. So we better update the code and documentation to reflect
that.Cc: Martin Schwidefsky
Signed-off-by: Heiko Carstens
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
.. since a failed allocation is being (initially) handled gracefully, and
panic()-ed upon failure explicitly in the function if retries with smaller
sizes failed.Signed-off-by: Jan Beulich
Signed-off-by: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Jan Kara
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The s390 software large page emulation implements shared page tables by
using page->index of the first tail page from a compound large page to
store page table information. This is set up in arch_prepare_hugepage(),
which is called from alloc_fresh_huge_page_node().A similar call to arch_prepare_hugepage() is missing for surplus large
pages that are allocated in alloc_buddy_huge_page(), which breaks the
software emulation mode for (surplus) large pages on s390. This patch
adds the missing call to arch_prepare_hugepage(). It will have no effect
on other architectures where arch_prepare_hugepage() is a nop.Also, use the correct order in the error path in alloc_fresh_huge_page_node().
Acked-by: Martin Schwidefsky
Signed-off-by: Gerald Schaefer
Acked-by: Nick Piggin
Acked-by: Adam Litke
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Now that the driver is removed we should also remove the entry in
Documentation/feature-removal-schedule.txtSigned-off-by: Adrian Bunk
Acked-by: Christoph Hellwig
Cc: James Bottomley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: hda - support new AMD HDMI Audio (1002:970f)
ALSA: hda_intel: ALSA HD Audio patch for Intel Ibex Peak DeviceIDs
ALSA: wm8750: add missing VREF output
ALSA: spitz: MONO -> MONO1
ALSA: wm8750: it's MONO1, not MONO
12 Aug, 2008
18 commits
-
…el/git/tip/linux-2.6-tip
* 'core-fixes-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
generic-ipi: fix stack and rcu interaction bug in smp_call_function_mask(), fix -
* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
fix spinlock recursion in hvc_console
stop_machine: remove unused variable
modules: extend initcall_debug functionality to the module loader
export virtio_rng.h
lguest: use get_user_pages_fast() instead of get_user_pages()
mm: Make generic weak get_user_pages_fast and EXPORT_GPL it
lguest: don't set MAC address for guest unless specified -
* 'agp-patches' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6:
agp: fix SIS 5591/5592 wrong PCI id
intel/agp: rewrite GTT on resume
agp: use dev_printk when possible
amd64-agp: run fallback when no bridges found, not when driver registration fails
intel_agp: official name for GM45 chipset -
Signed-off-by: Libin Yang
Signed-off-by: Takashi Iwai -
This patch adds the Intel Ibex Peak (PCH) HD Audio Controller DeviceIDs.
Signed-off by: Seth Heasley
Signed-off-by: Takashi Iwai -
Add missing output VREF. After a65f0568f6cc8433877fb71dd7d36b551854b0bc
it's critical, since it makes chip routing initialisation to fail.Signed-off-by: Dmitry Baryshkov
Acked-by: Mark Brown
Signed-off-by: Takashi Iwai -
Correct route name to be MONO1 instead of MONO to follow
recent fix in wm8750.Signed-off-by: Dmitry Baryshkov
Acked-by: Mark Brown
Signed-off-by: Takashi Iwai -
> > Nick Piggin (1):
> > generic-ipi: fix stack and rcu interaction bug in
> > smp_call_function_mask()
>
> I'm still not 100% sure that I have this patch right... I might have seen
> a lockup trace implicating the smp call function path... which may have
> been due to some other problem or a different bug in the new call function
> code, but if some more people can take a look at it before merging?OK indeed it did have a couple of bugs. Firstly, I wasn't freeing the
data properly in the alloc && wait case. Secondly, I wasn't resetting
CSD_FLAG_WAIT in the for each cpu loop (so only the first CPU would
wait).After those fixes, the patch boots and runs with the kmalloc commented
out (so it always executes the slowpath).Signed-off-by: Ingo Molnar
-
commit 611e097d7707741a336a0677d9d69bec40f29f3d
Author: Christian Borntraeger
hvc_console: rework setup to replace irq functions with callbacks
introduced a spinlock recursion problem.request_irq tries to call the handler if the IRQ is shared.
The irq handler of hvc_console calls hvc_poll and hvc_kill
which might take the hvc_struct spinlock. Therefore, we have
to call request_irq outside the spinlock.We can move the notifier_add safely outside the spinlock as ->data must
not be changed by the backend. Otherwise, tty_hangup would fail anyway.Signed-off-by: Christian Borntraeger
Signed-off-by: Rusty Russell -
Signed-off-by: Li Zefan
Signed-off-by: Rusty Russell -
The kernel has this really nice facility where if you put "initcall_debug"
on the kernel commandline, it'll print which function it's going to
execute just before calling an initcall, and then after the call completes
it will1) print if it had an error code
2) checks for a few simple bugs (like leaving irqs off)
and3) print how long the init call took in milliseconds.
While trying to optimize the boot speed of my laptop, I have been loving
number 3 to figure out what to optimize... ... and then I wished that
the same thing was done for module loading.This patch makes the module loader use this exact same functionality; it's
a logical extension in my view (since modules are just sort of late
binding initcalls anyway) and so far I've found it quite useful in finding
where things are too slow in my boot.Signed-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Rusty Russell -
Hello Rusty,
The entropy device was added after we exported all virtio headers. This
patch adds virtio_rng.h to the exportable userspace headers.Signed-off-by: Christian Borntraeger
Signed-off-by: Rusty Russell -
Using a simple page table thrashing program I measure a slight
improvement. The program creates five processes. Each touches 1000
pages then schedules the next process. We repeat this 1000 times. As
lguest only caches 4 cr3 values, this rebuilds a lot of shadow page
tables requiring virt->phys mappings.Before: 5.93 seconds
After: 5.40 seconds(Counts of slow vs fastpath in this usage are 6092 and 2852462 respectively.)
And more importantly for lguest, the code is simpler.
Signed-off-by: Rusty Russell
-
Out of line get_user_pages_fast fallback implementation, make it a weak
symbol, get rid of CONFIG_HAVE_GET_USER_PAGES_FAST.Export the symbol to modules so lguest can use it.
Signed-off-by: Nick Piggin
Signed-off-by: Rusty Russell -
This shows up when trying to bridge:
tap0: received packet with own address as source addressAs Max Krasnyansky points out, there's no reason to give the guest the
same mac address as the TUN device.Signed-off-by: Rusty Russell
Cc: Max Krasnyansky -
The correct id is the id of the main host (5591) not
the id of the PCI-to-PCI bridge AGP (0001).
Output from "lspci -nv" shows that only the former
has AGP capabilities flag set:00:00.0 0600: 1039:5591 (rev 02)
Flags: bus master, medium devsel, latency 64
Memory at ec000000 (32-bit, non-prefetchable) [size=32M]
Capabilities: [c0] AGP version 1.000:02.0 0604: 1039:0001 (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: eb500000-eb5fffff
Prefetchable memory behind bridge: eb300000-eb3fffffSigned-off-by: Krzysztof Helt
Signed-off-by: Dave Airlie -
On my Intel chipset (965GM), the GTT is entirely erased across
suspend/resume. This patch simply re-plays the current mapping at resume
time to restore the table.=20I noticed this once I started relying on persistent GTT mappings across VT
switch in our GEM work -- the old X server and DRM code carefully unbind
all memory from the GTT on VT switch, but GEM does not bother.I placed the list management and rewrite code in the generic layer on the
assumption that it will be needed on other hardware, but I did not add the
rewrite call to anything other than the Intel resume function.Keep a list of current GATT mappings. At resume time, rewrite them into
the GATT. This is needed on Intel (at least) as the entire GATT is
cleared across suspend/resume.[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Keith Packard
Cc: Dave Jones
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Dave Airlie -
Convert printks to use dev_printk().
Signed-off-by: Bjorn Helgaas
Signed-off-by: Andrew Morton
Signed-off-by: Dave Airlie
