[Intel-gfx] [PATCH] drm/i915: Add #defines for short/long pulse on gmch platforms

2014-06-05 Thread Daniel Vetter
For no reason at all the public docs lack them, and Dave needs them for his hpd interrupt rework. Cc: Dave Airlie Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_reg.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i91

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

2014-06-05 Thread Vandana Kannan
Added a property to enable user space to set aspect ratio. This patch contains declaration of the property and code to create the property. v2: Thierry's review comments. - Made aspect ratio enum generic instead of HDMI/CEA specfic - Removed usage of temporary aspect_ratio variable

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

2014-06-05 Thread Vandana Kannan
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. v2: Thierry's review comments. - Modified the comment "Populate..." as per review comments v3: Thierry's review comments.

Re: [Intel-gfx] [PATCH] [I-G-T]Add rc6_residency_counter subtest

2014-06-05 Thread Daniel Vetter
On Thu, Jun 05, 2014 at 10:27:42AM +0800, Wendy Wang wrote: > Move rc6_residency_check to subtest, add new rc6_residency_counter subtest > for pm_rc6_residency IGT case. I don't really understand what you're trying to do here really. Please explain better in the commit message not just what the pa

[Intel-gfx] [PATCH] drm: Fix getconnector connection_mutex locking

2014-06-05 Thread Daniel Vetter
I've fumbled my own idea and enthusiastically wrapped all the getconnector code with the connection_mutex. But we only need it to chase the connector->encoder link. Even there it's not really needed since races with userspace won't matter, but better paranoid and consistent about this stuff. If we

Re: [Intel-gfx] [PATCH] drm/i915: Replace remaining drm_get_connector_name(c) by c->name.

2014-06-05 Thread Daniel Vetter
On Wed, Jun 04, 2014 at 04:55:20PM -0300, Paulo Zanoni wrote: > 2014-06-04 15:47 GMT-03:00 Rodrigo Vivi : > > Signed-off-by: Rodrigo Vivi > > Yeah, this seems to make -nightly compile. > > Reviewed-by: Paulo Zanoni Sorry my script for fixing up the -nightly build failed. I've spotted this but

Re: [Intel-gfx] [PATCH] drm/i915: Update PSR on resume.

2014-06-05 Thread Daniel Vetter
On Wed, Jun 04, 2014 at 12:17:14PM -0700, Rodrigo Vivi wrote: > On Wed, May 28, 2014 at 5:57 AM, Daniel Vetter wrote: > > > On Tue, May 27, 2014 at 04:50:14PM -0700, Rodrigo Vivi wrote: > > > Some registers set during setup might not be persistent after > > suspend/resume. > > > This was causing

Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4

2014-06-05 Thread Daniel Vetter
On Wed, Jun 04, 2014 at 01:45:22PM -0700, Jesse Barnes wrote: > This allows the system to enter the lowest power mode during system freeze. > > v2: delete force wake timer at suspend (Imre) > v3: add GT work suspend function (Imre) > v4: use uncore forcewake reset (Daniel) > > Signed-off-by: Kris

Re: [Intel-gfx] [PATCH] drm/i915: revert intel_dp_probe_oui call during HPD interrupt handler

2014-06-05 Thread Daniel Vetter
On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Remove OUI read function from the lower half interrupt handler. Upon > closing the eDP panel lid an HPD interrupt is generated. The lower half > handler calls intel_dp_probe_oui() as part of intel

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

2014-06-05 Thread Thierry Reding
On Thu, Jun 05, 2014 at 02:45:29PM +0530, Vandana Kannan wrote: > 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. > > v2: Thierry's review comments. > - Modified the comm

Re: [Intel-gfx] [PATCH] drm/i915: BDW: Adding missing cursor offsets.

2014-06-05 Thread Daniel Vetter
On Wed, Jun 04, 2014 at 05:16:25PM -0700, Ben Widawsky wrote: > On Wed, Jun 04, 2014 at 05:09:30PM -0700, Rodrigo Vivi wrote: > > BDW uses IVB cursor offsets. > > > > Whithout this patch it is not possible to use multiple outputs with cursor > > on BDW. > > The cursor gets completely crazy because

Re: [Intel-gfx] [PATCH] drm/i915: Replace remaining drm_get_connector_name(c) by c->name.

