how to create alsa nodes?

how to create alsa nodes?

[loody]

Dear all:
In destop x86 system, the udev will automatically create the nodes in
snd directory, such as pcmC0D0c, pcmC0D1c, etc.
I try to let the usb sound device work on mips platform, but I have no
idea what is the proper way to create these nodes.
Should I
1. create them one by one by hand  from copying the attributes in my PC
    (if I have 2 or more usb sound devices, I have to first plug them
in pc and monitor the nodes)
2. smarter way to do so?


-- 
Regards,
miloody

Re: how to create alsa nodes?

[Clemens Ladisch]

loody wrote:
> In destop x86 system, the udev will automatically create the nodes in
> snd directory, such as pcmC0D0c, pcmC0D1c, etc.
> I try to let the usb sound device work on mips platform, but I have no
> idea what is the proper way to create these nodes.
> Should I
> 1. create them one by one by hand  from copying the attributes in my PC
>     (if I have 2 or more usb sound devices, I have to first plug them
> in pc and monitor the nodes)

This will not work if the device nodes' minor numbers are allocated
dynamically.

> 2. smarter way to do so?

GregKH would tell you that the smart way would be to run udev.  ;-)

To use static device nodes,
1) make sure that CONFIG_SND_DYNAMIC_MINORS is disabled,
2) use the snddevices script in the alsa-driver package.


Regards,
Clemens

Re: how to create alsa nodes?

[loody]

hi:

2011/3/17 Clemens Ladisch <clemens@ladisch.de>:
> loody wrote:
>> In destop x86 system, the udev will automatically create the nodes in
>> snd directory, such as pcmC0D0c, pcmC0D1c, etc.
>> I try to let the usb sound device work on mips platform, but I have no
>> idea what is the proper way to create these nodes.
>> Should I
>> 1. create them one by one by hand  from copying the attributes in my PC
>>     (if I have 2 or more usb sound devices, I have to first plug them
>> in pc and monitor the nodes)
>
> This will not work if the device nodes' minor numbers are allocated
> dynamically.
>
>> 2. smarter way to do so?
>
> GregKH would tell you that the smart way would be to run udev.  ;-)
>
> To use static device nodes,
> 1) make sure that CONFIG_SND_DYNAMIC_MINORS is disabled,
> 2) use the snddevices script in the alsa-driver package.
>
it works, thank U :-)
miloody

Connecting a codec to an i2c codec driver.

[Steve Calfee]

Hi,

I have a beagleboard xm and have a trainer board installed, so that adds another i2c bus, which with some platform tweaks I now have as /dev/i2c-2

I can use i2ctools and i2cdump my codec on that i2c bus, connected up on the platform data stuff.

I can modprobe the driver (in this case snd_soc_max98088), and no alsa "cards" or other linkages are established.

I got the i2c_probe routine to finally be called when I set the driver name to match the platform name:

static struct i2c_board_info __initdata beagle_i2c_trainer_boardinfo[] = {
	{
		I2C_BOARD_INFO("max98088", 0x10),
		.flags = I2C_CLIENT_WAKE,
		.irq = INT_34XX_SYS_NIRQ,
		.platform_data =&beagle_twldata,
	},
};

But then my max98088 probe routine was never called.

1) Is there a way to connect the i2c bus to a codec driver without having it built in the platform code?

2) What is the proper way to connect using a platform connection with multiple i2c buses and devices?

Thanks, Steve

Re: Connecting a codec to an i2c codec driver.

[Mark Brown]

On Tue, Mar 22, 2011 at 05:40:54PM -0700, Steve Calfee wrote:

You should fix your mail client to word wrap within paragraphs.

> I can modprobe the driver (in this case snd_soc_max98088), and no alsa
> "cards" or other linkages are established.

You need to write a machine driver for your board describing how the
CODEC is connected to the CPU and other components in your system.

Re: Connecting a codec to an i2c codec driver.

[Steve Calfee]

