Re: [Intel-gfx] [PULL] drm-intel-fixes

[Dave Airlie]

On 2 January 2016 at 23:56, Jani Nikula  wrote:
>
> Hi Dave, Linus -

Hi Linus,

can you pull this directly, baby has arrived, but I'm not back at work yet.

Dave.

>
> Two display fixes still for v4.4.
>
> The new year's resolution is to start using signed tags per Linus'
> request. This one is still unsigned; I want to fix this up in our
> maintainer scripts instead of doing it one-off.
>
>
> BR,
> Jani.
>
> The following changes since commit a98728e0bb978fbe9246c93ea89198de612c22e6:
>
>   drm/i915: Correct max delay for HDMI hotplug live status checking 
> (2015-12-22 13:01:24 +0200)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-01-02
>
> for you to fetch changes up to 3d8acd1f667b45c531401c8f0c2033072e32a05d:
>
>   drm/i915: increase the tries for HDMI hotplug live status checking 
> (2015-12-30 13:58:37 +0200)
>
> 
> Gary Wang (1):
>   drm/i915: increase the tries for HDMI hotplug live status checking
>
> Ville Syrjälä (1):
>   drm/i915: Unbreak check_digital_port_conflicts()
>
>  drivers/gpu/drm/i915/intel_display.c | 12 
>  drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
>  2 files changed, 9 insertions(+), 5 deletions(-)
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: increase the tries for HDMI hotplug live status checking

[Wang, Gary C]

So sorry for it, and will keep in mind on this kind of mistake.

Gary

-Original Message-
From: Kumar, Shobhit [mailto:shobhit.ku...@linux.intel.com] 
Sent: Thursday, December 31, 2015 1:47 AM
To: Jani Nikula ; Wang, Gary C 
; intel-gfx@lists.freedesktop.org
Cc: Kumar, Shobhit 
Subject: Re: [Intel-gfx] [PATCH] drm/i915: increase the tries for HDMI hotplug 
live status checking

On 12/30/2015 05:27 PM, Jani Nikula wrote:
> On Wed, 23 Dec 2015, Gary Wang  wrote:
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> old mode 100644
>> new mode 100755
>
> Please pay more attention to not changing the file permissions.
>

Yeah, and the new permissions are merged in drm-intel-nightly. Needs correcting 
the permissions back.

Regards
Shobhit

> Thanks,
> Jani.
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] drm-intel-fixes

[Linus Torvalds]

On Jan 3, 2016 18:06, "Dave Airlie"  wrote:
>
> can you pull this directly, baby has arrived, but I'm not back at work
yet.

Assumed so, and already did. It's in rc8,

 Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ warning: Fi.CI.BAT

[Patchwork]

== Summary ==

