- 05 Oct, 2008 10 commits
-
-
Dean Anderson authored
Fixes videobuf field_count Signed-off-by: Dean Anderson <dean@sensoray.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean Delvare authored
The zr36067 driver is improperly declaring pixel format RGBP twice, once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is actually RGBR. Fix the code to properly map both pixel formats. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andrew Morton authored
sparc32 allmodconfig: drivers/media/video/cafe_ccic.c: In function 'cafe_setup_siobuf': drivers/media/video/cafe_ccic.c:1192: error: implicit declaration of function 'PAGE_ALIGN' drivers/media/video/cafe_ccic.c: At top level: drivers/media/video/cafe_ccic.c:1430: error: variable 'cafe_v4l_vm_ops' has initializer but incomplete type drivers/media/video/cafe_ccic.c:1431: error: unknown field 'open' specified in initializer drivers/media/video/cafe_ccic.c:1431: warning: excess elements in struct initializer drivers/media/video/cafe_ccic.c:1431: warning: (near initialization for 'cafe_v4l_vm_ops') drivers/media/video/cafe_ccic.c:1432: error: unknown field 'close' specified in initializer drivers/media/video/cafe_ccic.c:1433: warning: excess elements in struct initializer drivers/media/video/cafe_ccic.c:1433: warning: (near initialization for 'cafe_v4l_vm_ops') drivers/media/video/cafe_ccic.c: In function 'cafe_v4l_mmap': drivers/media/video/cafe_ccic.c:1444: error: 'VM_WRITE' undeclared (first use in this function) drivers/media/video/cafe_ccic.c:1444: error: (Each undeclared identifier is reported only once drivers/media/video/cafe_ccic.c:1444: error: for each function it appears in.) drivers/media/video/cafe_ccic.c:1444: error: 'VM_SHARED' undeclared (first use in this function) drivers/media/video/cafe_ccic.c:1461: error: 'VM_DONTEXPAND' undeclared (first use in this function) This build breakage is caused by some header file shuffle in linux-next. But I suggest that this patch be merged ahead of linux-next to avoid bisection breakage. Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean Delvare authored
The zr36067 driver should return the actual bytes-per-line value when queried with ioctl VIDIOC_G_FMT, instead of 0. Otherwise user-space applications can get confused. Likewise, with ioctl VIDIOC_S_FMT, we are supposed to fill the bytes-per-line value. And we shouldn't fail if the caller sets the initial value to something different from 0. This is perfectly valid for applications to pre-fill this field with the value they expect. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean Delvare authored
Restore the default pixel format to YUYV as it used to be before kernel 2.6.23. It was accidentally changed to BGR3 by commit 603d6f2c. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean Delvare authored
Fix the following crash in the bttv driver: BUG: unable to handle kernel NULL pointer dereference at 000000000000036c IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv] This happens because radio_open assumes that all present bttv devices have a radio function. If a bttv device without radio and one with radio are installed on the same system, and the one without radio is registered first, then radio_open checks for the radio device number of a bttv device that has no radio function, and this breaks. All we have to do to fix it is to skip bttv devices without a radio function. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Douglas Schilling Landgraf authored
Removed duplicated entry for EM2800_BOARD_KWORLD_USB2800 Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Costantino Leandro authored
CS2102K stop streaming on setlightfreq (50Hz & 60Hz). Disable it for now until a correct solution is found. Signed-off-by: Costantino Leandro <le_costantino@pixartargentina.com.ar> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Earlier fixes to get the tuner audio working correctly broke the audio on the Compro VideoMate H900 cards. This is now fixed. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 29 Sep, 2008 9 commits
-
-
Hans de Goede authored
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Exposure was always 0. Thanks to sparse for finding this. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
sparse found an unbalanced BKL usage. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mike Isely authored
The device 2040:2950 is a really old variant of the PVR USB2 hardware. I have just learned of its existence. For the purposes of the pvrusb2 driver, it is functionally identical to the well known 29xxx series (2040:2900). Amazing that this went undetected for 3+ years. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Douglas Schilling Landgraf authored
Free allocated memory Cc: Jean-Francois Moine <moinejf@free.fr> Cc: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Douglas Schilling Landgraf authored
Free allocated memory Cc: Luca Risolia <luca.risolia@studio.unibo.it> Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Douglas Schilling Landgraf authored
Free allocated memory Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Douglas Schilling Landgraf authored
Free allocated memory Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Douglas Schilling Landgraf authored
Fixed order of usb_alloc_urb pointer validation. Cc: Luca Risolia <luca.risolia@studio.unibo.it> Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 11 Sep, 2008 2 commits
-
-
Hans Verkuil authored
i2c_client is allocated for us, we should never free it ourselves. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
-
- 07 Sep, 2008 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: i8042 - make Lenovo 3000 N100 blacklist entry more specific Input: bcm5974 - add BTN_TOUCH event for mousedev benefit Input: bcm5974 - improve finger tracking and counting Input: bcm5974 - small formatting cleanup Input: bcm5974 - add maintainer entry
-
Linus Torvalds authored
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: cpu_init(): fix memory leak when using CPU hotplug x86: pda_init(): fix memory leak when using CPU hotplug x86, xen: Use native_pte_flags instead of native_pte_val for .pte_flags x86: move mtrr cpu cap setting early in early_init_xxxx x86: delay early cpu initialization until cpuid is done x86: use X86_FEATURE_NOPL in alternatives x86: add NOPL as a synthetic CPU feature bit x86: boot: stub out unimplemented CPU feature words
-
Linus Torvalds authored
Merge branch 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: clocksource, acpi_pm.c: check for monotonicity clocksource, acpi_pm.c: use proper read function also in errata mode ntp: fix calculation of the next jiffie to trigger RTC sync x86: HPET: read back compare register before reading counter x86: HPET fix moronic 32/64bit thinko clockevents: broadcast fixup possible waiters HPET: make minimum reprogramming delta useful clockevents: prevent endless loop lockup clockevents: prevent multiple init/shutdown clockevents: enforce reprogram in oneshot setup clockevents: prevent endless loop in periodic broadcast handler clockevents: prevent clockevent event_handler ending up handler_noop
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6: Fix CONFIG_AC97_BUS dependency
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] Probe initrd header only if explicitly specified [MIPS] TX39xx: Add missing local_flush_icache_range initialization [MIPS] TXx9: Fix txx9_pcode initialization [MIPS] Fix WARNING: at kernel/smp.c:290 [MIPS] Fix data bus error recovery
-
- 06 Sep, 2008 12 commits
-
-
Andreas Herrmann authored
Exception stacks are allocated each time a CPU is set online. But the allocated space is never freed. Thus with one CPU hotplug offline/online cycle there is a memory leak of 24K (6 pages) for a CPU. Fix is to allocate exception stacks only once -- when the CPU is set online for the first time. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: akpm@linux-foundation.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Andreas Herrmann authored
pda->irqstackptr is allocated whenever a CPU is set online. But it is never freed. This results in a memory leak of 16K for each CPU offline/online cycle. Fix is to allocate pda->irqstackptr only once. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: akpm@linux-foundation.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Eduardo Habkost authored
Using native_pte_val triggers the BUG_ON() in the paravirt_ops version of pte_flags(). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
Krzysztof Helt found MTRR is not detected on k6-2 root cause: we moved mtrr_bp_init() early for mtrr trimming, and in early_detect we only read the CPU capability from cpuid, so some cpu doesn't have that bit in cpuid. So we need to add early_init_xxxx to preset those bit before mtrr_bp_init for those earlier cpus. this patch is for v2.6.27 Reported-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Krzysztof Helt authored
Move early cpu initialization after cpu early get cap so the early cpu initialization can fix up cpu caps. Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Dominik Brodowski authored
The current check for monotonicity is way too weak: Andreas Mohr reports ( http://lkml.org/lkml/2008/8/10/77 ) that on one of his test systems the current check only triggers in 50% of all cases, leading to catastrophic timer behaviour. To fix this issue, expand the check for monotonicity by doing ten consecutive tests instead of one. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Dominik Brodowski authored
On all hardware (some Intel ICH4, PIIX4 and PIIX4E chipsets) affected by a hardware errata there's about a 4.2% chance that initialization of the ACPI PMTMR fails. On those chipsets, we need to read out the timer value at least three times to get a correct result, for every once in a while (i.e. within a 3 ns window every 69.8 ns) the read returns a bogus result. During normal operation we work around this issue, but during initialization reading a bogus value may lead to -EINVAL even though the hardware is usable. Thanks to Andreas Mohr for spotting this issue. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Maciej W. Rozycki authored
We have a bug in the calculation of the next jiffie to trigger the RTC synchronisation. The aim here is to run sync_cmos_clock() as close as possible to the middle of a second. Which means we want this function to be called less than or equal to half a jiffie away from when now.tv_nsec equals 5e8 (500000000). If this is not the case for a given call to the function, for this purpose instead of updating the RTC we calculate the offset in nanoseconds to the next point in time where now.tv_nsec will be equal 5e8. The calculated offset is then converted to jiffies as these are the unit used by the timer. Hovewer timespec_to_jiffies() used here uses a ceil()-type rounding mode, where the resulting value is rounded up. As a result the range of now.tv_nsec when the timer will trigger is from 5e8 to 5e8 + TICK_NSEC rather than the desired 5e8 - TICK_NSEC / 2 to 5e8 + TICK_NSEC / 2. As a result if for example sync_cmos_clock() happens to be called at the time when now.tv_nsec is between 5e8 + TICK_NSEC / 2 and 5e8 to 5e8 + TICK_NSEC, it will simply be rescheduled HZ jiffies later, falling in the same range of now.tv_nsec again. Similarly for cases offsetted by an integer multiple of TICK_NSEC. This change addresses the problem by subtracting TICK_NSEC / 2 from the nanosecond offset to the next point in time where now.tv_nsec will be equal 5e8, effectively shifting the following rounding in timespec_to_jiffies() so that it produces a rounded-to-nearest result. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Takashi Iwai authored
CONFIG_AC97_BUS is used from both sound and ucb1400 drivers. The recent change in Kconfig introduced the exclusive dependency on CONFIG_SOUND, and disabled the ucb1400 build without sound. This patch makes CONFIG_AC97_BUS independent. Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Randy Dunlap <randy.dunlap@oracle.com>
-
Thomas Gleixner authored
After fixing the u32 thinko I sill had occasional hickups on ATI chipsets with small deltas. There seems to be a delay between writing the compare register and the transffer to the internal register which triggers the interrupt. Reading back the value makes sure, that it hit the internal match register befor we compare against the counter value. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
We use the HPET only in 32bit mode because: 1) some HPETs are 32bit only 2) on i386 there is no way to read/write the HPET atomic 64bit wide The HPET code unification done by the "moron of the year" did not take into account that unsigned long is different on 32 and 64 bit. This thinko results in a possible endless loop in the clockevents code, when the return comparison fails due to the 64bit/332bit unawareness. unsigned long cnt = (u32) hpet_read() + delta can wrap over 32bit. but the final compare will fail and return -ETIME causing endless loops. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
Until the C1E patches arrived there where no users of periodic broadcast before switching to oneshot mode. Now we need to trigger a possible waiter for a periodic broadcast when switching to oneshot mode. Otherwise we can starve them for ever. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
- 05 Sep, 2008 2 commits
-
-
H. Peter Anvin authored
Use X86_FEATURE_NOPL to determine if it is safe to use P6 NOPs in alternatives. Also, replace table and loop with simple if statement. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
The long noops ("NOPL") are supposed to be detected by family >= 6. Unfortunately, several non-Intel x86 implementations, both hardware and software, don't obey this dictum. Instead, probe for NOPL directly by executing a NOPL instruction and see if we get #UD. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
-