May 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/6] topology: complete PCM parsing and code refactoring
by mengdong.lin＠linux.intel.com 08 May '16

08 May '16

From: Mengdong Lin <mengdong.lin(a)linux.intel.com> There is no ABI change in this series. This series fixes bugs and missing info of PCM (Front-end DAI & DAI link) defined by the text conf file. There is also some code refactoring, as a preparation for Back-end DAI support and ABI update which is under internal test and review atm. Mengdong Lin (6): topology: Set manifest size for ABI topology: Refactor functions to parse and build streams topology: Use generic pointer to realloc buffer for private data topology: Fix pcm ID & name parsing topology: Parse front-end DAI name and ID for the PCM topology: Update PCM configurations in Broadwell text conf file include/sound/asoc.h | 2 +- include/topology.h | 4 + src/conf/topology/broadwell/broadwell.conf | 34 ++++++--- src/topology/data.c | 24 ++---- src/topology/parser.c | 4 +- src/topology/pcm.c | 119 ++++++++++++++++++++++------- src/topology/tplg_local.h | 2 +- 7 files changed, 131 insertions(+), 58 deletions(-) -- 2.5.0

5 11

Re: [alsa-devel] New codecs support for ALC234/ALC274/ALC294
by Kailang 08 May '16

08 May '16

Hi Takashi, Could you receive this mail? Thanks. BR, Kailang ________________________________ From: Kailang Sent: Wednesday, May 04, 2016 4:13 PM To: Takashi Iwai (tiwai(a)suse.de) Cc: (alsa-devel(a)alsa-project.org) Subject: New codecs support for ALC234/ALC274/ALC294 Hi Takashi, We have new codecs for ALC234/ALC274/ALC294. Attach file is the support patch. BR, Kailang

2 1

Re: [alsa-devel] ALSA: hda - Fix white noise on Asus UX501VW headset
by Takashi Iwai 08 May '16

08 May '16

On Thu, 05 May 2016 16:08:02 +0200, Kaho Ng wrote: > > For reducing the noise from the headset output on ASUS UX501VW, > call the existing fixup, alc_fixup_headset_mode_alc668(), additionally. > > Thread: https://bbs.archlinux.org/viewtopic.php?id=209554 > > Signed-off-by: Kaho Ng <ngkaho1234(a)gmail.com> > --- > diff -ruNp a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > --- a/sound/pci/hda/patch_realtek.c 2016-04-20 14:44:02.000000000 +0800 > +++ b/sound/pci/hda/patch_realtek.c 2016-05-03 16:31:30.815677146 +0800 > @@ -6424,6 +6424,7 @@ enum { > ALC668_FIXUP_DELL_DISABLE_AAMIX, > ALC668_FIXUP_DELL_XPS13, > ALC662_FIXUP_ASUS_Nx50, > + ALC668_FIXUP_ASUS_UX501VW, > }; > > static const struct hda_fixup alc662_fixups[] = { > @@ -6670,6 +6671,10 @@ static const struct hda_fixup alc662_fix > .chained = true, > .chain_id = ALC662_FIXUP_BASS_1A > }, > + [ALC668_FIXUP_ASUS_UX501VW] = { > + .type = HDA_FIXUP_FUNC, > + .v.func = alc_fixup_headset_mode_alc668, > + }, > }; There is already a fixup entry (ALC668_FIXUP_HEADSET_MODE) doing the very same thing, so you don't have to redefine it. > static const struct snd_pci_quirk alc662_fixup_tbl[] = { > @@ -6692,6 +6697,7 @@ static const struct snd_pci_quirk alc662 > SND_PCI_QUIRK(0x1028, 0x0698, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE), > SND_PCI_QUIRK(0x1028, 0x069f, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE), > SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800), > + SND_PCI_QUIRK(0x1043, 0x1080, "Asus UX501VW", ALC668_FIXUP_ASUS_UX501VW), And just add the quirk entry like SND_PCI_QUIRK(0x1043, 0x1080, "Asus UX501VW", ALC668_FIXUP_HEADSET_MODE), Could you resubmit the fix patch after adjusting like this? thanks, Takashi

