From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76935C43387 for ; Sun, 30 Dec 2018 09:21:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 44C4320866 for ; Sun, 30 Dec 2018 09:21:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726114AbeL3JVH (ORCPT ); Sun, 30 Dec 2018 04:21:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:43418 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726038AbeL3JVH (ORCPT ); Sun, 30 Dec 2018 04:21:07 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 96DE4AE9D; Sun, 30 Dec 2018 09:21:04 +0000 (UTC) Date: Sun, 30 Dec 2018 10:21:04 +0100 Message-ID: From: Takashi Iwai To: Linus Torvalds Cc: Takashi Iwai , Ingo Molnar , Pierre-Louis Bossart , Mark Brown , Liam Girdwood , Linux Kernel Mailing List Subject: Re: [GIT PULL] sound updates for 4.21 In-Reply-To: References: <20181228124303.GA16558@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/26 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Dec 2018 20:04:48 +0100, Linus Torvalds wrote: > > On Fri, Dec 28, 2018 at 9:07 AM Takashi Iwai wrote: > > > > 1) Whether ASoC driver cannot work with these Dell machines at all > > I'm willing to test patches. > > Right now, the reason it fails to even load is that "codec_mask" is 0x0001. > > And the skl_hda_dsp_generic.c code requires > > // This will be 1 for 0x0001 > codec_count = hweight_long(codec_mask); > > if (codec_count == 1 && codec_mask & IDISP_CODEC_MASK) { > .. this is ok .. > } else if (codec_count == 2 && codec_mask & IDISP_CODEC_MASK) { > .. as is this .. > } else { > .. but here we return -EINVAL; > } > > and that basically requires that IDISP_CODEC_MASK be part of > codec_mask. Which it isn't (IDISP_CODEC_MASK is 0x4). > > Anyway, as long as the ASoC driver refuses to touch this, the default > pretty much *has* to be the legacy PCI driver. Thanks, the above seems to be the likely cause. This is a good news and a bad news, actually. The good news is that we know the cause, and this can be detected earlier, too. The bad news is that the possible detection (the probe of codec mask) is done in an async probe work in the legacy HDA driver, hence the PCI driver probe() call cannot return -ENODEV for this. And, it brings me a question: does the audio routing work without iDISP at all? The current code looks mandating the iDISP, and I thought this is a core part of HD-audio routing on DSP. Intel people, could you clarify this? If iDISP is mandatory and really missing on these machines, we need another way to identify such systems without codec mask checks. Maybe DMI or such listing; ugly but should be still manageable since the number of devices hitting the problem must be fairly low. Or, an alternative is to let ASoC driver bind at first, e.g. by changing the driver name from snd-soc-skl to snd-hda-asoc, and drop the selective binding from snd-hda-intel, so that it'd work as catch-all after binding with ASoC fails. The above would work for the modules, but for built-in, we need to rearrange the link order, too, supposedly. (For the mixed case with built-in and module? I don't know, maybe we may forgive us by the presence of module options to control the binding.) BTW, one thing I'd really like to avoid is to rearrange the probe procedure of the legacy HDA driver (so that we can get codec_mask during pci probe() call). The async probe is the result of the many struggles with the various and complex configurations. Moving the codec probe to the beginning isn't trivial and quite risky to break something else. thanks, Takashi