I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it?
Recently (either 4.10/4.11 kernel, or same time frame Firefox on F25/F26) I notice a blocky flickering when Firefox is launched. This doesn't happen with the firmware loaded. So that's nice I guess, but doesn't seem critical.
Anyway, just curious.
I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it?
I expect when upstream decided they are stable and useful enough, upstream will enable them. I'm not fully sure how useful they are, I think they might possibly enable lower power states, but also nasty bugs.
Dave.
On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it?
I expect when upstream decided they are stable and useful enough, upstream will enable them. I'm not fully sure how useful they are, I think they might possibly enable lower power states, but also nasty bugs.
The same upstream which did not release stable version of Xorg Intel driver for past three years? ;-) According to the link, the firmwares are needed for HDMI audio, which is quite critical functionality. HDMI audio for older chipsets did not require binary blobs, so this is kind of regression.
----- Original Message -----
On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it?
I expect when upstream decided they are stable and useful enough, upstream will enable them. I'm not fully sure how useful they are, I think they might possibly enable lower power states, but also nasty bugs.
The same upstream which did not release stable version of Xorg Intel driver for past three years? ;-) According to the link, the firmwares are needed for HDMI audio, which is quite critical functionality. HDMI audio for older chipsets did not require binary blobs, so this is kind of regression.
That might be the reason why I had to blacklist the snd-hdmi-lpe-audio module on my system. Pulseaudio crashed trying to access the HDMI audio device.
----- Original Message -----
That might be the reason why I had to blacklist the snd-hdmi-lpe-audio module on my system. Pulseaudio crashed trying to access the HDMI audio device.
This wasn't related. Hans pointed me to a work-around for which I found the upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=100488
Cheers
On Wed, Jun 28, 2017 at 5:52 AM, Tomasz Torcz tomek@pipebreaker.pl wrote:
The same upstream which did not release stable version of Xorg Intel driver for past three years? ;-) According to the link, the firmwares are needed for HDMI audio, which is quite critical functionality. HDMI audio for older chipsets did not require binary blobs, so this is kind of regression.
We should push back very hard against this. I was under the impression that Intel was the open source CPU vendor. If we need binary blobs in the OS to make new chips work properly, perhaps Fedora and Red Hat should be heavily promoting AMD until Intel decides to change its ways.
(I am hoping AMD doesn't do this too. I have no idea.)
Michael
On Wed, Jun 28, 2017 at 2:08 PM, Michael Catanzaro mike.catanzaro@gmail.com wrote:
On Wed, Jun 28, 2017 at 5:52 AM, Tomasz Torcz tomek@pipebreaker.pl wrote:
The same upstream which did not release stable version of Xorg Intel driver for past three years? ;-) According to the link, the firmwares are needed for HDMI audio, which is quite critical functionality. HDMI audio for older chipsets did not require binary blobs, so this is kind of regression.
We should push back very hard against this. I was under the impression that Intel was the open source CPU vendor. If we need binary blobs in the OS to make new chips work properly, perhaps Fedora and Red Hat should be heavily promoting AMD until Intel decides to change its ways.
I believe all common current generation GPUs need firmware, some of the intel platforms have needed firmware for audio for some time.
The intel audio firmware is /lib/firmware/intel/dsp_fw_* and the various nVidia firmware is in /lib/firmware/nvidia/
(I am hoping AMD doesn't do this too. I have no idea.)
You'd be wrong, check /lib/firmware/amdgpu/
On 06/28/2017 03:16 PM, Peter Robinson wrote:
I believe all common current generation GPUs need firmware, some of the intel platforms have needed firmware for audio for some time.
And the border between firmware and application code is increasingly blurred. The support blob for Intel Precision Touch and Stylus looks more like application code loaded into the GPU.
Thanks, Florian
No not the same upstream.
I'll look into the hdmi audio situation when I get back from holidays.
----- Original Message -----
From: "Tomasz Torcz" tomek@pipebreaker.pl To: devel@lists.fedoraproject.org Sent: Wednesday, 28 June, 2017 8:52:03 PM Subject: Re: Intel i915 firmwares
On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it?
I expect when upstream decided they are stable and useful enough, upstream will enable them. I'm not fully sure how useful they are, I think they might possibly enable lower power states, but also nasty bugs.
The same upstream which did not release stable version of Xorg Intel driver for past three years? ;-) According to the link, the firmwares are needed for HDMI audio, which is quite critical functionality. HDMI audio for older chipsets did not require binary blobs, so this is kind of regression.
-- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzichubg@chrome.pl wagon filled with backup tapes." -- Jim Gray _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, 2017-06-28 at 05:20 -0400, David Airlie wrote:
I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it?
I expect when upstream decided they are stable and useful enough, upstream will enable them. I'm not fully sure how useful they are, I think they might possibly enable lower power states, but also nasty bugs.
And Ironlakes [1] ?
Can I get any better performance, if I try enable RC6 p-states ? by this link [2] is for 4th-gen ...
Dell release an update for BIOS [3]
Best regards,
[1] Xorg.0.log [ 1122.762] (II) intel(0): SNA initialized with Ironlake (gen5) backend
dmesg | grep drm [ 22.588888] [drm] RC6 disabled, disabling runtime PM support
[2] https://superuser.com/a/783944/176412
[3] Dell Latitude E6410 System BIOS This package provides the BIOS update for Dell Latitude E6410/6410ATG and is supported on Latitude E6410/6410ATG models (...)
Fixes: - Updated Intel ME Firmware to address security advisory CVE-2017-5689 / INTEL-SA-00075.
On Jun 28, 2017, at 4:20 AM, David Airlie airlied@redhat.com wrote:
I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it?
I expect when upstream decided they are stable and useful enough, upstream will enable them. I'm not fully sure how useful they are, I think they might possibly enable lower power states, but also nasty bugs.
HUC is used for bit rate control when using the low power fixed function AVC encoder(vdenc) on supported platforms. (Libva/intel-vapid-driver)
Dave. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Another thing that's a big frustrating about this, is when the firmware loading, or various other features, is enabled I get:
Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option enable_guc_loading - tainting kernel Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option enable_guc_submission - tainting kernel Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option enable_psr - tainting kernel Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option disable_power_well - tainting kernel
So it's a catch-22: take no dangerous risk, get no neat features. And it's vague danger. Dangerous how? Crashes? Or melt the CPU?
Chris Murphy
devel@lists.stg.fedoraproject.org
-
Bastien Nocera -
Chris Murphy -
David Airlie -
Florian Weimer -
Michael Catanzaro -
Peter Robinson -
Sean V Kelley -
Sérgio Basto -
Tomasz Torcz