On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Dec 30, 2011 at 10:00:55PM +0200, Felipe Contreras wrote: >> On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown >> > On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote: > >> >> >> > That should not be required, the modules should be loadable in any >> >> >> > order. > >> >> Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51. > >> > That is compltelely orthogonal to what you were saying above about the >> > ordering of module loading. > >> Not really, because if both are compiled as modules, >> snd_soc_tlv320aic3x will always be loaded first (automatically by >> udev). > > 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. 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. >> > The reason the driver is not loaded automatically is that the OMAP >> > machine drivers have not been converted to platform devices. > >> Well, if that's the case then there's a real issue. There doesn't seem >> to be a MODULE_DEPENDS(), or anything like that. > > A MODULE_DEPENDS() would also be irrelevant here. Ok. >> snd-soc-rx51 seems to depend on snd_soc_tlv320aic3x through >> codec_dai_name, and codec_name, and so on. I don't know how this >> dependency is supposed to work out. > > All the drivers should load via the normal driver instantiation > mechainsms and when they're all there they'll get matched together. Ok, I hope so. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
