August 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Asus X553M audio issue SOLVED
by Rafael Gonzalez 27 Aug '15

27 Aug '15

Guys, I was having a nice chat with debianuser from #alsa on freenode, and he helped me fix my audio issues with my laptop that dual boots windows and linux. So, the easiest way to show you is post the log file of our conversation. ud> Hi there. You've been helping me with my card issues. <salviadud> I want to share what progress I've got. <salviadud> The machine is a dual boot laptop. <salviadud> I also had another issue with ACPI, but I solved that by turning D-Bus on <salviadud> In fact, after d-bus, i can see the d-bus message when I plug in my headphones to the jack. <salviadud> I don't think that windows has been tampering with the soundcard so that I need to do a full electrial reset on it. <salviadud> I just think the alsa driver is ok, but there's something missing. <salviadud> I need to develop it, or something. <salviadud> I want to know who should I talk to. <salviadud> The card vendor (Realtek) <salviadud> The laptop manufacturer (asus) <salviadud> ? <salviadud> If you got any ideas, I am all ears. so to speak <salviadud> And my logic is this: there's no default option to choose between headphones/headsets/speakers. And like I said before, I can only get audio on headphones with 3 ringed jacks. <salviadud> Windows on the other hand, has this nifty userspace program from realtek... I don't like crabs today. <debianuser> Have you managed to boot any other linux liveusb on that laptop? Ubuntu? Fedora? Mageia? Debian? <salviadud> Funny that you mention that <salviadud> I did try to load a kubuntu 14.10 <salviadud> but it hanged on me <salviadud> Same thing happened with mint. <salviadud> So, the other live cd I could load was a slax live usb stick. <salviadud> But that one in particular loaded a different driver <salviadud> and the sound that came out, was crackled. <salviadud> I can still get sound on this thing, but it has to be from external speakers, and hdmi out <salviadud> Although, I think I need to play with hda analyzer for that. <debianuser> I thought that internal speakers work fine, and you only can't hear the sound from headphones... <salviadud> Sorry <salviadud> I meant what you just said <salviadud> I called them external by mistake <salviadud> laptop speakers work, headphones don't <debianuser> Ah, ok :) <salviadud> So, I want to be proactive about this <salviadud> In what other way can I debug this <salviadud> so that I can finally reverse engineer it <salviadud> I think its an unusual thing to have a jack decide on what to output based on the number of rings. <salviadud> I guess I'm old. <salviadud> I'm used to left-right jacks. <salviadud> They are simple pieces of hardware <salviadud> And well, I just love linux, I can't stand windows as my main. <salviadud> Especially for music. <debianuser> It's just there doesn't seem to be anything special about your laptop or codec. It looks normal, but it behaves unusual, as when your mixer values were different from codec dump... <debianuser> Have you tried "full poweroff" by the way? <salviadud> I haven't done it, I need to take out some screws for that. <debianuser> What for? <salviadud> The battery <salviadud> Its not plug-n-play <salviadud> its inside where the hdd lies <debianuser> Ah, well, try just shut it down and unplug power supply, without removing the battery <debianuser> It's just has to be poweroff, not suspend, not hibernate... <salviadud> I'm pretty sure I've done that. <salviadud> start it up on just the battery. <debianuser> (actually sometimes suspend or hibernate may help too, for a different reason, but it's better to try poweroff first...) <salviadud> I'll do it when I get off work <salviadud> Still, getting ahead of it. Lets say it stays the same. <debianuser> The important part is not how you start it, but to power it off for a few minutes, then boot linux first. You can boot it with power supply attached, just boot linux first :) <salviadud> mmmmm <salviadud> Maybe its that <salviadud> the missing link <salviadud> I have never done that <salviadud> after a certain time <salviadud> windows doesn't allow me to access uefi <salviadud> and it boots directly into windows <salviadud> but <salviadud> its because its the first option <salviadud> I just need to change that <salviadud> Ok, let me rephrase <salviadud> If I shut down on linux <salviadud> and I dunno, 10 minutes pass <salviadud> I turn on my computer again, and I want to change my boot option by pressing ESC. <salviadud> I can't <salviadud> It goes into fast boot mode <salviadud> I can't control it <salviadud> So, if I change my boot option <salviadud> I should be able to do that. <salviadud> Ok, please excuse my long explanation. <debianuser> (it was reported to help for different laptops, including laptops having the same codec: launchpad.net/bugs/1087428 comment 4) <debianuser> How do you get to the linux then? <debianuser> I mean how can you boot linux at all? <salviadud> The first time was so hard. <salviadud> I had to go into repair mode in windows. <salviadud> So I could get into the bios. <salviadud> After that, I could choose the cdrom option for boot <salviadud> and that's how I installed it. <salviadud> I don't use a boot manager like grub or lilo <salviadud> just the Bios utility <salviadud> so <salviadud> I usually boot into windows first. Then I do restart, and then it allows me to select my different boot options <salviadud> Its so annoying <salviadud> I'm definetely changing the boot order <debianuser> What if you select restart in windows, get into that options list, and then just press the power button? <salviadud> That link you gave me <salviadud> same exact issue <salviadud> Its too much of a hazzle <salviadud> I want a permanent solution <debianuser> What if you select restart in windows, get into that options list, and then just press the power button - I mean does the laptop turns off? <salviadud> Yeah, it should <salviadud> but when I turn it on, its gonna know it was powered off for a while <salviadud> and it will go into the first boot option <salviadud> which is windows <debianuser> Hm... Is there some hotkey to stop it? Maybe you need to hold Ctrl or Alt? <salviadud> Nope, its NSA loving spyware windows <salviadud> what did you expect? hehehe <salviadud> I know, its terrible <debianuser> Is this the fastboot?: https://www.asus.com/support/FAQ/1005535/ <salviadud> My bios does not look as fancy as that one <salviadud> but yeah, that's the option. <salviadud> I think I had to disable it just to get access to other boot options <salviadud> I think that bios might be for a desktop <salviadud> I dunno, this laptop just feels really secure tight about working on windows <salviadud> and not on linux <salviadud> I'll give it a go in a couple of hourse, I'll tell ya what happened tomorrow <salviadud> U are a lot of help dude, thank you much. <debianuser> It's just its default setting. It may be useful for windows, I mean regular users often don't need boot menu, but they want OS to boot faster :) (I remember how people were impressed when I booted simple linux gui in 10 seconds). <salviadud> 10 seconds? that's still impressive, hehe <salviadud> u know what, I'm gonna try this now <salviadud> brb <salviadud> dude, it totally worked <salviadud> I'm listening to my tunes on audacious <debianuser> Great! :) <salviadud> as a token of my appreciation <salviadud> here's my ftp server <salviadud> anachronox.dyndns.za.org <salviadud> user:ftpuser <salviadud> pass:meridian2002 <salviadud> its full of music roms n pr0n <salviadud> hehe <debianuser> As for 10 seconds boot - it's just a generic kernel, with a custom init script: about 5 seconds to probe/load modules for available devices, 2 seconds for Xorg to start and switch to graphical mode, and 3 more seconds to boot firefox (I don't remember exact timings but something like that). <debianuser> There're better boot times on youtube: https://youtu.be/whkmChncjRk https://youtu.be/XcbKe3ct610 https://youtu.be/fMM-ZZijRc4 https://youtu.be/s7NxCM8ryF8 3-5 seconds - that's impressive. :) But I was too lazy to build a custom kernel for that. :) <salviadud> I could do something similar... <salviadud> I got a custom kernel <salviadud> whatever... I don't care about boot times. <salviadud> thanx again man. <debianuser> You're welcome! Feel free to ask whenever you want to know anything else :) <salviadud> that ftp server gets shutdown when I got to sleep, keep that in mind. <salviadud> I turn it on, every now and then. * debianuser saves a not that full poweroff makes sound headphones working on a dual-boot Asus X553MA (Codec: Realtek ALC270) <debianuser> *a note <debianuser> And thanks for reporting the problem, by the way. If you want to spend a few more minutes for it we can try to compare working and broken settings to check what exactly was different... Maybe we find a way to undo that... <debianuser> (basically I'll just ask you to dump alsa-info 2 more times with one special optio) <debianuser> (and if we're lucky we'll have something to report to alsa-devel mailing list, and devs would be able to include that into the kernel to make it working in next kernel version out of box) <salviadud> ok <salviadud> sounds good <salviadud> How do I run the script, headphones on or off? <debianuser> There're vendor-specific coefficients that control the chip but sometimes are not reset on reboot. To include those int alsa-info run: `echo 1 | sudo tee /sys/module/snd_hda_codec/parameters/dump_coef` then dump alsa-info as usual with headphones plugged in. That's the "working" dump. <debianuser> Then we'll break it: reboot into windows, reboot back into linux, make sure headphones don't work, run `echo 1 | sudo tee /sys/module/snd_hda_codec/parameters/dump_coef` and dump alsa-info with headphones plugged in again. That would be "broken" dump. <salviadud> ok, I don't sudo, so I'll just run that as root. <debianuser> Then we'll diff them and see if there's some difference that we can undo... <salviadud> ok, working dump coming <debianuser> yeah `echo 1 > /sys/module/snd_hda_codec/parameters/dump_coef` as root will work too <salviadud> http://www.alsa-project.org/db/?f=abda2cd2c9137fbf2319015707cf2d8d30aaf773 <salviadud> I ran alsa-info after the echo <salviadud> let me go back into windows..., and see if it breaks on reboot * Registro cargado desde Wed Aug 26 18:45:41 2015 <salviadud> ok, I got broken audio <debianuser> Now let's get broken alsa-info and diff them! <salviadud> http://www.alsa-project.org/db/?f=4d597f8a6f9eaa0f0823d195d5fa5093ea71d0eb <salviadud> Well, I'm glad it worked <salviadud> and hell, I even left windows as a special option <salviadud> no need to erase boot options <salviadud> I just disabled it so I can boot straight into linux <salviadud> feels great man. <debianuser> Hah! The difference is just in 2 coefficients: Coeff 0x04: 0x9827 (working) / 0x9027 (broken) and Coeff 0x0d: 0x4440 (working) / 0xc440 (broken) <debianuser> Let's try to change them back and see if that would fix headphones! <salviadud> so, How do I do that? <debianuser> To do that install "alsa-tools" package if you don't have it yet and run these 4 commands in the following order: <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x04 <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x9827 <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x0d <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x4440 <salviadud> i got alsatools, let me give it a go. <debianuser> (not sure what which one of them is doing, so let's set them both and see if that will change anything) <salviadud> I got sound <salviadud> You are pro <salviadud> although, I really wouldn't like to do that every time. * salviadud knows that sounded dumb <debianuser> Great! You don't have to do that every time (well, you can add those to /etc/rc.local, or whatever is used in gentoo instead). But the point was to find what was causing the issue. <salviadud> that's why we're doing this test... hehe <salviadud> Yeah, I think its a small, yet important contribution. * debianuser wonders which one of those coefs breaks the sound... <salviadud> I think its safe to just keep both like that. <debianuser> Can you check that by the way? For example revert one of them back to "broken" value and check if you still have the sound from headphones: <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x04 <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x9027 <salviadud> I will <salviadud> for science <salviadud> that broke it <salviadud> I got no sound <salviadud> What else do I do? <salviadud> or is that it? <debianuser> How about the other way around? 0x04 to working, 0x0d to broken: <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x04 <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x9827 <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x0d <debianuser> sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xc440 <debianuser> (that's the last test) <salviadud> it works <salviadud> I think the other coefficient might be the hdmi <salviadud> But I can't debug that one over here right now <salviadud> still, that's just a wild guess <salviadud> Well, you got all you need to report debugging info? <debianuser> Well, that's all we need for the report. Now if you still feel the power to make the world better (just a little bit) - you can report that to alsa-devel mailing list. Include both alsa-info links, tell which one of them works and which one has headphones broken after windows reboot, and which hda-verb commands pair makes headphones working again. :) <salviadud> I'm just gonna send the log of this conversation <debianuser> They may ask you to test a kernel patch (they often do that) before sending it upstream to Linus. That's why it's better for you to report it. <salviadud> if you don't minnd <debianuser> I don't :) <salviadud> alsa rocks! <debianuser> especially when it works :) <salviadud> \O/ <debianuser> Thank you for your patience, for reporting the problem and for doing all those checks!

