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?
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
- 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.
- 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
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
- 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.
- smarter way to do so?
GregKH would tell you that the smart way would be to run udev. ;-)
To use static device nodes,
- make sure that CONFIG_SND_DYNAMIC_MINORS is disabled,
- use the snddevices script in the alsa-driver package.
it works, thank U :-) miloody
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
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.
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
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).
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
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.
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
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
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
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
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
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
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
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
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
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
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
-
Clemens Ladisch -
Karl Grill -
loody -
Mark Brown -
Monty Montgomery -
Steve Calfee -
Takashi Iwai