From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Sebastian Reichel <sre@debian.org>,
Jarkko Nikula <jarkko.nikula@bitmer.com>,
linux-omap@vger.kernel.org, alsa-devel@alsa-project.org
Subject: Re: It looks like snd-soc-rx51 only works as built-in, not as a module
Date: Mon, 2 Jan 2012 19:40:47 +0000 [thread overview]
Message-ID: <20120102194046.GA14418@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAMP44s1hUYAcMTDBBPAbV=m39oGrbKXUhv44bp71XkNg-dEBzA@mail.gmail.com>
On Mon, Jan 02, 2012 at 08:33:03PM +0200, Felipe Contreras wrote:
> On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown
> > Which is relevant because...? To repeat, the ordering of module loading
> > is totally ortogonal as any ordering of modules is supported. You
> > appear to be totally ignoring what I am writing here.
> One thing how things _should_ be, and another is how things actually
> _are_. Right now snd-soc-rx51 doesn't work if it's loaded before
> snd_soc_tlv320aic3x. Period.
Can you provide logs showing this (with debug logging enabled in
soc-core)? If this is happening it's a very serious issue, though I am
rather surprised that nobody else has noticed such an issue since the
usual instantiation order would have the card appear before the CODEC
(due to the fact that the card is normally a platform device) and the
structure of the code makes it difficult to imagine a failure path.
> That means that *right now*, snd-soc-rx51 works fine with udev,
> because snd_soc_tlv320aic3x will be loaded at boot time. Now, if
> snd-soc-rx51 is converted and loaded automatically by udev as well,
> the issues might appear again.
Not if we look at and resolve the actual issue. Once again, any
instantation ordering should be supported. I really don't understand
why you keep on talking about fixing the module ordering,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-01-02 19:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-09 23:04 It looks like snd-soc-rx51 only works as built-in, not as a module Felipe Contreras
2011-12-10 8:27 ` Sebastian Reichel
2011-12-10 15:59 ` Felipe Contreras
2011-12-29 18:37 ` Mark Brown
2011-12-29 21:25 ` Felipe Contreras
2011-12-29 21:27 ` Mark Brown
2011-12-29 21:51 ` Felipe Contreras
2011-12-29 21:54 ` Mark Brown
2011-12-29 22:22 ` Måns Rullgård
2011-12-30 10:52 ` [alsa-devel] " Mark Brown
2011-12-30 11:15 ` Jarkko Nikula
2011-12-30 18:21 ` Måns Rullgård
2011-12-30 19:34 ` Måns Rullgård
2011-12-31 1:02 ` Mark Brown
2011-12-30 20:00 ` Felipe Contreras
2011-12-31 0:59 ` Mark Brown
2012-01-02 18:33 ` Felipe Contreras
2012-01-02 19:40 ` Mark Brown [this message]
2012-01-03 0:19 ` Måns Rullgård
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=20120102194046.GA14418@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=felipe.contreras@gmail.com \
--cc=jarkko.nikula@bitmer.com \
--cc=linux-omap@vger.kernel.org \
--cc=sre@debian.org \
/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).