Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

On Wed, Apr 9, 2014 at 4:07 PM, Daniel J Blueman wrote: > On 9 April 2014 11:41, Dave Airlie wrote: >> On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman wrote: >>> On 8 April 2014 15:14, Jani Nikula wrote: On Tue, 08 Apr 2014, Daniel J Blueman wrote: > Ville et al, > > It looks

Re: [Intel-gfx] [PATCH 0/2] Optimization on intel HDMI detect and get_modes

Hello Quanxian Wang This patch is available and working on all MCG tree's (Main, R42B and R44B) We were trying to opensource this patch, but due to the dependency on live_status reg, we had to change the design. I was working on that, but couldn't finish the activity yet, Thanks for reminding

Re: [Intel-gfx] [PATCH] drm/mm: Don't WARN if drm_mm_reserve_node

On Tue, Apr 08, 2014 at 10:21:44AM -0700, Ben Widawsky wrote: > I am not convinced this is the correct solution. At least the way we > used this interface, it isn't meant to ever fail. I also didn't look > into exactly why we depend an ENOSPC return. That sounds fragile to me, > especially for a p

Re: [Intel-gfx] [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command

On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.vol...@intel.com wrote: > From: Brad Volkin > > The command parser in newer kernels will reject it and setting this > bit is not required for the actual test case. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670 > Signed-off-by

Re: [Intel-gfx] [PATCH 0/2] Optimization on intel HDMI detect and get_modes

Hi, Sharma, Shashank Is there any following patches to make it happen? Thanks Regards Quanxian Wang >-Original Message- >From: intel-gfx-boun...@lists.freedesktop.org >[mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Sharma, Shashank >Sent: Tuesday, January 14, 2014 1:20 A

[Intel-gfx] [BUG] Cursor code broken

Hi Chris! The intel xorg driver cursor code is broken, at least on my system. The last good commit is 3810cff42bca1badc5844002694a6f582c0f423. Hardware: AOpen i915GMm-hfs with Pentium-M Dothan cpu Software: openSuSE 13.1, kernel 3.14, xorg git master, kde Expected behavior: === I

Re: [Intel-gfx] [PATCH] drm/i915: Make vm eviction uninterruptible

On Tue, Apr 08, 2014 at 09:09:14PM -0700, Ben Widawsky wrote: > This is no more or less flagrant than any other use. Evict CANNOT finish > if we get interrupted by a signal. If we can't properly evict everything > from the address space, I can't make any guarantee about anything being > clean when

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

On 9 April 2014 11:41, Dave Airlie wrote: > On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman wrote: >> On 8 April 2014 15:14, Jani Nikula wrote: >>> On Tue, 08 Apr 2014, Daniel J Blueman wrote: Ville et al, It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or an

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Bring UP Power Wells before disabling RC6.

On 4/9/2014 9:43 AM, Ben Widawsky wrote: On Tue, Apr 08, 2014 at 06:22:52PM +0530, S, Deepak wrote: On 4/8/2014 6:13 PM, Ville Syrjälä wrote: On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote: On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote: From: Deepak S We nee

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Bring UP Power Wells before disabling RC6.

On Tue, Apr 08, 2014 at 06:22:52PM +0530, S, Deepak wrote: > > > On 4/8/2014 6:13 PM, Ville Syrjälä wrote: > >On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote: > >>On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote: > >>>From: Deepak S > >>> > >>>We need do forcewake before

Re: [Intel-gfx] [PATCH] drm/i915: Make vm eviction uninterruptible

On Tue, Apr 08, 2014 at 08:53:15AM +0200, Daniel Vetter wrote: > On Mon, Apr 7, 2014 at 11:58 PM, Ben Widawsky wrote: > > Blocking important fixes for a test case is harmful to customers of our > > software. I won't argue past that. If you won't take it as is, add it to the > > JIRA task like you

Re: [Intel-gfx] [PATCH] drm/i915: Make vm eviction uninterruptible

On Tue, Apr 08, 2014 at 07:50:39AM +0100, Chris Wilson wrote: > On Mon, Apr 07, 2014 at 02:58:34PM -0700, Ben Widawsky wrote: > > Blocking important fixes for a test case is harmful to customers of our > > software. I won't argue past that. If you won't take it as is, add it to the > > JIRA task li

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman wrote: > On 8 April 2014 15:14, Jani Nikula wrote: >> On Tue, 08 Apr 2014, Daniel J Blueman wrote: >>> Ville et al, >>> >>> It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or >>> another commit in 3.13.7) broke modes which require D

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

Ville et al, On 8 April 2014 16:02, Daniel Vetter wrote: > On Tue, Apr 8, 2014 at 9:32 AM, Daniel J Blueman wrote: >> I am using a dual-link DVI-D to DVI-D cable to this monitor, since I >> previously couldn't get 2560x1440 via HDMI. >> >> If it isn't this commit, then it may be another commit i

[Intel-gfx] [PATCH 1/5] drm/i915: Split the BDW device definition to prepare for dual BSD rings on BDW GT3

Based on the hardware spec, the BDW GT3 has the different configuration with the BDW GT1/GT2. So split the BDW device info definition. This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine. Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/i915_drv.c | 24

[Intel-gfx] [PATCH 4/5] drm/i915:Add the VCS2 switch in Intel_ring_setup_status_page for Gen7 to remove the switch check warning

The Gen7 doesn't have the second BSD ring. But it will complain the switch check warning message during compilation. So just add it to remove the switch check warning. Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/intel_ringbuffer.c |1 + 1 file changed, 1 insertion(+) diff --git a/dri

[Intel-gfx] [PATCH 0/5] drm/i915: Add the support of dual BSD rings on BDW GT3

This is the patch set that tries to add the support of dual BSD rings on BDW GT3. Based on hardware spec, the BDW GT3 has two independent BSD rings, which can be used to process the video commands. To be simpler, it is transparent to user-space driver/middleware. In such case the kernel driver wi

[Intel-gfx] [PATCH 3/5] drm/i915:Handle the irq interrupt for the second BSD ring

Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/i915_irq.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index bdda3b5..d5b1dd3 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915

[Intel-gfx] [PATCH 2/5] drm/i915:Initialize the second BSD ring on BDW GT3 machine

Based on the hardware spec, the BDW GT3 machine has two independent BSD ring that can be used to dispatch the video commands. So just initialize it. Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/i915_drv.c |4 +-- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/dr

[Intel-gfx] [PATCH 5/5] drm/i915:Use the coarse mechanism based on drm fd to dispatch the BSD command on BDW GT3

The BDW GT3 has two independent BSD rings, which can be used to process the video commands. To be simpler, it is transparent to user-space driver/middleware. Instead the kernel driver will decide which ring is to dispatch the BSD video command. As every BSD ring is powerful, it is enough to dispa

[Intel-gfx] [PATCH] drm/i915: Add more registers to the whitelist for mesa

From: Brad Volkin These are additional registers needed for performance monitoring and ARB_draw_indirect extensions in mesa. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76719 Cc: Kenneth Graunke Signed-off-by: Brad Volkin --- drivers/gpu/drm/i915/i915_cmd_parser.c | 9 + dr

[Intel-gfx] [PATCH 3/3] drm/i915: Add aspect ratio property for HDMI

Create and attach the drm property to set aspect ratio. If there is no user specified value, then PAR_NONE/Automatic option is set by default. User can select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would come into effect with a mode set. Signed-off-by: Vandana Kannan --- dri

[Intel-gfx] [PATCH 2/3] drm/edid: Check for user aspect ratio input

In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. Signed-off-by: Vandana Kannan Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file changed, 7

[Intel-gfx] [PATCH 1/3] drm/crtc: Add property for aspect ratio

Added a property to enable user space to set aspect ratio. This patch contains declaration of the property and code to create the property. Signed-off-by: Vandana Kannan Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/drm_crtc.c | 31 +++ include/drm/drm_crtc.

[Intel-gfx] [PATCH v2 5/15] drm/i915: take init power domain for sysfs/debugfs entries where needed

v2: - make it actually compile, I managed to send the wrong version as v1 somehow Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 18 -- drivers/gpu/drm/i915/i915_sysfs.c | 4 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/gpu

Re: [Intel-gfx] [PATCH] tests/gem_exec_parse: Test for OACONTROL tracking

Hi Daniel, we've merged the kernel change for this but not the test. I'm assuming we still want the test case. Brad On Thu, Mar 27, 2014 at 11:44:45AM -0700, Volkin, Bradley D wrote: > From: Brad Volkin > > Signed-off-by: Brad Volkin > --- > tests/gem_exec_parse.c | 48 +++

[Intel-gfx] [PATCH] tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command

From: Brad Volkin The command parser in newer kernels will reject it and setting this bit is not required for the actual test case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670 Signed-off-by: Brad Volkin --- tests/gen7_forcewake_mt.c | 55 +--

[Intel-gfx] [PATCH] dri3: Print log message

Whe currently only print a "direct rendering: DRI2 Enabled" which seems to confuse people so add a "DRI3 enabled" message as well when successfully initalizing dri3. Signed-off-by: Adel Gadllah Reviewed-by: Keith Packard --- src/uxa/intel_dri3.c | 2 +- src/uxa/intel_driver.c | 3 ++- 2 files

[Intel-gfx] [PATCH] dri3: Print log message

This is based on the not yet merged dri3 branch, it simply adds a log message to avoid user confusion. Adel Gadllah (1): dri3: Print log message src/uxa/intel_dri3.c | 2 +- src/uxa/intel_driver.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) -- 1.9.0 _

