[Intel-gfx] [PATCH] drm/i915: Update VBT data structures to have MIPI block enhancements

MIPI Block #52 which provides configuration details for the MIPI panel including dphy settings as per panel and tcon specs Block #53 gives information on panel enable sequences v2: Address review comemnts from Jani - Move panel ids from intel_dsi.h to intel_bios.h - bdb_mipi_config struct

[Intel-gfx] [PATCH] drm/i915: Fix drain latency precision multipler for VLV

>From spec the drain latency precision multipler is either 32 or 64 for VLV. Signed-off-by: Zhenyu Wang --- drivers/gpu/drm/i915/i915_reg.h | 18 +- drivers/gpu/drm/i915/intel_pm.c | 12 ++-- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm

Re: [Intel-gfx] [v2 1/2] drm/i915: Update VBT data structures to have MIPI block enhancements

On Thursday 27 February 2014 08:18 PM, Jani Nikula wrote: On Thu, 20 Feb 2014, Shobhit Kumar wrote: +/* Block 52 contains MIPI configuration block + * 6 * bdb_mipi_config, followed by 6 pps data + * block below + * + * all delays in ms The spec you sent me has "... delay in 100us unit" for MI

[Intel-gfx] [PATCH] [v2] drm/i915: Paranoia - get zeroed page table pages

We normally clear the page tables as one of the first things during initialization. They are however wired up (and potentially valid) before we clear them. To prevent the GPU from doing anything we might later regret, simply get zeroed pages, which always mean invalid on all GENs. NOTE: that a si

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add a partial instruction shootdown workaround on Broadwell.

On Thu, Feb 27, 2014 at 10:43:24AM +0200, Ville Syrjälä wrote: > On Wed, Feb 26, 2014 at 11:59:30PM -0800, Kenneth Graunke wrote: > > I believe this will be necessary on production hardware. > > > > Signed-off-by: Kenneth Graunke > > --- > > drivers/gpu/drm/i915/i915_reg.h | 3 +++ > > drivers/g

Re: [Intel-gfx] [PATCH 3/3] drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw

On Thu, Feb 27, 2014 at 09:59:03PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

Re: [Intel-gfx] Info: mapping multiple BARs. Your kernel is fine.

On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote: > I won't be able to look at that before Monday I'm afraid (personal > stuff). No worries, sir, whenever. It can wait. Thanks a lot! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- _

[Intel-gfx] [PATCH 18/23] drm/i915: remove dev_priv->pc8.enabled

From: Paulo Zanoni It was just being used on debugfs and on a WARN inside hsw_set_power_well. But now that we PC8 is part of runtime PM and we get/put runtime PM when we get/put any power domain, we shouldn't need the WARN anymore. v2: - Rebase. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm

[Intel-gfx] [PATCH 16/23] drm/i915: get/put runtime PM references for GMBUS and DP AUX

From: Paulo Zanoni We had these intel_aux_display_runtime_{get,put} abstractions that would just get/put PC8 references, but now that runtime PM and PC8 are the same stuff, we just need the runtime PM references, so just get/put runtime PM directly, because that's what the rest of our code does.

[Intel-gfx] [PATCH 23/23] drm/i915: init pm.suspended earlier

From: Paulo Zanoni Function intel_init_runtime_pm is supposed to start allowing runtime PM from that point, but it's called very late on the driver initialization code, to prevent the driver from trying to suspend while still initializing. The problem is that variables are accessed earlier than t

[Intel-gfx] [PATCH 04/23] drm/i915: kill dev_priv->pc8.gpu_idle

From: Paulo Zanoni Since the addition of dev_priv->mm.busy, there's no more need for dev_priv->pc8.gpu_idle, so kill it. Notice that when you remove gpu_idle, hsw_package_c8_gpu_idle and hsw_package_c8_gpu_busy become identical to hsw_enable_package_c8 and hsw_disable_package_c8, so just use the

[Intel-gfx] [PATCH 19/23] drm/i915: move pc8.irqs_disabled to pm.irqs_disabled

From: Paulo Zanoni When other platforms add runtime PM support they will also need to disable interrupts, so move the variable to the runtime PM struct. v2: - Rebase. v3: - Rebase. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 15/23] drm/i915: don't get/put PC8 reference on freeze/thaw

From: Paulo Zanoni We already get runtime PM references, and PC8 is now part of runtime PM, so this is enough. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv

[Intel-gfx] [PATCH 21/23] drm/i915: rename __hsw_do_{en, dis}able_pc8

From: Paulo Zanoni After we removed all the intermediate abstractions, we can rename these functions to just hsw_{en,dis}able_pc8. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/intel_display.c | 4 ++-- drivers/gpu/drm/i915/intel_drv.h

[Intel-gfx] [PATCH 12/23] drm/i915: get runtime PM references when the GPU is idle/busy

From: Paulo Zanoni ... instead of PC8 references. Now that both are the same thing and we are killing PC8, just get the runtime PM reference. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu

[Intel-gfx] [PATCH 00/23] Merge PC8 with runtime PM, v2

From: Paulo Zanoni Hi This is the second time I send this series to the mailing list. Please read the first cover letter: http://lists.freedesktop.org/archives/intel-gfx/2013-December/037721.html What's new? Two main differences: - Added a patch from Chris, which resulted in a change on h

[Intel-gfx] [PATCH 06/23] drm/i915: get/put runtime PM without holding rps.hw_lock

From: Paulo Zanoni We'll need this when we merge PC8 and Runtime PM: the PC8 enable/disable functions need that lock. Also, it's good practice to not hold a lock for longer than strictly needed. Reviewed-by: Imre Deak Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_debugfs.c | 12 +

[Intel-gfx] [PATCH 08/23] drm/i915: extract __hsw_do_{en, dis}able_package_c8

From: Paulo Zanoni When we merge PC8 and runtime PM, these new functions are going to be called by the runtime suspend/resume functions, and their callers are going to be removed. v2: - Rebase Reviewed-by: Imre Deak (v1) Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] [PATCH 03/23] drm/i915: put runtime PM only when we actually release force_wake

From: Paulo Zanoni When we call gen6_gt_force_wake_put we don't actually put force_wake, we just schedule gen6_force_wake_work through mod_delayed_work, and that will eventually release force_wake. The problem is that we call intel_runtime_pm_put directly at gen6_gt_force_wake_put, so most of th

[Intel-gfx] [PATCH 20/23] drm/i915: kill struct i915_package_c8

From: Paulo Zanoni The only remaining field of the struct was the lock, which was useless. v2: - Rebase. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_debugfs.c | 2 -- drivers/gpu/drm/i915/i915_drv.h | 6 -- drivers/gpu/drm/i915/intel_pm.c | 1 - 3 files changed, 9 de

[Intel-gfx] [PATCH 09/23] drm/i915: make PC8 be part of runtime PM suspend/resume

From: Paulo Zanoni Currently, when our driver becomes idle for i915.pc8_timeout (default: 5s) we enable PC8, so we save some power, but not everything we can. Then, while PC8 is enabled, if we stay idle for more autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the graphics devic

[Intel-gfx] [PATCH 22/23] drm/i915: update the PC8 and runtime PM documentation

From: Paulo Zanoni Now that PC8 got much simpler, there are less things to document. Also, runtime PM already has a nice documentation, so we don't need to re-explain it on our driver. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.h | 52 +--

[Intel-gfx] [PATCH 14/23] drm/i915: remove an indirection level on PC8 functions

From: Paulo Zanoni After the latest changes, the indirection is useless. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel

[Intel-gfx] [PATCH 13/23] drm/i915: kill pc8.disable_count

From: Paulo Zanoni Since after the latest patches it's only being used to prevent getting/putting the runtime PM refcount. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_debugfs.c | 1 - drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/intel_display.c | 14 ---

[Intel-gfx] [PATCH 02/23] drm/i915: put runtime PM only at the end of intel_mark_idle

From: Paulo Zanoni Because intel_mark_idle still touches some registers: it needs the machine to be awake. If you set both the autosuspend and PC8 delays to zero, you can get a "Device suspended" WARN when gen6_rps_idle touches registers. This is not easy to reproduce, but happens once in a whil

[Intel-gfx] [PATCH 17/23] drm/i915: don't get/put PC8 when getting/putting power wells

From: Paulo Zanoni Because we already get/put runtime PM every time we get/put any power domain, and now PC8 and runtime PM are the same thing. With this, we can also now kill the hsw_{en,dis}able_package_c8 functions. v2: - Rebase. v3: - Rebase. Signed-off-by: Paulo Zanoni --- drivers/gpu/d

[Intel-gfx] [PATCH 10/23] drm/i915: get/put runtime PM when we get/put a power domain

From: Paulo Zanoni Any power domain will require the HW to be in PCI D0 state, so just do the simple thing. Dear maintainer: since intel_display_power_put() and intel_display_power_get() are almost identical, git-am has failed to apply the patch on my local machine once: it added both chunks to

[Intel-gfx] [PATCH 07/23] drm/i915: add forcewake functions that don't touch runtime PM

From: Paulo Zanoni To solve a chicken-and-egg problem. Currently when we get/put forcewake we also get/put runtime PM and this works fine because the runtime PM code doesn't need forcewake. But we're going to merge PC8 and runtime PM into a single feature, and the PC8 code (the LCPLL code) does n

[Intel-gfx] [PATCH 01/23] drm/i915: Accurately track when we mark the hardware as idle/busy

From: Chris Wilson We currently call intel_mark_idle() too often, as we do so as a side-effect of processing the request queue. However, we the calls to intel_mark_idle() are expected to be paired with a call to intel_mark_busy() (or else we try to idle the hardware by accessing registers that ar

[Intel-gfx] [PATCH 11/23] drm/i915: remove dev_priv->pc8.requirements_met

From: Paulo Zanoni The requirements_met variable was used to track two things: enabled CRTCs and the power well. After the latest chagnes, we get a runtime PM reference whenever we get any of the power domains, and we get power domains when we enable CRTCs or the power well, so we should already

[Intel-gfx] [PATCH 05/23] drm/i915: rename modeset_update_power_wells

From: Paulo Zanoni To modeset_update_crtc_power_domains, since this function is responsible for updating all the power domains of all CRTCs after a modeset. In the future we should also run this function on all platforms, not just Haswell. Reviewed-by: Imre Deak Signed-off-by: Paulo Zanoni ---

[Intel-gfx] [PATCH 4/4] drm/i915: Register primary plane for each CRTC

Create a primary plane at CRTC init and hook up handlers for the various operations that may be performed on it. The DRM core will only advertise the primary planes to clients that set the appropriate capability bit. Since we're limited to the legacy plane operations at the moment (SetPlane and s

[Intel-gfx] [PATCH 3/4] drm/i915: Rename similar plane functions to avoid confusion

The name 'update_plane' was used both for the primary plane functions in intel_display.c and the sprite/overlay functions in intel_sprite.c. Rename the primary plane functions to 'update_primary_plane' to avoid confusion. On a similar note, intel_display.c already had a function called intel_disab

Re: [Intel-gfx] Info: mapping multiple BARs. Your kernel is fine.

On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote: > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote: > > My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and > > there to BAR is at a completely different address. Same thing on my > > Haswell deskto

[Intel-gfx] [PATCH v3] drm/i915: add support for Z-order of planes for VLV.

From: "Yu(Alex) Dai" Add "zorder" property to crtc to control Z-order of sprite and primary planes. The alpha channel of the planes can be enabled or disabled during Z-order change. This is enabled for Valleyview only. Signed-off-by: Yu(Alex) Dai --- drivers/gpu/drm/i915/i915_drv.h | 1

[Intel-gfx] [PATCH 3/2] drm/i915: Streamline VLV forcewake handling

From: Ville Syrjälä It occured to me that when we're trying to wake up both render and media wells on VLV, we might end up calling the low level force_wake_get/put two times even though one call would be enough. Make that happen by figuring out which wells really need to be woken up based on the

[Intel-gfx] [PATCH 0/3] drm/i915: A few BDW workarounds

From: Ville Syrjälä I was trawling the w/a database today and came across a few things we seem to be missing on BDW. Ville Syrjälä (3): drm/i915: Disable semaphore wait event idle message on BDW drm/i915: Implement WaDisableSDEUnitClockGating:bdw drm/i915: We implement WaDisableAsyncFlipPe

[Intel-gfx] [PATCH 1/3] drm/i915: Disable semaphore wait event idle message on BDW

From: Ville Syrjälä According to BSpec we need to always set this magic bit in ring buffer mode. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_pm.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/d

[Intel-gfx] [PATCH 3/3] drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index b340c75..a83ff91 100644 --- a/drivers/gpu/drm

[Intel-gfx] [PATCH 2/3] drm/i915: Implement WaDisableSDEUnitClockGating:bdw

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_pm.c | 4 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b47fff7..367362b 100644 --- a/drivers/gp

Re: [Intel-gfx] [PATCH] drm/i915: fix assert_cursor on BDW

On Thu, Feb 27, 2014 at 04:30:56PM -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > We need to read the correct register, not a register that doesn't exist > and will trigger "Unclaimed register" messages when we touch it. > > Also rearrange the checks in an attempt to prevent this error from

[Intel-gfx] [PATCH] drm/i915: fix assert_cursor on BDW

From: Paulo Zanoni We need to read the correct register, not a register that doesn't exist and will trigger "Unclaimed register" messages when we touch it. Also rearrange the checks in an attempt to prevent this error from happening again. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/

[Intel-gfx] [PATCH] drm/i915: Paranoia - get zeroed page table pages

We normally clear the page tables as one of the first things during initialization. They are however wired up (and potentially valid) before we clear them. To prevent the GPU from doing anything we might later regret, simply get zeroed pages, which always mean invalid on all GENs. NOTE: that a si

Re: [Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

2014-02-27 15:21 GMT-03:00 Keith Packard : > Ville Syrjälä writes: > >> Todd already implemented 5.4Gbps support a while back. So it seems your >> tree is a bit out of date. > > I didn't find it on drm-intel-fixes-2014-02-14; can you explain which > tree it is present in? It's on the drm-intel-ne

Re: [Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

Ville Syrjälä writes: > Todd already implemented 5.4Gbps support a while back. So it seems your > tree is a bit out of date. I didn't find it on drm-intel-fixes-2014-02-14; can you explain which tree it is present in? -- keith.pack...@intel.com pgpDBs_8j9uhj.pgp Description: PGP signature __

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Resolving the memory region conflict for Stolen area

On Mon, Feb 24, 2014 at 09:22:31PM +0200, Jani Nikula wrote: > I'm going to need a Reviewed-by and preferrably a Tested-by on this. I really didn't like this patch because requesting a region other than the one we use is morally equivalent to not requesting a region at all. The approach I would pr

[Intel-gfx] [PATCH 1/2] Add set_property stub for plane properties.

Hook up the set_property function pointer to a stub function. The function will be populated once actual plane properties are created. Signed-off-by: Bob Paauwe --- drivers/gpu/drm/i915/intel_sprite.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_sprite.

[Intel-gfx] [PATCH 2/2] Add gamma property to sprite planes.

Add a gamma property to sprite planes that enables/disables the gamma ramp on sprite planes. By default the gamma ramp is enabled to match the prior behavior. v2: Rename property variable from "gamma" to "gamma_property" for clarity Change property type from range to enum (Matt) Add enum d

[Intel-gfx] [PATCH 0/2] Sprite plane gamma on/off property.

Add the infrastructure to support plane properties in the intel_plane structure. Then use that infrastructure to add a property that controls wether gamma correction is applied to a plane. The default value is to enable gamma correction on the planes to match the previous behavior. Bob Paauwe (2)

Re: [Intel-gfx] [PATCH 03/19] drm/i915: add forcewake functions that don't touch runtime PM

On Thu, 2014-02-27 at 11:48 -0300, Paulo Zanoni wrote: > Hi > > I'm sorry, I forgot to say. This series is quite old, and I changed it > a little bit since then (since I found one or two problems), including > this patch. I think that, to avoid wasting your time reviewing old > patches, I should r

Re: [Intel-gfx] [PATCH 04/19] drm/i915: extract __hsw_do_{en, dis}able_package_c8

On Thu, 2013-12-19 at 11:54 -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > When we merge PC8 and runtime PM, these new functions are going to be > called by the runtime suspend/resume functions, and their callers are > going to be removed. > > Signed-off-by: Paulo Zanoni Reviewed-by: Imre

Re: [Intel-gfx] [PATCH 03/19] drm/i915: add forcewake functions that don't touch runtime PM

Hi I'm sorry, I forgot to say. This series is quite old, and I changed it a little bit since then (since I found one or two problems), including this patch. I think that, to avoid wasting your time reviewing old patches, I should resend the new series. The problem is that this series should be on

Re: [Intel-gfx] [v2 1/2] drm/i915: Update VBT data structures to have MIPI block enhancements

On Thu, 20 Feb 2014, Shobhit Kumar wrote: > +/* Block 52 contains MIPI configuration block > + * 6 * bdb_mipi_config, followed by 6 pps data > + * block below > + * > + * all delays in ms The spec you sent me has "... delay in 100us unit" for MIPI PPS entries which is weird and which is the reaso

Re: [Intel-gfx] [PATCH 03/19] drm/i915: add forcewake functions that don't touch runtime PM

On Thu, 2013-12-19 at 11:54 -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > To solve a chicken-and-egg problem. Currently when we get/put > forcewake we also get/put runtime PM and this works fine because the > runtime PM code doesn't need forcewake. But we're going to merge PC8 > and runtime

Re: [Intel-gfx] [PATCH] drm/i915: Reset vma->mm_list after unbinding

On Thu, Feb 27, 2014 at 04:11:39PM +0200, Ville Syrjälä wrote: > On Tue, Feb 25, 2014 at 02:23:28PM +, Chris Wilson wrote: > > In place of true activity counting, we walk the list of vma associated > > with an object managing each on the vm's active/inactive list everytime > > we call move-to-i

Re: [Intel-gfx] Fwd: [PATCH 2/2] drm/i915: Drop the forcewake count inc/dec around register read on VLV

On Wed, Jan 29, 2014 at 9:55 AM, ville syrjala -- Forwarded message -- From: ** mailto:ville.syrj...@linux.intel.com>> Date: Mon, Feb 24, 2014 at 8:32 PM Subject: [Intel-gfx] [PATCH 2/2] drm/i915: Drop the forcewake count inc/dec around register read on VLV To: intel-gfx@lists

Re: [Intel-gfx] Fwd: [PATCH 1/2] drm/i915: Fix VLV forcewake after reset

On Wed, Jan 29, 2014 at 9:55 AM, ville syrjala -- Forwarded message -- From: ** mailto:ville.syrj...@linux.intel.com>> Date: Mon, Feb 24, 2014 at 8:32 PM Subject: [Intel-gfx] [PATCH 1/2] drm/i915: Fix VLV forcewake after reset To: intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915: Reset vma->mm_list after unbinding

On Tue, Feb 25, 2014 at 02:23:28PM +, Chris Wilson wrote: > In place of true activity counting, we walk the list of vma associated > with an object managing each on the vm's active/inactive list everytime > we call move-to-inactive. This depends upon the vma->mm_list being > cleared after unbin

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Some more w/a'ish stuff

On 02/04/2014 09:59 PM, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > So I accidentally looked at gen6_init_clock_gating() and noticed a few > weird things that should have gotten cleaned up years ago. So I did that. > > While doing that I also noticed the WIZ hashing bits, and

Re: [Intel-gfx] [PATCH 02/19] drm/i915: get/put runtime PM without holding rps.hw_lock

On Thu, 2013-12-19 at 11:54 -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > We'll need this when we merge PC8 and Runtime PM: the PC8 > enable/disable functions need that lock. > > Also, it's good practice to not hold a lock for longer than strictly > needed. > > Signed-off-by: Paulo Zanoni

Re: [Intel-gfx] [PATCH 01/19] drm/i915: rename modeset_update_power_wells

On Thu, 2013-12-19 at 11:54 -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > To modeset_update_crtc_power_domains, since this function is > responsible for updating all the power domains of all CRTCs after a > modeset. In the future we should also run this function on all > platforms, not just

Re: [Intel-gfx] i915 resume-from-hibernation problems on resume with current Linus' tree

On Thu, 27 Feb 2014, Jiri Kosina wrote: > Hi, > > first things first: this is hard to bisect, because it doesn't happen > reliably and I don't really know what is the first good version, as I had > a delay in following Linus' tree. I think that I should've been clearer about the versions here

[Intel-gfx] [PATCH 3/5] drm/i915: Use DIV_ROUND_UP() when calculating number of required FDI lanes

From: Ville Syrjälä If we need precisely N lanes to satisfy the FDI bandwidth requirement, the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP() to get a more accurate answer. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insert

[Intel-gfx] [PATCH 4/5] drm/i915: Use port_clock for FDI frequency on DDI

From: Ville Syrjälä Use the port_clock that compute_config filled out in intel_fdi_link_freq() on DDI platforms. This means we're going to compute the FDI M/N based on the actual clock we're going to use, and we'll also check the link bandwidth against that clock. This eliminates the hidden assum

[Intel-gfx] [PATCH 0/5] drm/i915: FDI port_clock fix for DDI and other FDI changes

From: Ville Syrjälä I just set out to fix [1], but I ended up massaging the FDI and DDI code a bit more than I initially intended. The SPLL sharing part is untested due to the PLL sharing and selection being hardcoded to the output type. So I would've had to massage the code even more to get it

[Intel-gfx] [PATCH 5/5] drm/i915: Add SPLL sharing support for DDI

From: Ville Syrjälä Write some theoretical SPLL sharing support for DDI. Currently that will never happens since we never use SPLL for anything but FDI. But having the code there makes it easier if we ever want to do it, and it might excercise the PLL sharing code a bit more. Signed-off-by: Vill

[Intel-gfx] [PATCH 2/5] drm/i915: Change intel_fdi_link_freq() to 10kHz

From: Ville Syrjälä We normally use 10Khz units when describing DP link frequency. Have intel_fdi_link_freq() return the same units. I always get confused when the units start to be totally different. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 17 +

[Intel-gfx] [PATCH 1/5] drm/i915: Fix DDI port_clock for VGA output

From: Ville Syrjälä On DDI there's no PLL as such to generate the pixel clock for VGA. Instead we derive the pixel clock from the FDI link frequency. So to make .compute_config match what .get_config does, we need to set the port_clock based on the FDI link frequency. Note that we don't even che

Re: [Intel-gfx] Info: mapping multiple BARs. Your kernel is fine.

On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote: > On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra wrote: > > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote: > >> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. > >> They hang if I type

Re: [Intel-gfx] Info: mapping multiple BARs. Your kernel is fine.

On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote: > As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. > They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am > not so sure this is all related to the uncore IMC support, though. Unstable

Re: [Intel-gfx] Info: mapping multiple BARs. Your kernel is fine.

On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote: > My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and > there to BAR is at a completely different address. Same thing on my > Haswell desktop system. Hrrm, I'd like to see what Rafael finds out, whether what we're

Re: [Intel-gfx] [PATCH 19/19] drm/i915: power domains: add vlv power wells

On Wed, 2014-02-26 at 11:52 -0800, Jesse Barnes wrote: > On Wed, 26 Feb 2014 20:02:19 +0200 > Imre Deak wrote: > > > On Thu, 2014-02-20 at 11:58 -0800, Jesse Barnes wrote: > > > On Wed, 19 Feb 2014 14:29:44 +0200 > > > Ville Syrjälä wrote: > > > > > > > On Tue, Feb 18, 2014 at 12:02:20AM +0200,

Re: [Intel-gfx] Request for feedback : New Panel-fitter property for connectors

> Either we should have two range properties (eg. crtc_width and crtc_height), > or we could define a new property type that has both in the same value. > Not sure if it's worth adding another type for this. Although we might be > able to use such a type to reduce the number of properties a bit f

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add thread stall DOP clock gating workaround on Broadwell.

On Thu, Feb 27, 2014 at 10:43:34AM +0200, Ville Syrjälä wrote: > On Wed, Feb 26, 2014 at 11:59:31PM -0800, Kenneth Graunke wrote: > > Ben and I believe this will be necessary on production hardware. > > > > Signed-off-by: Kenneth Graunke > > --- > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > dri

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Resolving the memory region conflict for Stolen area

On Thu, 27 Feb 2014, Jani Nikula wrote: > On Wed, 26 Feb 2014, Jesse Barnes wrote: >> On Mon, 13 Jan 2014 16:25:21 +0530 >> akash.g...@intel.com wrote: >> >>> From: Akash Goel >>> >>> There is a conflict seen when requesting the kernel to reserve >>> the physical space used for the stolen area.

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Resolving the memory region conflict for Stolen area

On Wed, 26 Feb 2014, Jesse Barnes wrote: > On Mon, 13 Jan 2014 16:25:21 +0530 > akash.g...@intel.com wrote: > >> From: Akash Goel >> >> There is a conflict seen when requesting the kernel to reserve >> the physical space used for the stolen area. This is because >> some BIOS are wrapping the sto

Re: [Intel-gfx] [PATCH] drm/i915: use backlight legacy combination mode also for i915gm/i945gm

On Wed, 26 Feb 2014, Ville Syrjälä wrote: > On Tue, Feb 25, 2014 at 01:11:47PM +0200, Jani Nikula wrote: >> i915gm and i945gm also seem to use and need the legacy combination mode >> bit in BLC_PWM_CTL. >> >> v2: Also do this for i915gm (Ville). >> >> Reported-and-tested-by: Luis Ortega >> Bugz

Re: [Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

On Thu, Feb 27, 2014 at 12:11:39AM -0800, Carl Worth wrote: > With Haswell, 5.4Gbps is supported. And almost all of the code was > already in place already. All that was missing was this tiny bit of > additional wiring. Todd already implemented 5.4Gbps support a while back. So it seems your tree i

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add a partial instruction shootdown workaround on Broadwell.

On Wed, Feb 26, 2014 at 11:59:30PM -0800, Kenneth Graunke wrote: > I believe this will be necessary on production hardware. > > Signed-off-by: Kenneth Graunke > --- > drivers/gpu/drm/i915/i915_reg.h | 3 +++ > drivers/gpu/drm/i915/intel_pm.c | 4 > 2 files changed, 7 insertions(+) > > I ju

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add thread stall DOP clock gating workaround on Broadwell.

On Wed, Feb 26, 2014 at 11:59:31PM -0800, Kenneth Graunke wrote: > Ben and I believe this will be necessary on production hardware. > > Signed-off-by: Kenneth Graunke > --- > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 4 > 2 files changed, 5 insertions(+) >

[Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

With Haswell, 5.4Gbps is supported. And almost all of the code was already in place already. All that was missing was this tiny bit of additional wiring. Signed-off-by: Carl Worth Reviewed-by: Keith Packard --- drivers/gpu/drm/i915/intel_dp.c | 24 1 file changed, 20 in

[Intel-gfx] [PATCH 2/2] drm/i915: Add thread stall DOP clock gating workaround on Broadwell.

Ben and I believe this will be necessary on production hardware. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 4 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h in

[Intel-gfx] [PATCH 1/2] drm/i915: Add a partial instruction shootdown workaround on Broadwell.

I believe this will be necessary on production hardware. Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_pm.c | 4 2 files changed, 7 insertions(+) I just realized tonight that my workarounds series never got merged. After reviewing B