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

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

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

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

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

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