[alsa-devel] EMU-1212m "no Audiodock - no firmware" patch
Aloha!
i've been posting about my problem earlier, but i decided to DIY
the problem was that when going up from suspend the firmware for additional card (that i don't have) was trying to load, -but there's no card - sorry, i'm gonna check few more thousand times that caused my cpu to load insanely
so in the patch i've changed few more strings for debugging
but actually the one (but not the only) bug is here
*** 728,739 ****
! if (reg & EMU_HANA_OPTION_DOCK_OFFLINE) {
--- 729,740 ----
! if (reg & !EMU_HANA_OPTION_DOCK_OFFLINE) {
the thing is in the "!"EMU_HANA_OPTION_DOCK_OFFLINE -> then the firmware should be loaded.
and to debug some errors if something i've put the one more else state so if no audiodock - it could continue to load config
*** 777,784 **** /* Unmute all. Default is muted after a firmware load */ snd_emu1010_fpga_write(emu, EMU_HANA_UNMUTE, EMU_UNMUTE); } } ! snd_printk(KERN_INFO "emu1010: firmware thread stopping\n"); return 0; }
--- 778,790 ---- /* Unmute all. Default is muted after a firmware load */ snd_emu1010_fpga_write(emu, EMU_HANA_UNMUTE, EMU_UNMUTE); } + else if ((reg & 0x3f) == 0x15) + { + snd_printk(KERN_INFO "emu1212m: trying to load config emu_hana_fpga_config"); + snd_emu1010_fpga_write(emu, EMU_HANA_FPGA_CONFIG,0x02); + } } ! snd_printk(KERN_INFO "emu1010: emu dock firmware thread stopping\n"); return 0; }
***************
then i've commented the power_down for audiodock - it should be in other place, but as i'm 1212m user - it works for me - you know.
*** 841,847 **** outl(0x0005a000, emu->port + HCFG);
/* Disable 48Volt power to Audio Dock */ ! snd_emu1010_fpga_write(emu, EMU_HANA_DOCK_PWR, 0);
/* ID, should read & 0x7f = 0x55. (Bit 7 is the IRQ bit) */ snd_emu1010_fpga_read(emu, EMU_HANA_ID, ®); --- 847,853 ---- outl(0x0005a000, emu->port + HCFG);
/* Disable 48Volt power to Audio Dock */ ! /*snd_emu1010_fpga_write(emu, EMU_HANA_DOCK_PWR, 0);*/
/* ID, should read & 0x7f = 0x55. (Bit 7 is the IRQ bit) */ snd_emu1010_fpga_read(emu, EMU_HANA_ID, ®); ***************
and here i've changed that the emu_model was firstly enabled and then ecard - since i don't know what's the ecard i thought that it is a second module of my emu card.
*** 2079,2088 **** { if (emu->card_capabilities->ca_cardbus_chip) snd_emu10k1_cardbus_init(emu); ! if (emu->card_capabilities->ecard) ! snd_emu10k1_ecard_init(emu); ! else if (emu->card_capabilities->emu_model) snd_emu10k1_emu1010_init(emu); else snd_emu10k1_ptr_write(emu, AC97SLOT, 0, AC97SLOT_CNTR|AC97SLOT_LFE); snd_emu10k1_init(emu, emu->enable_ir, 1); --- 2098,2111 ---- { if (emu->card_capabilities->ca_cardbus_chip) snd_emu10k1_cardbus_init(emu); ! ! if (emu->card_capabilities->emu_model) ! { snd_emu10k1_emu1010_init(emu); + + } + else if (emu->card_capabilities->ecard) + snd_emu10k1_ecard_init(emu); else snd_emu10k1_ptr_write(emu, AC97SLOT, 0, AC97SLOT_CNTR|AC97SLOT_LFE); snd_emu10k1_init(emu, emu->enable_ir, 1);
Now i still have the problem of waking up i cannot request_firmware() properly on resume and it is trying to load nothing and other changes in patch - that was trying to debug the situation so i can at least alsa-reload at anytime. also i'd like to ask if i can use the ctxfi modules - CA0110-IBG i got xfi card (it is second of 5) that actually uses as i believe the same logic - maybe a lil modified, but not so much imho.
At Thu, 22 Nov 2012 02:18:47 +0400, oeai wrote:
Aloha!
i've been posting about my problem earlier, but i decided to DIY
the problem was that when going up from suspend the firmware for additional card (that i don't have) was trying to load, -but there's no card
- sorry, i'm gonna check few more thousand times
that caused my cpu to load insanely
Right now I fixed a few bugs regarding the firmware loading. It should have been improved by that. Take a look at my recent posts [PATCH 7/8] ALSA: emu10k1: cache emu1010 firmware and [PATCH 8/8] ALSA: emu10k1: don't update firmware during suspend/resume
so in the patch i've changed few more strings for debugging
but actually the one (but not the only) bug is here
*** 728,739 ****
! if (reg & EMU_HANA_OPTION_DOCK_OFFLINE) {
--- 729,740 ----
! if (reg & !EMU_HANA_OPTION_DOCK_OFFLINE) {
the thing is in the "!"EMU_HANA_OPTION_DOCK_OFFLINE -> then the firmware should be loaded.
and to debug some errors if something i've put the one more else state so if no audiodock - it could continue to load config
*** 777,784 **** /* Unmute all. Default is muted after a firmware load */ snd_emu1010_fpga_write(emu, EMU_HANA_UNMUTE, EMU_UNMUTE); } } ! snd_printk(KERN_INFO "emu1010: firmware thread stopping\n"); return 0; }
--- 778,790 ---- /* Unmute all. Default is muted after a firmware load */ snd_emu1010_fpga_write(emu, EMU_HANA_UNMUTE, EMU_UNMUTE); }
else if ((reg & 0x3f) == 0x15){snd_printk(KERN_INFO "emu1212m: trying to load config emu_hana_fpga_config");snd_emu1010_fpga_write(emu, EMU_HANA_FPGA_CONFIG,0x02);}! snd_printk(KERN_INFO "emu1010: emu dock firmware thread stopping\n"); return 0; }
then i've commented the power_down for audiodock - it should be in other place, but as i'm 1212m user - it works for me - you know.
*** 841,847 **** outl(0x0005a000, emu->port + HCFG);
/* Disable 48Volt power to Audio Dock */! snd_emu1010_fpga_write(emu, EMU_HANA_DOCK_PWR, 0);
/* ID, should read & 0x7f = 0x55. (Bit 7 is the IRQ bit) */ snd_emu1010_fpga_read(emu, EMU_HANA_ID, ®);--- 847,853 ---- outl(0x0005a000, emu->port + HCFG);
/* Disable 48Volt power to Audio Dock */! /*snd_emu1010_fpga_write(emu, EMU_HANA_DOCK_PWR, 0);*/
/* ID, should read & 0x7f = 0x55. (Bit 7 is the IRQ bit) */ snd_emu1010_fpga_read(emu, EMU_HANA_ID, ®);
Hmm. It's because you have no dock? What happens if you don't change this?
and here i've changed that the emu_model was firstly enabled and then ecard - since i don't know what's the ecard i thought that it is a second module of my emu card.
This should be harmless. ecard is set only to Emu APS card, and exclusive with EMU 1x1x & co.
What are other essentially required changes?
Do both Emu1010b and Emu1212 have the same PCI SSID? That sucks. I see you set ca_cardbus_chip=1 in the card entry. Is it mandatory?
Last but not least, please use "diff -up" for creating a patch in the unified diff format.
thanks,
Takashi
On 22.11.2012 21:17, Takashi Iwai wrote:
Right now I fixed a few bugs regarding the firmware loading. It should have been improved by that. Take a look at my recent posts [PATCH 7/8] ALSA: emu10k1: cache emu1010 firmware and [PATCH 8/8] ALSA: emu10k1: don't update firmware during suspend/resume
thanks, i'll try to find it and check, aren't they included yet? i just don't know actually how to find some specific threads here actually
so in the patch i've changed few more strings for debugging
Hmm. It's because you have no dock? What happens if you don't change this?
well the firmware is trying to load it endlessly and my cpu loads at 100% but it loads only 1 core so that was not so much worse for me
and here i've changed that the emu_model was firstly enabled and then ecard - since i don't know what's the ecard is, i thought that it is a second module of my emu card.
This should be harmless. ecard is set only to Emu APS card, and exclusive with EMU 1x1x & co.
- well this card i think that i got and it depends on loading the first part of E-MU as i think kinda a second part, so that's why i decided to load it a little later. i can find you a picture of the card it is providing IN OUT analog
What are other essentially required changes?
well i've changed emufx and other file because they were loading some libs and sliders that are not really needed by the emu_model
Do both Emu1010b and Emu1212 have the same PCI SSID? That sucks. I see you set ca_cardbus_chip=1 in the card entry. Is it mandatory?
i think that the cardbus is related to that ecard and yes it looks like they are the same when i
lspci -s 07:05.0 -nn 07:05.0 Multimedia audio controller [0401]: Creative Labs SB0400 Audigy2 Value [1102:0008] i don't know how to set the subsystem
Last but not least, please use "diff -up" for creating a patch in the unified diff format.
thanks,
Takashi
i've attached diff -u of all changes that i've made and in second reply i've put the dar.bz2 file with all changed files (not sure if it is on the deck) so i'll send it to you too.
i've tried to reply on my own thread today but i don't see the answer, so i ll dulicate a message for you
===================== ================================== ===========================
ALoha!
i continued to make -j4 all night long and all day passed through
so now the emu-1212m is working, i've changed some pieces of code - the diff file is only 30kb but some people don't know how to do that, so i\ll describe a process of compiling well there's still the bug of getting back from suspend state, but at least it is loading and i've described a bug with emu-firmware, so now all you need in case you are using suspend or maybe sllep mode (i didn't test hibernate too) just do "alsa reload" - if you decide to work on project. i've setted the adc_1361t something and it says that you can use the 24bits of capturing - well, all other was just to disable some audiodock commands if no audiodock is installed in system, i've moved some tweaks to load_patches function, reorganized some bits, and set few states that no need to load ac97 chipset sliders into the main window - that was awful. i'm thinking of binding some buttons and new volume sliders for DSP and capture channels, but it is all can simply be routed through @jack, so i'm gonna play some guitar finally at last!
i've changed not so much of a lot of things - but the good news - it is working!
so if you own emu-1212m you can take the dar.bz , download sources 1.0.25 from alsa-project unbzip it to the directory and enter it, then run next commands
"./configure && make -j4"
the compile process takes about 2-10mins -j4 means multithreading so you should set the number as many cores got your CPU then go to directory where the emu*.dar.bz2 downloaded run "bzip2 -x ./emu*bz2" you need to "apt-get install dar" or check the rpm package "dar -x ./emu*dar" press enter when it ask something then open mc and put files in next directories assuming the root dir is an alsa sources alsa-xxxx /pci/emu10k1/ - you'll emu10k1_main.c there copy 1 file here and delete emupmx.o and emufx.o files the others 2 copy into /alsa-kernel/pci/emu10k1/ then go to alsa-xxxx dir and run "make -j4" again then again run "alsa unload" make sure that emu10k1 unloaded, you should stop all jackd and any alsa mixers should be unloaded you can try "rmmod emu10k1" (-f - force)- it will show you maybe something then run "make install && modprobe snd-emu10k1" "alsa reload"
- ok now you can try to open the device!!!
i'm using QasMixer for alsa so you will find there DSP 0,1 - Silence - Change it to 0202 ADC Left+Right And the ADC0 -14dB PAD 0202 - is a GAIN XP button $ ) so you are ready to capture.
well it is working and that's more then enough i've debugged one superbug so now it's ok =))
Английский понимают многие люди и наверняка те, кто умеет ковыряться в линуксе - понимают и то? что ai написал =))
-- RA OE AI
=========================== ============================= ====================================
At Fri, 23 Nov 2012 00:09:37 +0400, oeai wrote:
On 22.11.2012 21:17, Takashi Iwai wrote:
Right now I fixed a few bugs regarding the firmware loading. It should have been improved by that. Take a look at my recent posts [PATCH 7/8] ALSA: emu10k1: cache emu1010 firmware and [PATCH 8/8] ALSA: emu10k1: don't update firmware during suspend/resume
thanks, i'll try to find it and check, aren't they included yet? i just don't know actually how to find some specific threads here actually
At best, check sound git tree for-next branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
so in the patch i've changed few more strings for debugging
Hmm. It's because you have no dock? What happens if you don't change this?
well the firmware is trying to load it endlessly and my cpu loads at 100% but it loads only 1 core so that was not so much worse for me
Does the firmware load happen all the time soon after loading the driver, or in certain situations?
and here i've changed that the emu_model was firstly enabled and then ecard - since i don't know what's the ecard is, i thought that it is a second module of my emu card.
This should be harmless. ecard is set only to Emu APS card, and exclusive with EMU 1x1x & co.
- well this card i think that i got and it depends on loading the first
part of E-MU as i think kinda a second part, so that's why i decided to load it a little later. i can find you a picture of the card it is providing IN OUT analog
Emu APS code is very much irrelevant with your card. So, don't add it.
What are other essentially required changes?
well i've changed emufx and other file because they were loading some libs and sliders that are not really needed by the emu_model
OK, but this is a clean up instead of a fix. Let's postpone it. Once after the device gets work stably, we can look back.
Do both Emu1010b and Emu1212 have the same PCI SSID? That sucks. I see you set ca_cardbus_chip=1 in the card entry. Is it mandatory?
i think that the cardbus is related to that ecard and yes it looks like they are the same when i
lspci -s 07:05.0 -nn 07:05.0 Multimedia audio controller [0401]: Creative Labs SB0400 Audigy2 Value [1102:0008] i don't know how to set the subsystem
The PCI SSID is set by the card itself, so this must be really a conflict with another existing card (emu1010b). That's bad.
The primary question is whether ca_cardbus_chip = 1 is mandatory. What happens if you don't set it?
Last but not least, please use "diff -up" for creating a patch in the unified diff format.
thanks,
Takashi
i've attached diff -u of all changes that i've made and in second reply i've put the dar.bz2 file with all changed files (not sure if it is on the deck) so i'll send it to you too.
i've tried to reply on my own thread today but i don't see the answer, so i ll dulicate a message for you
Did you subscribe to ML? It's a moderated list, so you have to subscribe at first.
Also, alsa-driver 1.0.25 is pretty old. Try the latest snapshot tarball instead ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz
thanks,
Takashi
On 23.11.2012 15:23, Takashi Iwai wrote:
At Fri, 23 Nov 2012 00:09:37 +0400, oeai wrote:
At best, check sound git tree for-next branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
o k i ll try to diff it with my fix and original just in some later time - i'm writing music now, srry i want to create more sounds in few days, i've already spent 2 days on programming and debugging alot and btw hows it works? what to do with git? i got own git in netbeans but still don't know how to use it more easy (maybe i'll it later) ok git clone - just right now, so i'll check it do i need to get from latest snapshot?
Does the firmware load happen all the time soon after loading the driver, or in certain situations?
- yep it was always when i was gettin out of suspend or reboot, with my fix it is not happening anymore but you need to ask some1 with audiodock to check if "!" is working
Emu APS code is very much irrelevant with your card. So, don't add it.
found it, ok i'll try to rem it and see what happens, but for me it is working right now when it is enabled and as i seen it it notebook i thought that it is similar to mine (there was a pcmcia version with audiodock-m so i think 1212 is a next gen of ecard)
What are other essentially required changes?
well i've changed emufx and other file because they were loading some libs and sliders that are not really needed by the emu_model
OK, but this is a clean up instead of a fix. Let's postpone it. Once after the device gets work stably, we can look back.
no it's not a clean up, i've really fixed the code check the .patch diff for other files i've set if (not emu_model){exec ac97 and spk71}
The PCI SSID is set by the card itself, so this must be really a conflict with another existing card (emu1010b). That's bad.
The primary question is whether ca_cardbus_chip = 1 is mandatory. What happens if you don't set it?
well i'm not really sure, i don't like to reboot system everyweek, my last uptime was 23 days but because of the driver - it's changed and i had freezes few times when trying to wakeup the system and exec load firmware some other ways.
actually i need to know what is the ca_cardbus is ? and then see the code to check when it is loading and which registers needs to be checked.
Did you subscribe to ML? It's a moderated list, so you have to subscribe at first.
Also, alsa-driver 1.0.25 is pretty old. Try the latest snapshot tarball instead ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz
thanks,
Takashi
yes, i'm subscribed and i was looking for latest drivers few times but the problem is that i'm banned as a tor-exit-node, so i've disabled tor, but still cannot access few sites - i cannot go to https://alsa.ftp for example, so i've take some that i could, looks like i'll have to check all changes again?
================ goingto man diff then crazy
Can I help at all? I don't have much time spare, but I do have datasheets for some EMU cards. The PCMCIA/Cardbus versions need a special startup sequence before you can write or read any other registers. Failing to follow the startup sequence causes a PCI fault on the bus when you write to other registers on the card. I have not read the code recently, but I think that is what "ca_cardbus_chip = 1". For any new cards, you can try removing it, and if you get a PCI fault or hang on start up, put it back in.
On 23 November 2012 11:23, Takashi Iwai tiwai@suse.de wrote:
At Fri, 23 Nov 2012 00:09:37 +0400, oeai wrote:
On 22.11.2012 21:17, Takashi Iwai wrote:
Right now I fixed a few bugs regarding the firmware loading. It should have been improved by that. Take a look at my recent posts [PATCH 7/8] ALSA: emu10k1: cache emu1010 firmware and [PATCH 8/8] ALSA: emu10k1: don't update firmware during suspend/resume
thanks, i'll try to find it and check, aren't they included yet? i just don't know actually how to find some specific threads here actually
At best, check sound git tree for-next branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
so in the patch i've changed few more strings for debugging
Hmm. It's because you have no dock? What happens if you don't change this?
well the firmware is trying to load it endlessly and my cpu loads at 100% but it loads only 1 core so that was not so much worse for me
Does the firmware load happen all the time soon after loading the driver, or in certain situations?
and here i've changed that the emu_model was firstly enabled and then ecard - since i don't know what's the ecard is, i thought that it is a second module of my emu card.
This should be harmless. ecard is set only to Emu APS card, and exclusive with EMU 1x1x & co.
- well this card i think that i got and it depends on loading the first
part of E-MU as i think kinda a second part, so that's why i decided to load it a little later. i can find you a picture of the card it is providing IN OUT analog
Emu APS code is very much irrelevant with your card. So, don't add it.
What are other essentially required changes?
well i've changed emufx and other file because they were loading some libs and sliders that are not really needed by the emu_model
OK, but this is a clean up instead of a fix. Let's postpone it. Once after the device gets work stably, we can look back.
Do both Emu1010b and Emu1212 have the same PCI SSID? That sucks. I see you set ca_cardbus_chip=1 in the card entry. Is it mandatory?
i think that the cardbus is related to that ecard and yes it looks like they are the same when i
lspci -s 07:05.0 -nn 07:05.0 Multimedia audio controller [0401]: Creative Labs SB0400 Audigy2 Value [1102:0008] i don't know how to set the subsystem
The PCI SSID is set by the card itself, so this must be really a conflict with another existing card (emu1010b). That's bad.
The primary question is whether ca_cardbus_chip = 1 is mandatory. What happens if you don't set it?
Last but not least, please use "diff -up" for creating a patch in the unified diff format.
thanks,
Takashi
i've attached diff -u of all changes that i've made and in second reply i've put the dar.bz2 file with all changed files (not sure if it is on the deck) so i'll send it to you too.
i've tried to reply on my own thread today but i don't see the answer, so i ll dulicate a message for you
Did you subscribe to ML? It's a moderated list, so you have to subscribe at first.
Also, alsa-driver 1.0.25 is pretty old. Try the latest snapshot tarball instead ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Oh, it's nice really!! Did i understand you correctly - that the ca_cardbus - is the pcmcia bus support? So i need just to turn it off and that will solve the problem of waking up from suspend? nor should i put it in the end of the init process (so that sequence would be loaded before it)?
just didn't understand what do you mean @new card@ because it is actually stopped being supported and now they do the pcie and usb cards only.
=)
On 25.11.2012 23:05, James Courtier-Dutton wrote:
Can I help at all? I don't have much time spare, but I do have datasheets for some EMU cards. The PCMCIA/Cardbus versions need a special startup sequence before you can write or read any other registers. Failing to follow the startup sequence causes a PCI fault on the bus when you write to other registers on the card. I have not read the code recently, but I think that is what "ca_cardbus_chip = 1". For any new cards, you can try removing it, and if you get a PCI fault or hang on start up, put it back in.
-- RA OE AI
aLoha! Sorry, being so long, i was doing some other things.
i've downloaded the sound.git and somehow just compiled right what i needed and changed the code.
i've changed the snd_emu10k1_emu1010_init function so it is now loading regs from other function load_patches because of that a lot of space has changed, but it is simplier to just set to default right now and the error in the init function was that it was not calling the load_firmware function in the end that's the real problem and a lot of changes that in the load_patches are just to leave audiodock outside if it is not presented tried the resume function - it's not working for emu1212 need to reload alsa i thought of calling dev_create or dev_free but not sure how to use it free_emu is hanging up on wake_up yeah i've done the exclamation !EMU_HANA_OPTION_DOCK_OFFLINE in firmware_thread and added "else if" to avoid occasional error well it is Loading!!! and looks like no loops occuring.
in the bottom there's a emufx.c patch Disabled most of unuseful sliders for emu_model cards
here's the file with patch
aLoha! Sorry, being so long, i was doing some other things.
i've downloaded the sound.git and somehow just compiled right what i needed and changed the code.
i've changed the snd_emu10k1_emu1010_init function so it is now loading regs from other function load_patches because of that a lot of space has changed, but it is simplier to just set to default right now and the error in the init function was that it was not calling the load_firmware function in the end that's the real problem and a lot of changes that in the load_patches are just to leave audiodock outside if it is not presented tried the resume function - it's not working for emu1212 need to reload alsa i thought of calling dev_create or dev_free but not sure how to use it free_emu is hanging up on wake_up yeah i've done the exclamation !EMU_HANA_OPTION_DOCK_OFFLINE in firmware_thread and added "else if" to avoid occasional error well it is Loading!!! and looks like no loops occuring.
in the bottom there's a emufx.c patch Disabled most of unuseful sliders for emu_model cards
participants (3)
-
James Courtier-Dutton -
oeai -
Takashi Iwai