When CONFIG_PM is set but CONFIG_PM_SLEEP is unset,
SIMPLE_DEV_PM_OPS() ignores the given functions, and this leads to
compile warnings.
For avoiding this, simply check CONFIG_PM_SLEEP instead of CONFIG_PM.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The implicit presence of module.h lured several users into
incorrectly thinking that they only needed/used modparam.h
but once we clean up the module.h presence, these will show
up as build failures, so fix 'em now.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Currently, if the high-res timers are unavailable, snd-pcsp does not
initialize. People who choose it over pcspkr, loose their console beeps
in that case and get annoyed.
With this patch, the console beeps remain regardless of the high-res
timers. Additionally, the "nopcm" modparam is added to forcibly
disable the PCM capabilities of the driver.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
hrtimers: fix warning in kernel/hrtimer.c
x86: make sure we really have an hpet mapping before using it
x86: enable HPET on Fujitsu u9200
linux/timex.h: cleanup for userspace
posix-timers: simplify de_thread()->exit_itimers() path
posix-timers: check ->it_signal instead of ->it_pid to validate the timer
posix-timers: use "struct pid*" instead of "struct task_struct*"
nohz: suppress needless timer reprogramming
clocksource, acpi_pm.c: put acpi_pm_read_slow() under CONFIG_PCI
nohz: no softirq pending warnings for offline cpus
hrtimer: removing all ur callback modes, fix
hrtimer: removing all ur callback modes, fix hotplug
hrtimer: removing all ur callback modes
x86: correct link to HPET timer specification
rtc-cmos: export second NVRAM bank
Fixed up conflicts in sound/drivers/pcsp/pcsp.c and sound/core/hrtimer.c
manually.
Impact: cleanup, move all hrtimer processing into hardirq context
This is an attempt at removing some of the hrtimer complexity by
reducing the number of callback modes to 1.
This means that all hrtimer callback functions will be ran from HARD-irq
context.
I went through all the 30 odd hrtimer callback functions in the kernel
and saw only one that I'm not quite sure of, which is the one in
net/can/bcm.c - hence I'm CC-ing the folks responsible for that code.
Furthermore, the hrtimer core now calls callbacks directly with IRQs
disabled in case you try to enqueue an expired timer. If this timer is a
periodic timer (which should use hrtimer_forward() to advance its time)
then it might be possible to end up in an inf. recursive loop due to the
fact that hrtimer_forward() doesn't round up to the next timer
granularity, and therefore keeps on calling the callback - obviously
this needs a fix.
Aside from that, this seems to compile and actually boot on my dual core
test box - although I'm sure there are some bugs in, me not hitting any
makes me certain :-)
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
snd-pcsp driver takes chip->substream_lock together with PCM substream
lock. These are even mixed up with hrtimer's lock, resulting in messy
lock depencies. Right now, snd-pcsp driver resolves the deadlock by
using HRTIMER_CB_SOFTIRQ. However, this isn't nice for a really fast
path like bit-flipping.
This patch introduces a tasklet for PCM period handling so that the
hrtimer callback can be handled fast. This also reduce the use of
chip->substream_lock to avoid deadlocks. It's still used in pointer
callback, but even this could be removed with a proper barrier.
Another good solution is to introduce async trigger callback. But,
this will involve with a major rewrite of the PCM core code, so I
take first this easy fix.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Change HRTIMER_CB_IRQSAFE to HRTIMER_CB_SOFTIRQ,
as suggested by Thomas Gleixner.
That solves the lock dependancy reported in
Bug #10701.
That also allows to call hrtimer_start()
directly, tasklet "stupid hack" removed.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/drivers/pcsp/pcsp.c: In function 'pcsp_suspend':
sound/drivers/pcsp/pcsp.c:201: error: implicit declaration of function 'snd_pcm_suspend_all'
Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net>
CC: Stas Sergeev <stsp@aknet.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/drivers/pcsp/pcsp.c: In function 'snd_pcsp_create':
sound/drivers/pcsp/pcsp.c:54: error: 'loops_per_jiffy' undeclared (first use in\ this function)
sound/drivers/pcsp/pcsp.c:54: error: (Each undeclared identifier is reported on\ ly once
sound/drivers/pcsp/pcsp.c:54: error: for each function it appears in.)
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- make pcsp_start_timer_tasklet static
- remove redundant includes. <asm/i8253.h> is not available on all platforms.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