Re: [Intel-gfx] Fujitsu S6010 still woes (partially)

On 08.04.2014 18:10, Daniel Vetter wrote: On Tue, Apr 8, 2014 at 2:05 PM, Thomas Richter Also, from the linux suspend mechanism, /usr/lib/pm-utils/sleep.d/99video is just useless or breaks more than it helps. I just removed it. It tries some weird workarounds that are not beneficial, and the d

Re: [Intel-gfx] [PATCH] drm/mm: Don't WARN if drm_mm_reserve_node

On Mon, Apr 07, 2014 at 10:13:13PM -0700, Jesse Barnes wrote: > On Mon, 7 Apr 2014 23:25:20 +0200 > Daniel Vetter wrote: > > > Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC > > return value to detect overlapping framebuffers (which the bios uses > > always when lighting up m

Re: [Intel-gfx] [PATCH 1/5] dmr/i915: Displayport - Add a function to set the training pattern

Hi 2014-04-08 14:47 GMT-03:00 Todd Previte : > Adds a function to set the training pattern for Displayport. This is > functionality required to establish more fine-grained control over > the Displayport interface, both for operational reliability and > compliance testing. Just a suggestion: it's

[Intel-gfx] [PATCH 12/15] drm/i915: add various missing GTI/Gunit register definitions

Needed by the VLV S0ix context save/restore helpers. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_reg.h | 43 - 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

[Intel-gfx] [PATCH 14/15] drm/i915: vlv: add runtime PM support

Add runtime PM support for VLV, but leave it disabled. The next patch enables it. The suspend/resume sequence used is based on [1] and [2]. In practice we depend on the GT RC6 mechanism to save the HW context depending on the render and media power wells. By the time we run the runtime suspend cal

[Intel-gfx] [PATCH 10/15] drm/i915: disable runtime PM until delayed RPS/RC6 enabling completes

At least on some platforms we depend on RC6 being enabled for RPM, so disable RPM until the delayed RC6 enabling completes. For simplicity don't differentiate between platforms, those that don't have this dependency will enable RC6 only rarely during driver init and system resume. Signed-off-by: I

[Intel-gfx] [PATCH 11/15] drm/i915: vlv: disable RPM if RC6 is not enabled

On VLV we depend on RC6 saving the GT render and media HW context before going to D3 state, so disable RPM if RC6 is not enabled. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_pm.c | 29 - 2 files changed, 30 insert

[Intel-gfx] [PATCH 04/15] drm/i915: fix rc6 status debug print

The parsing was incorrect for ILK and VLV. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_pm.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index a0527a1..869a4e3 100644 --- a/drivers/gpu/drm

[Intel-gfx] [PATCH 09/15] drm/i915: vlv: factor out vlv_force_gfx_clock

This will be needed by the VLV RPM helpers too. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_drv.c | 32 drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 16 ++-- 3 files changed, 35 insertions(+), 14 deletions(-) d

[Intel-gfx] [PATCH 02/15] drm/i915: vlv: clear master interrupt flag when disabling interrupts

Not clearing this flag causes spurious interrupts at least in D3 state, so before enabling RPM we need to fix this. We were already setting this flag when enabling interrupts, only clearing it was missing. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_irq.c | 2 ++ 1 file changed, 2 ins

[Intel-gfx] [PATCH 05/15] drm/i915: take init power domain for sysfs/debugfs entries where needed

For simplicity take the init power domain, which puts the device into D0 and turns on all display power wells. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 17 +++-- drivers/gpu/drm/i915/i915_sysfs.c | 4 2 files changed, 19 insertions(+), 2 deletions(-)

[Intel-gfx] [PATCH 00/15] vlv: add support for RPM

This adds the required helpers for saving/restoring HW context when going to D3 (and possibly to S0ix afterwards) state on VLV and then enables RPM. Since we depend on the RC6 power context mechanism to save some state this also touches generic RPM parts, so that RPM is only enabled after the dela

[Intel-gfx] [PATCH 01/15] drm/i915: vlv: clean up GTLC wake control/status register macros

These will be needed by the upcoming VLV RPM helpers. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_gem.c | 5 +++-- drivers/gpu/drm/i915/i915_reg.h | 10 -- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i

Re: [Intel-gfx] [PATCH 08/24] drm/i915: Shuffle wait_for_vblank out of primary_enable/disable funcs

On Mon, Apr 07, 2014 at 05:27:41PM -0300, Paulo Zanoni wrote: > 2014-03-07 13:32 GMT-03:00 : > > From: Ville Syrjälä > > > > Rather than have a wait_for_vblank() in the primary plane enable/disable > > funcs, move the wait_for_vblank() to happen after enabling/disabling all > > planes. > > Why e

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: New drm crtc property for varying the size of borders

On Mon, Apr 07, 2014 at 04:06:34AM +, Goel, Akash wrote: > Hi Ville, > > Please could you review this patch. You need a pass of checkpatch.pl in here. Not sure what happened with the coding style. -- Damien ___ Intel-gfx mailing list Intel-gfx@lis

Re: [Intel-gfx] [PATCH 09/24] drm/i915: Keep vblank interrupts enabled while enabling/disabling planes

On Mon, Apr 07, 2014 at 06:21:08PM -0300, Paulo Zanoni wrote: > 2014-03-07 13:32 GMT-03:00 : > > From: Ville Syrjälä > > > > We may have use for vblank interrupts during plane enabling/disabling, so > > don't call drm_vblank_off() until planes are off, and call > > drm_vblank_on() just before we

[Intel-gfx] [PATCH 3/5] drm/i915: Displayport - Add function to enable/disable scrambling on the main link

Adds a function to enable and disable scrambling directly for the main link. This is functionality required to establish more fine-grained control over the Displayport interface, both for operational reliability and compliance testing. Signed-off-by: Todd Previte --- drivers/gpu/drm/i915/intel_d

[Intel-gfx] [PATCH 4/5] drm/i915: Displayport - Add function for executing a single iteration of clock recovery

Adds a function to execute a single iteration of the clock recovery sequence for Displayport. This is functionality required to establish more fine-grained control over the Displayport interface, both for operational reliability and compliance testing. Signed-off-by: Todd Previte --- drivers/gpu

[Intel-gfx] [PATCH 5/5] drm/i915: Displayport - Add function to execute a single iteration of channel equalization

Adds a function to execute a single iteration of the channel equalization sequence for Displayport. This is functionality required to establish more fine-grained control over the Displayport interface, both for operational reliability and compliance testing. Signed-off-by: Todd Previte --- drive

[Intel-gfx] [PATCH 2/5] drm/i915: Displayport - Add function to check link status

Adds a function to check the link status across all lanes for Displayport. This is functionality required to establish more fine-grained control over the Displayport interface, both for operational reliability and compliance testing. Signed-off-by: Todd Previte --- drivers/gpu/drm/i915/intel_dp.

[Intel-gfx] [PATCH 0/5] RFC: Displayport Link Policy Maker Update

This patch set lays the initial groundwork for updating the Displayport link policy maker in the i915 driver. These first 5 patches add modular functions that have been split out from the larger, monolithic ones present in the driver. The purpose of this work is the following: 1) Improve

