On Mon, May 25, 2009 at 11:31:48AM +0800, Leung Chi Tat wrote:

1. describing those important structures, e.g. struct soc_enum, struct snd_kcontrol_new, struct snd_soc_dapm_widget;

An enum is used to define an enumerated ALSA control. A kcontrol is a generic ALSA control - there's nothing ASoC specific about it - and a DAPM widget is a thing for which there is power control.

2. what is/are the relationships among those important structures;
3. what is the differences between those controls for struct snd_kcontrol_new and struct snd_soc_dapm_widget;

It'd be easier to answer this if you had some more specific questions? In general the answer is that things only go into DAPM if they have some relevance to power - that is, if they're a thing for which there is power control or if they control the routing of audio through the chip (and therefore let the core decide which parts of the chip need to be powered on).

As has already been suggested the easiest thing is probably to look at other CODEC drivers and compare what their drivers do with the datasheets.

4. Should those sinks, sources, paths be defined in the arrays of struct snd_dapm_widget;

Yes, all the things you have power control for should be there.

5. How can I select those defined paths through ALSA user-mode library as I can't find any examples in those ALSA tutorials;

The controls are all visible as normal ALSA controls - there's nothing ASoC specific in the userspace API. Look with an application such as amixer or alsamixer to see what's there.

Indeed, I'm right now trying to write a WM8985 driver for my s3c6400 based platform based on the kernel source v2.6.21 from Samsung.

Note that this is rather old and there were a few issues in the example code with the way that the clocking was set up for the CPU - mostly due to direct access to the system clocking registers which could interfere with other drivers. It might be worth looking at the very latest linux-next tree where there's a mostly complete implementation of audio support.