It looks like snd-soc-rx51 only works as built-in, not as a module

It looks like snd-soc-rx51 only works as built-in, not as a module

[Felipe Contreras]

Hi,

Pretty much $subject. Any ideas about why?

# cat /proc/asound/cards
--- no soundcards ---

There's no error message or anything, and rx51_soc_init() exists properly.

Cheers.

-- 
Felipe Contreras

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

Hi Felipe,

Using RX51 audio as module works on 3.1 mainline kernel after loading
the following modules:

$ modprobe snd-soc-rx51
$ modprobe snd-soc-omap

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Felipe Contreras]

On Sat, Dec 10, 2011 at 10:27 AM, Sebastian Reichel <sre@debian.org> wrote:
> Using RX51 audio as module works on 3.1 mainline kernel after loading
> the following modules:
>
> $ modprobe snd-soc-rx51
> $ modprobe snd-soc-omap

It was not working for me, but it seems the problem was related to
mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.

Cheers.

-- 
Felipe Contreras

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Mark Brown]

On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote:

> It was not working for me, but it seems the problem was related to
> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.

That should not be required, the modules should be loadable in any
order.

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Felipe Contreras]

On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote:
>
>> It was not working for me, but it seems the problem was related to
>> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.
>
> That should not be required, the modules should be loadable in any
> order.

Are you sure? I recall having a similar discussion with Rusell King,
and the conclusion is that certain modules are supposed to be loaded
by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them.

-- 
Felipe Contreras

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Mark Brown]

On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote:
> On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown
> > On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote:

> >> It was not working for me, but it seems the problem was related to
> >> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.

> > That should not be required, the modules should be loadable in any
> > order.

> Are you sure? I recall having a similar discussion with Rusell King,
> and the conclusion is that certain modules are supposed to be loaded
> by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them.

I'm absolutely positive.  ASoC supports loading the modules in any
order.  udev is supposed to load anything autoloadable at boot time,
including I2C devices, but that's orthogonal to the order in which
things actually get loaded - udev can randomly reorder things if it
feels like it.

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Felipe Contreras]

On Thu, Dec 29, 2011 at 11:27 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote:
>> On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown
>> > On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote:
>
>> >> It was not working for me, but it seems the problem was related to
>> >> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.
>
>> > That should not be required, the modules should be loadable in any
>> > order.
>
>> Are you sure? I recall having a similar discussion with Rusell King,
>> and the conclusion is that certain modules are supposed to be loaded
>> by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them.
>
> I'm absolutely positive.  ASoC supports loading the modules in any
> order.  udev is supposed to load anything autoloadable at boot time,
> including I2C devices, but that's orthogonal to the order in which
> things actually get loaded - udev can randomly reorder things if it
> feels like it.

Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51.

-- 
Felipe Contreras
--
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

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Mark Brown]

On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote:
> On Thu, Dec 29, 2011 at 11:27 PM, Mark Brown
> > On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote:
> >> On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown
> >> > On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote:

> >> >> It was not working for me, but it seems the problem was related to
> >> >> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.

> >> > That should not be required, the modules should be loadable in any
> >> > order.

> >> Are you sure? I recall having a similar discussion with Rusell King,
> >> and the conclusion is that certain modules are supposed to be loaded
> >> by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them.

> > I'm absolutely positive.  ASoC supports loading the modules in any
> > order.  udev is supposed to load anything autoloadable at boot time,
> > including I2C devices, but that's orthogonal to the order in which
> > things actually get loaded - udev can randomly reorder things if it
> > feels like it.

> 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.

The reason the driver is not loaded automatically is that the OMAP
machine drivers have not been converted to platform devices.
--
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

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Måns Rullgård]

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote:
>> On Thu, Dec 29, 2011 at 11:27 PM, Mark Brown
>> > On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote:
>> >> On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown
>> >> > On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote:
>
>> >> >> It was not working for me, but it seems the problem was related to
>> >> >> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.
>
>> >> > That should not be required, the modules should be loadable in any
>> >> > order.
>
>> >> Are you sure? I recall having a similar discussion with Rusell King,
>> >> and the conclusion is that certain modules are supposed to be loaded
>> >> by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them.
>
>> > I'm absolutely positive.  ASoC supports loading the modules in any
>> > order.  udev is supposed to load anything autoloadable at boot time,
>> > including I2C devices, but that's orthogonal to the order in which
>> > things actually get loaded - udev can randomly reorder things if it
>> > feels like it.
>
>> 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.
>
> The reason the driver is not loaded automatically is that the OMAP
> machine drivers have not been converted to platform devices.

