HDA Codec driver,HDA Intel driver
Merged the work of pshou <pshou@realtek.com.tw> for the support of
more models with ALC codecs: ALC880 ASUS, Uniwill, FSC1734, generic 6-stack,
and ALC260 HP. Tests with the real hardwares are appreciated.
The codec patch is cleaned up: The preset configuration of codecs are
stored in the table and copied to the spec instance.
Added/fixed comments.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HDA Codec driver
Allow sub_device=0 in board config check. This means that every device
with the given sub vendor ID will match.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HDA Codec driver
Clean up and fix ALC-codec support code.
The last addition of bound volume is fixed now to handle correctly
the bound 'mute switches'. The analog loopback should work better.
The init verbs are fixed together with this change.
The numbers are replaced with macros for better readability.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HDA Codec driver
Feed front signals to all surround channels if no data is given
for surround channels.
It seems that CLFE works as expected (only center outputs) even if
connected from the front line - at least on my test system.
If this change causes problems on other system (e.g. only the left
channel is transferred to the center channel), please let me know...
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HDA Codec driver
Fixed the handling of amp cache in hda-codec driver.
The confliction of cache values with different indices should be fixed now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CS4236+ driver
Background: The card/chipset supports an external MIDI interrupt. By
default, this interrupt isn't used (because the isapnp mechanism chooses a
configuration without an assigned interrupt). If the user wishes to
explicitly select an interrupt via the mpu_irq parameter for such a
configured device, it doesn't work: The driver always shows:
isapnp MPU: port=0x330, irq=-1
(note the 'irq=-1')
Problem: The driver only allows to set the irq if pnp_irq_valid returns
true for this particular pnp device. This, however, is only true if an
interrupt has already been assigned (pnp_valid_irq returns true if the flag
IORESOURCE_IRQ is set and IORESOURCE_UNSET is not set). If no interrupt
has been assigned so far, IORESOURCE_UNSET is set and pnp_irq_valid returns
false, thereby inhibiting the selection of a valid irq.
Solution: Don't check for a valid (= already assigned) irq at the point of
calling pnp_resource_change.
Tested successfully on Linux 2.6.11.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
ALSA<-OSS emulation
The problem was negative/wrong result (info.bytes) in a specific condition at
playback startup.
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
ALSA<-OSS emulation
The problem was negative result (info.bytes) in a specific condition at
playback startup.
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
Documentation,Memalloc module,RME HDSP driver,RME9652 driver
Add the write support to snd-page-alloc proc file for buffer pre-allocation.
Removed the pre-allocation codes via module options.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Timer Midlevel,ALSA sequencer,ALSA<-OSS sequencer,Digigram VX core
I2C tea6330t,GUS Library,VIA82xx driver,VIA82xx-modem driver
CA0106 driver,CS46xx driver,EMU10K1/EMU10K2 driver,YMFPCI driver
Digigram VX Pocket driver,Common EMU synth,USB generic driver,USB USX2Y
Checking a pointer for NULL before calling kfree() on it is redundant,
kfree() deals with NULL pointers just fine.
This patch removes such checks from sound/
This patch also makes another, but closely related, change.
It avoids casting pointers about to be kfree()'ed.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Intel8x0 driver
To avoid confusion, the structure members vendor/device were renamed
to subvendor/subdevice, because we compare them with PCI subsystem vendor
and subsystem device.
Signed-off-by: James Courtier-Dutton <James@superbug.co.uk>
AC97 Codec,ATIIXP driver,VIA82xx driver
To avoid confusion, the structure members vendor/device were renamed
to subvendor/subdevice, because we compare them with PCI subsystem vendor
and subsystem device.
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
ALI5451 driver
This patch adds modem support for ali5451. Since it is same pci device
all is done in ali5451.c.
Signed-off-by: Sasha Khapyorsky <sashak@smlink.com>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
CA0106 driver
Use the DMA_32BIT_MASK constant from dma-mapping.h
when calling pci_set_dma_mask() or pci_set_consistent_dma_mask()
See http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for details
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
AC97 Codec
Simple MC97 modem mixer with two common controls: Off-hook and CID,
and Si3056 MC specific control: Modem Speaker.
Signed-off-by: Sasha Khapyorsky <sashak@smlink.com>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
This patch removes some unneeded checks of pointers being NULL before
calling kfree() on them. kfree() handles NULL pointers just fine, checking
first is pointless.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Due to the use of write-behind, it is possible for md to write a page to
the bitmap file that is still completing writeback. This is not allowed.
With this patch, we detect those cases and either force a sync write, or
back off and try later, as appropriate.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
1/ Must typecast int to (sector_t) before inverting or we
might not invert enough bits.
2/ When "bitmap_offset" was added to mdp_superblock_1, we didn't increase
the count of words-used (96 to 100).
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
currently, md updates all superblocks (one on each device) in series. It
waits for one write to complete before starting the next. This isn't a big
problem as superblock updates don't happen that often.
However it is neater to do it in parallel, and if the drives in the array have
gone to "sleep" after a period of idleness, then waking them is parallel is
faster (and someone else should be worrying about power drain).
Futher, we will need parallel superblock updates for a future patch which
keeps the intent-logging bitmap near the superblock.
Also remove the silly code that retired superblock updates 100 times. This
simply never made sense.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This provides an alternate to storing the bitmap in a separate file. The
bitmap can be stored at a given offset from the superblock. Obviously the
creator of the array must make sure this doesn't intersect with data....
After is good for version-0.90 superblocks.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Before completing a 'write' the md superblock might need to be updated.
This is best done by the md_thread.
The current code schedules this up and queues the write request for later
handling by the md_thread.
However some personalities (Raid5/raid6) will deadlock if the md_thread
tries to submit requests to its own array.
So this patch changes things so the processes submitting the request waits
for the superblock to be written and then submits the request itself.
This fixes a recently-created deadlock in raid5/raid6
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When an array is degraded, bit in the intent-bitmap are never cleared. So if
a recently failed drive is re-added, we only need to reconstruct the block
that are still reflected in the bitmap.
This patch adds support for this re-adding.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Otherwise it could have a random value and might BUG. This fixes a BUG
during resync problem in raid1 introduced by the bitmap-based-intent-loggin
patches.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The logic here is wrong. if fullsync is 0, it WILL BUG.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When looking for pages that need cleaning we skip pages that don't have
BITMAP_PAGE_CLEAN set. But if it is the 'current' page we will have cleared
that bit ourselves, so skipping it is wrong. So: move the 'skip this page'
inside 'if page != lastpage'.
Also fold call of file_page_offset into the one place where the value (bit) is
used.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently we don't wait for updates to the bitmap to be flushed to disk
properly. The infrastructure all there, but it isn't being used....
A separate kernel thread (bitmap_writeback_daemon) is needed to wait for each
page as we cannot get callbacks when a page write completes.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- report sync_size properly - need /2 to convert sectors to KB
- move everything over 2 spaces to allow proper spelling of
"events cleared".
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A u64 is not an unsigned long long. On power4 it is `long', and printk warns.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
As the array-wide clean bit (in the superblock) is set more agressively than
the bits in the bitmap are cleared, it is possible to have an array which is
clean despite there being bits set in the bitmap.
These bits will currently never get cleared, as they can only be cleared by a
resync pass, which never happens.
No, when reading bits from disk, be aware of whether the whole array is known
to be in sync, and act accordingly.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
