[alsa-devel] HD-audio dynamic configuration

[Takashi Iwai]

Hi,

time passed since the last discussion about where the HD-audio driver 
development to go to.  I checked and tried to rework a bit the
user-space configuration tool, and found out that it's really  hard to
keep it up to date.

One of the big obstacles is that the HD-audio codecs often behave
unexpectedly, in most cases, due to hardware bugs.  For example, some
codecs need the override of AMP caps and some needs rewrite of pin
caps, etc.  This is hard to catch with a sole generic code.  It means,
we need more or less codec-specific workarounds.

Consequently, I believe it's easier to keep a little amount of
codec-specific parser codes in the hda driver.  This is of course
hard-coded in the kernel.  Then the goal is to reduce the amount of
"patches" we have now for each specific device type.

For this purpose, I've implemented a new feature -- allow hd-audio
driver to reconfigure dynamically with additional hints.  The hd-audio
driver would have sysfs entries that can read/write the information
dynamically and trigger the re-configuration of the parser.  Right
now, it's created as sysfs entries of each hwdep device, so that it
can be bound to each codec chip.

For example, suppose the card0 has codec#2.  It corresponds to hwC0D2
device.   /sys/class/sound/hwC0D2/ has the following new entries: 
  1. vendor_id, subsystem_id, revision_id, afg, mfg,
  2. name, modelname
  3. init-verbs, hints
  4. reconfig, clear

The files in 1 are the codec information that can be obtained from the
codec chip.  These are digits, and can be read *and* written.  The
write means the specific value will be overridden, and the driver
handles as if the codec returns so.  For example, if you have a new,
unsupported codec chip that is compatible with others, you can change
vendor_id value on the fly.

The files in 2 are the strings that appear in the mixer, etc.  The
modelname is the model module option.  This can be changed dynamically
as well.

The init-verbs and hints are write-only.  You can pass the additional
init verbs (e.g. for reprogramming the pincfg) and pass hints to the
codec parser code.  The hints are simply strings.

Then you can write (any value) to "reconfig" to trigger the
reconfiguration of the codec parser.  Then all existing PCMs and mixer
elements of this codec will be once removed and re-generated again
with new init-verbs and hints.  The "clear" is to clear the existing
PCMs, mixer elements and init-verbs/hints entries.

Now, the big missing piece is more clever codec parser code.
Especially, the generic parser could be greatly improved with hints.
A lot of works ahead, though :)

For people who are interested, I put preliminary patches on my git tree
here:
	git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git
For building the external modules, you'd need this build stub tree:
	git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/alsa-driver-build-unstable.git
and run utils/setup-alsa-kernel script once (see INSTALL).

The alsa-driver tarball snapshots are available at:
	http://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/
These experimental patches are in alsa-driver-unstable-snapshot
tarball.


Any comments appreciated.


thanks,

Takashi