[Intel-gfx] [PATCH 1/5] dmr/i915: Displayport - Add a function to set the training pattern

Adds a function to set the training pattern for Displayport. This is functionality required to establish more fine-grained control over the Displayport interface, both for operational reliability and compliance testing. Signed-off-by: Todd Previte --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ dri

[Intel-gfx] [PATCH 15/15] drm/i915: vlv: enable RPM

Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index d94e10a..84d4298 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_dr

[Intel-gfx] [PATCH 13/15] drm/i915: vlv: add gunit s0ix save/restore helpers

Needed by the next patch adding RPM suspend/resume support to VLV. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_drv.c | 192 drivers/gpu/drm/i915/i915_drv.h | 62 + 2 files changed, 254 insertions(+) diff --git a/drivers/gpu/drm/i9

[Intel-gfx] [PATCH 06/15] drm/i915: get init power domain for gpu error state capture

Since the state capture happens from a deferred work, we may drop the last power domain/RPM reference since the error got triggered (from an interrupt handler for example). I hit this by writing to the i915_wedged debugfs file. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_irq.c | 4 +++

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: New drm crtc property for varying the size of borders

On Tue, Apr 08, 2014 at 05:31:06PM +0100, Damien Lespiau wrote: > On Mon, Apr 07, 2014 at 04:06:34AM +, Goel, Akash wrote: > > Hi Ville, > > > > Please could you review this patch. > > You need a pass of checkpatch.pl in here. Not sure what happened with > the coding style. Ignore this, I wa

