alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@freescale.com>
To: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: ASoC and a codec that can't be controlled
Date: Wed, 30 May 2007 13:10:28 -0500	[thread overview]
Message-ID: <465DBE14.5020206@freescale.com> (raw)
In-Reply-To: <1180529741.29590.54.camel@a10072.wolfsonmicro.main>

Liam Girdwood wrote:

>> I guess I just don't understand why the codec driver is acting like the "master" driver of 
>> ASOC.  IMHO, the codec driver should be doing two things:
> 
> I guess this is due to an ordering issue we had during early
> development. We had to make sure that the I2C probe of the codec
> succeeded before registering the card, pcms, etc. Fwiw, I do intend to
> address this in future versions (I should probably add a road map to the
> wiki now).

In that case, I think we can solve this problem as well as the PowerPC device tree problem 
in one shot, because they're basically the same problem.

Anyway, let me see if I get this right:

1. The first function called is eti_b1_init().
2. eti_b1_init() calls platform_device_add() to add an soc-audio class device and register 
the eti_b1_snd_devdata structure.
3. The registration causes a number of things to happen, one of which is a call to 
soc_probe().
4. soc_probe() sees that the snd_soc_machine_eti_b1.probe is NULL, so that part is skipped.
3. soc_probe() sees that snd_soc_machine_eti_b1.dai_link->cpu_dai->probe is also NULL, so 
that part is skipped. (eti_b1_snd_devdata.machine == snd_soc_machine_eti_b1)
4. soc_probe() sees that soc_codec_dev_wm8731.probe is not NULL, so it calls wm8731_probe().
5. wm8731_probe() registers an I2C driver.
6. The I2C class driver calls wm8731_i2c_driver.attach_adapter, which is wm8731_i2c_attach().
7. wm8731_i2c_attach() calls i2c_probe(), which in turn calls wm8731_codec_probe()
8. wm8731_codec_probe() allocates a snd_soc_codec structure.
8. wm8731_codec_probe() calls wm8731_init().

This means that if there is no I2C support, wm8731_init() will never be called.

9. wm8731_init() initializes the snd_soc_codec structure.

Question: why doesn't wm8731_probe() initialize the non-I2C parts of the snd_soc_codec 
structure?  For example, snd_soc_codec.dai, snd_soc_codec.name, and snd_soc_codec.owner? 
That way, the snd_soc_codec structure will be properly initialized even when there's no I2C.

10. wm8731_init() calls snd_soc_new_pcms.
11. wm8731_init() exits, wm8731_codec_probe() exits, wm8731_i2c_attach() exits, and then 
wm8731_probe() exits.  Control returns to soc_probe().
12. soc_probe() notices that eti_b1_snd_devdata.platform.probe is NULL, so it skips that.

Question: why don't you define a function for at91_soc_platform.probe, and in that 
function you can call snd_soc_new_pcms()?  That way, you guarantee the codec driver's I2C 
interface is initialized before snd_soc_new_pcms() is called, and you avoid have PCM calls 
in the codec driver.

>> ASOC and the machine driver should then work in tandem to decide which driver will do what 
>> and which capabilities are *actually* supported.  *Something* needs to look at the entire 
>> system and say to each device, "Well, yes, I know about this little feature of yours, but 
>> we're just not going to support that today."
>>
> 
> The machine driver pretty much already does this. It can override valid
> hardware configurations and return -EINVAl if required. 

Do you have an example of that?  Would that be eti_b1_hw_params()?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

  parent reply	other threads:[~2007-05-30 18:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-22 15:47 ASoC and a codec that can't be controlled Timur Tabi
2007-05-23 15:37 ` Liam Girdwood
2007-05-25 20:17   ` Timur Tabi
2007-05-28 12:10     ` Liam Girdwood
2007-05-29  0:18       ` Timur Tabi
2007-05-29  8:53         ` Liam Girdwood
2007-05-29 18:10           ` Timur Tabi
2007-05-30 12:28             ` Liam Girdwood
2007-05-29 18:47       ` Timur Tabi
2007-05-30 12:20         ` Liam Girdwood
2007-05-29 19:02       ` Timur Tabi
     [not found]         ` <1180529741.29590.54.camel@a10072.wolfsonmicro.main>
2007-05-30 18:10           ` Timur Tabi [this message]
2007-05-31 17:19             ` Liam Girdwood
2007-05-31 19:49               ` Timur Tabi
2007-06-01 13:36                 ` Liam Girdwood
2007-06-01 13:45                   ` Timur Tabi
2007-06-01 21:34               ` Timur Tabi
2007-05-29 23:05       ` Timur Tabi
2007-05-30 13:06         ` Liam Girdwood
2007-05-30 15:46           ` Timur Tabi
2007-05-31 17:32             ` Liam Girdwood
2007-05-31 18:55               ` Timur Tabi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=465DBE14.5020206@freescale.com \
    --to=timur@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lg@opensource.wolfsonmicro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).