Detailed HDA changes v1.0.17rc1 v1.0.17rc2

Detailed HDA changelog between 1.0.17rc1 and 1.0.17rc2 releases

alsa-driver

HDA Codec driver

- ALSA: hda: Add support for 92HD73xxx codecs

Added support for new family of IDT codecs.

- ALSA: hda - Remove unused mutex

Removed unused mutex from patch_*.c.

- ALSA: hda - Fix stac9205_cfg_tbl

Sort stac9205_cfg_table in the order of id numbers, and removed the

duplicated (obsoleted) entries for 0x01fc and 0x01fd. This doesn't

change the driver behavior since the old entries are all secondary.

The duplication occured due to commit dfe495d0, and the old entries

were introduced by commit ae0a8ed8.

- [ALSA] hda - Add Toshiba dynabook SS RX1 support

I have Toshiba dynabook SS RX1 and this patch adds that support.

- [ALSA] hda - Fix "alc262_sony_unsol[]" hda_verb array

I think that hda_verb array must have "terminator (empty array)".

But alc262_sony_unsol[] does not have it.

And it causes gcc-4.3's buggy behavior

with snd_hda_sequence_write().

- [ALSA] hda - Fix resume of auto-config mode with Realtek codecs

The auto-config mode of Realtek ALC codecs has a bug since 2.6.25

that it cannot resume properly. The problem was the wrong assignment

of init_hook that overrides the whole initialization.

Relevant bug reports:

http://bugzilla.kernel.org/show_bug.cgi?id=10662

https://bugzilla.novell.com/show_bug.cgi?id=385473

- [ALSA] hda - COMPAL IFL90/JFL-92 laptop quirk

Use quirk table to assign ALC268_TOSHIBA to COMPAL IFL90/JFL-92 laptops.

No analog output on autoprobe.

Tested-by: Guri <gurashka@gmail.com>

- [ALSA] hda - Fix PLL gating control on Realtek codecs

On some Realtek codecs, the analog PLL gating control bit must be set

off while the default value is 1.

- [ALSA] hda - support intel DG33 motherboards

These two motherboards's pin configuration are not covered by driver.

I wrote a new model to support them.

HDA Intel driver

- ALSA: hda - use upper_32_bits()

Use the standard upper_32_bits() instead of own macro.

- ALSA: hda - bdl_pos_adj=32 as default

Use bdl_pos_adj=32 as default except for Intel hardwares confirmed

to work with bdl_pos_adj=1. Looks like ATI and NVidia require this

higher value.

- ALSA: hda - Add a warning if pending IRQ is found

The pending IRQ handling is a very hackish workaround and should be

avoided as much as possible via a larger bdl_pos_adj option value.

Put a warning message if this situation occurs so that the user may have

a chance to notice that something is wrong.

- ALSA: hda - Fix bdl_pos_adj value for ATI SB chipsets

ATI SB controllers seem to report the DMA ahead in the amount of FIFO.

Thus bdl_pos_adj should be 32 for them as default.

Also, the default value is set to -1, which means to make the driver

to choose the appropriate value.

- ALSA: hda - bdl_pos_adj option to each instance

The option bdl_pos_adj should be provided for each card instance instead of

a global one because the value depends rather on each controller-chip.

- ALSA: hda - remove position_fix=3

position_fix=3 is the option to correct the DMA position with the

FIFO size. But, it never worked correctly, and we have now more other

workarounds for the DMA position fixes. Thus better to remove it.

Also, change POS_FIX_NONE to POS_FIX_LPIB to represent its real role

better.

- ALSA: hda - Add bdl_pos_adj option

Added a new option, bdl_pos_adj, to adjust the delay of IRQ-wakeup

timing.

Most HD-audio hardwares have a problem that a BDL IRQ is issued before

actually the data and the DMA pointer are updated.

We have already a mechanism to force to delay snd_pcm_period_elapsed()

calls via workq, but this costs much CPU, and typically the delay is

within one sample. Thus, it's more clever to adjust the BDL entries

instead.

The new option adds the size of the delay in frames. As default,

it's set to 1 -- that is, one sample delay. Even the hardware is

really correct, one sample delay is relatively harmless in comparison

with reporting wrong positions.

- [ALSA] hda - increase max_codecs of ICH to 4

It turned out that some ICH9-based boards use SD3 for the audio codec

where the current driver code doesn't probe. Since we have a better

codec slot check now, it must be safe to increase this to 4.