On Tue, 02 May 2017 22:15:20 +0200, Pierre-Louis Bossart wrote:
On 5/2/17 1:27 PM, Ville Syrjälä wrote:
On Mon, May 01, 2017 at 08:29:10PM -0500, Pierre-Louis Bossart wrote:
On 04/28/2017 02:37 PM, Ville Syrjälä wrote:
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@linux.intel.com wrote: > From: Ville Syrjälä ville.syrjala@linux.intel.com > > 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@suse.de > Cc: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com All look good, and feel free to take my reviewed-by tag Reviewed-by: Takashi Iwai tiwai@suse.de
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.
There was an standard PORT_B off-by-one error which resulted in memory corruption.
Doh.
the patch below seems to fix the problem, I can get the same functionality as before with concurrent playback on HDMI and DP, and the jack values are correctly set.
Thanks. I do wonder a bit which side should apply this offset. But I guess it doesn't really matter in the end as long as both sides know what the deal is. So unless there are good reasons for anything else I'll just squash this into my patch(es).
Fine with me. One open I still have is that it's not self-explanatory for the user to figure out which output the devices correspond to, e.g. on my CHT device HDMI is device 2 and DP is device 0. I may be mistaken but in the previous pipe-based solution, audio playback would progress at a normal rate even if nothing was connected. With the port-based, it looks like playback doesn't progress if there is nothing connected - speaker-test is stuck. Not sure if the open or hw_params should fail in that case? One could argue that the user should know better and check the jack status, but in reality I don't think any userspace layer will ever do this.
It's the problem we've had from the beginning. If the open fails, PA can't detect the PCM device at probe time, and it's gone forever until PA gets restarted. It's no hotplug device, thus the PCM streams are determined only once.
So, the open and co are accepted even without the connection but the actual playback fails -- it's implemented in that way as a workaround for PA.
Takashi