On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote: > > > On 04/28/2017 03:41 AM, Takashi Iwai wrote: > > On Thu, 27 Apr 2017 18:02:19 +0200, > > ville.syrjala@xxxxxxxxxxxxxxx wrote: > >> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > >> > >> Okay, here's the second attempt at getting multiple pipes playing back > >> audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is > >> that now the PCM devices are associated with ports instead of pipes, > >> so the audio from one device always gets output on the same display. > >> > >> I've also tacked on the alsa-lib conf update. No clue whether it's > >> really correct or not (the config language isn't a close friend > >> of mine). > >> > >> BTW I did notice that with LPE audio all the controls say iface=PCM, > >> whereas on HDA a bunch of them say iface=MIXER. No idea if that's > >> OK or not, just something I spotted when I was comparing the results > >> with HDA. > > We generally accept both iface types for IEC958 stuff, since > > historically many drivers have already mixed them up. So it's no > > problem :) > > > > > >> Entire series available here: > >> git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2 > >> > >> Cc: Takashi Iwai <tiwai@xxxxxxx> > >> Cc: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > > All look good, and feel free to take my reviewed-by tag > > Reviewed-by: Takashi Iwai <tiwai@xxxxxxx> > > > > As said previously, my only slight concern is the compatibility. > > But, in the current situation with PulseAudio, only few people would > > use this driver, so it shouldn't be so big impact, I suppose. > > > > BTW, which port is used in general on BYT/CHT? > > > > Oh, also, I suppose you want to carry these over i915 tree? > > I don't mind either way, I can take them through sound tree if > > preferred, too. > I see frequent oops on startup with this lpe_audio_multipipe_2 branch > with my CHT device not booting or no HDMI audio device created. > Not sure if these issues are due to the new patches or to the rest of > the drm code? > > [ 5.529023] BUG: unable to handle kernel NULL pointer dereference > at (null) > [ 5.529143] IP: hdmi_lpe_audio_probe+0x40f/0x650 [snd_hdmi_lpe_audio] > [ 5.529202] PGD 0 > > [ 5.529242] Oops: 0000 [#1] SMP > [ 5.529274] Modules linked in: snd_soc_sst_atom_hifi2_platform > snd_soc_sst_match snd_soc_core snd_compress lpc_ich snd_seq > snd_seq_device shpchp snd_hdmi_lpe_audio(+) snd_pcm snd_timer dw_dmac > snd soundcore i2c_designware_platform(+) i2c_designware_core > spi_pxa2xx_platform acpi_pad mac_hid nfsd auth_rpcgss nfs_acl lockd > grace sunrpc ip_tables x_tables hid_generic mmc_block i2c_hid usbhid hid > autofs4 > [ 5.529605] CPU: 2 PID: 512 Comm: systemd-udevd Not tainted > 4.11.0-rc8-test+ #11 > [ 5.529671] Hardware name: ZOTAC XXXXXX/Cherry Trail FFD, BIOS 5.11 > 09/28/2016 > [ 5.529736] task: ffff88007485b780 task.stack: ffffc90000bfc000 > [ 5.529793] RIP: 0010:hdmi_lpe_audio_probe+0x40f/0x650 > [snd_hdmi_lpe_audio] > [ 5.529855] RSP: 0018:ffffc90000bffaf0 EFLAGS: 00010246 > [ 5.529904] RAX: 0000000000000000 RBX: ffff880079209898 RCX: > ffff88007920f078 > [ 5.529967] RDX: 0000000000000014 RSI: ffffc90000bffb28 RDI: > 0000000000000002 > [ 5.530031] RBP: ffffc90000bffb70 R08: 0000000000000001 R09: > 0000000000000000 > [ 5.530094] R10: ffff88007441bf00 R11: ffffc90000bffb36 R12: > ffff88007920ef20 > [ 5.530159] R13: ffff88007920ef48 R14: 0000000000005688 R15: > 0000000000000047 > [ 5.530225] FS: 00007f627c988640(0000) GS:ffff88007b300000(0000) > knlGS:0000000000000000 > [ 5.530299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 5.530352] CR2: 0000000000000000 CR3: 0000000078cb8000 CR4: > 00000000001006e0 > [ 5.530416] Call Trace: > [ 5.530452] platform_drv_probe+0x3b/0xa0 > [ 5.530494] driver_probe_device+0x2bb/0x460 > [ 5.530538] __driver_attach+0xdf/0xf0 > [ 5.530576] ? driver_probe_device+0x460/0x460 > [ 5.530620] bus_for_each_dev+0x60/0xa0 > [ 5.530658] driver_attach+0x1e/0x20 > [ 5.530693] bus_add_driver+0x170/0x270 > [ 5.530731] driver_register+0x60/0xe0 > [ 5.530769] ? 0xffffffffa01cb000 > [ 5.530803] __platform_driver_register+0x36/0x40 > [ 5.530851] hdmi_lpe_audio_driver_init+0x17/0x1000 [snd_hdmi_lpe_audio] > [ 5.530915] do_one_initcall+0x43/0x180 > [ 5.530956] ? __vunmap+0x81/0xd0 > [ 5.530991] ? kfree+0x14c/0x160 > [ 5.531024] ? kmem_cache_alloc_trace+0x38/0x150 > [ 5.531070] do_init_module+0x5f/0x1f8 > [ 5.531108] load_module+0x271e/0x2bd0 > [ 5.531147] ? kernel_read_file+0x1a3/0x1c0 > [ 5.531188] SYSC_finit_module+0xbc/0xf0 > [ 5.531226] ? SYSC_finit_module+0xbc/0xf0 > [ 5.531267] SyS_finit_module+0xe/0x10 > [ 5.531305] do_syscall_64+0x6e/0x180 > [ 5.531345] entry_SYSCALL64_slow_path+0x25/0x25 > [ 5.531389] RIP: 0033:0x7f627b5fbbf9 > [ 5.531424] RSP: 002b:00007ffe053eee68 EFLAGS: 00000246 ORIG_RAX: > 0000000000000139 > [ 5.531493] RAX: ffffffffffffffda RBX: 000055d6c745b690 RCX: > 00007f627b5fbbf9 > [ 5.531558] RDX: 0000000000000000 RSI: 00007f627c134995 RDI: > 0000000000000007 > [ 5.531622] RBP: 00007f627c134995 R08: 0000000000000000 R09: > 00007ffe053eef80 > [ 5.531687] R10: 0000000000000007 R11: 0000000000000246 R12: > 0000000000000000 > [ 5.531751] R13: 000055d6c7459ae0 R14: 0000000000020000 R15: > 000055d6c745b690 > [ 5.531816] Code: 48 8b 45 b0 8b 48 18 e8 e0 cb 22 e1 49 8b 44 24 28 > 4a 8d 8c 33 58 01 00 00 48 8d 75 b8 45 31 c9 41 b8 01 00 00 00 ba 14 00 > 00 00 <48> 8b 38 e8 a9 2a ff ff 85 c0 0f 88 09 01 00 00 49 8b 84 24 58 Disassembling that I get: 4005a0: 48 8b 45 b0 mov -0x50(%rbp),%rax 4005a4: 8b 48 18 mov 0x18(%rax),%ecx 4005a7: e8 e0 cb 22 e1 callq ffffffffe162d18c <_end+0xffffffffe102c14c> 4005ac: 49 8b 44 24 28 mov 0x28(%r12),%rax 4005b1: 4a 8d 8c 33 58 01 00 lea 0x158(%rbx,%r14,1),%rcx 4005b8: 00 4005b9: 48 8d 75 b8 lea -0x48(%rbp),%rsi 4005bd: 45 31 c9 xor %r9d,%r9d 4005c0: 41 b8 01 00 00 00 mov $0x1,%r8d 4005c6: ba 14 00 00 00 mov $0x14,%edx 4005cb: 48 8b 38 mov (%rax),%rdi 4005ce: e8 a9 2a ff ff callq 3f307c <_init-0xd32c> 4005d3: 85 c0 test %eax,%eax 4005d5: 0f 88 09 01 00 00 js 4006e4 <__GNU_EH_FRAME_HDR+0x100> 4005db: 49 rex.WB 4005dc: 8b .byte 0x8b 4005dd: 84 24 58 test %ah,(%rax,%rbx,2) Comparing that with the disassembly from my build, that first call looks like the snprintf() and the second one would then be snd_jack_new(). So it seems to blow in the ctx->card_ctx->card dereference. But I don't really see how a NULL pointer could sneak in there. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