I posted patches doing the conversion a long time ago (September?).  It
seems they got lost somewhere.

-- 
Måns Rullgård
mans@mansr.com

--
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

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module

[Mark Brown]

On Thu, Dec 29, 2011 at 10:22:31PM +0000, M?ns Rullg?rd wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> > The reason the driver is not loaded automatically is that the OMAP
> > machine drivers have not been converted to platform devices.

> I posted patches doing the conversion a long time ago (September?).  It
> seems they got lost somewhere.

Most of them have been converted, but the rx51 wasn't.

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module

[Jarkko Nikula]

On 12/30/2011 12:52 PM, Mark Brown wrote:
> On Thu, Dec 29, 2011 at 10:22:31PM +0000, M?ns Rullg?rd wrote:
>> Mark Brown<broonie@opensource.wolfsonmicro.com>  writes:
>
>>> The reason the driver is not loaded automatically is that the OMAP
>>> machine drivers have not been converted to platform devices.
>
>> I posted patches doing the conversion a long time ago (September?).  It
>> seems they got lost somewhere.
>
> Most of them have been converted, but the rx51 wasn't.

I guess that patch has been forgotten. Måns: care to check and resend? 
It's definitely great to get OMAP ASoC machine driver autoloading working.

-- 
Jarkko
--
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

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module

[Måns Rullgård]

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Thu, Dec 29, 2011 at 10:22:31PM +0000, M?ns Rullg?rd wrote:
>> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>
>> > The reason the driver is not loaded automatically is that the OMAP
>> > machine drivers have not been converted to platform devices.
>
>> I posted patches doing the conversion a long time ago (September?).  It
>> seems they got lost somewhere.
>
> Most of them have been converted,

In which tree?  I haven't seen anything of the kind.

> but the rx51 wasn't.

RX51 was done in my patch...

-- 
Måns Rullgård
mans@mansr.com
--
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

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module

[Måns Rullgård]

Måns Rullgård <mans@mansr.com> writes:

> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>
>> On Thu, Dec 29, 2011 at 10:22:31PM +0000, M?ns Rullg?rd wrote:
>>> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>>
>>> > The reason the driver is not loaded automatically is that the OMAP
>>> > machine drivers have not been converted to platform devices.
>>
>>> I posted patches doing the conversion a long time ago (September?).  It
>>> seems they got lost somewhere.
>>
>> Most of them have been converted,
>
> In which tree?  I haven't seen anything of the kind.
>
>> but the rx51 wasn't.
>
> RX51 was done in my patch...

That would be this one:
http://article.gmane.org/gmane.linux.alsa.devel/89052

-- 
Måns Rullgård
mans@mansr.com
--
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

Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module

[Mark Brown]

On Fri, Dec 30, 2011 at 07:34:29PM +0000, Måns Rullgård wrote:
> Måns Rullgård <mans@mansr.com> writes:

> > In which tree?  I haven't seen anything of the kind.

The random sampling of drivers I looked at seemed to be doing something
sensible.

> That would be this one:
> http://article.gmane.org/gmane.linux.alsa.devel/89052

Oh, well.  Liam is a bit lossy sometimes.  You really need to repost
patches if they're worthwhile, don't just let them rot.
--
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

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Felipe Contreras]

On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote:
>> On Thu, Dec 29, 2011 at 11:27 PM, Mark Brown
>> > On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote:
>> >> On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown
>> >> > On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote:
>
>> >> >> It was not working for me, but it seems the problem was related to
>> >> >> mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51.
>
>> >> > That should not be required, the modules should be loadable in any
>> >> > order.
>
>> >> Are you sure? I recall having a similar discussion with Rusell King,
>> >> and the conclusion is that certain modules are supposed to be loaded
>> >> by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them.
>
>> > I'm absolutely positive.  ASoC supports loading the modules in any
>> > order.  udev is supposed to load anything autoloadable at boot time,
>> > including I2C devices, but that's orthogonal to the order in which
>> > things actually get loaded - udev can randomly reorder things if it
>> > feels like it.
>
>> 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).

> 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.

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.

Cheers.

-- 
Felipe Contreras
--
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

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Mark Brown]

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.

> > 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.

> 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.

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Felipe Contreras]

On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Mark Brown]

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

Re: It looks like snd-soc-rx51 only works as built-in, not as a module

[Måns Rullgård]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> 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.

Does this patch change anything?
http://article.gmane.org/gmane.linux.alsa.devel/89052

-- 
Måns Rullgård
mans@mansr.com
--
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