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: Fri, 01 Jun 2007 08:45:01 -0500 [thread overview]
Message-ID: <466022DD.8010200@freescale.com> (raw)
In-Reply-To: <1180704965.26032.68.camel@localhost.localdomain>
Liam Girdwood wrote:
> Imho, there is little point in probing or allocating any more resources
> until we know the I2C codec probe succeeds. We would just have to free
> any resources allocated up to that point.
True, but if the I2C probe fails, then I would think that the whole system is shot, so this sounds like a very unlikely situation. If you changed the code to clean up after an I2C failure, you could make the whole thing more modular, including eliminating the call to snd_soc_new() in the codec driver.
Since ASoC divides everything into four more-or-less independent drivers, it makes sense that it should be able to handle a situation where one of those drivers just fails to load.
next prev parent reply other threads:[~2007-06-01 13:44 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
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 [this message]
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=466022DD.8010200@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.