Built on 79686f613b3955a4ed09cee936e7f70ec4e61b67 drm-intel-nightly: 
2015y-12m-30d-11h-59m-54s UTC integration manifest

Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS   (skl-i7k-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (ilk-hp8440p)
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (snb-x220t)
dmesg-warn -> PASS   (hsw-xps12)
dmesg-warn -> PASS   (hsw-brixbox)
dmesg-warn -> PASS   (bdw-nuci7)
dmesg-warn -> PASS   (ilk-hp8440p)
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (ivb-t430s)
Subgroup read-crc-pipe-a:
dmesg-warn -> PASS   (snb-x220t)
dmesg-warn -> PASS   (byt-nuc)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
dmesg-warn -> PASS   (snb-dellxps)

bdw-nuci7total:132  pass:122  dwarn:1   dfail:0   fail:0   skip:9  
bdw-ultratotal:132  pass:124  dwarn:2   dfail:0   fail:0   skip:6  
bsw-nuc-2total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
byt-nuc  total:135  pass:120  dwarn:2   dfail:0   fail:0   skip:13 
hsw-brixbox  total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2  total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
hsw-xps12total:132  pass:126  dwarn:2   dfail:0   fail:0   skip:4  
ilk-hp8440p  total:135  pass:100  dwarn:0   dfail:0   fail:0   skip:35 
ivb-t430stotal:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
skl-i7k-2total:135  pass:125  dwarn:2   dfail:0   fail:0   skip:8  
snb-dellxps  total:135  pass:122  dwarn:1   dfail:0   fail:0   skip:12 
snb-x220ttotal:135  pass:121  dwarn:2   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_1057/

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Suspend To RAM failure in >= 4.1 - bissected to "drm/i915: Track GEN6 page table usage"

[Sylvain Munaut]

Hi,

> I then ran a git bissect between v4.0 and v4.1 from Linus's tree and
> found the "guilty" commit was
>
> commit 317b4e903636305cfe702ab3e5b3d68547a69e72
> Author: Ben Widawsky 
> Date:   Mon Mar 16 16:00:55 2015 +
>
> drm/i915: Extract context switch skip and add pd load logic

Damnit, paste fail.

I meant to paste :

commit 678d96fbb3b5995a2fdff2bca5e1ab4a40b7e968
Author: Ben Widawsky 
Date:   Mon Mar 16 16:00:56 2015 +

drm/i915: Track GEN6 page table usage

(as indicated in the title and in the git bisect log)


Cheers,

   Sylvain
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Suspend To RAM failure in >= 4.1 - bissected to "drm/i915: Track GEN6 page table usage"

[Sylvain Munaut]

Hi,


When trying to upgrade my kernel yesterday to the latest 4.3.3 I
noticed that the suspend to ram was not working. Basically it goes to
sleep but never wakes up. It seems to power up but no screen, not
available through ssh either and afaict nothing runs afterwards.

I first tried a couple official release to see where it broke and I
found that 4.0.9 was working fine, but 4.1.15 was not.

I then ran a git bissect between v4.0 and v4.1 from Linus's tree and
found the "guilty" commit was

commit 317b4e903636305cfe702ab3e5b3d68547a69e72
Author: Ben Widawsky 
Date:   Mon Mar 16 16:00:55 2015 +

drm/i915: Extract context switch skip and add pd load logic


Here's the full log :

git bisect start
# bad: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
git bisect bad b953c0d234bc72e8489d3bf51a276c5c4ec85345
# good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0
git bisect good 39a8804455fb23f09157341d3ba7db6d7ae6ee76
# good: [d0a3997c0c3f9351e24029349dee65dd1d9e8d84] Merge tag
'sound-4.1-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good d0a3997c0c3f9351e24029349dee65dd1d9e8d84
# bad: [cf82f52d3619d2e15c83ec9a03c6ce8cdf6c6b58] watchdog:
stmp3xxx_rtc_wdt: fix broken email address
git bisect bad cf82f52d3619d2e15c83ec9a03c6ce8cdf6c6b58
# good: [79319a052cb0ae862954fe9f6e606417f1698ddb] Merge tag
'iommu-updates-v4.1' of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
git bisect good 79319a052cb0ae862954fe9f6e606417f1698ddb
# bad: [8f443e2372ba23d51ee365974f54507acd6f69d1] Revert "ocfs2:
incorrect check for debugfs returns"
git bisect bad 8f443e2372ba23d51ee365974f54507acd6f69d1
# bad: [3165c074175cddab1dcfd553042ea4f363bc76e7] drm/i915: Use atomic
state in intel_ddi_crtc_get_new_encoder()
git bisect bad 3165c074175cddab1dcfd553042ea4f363bc76e7
# good: [8dd0eb3566711d81bfbe2b4421b33f0dd723cec4] Merge tag
'drm-intel-next-2015-02-27' of git://anongit.freedesktop.org/drm-intel
into drm-next
git bisect good 8dd0eb3566711d81bfbe2b4421b33f0dd723cec4
# good: [5704195c3f3c04a00c16334a033b180f16db1f94] drm/i915/skl:
Updated the gen6_set_rps function
git bisect good 5704195c3f3c04a00c16334a033b180f16db1f94
# good: [07749ef32c4fd60334c2451739460dd1cf600281] drm/i915: page
table generalizations
git bisect good 07749ef32c4fd60334c2451739460dd1cf600281
# bad: [58072ccbb81c6f2d67c5b4cc7597707c4fb86a5e] drm/i915: fix race
when clearing RPS IIR bits
git bisect bad 58072ccbb81c6f2d67c5b4cc7597707c4fb86a5e
# bad: [48fe4691ae639e60fda37faf06dccdff60245149] drm/i915: Eliminate
plane control register RMW from sprite code
git bisect bad 48fe4691ae639e60fda37faf06dccdff60245149
# bad: [bdd7554d568fa165b0e86fc32b1cde3c895ff774] drm/i915: Kill
intel_plane->obj
git bisect bad bdd7554d568fa165b0e86fc32b1cde3c895ff774
# bad: [678d96fbb3b5995a2fdff2bca5e1ab4a40b7e968] drm/i915: Track GEN6
page table usage
git bisect bad 678d96fbb3b5995a2fdff2bca5e1ab4a40b7e968
# good: [317b4e903636305cfe702ab3e5b3d68547a69e72] drm/i915: Extract
context switch skip and add pd load logic
git bisect good 317b4e903636305cfe702ab3e5b3d68547a69e72
# first bad commit: [678d96fbb3b5995a2fdff2bca5e1ab4a40b7e968]
drm/i915: Track GEN6 page table usage


The machine is a Lenovo T440s laptop :


00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
Integrated Graphics Controller (rev 0b)
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
00:16.3 Serial controller: Intel Corporation 8 Series HECI KT (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection
I218-LM (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 6 (rev e4)
00:1c.1 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4)
00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4)
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1
[AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
RTS5227 PCI Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
04:00.0 VGA compatible controller: NVIDIA Corporation GK208M [GeForce
GT 730M] (rev a1)


Cheers,

Sylvain Munaut
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: correctly handling failed allocation

[Insu Yun]

On Wed, Dec 30, 2015 at 4:16 AM, Jani Nikula 
wrote:

> On Tue, 29 Dec 2015, Insu Yun  wrote:
> > Signed-off-by: Insu Yun 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > index a5e99ac..4e279dd 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > @@ -666,6 +666,8 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> >
> >   /* This is cheating a bit with the cleanup. */
> >   vbt_panel = devm_kzalloc(dev->dev, sizeof(*vbt_panel), GFP_KERNEL);
> > + if (!vbt_pannel)
> > + return NULL;
>

Oh sorry. There was a type.


>
> We have build bots and CI, but the least you must do is build the code
> you change before submitting patches.
>

Yes. Sorry.


>
> BR,
> Jani.
>
>
> >
> >   vbt_panel->intel_dsi = intel_dsi;
> >   drm_panel_init(_panel->panel);
>
> --
> Jani Nikula, Intel Open Source Technology Center
>



-- 
Regards
Insu Yun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu

[Christoph Mathys]

On Tue, Dec 22, 2015 at 4:37 PM, Sebastian Andrzej Siewior
 wrote:
> I have to admit, the i915 tries very hard to avoid running on -RT. Could
> you try the s/local_irq_disable();/local_irq_disable_nort();/ patch
> mentioned in the thread?

It did not crash so far, I did some usual work and executed glmark2
several times. The BUG has not surfaced again. BUT, the latency is
still far from ideal, it takes only seconds for the maximum latency to
spike into the range of milliseconds. By the way, this is now
4.1.15-rt17 with the changes from here:
http://www.spinics.net/lists/linux-rt-users/msg13543.html

During some tests with cyclictests --breaktrace I've seen more BUG
messages, but they might relate to the kernel tracing. Unfortunately,
I could not make much of the --breaktrace.

[ 4629.753864] BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:917
[ 4629.753865] in_atomic(): 1, irqs_disabled(): 0, pid: 1913, name: Xorg
[ 4629.753866] 2 locks held by Xorg/1913:
[ 4629.753879]  #0:  (crtc_ww_class_acquire){+.+.+.}, at:
[] drm_modeset_lock_crtc+0x4c/0x100 [drm]
[ 4629.753887]  #1:  (crtc_ww_class_mutex){+.+.+.}, at:
[] drm_modeset_lock+0x41/0x130 [drm]
[ 4629.753888] CPU: 4 PID: 1913 Comm: Xorg Tainted: GE
4.1.15-i915-patch-realtime-1-rt17+ #4
[ 4629.753889] Hardware name: Komax AG, Dierikon Komax-PC/KMX-B75,
BIOS DD3-1-1D 08/21/2013
[ 4629.753891]  81c862ce 8803e92538b8 81805313
5b10
[ 4629.753892]  8803e8baa660 8803e92538e8 8108813a
8803e92538d8
[ 4629.753893]  8803fe6d0070 8803fe6d0070 8803fe6d0068
8803e9253918
[ 4629.753893] Call Trace:
[ 4629.753897]  [] dump_stack+0x4a/0x61
[ 4629.753899]  [] ___might_sleep+0x13a/0x200
[ 4629.753901]  [] rt_spin_lock+0x24/0x60
[ 4629.753916]  [] gen6_read32+0x46/0x380 [i915]
[ 4629.753925]  [] gm45_get_vblank_counter+0x32/0x40 [i915]
[ 4629.753934]  []
ftrace_raw_event_i915_pipe_update_start+0x65/0xb0 [i915]
[ 4629.753944]  [] intel_pipe_update_start+0x2a3/0x640 [i915]
[ 4629.753946]  [] ? prepare_to_wait_event+0x130/0x130
[ 4629.753956]  [] intel_begin_crtc_commit+0x166/0x1e0 [i915]
[ 4629.753961]  []
drm_plane_helper_commit+0x112/0x2c0 [drm_kms_helper]
[ 4629.753963]  [] drm_plane_helper_update+0x9a/0xf0
[drm_kms_helper]
[ 4629.753970]  [] __setplane_internal+0x248/0x350 [drm]
[ 4629.753975]  [] drm_mode_cursor_universal+0x125/0x210 [drm]
[ 4629.753981]  [] drm_mode_cursor_common+0x7f/0x1b0 [drm]
[ 4629.753987]  [] drm_mode_cursor_ioctl+0x41/0x50 [drm]
[ 4629.753992]  [] drm_ioctl+0x349/0x690 [drm]
[ 4629.753998]  [] ? drm_mode_setcrtc+0x630/0x630 [drm]
[ 4629.753999]  [] ? local_clock+0x25/0x30
[ 4629.754001]  [] ? lock_release_holdtime.part.31+0xd3/0x1a0
[ 4629.754002]  [] do_vfs_ioctl+0x328/0x5e0
[ 4629.754004]  [] ? __fget+0x5/0x210
[ 4629.754004]  [] ? __fget_light+0x2a/0xa0
[ 4629.754005]  [] SyS_ioctl+0x81/0xa0
[ 4629.754007]  [] tracesys_phase2+0x88/0x8d

[  361.526236] BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:917
[  361.526237] in_atomic(): 1, irqs_disabled(): 0, pid: 667, name: irq/51-i915
[  361.526237] no locks held by irq/51-i915/667.
[  361.526239] CPU: 4 PID: 667 Comm: irq/51-i915 Tainted: G
E   4.1.15-i915-patch-realtime-1-rt17+ #4
[  361.526240] Hardware name: Komax AG, Dierikon Komax-PC/KMX-B75,
BIOS DD3-1-1D 08/21/2013
[  361.526242]  81c862ce 8803fe6e7b58 81805313

[  361.526243]  8803ff3d4cc0 8803fe6e7b88 8108813a
0296
[  361.526244]  8803fe6d0070 8803fe6d0070 8803fe6d0068
8803fe6e7bb8
[  361.526244] Call Trace:
[  361.526249]  [] dump_stack+0x4a/0x61
[  361.526251]  [] ___might_sleep+0x13a/0x200
[  361.526253]  [] rt_spin_lock+0x24/0x60
[  361.526281]  [] gen6_read32+0x46/0x380 [i915]
[  361.526283]  [] ? trace_event_buffer_lock_reserve+0x40/0x80
[  361.526293]  [] gen6_ring_get_seqno+0x2f/0x40 [i915]
[  361.526301]  []
ftrace_raw_event_i915_gem_request_notify+0x5f/0x90 [i915]
[  361.526309]  [] notify_ring.isra.12+0xcd/0x240 [i915]
[  361.526316]  [] snb_gt_irq_handler+0x12c/0x180 [i915]
[  361.526323]  [] ironlake_irq_handler+0x1c7/0xfe0 [i915]
[  361.526324]  [] ? finish_task_switch+0x4d/0x140
[  361.526325]  [] irq_forced_thread_fn+0x27/0x70
[  361.526326]  [] irq_thread+0x149/0x1f0
[  361.526327]  [] ? irq_thread_fn+0x40/0x40
[  361.526328]  [] ? wake_threads_waitq+0x30/0x30
[  361.526329]  [] ? irq_thread_check_affinity+0x70/0x70
[  361.526330]  [] kthread+0xe4/0x100
[  361.526332]  [] ? trace_hardirqs_on+0xd/0x10
[  361.526333]  [] ? kthread_create_on_node+0x240/0x240
[  361.526334]  [] ret_from_fork+0x42/0x70
[  361.526335]  [] ? kthread_create_on_node+0x240/0x240
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] i915: correctly handling failed allocation

[Insu Yun]

Signed-off-by: Insu Yun 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac..4e279dd 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -666,6 +666,8 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
*intel_dsi, u16 panel_id)
 