[Intel-gfx] [PATCH 08/15] drm/i915: vlv: setup RPS min/max frequencies once during init time

When enabling RPM on VLV, GT power save enabling becomes relatively frequent, so optimize it a bit. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_pm.c | 66 + 1 file changed, 41 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/i915/in

[Intel-gfx] [PATCH 07/15] drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on

Some platforms need additional power domains to be on in addition to the device D0 state to access the panel registers. Suggested by Daniel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987 Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_dp.c | 6 +- 1 file changed, 5 in

[Intel-gfx] [PATCH 03/15] drm/i915: vlv: add RC6 residency counters

Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 5 + drivers/gpu/drm/i915/i915_reg.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 1e83ae4..02f1b39 100644 --- a/drivers/gpu/drm/i9

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: New drm crtc property for varying the size of borders

On Wed, Mar 26, 2014 at 09:25:12AM +0530, akash.g...@intel.com wrote: > From: Akash Goel > > This patch adds a new drm crtc property for varying the size of > the horizontal & vertical borers of the output/display window. > This will control the output of Panel fitter. > > v2: Added a new check

Re: [Intel-gfx] Fujitsu S6010 still woes (partially)

On Tue, Apr 8, 2014 at 2:05 PM, Thomas Richter wrote: > Am 08.04.2014 13:52, schrieb Daniel Vetter: >> >> On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter >> >> Hm, my X30 also locks up here on resume. What hack do you apply to >> make the ns2501 driver get through resume? I don't care about black