1 0

Re: [alsa-devel] New codecs support for ALC234/ALC274/ALC294
by Takashi Iwai 08 May '16

08 May '16

On Wed, 04 May 2016 10:12:41 +0200, Kailang wrote: > > Hi Takashi, > > We have new codecs for ALC234/ALC274/ALC294. > Attach file is the support patch. Thanks, applied now. Takashi

1 0

[alsa-devel] [patch] ALSA: isa/wavefront: prevent some out of bound writes
by Dan Carpenter 08 May '16

08 May '16

"header->number" can be up to USHRT_MAX and it comes from the ioctl so it needs to be capped. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/isa/wavefront/wavefront_synth.c b/sound/isa/wavefront/wavefront_synth.c index 69f76ff..718d5e3 100644 --- a/sound/isa/wavefront/wavefront_synth.c +++ b/sound/isa/wavefront/wavefront_synth.c @@ -785,6 +785,9 @@ wavefront_send_patch (snd_wavefront_t *dev, wavefront_patch_info *header) DPRINT (WF_DEBUG_LOAD_PATCH, "downloading patch %d\n", header->number); + if (header->number >= ARRAY_SIZE(dev->patch_status)) + return -EINVAL; + dev->patch_status[header->number] |= WF_SLOT_FILLED; bptr = buf; @@ -809,6 +812,9 @@ wavefront_send_program (snd_wavefront_t *dev, wavefront_patch_info *header) DPRINT (WF_DEBUG_LOAD_PATCH, "downloading program %d\n", header->number); + if (header->number >= ARRAY_SIZE(dev->prog_status)) + return -EINVAL; + dev->prog_status[header->number] = WF_SLOT_USED; /* XXX need to zero existing SLOT_USED bit for program_status[i] @@ -898,6 +904,9 @@ wavefront_send_sample (snd_wavefront_t *dev, header->number = x; } + if (header->number >= WF_MAX_SAMPLE) + return -EINVAL; + if (header->size) { /* XXX it's a debatable point whether or not RDONLY semantics

2 1

Re: [alsa-devel] [PATCH] infoleak fix1 in timer
by Takashi Iwai 08 May '16

08 May '16

On Tue, 03 May 2016 22:44:07 +0200, Kangjie Lu wrote: > > The stack object “tread” has a total size of 32 bytes. Its field > “event” and “val” both contain 4 bytes padding. These 8 bytes > padding bytes are sent to user without being initialized. > > Signed-off-by: Kangjie Lu <kjlu(a)gatech.edu> Thanks, I applied now all three patches. But I rephrased the subjects to more meaningful ones. Better to give a bit more informative subject line at the next time. Takashi

1 0

[alsa-devel] [PATCH] ALSA: compress: fix some typo
by Vinod Koul 08 May '16

08 May '16

Noticed two typos in Documentation, so fix them up Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- Documentation/sound/alsa/compress_offload.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index 630c492c3dc2..8ba556a131c3 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -149,7 +149,7 @@ Gapless Playback ================ When playing thru an album, the decoders have the ability to skip the encoder delay and padding and directly move from one track content to another. The end -user can perceive this as gapless playback as we dont have silence while +user can perceive this as gapless playback as we don't have silence while switching from one track to another Also, there might be low-intensity noises due to encoding. Perfect gapless is @@ -184,7 +184,7 @@ Sequence flow for gapless would be: - Fill data of the first track - Trigger start - User-space finished sending all, -- Indicaite next track data by sending set_next_track +- Indicate next track data by sending set_next_track - Set metadata of the next track - then call partial_drain to flush most of buffer in DSP - Fill data of the next track -- 1.9.1

2 1

[alsa-devel] sound: deadlock involving snd_hrtimer_callback
by Dmitry Vyukov 08 May '16

08 May '16

Hi Takashi, I've incorporated your hrtimer fixes (but also updated to ddce192106e4f984123884f8e878f66ace94b573) and now I am seeing lots of the following deadlock messages: [ INFO: possible circular locking dependency detected ] 4.6.0-rc4+ #351 Not tainted ------------------------------------------------------- swapper/0/0 is trying to acquire lock: (&(&timer->lock)->rlock){-.-...}, at: [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 but task is already holding lock: (&(&stime->lock)->rlock){-.....}, at: [<ffffffff85383d3f>] snd_hrtimer_callback+0x4f/0x2b0 sound/core/hrtimer.c:54 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&(&stime->lock)->rlock){-.....}: [<ffffffff81477693>] lock_acquire+0x1e3/0x460 kernel/locking/lockdep.c:3677 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:112 [<ffffffff867c005f>] _raw_spin_lock_irqsave+0x9f/0xd0 kernel/locking/spinlock.c:159 [<ffffffff85383baa>] snd_hrtimer_start+0x4a/0xf0 sound/core/hrtimer.c:112 [<ffffffff85379c74>] snd_timer_start1+0x2b4/0x5a0 sound/core/timer.c:457 [<ffffffff8537d33d>] snd_timer_start+0x5d/0xa0 sound/core/timer.c:571 [< inline >] seq_timer_start sound/core/seq/seq_timer.c:393 [<ffffffff853fc260>] snd_seq_timer_start+0x1a0/0x2b0 sound/core/seq/seq_timer.c:405 [< inline >] snd_seq_queue_process_event sound/core/seq/seq_queue.c:687 [<ffffffff853f6f14>] snd_seq_control_queue+0x304/0x8b0 sound/core/seq/seq_queue.c:748 [<ffffffff853fcbb5>] event_input_timer+0x25/0x30 sound/core/seq/seq_system.c:118 [<ffffffff853ef7d4>] snd_seq_deliver_single_event.constprop.11+0x3f4/0x740 sound/core/seq/seq_clientmgr.c:636 [<ffffffff853efc38>] snd_seq_deliver_event+0x118/0x800 sound/core/seq/seq_clientmgr.c:833 [<ffffffff853f1026>] snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418 [<ffffffff85405c2b>] send_timer_event.isra.0+0x10b/0x150 sound/core/seq/oss/seq_oss_timer.c:153 [<ffffffff8540615a>] snd_seq_oss_timer_start+0x1ca/0x310 sound/core/seq/oss/seq_oss_timer.c:174 [< inline >] old_event sound/core/seq/oss/seq_oss_event.c:125 [<ffffffff854095ff>] snd_seq_oss_process_event+0xa1f/0x2ce0 sound/core/seq/oss/seq_oss_event.c:100 [< inline >] insert_queue sound/core/seq/oss/seq_oss_rw.c:179 [<ffffffff8540c201>] snd_seq_oss_write+0x321/0x810 sound/core/seq/oss/seq_oss_rw.c:148 [<ffffffff85403f99>] odev_write+0x59/0xa0 sound/core/seq/oss/seq_oss.c:177 [<ffffffff817f3fc3>] __vfs_write+0x113/0x4b0 fs/read_write.c:529 [<ffffffff817f5a97>] vfs_write+0x167/0x4a0 fs/read_write.c:578 [< inline >] SYSC_write fs/read_write.c:625 [<ffffffff817f98d1>] SyS_write+0x111/0x220 fs/read_write.c:617 [<ffffffff867c0440>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 -> #0 (&(&timer->lock)->rlock){-.-...}: [< inline >] check_prev_add kernel/locking/lockdep.c:1823 [< inline >] check_prevs_add kernel/locking/lockdep.c:1933 [< inline >] validate_chain kernel/locking/lockdep.c:2238 [<ffffffff81474035>] __lock_acquire+0x3625/0x4d00 kernel/locking/lockdep.c:3298 [<ffffffff81477693>] lock_acquire+0x1e3/0x460 kernel/locking/lockdep.c:3677 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:112 [<ffffffff867c005f>] _raw_spin_lock_irqsave+0x9f/0xd0 kernel/locking/spinlock.c:159 [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 [<ffffffff85383e75>] snd_hrtimer_callback+0x185/0x2b0 sound/core/hrtimer.c:59 [< inline >] __run_hrtimer kernel/time/hrtimer.c:1242 [<ffffffff814d1071>] __hrtimer_run_queues+0x331/0xe90 kernel/time/hrtimer.c:1306 [<ffffffff814d3a42>] hrtimer_interrupt+0x182/0x430 kernel/time/hrtimer.c:1340 [<ffffffff8125aa52>] local_apic_timer_interrupt+0x72/0xe0 arch/x86/kernel/apic/apic.c:907 [<ffffffff867c2d59>] smp_apic_timer_interrupt+0x79/0xa0 arch/x86/kernel/apic/apic.c:931 [<ffffffff867c10ac>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:454 [< inline >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:118 [<ffffffff8120f402>] default_idle+0x52/0x370 arch/x86/kernel/process.c:307 [<ffffffff81210bba>] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:298 [<ffffffff81454c28>] default_idle_call+0x48/0xa0 kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call kernel/sched/idle.c:151 [< inline >] cpu_idle_loop kernel/sched/idle.c:242 [<ffffffff8145520f>] cpu_startup_entry+0x58f/0x7b0 kernel/sched/idle.c:291 [<ffffffff8679ac6d>] rest_init+0x18d/0x1a0 init/main.c:408 [<ffffffff88ce7759>] start_kernel+0x63a/0x660 init/main.c:661 [<ffffffff88ce6364>] x86_64_start_reservations+0x38/0x3a arch/x86/kernel/head64.c:195 [<ffffffff88ce64be>] x86_64_start_kernel+0x158/0x167 arch/x86/kernel/head64.c:176 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&stime->lock)->rlock); lock(&(&timer->lock)->rlock); lock(&(&stime->lock)->rlock); lock(&(&timer->lock)->rlock); *** DEADLOCK *** 1 lock held by swapper/0/0: #0: (&(&stime->lock)->rlock){-.....}, at: [<ffffffff85383d3f>] snd_hrtimer_callback+0x4f/0x2b0 sound/core/hrtimer.c:54 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc4+ #351 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffffffff87eb25c0 ffff88003ec07a50 ffffffff82c8f92f ffffffff00000000 fffffbfff0fd64b8 ffffffff8997bad0 ffffffff8997bad0 ffffffff8998aa70 ffffffff87e27510 ffffffff87e26d00 ffff88003ec07aa0 ffffffff8146cf58 Call Trace: <IRQ> [< inline >] __dump_stack lib/dump_stack.c:15 <IRQ> [<ffffffff82c8f92f>] dump_stack+0x12e/0x18f lib/dump_stack.c:51 [<ffffffff8146cf58>] print_circular_bug+0x288/0x340 kernel/locking/lockdep.c:1196 [< inline >] check_prev_add kernel/locking/lockdep.c:1823 [< inline >] check_prevs_add kernel/locking/lockdep.c:1933 [< inline >] validate_chain kernel/locking/lockdep.c:2238 [<ffffffff81474035>] __lock_acquire+0x3625/0x4d00 kernel/locking/lockdep.c:3298 [<ffffffff81477693>] lock_acquire+0x1e3/0x460 kernel/locking/lockdep.c:3677 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:112 [<ffffffff867c005f>] _raw_spin_lock_irqsave+0x9f/0xd0 kernel/locking/spinlock.c:159 [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 [<ffffffff85383e75>] snd_hrtimer_callback+0x185/0x2b0 sound/core/hrtimer.c:59 [< inline >] __run_hrtimer kernel/time/hrtimer.c:1242 [<ffffffff814d1071>] __hrtimer_run_queues+0x331/0xe90 kernel/time/hrtimer.c:1306 [<ffffffff814d3a42>] hrtimer_interrupt+0x182/0x430 kernel/time/hrtimer.c:1340 [<ffffffff8125aa52>] local_apic_timer_interrupt+0x72/0xe0 arch/x86/kernel/apic/apic.c:907 [<ffffffff867c2d59>] smp_apic_timer_interrupt+0x79/0xa0 arch/x86/kernel/apic/apic.c:931 [<ffffffff867c10ac>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:454 [< inline >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:118 [<ffffffff8120f402>] default_idle+0x52/0x370 arch/x86/kernel/process.c:307 [<ffffffff81210bba>] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:298 [<ffffffff81454c28>] default_idle_call+0x48/0xa0 kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call kernel/sched/idle.c:151 [< inline >] cpu_idle_loop kernel/sched/idle.c:242 [<ffffffff8145520f>] cpu_startup_entry+0x58f/0x7b0 kernel/sched/idle.c:291 [<ffffffff8679ac6d>] rest_init+0x18d/0x1a0 init/main.c:408 [<ffffffff88ce7759>] start_kernel+0x63a/0x660 init/main.c:661 [<ffffffff88ce6364>] x86_64_start_reservations+0x38/0x3a arch/x86/kernel/head64.c:195 [<ffffffff88ce64be>] x86_64_start_kernel+0x158/0x167 arch/x86/kernel/head64.c:176 They are also followed by rcu stalls and actual spinlock lockups: BUG: spinlock lockup suspected on CPU#3, syz-fuzzer/7040 lock: 0xffff880032ae2bd8, .magic: dead4ead, .owner: syz-executor/11206, .owner_cpu: 0 CPU: 3 PID: 7040 Comm: syz-fuzzer Not tainted 4.6.0-rc4+ #351 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffffffff87eb25c0 ffff88006d507c40 ffffffff82c8f92f ffffffff2c963698 fffffbfff0fd64b8 ffff880032ae2bd8 ffff88002c963040 ffff880061238040 ffff880032ae2be0 000000009a9d0630 ffff88006d507c78 ffffffff8147f58d Call Trace: <IRQ> [< inline >] __dump_stack lib/dump_stack.c:15 <IRQ> [<ffffffff82c8f92f>] dump_stack+0x12e/0x18f lib/dump_stack.c:51 [<ffffffff8147f58d>] spin_dump+0x14d/0x280 kernel/locking/spinlock_debug.c:67 [< inline >] __spin_lock_debug kernel/locking/spinlock_debug.c:117 [<ffffffff8147f8ad>] do_raw_spin_lock+0x15d/0x2b0 kernel/locking/spinlock_debug.c:137 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:119 [<ffffffff867c0067>] _raw_spin_lock_irqsave+0xa7/0xd0 kernel/locking/spinlock.c:159 [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 [<ffffffff85383e75>] snd_hrtimer_callback+0x185/0x2b0 sound/core/hrtimer.c:59 [< inline >] __run_hrtimer kernel/time/hrtimer.c:1242 [<ffffffff814d1071>] __hrtimer_run_queues+0x331/0xe90 kernel/time/hrtimer.c:1306 [<ffffffff814d3a42>] hrtimer_interrupt+0x182/0x430 kernel/time/hrtimer.c:1340 [<ffffffff8125aa52>] local_apic_timer_interrupt+0x72/0xe0 arch/x86/kernel/apic/apic.c:907 [<ffffffff867c2d59>] smp_apic_timer_interrupt+0x79/0xa0 arch/x86/kernel/apic/apic.c:931 [<ffffffff867c10ac>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:454 <EOI>

2 11

[alsa-devel] Unlikely big volume range Plantronics BT300
by Dennis Kadioglu 08 May '16

08 May '16

Hi, when I connect the bluetooth BT300 of my Plantronics Headset I can see the following warning: [172855.985539] usb 2-1.3: Warning! Unlikely big volume range (=720), cval->res is probably wrong. [172855.985544] usb 2-1.3: [5] FU [PCM Playback Volume] ch = 1, val = -10240/1280/16 As far as I understand it, the problem may be solved by applying a quirk which is already applied for Logitech webcams. Can somebody help me in finding out the correct value for cval->res. I have no clue which calculations are necessary for that. Thanks in advance. Dennis Kadioglu

2 2

Re: [alsa-devel] WM5102 - Help to make baytrail machine driver work
by Pierre-Louis Bossart 07 May '16

07 May '16

On 5/4/16 8:21 PM, Paulo Sergio wrote: > Hi list, > > I've been trying to make Lenovo Yoga 2 (Model 1051F) sound work on > Android-x86/ Linux. [1] > > Based on already discussed info from Christian Hartmann with members > (see [2] and [3] ) of this list and some efforts (basically patch pxa2xx > with Mika Westerberg changes, set the correct gpio int values {246 for > reset / 405 for ldoena and 342 for irq_gpio} and set LDO1 vcc suppliers) > we could have wm5102 initialized through spi / regmap (arizona code on > drivers/mfd) and register the DAI's. > > I also ported a machine driver code from a kernel Lenovo made available > for a similar hardware (Lenovo yoga 2 1050 - uses the same baytrail > Z3745 and wolfson wm5102 audio) [4] There are quite a few references in the machine driver to concepts related to Clovertrail+ and early versions of Baytrail. I am fairly convinced the mentions of 'BYT_COMMS_BT' or 'modem mixing' are no longer supported with the DPCM platform driver/firmware you used. To enable this codec it would be simpler to start with a newer machine driver derived from the bytcr_rt5640 one, with just a basic SSP0-aif1 link for starters (+ MCLK). Better yet, do this work with a MinnowBoard and an WM5102 eval board and test all this with more control on how the hardware is setup. If you stick to working directly on the Lenovo device, make sure you use all the DSP controls set in the UCM files used for baytrail/baytrail-CR (see github.com/plbossart/UCM). > > Although machine driver is registered, we still don't have sound. Tried > some mixer settings / routes used on raspberry pi, but none help. > Application (in this case alsa / Android players) returns a "Device or > resource busy" when trying to ioctl pcm device: > > 04-30 13:05:07.877 1784 2078 E audio_hw_primary: out_write: error -1 - cannot prepare channel: Device or resource busy > > # This is raised here (external/tinyalsa/pcm.c): > > if (ioctl(pcm->fd, SNDRV_PCM_IOCTL_PREPARE) < 0) > > return oops(pcm, errno, "cannot prepare channel"); > > > Note: As pointed here [5] had to change the acpi_ipc_irq_index to 0 on > sound/soc/intel/atom/sst/sst_acpi.c because this is the 1st ACPI entry > listed on DSDT > I'm also trying to use a fw version that uses SSP0 [6] instead of SSP2 > used as default - but no sound with both > > > I'd like some help from you in order to make this work. I've collect > several info which can be found here [7] > - /proc/asound/cards > - /proc/interrupts > - amixer controls list > - dmesg > - DSDT file (decoded with iasl) > > > Source code with changes made so far is available on github [8] > > Any hint is appreciated > > Thanks, > Paulo Sérgio Travaglia (pstglia) > > > [1] - https://groups.google.com/forum/#!forum/android-x86 > [2] - http://www.spinics.net/lists/linux-acpi/msg58680.html > [3] - https://goo.gl/vBKOeI > [4] - http://goo.gl/zriwbw > [5] - https://bugzilla.kernel.org/show_bug.cgi?id=86581 > [6] - http://thread.gmane.org/gmane.linux.alsa.devel/134554/focus=140634 > [7] > - https://drive.google.com/folderview?id=0BxO6THtB865fWjVHLTFfV25ORjQ&usp=sha… > [8] - https://github.com/pstglia/linux

2 1