/* This is cheating a bit with the cleanup. */
vbt_panel = devm_kzalloc(dev->dev, sizeof(*vbt_panel), GFP_KERNEL);
+   if (!vbt_pannel)
+   return NULL;
 
vbt_panel->intel_dsi = intel_dsi;
drm_panel_init(_panel->panel);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] i915: correctly handling failed allocation

[Insu Yun]

Since devm_kzalloc can be failed, it needs to be checked
if not, NULL dereference could be happened.

Signed-off-by: Insu Yun 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac..aa1f7bc 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -666,6 +666,8 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
*intel_dsi, u16 panel_id)
 
/* This is cheating a bit with the cleanup. */
vbt_panel = devm_kzalloc(dev->dev, sizeof(*vbt_panel), GFP_KERNEL);
+   if (!vbt_panel)
+   return NULL;
 
vbt_panel->intel_dsi = intel_dsi;
drm_panel_init(_panel->panel);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/docs: more leftovers from the big vtable documentation pile

[Daniel Vetter]

Another pile of vfuncs from the old gpu.tmpl xml documentation that
I've forgotten to delete. I spotted a few more things to
clarify/extend in the new kerneldoc while going through this once
more.

v2: Spelling fixes (Thierry).

Cc: Laurent Pinchart 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/gpu.tmpl   | 188 ---
 include/drm/drm_modeset_helper_vtables.h |  28 -
 2 files changed, 25 insertions(+), 191 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index a3764291c826..c0fa21c797fe 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1579,194 +1579,6 @@ void intel_crt_init(struct drm_device *dev)
   entities.
 
 