Re: [Intel-gfx] [PATCH 4/6] drm/i915: add flag to prevent dmesg spam on context banning

Rodrigo Vivi writes: > From: Mika Kuoppala > > Piglit runner and QA are both looking at the dmesg for > DRM_ERRORs with test cases. > > Add flag to stop_rings debugfs interface to prevent DRM_ERROR > output when default context banning is being tested. > > References: https://bugs.freedesktop.or

Re: [Intel-gfx] Fujitsu S6010 still woes (partially)

On Tue, Apr 08, 2014 at 02:17:10PM +0200, Thomas Richter wrote: > Am 08.04.2014 13:37, schrieb Ville Syrjälä: > > On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote: > > > > I saw the watermark issue on my S6010 too. I have no good explanation > > for it since low value in the register

Re: [Intel-gfx] [PATCH] drm/i915: support address only i2c-over-aux transactions

Am 08.04.2014 15:04, schrieb Alex Deucher: On Tue, Apr 8, 2014 at 4:03 AM, Daniel Vetter wrote: On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula wrote: Before the conversion to dp aux helpers there was a switch case [1] that ended up in msg_bytes = 3 for address only start/stop messages (MODE_I2C_

Re: [Intel-gfx] [PATCH] drm/i915: support address only i2c-over-aux transactions

On Tue, Apr 8, 2014 at 9:09 AM, Christian König wrote: > Am 08.04.2014 15:04, schrieb Alex Deucher: > >> On Tue, Apr 8, 2014 at 4:03 AM, Daniel Vetter wrote: >>> >>> On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula >>> wrote: Before the conversion to dp aux helpers there was a switch case [

Re: [Intel-gfx] [PATCH] drm/i915: support address only i2c-over-aux transactions

On Tue, Apr 8, 2014 at 4:03 AM, Daniel Vetter wrote: > On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula wrote: >> Before the conversion to dp aux helpers there was a switch case [1] that >> ended up in msg_bytes = 3 for address only start/stop messages >> (MODE_I2C_START or MODE_I2C_STOP bit set [2]).

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Bring UP Power Wells before disabling RC6.

On 4/8/2014 6:13 PM, Ville Syrjälä wrote: On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote: On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote: From: Deepak S We need do forcewake before Disabling RC6, This is what the BIOS expects while going into suspend. v2: update

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Bring UP Power Wells before disabling RC6.

On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote: > On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote: > > From: Deepak S > > > > We need do forcewake before Disabling RC6, This is what the BIOS > > expects while going into suspend. > > > > v2: updated commit message. (Dan

Re: [Intel-gfx] Fujitsu S6010 still woes (partially)

Am 08.04.2014 13:37, schrieb Ville Syrjälä: On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote: I saw the watermark issue on my S6010 too. I have no good explanation for it since low value in the register means the watermark is actually high. I know )-: So it's a mystery why

Re: [Intel-gfx] [PATCH] drm/i915: Remove misleading debug message

On Tue, 08 Apr 2014, Damien Lespiau wrote: > haswell_write_eld() is also used on broadwell, so let's not explicitely > mention Haswell. The rest of the function has plenty of debug output > which will print the function name, so we know where we are anyway. > > Signed-off-by: Damien Lespiau Revi

Re: [Intel-gfx] Fujitsu S6010 still woes (partially)

Am 08.04.2014 13:52, schrieb Daniel Vetter: On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter Hm, my X30 also locks up here on resume. What hack do you apply to make the ns2501 driver get through resume? I don't care about black screen, but I just wonder whether my X30 has the same issue - atm it

Re: [Intel-gfx] Fujitsu S6010 still woes (partially)

On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter wrote: > 3) Suspend to RAM: Whether with or without the quirk, s2ram is > non-functioning, but *almost* functioning. The problem on the S6010 is > again the ns2501. Unfortunately, I do not know which of the intel > functions are called on resume in w

Re: [Intel-gfx] Fujitsu S6010 still woes (partially)

On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote: > Hi Daniel, dear intel-experts, > > again I had the chance to test the latest intel-drm-nightly of the > 3.14.0 kernel on the Siemens S6010 with its dreadful nso2501 DVO. > Unfortunately, there are still a couple of issues here, and

[Intel-gfx] [PATCH] drm/i915: Remove misleading debug message

haswell_write_eld() is also used on broadwell, so let's not explicitely mention Haswell. The rest of the function has plenty of debug output which will print the function name, so we know where we are anyway. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_display.c | 3 --- 1 file

Re: [Intel-gfx] [PATCH] drm/i915: Rename GEN8_PIPE_FLIP_DONE to PRIMARY_FLIP_DONE

On Tue, Apr 08, 2014 at 01:22:44AM +0100, Damien Lespiau wrote: > It is now clear that this interrupt is for the primary plane and not > something global to the pipe. It also matches what the spec calls it. > > Signed-off-by: Damien Lespiau Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i

[Intel-gfx] Fujitsu S6010 still woes (partially)

Hi Daniel, dear intel-experts, again I had the chance to test the latest intel-drm-nightly of the 3.14.0 kernel on the Siemens S6010 with its dreadful nso2501 DVO. Unfortunately, there are still a couple of issues here, and I also want to report on some progress and some workarounds. 1) Panning