On Wed, Mar 23, 2011 at 4:07 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Mar 22, 2011 at 05:40:54PM -0700, Steve Calfee wrote:
>
> You should fix your mail client to word wrap within paragraphs.
>

Hi Mark,

I am still trying to figure out how to get thunderbird to behave, sorry.

>> I can modprobe the driver (in this case snd_soc_max98088), and no alsa
>> "cards" or other linkages are established.
>
> You need to write a machine driver for your board describing how the
> CODEC is connected to the CPU and other components in your system.
>
Great, can you give me a pointer to a sample arm source code
in the 2.6.38 kernel?

Regards, Steve

Re: Connecting a codec to an i2c codec driver.

[Mark Brown]

On Wed, Mar 23, 2011 at 06:22:59AM -0700, Steve Calfee wrote:
> On Wed, Mar 23, 2011 at 4:07 AM, Mark Brown

> > You need to write a machine driver for your board describing how the
> > CODEC is connected to the CPU and other components in your system.

> Great, can you give me a pointer to a sample arm source code
> in the 2.6.38 kernel?

There are *many* example machine drivers under sound/soc.  Look for a
driver for a machine relevant to your CPU (eg, a reference board).

Re: Connecting a codec to an i2c codec driver.

[Steve Calfee]

On 03/23/11 06:30, Mark Brown wrote:
> On Wed, Mar 23, 2011 at 06:22:59AM -0700, Steve Calfee wrote:
>> On Wed, Mar 23, 2011 at 4:07 AM, Mark Brown
>
>>> You need to write a machine driver for your board describing how the
>>> CODEC is connected to the CPU and other components in your system.
>
>> Great, can you give me a pointer to a sample arm source code
>> in the 2.6.38 kernel?
>
> There are *many* example machine drivers under sound/soc.  Look for a
> driver for a machine relevant to your CPU (eg, a reference board).

Thanks, that helps.

Any tips on how to turn on the debug printouts in the alsa and device 
systems? Do I recompile the kernel with new options etc? I already 
lowered the /proc/sys/kernel/printk level to 8.

Regards, Steve

Re: Connecting a codec to an i2c codec driver.

[Mark Brown]

On Thu, Mar 24, 2011 at 12:56:27PM -0700, Steve Calfee wrote:

> Any tips on how to turn on the debug printouts in the alsa and
> device systems? Do I recompile the kernel with new options etc? I
> already lowered the /proc/sys/kernel/printk level to 8.

Add #define DEBUG at the top of the source file to turn dev_dbg() on by
default.

emi62 (may be slightly off-topic)

[Karl Grill]

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

