From: Roy Spliet <nouveau@spliet.org>
To: Karol Herbst <kherbst@redhat.com>,
Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
"moderated list:SOUND" <alsa-devel@alsa-project.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Takashi Iwai <tiwai@suse.de>,
nouveau <nouveau@lists.freedesktop.org>,
tiwai@suse.com, open list <linux-kernel@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Alan Stern <stern@rowland.harvard.edu>,
Mike Rapoport <rppt@kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Alex Deucher <alexander.deucher@amd.com>,
Jaroslav Kysela <perex@perex.cz>
Subject: Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
Date: Sat, 10 Apr 2021 16:51:27 +0100 [thread overview]
Message-ID: <d01e375f-bf16-a005-ec66-0910956cc616@spliet.org> (raw)
In-Reply-To: <CACO55tsPx_UC3OPf9Hq9sGdnZg9jH1+B0zOi6EAxTZ13E1tf7A@mail.gmail.com>
Reviving this thread as we have another user (rightfully) complaining on
IRC about this.
The way I see it there's two issues:
1) snd_hda_intel not allowing runpm (or w/e vgaswitcheroo needs) when
there's missing codecs, inhibiting the entire GPU from performing runpm.
This needlessly wastes lots of battery power.
2) HDMI audio not working on such machines unless it was plugged in at
boot-time.
The original workarounds proposed by Kai-Heng seem to fix 1), which is
progress. I don't see a reason why that should be held off even if it
doesn't fix 2).
To fix 2), more work is needed. On a high level, I suspect nouveau
should start controlling the enabling/disabling of the HDA controller
based on connector events and/or connector state at module load.
Currently the PCI quirk seems to enable it wholesale, and I don't know
why. If no GPU driver is loaded, it's pointless to turn the HDA device
on. The blob presumably doesn't need this either, as it can control the
device just as well as nouveau. If it doesn't, NVIDIA should fix it
rather than rely on this quirk. The only reason I can think of is that
snd_hda_intel or vgaswitcheroo isn't prepared for hot(un)plugging (or
alternatively reprobing) devices. Without that, we presumably won't
solve issue 2). Can I ask someone with more technical knowledge of
snd_hda_intel and vgaswitcheroo to brainstorm about the possible
challenges of nouveau taking matters into its own hand rather than
keeping this PCI quirk around?
Roy
Op 04-01-2021 om 13:20 schreef Karol Herbst:
> On Tue, Dec 22, 2020 at 3:50 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>> On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>>>
>>> On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
>>> <kai.heng.feng@canonical.com> wrote:
>>>>
>>>> [+Cc nouveau]
>>>>
>>>> On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai <tiwai@suse.de> wrote:
>>>> [snip]
>>>>>> Quite possibly the system doesn't power up HDA controller when there's
>>>>>> no external monitor.
>>>>>> So when it's connected to external monitor, it's still needed for HDMI audio.
>>>>>> Let me ask the user to confirm this.
>>>>>
>>>>> Yeah, it's the basic question whether the HD-audio is supposed to work
>>>>> on this machine at all. If yes, the current approach we take makes
>>>>> less sense - instead we should rather make the HD-audio controller
>>>>> working.
>>>>
>>>> Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
>>>>
>>>>>>> - The second problem is that pci_enable_device() ignores the error
>>>>>>> returned from pci_set_power_state() if it's -EIO. And the
>>>>>>> inaccessible access error returns -EIO, although it's rather a fatal
>>>>>>> problem. So the driver believes as the PCI device gets enabled
>>>>>>> properly.
>>>>>>
>>>>>> This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix
>>>>>> regression in pci_enable_device_bars") to fix UHCI controller.
>>>>>>
>>>>>>>
>>>>>>> - The third problem is that HD-audio driver blindly believes the
>>>>>>> codec_mask read from the register even if it's a read failure as I
>>>>>>> already showed.
>>>>>>
>>>>>> This approach has least regression risk.
>>>>>
>>>>> Yes, but it assumes that HD-audio is really non-existent.
>>>>
>>>> I really don't know any good approach to address this.
>>>> On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the
>>>> driver will flag the magic bit to make HDA audio appear on the PCI
>>>> bus.
>>>> IIRC the current approach is to make nouveau and device link work.
>>>
>>> I don't have the full context of this discussion, but the kernel
>>> force-enables the HDA subfunction nowadays, irrespective of nouveau or
>>> nvidia or whatever:
>>
>> That's the problem.
>>
>> The nvidia HDA controller on the affected system only gets its power
>> after HDMI cable plugged, so the probe on boot fails.
>>
>
> it might be that the code to enable the sub function is a bit broken
> :/ but it should work. Maybe the quirk_nvidia_hda function needs to be
> called on more occasions? No idea.
>
>> Kai-Heng
>>
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/quirks.c?h=v5.10#n5267
>>>
>>> Cheers,
>>>
>>> -ilia
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
>>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
next prev parent reply other threads:[~2021-04-10 16:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201214060621.1102931-1-kai.heng.feng@canonical.com>
[not found] ` <20201216124726.2842197-1-kai.heng.feng@canonical.com>
[not found] ` <s5h5z51oj12.wl-tiwai@suse.de>
[not found] ` <CAAd53p6kORC1GsW5zt+=0=J5ki43iriO-OqtFvf5W67LWhyyhA@mail.gmail.com>
[not found] ` <s5hzh2dn3oa.wl-tiwai@suse.de>
[not found] ` <CAAd53p6Ef2zFX_t3y1c6O7BmHnxYGtGSfgzXAMQSom1ainWXzg@mail.gmail.com>
[not found] ` <s5hsg85n2km.wl-tiwai@suse.de>
[not found] ` <s5hmtydn0yg.wl-tiwai@suse.de>
2020-12-18 5:09 ` [PATCH v2] ALSA: hda: Continue to probe when codec probe fails Kai-Heng Feng
2020-12-18 8:06 ` Takashi Iwai
2020-12-21 16:33 ` Kai-Heng Feng
2020-12-21 16:47 ` Takashi Iwai
2020-12-21 17:15 ` Kai-Heng Feng
2020-12-21 17:56 ` [Nouveau] " Ilia Mirkin
2020-12-22 2:49 ` Kai-Heng Feng
2021-01-04 13:20 ` Karol Herbst
2021-04-10 15:51 ` Roy Spliet [this message]
2021-04-10 19:23 ` Lukas Wunner
2021-04-10 20:48 ` Roy Spliet
2021-04-12 19:06 ` Aaron Plattner
2021-04-12 19:36 ` Roy Spliet
2021-04-12 20:00 ` Aaron Plattner
2021-04-12 20:03 ` Ilia Mirkin
2021-04-13 0:10 ` Karol Herbst
2021-04-13 8:24 ` Roy Spliet
2021-04-13 9:48 ` Karol Herbst
2021-04-13 11:17 ` Roy Spliet
2021-04-13 11:49 ` Karol Herbst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d01e375f-bf16-a005-ec66-0910956cc616@spliet.org \
--to=nouveau@spliet.org \
--cc=alexander.deucher@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=bhelgaas@google.com \
--cc=kai.heng.feng@canonical.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=kherbst@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rppt@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).