On Thu, Jul 14, 2016 at 03:07:20PM +0200, Chemsi Mehdi wrote:
Why codec driver of ASOC are always I2C based ?, is codec driver role is only control of audio hardware(set/reset registers only)?
That is not true, there are few SPI based and one i wrote which was a different method altogether. Mostly the audio embedded industry uses I2C codecs so they are very common
There should be three drivers : machine driver, platform driver and codec driver , all of them have .probe and . remove , what is relation between all the probes? removes ?
All of these have two probes :)
First one in hardware probe. Nothing unusual here. Second is the ASoC probe. Each of these registers a component. The ASoC core will create the sound card only when all of these components are present. At that time the ASoC probe in invoked signalling card creation to driver
As far I know McBSP is source of audio coming from host and I2C/ McBSP have no direct relation so why we connect platform driver (McBSP) with codec driver(I2C) Via DAI ?
You will have to ask driver authors that, pls cc them
When calling snd_pcm_open from userspace which kernel API is called ? snd_pcm_lib_ioctl or snd_stm_spdif_player_open ? if snd_stm_spdif_player_open so when called snd_pcm_lib_ioctl ?
system call open()
How ALSA KERNELAPI is connected to ALSA SOC CORE, via which calls/mechanism ?
The alsa provides driver callbacks. See struct snd_pcm_ops. ASoC provides the same to asoc driver as well! Additionally we have dai_ops as well.
ASoC has its own ops for card and then it invokes platform, codec pcm and dai_ops. See sound/soc/soc-pcm.c