Re: [Intel-gfx] [PATCH] drm/i915: support address only i2c-over-aux transactions

On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula wrote: > Before the conversion to dp aux helpers there was a switch case [1] that > ended up in msg_bytes = 3 for address only start/stop messages > (MODE_I2C_START or MODE_I2C_STOP bit set [2]). With Alex's series in, > but without my patch, we'd send t

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

On Tue, Apr 8, 2014 at 9:32 AM, Daniel J Blueman wrote: > I am using a dual-link DVI-D to DVI-D cable to this monitor, since I > previously couldn't get 2560x1440 via HDMI. > > If it isn't this commit, then it may be another commit in 3.13.7, > albeit it feels less likely. Before we go on a wild

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

On 8 April 2014 15:14, Jani Nikula wrote: > On Tue, 08 Apr 2014, Daniel J Blueman wrote: >> Ville et al, >> >> It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or >> another commit in 3.13.7) broke modes which require DVI-D dual-link, >> eg 2560x1440 with my panel. >> >> I don't see

Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

On Tue, 08 Apr 2014, Daniel J Blueman wrote: > Ville et al, > > It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or > another commit in 3.13.7) broke modes which require DVI-D dual-link, > eg 2560x1440 with my panel. > > I don't see these modelines in 3.13.7 or later (eg 3.14): > > [

Re: [Intel-gfx] [PATCH 3/3] drm/i915/bdw: Use the GEN8 SRM when qeueing a flip

On Tue, Apr 08, 2014 at 07:24:23AM +0100, Chris Wilson wrote: > On Mon, Apr 07, 2014 at 11:20:14PM +0100, Damien Lespiau wrote: > > On Mon, Apr 07, 2014 at 01:59:17PM -0700, Ben Widawsky wrote: > > > Cool. This explains the bad DERRMR values I was seeing in in error > > > states. I'm honestly didn'