[git pull] drm for v4.8
On Tue, Aug 02, 2016 at 08:01:14PM +0200, Daniel Vetter wrote: > On Tue, Aug 2, 2016 at 6:40 PM, Linus Torvalds > wrote: > > On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä > > wrote: > >> > >> So PSR seems more likely. The underruns might point at some watermark > >> fail though :( > >> > >> I have a couple of pending PSR patches you may want to try as well, > >> if i915.enable_psr=0 helps. > >> > >> First set is here: > >> git://github.com/vsyrjala/linux.git psr_setup_time_2 > >> This should be perfectly safe to go in actually, as it will only result > >> in disabling PSR with certain panels. > > > > This first git pull fixes it for me, as far as I can tell. I'm not > > sure that the problem is 100% reproducible, but I booted into each > > kernel twice, and the current git tree is broken, while with your > > psr_setup_time_2 branch pulled it works. So it does seem to be the > > fix. > > > >> The second set is here: > >> git://github.com/vsyrjala/linux.git psr_fixes_2 > > > > I didn't even test that one. > > > > Should I just pull that psr_setup_time2 branch for real? I'd like to > > get a real pull request with explanations etc, but other than that it > > looks good to go. > > Hm, I reviewed all the patches from Ville already. I gues they were > stuck because we didn't have someone who reported that it's fixed, > plus they lacked an ack from Dave for the 2 core patches. + they were part of a series that included a rotten apple responsible for a BAT regression > tbh I'd just > apply them all to drm-intel-fixes and then send out a pull for that > (there's two more bugfix patches on it which missed Dave's main pull > by a notch). Dave/Jani? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ville Syrjälä Intel OTC
[git pull] drm for v4.8
On Tue, Aug 2, 2016 at 6:40 PM, Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä > wrote: >> >> So PSR seems more likely. The underruns might point at some watermark >> fail though :( >> >> I have a couple of pending PSR patches you may want to try as well, >> if i915.enable_psr=0 helps. >> >> First set is here: >> git://github.com/vsyrjala/linux.git psr_setup_time_2 >> This should be perfectly safe to go in actually, as it will only result >> in disabling PSR with certain panels. > > This first git pull fixes it for me, as far as I can tell. I'm not > sure that the problem is 100% reproducible, but I booted into each > kernel twice, and the current git tree is broken, while with your > psr_setup_time_2 branch pulled it works. So it does seem to be the > fix. > >> The second set is here: >> git://github.com/vsyrjala/linux.git psr_fixes_2 > > I didn't even test that one. > > Should I just pull that psr_setup_time2 branch for real? I'd like to > get a real pull request with explanations etc, but other than that it > looks good to go. Hm, I reviewed all the patches from Ville already. I gues they were stuck because we didn't have someone who reported that it's fixed, plus they lacked an ack from Dave for the 2 core patches. tbh I'd just apply them all to drm-intel-fixes and then send out a pull for that (there's two more bugfix patches on it which missed Dave's main pull by a notch). Dave/Jani? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[git pull] drm for v4.8
On Tue, 02 Aug 2016, Jiri Kosina wrote:
> On Mon, 1 Aug 2016, Linus Torvalds wrote:
>
>> > This is the main drm pull request for 4.8, I'm down with a cold at the
>> > moment
>> > so hopefully this isn't in too bad a state, I finished pulling stuff last
>> > week mostly (nouveau fixes just went in today), so only this message should
>> > be influenced by illness. Apologies to anyone who's major feature I missed
>> > :-)
>> >
>> > i915:
>> > BXT support enabled by default
>> > GVT-g infrastructure
>> > GuC command submission and fixes
>> > BXT workarounds
>> > SKL/BKL workarounds
>> > Demidlayering device registration
>> > Thundering herd fixes
>> > Missing pci ids
>> > Atomic updates
>>
>> Hmm. I did the merge and pushed it out, but testing it on my laptop
>> shows some very annoying flickering problem.
>
> In addition to that, what I see with current git (HEAD == 731c7d3a205,
> i.e. the drm merge) is lockdep report during bootup about AB-BA between
> mode_config.mutex and fb_notifier_list rwsem; will probably not have time
> to look into it more (look at the code and / or bisect) until tomorrow, so
> sending out early as a heads-up.
>
> Also, trying to suspend the machine to disk hangs, with the "suspend" LED
> constantly blinking, LCD being blank, but the machine never actually
> powering off. Not sure whether it might not be the very deadlock actually
> triggering for real.
There was [1] before my vacation to fix this, but it doesn't seem to
have gone anywhere since. And it doesn't refer what caused the lockdep
splat to begin with.
BR,
Jani.
[1]
http://patchwork.freedesktop.org/patch/msgid/1467286256-8870-1-git-send-email-chris
at chris-wilson.co.uk
>
>
> [8.731638] fbcon: inteldrmfb (fb0) is primary device
>
> [8.732611] ==
> [8.732612] [ INFO: possible circular locking dependency detected ]
> [8.732614] 4.7.0-10753-g731c7d3 #459 Not tainted
> [8.732614] ---
> [8.732615] kworker/u8:3/60 is trying to acquire lock:
> [8.732650] (>mode_config.mutex){+.+.+.}, at: []
> drm_modeset_lock_all+0x40/0x120 [drm]
> [8.732651]
> but task is already holding lock:
> [8.732657] ((fb_notifier_list).rwsem){.+}, at: []
> __blocking_notifier_call_chain+0x3a/0x70
> [8.732658]
> which lock already depends on the new lock.
>
> [8.732658]
> the existing dependency chain (in reverse order) is:
> [8.732661]
> -> #1 ((fb_notifier_list).rwsem){.+}:
> [8.732665][] lock_acquire+0xb0/0x1e0
> [8.732669][] down_write+0x55/0xc0
> [8.732671][]
> blocking_notifier_chain_register+0x21/0xb0
> [8.732674][] fb_register_client+0x18/0x20
> [8.732676][]
> backlight_device_register+0x138/0x250
> [8.732746][]
> intel_backlight_device_register+0xa2/0x160 [i915]
> [8.732791][] intel_connector_register+0xe/0x10
> [i915]
> [8.732809][] drm_connector_register+0x49/0x80
> [drm]
> [8.732827][]
> drm_modeset_register_all+0x1d0/0x260 [drm]
> [8.732843][] drm_dev_register+0xc2/0xd0 [drm]
> [8.732878][] i915_driver_load+0x745/0x13e0
> [i915]
> [8.732914][] i915_pci_probe+0x4f/0x70 [i915]
> [8.732917][] local_pci_probe+0x45/0xa0
> [8.732920][] pci_device_probe+0xe1/0x130
> [8.732923][] driver_probe_device+0x1a8/0x460
> [8.732925][] __driver_attach+0xcd/0xf0
> [8.732927][] bus_for_each_dev+0x64/0xa0
> [8.732929][] driver_attach+0x1e/0x20
> [8.732931][] bus_add_driver+0x1d3/0x290
> [8.732933][] driver_register+0x60/0xe0
> [8.732935][] __pci_register_driver+0x60/0x70
> [8.732972][] i915_init+0x5d/0x64 [i915]
> [8.732975][] do_one_initcall+0x3d/0x160
> [8.732979][] do_init_module+0x60/0x1dc
> [8.732982][] load_module+0x142e/0x1bf0
> [8.732984][] SYSC_finit_module+0xa9/0xd0
> [8.732986][] SyS_finit_module+0xe/0x10
> [8.732989][] entry_SYSCALL_64_fastpath+0x1c/0xac
> [8.732992]
> -> #0 (>mode_config.mutex){+.+.+.}:
> [8.732995][] __lock_acquire+0x16cc/0x1700
> [8.732997][] lock_acquire+0xb0/0x1e0
> [8.732999][] mutex_lock_nested+0x71/0x390
> [8.733019][] drm_modeset_lock_all+0x40/0x120
> [drm]
> [8.733034][]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
> [8.733043][] drm_fb_helper_set_par+0x2c/0x50
> [drm_kms_helper]
> [8.733088][] intel_fbdev_set_par+0x1a/0x60
> [i915]
> [8.733091][] fbcon_init+0x4d8/0x550
> [8.733094][] visual_init+0xd6/0x130
> [8.733097][] do_bind_con_driver+0x146/0x310
> [8.733099][]
[git pull] drm for v4.8
On Tue, 02 Aug 2016, Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä > wrote: >> >> I have a couple of pending PSR patches you may want to try as well, >> if i915.enable_psr=0 helps. > > Yes. i915.enable_psr=0 seems to make the bad flickering go away. > > I'll try your git trees out later, but what exactly changed with > regards to psr lately? It's set as a "dangerous" option, and even just > clearing it caused > > Setting dangerous option enable_psr - tainting kernel > > which seems entirely bogus. The warning comes from kernel/params.c for module_param_named_unsafe() which has no way of knowing which values are safe, and complains if the option is set at all. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[git pull] drm for v4.8
On Tue, 2 Aug 2016, Jani Nikula wrote: > >> > This is the main drm pull request for 4.8, I'm down with a cold at the > >> > moment > >> > so hopefully this isn't in too bad a state, I finished pulling stuff last > >> > week mostly (nouveau fixes just went in today), so only this message > >> > should > >> > be influenced by illness. Apologies to anyone who's major feature I > >> > missed :-) > >> > > >> > i915: > >> > BXT support enabled by default > >> > GVT-g infrastructure > >> > GuC command submission and fixes > >> > BXT workarounds > >> > SKL/BKL workarounds > >> > Demidlayering device registration > >> > Thundering herd fixes > >> > Missing pci ids > >> > Atomic updates > >> > >> Hmm. I did the merge and pushed it out, but testing it on my laptop > >> shows some very annoying flickering problem. > > > > In addition to that, what I see with current git (HEAD == 731c7d3a205, > > i.e. the drm merge) is lockdep report during bootup about AB-BA between > > mode_config.mutex and fb_notifier_list rwsem; will probably not have time > > to look into it more (look at the code and / or bisect) until tomorrow, so > > sending out early as a heads-up. > > > > Also, trying to suspend the machine to disk hangs, with the "suspend" LED > > constantly blinking, LCD being blank, but the machine never actually > > powering off. Not sure whether it might not be the very deadlock actually > > triggering for real. > > There was [1] before my vacation to fix this, but it doesn't seem to > have gone anywhere since. And it doesn't refer what caused the lockdep > splat to begin with. Confirmed, that patch fixes the lockdep splat, so for that part Tested-by: Jiri Kosina -- Jiri Kosina SUSE Labs
[git pull] drm for v4.8
On Tue, 2 Aug 2016, Jiri Kosina wrote: > In addition to that, what I see with current git (HEAD == 731c7d3a205, > i.e. the drm merge) is lockdep report during bootup about AB-BA between > mode_config.mutex and fb_notifier_list rwsem; will probably not have time > to look into it more (look at the code and / or bisect) until tomorrow, so > sending out early as a heads-up. > > Also, trying to suspend the machine to disk hangs, with the "suspend" LED > constantly blinking, LCD being blank, but the machine never actually > powering off. Not sure whether it might not be the very deadlock actually > triggering for real. Ok, I tried HEAD == 7a66ecf (per-drm merge kernel from yesterday), and it doesn't produce the AB-BA warning (so it's really introduced by the last merge), but still has the suspend issue, so those are two separate issues. -- Jiri Kosina SUSE Labs
[git pull] drm for v4.8
On Mon, 1 Aug 2016, Linus Torvalds wrote:
> > This is the main drm pull request for 4.8, I'm down with a cold at the
> > moment
> > so hopefully this isn't in too bad a state, I finished pulling stuff last
> > week mostly (nouveau fixes just went in today), so only this message should
> > be influenced by illness. Apologies to anyone who's major feature I missed
> > :-)
> >
> > i915:
> > BXT support enabled by default
> > GVT-g infrastructure
> > GuC command submission and fixes
> > BXT workarounds
> > SKL/BKL workarounds
> > Demidlayering device registration
> > Thundering herd fixes
> > Missing pci ids
> > Atomic updates
>
> Hmm. I did the merge and pushed it out, but testing it on my laptop
> shows some very annoying flickering problem.
In addition to that, what I see with current git (HEAD == 731c7d3a205,
i.e. the drm merge) is lockdep report during bootup about AB-BA between
mode_config.mutex and fb_notifier_list rwsem; will probably not have time
to look into it more (look at the code and / or bisect) until tomorrow, so
sending out early as a heads-up.
Also, trying to suspend the machine to disk hangs, with the "suspend" LED
constantly blinking, LCD being blank, but the machine never actually
powering off. Not sure whether it might not be the very deadlock actually
triggering for real.
[8.731638] fbcon: inteldrmfb (fb0) is primary device
[8.732611] ==
[8.732612] [ INFO: possible circular locking dependency detected ]
[8.732614] 4.7.0-10753-g731c7d3 #459 Not tainted
[8.732614] ---
[8.732615] kworker/u8:3/60 is trying to acquire lock:
[8.732650] (>mode_config.mutex){+.+.+.}, at: []
drm_modeset_lock_all+0x40/0x120 [drm]
[8.732651]
but task is already holding lock:
[8.732657] ((fb_notifier_list).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x3a/0x70
[8.732658]
which lock already depends on the new lock.
[8.732658]
the existing dependency chain (in reverse order) is:
[8.732661]
-> #1 ((fb_notifier_list).rwsem){.+}:
[8.732665][] lock_acquire+0xb0/0x1e0
[8.732669][] down_write+0x55/0xc0
[8.732671][]
blocking_notifier_chain_register+0x21/0xb0
[8.732674][] fb_register_client+0x18/0x20
[8.732676][] backlight_device_register+0x138/0x250
[8.732746][]
intel_backlight_device_register+0xa2/0x160 [i915]
[8.732791][] intel_connector_register+0xe/0x10
[i915]
[8.732809][] drm_connector_register+0x49/0x80
[drm]
[8.732827][] drm_modeset_register_all+0x1d0/0x260
[drm]
[8.732843][] drm_dev_register+0xc2/0xd0 [drm]
[8.732878][] i915_driver_load+0x745/0x13e0 [i915]
[8.732914][] i915_pci_probe+0x4f/0x70 [i915]
[8.732917][] local_pci_probe+0x45/0xa0
[8.732920][] pci_device_probe+0xe1/0x130
[8.732923][] driver_probe_device+0x1a8/0x460
[8.732925][] __driver_attach+0xcd/0xf0
[8.732927][] bus_for_each_dev+0x64/0xa0
[8.732929][] driver_attach+0x1e/0x20
[8.732931][] bus_add_driver+0x1d3/0x290
[8.732933][] driver_register+0x60/0xe0
[8.732935][] __pci_register_driver+0x60/0x70
[8.732972][] i915_init+0x5d/0x64 [i915]
[8.732975][] do_one_initcall+0x3d/0x160
[8.732979][] do_init_module+0x60/0x1dc
[8.732982][] load_module+0x142e/0x1bf0
[8.732984][] SYSC_finit_module+0xa9/0xd0
[8.732986][] SyS_finit_module+0xe/0x10
[8.732989][] entry_SYSCALL_64_fastpath+0x1c/0xac
[8.732992]
-> #0 (>mode_config.mutex){+.+.+.}:
[8.732995][] __lock_acquire+0x16cc/0x1700
[8.732997][] lock_acquire+0xb0/0x1e0
[8.732999][] mutex_lock_nested+0x71/0x390
[8.733019][] drm_modeset_lock_all+0x40/0x120 [drm]
[8.733034][]
drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
[8.733043][] drm_fb_helper_set_par+0x2c/0x50
[drm_kms_helper]
[8.733088][] intel_fbdev_set_par+0x1a/0x60 [i915]
[8.733091][] fbcon_init+0x4d8/0x550
[8.733094][] visual_init+0xd6/0x130
[8.733097][] do_bind_con_driver+0x146/0x310
[8.733099][] do_take_over_console+0x106/0x180
[8.733101][] do_fbcon_takeover+0x57/0xb0
[8.733104][] fbcon_event_notify+0x726/0x870
[8.733106][] notifier_call_chain+0x4e/0xa0
[8.733109][]
__blocking_notifier_call_chain+0x53/0x70
[8.733111][]
blocking_notifier_call_chain+0x16/0x20
[8.733113][] fb_notifier_call_chain+0x1b/0x20
[8.733116][] register_framebuffer+0x239/0x320
[8.733126][]
drm_fb_helper_initial_config+0x25a/0x3a3
[git pull] drm for v4.8
On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä wrote: > > So PSR seems more likely. The underruns might point at some watermark > fail though :( > > I have a couple of pending PSR patches you may want to try as well, > if i915.enable_psr=0 helps. > > First set is here: > git://github.com/vsyrjala/linux.git psr_setup_time_2 > This should be perfectly safe to go in actually, as it will only result > in disabling PSR with certain panels. This first git pull fixes it for me, as far as I can tell. I'm not sure that the problem is 100% reproducible, but I booted into each kernel twice, and the current git tree is broken, while with your psr_setup_time_2 branch pulled it works. So it does seem to be the fix. > The second set is here: > git://github.com/vsyrjala/linux.git psr_fixes_2 I didn't even test that one. Should I just pull that psr_setup_time2 branch for real? I'd like to get a real pull request with explanations etc, but other than that it looks good to go. Linus
[git pull] drm for v4.8
> Hmm. I did the merge and pushed it out, but testing it on my laptop > shows some very annoying flickering problem. I can confirm that this problem present in older kernels. Just run Fedora 24 as guest in gnome-boxes on Fedora 24. -- Best Regards, Mike Gavrilov.
[git pull] drm for v4.8
On Tue, Aug 02, 2016 at 10:00:12AM +0200, Daniel Vetter wrote: > On Tue, Aug 2, 2016 at 4:26 AM, Linus Torvalds > wrote: > > On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie wrote: > >> > >> This is the main drm pull request for 4.8, I'm down with a cold at the > >> moment > >> so hopefully this isn't in too bad a state, I finished pulling stuff last > >> week mostly (nouveau fixes just went in today), so only this message should > >> be influenced by illness. Apologies to anyone who's major feature I missed > >> :-) > >> > >> i915: > >> BXT support enabled by default > >> GVT-g infrastructure > >> GuC command submission and fixes > >> BXT workarounds > >> SKL/BKL workarounds > >> Demidlayering device registration > >> Thundering herd fixes > >> Missing pci ids > >> Atomic updates > > > > Hmm. I did the merge and pushed it out, but testing it on my laptop > > shows some very annoying flickering problem. > > > > The screen goes dark for a very short while (one frame? Who knows? > > Seems longer occasionally). I have no idea what triggers it, but it > > happens quite a lot when it happens. Like once every second or two. > > And it seems to happen most of the time, although right now it happens > > to be behaving nicely, so sometimes it goes for a while without the > > flickering. > > > > Things *work*, but the flickering is nasty enough to make the end > > result painful to use. > > > > The only thing I see in dmesg that looks bad is > > > >[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* > > uncleared fifo underrun on pipe A > >[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A > > FIFO underrun > > > > but I've seen that before, and it happens a couple of times during > > boot. Not once per second. > > > > This is my old Vaio 11 Pro, now running Fedora 24 (up-to-date as of today). > > > > So it's bog-standard intel graphics (i5-4200U - Haswell ULT). > > > > Suggestions to try? > > psr or fbc are the likely culprits. More likely fbc if the underruns > correlate with the flicker (but note that by default we only report > them once per modest, needs to be reset with a dpms or > suspend/resume). Driver should even pick up the new module option > settings at runtime (but again you need to force a modeset, just > suspend/resume quickly), so fast to test. I think FBC is still disabled by default on HSW. So PSR seems more likely. The underruns might point at some watermark fail though :( I have a couple of pending PSR patches you may want to try as well, if i915.enable_psr=0 helps. First set is here: git://github.com/vsyrjala/linux.git psr_setup_time_2 This should be perfectly safe to go in actually, as it will only result in disabling PSR with certain panels. The second set is here: git://github.com/vsyrjala/linux.git psr_fixes_2 This one I think is causing some kind of slight regression on one machine in our CI system. Still not sure what's going on there. -- Ville Syrjälä Intel OTC
[git pull] drm for v4.8
On Tue, Aug 2, 2016 at 4:26 AM, Linus Torvalds wrote: > On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie wrote: >> >> This is the main drm pull request for 4.8, I'm down with a cold at the moment >> so hopefully this isn't in too bad a state, I finished pulling stuff last >> week mostly (nouveau fixes just went in today), so only this message should >> be influenced by illness. Apologies to anyone who's major feature I missed >> :-) >> >> i915: >> BXT support enabled by default >> GVT-g infrastructure >> GuC command submission and fixes >> BXT workarounds >> SKL/BKL workarounds >> Demidlayering device registration >> Thundering herd fixes >> Missing pci ids >> Atomic updates > > Hmm. I did the merge and pushed it out, but testing it on my laptop > shows some very annoying flickering problem. > > The screen goes dark for a very short while (one frame? Who knows? > Seems longer occasionally). I have no idea what triggers it, but it > happens quite a lot when it happens. Like once every second or two. > And it seems to happen most of the time, although right now it happens > to be behaving nicely, so sometimes it goes for a while without the > flickering. > > Things *work*, but the flickering is nasty enough to make the end > result painful to use. > > The only thing I see in dmesg that looks bad is > >[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* > uncleared fifo underrun on pipe A >[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A > FIFO underrun > > but I've seen that before, and it happens a couple of times during > boot. Not once per second. > > This is my old Vaio 11 Pro, now running Fedora 24 (up-to-date as of today). > > So it's bog-standard intel graphics (i5-4200U - Haswell ULT). > > Suggestions to try? psr or fbc are the likely culprits. More likely fbc if the underruns correlate with the flicker (but note that by default we only report them once per modest, needs to be reset with a dpms or suspend/resume). Driver should even pick up the new module option settings at runtime (but again you need to force a modeset, just suspend/resume quickly), so fast to test. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[git pull] drm for v4.8
On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä wrote: > > I have a couple of pending PSR patches you may want to try as well, > if i915.enable_psr=0 helps. Yes. i915.enable_psr=0 seems to make the bad flickering go away. I'll try your git trees out later, but what exactly changed with regards to psr lately? It's set as a "dangerous" option, and even just clearing it caused Setting dangerous option enable_psr - tainting kernel which seems entirely bogus. Linus
[git pull] drm for v4.8
Hi Linus, This is the main drm pull request for 4.8, I'm down with a cold at the moment so hopefully this isn't in too bad a state, I finished pulling stuff last week mostly (nouveau fixes just went in today), so only this message should be influenced by illness. Apologies to anyone who's major feature I missed :-) Dave. Core: Lockless GEM BO freeing Non-blocking atomic work Documentation changes (rst/sphinx) Prep for new fencing changes Simple display helpers Master/auth changes Register/unregister rework Loads of trivial patches/fixes. New stuff: ARM Mali display driver (not the 3D chip) sii902x RGB->HDMI bridge Panel: Support for new panels Improved backlight support Bridge: Convert ADV7511 to bridge driver ADV7533 support TC358767 (DSI/DPI to eDP) encoder chip support i915: BXT support enabled by default GVT-g infrastructure GuC command submission and fixes BXT workarounds SKL/BKL workarounds Demidlayering device registration Thundering herd fixes Missing pci ids Atomic updates amdgpu/radeon: ATPX improvements for better dGPU power control on PX systems New power features for CZ/BR/ST Pipelined BO moves and evictions in TTM GPU scheduler improvements GPU reset improvements Overclocking on dGPUs with amdgpu Polaris powermanagement enabled nouveau: GK20A/GM20B volt and clock improvements. Initial support for GP100/GP104 GPUs, GP104 will not yet support acceleration due to NVIDIA having not released firmware for them as of yet. exynos: Exynos5433 SoC with IOMMU support. vc4: Shader validation for branching imx-drm: Atomic mode setting conversion Reworked DMFC FIFO allocation External bridge support analogix-dp: RK3399 eDP support Lots of fixes. rockchip: Lots of small fixes. msm: DT bindings cleanups Shrinker and madvise support ASoC HDMI codec support tegra: Host1x driver cleanups SOR reworking for DP support Runtime PM support omapdrm: PLL enhancements Header refactoring Gamma table support arcgpu: Simulator support virtio-gpu: Atomic modesetting fixes. rcar-du: Misc fixes. mediatek: MT8173 HDMI support sti: ASOC HDMI codec support Minor fixes fsl-dcu: Suspend/resume support Bridge support amdkfd: Minor fixes. etnaviv: Enable GPU clock gating hisilicon: Vblank and other fixes The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e: Linux 4.7 (2016-07-24 12:23:50 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.8 for you to fetch changes up to 753e7c8cbd8c503b962294303c7b5e9ea8513443: Merge branch 'linux-4.8' of git://github.com/skeggsb/linux into drm-next (2016-08-02 11:16:02 +1000) Alex Deucher (59): drm/amdgpu: load different smc firmware on some CI variants drm/radeon: load different smc firmware on some SI variants drm/radeon: load different smc firmware on some CI variants drm/amdgpu/gfx7: expand cp jt size to handle GDS as well drm/radeon/gfx7: expand cp jt size to handle GDS as well drm/amdgpu/gfx8: add state setup for CZ/ST GFX power gating drm/amdgpu/gfx8: rename some pg functions drm/amdgpu: add new GFX powergating types drm/amdgpu/gfx8: add powergating support for CZ/ST drm/amdgpu/gfx8: clean up polaris11 PG enable drm/amdgpu: disable power control on hybrid laptops drm/amdgpu: clean up atpx power control handling drm/amdgpu: add a delay after ATPX dGPU power off drm/amdgpu/atpx: add a query for ATPX dGPU power control drm/amdgpu: use PCI_D3hot for PX systems without dGPU power control drm/amdgpu/atpx: drop forcing of dGPU power control drm/radeon: disable power control on hybrid laptops drm/radeon: clean up atpx power control handling drm/radeon: add a delay after ATPX dGPU power off drm/radeon/atpx: add a query for ATPX dGPU power control drm/radeon: use PCI_D3hot for PX systems without dGPU power control drm/radeon/atpx: drop forcing of dGPU power control drm/amdgpu/atpx: track whether if this is a hybrid graphics platform drm/amdgpu/atpx: hybrid platforms use d3cold drm/amdgpu: drop explicit pci D3/D0 setting for ATPX power control drm/radeon/atpx: track whether if this is a hybrid graphics platform drm/radeon/atpx: hybrid platforms use d3cold drm/radeon: drop explicit pci D3/D0 setting for ATPX power control drm/amdgpu: work around lack of
[git pull] drm for v4.8
On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie wrote: > > This is the main drm pull request for 4.8, I'm down with a cold at the moment > so hopefully this isn't in too bad a state, I finished pulling stuff last > week mostly (nouveau fixes just went in today), so only this message should > be influenced by illness. Apologies to anyone who's major feature I missed :-) > > i915: > BXT support enabled by default > GVT-g infrastructure > GuC command submission and fixes > BXT workarounds > SKL/BKL workarounds > Demidlayering device registration > Thundering herd fixes > Missing pci ids > Atomic updates Hmm. I did the merge and pushed it out, but testing it on my laptop shows some very annoying flickering problem. The screen goes dark for a very short while (one frame? Who knows? Seems longer occasionally). I have no idea what triggers it, but it happens quite a lot when it happens. Like once every second or two. And it seems to happen most of the time, although right now it happens to be behaving nicely, so sometimes it goes for a while without the flickering. Things *work*, but the flickering is nasty enough to make the end result painful to use. The only thing I see in dmesg that looks bad is [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun but I've seen that before, and it happens a couple of times during boot. Not once per second. This is my old Vaio 11 Pro, now running Fedora 24 (up-to-date as of today). So it's bog-standard intel graphics (i5-4200U - Haswell ULT). Suggestions to try? Linus