2014-06-05 Thread Daniel Vetter
On Thu, Jun 05, 2014 at 11:13:58AM +0200, Daniel Vetter wrote: > On Wed, Jun 04, 2014 at 04:55:20PM -0300, Paulo Zanoni wrote: > > 2014-06-04 15:47 GMT-03:00 Rodrigo Vivi : > > > Signed-off-by: Rodrigo Vivi > > > > Yeah, this seems to make -nightly compile. > > > > Reviewed-by: Paulo Zanoni >

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

2014-06-05 Thread Thierry Reding
On Thu, Jun 05, 2014 at 02:40:08PM +0530, Vandana Kannan wrote: [...] > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c [...] > /** > + * drm_mode_create_aspect_ratio_property - create aspect ratio property > + * @dev: DRM device > + * > + * Called by a driver the first time i

[Intel-gfx] [PATCH] drm/i915: Reorder semaphore deadlock check

2014-06-05 Thread Chris Wilson
If a semaphore is waiting on another ring, which in turn happens to be waiting on the first ring, but that second semaphore has been signalled, we will be able to kick the second ring and so can treat the first ring as a valid WAIT and not as HUNG. References: https://bugs.freedesktop.org/show_bug

[Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP

2014-06-05 Thread Shobhit Kumar
The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detection failures for eDP. Reduce the number of bits of interest in DEVICE_TYPE_eDP_BITS to just check most relevant and conclusive ones and ensure they are set in device_class from VBT. This will ensure that eDP

Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP

2014-06-05 Thread Ville Syrjälä
On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: > The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which > can causes wrong detection failures for eDP. Reduce the number of bits > of interest in DEVICE_TYPE_eDP_BITS to just check most relevant and > conclusive ones and e

[Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

2014-06-05 Thread Hans de Goede
We've several reports from users where the backlight comes up turned off on starting X, when using video.use_native_backlight=1 (true dmi quirks, will be the default for 3.16), in combination with having an external display plugged in: https://bugzilla.redhat.com/show_bug.cgi?id=1032978 https://bu

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

2014-06-05 Thread Jani Nikula
On Thu, 05 Jun 2014, Hans de Goede wrote: > We've several reports from users where the backlight comes up turned off > on starting X, when using video.use_native_backlight=1 (true dmi quirks, will > be the default for 3.16), in combination with having an external display > plugged in: > > https://

Re: [Intel-gfx] [PATCH] drm: Fix getconnector connection_mutex locking

2014-06-05 Thread Rob Clark
On Thu, Jun 5, 2014 at 5:12 AM, Daniel Vetter wrote: > I've fumbled my own idea and enthusiastically wrapped all the > getconnector code with the connection_mutex. But we only need it to > chase the connector->encoder link. Even there it's not really needed > since races with userspace won't matte

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

2014-06-05 Thread Chris Wilson
On Thu, Jun 05, 2014 at 05:01:23PM +0300, Jani Nikula wrote: > On Thu, 05 Jun 2014, Hans de Goede wrote: > > We've several reports from users where the backlight comes up turned off > > on starting X, when using video.use_native_backlight=1 (true dmi quirks, > > will > > be the default for 3.16),

[Intel-gfx] [PATCH 4/5] drm/i915: Fixup global gtt cleanup

2014-06-05 Thread Daniel Vetter
The global gtt is setup up in 2 parts, so we need to be careful with the cleanup. For consistency shovel it all into the ->cleanup callback, like with ppgtt. Noticed because it blew up in the out_gtt: cleanup code while fiddling with the vgacon code. Signed-off-by: Daniel Vetter --- drivers/gpu

[Intel-gfx] [PATCH 3/5] vt: Don't ignore unbind errors in vt_unbind

2014-06-05 Thread Daniel Vetter
Otherwise the loop will never stop since we don't make any forward progress. Noticed while breaking this accidentally in a painful attempt to make vga_con unregistering work. With this patch we'll bail out on the first attempt, which at least leaves a useful enough system behind for debugging. Liv

[Intel-gfx] [PATCH 1/5] vt: Fix replacement console check when unbinding

2014-06-05 Thread Daniel Vetter
I don't fully understand the magic of the vt register/unregister logic, but apparently everything but the inital console (as set in the conswitchp pointer) is marked with FLAG_MODULE. Which means if something unregistered the boot vt driver (e.g. i915.ko kicking out vga_con) there's nothing left wh

[Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console

2014-06-05 Thread Daniel Vetter
Touching the VGA resources on an IVB EFI machine causes hard hangs when we then kick out the efifb. Ouch. Apparently this also prevents unclaimed register errors on hsw and hard machine hangs on my i855gm when trying to unbind fbcon. Also, we want this to make I915_FBDEV=n safe. v2: Rebase and p

[Intel-gfx] [PATCH 2/5] vt: Fix up unregistration of vt drivers

2014-06-05 Thread Daniel Vetter
A bunch of issues: - We should not kick out the default console (which is tracked in conswitchp), so check for that. - Add better error codes so callers can differentiate between "something went wrong" and "your driver isn't registered already". i915 needs that so it doesn't fall over when re

[Intel-gfx] [PATCH] drm/i915: Make the physical object coherent with GTT

2014-06-05 Thread Chris Wilson
Currently objects for which the hardware needs a contiguous physical address are allocated a shadow backing storage to satisfy the contraint. This shadow buffer is not wired into the normal obj->pages and so the physical object is incoherent with accesses via the GPU, GTT and CPU. By setting up the

[Intel-gfx] [PATCH] resume timings

2014-06-05 Thread Jesse Barnes
--- drivers/gpu/drm/i915/i915_drv.c | 6 ++ drivers/gpu/drm/i915/intel_display.c | 9 + 2 files changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 0f9e836..a2036b2 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drive

Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4

2014-06-05 Thread Jesse Barnes
On Thu, 5 Jun 2014 11:21:02 +0200 Daniel Vetter wrote: > On Wed, Jun 04, 2014 at 01:45:22PM -0700, Jesse Barnes wrote: > > This allows the system to enter the lowest power mode during system freeze. > > > > v2: delete force wake timer at suspend (Imre) > > v3: add GT work suspend function (Imre)

Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP

2014-06-05 Thread Jesse Barnes
On Thu, 5 Jun 2014 16:09:29 +0300 Ville Syrjälä wrote: > On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: > > The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which > > can causes wrong detection failures for eDP. Reduce the number of bits > > of interest in DEVICE_TYPE

[Intel-gfx] New async patch for resume

2014-06-05 Thread Jesse Barnes
In digging into the async crtc stuff, I found it was going to be really difficult to prevent other functions from getting clobbered by a delayed crtc enable or disable. Daniel's work to remove a bunch of the ->mode_set callbacks is a good start, but we still end up doing some reg reads and writes

[Intel-gfx] [PATCH 00/15] drm/i915: Fix 830M/ns2501 for real, well almost

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Since the 830M dragon popped up again, I figured I'd dig out my old patches that try to fix it. I ended up reworking the primary plane code a bit also to eliminate the DSPCNTR/DSPADDR RMW accesses since those are dangerous on 830M. But I think the end result is more in line w

[Intel-gfx] [PATCH 01/15] drm/i915: Use named initializers for gmch wm params

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Using names initializers when filling out the watermark structs saves you from having go look up the struct definition every single time. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 130 1 file changed, 65 inse

[Intel-gfx] [PATCH 06/15] drm/i915: Don't call DVO mode_set hook on DPMS changes

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Calling the mode_set hook on DPMS changes doesn't seem to be necessary for ns2501. Just drop it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dvo.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 03/15] drm/i915: Don't get hw state from DVO chip unless DVO is enabled

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Certain DVO chips (ns2501 for example) don't like to be accessed unless the PLL is running. Simply skip the DVO get_hw_state if the DVO port is disabled. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dvo.c | 8 1 file changed, 8 insertions(+) diff --

[Intel-gfx] [PATCH 02/15] drm/i915: Fix gen2 planes B and C max watermark value

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä The max watermark value for gen2 planes B and C is 0x1f, instead of the 0x3f that plane A uses. Also check against the max even if the pipe is disabled since the FIFO size exceeds the plane B and C max watermark value. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 09/15] drm/i915: Ignore VBT int_crt_support on 830M

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä My Fujitsu-Siemens Lifebook S6010 definitely has a VGA connector, but the VBT says different. Ignore the VBT for 830M since it seems such old machines would generally have a VGA connector. This is a regression caused by: commit 9c2a03c2a194c086949f25d332937ac8dc4d9f7e Autho

[Intel-gfx] [PATCH 11/15] Revert "drm/i915: Nuke pipe A quirk on i830M"

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä This reverts commit ac6696d3236bd61503f89a1a99680fd7894d5d53. --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index af944be..3b6eccd 100644 --- a/drive

[Intel-gfx] [PATCH 12/15] drm/i915: Add pipe B force quirk for 830M

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä 830M has problems when some of the pipes are disabled. Namely if a plane, DVO port etc. is currently assigned to a disabled pipe, it can't moved to the other pipe until the current pipe is also enabled. To keep things simple just leave both pipes running all the time. Ideally

[Intel-gfx] [PATCH 05/15] drm/i915: Enable DVO between mode_set and dpms hooks

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä To more closely match the IEGD ns2501 driver behaviour, call the mode_set hook while the DVO port is still disabled, then enable the DVO port, and finally call the dpms hook. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dvo.c | 5 +++-- 1 file changed, 3 inse

[Intel-gfx] [PATCH 07/15] drm/i915: Kill useless ns2501_dump_regs

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/dvo_ns2501.c | 17 - 1 file changed, 17 deletions(-) diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c b/drivers/gpu/drm/i915/dvo_ns2501.c index 74f2af7..85030d4 100644 --- a/drivers/gpu/drm/i915/dvo_ns2501

[Intel-gfx] [PATCH 08/15] drm/i915: Rewrite ns2501 driver a bit

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Try to use the same programming sequence as used by the IEGD driver. Also shovel the magic register values into a big static const array. The register values are actually the based on what the BIOS programs on the Fujitsu-Siemens Lifebook S6010. IEGD seemed to have hardcoded

[Intel-gfx] [PATCH 13/15] drm/i915: Eliminate rmw from .update_primary_plane()

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Move the entire DSPCNTR register setup into the .update_primary_plane() functions. That's where it belongs anyway and it'll also help 830M which has the extra problem that plane registers reads will return the value latched at the last vblank, not the value that was last writt

[Intel-gfx] [PATCH 14/15] drm/i915: Call .update_primary_plane in intel_{enable, disable}_primary_hw_plane()

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä Make the intel_{enable,disable}_primary_hw_plane() simply call .update_primary_plane(), thus eliminating the rmw from these functions which should help the poor old 830M. Now we can also remove the .update_primary_plane() from the .crtc_enable() hooks. This also has the nice

[Intel-gfx] [PATCH 15/15] drm/i915: Check pixel clock in ns2501 mode_valid hook

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä The vbt on my Fujitsu-Siemens Lifebook S6010 provides two 800x600 modes, 60Hz and 56Hz. The magic register values we have correspond to the 60Hz mode, and as I don't know how one would trick the VGA BIOS to set up the 56Hz mode we can't get the magic values for the orther mode

[Intel-gfx] [PATCH 10/15] drm/i915: Fix DVO 2x clock enable on 830M

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä The spec says: "For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata, GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31 (DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in both the DPLL A Control Register (06014h-06017h) and DPLL B Co

[Intel-gfx] [PATCH 04/15] drm/i915: ns2501 is on DVOB

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead of DVOC. FIXME: Maybe need to dig out the correct DVO port from VBT Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dvo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

2014-06-05 Thread Jesse Barnes
On Wed, 4 Jun 2014 08:04:53 -0700 Stéphane Marchesin wrote: > > We could have dpms standby mean backlight off, everything else on, > > similarly to what you want by 0 backlight meaning off. So you could > > switch between dpms on/standby more quickly. The point in that is that > > it's the right

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

2014-06-05 Thread Matthew Garrett
On Wed, 2014-06-04 at 08:04 -0700, Stéphane Marchesin wrote: > Well, for example ACPI backlight isn't the default on intel, instead > i915 implements its own backlight. ACPI backlight doesn't support as > many backlight levels as the native backlight for example. So I do > think that ACPI backligh

[Intel-gfx] [PATCH v2 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory

2014-06-05 Thread ville . syrjala
From: Ville Syrjälä On most gen2-4 platforms the GTT can be (or maybe always is?) inside the stolen memory region. If that's the case, reduce the size of the stolen memory appropriately to make make sure we don't clobber the GTT. v2: Deal with gen4 36 bit physical address Signed-off-by: Ville S

Re: [Intel-gfx] [PATCH] [I-G-T]Add rc6_residency_counter subtest

2014-06-05 Thread Ben Widawsky
On Thu, Jun 05, 2014 at 10:27:42AM +0800, Wendy Wang wrote: > Move rc6_residency_check to subtest, add new rc6_residency_counter subtest > for pm_rc6_residency IGT case. > Looks good to me. You have some formatting issues: for loops don't use the right coding style useless comment to fopen bad

[Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state

2014-06-05 Thread Imre Deak
Jesse noticed that the punit communication needed to query the VLV power well status can cause substantial delays. Since we can query the state frequently, for example during I2C transfers, maintain a cached version of the HW state to get rid of this delay. This fixes at least one reported regress

Re: [Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state

2014-06-05 Thread Jesse Barnes
On Thu, 5 Jun 2014 20:31:47 +0300 Imre Deak wrote: > Jesse noticed that the punit communication needed to query the VLV power > well status can cause substantial delays. Since we can query the state > frequently, for example during I2C transfers, maintain a cached version > of the HW state to ge

Re: [Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state

2014-06-05 Thread Imre Deak
On Thu, 2014-06-05 at 10:35 -0700, Jesse Barnes wrote: > On Thu, 5 Jun 2014 20:31:47 +0300 > Imre Deak wrote: > > > Jesse noticed that the punit communication needed to query the VLV power > > well status can cause substantial delays. Since we can query the state > > frequently, for example duri

[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

2014-06-05 Thread Jesse Barnes
Let them eat mincemeat pie. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index d05a2af..081ab2f 100644 --- a/drivers/gpu/drm/i915

[Intel-gfx] [PATCH 1/5] drm/i915: preserve SSC if previously set v2

2014-06-05 Thread Jesse Barnes
Some machines may have a broken VBT or no VBT at all, but we still want to use SSC there. So check for it and keep it enabled if we see it already on. Based on an earlier fix from Kristian. v2: honor modparam if set too (Daniel) read out at init time and store for panel_use_ssc() use (Jesse)

[Intel-gfx] [PATCH 4/5] drm/i915: use current mode if the size matches the preferred mode

2014-06-05 Thread Jesse Barnes
From: Kristian Høgsberg The BIOS may set a native mode that doesn't quite match the preferred mode timings. It should be ok to use however if it uses the same size, so try to avoid a mode set in that case. Signed-off-by: Kristian Høgsberg Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 3/5] drm: add drm_mode_same_size function

2014-06-05 Thread Jesse Barnes
From: Kristian Høgsberg Like mode_equal but w/o the clock checks. Useful for checking if modes are close enough to re-use to avoid a boot time mode set for example. Signed-off-by: Kristian Høgsberg Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_modes.c | 8 include/drm/drm_mode

[Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

2014-06-05 Thread Jesse Barnes
Some machines (like MBAs) might use a tiled framebuffer but not enable display swizzling at boot time. We want to preserve that configuration if possible to prevent a boot time mode set. On IVB+ it shouldn't affect performance anyway since the memory controller does internal swizzling anyway. Fo

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

2014-06-05 Thread Hans de Goede
Hi, On 06/05/2014 04:29 PM, Chris Wilson wrote: > On Thu, Jun 05, 2014 at 05:01:23PM +0300, Jani Nikula wrote: >> On Thu, 05 Jun 2014, Hans de Goede wrote: >>> We've several reports from users where the backlight comes up turned off >>> on starting X, when using video.use_native_backlight=1 (true

Re: [Intel-gfx] [PATCH] [I-G-T]Add rc6_residency_counter subtest

2014-06-05 Thread Daniel Vetter
On Thu, Jun 5, 2014 at 7:19 PM, Ben Widawsky wrote: > On Thu, Jun 05, 2014 at 10:27:42AM +0800, Wendy Wang wrote: >> Move rc6_residency_check to subtest, add new rc6_residency_counter subtest >> for pm_rc6_residency IGT case. >> > > Looks good to me. You have some formatting issues: > for loops d

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

2014-06-05 Thread Chris Wilson
On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote: > Note that it is read after the framebuffer has been resized and a new mode > has been set on "pipe 0 using LVDS1", could this perhaps cause the 0 to be > read when using actual_brightness ? Indeed, that is likely the explanation, and

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Use named initializers for gmch wm params

2014-06-05 Thread Chris Wilson
On Thu, Jun 05, 2014 at 07:15:50PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Using names initializers when filling out the watermark structs > saves you from having go look up the struct definition every > single time. > > Signed-off-by: Ville Syrjälä Thank you, Rev

[Intel-gfx] [PATCH] drm/i915/vlv: drop punit freq staus read after setting idle

2014-06-05 Thread Jesse Barnes
This may take awhile (~10ms), and we don't need to make noise about it. References: https://bugs.freedesktop.org/show_bug.cgi?id=75244 Tested-by: huax...@intel.com Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/d

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Use named initializers for gmch wm params

2014-06-05 Thread Thomas Richter
Am 05.06.2014 22:43, schrieb Chris Wilson: On Thu, Jun 05, 2014 at 07:15:50PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Using names initializers when filling out the watermark structs saves you from having go look up the struct definition every single time. Signed-off-by:

[Intel-gfx] [PATCH] drm/i915: Fix VLV CRC reading.

2014-06-05 Thread Rodrigo Vivi
Adding missing Display mmio reg offset. Credits-to: Laws, Philip Cc: He, Shuang Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 286f05c..0

[Intel-gfx] Bug reports on 830MG patches (thanks, but more trouble)

2014-06-05 Thread Thomas Richter
Update on the 830MG Updates: As Ville already said, resume from "suspend-to-ram" is broken. No surprise, old broken bios. However, there is a big difference between the kernel with the pipe-A quirk disabled, and the one with pipe-a and pipe-b quirks enabled: If resumed without the quirk, the d

Re: [Intel-gfx] [PATCH 13/15] drm/i915: Eliminate rmw from .update_primary_plane()

2014-06-05 Thread Matt Roper
On Thu, Jun 05, 2014 at 07:16:02PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the entire DSPCNTR register setup into the .update_primary_plane() > functions. That's where it belongs anyway and it'll also help 830M which > has the extra problem that plane registers

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Call .update_primary_plane in intel_{enable, disable}_primary_hw_plane()

2014-06-05 Thread Matt Roper
On Thu, Jun 05, 2014 at 07:16:03PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make the intel_{enable,disable}_primary_hw_plane() simply call > .update_primary_plane(), thus eliminating the rmw from these functions > which should help the poor old 830M. > > Now we can a

[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

2014-06-05 Thread Stephen Rothwell
y only contain stuff that depend on Linus' trees ... but here it include all of yesterday's drm tree as well. I have used the drm-intel-fixes tree from next-20140605 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.

Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP

2014-06-05 Thread Kumar, Shobhit
On 6/5/2014 9:34 PM, Jesse Barnes wrote: On Thu, 5 Jun 2014 16:09:29 +0300 Ville Syrjälä wrote: On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detection failures for eDP. Reduce the number of

Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP

2014-06-05 Thread Kumar, Shobhit
On 6/6/2014 9:33 AM, Kumar, Shobhit wrote: On 6/5/2014 9:34 PM, Jesse Barnes wrote: On Thu, 5 Jun 2014 16:09:29 +0300 Ville Syrjälä wrote: On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detec

[Intel-gfx] [PATCH] drm/i915: Only wait one vblank when disabling crc if the pipe is on

2014-06-05 Thread Daniel Vetter
Otherwise we incur an unsightly WARNING. The mutex locking is a bit overkill, but it curbs races and eventially we might grow a locking check in the vblank wait code to make sure the right crtc lock is held. This is fallout from commit 9393707190194eb8b42e412b444a03331db6862f Author: Jesse Ba

Re: [Intel-gfx] [PATCH] drm/i915: enable PPGTT on VLV

2014-06-05 Thread Daniel Vetter
On Mon, Jun 02, 2014 at 05:33:26PM +0200, Daniel Vetter wrote: > On Mon, Jun 02, 2014 at 02:09:06PM +0300, Ville Syrjälä wrote: > > On Thu, May 29, 2014 at 02:33:21PM -0700, Jesse Barnes wrote: > > > Working for real this time. i915_ppgtt_info has all sorts of good stuff > > > in it and X is runni

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

2014-06-05 Thread Daniel Vetter
Hi Dave, Bunch of stuff for 3.16 still: - Mipi dsi panel support for byt. Finally! From Shobhit&others. I've squeezed this in since it's a regression compared to vbios and we've been ridiculed about it a bit too often ... - connection_mutex deadlock fix in get_connector (only affects i915). -

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

2014-06-05 Thread Daniel Vetter
k 3.17 and gather patches on top of the all the work readied before the merge window. > I have used the drm-intel-fixes tree from next-20140605 for today. I think you should drop drm-intel-fixes until 3.16 is out and the merge window properly public, otherwise this mess will rep