Commit | Line | Data |
---|---|---|
a7fe49bf TI |
1 | MORE NOTES ON HD-AUDIO DRIVER |
2 | ============================= | |
3 | Takashi Iwai <tiwai@suse.de> | |
4 | ||
5 | ||
6 | GENERAL | |
7 | ------- | |
8 | ||
9 | HD-audio is the new standard on-board audio component on modern PCs | |
10 | after AC97. Although Linux has been supporting HD-audio since long | |
11 | time ago, there are often problems with new machines. A part of the | |
d2afbe78 TI |
12 | problem is broken BIOS, and the rest is the driver implementation. |
13 | This document explains the brief trouble-shooting and debugging | |
14 | methods for the HD-audio hardware. | |
a7fe49bf TI |
15 | |
16 | The HD-audio component consists of two parts: the controller chip and | |
17 | the codec chips on the HD-audio bus. Linux provides a single driver | |
d2afbe78 | 18 | for all controllers, snd-hda-intel. Although the driver name contains |
19f59460 | 19 | a word of a well-known hardware vendor, it's not specific to it but for |
d2afbe78 TI |
20 | all controller chips by other companies. Since the HD-audio |
21 | controllers are supposed to be compatible, the single snd-hda-driver | |
22 | should work in most cases. But, not surprisingly, there are known | |
23 | bugs and issues specific to each controller type. The snd-hda-intel | |
24 | driver has a bunch of workarounds for these as described below. | |
a7fe49bf TI |
25 | |
26 | A controller may have multiple codecs. Usually you have one audio | |
d2afbe78 TI |
27 | codec and optionally one modem codec. In theory, there might be |
28 | multiple audio codecs, e.g. for analog and digital outputs, and the | |
29 | driver might not work properly because of conflict of mixer elements. | |
30 | This should be fixed in future if such hardware really exists. | |
a7fe49bf TI |
31 | |
32 | The snd-hda-intel driver has several different codec parsers depending | |
33 | on the codec. It has a generic parser as a fallback, but this | |
34 | functionality is fairly limited until now. Instead of the generic | |
35 | parser, usually the codec-specific parser (coded in patch_*.c) is used | |
36 | for the codec-specific implementations. The details about the | |
37 | codec-specific problems are explained in the later sections. | |
38 | ||
39 | If you are interested in the deep debugging of HD-audio, read the | |
40 | HD-audio specification at first. The specification is found on | |
41 | Intel's web page, for example: | |
42 | ||
43 | - http://www.intel.com/standards/hdaudio/ | |
44 | ||
45 | ||
46 | HD-AUDIO CONTROLLER | |
47 | ------------------- | |
48 | ||
49 | DMA-Position Problem | |
50 | ~~~~~~~~~~~~~~~~~~~~ | |
51 | The most common problem of the controller is the inaccurate DMA | |
52 | pointer reporting. The DMA pointer for playback and capture can be | |
53 | read in two ways, either via a LPIB register or via a position-buffer | |
d2afbe78 TI |
54 | map. As default the driver tries to read from the io-mapped |
55 | position-buffer, and falls back to LPIB if the position-buffer appears | |
56 | dead. However, this detection isn't perfect on some devices. In such | |
57 | a case, you can change the default method via `position_fix` option. | |
a7fe49bf TI |
58 | |
59 | `position_fix=1` means to use LPIB method explicitly. | |
60 | `position_fix=2` means to use the position-buffer. 0 is the default | |
d2afbe78 TI |
61 | value, the automatic check and fallback to LPIB as described in the |
62 | above. If you get a problem of repeated sounds, this option might | |
63 | help. | |
a7fe49bf TI |
64 | |
65 | In addition to that, every controller is known to be broken regarding | |
66 | the wake-up timing. It wakes up a few samples before actually | |
67 | processing the data on the buffer. This caused a lot of problems, for | |
68 | example, with ALSA dmix or JACK. Since 2.6.27 kernel, the driver puts | |
69 | an artificial delay to the wake up timing. This delay is controlled | |
70 | via `bdl_pos_adj` option. | |
71 | ||
72 | When `bdl_pos_adj` is a negative value (as default), it's assigned to | |
73 | an appropriate value depending on the controller chip. For Intel | |
d2afbe78 | 74 | chips, it'd be 1 while it'd be 32 for others. Usually this works. |
a7fe49bf | 75 | Only in case it doesn't work and you get warning messages, you should |
d2afbe78 | 76 | change this parameter to other values. |
a7fe49bf TI |
77 | |
78 | ||
79 | Codec-Probing Problem | |
80 | ~~~~~~~~~~~~~~~~~~~~~ | |
81 | A less often but a more severe problem is the codec probing. When | |
82 | BIOS reports the available codec slots wrongly, the driver gets | |
83 | confused and tries to access the non-existing codec slot. This often | |
d2afbe78 TI |
84 | results in the total screw-up, and destructs the further communication |
85 | with the codec chips. The symptom appears usually as error messages | |
86 | like: | |
a7fe49bf | 87 | ------------------------------------------------------------------------ |
d2afbe78 | 88 | hda_intel: azx_get_response timeout, switching to polling mode: |
a7fe49bf | 89 | last cmd=0x12345678 |
d2afbe78 | 90 | hda_intel: azx_get_response timeout, switching to single_cmd mode: |
a7fe49bf TI |
91 | last cmd=0x12345678 |
92 | ------------------------------------------------------------------------ | |
93 | ||
94 | The first line is a warning, and this is usually relatively harmless. | |
95 | It means that the codec response isn't notified via an IRQ. The | |
96 | driver uses explicit polling method to read the response. It gives | |
97 | very slight CPU overhead, but you'd unlikely notice it. | |
98 | ||
99 | The second line is, however, a fatal error. If this happens, usually | |
100 | it means that something is really wrong. Most likely you are | |
101 | accessing a non-existing codec slot. | |
102 | ||
103 | Thus, if the second error message appears, try to narrow the probed | |
104 | codec slots via `probe_mask` option. It's a bitmask, and each bit | |
d2afbe78 TI |
105 | corresponds to the codec slot. For example, to probe only the first |
106 | slot, pass `probe_mask=1`. For the first and the third slots, pass | |
107 | `probe_mask=5` (where 5 = 1 | 4), and so on. | |
a7fe49bf TI |
108 | |
109 | Since 2.6.29 kernel, the driver has a more robust probing method, so | |
110 | this error might happen rarely, though. | |
111 | ||
ae374d66 TI |
112 | On a machine with a broken BIOS, sometimes you need to force the |
113 | driver to probe the codec slots the hardware doesn't report for use. | |
114 | In such a case, turn the bit 8 (0x100) of `probe_mask` option on. | |
115 | Then the rest 8 bits are passed as the codec slots to probe | |
116 | unconditionally. For example, `probe_mask=0x103` will force to probe | |
117 | the codec slots 0 and 1 no matter what the hardware reports. | |
118 | ||
a7fe49bf TI |
119 | |
120 | Interrupt Handling | |
121 | ~~~~~~~~~~~~~~~~~~ | |
122 | In rare but some cases, the interrupt isn't properly handled as | |
123 | default. You would notice this by the DMA transfer error reported by | |
124 | ALSA PCM core, for example. Using MSI might help in such a case. | |
125 | Pass `enable_msi=1` option for enabling MSI. | |
126 | ||
127 | ||
128 | HD-AUDIO CODEC | |
129 | -------------- | |
130 | ||
131 | Model Option | |
132 | ~~~~~~~~~~~~ | |
d2afbe78 TI |
133 | The most common problem regarding the HD-audio driver is the |
134 | unsupported codec features or the mismatched device configuration. | |
135 | Most of codec-specific code has several preset models, either to | |
136 | override the BIOS setup or to provide more comprehensive features. | |
a7fe49bf TI |
137 | |
138 | The driver checks PCI SSID and looks through the static configuration | |
139 | table until any matching entry is found. If you have a new machine, | |
140 | you may see a message like below: | |
9a11f1aa TI |
141 | ------------------------------------------------------------------------ |
142 | hda_codec: ALC880: BIOS auto-probing. | |
143 | ------------------------------------------------------------------------ | |
144 | Meanwhile, in the earlier versions, you would see a message like: | |
a7fe49bf TI |
145 | ------------------------------------------------------------------------ |
146 | hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... | |
147 | ------------------------------------------------------------------------ | |
d2afbe78 TI |
148 | Even if you see such a message, DON'T PANIC. Take a deep breath and |
149 | keep your towel. First of all, it's an informational message, no | |
150 | warning, no error. This means that the PCI SSID of your device isn't | |
151 | listed in the known preset model (white-)list. But, this doesn't mean | |
152 | that the driver is broken. Many codec-drivers provide the automatic | |
153 | configuration mechanism based on the BIOS setup. | |
a7fe49bf TI |
154 | |
155 | The HD-audio codec has usually "pin" widgets, and BIOS sets the default | |
156 | configuration of each pin, which indicates the location, the | |
157 | connection type, the jack color, etc. The HD-audio driver can guess | |
158 | the right connection judging from these default configuration values. | |
d2afbe78 | 159 | However -- some codec-support codes, such as patch_analog.c, don't |
a7fe49bf TI |
160 | support the automatic probing (yet as of 2.6.28). And, BIOS is often, |
161 | yes, pretty often broken. It sets up wrong values and screws up the | |
162 | driver. | |
163 | ||
d2afbe78 TI |
164 | The preset model is provided basically to overcome such a situation. |
165 | When the matching preset model is found in the white-list, the driver | |
a7fe49bf | 166 | assumes the static configuration of that preset and builds the mixer |
d2afbe78 TI |
167 | elements and PCM streams based on the static information. Thus, if |
168 | you have a newer machine with a slightly different PCI SSID from the | |
169 | existing one, you may have a good chance to re-use the same model. | |
170 | You can pass the `model` option to specify the preset model instead of | |
171 | PCI SSID look-up. | |
a7fe49bf TI |
172 | |
173 | What `model` option values are available depends on the codec chip. | |
174 | Check your codec chip from the codec proc file (see "Codec Proc-File" | |
175 | section below). It will show the vendor/product name of your codec | |
83b2086c | 176 | chip. Then, see Documentation/sound/alsa/HD-Audio-Models.txt file, |
692f9042 | 177 | the section of HD-audio driver. You can find a list of codecs |
d2afbe78 | 178 | and `model` options belonging to each codec. For example, for Realtek |
a7fe49bf TI |
179 | ALC262 codec chip, pass `model=ultra` for devices that are compatible |
180 | with Samsung Q1 Ultra. | |
181 | ||
d2afbe78 TI |
182 | Thus, the first thing you can do for any brand-new, unsupported and |
183 | non-working HD-audio hardware is to check HD-audio codec and several | |
83b2086c | 184 | different `model` option values. If you have any luck, some of them |
d2afbe78 | 185 | might suit with your device well. |
a7fe49bf TI |
186 | |
187 | Some codecs such as ALC880 have a special model option `model=test`. | |
188 | This configures the driver to provide as many mixer controls as | |
189 | possible for every single pin feature except for the unsolicited | |
190 | events (and maybe some other specials). Adjust each mixer element and | |
191 | try the I/O in the way of trial-and-error until figuring out the whole | |
192 | I/O pin mappings. | |
193 | ||
194 | Note that `model=generic` has a special meaning. It means to use the | |
195 | generic parser regardless of the codec. Usually the codec-specific | |
196 | parser is much better than the generic parser (as now). Thus this | |
197 | option is more about the debugging purpose. | |
198 | ||
199 | ||
200 | Speaker and Headphone Output | |
201 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
202 | One of the most frequent (and obvious) bugs with HD-audio is the | |
203 | silent output from either or both of a built-in speaker and a | |
204 | headphone jack. In general, you should try a headphone output at | |
205 | first. A speaker output often requires more additional controls like | |
d2afbe78 TI |
206 | the external amplifier bits. Thus a headphone output has a slightly |
207 | better chance. | |
a7fe49bf TI |
208 | |
209 | Before making a bug report, double-check whether the mixer is set up | |
210 | correctly. The recent version of snd-hda-intel driver provides mostly | |
d2afbe78 TI |
211 | "Master" volume control as well as "Front" volume (where Front |
212 | indicates the front-channels). In addition, there can be individual | |
213 | "Headphone" and "Speaker" controls. | |
a7fe49bf TI |
214 | |
215 | Ditto for the speaker output. There can be "External Amplifier" | |
216 | switch on some codecs. Turn on this if present. | |
217 | ||
218 | Another related problem is the automatic mute of speaker output by | |
219 | headphone plugging. This feature is implemented in most cases, but | |
220 | not on every preset model or codec-support code. | |
221 | ||
222 | In anyway, try a different model option if you have such a problem. | |
223 | Some other models may match better and give you more matching | |
224 | functionality. If none of the available models works, send a bug | |
225 | report. See the bug report section for details. | |
226 | ||
227 | If you are masochistic enough to debug the driver problem, note the | |
228 | following: | |
229 | ||
230 | - The speaker (and the headphone, too) output often requires the | |
231 | external amplifier. This can be set usually via EAPD verb or a | |
232 | certain GPIO. If the codec pin supports EAPD, you have a better | |
233 | chance via SET_EAPD_BTL verb (0x70c). On others, GPIO pin (mostly | |
d2afbe78 | 234 | it's either GPIO0 or GPIO1) may turn on/off EAPD. |
a7fe49bf TI |
235 | - Some Realtek codecs require special vendor-specific coefficients to |
236 | turn on the amplifier. See patch_realtek.c. | |
237 | - IDT codecs may have extra power-enable/disable controls on each | |
238 | analog pin. See patch_sigmatel.c. | |
239 | - Very rare but some devices don't accept the pin-detection verb until | |
240 | triggered. Issuing GET_PIN_SENSE verb (0xf09) may result in the | |
241 | codec-communication stall. Some examples are found in | |
242 | patch_realtek.c. | |
243 | ||
244 | ||
245 | Capture Problems | |
246 | ~~~~~~~~~~~~~~~~ | |
d2afbe78 TI |
247 | The capture problems are often because of missing setups of mixers. |
248 | Thus, before submitting a bug report, make sure that you set up the | |
249 | mixer correctly. For example, both "Capture Volume" and "Capture | |
250 | Switch" have to be set properly in addition to the right "Capture | |
251 | Source" or "Input Source" selection. Some devices have "Mic Boost" | |
252 | volume or switch. | |
a7fe49bf TI |
253 | |
254 | When the PCM device is opened via "default" PCM (without pulse-audio | |
255 | plugin), you'll likely have "Digital Capture Volume" control as well. | |
256 | This is provided for the extra gain/attenuation of the signal in | |
257 | software, especially for the inputs without the hardware volume | |
258 | control such as digital microphones. Unless really needed, this | |
d2afbe78 TI |
259 | should be set to exactly 50%, corresponding to 0dB -- neither extra |
260 | gain nor attenuation. When you use "hw" PCM, i.e., a raw access PCM, | |
261 | this control will have no influence, though. | |
a7fe49bf TI |
262 | |
263 | It's known that some codecs / devices have fairly bad analog circuits, | |
264 | and the recorded sound contains a certain DC-offset. This is no bug | |
265 | of the driver. | |
266 | ||
d2afbe78 | 267 | Most of modern laptops have no analog CD-input connection. Thus, the |
a7fe49bf | 268 | recording from CD input won't work in many cases although the driver |
d2afbe78 | 269 | provides it as the capture source. Use CDDA instead. |
a7fe49bf TI |
270 | |
271 | The automatic switching of the built-in and external mic per plugging | |
272 | is implemented on some codec models but not on every model. Partly | |
273 | because of my laziness but mostly lack of testers. Feel free to | |
274 | submit the improvement patch to the author. | |
275 | ||
276 | ||
277 | Direct Debugging | |
278 | ~~~~~~~~~~~~~~~~ | |
f8bbd06b | 279 | If no model option gives you a better result, and you are a tough guy |
623b9f67 | 280 | to fight against evil, try debugging via hitting the raw HD-audio |
a7fe49bf TI |
281 | codec verbs to the device. Some tools are available: hda-emu and |
282 | hda-analyzer. The detailed description is found in the sections | |
283 | below. You'd need to enable hwdep for using these tools. See "Kernel | |
d2afbe78 | 284 | Configuration" section. |
a7fe49bf TI |
285 | |
286 | ||
287 | OTHER ISSUES | |
288 | ------------ | |
289 | ||
290 | Kernel Configuration | |
291 | ~~~~~~~~~~~~~~~~~~~~ | |
292 | In general, I recommend you to enable the sound debug option, | |
293 | `CONFIG_SND_DEBUG=y`, no matter whether you are debugging or not. | |
294 | This enables snd_printd() macro and others, and you'll get additional | |
295 | kernel messages at probing. | |
296 | ||
297 | In addition, you can enable `CONFIG_SND_DEBUG_VERBOSE=y`. But this | |
298 | will give you far more messages. Thus turn this on only when you are | |
299 | sure to want it. | |
300 | ||
301 | Don't forget to turn on the appropriate `CONFIG_SND_HDA_CODEC_*` | |
302 | options. Note that each of them corresponds to the codec chip, not | |
303 | the controller chip. Thus, even if lspci shows the Nvidia controller, | |
d2afbe78 TI |
304 | you may need to choose the option for other vendors. If you are |
305 | unsure, just select all yes. | |
a7fe49bf TI |
306 | |
307 | `CONFIG_SND_HDA_HWDEP` is a useful option for debugging the driver. | |
308 | When this is enabled, the driver creates hardware-dependent devices | |
309 | (one per each codec), and you have a raw access to the device via | |
d2afbe78 TI |
310 | these device files. For example, `hwC0D2` will be created for the |
311 | codec slot #2 of the first card (#0). For debug-tools such as | |
312 | hda-verb and hda-analyzer, the hwdep device has to be enabled. | |
313 | Thus, it'd be better to turn this on always. | |
a7fe49bf TI |
314 | |
315 | `CONFIG_SND_HDA_RECONFIG` is a new option, and this depends on the | |
316 | hwdep option above. When enabled, you'll have some sysfs files under | |
317 | the corresponding hwdep directory. See "HD-audio reconfiguration" | |
318 | section below. | |
319 | ||
320 | `CONFIG_SND_HDA_POWER_SAVE` option enables the power-saving feature. | |
321 | See "Power-saving" section below. | |
322 | ||
323 | ||
324 | Codec Proc-File | |
325 | ~~~~~~~~~~~~~~~ | |
326 | The codec proc-file is a treasure-chest for debugging HD-audio. | |
327 | It shows most of useful information of each codec widget. | |
328 | ||
329 | The proc file is located in /proc/asound/card*/codec#*, one file per | |
330 | each codec slot. You can know the codec vendor, product id and | |
331 | names, the type of each widget, capabilities and so on. | |
332 | This file, however, doesn't show the jack sensing state, so far. This | |
333 | is because the jack-sensing might be depending on the trigger state. | |
334 | ||
335 | This file will be picked up by the debug tools, and also it can be fed | |
336 | to the emulator as the primary codec information. See the debug tools | |
337 | section below. | |
338 | ||
339 | This proc file can be also used to check whether the generic parser is | |
340 | used. When the generic parser is used, the vendor/product ID name | |
341 | will appear as "Realtek ID 0262", instead of "Realtek ALC262". | |
342 | ||
343 | ||
344 | HD-Audio Reconfiguration | |
345 | ~~~~~~~~~~~~~~~~~~~~~~~~ | |
346 | This is an experimental feature to allow you re-configure the HD-audio | |
347 | codec dynamically without reloading the driver. The following sysfs | |
348 | files are available under each codec-hwdep device directory (e.g. | |
349 | /sys/class/sound/hwC0D0): | |
350 | ||
351 | vendor_id:: | |
352 | Shows the 32bit codec vendor-id hex number. You can change the | |
353 | vendor-id value by writing to this file. | |
354 | subsystem_id:: | |
355 | Shows the 32bit codec subsystem-id hex number. You can change the | |
356 | subsystem-id value by writing to this file. | |
357 | revision_id:: | |
358 | Shows the 32bit codec revision-id hex number. You can change the | |
359 | revision-id value by writing to this file. | |
360 | afg:: | |
361 | Shows the AFG ID. This is read-only. | |
362 | mfg:: | |
363 | Shows the MFG ID. This is read-only. | |
364 | name:: | |
365 | Shows the codec name string. Can be changed by writing to this | |
366 | file. | |
367 | modelname:: | |
368 | Shows the currently set `model` option. Can be changed by writing | |
369 | to this file. | |
370 | init_verbs:: | |
371 | The extra verbs to execute at initialization. You can add a verb by | |
d02b1f39 TI |
372 | writing to this file. Pass three numbers: nid, verb and parameter |
373 | (separated with a space). | |
a7fe49bf | 374 | hints:: |
d02b1f39 TI |
375 | Shows / stores hint strings for codec parsers for any use. |
376 | Its format is `key = value`. For example, passing `hp_detect = yes` | |
377 | to IDT/STAC codec parser will result in the disablement of the | |
378 | headphone detection. | |
f1085c4f TI |
379 | init_pin_configs:: |
380 | Shows the initial pin default config values set by BIOS. | |
346ff70f | 381 | driver_pin_configs:: |
f1085c4f TI |
382 | Shows the pin default values set by the codec parser explicitly. |
383 | This doesn't show all pin values but only the changed values by | |
384 | the parser. That is, if the parser doesn't change the pin default | |
385 | config values by itself, this will contain nothing. | |
346ff70f TI |
386 | user_pin_configs:: |
387 | Shows the pin default config values to override the BIOS setup. | |
388 | Writing this (with two numbers, NID and value) appends the new | |
389 | value. The given will be used instead of the initial BIOS value at | |
5e7b8e0d TI |
390 | the next reconfiguration time. Note that this config will override |
391 | even the driver pin configs, too. | |
a7fe49bf TI |
392 | reconfig:: |
393 | Triggers the codec re-configuration. When any value is written to | |
394 | this file, the driver re-initialize and parses the codec tree | |
395 | again. All the changes done by the sysfs entries above are taken | |
396 | into account. | |
397 | clear:: | |
398 | Resets the codec, removes the mixer elements and PCM stuff of the | |
399 | specified codec, and clear all init verbs and hints. | |
400 | ||
39c2871e TI |
401 | For example, when you want to change the pin default configuration |
402 | value of the pin widget 0x14 to 0x9993013f, and let the driver | |
403 | re-configure based on that state, run like below: | |
404 | ------------------------------------------------------------------------ | |
405 | # echo 0x14 0x9993013f > /sys/class/sound/hwC0D0/user_pin_configs | |
406 | # echo 1 > /sys/class/sound/hwC0D0/reconfig | |
407 | ------------------------------------------------------------------------ | |
408 | ||
a7fe49bf | 409 | |
76824825 TI |
410 | Early Patching |
411 | ~~~~~~~~~~~~~~ | |
412 | When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a | |
413 | firmware file for modifying the HD-audio setup before initializing the | |
414 | codec. This can work basically like the reconfiguration via sysfs in | |
415 | the above, but it does it before the first codec configuration. | |
416 | ||
1e7b8c87 | 417 | A patch file is a plain text file which looks like below: |
76824825 TI |
418 | |
419 | ------------------------------------------------------------------------ | |
420 | [codec] | |
421 | 0x12345678 0xabcd1234 2 | |
422 | ||
423 | [model] | |
424 | auto | |
425 | ||
426 | [pincfg] | |
427 | 0x12 0x411111f0 | |
428 | ||
429 | [verb] | |
430 | 0x20 0x500 0x03 | |
431 | 0x20 0x400 0xff | |
432 | ||
433 | [hint] | |
434 | hp_detect = yes | |
435 | ------------------------------------------------------------------------ | |
436 | ||
437 | The file needs to have a line `[codec]`. The next line should contain | |
438 | three numbers indicating the codec vendor-id (0x12345678 in the | |
439 | example), the codec subsystem-id (0xabcd1234) and the address (2) of | |
440 | the codec. The rest patch entries are applied to this specified codec | |
441 | until another codec entry is given. | |
442 | ||
443 | The `[model]` line allows to change the model name of the each codec. | |
444 | In the example above, it will be changed to model=auto. | |
445 | Note that this overrides the module option. | |
446 | ||
447 | After the `[pincfg]` line, the contents are parsed as the initial | |
448 | default pin-configurations just like `user_pin_configs` sysfs above. | |
449 | The values can be shown in user_pin_configs sysfs file, too. | |
450 | ||
451 | Similarly, the lines after `[verb]` are parsed as `init_verbs` | |
452 | sysfs entries, and the lines after `[hint]` are parsed as `hints` | |
453 | sysfs entries, respectively. | |
454 | ||
1e7b8c87 TI |
455 | The hd-audio driver reads the file via request_firmware(). Thus, |
456 | a patch file has to be located on the appropriate firmware path, | |
457 | typically, /lib/firmware. For example, when you pass the option | |
458 | `patch=hda-init.fw`, the file /lib/firmware/hda-init-fw must be | |
459 | present. | |
460 | ||
461 | The patch module option is specific to each card instance, and you | |
462 | need to give one file name for each instance, separated by commas. | |
463 | For example, if you have two cards, one for an on-board analog and one | |
464 | for an HDMI video board, you may pass patch option like below: | |
465 | ------------------------------------------------------------------------ | |
466 | options snd-hda-intel patch=on-board-patch,hdmi-patch | |
467 | ------------------------------------------------------------------------ | |
468 | ||
76824825 | 469 | |
a7fe49bf TI |
470 | Power-Saving |
471 | ~~~~~~~~~~~~ | |
472 | The power-saving is a kind of auto-suspend of the device. When the | |
473 | device is inactive for a certain time, the device is automatically | |
474 | turned off to save the power. The time to go down is specified via | |
475 | `power_save` module option, and this option can be changed dynamically | |
476 | via sysfs. | |
477 | ||
478 | The power-saving won't work when the analog loopback is enabled on | |
479 | some codecs. Make sure that you mute all unneeded signal routes when | |
480 | you want the power-saving. | |
481 | ||
482 | The power-saving feature might cause audible click noises at each | |
483 | power-down/up depending on the device. Some of them might be | |
484 | solvable, but some are hard, I'm afraid. Some distros such as | |
485 | openSUSE enables the power-saving feature automatically when the power | |
486 | cable is unplugged. Thus, if you hear noises, suspect first the | |
623b9f67 | 487 | power-saving. See /sys/module/snd_hda_intel/parameters/power_save to |
a7fe49bf TI |
488 | check the current value. If it's non-zero, the feature is turned on. |
489 | ||
490 | ||
132bb7c0 TI |
491 | Development Tree |
492 | ~~~~~~~~~~~~~~~~ | |
493 | The latest development codes for HD-audio are found on sound git tree: | |
494 | ||
495 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git | |
496 | ||
497 | The master branch or for-next branches can be used as the main | |
498 | development branches in general while the HD-audio specific patches | |
499 | are committed in topic/hda branch. | |
500 | ||
501 | If you are using the latest Linus tree, it'd be better to pull the | |
502 | above GIT tree onto it. If you are using the older kernels, an easy | |
503 | way to try the latest ALSA code is to build from the snapshot | |
504 | tarball. There are daily tarballs and the latest snapshot tarball. | |
505 | All can be built just like normal alsa-driver release packages, that | |
506 | is, installed via the usual spells: configure, make and make | |
507 | install(-modules). See INSTALL in the package. The snapshot tarballs | |
508 | are found at: | |
509 | ||
510 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ | |
511 | ||
512 | ||
a7fe49bf TI |
513 | Sending a Bug Report |
514 | ~~~~~~~~~~~~~~~~~~~~ | |
515 | If any model or module options don't work for your device, it's time | |
516 | to send a bug report to the developers. Give the following in your | |
517 | bug report: | |
518 | ||
519 | - Hardware vendor, product and model names | |
520 | - Kernel version (and ALSA-driver version if you built externally) | |
521 | - `alsa-info.sh` output; run with `--no-upload` option. See the | |
522 | section below about alsa-info | |
523 | ||
524 | If it's a regression, at best, send alsa-info outputs of both working | |
525 | and non-working kernels. This is really helpful because we can | |
526 | compare the codec registers directly. | |
527 | ||
528 | Send a bug report either the followings: | |
529 | ||
530 | kernel-bugzilla:: | |
531 | http://bugme.linux-foundation.org/ | |
532 | alsa-devel ML:: | |
533 | alsa-devel@alsa-project.org | |
534 | ||
535 | ||
536 | DEBUG TOOLS | |
537 | ----------- | |
538 | ||
539 | This section describes some tools available for debugging HD-audio | |
540 | problems. | |
541 | ||
542 | alsa-info | |
543 | ~~~~~~~~~ | |
544 | The script `alsa-info.sh` is a very useful tool to gather the audio | |
545 | device information. You can fetch the latest version from: | |
546 | ||
547 | - http://www.alsa-project.org/alsa-info.sh | |
548 | ||
549 | Run this script as root, and it will gather the important information | |
550 | such as the module lists, module parameters, proc file contents | |
551 | including the codec proc files, mixer outputs and the control | |
552 | elements. As default, it will store the information onto a web server | |
553 | on alsa-project.org. But, if you send a bug report, it'd be better to | |
554 | run with `--no-upload` option, and attach the generated file. | |
555 | ||
556 | There are some other useful options. See `--help` option output for | |
557 | details. | |
558 | ||
ae374d66 TI |
559 | When a probe error occurs or when the driver obviously assigns a |
560 | mismatched model, it'd be helpful to load the driver with | |
561 | `probe_only=1` option (at best after the cold reboot) and run | |
562 | alsa-info at this state. With this option, the driver won't configure | |
563 | the mixer and PCM but just tries to probe the codec slot. After | |
564 | probing, the proc file is available, so you can get the raw codec | |
565 | information before modified by the driver. Of course, the driver | |
566 | isn't usable with `probe_only=1`. But you can continue the | |
567 | configuration via hwdep sysfs file if hda-reconfig option is enabled. | |
568 | ||
a7fe49bf TI |
569 | |
570 | hda-verb | |
571 | ~~~~~~~~ | |
572 | hda-verb is a tiny program that allows you to access the HD-audio | |
d2afbe78 | 573 | codec directly. You can execute a raw HD-audio codec verb with this. |
a7fe49bf TI |
574 | This program accesses the hwdep device, thus you need to enable the |
575 | kernel config `CONFIG_SND_HDA_HWDEP=y` beforehand. | |
576 | ||
577 | The hda-verb program takes four arguments: the hwdep device file, the | |
578 | widget NID, the verb and the parameter. When you access to the codec | |
579 | on the slot 2 of the card 0, pass /dev/snd/hwC0D2 to the first | |
580 | argument, typically. (However, the real path name depends on the | |
581 | system.) | |
582 | ||
583 | The second parameter is the widget number-id to access. The third | |
584 | parameter can be either a hex/digit number or a string corresponding | |
585 | to a verb. Similarly, the last parameter is the value to write, or | |
586 | can be a string for the parameter type. | |
587 | ||
588 | ------------------------------------------------------------------------ | |
589 | % hda-verb /dev/snd/hwC0D0 0x12 0x701 2 | |
590 | nid = 0x12, verb = 0x701, param = 0x2 | |
591 | value = 0x0 | |
592 | ||
593 | % hda-verb /dev/snd/hwC0D0 0x0 PARAMETERS VENDOR_ID | |
594 | nid = 0x0, verb = 0xf00, param = 0x0 | |
595 | value = 0x10ec0262 | |
596 | ||
597 | % hda-verb /dev/snd/hwC0D0 2 set_a 0xb080 | |
598 | nid = 0x2, verb = 0x300, param = 0xb080 | |
599 | value = 0x0 | |
600 | ------------------------------------------------------------------------ | |
601 | ||
602 | Although you can issue any verbs with this program, the driver state | |
603 | won't be always updated. For example, the volume values are usually | |
604 | cached in the driver, and thus changing the widget amp value directly | |
605 | via hda-verb won't change the mixer value. | |
606 | ||
607 | The hda-verb program is found in the ftp directory: | |
608 | ||
609 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ | |
610 | ||
611 | Also a git repository is available: | |
612 | ||
613 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-verb.git | |
614 | ||
615 | See README file in the tarball for more details about hda-verb | |
616 | program. | |
617 | ||
618 | ||
619 | hda-analyzer | |
620 | ~~~~~~~~~~~~ | |
621 | hda-analyzer provides a graphical interface to access the raw HD-audio | |
622 | control, based on pyGTK2 binding. It's a more powerful version of | |
d2afbe78 | 623 | hda-verb. The program gives you an easy-to-use GUI stuff for showing |
a7fe49bf TI |
624 | the widget information and adjusting the amp values, as well as the |
625 | proc-compatible output. | |
626 | ||
627 | The hda-analyzer is a part of alsa.git repository in | |
628 | alsa-project.org: | |
629 | ||
630 | - http://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer | |
631 | ||
632 | ||
623b9f67 TI |
633 | Codecgraph |
634 | ~~~~~~~~~~ | |
635 | Codecgraph is a utility program to generate a graph and visualizes the | |
636 | codec-node connection of a codec chip. It's especially useful when | |
637 | you analyze or debug a codec without a proper datasheet. The program | |
638 | parses the given codec proc file and converts to SVG via graphiz | |
639 | program. | |
640 | ||
641 | The tarball and GIT trees are found in the web page at: | |
642 | ||
643 | - http://helllabs.org/codecgraph/ | |
644 | ||
645 | ||
a7fe49bf TI |
646 | hda-emu |
647 | ~~~~~~~ | |
d2afbe78 | 648 | hda-emu is an HD-audio emulator. The main purpose of this program is |
a7fe49bf TI |
649 | to debug an HD-audio codec without the real hardware. Thus, it |
650 | doesn't emulate the behavior with the real audio I/O, but it just | |
651 | dumps the codec register changes and the ALSA-driver internal changes | |
652 | at probing and operating the HD-audio driver. | |
653 | ||
654 | The program requires a codec proc-file to simulate. Get a proc file | |
655 | for the target codec beforehand, or pick up an example codec from the | |
656 | codec proc collections in the tarball. Then, run the program with the | |
657 | proc file, and the hda-emu program will start parsing the codec file | |
658 | and simulates the HD-audio driver: | |
659 | ||
660 | ------------------------------------------------------------------------ | |
661 | % hda-emu codecs/stac9200-dell-d820-laptop | |
662 | # Parsing.. | |
663 | hda_codec: Unknown model for STAC9200, using BIOS defaults | |
664 | hda_codec: pin nid 08 bios pin config 40c003fa | |
665 | .... | |
666 | ------------------------------------------------------------------------ | |
667 | ||
668 | The program gives you only a very dumb command-line interface. You | |
669 | can get a proc-file dump at the current state, get a list of control | |
670 | (mixer) elements, set/get the control element value, simulate the PCM | |
671 | operation, the jack plugging simulation, etc. | |
672 | ||
673 | The package is found in: | |
674 | ||
675 | - ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ | |
676 | ||
677 | A git repository is available: | |
678 | ||
679 | - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git | |
680 | ||
681 | See README file in the tarball for more details about hda-emu | |
682 | program. |