https://bugs.freedesktop.org/show_bug.cgi?id=75985
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #121 from Przemysław Kopa ---
(In reply to Lukas Wunner from comment #120)
> Okay the culprit is a tool called "tlp" which disables runtime PM on the HDA
> controller via sysfs:
Thanks, I fixed it by adding RUNTIME_PM_BLACKLIST="01:00
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #120 from Lukas Wunner ---
(In reply to Przemysław Kopa from comment #118)
> (In reply to Lukas Wunner from comment #116)
> > There's one problem remaining, you shouldn't have to manually echo "auto" to
> > the HDA's control file beca
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #119 from Przemysław Kopa ---
Created attachment 145830
--> https://bugs.freedesktop.org/attachment.cgi?id=145830&action=edit
Dmesg dump
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #118 from Przemysław Kopa ---
(In reply to Lukas Wunner from comment #116)
> @Przemysław Kopa:
>
> The fix was applied by Takashi Iwai on Thursday Oct 17 with commit
> 94989e318b2f, it was merged to Linus' tree on Friday Oct 18 and w
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #117 from Lukas Wunner ---
Created attachment 145778
--> https://bugs.freedesktop.org/attachment.cgi?id=145778&action=edit
Debug patch to log invocations of pm_runtime_forbid()
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #116 from Lukas Wunner ---
@Przemysław Kopa:
The fix was applied by Takashi Iwai on Thursday Oct 17 with commit
94989e318b2f, it was merged to Linus' tree on Friday Oct 18 and will thus be
part of v5.4-rc4 due out later today. It sho
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #115 from Przemysław Kopa ---
(In reply to Lukas Wunner from comment #114)
> HDA_CODEC_ENTRY() needs to match for the 32-bit HD audio vendor ID. Just to
> double-check, could you execute "cat
> /sys/bus/pci/devices/:01:00.1/hdaudi
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #114 from Lukas Wunner ---
(In reply to Przemysław Kopa from comment #113)
> (In reply to Lukas Wunner from comment #112)
> > Glad to hear. You don't seem to have any commits in the kernel so far. Would
> > you like to try and bake th
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #113 from Przemysław Kopa ---
(In reply to Lukas Wunner from comment #112)
>
> Glad to hear. You don't seem to have any commits in the kernel so far. Would
> you like to try and bake these changes into a proper patch? If not I'll
> gl
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #112 from Lukas Wunner ---
(In reply to Przemysław Kopa from comment #111)
> (In reply to Lukas Wunner from comment #110)
> > What does "cat /sys/bus/pci/devices/:01:00.1/hdaudioC1D0/revision_id"
> > say?
> It says: 0x100100
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #111 from Przemysław Kopa ---
(In reply to Lukas Wunner from comment #110)
> What does "cat /sys/bus/pci/devices/:01:00.1/hdaudioC1D0/revision_id" say?
It says: 0x100100
> If you add "codec->link_down_at_suspend = 1;" to patch_nv
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #110 from Lukas Wunner ---
(In reply to Przemysław Kopa from comment #109)
> Created attachment 145640 [details]
> Dmesg dump to present the problem of NVIDIA HDA not suspending correctly #2.
Thanks. This is the same issue as bug #10
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #109 from Przemysław Kopa ---
Created attachment 145640
--> https://bugs.freedesktop.org/attachment.cgi?id=145640&action=edit
Dmesg dump to present the problem of NVIDIA HDA not suspending correctly #2.
--
You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #108 from Daniel Drake ---
If codec devices are always child devices of the controller, then I also wonder
if codec_powered could be completely removed.
Seems like the PM core already ensures the children are inactive before
suspendi
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #107 from Lukas Wunner ---
(In reply to Daniel Drake from comment #105)
> codec_powered has value 0xf which means bits 0,1,2,3 are set. Bit 15 would
> be 0x8000.
Ugh, indeed, thanks for having my back Daniel, I should stay away from
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #106 from Lukas Wunner ---
Created attachment 145627
--> https://bugs.freedesktop.org/attachment.cgi?id=145627&action=edit
HDA runtime PM debug patch #2 for v5.3
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #105 from Daniel Drake ---
codec_powered has value 0xf which means bits 0,1,2,3 are set. Bit 15 would be
0x8000.
But I agree with the next step of looking closer at accesses to this variable.
Thanks for jumping on that!
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #104 from Lukas Wunner ---
(In reply to Daniel Drake from comment #102)
> Thanks. azx_runtime_idle() is returning EBUSY because
> azx_bus(chip)->codec_powered=0xf.
>
> codec_powered is set during initialization via snd_hdac_bus_add_d
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #103 from Przemysław Kopa ---
(In reply to Daniel Drake from comment #102)
> Under /sys/bus/pci/devices/:01:00.1 you should see some subdirectories
> that are named hdaudioC?D?. Those subdirectories in turn have power
> subdirecto
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #102 from Daniel Drake ---
Thanks. azx_runtime_idle() is returning EBUSY because
azx_bus(chip)->codec_powered=0xf.
codec_powered is set during initialization via snd_hdac_bus_add_device(),
presumably to reflect that the device is def
https://bugs.freedesktop.org/show_bug.cgi?id=75985
Przemysław Kopa changed:
What|Removed |Added
Attachment #145615|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #100 from Przemysław Kopa ---
Created attachment 145615
--> https://bugs.freedesktop.org/attachment.cgi?id=145615&action=edit
Dmesg dump to present the problem of NVIDIA HDA not suspending correctly.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #99 from Przemysław Kopa ---
Here is the dmesg dump generated when running patched kernel.
--
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #98 from Lukas Wunner ---
Created attachment 145614
--> https://bugs.freedesktop.org/attachment.cgi?id=145614&action=edit
HDA runtime PM debug patch for v5.3
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #97 from Lukas Wunner ---
(In reply to Przemysław Kopa from comment #87)
> (In reply to Lukas Wunner from comment #86)
> > Please provide the output of "grep .
> > /sys/bus/pci/devices/:01:00.1/power/*" after echoing "auto" to its
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #96 from Maik Freudenberg ---
Partly unrelated but important, just enabling runtime pm on a turing gpu
without removing the subdevices as per the linked document leads to a
_devastating_ effect, the idle power consumption rising to in
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #95 from Maik Freudenberg ---
This is very fresh, about 1 month old, context is that the latest nvidia 435
driver added support for render offload and driver controlled dynamic runtime
pm (turing only).
So I don't expect Nvidia to tal
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #94 from Daniel Drake ---
Sorry getting mixed up. Those last questions were went for Maik.
--
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #93 from Daniel Drake ---
Yes, that looks like history.
Lukas, do you have any further context on that link? Is it a historical remnant
or something still relevant? Which upstream kernel changes are being done to
fix it?
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #92 from Przemysław Kopa ---
(In reply to Daniel Drake from comment #91)
> That looks promising! Since you are the bug reporter, could you please test
> it?
> Or have you already confirmed that it fixes the issue reported here?
Am I
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #91 from Daniel Drake ---
(In reply to Przemysław Kopa from comment #90)
> Wasn't this bug fixed already?
> https://github.com/torvalds/linux/commit/
> fc09ab7a767394f9ecdad84ea6e85d68b83c8e21
That looks promising! Since you are the
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #90 from Przemysław Kopa ---
(In reply to Maik Freudenberg from comment #89)
> > 2. There is a known issue with the audio driver due to which the audio PCI
> > function remains in an active state from the kernel version 4.19 and up.
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #89 from Maik Freudenberg ---
I didn't follow all of this, but I suspect you're hitting a known bug, please
see
http://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/dynamicpowermanagement.html#KnownIssuesAndW6426e
> 2. There
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #88 from Daniel Drake ---
So we don't have clear insight as to why the device is not being runtime
suspended. I'll try to reproduce in our lab.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #87 from Przemysław Kopa ---
(In reply to Lukas Wunner from comment #86)
> Please provide the output of "grep .
> /sys/bus/pci/devices/:01:00.1/power/*" after echoing "auto" to its
> "control" file.
Here it is:
/sys/bus/pci/devic
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #86 from Lukas Wunner ---
Please provide the output of "grep . /sys/bus/pci/devices/:01:00.1/power/*"
after echoing "auto" to its "control" file.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #85 from Przemysław Kopa ---
> Something has forced the HDA on, hence it doesn't autosuspend.
>
> Does the issue go away if you re-enable runtime suspend? Try:
>
> echo auto > /sys/bus/pci/devices/:01:00.1/power/control
Unfortu
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #84 from Lukas Wunner ---
(In reply to Przemysław Kopa from comment #83)
> This is the output of grep . /sys/bus/pci/devices/:01:00.1/power/*:
>
> /sys/bus/pci/devices/:01:00.1/power/control:on
Something has forced the HDA o
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #83 from Przemysław Kopa ---
> Check the runtime PM status of the HDA:
> grep . /sys/bus/pci/devices/:01:00.1/power/*
This is the output of grep . /sys/bus/pci/devices/:01:00.1/power/*:
/sys/bus/pci/devices/:01:00.1/powe
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #82 from Lukas Wunner ---
(In reply to Przemysław Kopa from comment #81)
> (In reply to Daniel Drake from comment #80)
> > A patch titled "PCI: Enable NVIDIA HDA controllers" (effecively attachment
> > #137939 [details] [review]) is h
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #81 from Przemysław Kopa ---
(In reply to Daniel Drake from comment #80)
> A patch titled "PCI: Enable NVIDIA HDA controllers" (effecively attachment
> #137939 [details] [review]) is headed into linux-next and potentially Linux
> 5.3.
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #80 from Daniel Drake ---
A patch titled "PCI: Enable NVIDIA HDA controllers" (effecively attachment
#137939) is headed into linux-next and potentially Linux 5.3. Testing
appreciated!
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #79 from Daniel Drake ---
Thanks, you're right, the value changes based on HDMI connector status.
So for this platform, \_SB.PCI0.PEG0 has a PG00 PowerResource that will set the
magic bit in _ON, and likewise \_SB.PCI0.PEG0.PEGP has
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #78 from Lukas Wunner ---
(In reply to Daniel Drake from comment #77)
> MLTF presumably means multifunction and it's exactly the bit we've been
> working with. But I haven't yet managed to get _PS0 to run this code. I get
> to the GGI
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #77 from Daniel Drake ---
Created attachment 144596
--> https://bugs.freedesktop.org/attachment.cgi?id=144596&action=edit
Acer Predator G3-572 acpidump
Martin Lopatář, thanks for the analysis above, sorry I missed those details
bef
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #76 from Maik Freudenberg ---
(In reply to jonasz from comment #75)
> Hi guys,
>
> I have a dell t7610 centOS installation with two K6000 gpus with the latest
> available firmware installed. These gpus have two DisplayPorts and two D
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #75 from jon...@mac.com ---
Hi guys,
I have a dell t7610 centOS installation with two K6000 gpus with the latest
available firmware installed. These gpus have two DisplayPorts and two DVI
ports each.
There is no hdmi sound coming fro
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #74 from Eugene Medvedev ---
(In reply to Maik Freudenberg from comment #27)
> Created attachment 136418 [details]
> Kernel module to toggle audio function
I have a somewhat strange variation on the bug when using your kernel module
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #73 from fhe...@gmail.com ---
Hi all, I can confirm that the module posted by Maik Freudenberg [Comment 27]
works nicely: I can turn the HDMI audio on/off on the fly with no problems at
all!
Thank you very much!
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #72 from Mark Ackerman ---
Mark Thank you SO Much.
Now my seventh day with this new Hp Omen X 17-ap0xx and its' Nvidia GTX 1080m
(Hp's most awesome Laptop / GPU as of today WooHoo), and I always have despised
Windows and stuck
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #71 from Maik Freudenberg ---
So you're talking about the driver toggling the bit and emitting a general
hotplug event to trigger a rescan of the pci bus? Having one of those would
sure be handy.
(You can imagine in windows a daemon t
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #70 from Aaron Plattner ---
How the audio and video drivers interact is described a bit in [1]: The audio
function and the graphics function work hand-in-hand to provide audio support.
At modeset time, the graphics driver extracts inf
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #69 from Daniel Drake ---
Thanks for the efforts here. I have tested the switcheroo_devlink_v2 branch
plus patches:
[PATCH 1/3] PCI: Expose Nvidia HDA controllers
[PATCH 2/3] PCI: Apply quirks on runtime resume despite being unbou
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #68 from Lukas Wunner ---
Created attachment 137989
--> https://bugs.freedesktop.org/attachment.cgi?id=137989&action=edit
Patch to simulate hidden HDA on systems which normally expose it
This is a quick & dirty hack to hide the HDA
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #67 from Maik Freudenberg ---
(In reply to Lukas Wunner from comment #66)
> Hm, the multifunction bit is set. Try adding an msleep(100) after setting
> the bit at offset 0x488 and before re-reading the header type register. 100
> ms i
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #66 from Lukas Wunner ---
(In reply to Maik Freudenberg from comment #65)
> Now with the acpi bug fixed, I applied both of your v2 patchsets with some
> nip/tuck to a 4.16rc4+ kernel and ran into the next oddity: while the pci
> quirk
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #65 from Maik Freudenberg ---
I feel like I'm jumping from puddle to puddle now.
Lukas, I previously couldn't test your patches due to an acpica bug affecting
my machine rendering results useless. Luckily, this has been fixed now.
Me
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #64 from Lukas Wunner ---
(In reply to Maik Freudenberg from comment #57)
> (In reply to Ilia Mirkin from comment #55)
> > What's the downside for doing this always btw
> By 'this', you mean, always turning it on?
> This generates th
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #63 from Lukas Wunner ---
(In reply to Peter Wu from comment #59)
> (In reply to Lukas Wunner from comment #51)
> > On my GK107 I do not see any change in power consumption regardless whether
> > bit 25 at config space offset 0x488 is
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #62 from Lukas Wunner ---
Created attachment 137941
--> https://bugs.freedesktop.org/attachment.cgi?id=137941&action=edit
[PATCH 3/3] ALSA: hda - Broaden VGA class matching
--
You are receiving this mail because:
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=75985
Lukas Wunner changed:
What|Removed |Added
Attachment #137764|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #61 from Lukas Wunner ---
Created attachment 137940
--> https://bugs.freedesktop.org/attachment.cgi?id=137940&action=edit
[PATCH 2/3] PCI: Apply quirks on runtime resume despite being unbound
--
You are receiving this mail because
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #59 from Peter Wu ---
(In reply to Lukas Wunner from comment #51)
> On my GK107 I do not see any change in power consumption regardless whether
> bit 25 at config space offset 0x488 is set or cleared, which is somewhat
> disappointing
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #58 from Ilia Mirkin ---
OK, well, I've seen this both ways -- 3D controllers with outputs as well as
VGA display adapters with the display function actually fused off. The only
reliable thing is the DCB block, but like you said, it's
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #57 from Maik Freudenberg ---
(In reply to Ilia Mirkin from comment #55)
> What's the downside for doing this always btw
By 'this', you mean, always turning it on?
This generates the errors from comment #42 since those devices are no
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #56 from Lukas Wunner ---
(In reply to Ilia Mirkin from comment #53)
> (In reply to Lukas Wunner from comment #52)
> > Ilia, do you have definitive knowledge of GPUs which
> > a) have a different class than PCI_CLASS_DISPLAY_VGA and
>
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #55 from Ilia Mirkin ---
(In reply to Maik Freudenberg from comment #54)
> (In reply to Ilia Mirkin from comment #44)
> > One can check if the DCB table has any outputs, and only do
> > stuff if there are none.
> I don't see how that'
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #54 from Maik Freudenberg ---
(In reply to Ilia Mirkin from comment #44)
> One can check if the DCB table has any outputs, and only do
> stuff if there are none.
I don't see how that's feasible since this would require to load the ROM
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #53 from Ilia Mirkin ---
(In reply to Lukas Wunner from comment #52)
> (In reply to Ilia Mirkin from comment #49)
> > (In reply to Maik Freudenberg from comment #47)
> > > There's of course the possibility that some braindead vendor w
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #52 from Lukas Wunner ---
(In reply to Ilia Mirkin from comment #49)
> (In reply to Maik Freudenberg from comment #47)
> > There's of course the possibility that some braindead vendor would ship a 3D
> > class tagged device actually h
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #51 from Lukas Wunner ---
(In reply to Maik Freudenberg from comment #31)
> As a sidenote: another user reported 5 Watts additional power draw when
> enabling the audio function. Regardless of this being accurate it should be
> taken
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #50 from Lukas Wunner ---
(In reply to Denis Lisov from comment #45)
> (In reply to Lukas Wunner from comment #37)
> > Related to this issue, I've just posted v2 of my patch set to use a device
> > link for power management of GPU-int
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #49 from Ilia Mirkin ---
(In reply to Maik Freudenberg from comment #47)
> There's of course the possibility that some braindead vendor would ship a 3D
> class tagged device actually having outputs.
This happens. A lot. See comment #
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #48 from Maik Freudenberg ---
(In reply to Denis Lisov from comment #45)
> For this hardware, even a plugged in HDMI TV on boot does not cause the
> audio device to appear, so the test was done with a PCI early quirk like
> suggested
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #47 from Maik Freudenberg ---
There's of course the possibility that some braindead vendor would ship a 3D
class tagged device actually having outputs. From my observations, this would
break the prop. driver so this vendor would have
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #46 from Maik Freudenberg ---
(In reply to Lukas Wunner from comment #43)
> Is this a Thunderbolt-attached GPU?
Calm down, get back to basics.
This is the dmesg when you turn on the hda dev on a 3d class device.
Just exclude the 3D cl
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #45 from Denis Lisov ---
(In reply to Lukas Wunner from comment #37)
> Related to this issue, I've just posted v2 of my patch set to use a device
> link for power management of GPU-integrated HDA controllers:
> https://lists.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #44 from Ilia Mirkin ---
(In reply to Maik Freudenberg from comment #42)
> The hda devices on 3D controller are existing but not completely configured
> by vendors leading to errors like
> [ 4790.121207] pci :07:00.1: [10de:0e0f]
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #43 from Lukas Wunner ---
(In reply to Maik Freudenberg from comment #42)
> The hda devices on 3D controller are existing but not completely configured
> by vendors leading to errors like
> [ 4790.121207] pci :07:00.1: [10de:0e0f]
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #42 from Maik Freudenberg ---
The hda devices on 3D controller are existing but not completely configured by
vendors leading to errors like
[ 4790.121207] pci :07:00.1: [10de:0e0f] type 00 class 0x040300
[ 4790.121253] pci :07
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #41 from Lukas Wunner ---
(In reply to Maik Freudenberg from comment #39)
> Lukas, unconditionally enabling the nvidia hda shouldn't be done. In my
> case, having a "3D controller" meaning a dGPU without outputs this would
> lead to h
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #40 from Maik Freudenberg ---
Should be easily avoidable by not enabling it when adapter class is
PCI_CLASS_DISPLAY_3D
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #39 from Maik Freudenberg ---
Lukas, unconditionally enabling the nvidia hda shouldn't be done. In my case,
having a "3D controlller" meaning a dGPU without outputs this would lead to
having a broken HDA device visible.
--
You are r
https://bugs.freedesktop.org/show_bug.cgi?id=75985
Lukas Wunner changed:
What|Removed |Added
CC||lu...@wunner.de
--- Comment #38 from Luka
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #37 from Lukas Wunner ---
Related to this issue, I've just posted v2 of my patch set to use a device link
for power management of GPU-integrated HDA controllers:
https://lists.freedesktop.org/archives/dri-devel/2018-March/168012.html
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #36 from Maik Freudenberg ---
I don't know about the current state of this, I would put some effort into it
if nobody else is working on it. Daniel Drake's patch is a good starting point
for that.
Currently, it looks like the problem
https://bugs.freedesktop.org/show_bug.cgi?id=75985
Raphaël Doursenaud changed:
What|Removed |Added
CC||rdoursen...@free.fr
--- Comment #35
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #34 from Maik Freudenberg ---
(In reply to Martin Lopatář from comment #32)
Really nice find that it's depending on power states or the change thereof. Can
you check when you boot to X with audio disabled and then enable it either
usi
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #33 from spa...@rambler.ru ---
My system specs:
i7-7700HQ + GTX 1060 6GB
Linux kernel version: 4.10.0-42-generic
Nvidia driver Version: 384.90
OS: Linux Mint 18.2
I can confirm that kernel module, posted by Maik Freudenberg [Comment 2
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #32 from Martin Lopatář ---
Hello.
I have Dell XPS 17 L702X with discrete GPU GF106M [GeForce GT 555M]
[10de:0dcd].
I'm trying to investigate the HDMI audio issue for some time, but I'm complete
novice in all - kernel development, pow
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #31 from Maik Freudenberg ---
As a sidenote: another user reported 5 Watts additional power draw when
enabling the audio function. Regardless of this being accurate it should be
taken into account to not enable it unconditionally sinc
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #30 from Ilia Mirkin ---
(In reply to Karol Herbst from comment #29)
> I think this check against 0x134 can be something like < 0x82 instead. This
> thing is there since like G82 GPUs and I am sure the HDMI audio device is
> controlle
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #29 from Karol Herbst ---
(In reply to Daniel Drake from comment #22)
> Created attachment 136369 [details] [review]
> GP104: enable HDMI audio device function
>
> On Asus GL502VS I investigated why the gfx device must be removed bef
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #28 from Raphaël Doursenaud ---
Maik Freudenberg, I tried your module on my ThinkPad P51 and it successfully
enabled the HDMI audio.
HDMI audio playback is now fully functional on my laptop.
I'm using it with the proprietary driver.
T
https://bugs.freedesktop.org/show_bug.cgi?id=75985
Maik Freudenberg changed:
What|Removed |Added
Attachment #136416|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #26 from Maik Freudenberg ---
Created attachment 136416
--> https://bugs.freedesktop.org/attachment.cgi?id=136416&action=edit
Kernel module to toggle audio function
Thank you, Daniel. I was too blind to see the attachment.
Attachin
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #25 from Daniel Drake ---
I found the difference. When I previously tested and found HDMI audio to be
working after the setpci,unload,rescan approach, I was using the nvidia
proprietary driver. HDMI audio PCI device was then detected,
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #24 from Daniel Drake ---
(In reply to Maik Freudenberg from comment #23)
> My idea would be to use the pci_scan_single_device function to add the
> sub-function device.
That's what I did in the above patch. Need to look closer at w
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #23 from Maik Freudenberg ---
@Daniel Drake: that's coherent with my investigations, even on a 740M without
any outputs setting the bit at 0x488 changes the pci header type to 0x80,
multifunction. My idea would be to use the pci_scan_
1 - 100 of 122 matches
Mail list logo
