Great thanks Vinod for your reactivity. Always helpful 2016-07-19 5:54 GMT+02:00 Vinod Koul <vinod.koul@xxxxxxxxx>: > 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 > > -- > ~Vinod > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