-  Legacy CRTC Helper Operations
-  
-
-  bool (*mode_fixup)(struct drm_crtc *crtc,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
-  
-Let CRTCs adjust the requested mode or reject it completely. This
-operation returns true if the mode is accepted (possibly after 
being
-adjusted) or false if it is rejected.
-  
-  
-The mode_fixup operation should reject the
-mode if it can't reasonably use it. The definition of "reasonable"
-is currently fuzzy in this context. One possible behaviour would be
-to set the adjusted mode to the panel timings when a fixed-mode
-panel is used with hardware capable of scaling. Another behaviour
-would be to accept any input mode and adjust it to the closest mode
-supported by the hardware (FIXME: This needs to be clarified).
-  
-
-
-  int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
-  
-Move the CRTC on the current frame buffer (stored in
-crtc-fb) to position (x,y). Any of the frame
-buffer, x position or y position may have been modified.
-  
-  
-This helper operation is optional. If not provided, the
-drm_crtc_helper_set_config function will fall
-back to the mode_set helper operation.
-  
-  
-FIXME: Why are x and y passed as arguments, as they can be accessed
-through crtc-x and
-crtc-y?
-  
-
-
-  void (*prepare)(struct drm_crtc *crtc);
-  
-Prepare the CRTC for mode setting. This operation is called after
-validating the requested mode. Drivers use it to perform
-device-specific operations required before setting the new mode.
-  
-
-
-  int (*mode_set)(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode, int x, int y,
-struct drm_framebuffer *old_fb);
-  
-Set a new mode, position and frame buffer. Depending on the device
-requirements, the mode can be stored internally by the driver and
-applied in the commit operation, or
-programmed to the hardware immediately.
-  
-  
-The mode_set operation returns 0 on 
success
-   or a negative error code if an error occurs.
-  
-
-
-  void (*commit)(struct drm_crtc *crtc);
-  
-Commit a mode. This operation is called after setting the new mode.
-Upon return the device must use the new mode and be fully
-operational.
-  
-
-  
-
-
-  Encoder Helper Operations
-  
-
-  bool (*mode_fixup)(struct drm_encoder *encoder,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
-  
-Let encoders adjust the requested mode or reject it completely. 
This
-operation returns true if the mode is accepted (possibly after 
being
-adjusted) or false if it is rejected. See the
-mode_fixup CRTC helper
-operation for an explanation of the allowed adjustments.
-  
-
-
-  void (*prepare)(struct drm_encoder *encoder);
-  
-Prepare the encoder for mode setting. This operation is called 
after
-validating the requested mode. Drivers use it to perform
-device-specific operations required before setting the new mode.
-  
-
-
-  void (*mode_set)(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode);
-  

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Save/Restore Backlight registers when PG0 is gated

[Jani Nikula]

On Sat, 02 Jan 2016, Jani Nikula  wrote:
> On Thu, 31 Dec 2015, Vidya Srinivas  wrote:
>> Currently Backlight registers which are associated with Power Well 0
>> are not being saved before gating the power well for S0ix. Hence,
>> upon resume from S0ix, these registers are not being restored. Due to
>> this, the display has resumed and since there is no backlight, nothing is
>> seen. Patch fixes this issue by saving/restoring BLC registers for S0ix.
>
> No, this is not the approach.
>
> The backlight disable/enable hooks should handle this by always writing
> the full state of the registers on enable. Doing blind register copies
> (and read-modify-writes) is what we've been trying to get rid of across
> the driver.

To be more specific, we *already* write the full state to the three
registers in bxt_enable_backlight(). Your conclusions in the commit
message are wrong. If you're seeing issues, it must be about the
sequence in which the registers are written. Please look into that.

BR,
Jani.

>
> BR,
> Jani.
>
>
>>
>> Signed-off-by: A.Sunil Kamath 
>> Signed-off-by: Vidya Srinivas 
>> ---
>>  drivers/gpu/drm/i915/intel_drv.h   |  4 
>>  drivers/gpu/drm/i915/intel_panel.c | 18 ++
>>  2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 50f83d2..752fb58 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -193,6 +193,10 @@ struct intel_panel {
>>uint32_t hz);
>>  void (*power)(struct intel_connector *, bool enable);
>>  } backlight;
>> +
>> +u32 blc_pwm_ctl;
>> +u32 blc_pwm_freq;
>> +u32 blc_pwm_duty;
>>  };
>>  
>>  struct intel_connector {
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index ae808b6..421cd3a 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -816,6 +816,16 @@ static void bxt_disable_backlight(struct 
>> intel_connector *connector)
>>  val &= ~UTIL_PIN_ENABLE;
>>  I915_WRITE(UTIL_PIN_CTL, val);
>>  }
>> +
>> +/* Saving BLC registers for PG0 gating */
>> +panel->blc_pwm_ctl =
>> +I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>> +panel->blc_pwm_freq =
>> +I915_READ(BXT_BLC_PWM_FREQ(panel->backlight.controller));
>> +panel->blc_pwm_duty =
>> +I915_READ(BXT_BLC_PWM_DUTY(panel->backlight.controller));
>> +
>> +
>>  }
>>  
>>  static void pwm_disable_backlight(struct intel_connector *connector)
>> @@ -1050,6 +1060,14 @@ static void bxt_enable_backlight(struct 
>> intel_connector *connector)
>>  enum pipe pipe = intel_get_pipe_from_connector(connector);
>>  u32 pwm_ctl, val;
>>  
>> +/* Restore BLC registers if PG0 was gated */
>> +I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
>> +panel->blc_pwm_ctl);
>> +I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
>> +panel->blc_pwm_freq);
>> +I915_WRITE(BXT_BLC_PWM_DUTY(panel->backlight.controller),
>> +panel->blc_pwm_duty);
>> +
>>  /* To use 2nd set of backlight registers, utility pin has to be
>>   * enabled with PWM mode.
>>   * The field should only be changed when the utility pin is disabled

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/docs: more leftovers from the big vtable documentation pile

[Daniel Vetter]

On Mon, Dec 28, 2015 at 11:22:52AM +0100, Thierry Reding wrote:
> On Wed, Dec 16, 2015 at 06:18:25PM +0100, Daniel Vetter wrote:
> > Another pile of vfuncs from the old gpu.tmpl xml documentation that
> > I've forgotten to delete. I spotted a few more things to
> > clarify/extend in the new kerneldoc while going through this once
> > more.
> > 
> > Cc: Laurent Pinchart 
> > Cc: Thierry Reding 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  Documentation/DocBook/gpu.tmpl   | 188 
> > ---
> >  include/drm/drm_modeset_helper_vtables.h |  28 -
> >  2 files changed, 25 insertions(+), 191 deletions(-)
> > 
> > diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> > index a3764291c826..c0fa21c797fe 100644
> > --- a/Documentation/DocBook/gpu.tmpl
> > +++ b/Documentation/DocBook/gpu.tmpl
> > @@ -1579,194 +1579,6 @@ void intel_crt_init(struct drm_device *dev)
> >entities.
> >  
> >  
> > -  Legacy CRTC Helper Operations
> > -  
> > -
> > -  bool (*mode_fixup)(struct drm_crtc *crtc,
> > -   const struct drm_display_mode *mode,
> > -   struct drm_display_mode *adjusted_mode);
> > -  
> > -Let CRTCs adjust the requested mode or reject it completely. 
> > This
> > -operation returns true if the mode is accepted (possibly after 
> > being
> > -adjusted) or false if it is rejected.
> > -  
> > -  
> > -The mode_fixup operation should 
> > reject the
> > -mode if it can't reasonably use it. The definition of 
> > "reasonable"
> > -is currently fuzzy in this context. One possible behaviour 
> > would be
> > -to set the adjusted mode to the panel timings when a fixed-mode
> > -panel is used with hardware capable of scaling. Another 
> > behaviour
> > -would be to accept any input mode and adjust it to the closest 
> > mode
> > -supported by the hardware (FIXME: This needs to be clarified).
> > -  
> > -
> 
> I just noticed that this deviates somewhat from what is now in the new
> documentation in include/drm/drm_modeset_helper_vtables.h. The new
> documentation suggests that ->mode_fixup() should not modify
> adjusted_mode but instead reject the mode if the conversion from mode to
> adjusted_mode can't be supported. The new definition sounds much saner
> to me, because if we allowed the CRTC's ->mode_fixup() to modify the
> adjusted_mode, we'd need to make sure that the encoder (and bridge)
> still accept it. And we'd need to potentially reiterate until everybody
> agrees.

Yeah, I simply addressed the FIXME while typing the new docs and made this
a strong recommendation (that's why I picked "should" instead of "must").
There's some drivers (at least i915's TV-out) where the input mode is
massively mangled, but no one will ever fix this.

> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 29e0dc50031d..b995d5ec50a0 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -131,6 +131,12 @@ struct drm_crtc_helper_funcs {
> >  * Atomic drivers which need to inspect and adjust more state should
> >  * instead use the @atomic_check callback.
> >  *
> > +* Also beware that the core nor helpers filters mode before passing the
> 
> "... neither the core nor the helpers filter modes before passing them ..."?
> 
> > +* to the driver. More specifically modes rejected by the ->mode_valid
> > +* callback from #drm_connector_helper_funcs can still be requested by
> > +* userspace and therefore also need to be rejected in either this hook,
> > +* or the one in #drm_encoder_helper_funcs.
> 
> Hmm... that's odd. Why would one want to allow a mode that the connector
> can't support? Also looking at drm_helper_probe_single_connector_modes()
> this isn't quite true. That helper is used by all connectors except
> vmwgfx. It also calls drm_mode_prune_invalid(), which will remove all
> modes from the connector's mode list that don't have status == MODE_OK.
> As far as I can see after they've been removed from the connector's mode
> list they will no longer be exposed to userspace.

Maybe I need to hammer this in more, but it's a common misconception that
userspace can only ask for modes in the connector list. Generally that's
what's happening, but there's not restrictions on userspace to ask for a
mode which is _not_ in the connector's mode list.

If you don't believe that, look at xrandr --addmode and try yourself.

That's why drivers MUST filter modes in both mode_valid and mode_fixup.
Any suggestions for how to make this even more clear?

Aside, I tried looking into untangling this a bit with a helper to

Re: [Intel-gfx] [PATCH] drm/dp/mst: constify drm_dp_mst_topology_cbs structures

[Daniel Vetter]

On Wed, Dec 30, 2015 at 10:20:30PM +0100, Julia Lawall wrote:
> The drm_dp_mst_topology_cbs structures are never modified, so declare them
> as const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Applied to drm-misc, thanks.
-Daniel

> 
> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c|2 +-
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |2 +-
>  include/drm/drm_dp_mst_helper.h|2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 74b5888..b37b859 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -421,7 +421,7 @@ struct drm_dp_payload {
>  struct drm_dp_mst_topology_mgr {
>  
>   struct device *dev;
> - struct drm_dp_mst_topology_cbs *cbs;
> + const struct drm_dp_mst_topology_cbs *cbs;
>   int max_dpcd_transaction_bytes;
>   struct drm_dp_aux *aux; /* auxch for this topology mgr to use */
>   int max_payloads;
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c 
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index 94323f5..8a02225 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> @@ -329,7 +329,7 @@ static void radeon_dp_mst_hotplug(struct 
> drm_dp_mst_topology_mgr *mgr)
>   drm_kms_helper_hotplug_event(dev);
>  }
>  
> -struct drm_dp_mst_topology_cbs mst_cbs = {
> +const struct drm_dp_mst_topology_cbs mst_cbs = {
>   .add_connector = radeon_dp_add_mst_connector,
>   .register_connector = radeon_dp_register_mst_connector,
>   .destroy_connector = radeon_dp_destroy_mst_connector,
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index e2f515d..fa0dabf 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -534,7 +534,7 @@ static void intel_dp_mst_hotplug(struct 
> drm_dp_mst_topology_mgr *mgr)
>   drm_kms_helper_hotplug_event(dev);
>  }
>  
> -static struct drm_dp_mst_topology_cbs mst_cbs = {
> +static const struct drm_dp_mst_topology_cbs mst_cbs = {
>   .add_connector = intel_dp_add_mst_connector,
>   .register_connector = intel_dp_register_mst_connector,
>   .destroy_connector = intel_dp_destroy_mst_connector,
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Intel graphics on Thinkpad T540p is most unsuable now :( (Intel(R) HD Graphics 4600)

[Marc MERLIN]

On Sat, Dec 19, 2015 at 08:52:17AM -0800, Marc MERLIN wrote:
> > Thanks both. I filed a bug as requested:
> > https://bugs.freedesktop.org/show_bug.cgi?id=93438
> > 
> > It just crashed again, same crash. Looks like I'm going to get a crash every
> > 2 days or so at this stage.
> 
> Sigh, same crash again today.
> Ok, I can't take it anymore, this amount of crashing and data loss is
> not something I can deal with.
> 
> I went back to kernel 4.1.3, where things were working well enough.
> Hopefully I won't stay stuck with 4.1 forever or until I get rid of my
> intel graphics chipset.

I wish you all a happy new year.
Sadly, my time off was filled with Xorg crashes and more data loss.

The old xserver-xorg-video-intel 2:2.99.917-1 fails with 4.1.15 and
4.3.3 but when it does, my mouse keeps working, sound on an mplayer
video keeps working (but no video), and I can switch back to a text
console.
The X server does not come back to life though.

With 2:2.99.917+git20151217-1~exp1 , X server deadlocks, everything is
lost, I need to power cycle (both with 4.1.15 and 4.3.3).

I've updated https://bugs.freedesktop.org/show_bug.cgi?id=93438
but now I really really regret having gotten intel graphics for my
laptop. In the past performance was so poor that it was barely usable at
times.
Now performance is better, but when the driver doesn't crash (it did
stop crashing), it just deadlocks and I lose everything.

Is anyone working on the driver using a laptop with (Intel(R) HD
Graphics 4600 and a 3K screen for daily work?
If not, can you please have someone do this so that you can see the
problems with the driver and you can experience the problems before me?

My hunch at this point is that google-chrome-beta is taxing the GPU and
causing the driver to misbehave. I'm now back to
2:2.99.917+git20151217-1~exp1 and 4.3.3 and will run google-chrome-beta
--disable-gpu, but this kills other stuff I need and won't be working
anymore as a result :(

Whoever someone working on the driver can test that chip with a 3K
screen, please run google-chrome-beta for a few days with a bunch of
tabs, some 3D, and all.

If things don't get better, I'll just get a new laptop with an nvidia
chip since I can't really bear these instabilities much longer. I really
don't want to go there, but if I'm out of options, it's the only path
left I see :(

Thanks for looking,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i965 LVDS mode setting questions

[Alexander von Gluck IV]

December 29 2015 6:37 PM, "Alexander von Gluck IV"  
wrote:
> I'm working on getting our intel driver cleaned up under Haiku.
> 
> i965 was working, however I have run into a few strange issues
> with the LVDS control changing on it's own after setting after
> my rewrite.

Sigh.

LVDS port control moves the polarization from bits 3 -> 20.
Later code was assuming all connectors had polarization at bit 3.

Please ignore.

Thanks!
 -- Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx