Difference between revisions of "Detailed HDA changes v1.0.17rc1 v1.0.17rc2"

From AlsaProject
Jump to: navigation, search
m (1 revision(s))

Revision as of 11:11, 31 October 2011


Detailed HDA changelog between 1.0.17rc1 and 1.0.17rc2 releases


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:
- [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
- ALSA: hda - Add bdl_pos_adj option
Added a new option, bdl_pos_adj, to adjust the delay of IRQ-wakeup
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
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.
Custom Search
Personal tools