Hi all,
I'm not quite sure if this is really on-topic as the emi62 loader is not
in alsa-driver. On the other hand, the patch is small (changing only two
bytes in the sources, one in  the binary - as a matter of fact, I fixed
the driver for myself by directly patching the binary), so I'll attach
it here (against the alsa-kernel tree). The driver has been broken since
kernel 2.6.27 (http://xiphmont.livejournal.com/46858.html).
BTW, the firmware for both the 6|2m and the 2|6 in the alsa-firmware
package are in the wrong format (the kernel drivers don't work with raw
binaries but with the binary ihex .fw format), and it is installed in
the wrong place. This may create some confusion - it did so for me. As
the mainstream linux kernel already contains the proper firmware, it
might be the best solution to remove the emi_26_62 stuff altogether.

Regards
Karl


[-- Attachment #2: 0001-emi62-fix.patch --]
[-- Type: text/x-patch, Size: 863 bytes --]

>From 850dfc9bd36b4d76d3bd4279028dd74bc3d7e170 Mon Sep 17 00:00:00 2001
From: Karl Grill <kgrill@chello.at>
Date: Sun, 10 Feb 2013 20:27:25 +0100
Subject: [PATCH] emi62-fix
 fix firmware loading for emi6|2m (was broken since 2.6.27)


Signed-off-by: Karl Grill <kgrill@chello.at>
---
 drivers/usb/misc/emi62.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/misc/emi62.c b/drivers/usb/misc/emi62.c
index ae794b9..4e94b60 100644
--- a/drivers/usb/misc/emi62.c
+++ b/drivers/usb/misc/emi62.c
@@ -197,7 +197,7 @@ static int emi62_load_firmware (struct usb_device *dev)
 		if (INTERNAL_RAM(be32_to_cpu(rec->addr))) {
 			err = emi62_writememory(dev, be32_to_cpu(rec->addr),
 						rec->data, be16_to_cpu(rec->len),
-						ANCHOR_LOAD_EXTERNAL);
+						ANCHOR_LOAD_INTERNAL);
 			if (err < 0)
 				goto wraperr;
 		}
-- 
1.7.2.5


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: emi62 (may be slightly off-topic)

[Takashi Iwai]

At Tue, 12 Feb 2013 09:17:54 +0100,
Karl Grill wrote:
> 
> Hi all,
> I'm not quite sure if this is really on-topic as the emi62 loader is not
> in alsa-driver. On the other hand, the patch is small (changing only two
> bytes in the sources, one in  the binary - as a matter of fact, I fixed
> the driver for myself by directly patching the binary), so I'll attach
> it here (against the alsa-kernel tree). The driver has been broken since
> kernel 2.6.27 (http://xiphmont.livejournal.com/46858.html).

Could you resend the patch to usb-devel ML instead?
They are responsible for that path.

> BTW, the firmware for both the 6|2m and the 2|6 in the alsa-firmware
> package are in the wrong format (the kernel drivers don't work with raw
> binaries but with the binary ihex .fw format), and it is installed in
> the wrong place. This may create some confusion - it did so for me. As
> the mainstream linux kernel already contains the proper firmware, it
> might be the best solution to remove the emi_26_62 stuff altogether.

Fair enough, I'll remove it from alsa-firmware.


thanks,

Takashi

Re: emi62 (may be slightly off-topic)

[Monty Montgomery]

The in-kernel firmware loaders are also completely broken right now
due to the movement of the loader to userspace causing a deadlock in
the load process.  systemd tries to probe the USB topology when
handling the firmware request, but the current loader is synchronous,
so each blocks on the other.

I wrote a complete, new unified emi26/26 loader last year... and it
got bogged down in 'what is the license on the firmware anyway?' like
it has for all the submissions I've made regarding the 26/62 in the
past five years :-(

If you want just the loader and/or firmware update patches (we're also
shipping an unreleased alpha of the firmware IIRC, and there are
numerous bugs later releases fixed. Oh and they add 96kHz support),
write me.  I've been using the most recent version for the past year
wihthout problems.

Oh, actually, there is one problem, but it's not the loader:
disconnecting a device in use now hangs the entire USB subsystem until
reboot about 50% of the time, but that bug is there with the old
loader too.

Monty

Re: emi62 (may be slightly off-topic)

[Monty Montgomery]

On Fri, Feb 15, 2013 at 10:28 AM, Monty Montgomery <xiphmont@gmail.com> wrote:
> The in-kernel firmware loaders are also completely broken right now
> due to the movement of the loader to userspace causing a deadlock in
> the load process.

Sorry, let me be more clear there; it is now the responsibility of
systemd to find and return firmware when the in-kernel loader makes a
firmware request.  Unfortunately, systemd can't resist firing off
several 'learn everything we can about this device!' threads when the
firmware request comes in, and if one of them hits the USB bus blocked
in probe() waiting for firmware before the firmware request is
fufilled (this happens much of the time) the load request deadlocks.
It will time out in ~20s, and then the process repeats through several
retries before finally failing.

The solution is a loader that makes an asynchronous firmware request
in probe and handles the response in a callback, which is what my new
loader did/does.

Also: I'm happy to resubmit the code, but I'm not interested in trying
to chase down all the licensing information for the firmware as Tapio
has disappeared and eMagic is no more.  As far as I know, we never had
anything but Tapio's word that we had permission to ship any version
of firmware.  I'd rather just see the driver pulled from the kernel
(after all, it hasn't worked in years), and distribute modules by hand
as an individual to the last remaining eMagic people, than deal with
the red tape.

Monty

Re: emi62 (may be slightly off-topic)

[Takashi Iwai]

At Fri, 15 Feb 2013 10:37:07 -0500,
Monty Montgomery wrote:
> 
> On Fri, Feb 15, 2013 at 10:28 AM, Monty Montgomery <xiphmont@gmail.com> wrote:
> > The in-kernel firmware loaders are also completely broken right now
> > due to the movement of the loader to userspace causing a deadlock in
> > the load process.
> 
> Sorry, let me be more clear there; it is now the responsibility of
> systemd to find and return firmware when the in-kernel loader makes a
> firmware request.  Unfortunately, systemd can't resist firing off
> several 'learn everything we can about this device!' threads when the
> firmware request comes in, and if one of them hits the USB bus blocked
> in probe() waiting for firmware before the firmware request is
> fufilled (this happens much of the time) the load request deadlocks.
> It will time out in ~20s, and then the process repeats through several
> retries before finally failing.
> 
> The solution is a loader that makes an asynchronous firmware request
> in probe and handles the response in a callback, which is what my new
> loader did/does.

Do you still have the patch for async load?  The fix patch on the blog
entry isn't that.

The recent kernel switched the firmware loading in kernel without udev
(it might be still used as fallback, though), thus udev is no longer a
problem.  But the bus-blocking behavior will be still an issue.

> Also: I'm happy to resubmit the code, but I'm not interested in trying
> to chase down all the licensing information for the firmware as Tapio
> has disappeared and eMagic is no more.  As far as I know, we never had
> anything but Tapio's word that we had permission to ship any version
> of firmware.  I'd rather just see the driver pulled from the kernel
> (after all, it hasn't worked in years), and distribute modules by hand
> as an individual to the last remaining eMagic people, than deal with
> the red tape.

Yeah, the license issue about such firmware files is horrible.
It's one of the reasons that the firmware went out of kernel tree.


thanks,

Takashi

Re: emi62 (may be slightly off-topic)

[Monty Montgomery]

> Do you still have the patch for async load?

Oh yes.  I should check it against 3.7

And for the record, it's a complete new loader, one module for both
eMagic boxes,  so the patch consists of removing several files and
adding new ones.

> The fix patch on the blog
> entry isn't that.

Correct. There were other [minor] problems in the old loader, but
without fixing the deadlock, it's all sort of moot.  Also, the 6|2
loader is currently trying to use firmware for some other device--
it's not 6|2 firmware.  if you do succeed in loading what's currently
shipping, the device simply crashes.

So, I came to the conclusion a few years ago i was the last person
using eMagic boxes (though people since then have sent me mail for the
driver, so I know that's not quite true).

Monty

Re: emi62 (may be slightly off-topic)

[Takashi Iwai]

At Fri, 15 Feb 2013 11:14:46 -0500,
Monty Montgomery wrote:
> 
> > Do you still have the patch for async load?
> 
> Oh yes.  I should check it against 3.7
> 
> And for the record, it's a complete new loader, one module for both
> eMagic boxes,  so the patch consists of removing several files and
> adding new ones.

This makes more sense, indeed.

> > The fix patch on the blog
> > entry isn't that.
> 
> Correct. There were other [minor] problems in the old loader, but
> without fixing the deadlock, it's all sort of moot.  Also, the 6|2
> loader is currently trying to use firmware for some other device--
> it's not 6|2 firmware.  if you do succeed in loading what's currently
> shipping, the device simply crashes.
> 
> So, I came to the conclusion a few years ago i was the last person
> using eMagic boxes (though people since then have sent me mail for the
> driver, so I know that's not quite true).

Or people just had used the old kernel :)


Takashi

Re: emi62 (may be slightly off-topic)

[Monty Montgomery]

Karl just reminded me that I never sent a link to my up-to-date out of
tree eMagic driver update.  Here's the latest version:

http://people.xiph.org/~xiphmont/emagic/emi-20131209.tgz

This includes the latest/correct firmware for the 2|6 and 6|2m (not
the same as shipped in the kernel).  It builds a single emi.ko that
functions as a loader for both devices.
There's the usual make and make install target, as well as a
'remove-old' target that kills off the old installed firmware and
emi26/62 modules.

The Makefile is a bit slapdash, hopefully it doesn't misbehave.

I've mentioned it before, but the current in-kernel loader (and
official firmware) are both outright broken. I'm happy enough to
maintain this out of kernel (since there were objections to updating
the firmware), but the in-tree / mainline stuff should be either
updated or removed.  It simply doesn't work.

Monty

On Fri, Feb 15, 2013 at 11:26 AM, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 15 Feb 2013 11:14:46 -0500,
> Monty Montgomery wrote:
>>
>> > Do you still have the patch for async load?
>>
>> Oh yes.  I should check it against 3.7
>>
>> And for the record, it's a complete new loader, one module for both
>> eMagic boxes,  so the patch consists of removing several files and
>> adding new ones.
>
> This makes more sense, indeed.
>
>> > The fix patch on the blog
>> > entry isn't that.
>>
>> Correct. There were other [minor] problems in the old loader, but
>> without fixing the deadlock, it's all sort of moot.  Also, the 6|2
>> loader is currently trying to use firmware for some other device--
>> it's not 6|2 firmware.  if you do succeed in loading what's currently
>> shipping, the device simply crashes.
>>
>> So, I came to the conclusion a few years ago i was the last person
>> using eMagic boxes (though people since then have sent me mail for the
>> driver, so I know that's not quite true).
>
> Or people just had used the old kernel :)
>
>
> Takashi

Re: emi62 (may be slightly off-topic)

[Takashi Iwai]

At Tue, 10 Dec 2013 19:04:22 -0500,
Monty Montgomery wrote:
> 
> Karl just reminded me that I never sent a link to my up-to-date out of
> tree eMagic driver update.  Here's the latest version:
> 
> http://people.xiph.org/~xiphmont/emagic/emi-20131209.tgz
> 
> This includes the latest/correct firmware for the 2|6 and 6|2m (not
> the same as shipped in the kernel).  It builds a single emi.ko that
> functions as a loader for both devices.
> There's the usual make and make install target, as well as a
> 'remove-old' target that kills off the old installed firmware and
> emi26/62 modules.
> 
> The Makefile is a bit slapdash, hopefully it doesn't misbehave.
> 
> I've mentioned it before, but the current in-kernel loader (and
> official firmware) are both outright broken. I'm happy enough to
> maintain this out of kernel (since there were objections to updating
> the firmware), but the in-tree / mainline stuff should be either
> updated or removed.  It simply doesn't work.

Monty, would you submit the emi driver patch to upstream?  We can keep
the old EMI26 and EMI62 at first but make them conflicting with EMI
driver via Kconfig.  The external firmware files are maintained in
linux-firmware tree nowadays.  Once all things get merged, the old
emi26/62 can be faded away.

Looking through the tarball and codes, my only concern is the license
of the new firmware files...


thanks,

Takashi

Re: emi62 (may be slightly off-topic)

[Monty Montgomery]

> Monty, would you submit the emi driver patch to upstream?

It's been a few years since I've submitted a patch.  Last I tried,
upstream seriously frowned on any sort of 'I wrote a whole new driver'
type patches. But I'm happy to try if you think it would go through.

>  We can keep
> the old EMI26 and EMI62 at first but make them conflicting with EMI
> driver via Kconfig.  The external firmware files are maintained in
> linux-firmware tree nowadays.  Once all things get merged, the old
> emi26/62 can be faded away.

Sure, that sounds perfectly sensible.

> Looking through the tarball and codes, my only concern is the license
> of the new firmware files...

Yes, that's what has always been problematic in the past.  I see
there's at least a patch now to restore it to the state it was in in
early 2.6 when it worked but was just outdated.

That said, I don't want to go through this yet again where one problem
gets fixed, everyone gets bogged down in arguing over the rest, and
that's the state things stay in.  That's where eMagic support has been
since roughly 2008.  If we're not going to fix it all, and fix it for
real, I'd honestly rather not bother.  No more partial solutions when
the complete solution is already right here.

So before submitting a patch, I'd like to secure agreement over the
firmware update from whomever needs to commit.  Who would that be?  If
we can agree on that, I'm in for the rest.

I mean, it's not like we have explicit permission to distribute the
firmware we're shipping now. :-P

Cheers,
Monty

Re: emi62 (may be slightly off-topic)

[Takashi Iwai]

At Thu, 12 Dec 2013 02:32:13 -0500,
Monty Montgomery wrote:
> 
> > Monty, would you submit the emi driver patch to upstream?
> 
> It's been a few years since I've submitted a patch.  Last I tried,
> upstream seriously frowned on any sort of 'I wrote a whole new driver'
> type patches. But I'm happy to try if you think it would go through.

I guess merging this code shouldn't be difficult.  Of course, it'd be
better to fix trivial coding style issues scripts/checkpatch.pl
complains beforehand (and also avoid typedefs).  Once when ready, I
can give my reviewed-by tag, which will make the upstream merge
easier.

> >  We can keep
> > the old EMI26 and EMI62 at first but make them conflicting with EMI
> > driver via Kconfig.  The external firmware files are maintained in
> > linux-firmware tree nowadays.  Once all things get merged, the old
> > emi26/62 can be faded away.
> 
> Sure, that sounds perfectly sensible.

FWIW, a patch would be like below:

-- 8< --
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -4,7 +4,8 @@
 comment "USB Miscellaneous drivers"
 
 config USB_EMI62
-	tristate "EMI 6|2m USB Audio interface support"
+	tristate "EMI 6|2m USB Audio interface support (deprecated)"
+	depends on !USB_EMI
 	---help---
 	  This driver loads firmware to Emagic EMI 6|2m low latency USB
 	  Audio and Midi interface.
@@ -18,7 +19,8 @@ config USB_EMI62
 	  module, say M here and read <file:Documentation/kbuild/modules.txt>.
 
 config USB_EMI26
-	tristate "EMI 2|6 USB Audio interface support"
+	tristate "EMI 2|6 USB Audio interface support (deprecated)"
+	depends on !USB_EMI
 	---help---
 	  This driver loads firmware to Emagic EMI 2|6 low latency USB
 	  Audio interface.
-- 8< --

> > Looking through the tarball and codes, my only concern is the license
> > of the new firmware files...
> 
> Yes, that's what has always been problematic in the past.  I see
> there's at least a patch now to restore it to the state it was in in
> early 2.6 when it worked but was just outdated.
> 
> That said, I don't want to go through this yet again where one problem
> gets fixed, everyone gets bogged down in arguing over the rest, and
> that's the state things stay in.  That's where eMagic support has been
> since roughly 2008.  If we're not going to fix it all, and fix it for
> real, I'd honestly rather not bother.  No more partial solutions when
> the complete solution is already right here.
> 
> So before submitting a patch, I'd like to secure agreement over the
> firmware update from whomever needs to commit.  Who would that be?  If
> we can agree on that, I'm in for the rest.

The linux-firmware tree is maintained by Ben Hutchings
<ben@decadent.org.uk>.

Of course, another option would be to distribute from other places.
For example, ALSA still keeps some firmware files in alsa-firmware
package because of their strange license condition.

> I mean, it's not like we have explicit permission to distribute the
> firmware we're shipping now. :-P

Yeah, but the license issue is always picky (especially some people
are), so I won't be surprised even if they won't land to
linux-firmware tree but be distributed from somewhere else...


thanks,

Takashi