[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Hogan]

On 7 July 2016 at 20:19, James Bottomley
 wrote:
> On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
>> On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
>> > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
>> > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
>> > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
>> > > > > Cc: Ville
>> > > > >
>> > > > > On Mon, 20 Jun 2016, James Bottomley <
>> > > > > James.Bottomley at HansenPartnership.com> wrote:
>> > > > > > OK, my candidate bad commit is this one:
>> > > > > >
>> > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
>> > > > > > Author: Ville Syrjälä 
>> > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
>> > > > > >
>> > > > > > drm/i915: Get panel_type from OpRegion panel details
>> > > > > >
>> > > > > > After being more careful about waiting to identify flicker,
>> > > > > > this one seems to be the one the bisect finds.  I'm now
>> > > > > > running v4.7-rc3 with this one reverted and am currently
>> > > > > > seeing no flicker problems.   It is, however, early days
>> > > > > > because the flicker can hide for long periods, so I 'll
>> > > > > > wait
>> > > > > > until Monday evening and a few reboots before declaring
>> > > > > > victory.
>> > > > >
>> > > > > If that turns out to be the bad commit, it doesn't really
>> > > > > surprise me, and that in itself is depressing.
>> > > >
>> > > > As far as I can tell, after running for a day with this
>> > > > reverted,
>> > > > this is the problem.  The flicker hasn't appeared with it
>> > > > reverted.  It's pretty noticeable with this commit included.
>> > >
>> > > Hmm. The only difference I can see is low vs. normal vswing.
>> > > Panel
>> > > 0 has low, panel 2 has normal. So either the VBT or opregion is
>> > > telling utter lies, or there's some other bug in our low vswing
>> > > support.
>> >
>> > I did a quick once over of out DDI vswing stuff and didn't find
>> > anything too serious. There were some buglets in the iboost
>> > handling,
>> > but I'm not very hopeful that fixing those would help with your
>> > machine.
>> >
>> > Here's a branch anyway in case you want to give it a go:
>> > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
>> >
>> > Actually, I think the only patch in there that might make a
>> > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI
>> > with 4 lanes on SKL")
>>
>> Running with it now (the entire branch).  So far it looks OK, but
>> I'll give it a couple of days to see if anything manifests before
>> declaring victory.
>
> Bad news, I'm afraid: after a couple of hours of run time, there is now
> noticeable flicker on the display, so although the iboost fixes may
> have lessened it, it's still present.
>
> James
>
>

I've just bisected a similar (same?) problem (slow increase and
decrease of screen brightness with a period of a few seconds) to the
same commit (this is on a Dell XPS 13 laptop)

commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä 
Date:   Mon Apr 11 10:23:51 2016 +0300

drm/i915: Get panel_type from OpRegion panel details

the difference for me is that good commits used the acpi backlight,
and bad ones used the intel backlight (/sys/class/backlight/). Its
like intel_backlight is fighting with the firmware to control the
backlight or something. Reverting the commit on v4.7.3 switches it
back to the acpi backlight and all works nicely again.

let me know if I can provide anything else to help debug.

Cheers
James

drm/i915: XPS13 backlight regression in v3.14

[James Hogan]

Hi,

I've noticed that v3.14 breaks the backlight on Dell XPS13. Reverting the 
following commit fixes the issue for me (i.e. the GUI brightness controls work 
again):

bc0bb9fd1c78 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE

It appears that in v3.14 (with the above patch):
* intel_backlight/brightness=4882 (max & default) causes 
acpi_video0/brightness to have no effect.
* intel_backlight/brightness=0 causes acpi_video0/brightness to behave 
corrrectly (the firmware (I assume) fades the brightness gradually when 
acpi_video0/brightness is set)
* intel_backlight/brightness=something else in between often causes 
acpi_video0 and intel_backlight to apparently "fight" over the backlight, 
resulting in brightness flickering up and down every second or so.

Reverting the above patch on v3.14:
* intel_backlight/brightness has no effect
* acpi_video0/brightness works normally

It doesn't seem quite as simple as them trying to use the same hardware since 
when intel_backlight/brightness=4882, acpi_video0/brightness has no effect at 
all, so I don't really get what's going on.

Can anybody shed some light or suggest a proper fix for this recurring issue?

Thanks
James
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

[PATCH 1/1] drm: only build ati_pcigart if PCI enabled

[James Hogan]

Prevent ati_pcigart.c being built unless PCI is enabled. The exported
functions in this file are only used by drivers which depend on PCI
(namely r128 and radeon), and it tries to use PCI specific functions
(pci_unmap_page, pci_map_page, and pci_dma_mapping_error) that cause
compiler errors when PCI is disabled.

Signed-off-by: James Hogan 
Cc: David Airlie 
---
 drivers/gpu/drm/Makefile |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2ff5cef..3e303b1b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -8,7 +8,7 @@ drm-y   :=  drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \
drm_context.o drm_dma.o \
drm_drv.o drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \
-   drm_agpsupport.o drm_scatter.o ati_pcigart.o drm_pci.o \
+   drm_agpsupport.o drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
@@ -16,6 +16,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
+drm-$(CONFIG_PCI) += ati_pcigart.o

 drm-usb-y   := drm_usb.o

-- 
1.7.7.6

[PATCH 1/1] drm: only build ati_pcigart if PCI enabled

[James Hogan]

Prevent ati_pcigart.c being built unless PCI is enabled. The exported
functions in this file are only used by drivers which depend on PCI
(namely r128 and radeon), and it tries to use PCI specific functions
(pci_unmap_page, pci_map_page, and pci_dma_mapping_error) that cause
compiler errors when PCI is disabled.

Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: David Airlie airl...@linux.ie
---
 drivers/gpu/drm/Makefile |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2ff5cef..3e303b1b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -8,7 +8,7 @@ drm-y   :=  drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \
drm_context.o drm_dma.o \
drm_drv.o drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \
-   drm_agpsupport.o drm_scatter.o ati_pcigart.o drm_pci.o \
+   drm_agpsupport.o drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
@@ -16,6 +16,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
 
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
+drm-$(CONFIG_PCI) += ati_pcigart.o
 
 drm-usb-y   := drm_usb.o
 
-- 
1.7.7.6


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel