From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown 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 Message-ID: <20120102194046.GA14418@opensource.wolfsonmicro.com> References: <20111210082741.GA32605@earth.universe> <20111229183712.GB32392@sirena.org.uk> <20111229212707.GA9737@opensource.wolfsonmicro.com> <20111229215407.GB9737@opensource.wolfsonmicro.com> <20111231005935.GA5835@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org To: Felipe Contreras Cc: Sebastian Reichel , Jarkko Nikula , linux-omap@vger.kernel.org, alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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...? =A0To repeat, the ordering of module = loading > > is totally ortogonal as any ordering of modules is supported. =A0Yo= u > > 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" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html