Ben and I believe this will be necessary on production hardware.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
I believe this will be necessary on production hardware.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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 cwo...@cworth.org
Reviewed-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 24
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 kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5
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 kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 7
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 is
On Wed, 26 Feb 2014, Ville Syrjälä ville.syrj...@linux.intel.com 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:
On Wed, 26 Feb 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 13 Jan 2014 16:25:21 +0530
akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
There is a conflict seen when requesting the kernel to reserve
the physical space used for the stolen area. This is because
On Thu, 27 Feb 2014, Jani Nikula jani.nik...@linux.intel.com wrote:
On Wed, 26 Feb 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 13 Jan 2014 16:25:21 +0530
akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
There is a conflict seen when requesting the kernel to
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 kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_reg.h | 1
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 for
On Wed, 2014-02-26 at 11:52 -0800, Jesse Barnes wrote:
On Wed, 26 Feb 2014 20:02:19 +0200
Imre Deak imre.d...@intel.com 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ä ville.syrj...@linux.intel.com wrote:
On Tue,
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
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
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org 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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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 -- I
On Thu, 2013-12-19 at 11:54 -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Thu, 2013-12-19 at 11:54 -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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.
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
On Wed, Jan 29, 2014 at 9:55 AM, ville syrjala
-- Forwarded message --
From: ** ville.syrj...@linux.intel.com
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:
On Wed, Jan 29, 2014 at 9:55 AM, ville syrjala
-- Forwarded message --
From: ** ville.syrj...@linux.intel.com
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
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
On Thu, 20 Feb 2014, Shobhit Kumar shobhit.ku...@intel.com 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
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 Thu, 2013-12-19 at 11:54 -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
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 resend
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
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
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 bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/intel_sprite.c | 9 +
1 file changed, 9 insertions(+)
diff --git
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
Ville Syrjälä ville.syrj...@linux.intel.com 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
2014-02-27 15:21 GMT-03:00 Keith Packard kei...@keithp.com:
Ville Syrjälä ville.syrj...@linux.intel.com 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
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Thu, Feb 27, 2014 at 04:30:56PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
According to BSpec we need to always set this magic bit in ring buffer
mode.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 3 +++
2 files changed, 6
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Yu(Alex) Dai yu@intel.com
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 yu@intel.com
---
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 desktop
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
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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 paulo.r.zan...@intel.com
---
From: Paulo Zanoni paulo.r.zan...@intel.com
After the latest changes, the indirection is useless.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
Since after the latest patches it's only being used to prevent
getting/putting the runtime PM refcount.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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 imre.d...@intel.com
Signed-off-by: Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com
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 imre.d...@intel.com (v1)
Signed-off-by: Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com
After we removed all the intermediate abstractions, we can rename
these functions to just hsw_{en,dis}able_pc8.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
From: Paulo Zanoni paulo.r.zan...@intel.com
... 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 paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
We already get runtime PM references, and PC8 is now part of runtime
PM, so this is enough.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Chris Wilson ch...@chris-wilson.co.uk
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Thu, Feb 27, 2014 at 09:59:03PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
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
From spec the drain latency precision multipler is either 32 or 64 for VLV.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 18 +-
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
2 files changed, 15 insertions(+), 15 deletions(-)
diff
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
70 matches
Mail list logo