1 0

[alsa-devel] different acpi_ipc_irq_index among baytrail boards issue
by Michele Curti 26 Aug '15

26 Aug '15

Hi, some baytrail machines, although belonging to the same platform, have the ADSP IRQ number at different ACPI index (.acpi_ipc_irq_index = 0 instead of 5). Not an issue for now, since there is no support for these machines (like the Asus X205TA) at the moment, but if the driver will work, a patch like the following would be acceptable (I ask so I can try to keep a sort of patchset)? * declare a new struct type sst_acpi_info where to place acpi infos lpe_res_index, ddr_index, ipc_irq_index * create a new 'const struct sst_acpi_info *acpi_info' field into the struct sst_platform_info (to be managed like the others ipc_info, res_info, ...) * move the acpi infos from the byt_rvp_res_info variable to a new byt_acpi_res_info one In this way one could duplicate byt_rvp_acpi_info instead of the whole byt_rvp_res_info (which seems "not good" to me, or it's ok?) to manage different acpi indexes. Hope I was clear enough.. Thanks, Michele --- arch/x86/include/asm/platform_sst_audio.h | 11 ++++++++--- sound/soc/intel/atom/sst/sst_acpi.c | 17 +++++++++++------ 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/platform_sst_audio.h b/arch/x86/include/asm/platform_sst_audio.h index 7249e6d..b10f6a7 100644 --- a/arch/x86/include/asm/platform_sst_audio.h +++ b/arch/x86/include/asm/platform_sst_audio.h @@ -118,9 +118,6 @@ struct sst_res_info { unsigned int dram_size; unsigned int mbox_offset; unsigned int mbox_size; - unsigned int acpi_lpe_res_index; - unsigned int acpi_ddr_index; - unsigned int acpi_ipc_irq_index; }; struct sst_ipc_info { @@ -128,13 +125,21 @@ struct sst_ipc_info { unsigned int mbox_recv_off; }; +struct sst_acpi_info { + unsigned int lpe_res_index; + unsigned int ddr_index; + unsigned int ipc_irq_index; +}; + struct sst_platform_info { const struct sst_info *probe_data; const struct sst_ipc_info *ipc_info; + const struct sst_acpi_info *acpi_info; const struct sst_res_info *res_info; const struct sst_lib_dnld_info *lib_info; const char *platform; }; + int add_sst_platform_device(void); #endif diff --git a/sound/soc/intel/atom/sst/sst_acpi.c b/sound/soc/intel/atom/sst/sst_acpi.c index bb19b58..427e404 100644 --- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -116,14 +116,18 @@ static const struct sst_res_info byt_rvp_res_info = { .dram_size = 0x28000, .mbox_offset = 0x144000, .mbox_size = 0x1000, - .acpi_lpe_res_index = 0, - .acpi_ddr_index = 2, - .acpi_ipc_irq_index = 5, +}; + +static const struct sst_acpi_info byt_rvp_acpi_info = { + .lpe_res_index = 0, + .ddr_index = 2, + .ipc_irq_index = 5, }; static struct sst_platform_info byt_rvp_platform_data = { .probe_data = &byt_fwparse_info, .ipc_info = &byt_ipc_info, + .acpi_info = &byt_rvp_acpi_info, .lib_info = &byt_lib_dnld_info, .res_info = &byt_rvp_res_info, .platform = "sst-mfld-platform", @@ -135,6 +139,7 @@ static struct sst_platform_info byt_rvp_platform_data = { static struct sst_platform_info chv_platform_data = { .probe_data = &byt_fwparse_info, .ipc_info = &byt_ipc_info, + .acpi_info = &byt_rvp_acpi_info, .lib_info = &byt_lib_dnld_info, .res_info = &byt_rvp_res_info, .platform = "sst-mfld-platform", @@ -148,7 +153,7 @@ static int sst_platform_get_resources(struct intel_sst_drv *ctx) /* All ACPI resource request here */ /* Get Shim addr */ rsrc = platform_get_resource(pdev, IORESOURCE_MEM, - ctx->pdata->res_info->acpi_lpe_res_index); + ctx->pdata->acpi_info->lpe_res_index); if (!rsrc) { dev_err(ctx->dev, "Invalid SHIM base from IFWI"); return -EIO; @@ -202,7 +207,7 @@ static int sst_platform_get_resources(struct intel_sst_drv *ctx) ctx->mailbox_add = ctx->info.mailbox_start; rsrc = platform_get_resource(pdev, IORESOURCE_MEM, - ctx->pdata->res_info->acpi_ddr_index); + ctx->pdata->acpi_info->ddr_index); if (!rsrc) { dev_err(ctx->dev, "Invalid DDR base from IFWI"); return -EIO; @@ -219,7 +224,7 @@ static int sst_platform_get_resources(struct intel_sst_drv *ctx) /* Find the IRQ */ ctx->irq_num = platform_get_irq(pdev, - ctx->pdata->res_info->acpi_ipc_irq_index); + ctx->pdata->acpi_info->ipc_irq_index); return 0; } -- 2.5.0

1 0

[alsa-devel] [PATCH 0/3] USB-audio disconnection lockdep fixes
by Takashi Iwai 26 Aug '15

26 Aug '15

Hi, this is a series of patches for USB-audio to improve the lock handling at disconnection. Originally it was aimed to get rid of spurious lockdep warnings, but this ended up with the rewrite and improvement of locking code at disconnection and its checks in the mixer and PCM codes. Takashi === Takashi Iwai (3): ALSA: usb-audio: Avoid nested autoresume calls ALSA: usb-audio: Replace probing flag with active refcount ALSA: usb-audio: Handle normal and auto-suspend equally sound/usb/card.c | 108 ++++++++++++++++++++++------------------ sound/usb/endpoint.c | 10 ++-- sound/usb/mixer.c | 32 ++++-------- sound/usb/mixer_quirks.c | 126 ++++++++++++++++++++--------------------------- sound/usb/pcm.c | 32 ++++++------ sound/usb/proc.c | 4 +- sound/usb/usbaudio.h | 11 +++-- 7 files changed, 155 insertions(+), 168 deletions(-) -- 2.5.0

1 3

[alsa-devel] ALSA/usb-audio: snd_usb_autoresume possible recursive locking detected
by Alexnader Kuleshov 26 Aug '15

26 Aug '15

Hello all, Today I've update to 4.2.0-rc8+ and started to get following lines in the dmesg output: [ 13.884092] ============================================= [ 13.884092] [ INFO: possible recursive locking detected ] [ 13.884094] 4.2.0-rc8+ #61 Not tainted [ 13.884094] --------------------------------------------- [ 13.884095] pulseaudio/980 is trying to acquire lock: [ 13.884096] (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] [ 13.884103] but task is already holding lock: [ 13.884104] (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] [ 13.884107] other info that might help us debug this: [ 13.884108] Possible unsafe locking scenario: [ 13.884109] CPU0 [ 13.884110] ---- [ 13.884110] lock(&chip->shutdown_rwsem); [ 13.884111] lock(&chip->shutdown_rwsem); [ 13.884112] *** DEADLOCK *** [ 13.884113] May be due to missing lock nesting notation [ 13.884114] 2 locks held by pulseaudio/980: [ 13.884115] #0: (&pcm->open_mutex){+.+.+.}, at: [<ffffffffa02ac9bc>] snd_pcm_open+0xa9/0x1f8 [snd_pcm] [ 13.884120] #1: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] [ 13.884124] stack backtrace: [ 13.884125] CPU: 0 PID: 980 Comm: pulseaudio Not tainted 4.2.0-rc8+ #61 [ 13.884126] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD5H-BK/Z97X-UD5H-BK, BIOS F6 06/17/2014 [ 13.884127] 0000000000000000 000000003d4c66e6 ffff88040897b4d8 ffffffff815ba622 [ 13.884129] 0000000000000000 ffffffff82399320 ffff88040897b598 ffffffff810dd54e [ 13.884130] ffff88040ac486a8 0000000000000000 0000000000000001 ffffffff82399320 [ 13.884132] Call Trace: [ 13.884134] [<ffffffff815ba622>] dump_stack+0x4c/0x65 [ 13.884137] [<ffffffff810dd54e>] validate_chain.isra.9+0x75d/0xf59 [ 13.884139] [<ffffffff815c62b3>] ? _raw_spin_unlock_irq+0x28/0x34 [ 13.884140] [<ffffffff810e0964>] __lock_acquire+0x753/0xabf [ 13.884142] [<ffffffff81163819>] ? kfree+0xb8/0x10d [ 13.884143] [<ffffffff810e1131>] lock_acquire+0x7b/0x9c [ 13.884146] [<ffffffffa0355dac>] ? snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] [ 13.884147] [<ffffffff815c4896>] down_read+0x44/0x8d [ 13.884150] [<ffffffffa0355dac>] ? snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] [ 13.884152] [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] [ 13.884153] [<ffffffff815c37e5>] ? __mutex_unlock_slowpath+0x110/0x11b [ 13.884156] [<ffffffffa0359338>] snd_usb_mixer_set_ctl_value+0x9a/0x16d [snd_usb_audio] [ 13.884159] [<ffffffffa035957e>] snd_usb_set_cur_mix_value+0x4d/0x77 [snd_usb_audio] [ 13.884161] [<ffffffffa0359db9>] restore_mixer_value+0x74/0x87 [snd_usb_audio] [ 13.884164] [<ffffffffa035b581>] snd_usb_mixer_resume+0x64/0x70 [snd_usb_audio] [ 13.884166] [<ffffffffa035505c>] __usb_audio_resume+0x5c/0xd8 [snd_usb_audio] [ 13.884169] [<ffffffff81413ca4>] ? usb_runtime_suspend+0x63/0x63 [ 13.884171] [<ffffffffa03550e6>] usb_audio_reset_resume+0xe/0x10 [snd_usb_audio] [ 13.884172] [<ffffffff81412fde>] usb_resume_interface.isra.1+0x6c/0xbd [ 13.884174] [<ffffffff814130cf>] usb_resume_both+0xa0/0xc0 [ 13.884175] [<ffffffff81413cb9>] usb_runtime_resume+0x15/0x17 [ 13.884178] [<ffffffff813b92b0>] __rpm_callback+0x35/0x5d [ 13.884179] [<ffffffff81413ca4>] ? usb_runtime_suspend+0x63/0x63 [ 13.884180] [<ffffffff813b9330>] rpm_callback+0x58/0x77 [ 13.884182] [<ffffffff81413ca4>] ? usb_runtime_suspend+0x63/0x63 [ 13.884183] [<ffffffff813ba0db>] rpm_resume+0x370/0x412 [ 13.884184] [<ffffffff813ba06c>] rpm_resume+0x301/0x412 [ 13.884186] [<ffffffff813ba1e3>] __pm_runtime_resume+0x66/0x82 [ 13.884187] [<ffffffff81412e10>] usb_autopm_get_interface+0x1e/0x48 [ 13.884190] [<ffffffffa0355dcc>] snd_usb_autoresume+0x3d/0x52 [snd_usb_audio] [ 13.884191] [<ffffffff810d84b9>] ? __init_waitqueue_head+0x37/0x4b [ 13.884194] [<ffffffffa035e765>] snd_usb_pcm_open+0x181/0x3bb [snd_usb_audio] [ 13.884197] [<ffffffffa035e9ad>] snd_usb_capture_open+0xe/0x10 [snd_usb_audio] [ 13.884200] [<ffffffffa02ac8c6>] snd_pcm_open_substream+0x50/0x9d [snd_pcm] [ 13.884203] [<ffffffffa02ac9ce>] snd_pcm_open+0xbb/0x1f8 [snd_pcm] [ 13.884204] [<ffffffff810de87d>] ? trace_hardirqs_on+0xd/0xf [ 13.884206] [<ffffffff810c5550>] ? wake_up_q+0x53/0x53 [ 13.884209] [<ffffffffa02acb49>] snd_pcm_capture_open+0x3e/0x61 [snd_pcm] [ 13.884212] [<ffffffffa028232d>] snd_open+0x130/0x13f [snd] [ 13.884214] [<ffffffff811788c5>] chrdev_open+0x13b/0x175 [ 13.884215] [<ffffffff8117878a>] ? cdev_put+0x20/0x20 [ 13.884217] [<ffffffff81172f31>] do_dentry_open.isra.1+0x1d2/0x2c9 [ 13.884218] [<ffffffff8117d0e4>] ? __inode_permission+0x84/0x95 [ 13.884219] [<ffffffff81173bf6>] vfs_open+0x50/0x54 [ 13.884221] [<ffffffff811815e0>] path_openat+0xa90/0xd0f [ 13.884222] [<ffffffff810e0900>] ? __lock_acquire+0x6ef/0xabf [ 13.884223] [<ffffffff8118269e>] do_filp_open+0x48/0xac [ 13.884225] [<ffffffff815c6203>] ? _raw_spin_unlock+0x23/0x2e [ 13.884227] [<ffffffff8118f5b7>] ? __alloc_fd+0x144/0x156 [ 13.884228] [<ffffffff81173f3a>] do_sys_open+0x154/0x1f7 [ 13.884229] [<ffffffff81173ff6>] SyS_open+0x19/0x1b [ 13.884231] [<ffffffff815c6a57>] entry_SYSCALL_64_fastpath+0x12/0x6f Previous version of the kernel was 4.2.0-rc6+.

3 11

[alsa-devel] [PATCH] ALSA: hda - Remove superfluous pcm NULL check
by Takashi Iwai 26 Aug '15

26 Aug '15

The variable pcm can be never NULL since it was rewritten with list_for_each_entry(). Suggested-by: Markus Osterhoff <linux-kernel(a)k-raum.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_codec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 2c021911f88a..37f43a1b34ef 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3102,8 +3102,7 @@ static int add_std_chmaps(struct hda_codec *codec) struct snd_pcm_chmap *chmap; const struct snd_pcm_chmap_elem *elem; - if (!pcm || !pcm->pcm || pcm->own_chmap || - !hinfo->substreams) + if (!pcm->pcm || pcm->own_chmap || !hinfo->substreams) continue; elem = hinfo->chmap ? hinfo->chmap : snd_pcm_std_chmaps; err = snd_pcm_add_chmap_ctls(pcm->pcm, str, elem, -- 2.5.0

1 0

[alsa-devel] [asoc:topic/rockchip 1/4] sound/soc/rockchip/rockchip_max98090.c:225:3-8: No need to set .owner here. The core will do it.
by kbuild test robot 26 Aug '15

26 Aug '15

tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/rockchip head: f8ce20005d1694584448cd544be5fb32416a277c commit: 49bdb0440541ad1144ad08d5613f9a28bcd2a8dc [1/4] ASoC: rockchip: Add machine driver for max98090 codec coccinelle warnings: (new ones prefixed by >>) >> sound/soc/rockchip/rockchip_max98090.c:225:3-8: No need to set .owner here. The core will do it. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 2

[alsa-devel] [asoc:topic/rockchip 2/4] sound/soc/rockchip/rockchip_rt5645.c:214:3-8: No need to set .owner here. The core will do it.
by kbuild test robot 26 Aug '15

26 Aug '15

tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/rockchip head: f8ce20005d1694584448cd544be5fb32416a277c commit: 86059653ea7ca7b30ed25d6bec5807ba59a4f2e6 [2/4] ASoC: rockchip: Add machine driver for rt5645/rt5650 codec coccinelle warnings: (new ones prefixed by >>) >> sound/soc/rockchip/rockchip_rt5645.c:214:3-8: No need to set .owner here. The core will do it. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 2

[alsa-devel] [PATCH v4] ASoC: ics43432: Add codec driver for InvenSense ICS-43432 (fwd)
by Ricard Wanderlof 26 Aug '15

26 Aug '15

Add support for the InvenSense ICS-43432 I2S MEMS microphone. This is a non-software-configurable MEMS microphone with I2S output. Tested on a setup with a single ICS-43432, although the device itself supports stereo operation using a hardware pin controlling left vs. right channel output. Signed-off-by: Ricard Wanderlof <ricardw(a)axis.com> --- V4: Updated commit message that the driver has been tested with real hardware, after off-list comment on V3. V3: Fixed MODULE_LICENSE string. V2: Update after comments from Lars-Peter: set rate to CONTINUOUS and let ALSA figure out the details, also removing hw_params as it is then not needed. I've left the checks in dai_set_fmt, as (IIUC) there currently doesn't seem to be a way for the ALSA framework to handle format constraints using the codec configuration struct. .../devicetree/bindings/sound/ics43432.txt | 17 ++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/ics43432.c | 101 ++++++++++++++++++++ 5 files changed, 125 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/ics43432.txt create mode 100644 sound/soc/codecs/ics43432.c diff --git a/Documentation/devicetree/bindings/sound/ics43432.txt b/Documentation/devicetree/bindings/sound/ics43432.txt new file mode 100644 index 0000000..b02e3a6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ics43432.txt @@ -0,0 +1,17 @@ +Invensense ICS-43432 MEMS microphone with I2S output. + +There are no software configuration options for this device, indeed, the only +host connection is the I2S interface. Apart from requirements on clock +frequency (460 kHz to 3.379 MHz according to the data sheet) there must be +64 clock cycles in each stereo output frame; 24 of the 32 available bits +contain audio data. A hardware pin determines if the device outputs data +on the left or right channel of the I2S frame. + +Required properties: + - compatible : Must be "invensense,ics43432" + +Example: + + ics43432: ics43432 { + compatible = "invensense,ics43432"; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 8033919..7966637 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -103,6 +103,7 @@ img Imagination Technologies Ltd. innolux Innolux Corporation intel Intel Corporation intercontrol Inter Control Group +invensense InvenSense Inc. isee ISEE 2007 S.L. isil Intersil karo Ka-Ro electronics GmbH diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 061c465..d696c85 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -62,6 +62,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_BT_SCO select SND_SOC_ES8328_SPI if SPI_MASTER select SND_SOC_ES8328_I2C if I2C + select SND_SOC_ICS43432 select SND_SOC_ISABELLE if I2C select SND_SOC_JZ4740_CODEC select SND_SOC_LM4857 if I2C @@ -444,6 +445,9 @@ config SND_SOC_ES8328_SPI tristate select SND_SOC_ES8328 +config SND_SOC_ICS43432 + tristate + config SND_SOC_ISABELLE tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index abe2d7e..23a2caf 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -55,6 +55,7 @@ snd-soc-dmic-objs := dmic.o snd-soc-es8328-objs := es8328.o snd-soc-es8328-i2c-objs := es8328-i2c.o snd-soc-es8328-spi-objs := es8328-spi.o +snd-soc-ics43432-objs := ics43432.o snd-soc-isabelle-objs := isabelle.o snd-soc-jz4740-codec-objs := jz4740.o snd-soc-l3-objs := l3.o @@ -240,6 +241,7 @@ obj-$(CONFIG_SND_SOC_DMIC) += snd-soc-dmic.o obj-$(CONFIG_SND_SOC_ES8328) += snd-soc-es8328.o obj-$(CONFIG_SND_SOC_ES8328_I2C)+= snd-soc-es8328-i2c.o obj-$(CONFIG_SND_SOC_ES8328_SPI)+= snd-soc-es8328-spi.o +obj-$(CONFIG_SND_SOC_ICS43432) += snd-soc-ics43432.o obj-$(CONFIG_SND_SOC_ISABELLE) += snd-soc-isabelle.o obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o diff --git a/sound/soc/codecs/ics43432.c b/sound/soc/codecs/ics43432.c new file mode 100644 index 0000000..fe0af4a --- /dev/null +++ b/sound/soc/codecs/ics43432.c @@ -0,0 +1,101 @@ +/* + * I2S MEMS microphone driver for InvenSense ICS-43432 + * + * - Non configurable. + * - I2S interface, 64 BCLs per frame, 32 bits per channel, 24 bit data + * + * Copyright (c) 2015 Axis Communications AB + * + * Licensed under GPL2. + */ + +#include <linux/module.h> +#include <linux/init.h> +#include <linux/slab.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/initval.h> +#include <sound/tlv.h> + +#define ICS43432_RATE_MIN 7190 /* Hz, from data sheet */ +#define ICS43432_RATE_MAX 52800 /* Hz, from data sheet */ + +static int ics43432_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) +{ + switch (fmt & SND_SOC_DAIFMT_INV_MASK) { + case SND_SOC_DAIFMT_NB_NF: + break; + default: + return -EINVAL; + } + + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { + case SND_SOC_DAIFMT_I2S: + break; + default: + return -EINVAL; + } + + return 0; +} + +#define ICS43432_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32) + +static const struct snd_soc_dai_ops ics43432_dai_ops = { + .set_fmt = ics43432_set_dai_fmt, +}; + +static struct snd_soc_dai_driver ics43432_dai = { + .name = "ics43432-hifi", + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rate_min = ICS43432_RATE_MIN, + .rate_max = ICS43432_RATE_MAX, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .formats = ICS43432_FORMATS, + }, + .ops = &ics43432_dai_ops, +}; + +static struct snd_soc_codec_driver ics43432_codec_driver = { +}; + +static int ics43432_probe(struct platform_device *pdev) +{ + return snd_soc_register_codec(&pdev->dev, &ics43432_codec_driver, + &ics43432_dai, 1); +} + +static int ics43432_remove(struct platform_device *pdev) +{ + snd_soc_unregister_codec(&pdev->dev); + return 0; +} + +#ifdef CONFIG_OF +static const struct of_device_id ics43432_ids[] = { + { .compatible = "invensense,ics43432", }, + { } +}; +MODULE_DEVICE_TABLE(of, ics43432_dt_ids); +#endif + +static struct platform_driver ics43432_driver = { + .driver = { + .name = "ics43432", + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(ics43432_ids), + }, + .probe = ics43432_probe, + .remove = ics43432_remove, +}; + +module_platform_driver(ics43432_driver); + +MODULE_DESCRIPTION("ASoC ICS43432 driver"); +MODULE_AUTHOR("Ricard Wanderlof <ricardw(a)axis.com>"); +MODULE_LICENSE("GPLv2"); -- 1.7.10.4 -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 2

[alsa-devel] [PATCH 1/5] ASoC: rt5645: Prevent the pop sound of the headphone while rebooting or shutdowning
by Oder Chiou 26 Aug '15

26 Aug '15

Add i2c shutdown function to prevent the pop sound of the headphone while the system is rebooting or shutdowning Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5645.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index e5fef8f..4189d5a 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -3490,13 +3490,23 @@ static int rt5645_i2c_remove(struct i2c_client *i2c) return 0; } +static void rt5645_i2c_shutdown(struct i2c_client *i2c) +{ + struct rt5645_priv *rt5645 = i2c_get_clientdata(i2c); + + regmap_update_bits(rt5645->regmap, RT5645_GEN_CTRL3, 0x0020, 0x0020); + regmap_update_bits(rt5645->regmap, RT5645_IN1_CTRL2, 0x1000, 0x1000); + regmap_update_bits(rt5645->regmap, RT5645_IN1_CTRL1, 0x0004, 0x0000); +} + static struct i2c_driver rt5645_i2c_driver = { .driver = { .name = "rt5645", .acpi_match_table = ACPI_PTR(rt5645_acpi_match), }, .probe = rt5645_i2c_probe, - .remove = rt5645_i2c_remove, + .remove = rt5645_i2c_remove, + .shutdown = rt5645_i2c_shutdown, .id_table = rt5645_i2c_id, }; module_i2c_driver(rt5645_i2c_driver); -- 1.8.1.1.439.g50a6b54

2 11

[alsa-devel] [PATCH v2] ASoC: rockchip: fix a misjudgement by return
by Xing Zheng 26 Aug '15

26 Aug '15

Being careless, judge the return value of snd_soc_card_jack_new is opposite, so it should be fixed. --- Changes in v2: Signed-off-by: Xing Zheng <zhengxing(a)rock-chips.com> Reviewed-by: Dylan Reid <dgreid(a)chromium.org> sound/soc/rockchip/rockchip_rt5645.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/rockchip/rockchip_rt5645.c b/sound/soc/rockchip/rockchip_rt5645.c index 3c6bb1e..adfe98c 100644 --- a/sound/soc/rockchip/rockchip_rt5645.c +++ b/sound/soc/rockchip/rockchip_rt5645.c @@ -118,7 +118,7 @@ static int rk_init(struct snd_soc_pcm_runtime *runtime) SND_JACK_BTN_0 | SND_JACK_BTN_1 | SND_JACK_BTN_2 | SND_JACK_BTN_3, &headset_jack, NULL, 0); - if (!ret) { + if (ret) { dev_err(card->dev, "New Headset Jack failed! (%d)\n", ret); return ret; } -- 1.7.9.5

2 1