On Thu, Feb 27, 2014 at 07:26:34PM -0300, Paulo Zanoni wrote:
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
On Fri, Feb 21, 2014 at 09:03:35PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Tell the drm core vblank code to reject drm_vblank_get()s only between
drm_vblank_off() and drm_vblank_on() calls, and sprinkle the appropriate
drm_vblank_on()
We don't want to suffer scheduling delay when turning off the GPU after
waking it up to touch registers. Ideally, we only want to keep the GPU
awake for the register access sequence, with a single forcewake dance on
the first access and release immediately after the last. We set a timer
on the
On Fri, Feb 28, 2014 at 09:02:38AM +, Chris Wilson wrote:
We don't want to suffer scheduling delay when turning off the GPU after
waking it up to touch registers. Ideally, we only want to keep the GPU
awake for the register access sequence, with a single forcewake dance on
the first access
We have reports of heavy screen corruption if we try to use the stolen
memory reserved by the BIOS whilst the DMA-Remapper is active. This
quirk may be only specific to a few machines or BIOSes, but first lets
apply the big hammer and always disable use of stolen memory when DMAR
is active.
On Thu, 20 Feb 2014, Shobhit Kumar shobhit.ku...@intel.com wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address review comments by Jani
- adjust code for the structure changes for bdb_mipi_config
- add boundry and
On Mon, 2014-02-24 at 11:34 -0300, Paulo Zanoni wrote:
2014-02-24 8:23 GMT-03:00 Imre Deak imre.d...@intel.com:
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Otherwise, when we run intel_modeset_check_state we may already be
runtime
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Thu, 27 Feb 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
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
On Thu, 27 Feb 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
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
On Tue, 11 Feb 2014, Imre Deak imre.d...@intel.com wrote:
We reserve the space for the power context in stolen memory at a fixed
address from a delayed work. This races with the subsequent driver
init/resume code which could allocate something at that address, so the
reservation for the power
On Fri, 2014-02-21 at 15:05 -0300, Paulo Zanoni wrote:
2014-02-21 13:52 GMT-03:00 Paulo Zanoni przan...@gmail.com:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because we shouldn't be runtime suspended when forcewake is supposed
to be enabled.
This commit will trigger the WARNs because
On Fri, 14 Feb 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, Feb 14, 2014 at 08:23:54PM +0200, Imre Deak wrote:
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
starting with the WARN below.
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Just to be sure...
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
On 2/28/2014 1:37 AM, ville.syrj...@linux.intel.com wrote:
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
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because gen6_gt_force_wake_{get,put} should already be responsible for
getting/putting runtime PM.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Imre Deak
On Fri, Feb 28, 2014 at 07:56:56PM +0530, S, Deepak wrote:
On 2/28/2014 1:37 AM, ville.syrj...@linux.intel.com wrote:
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
On Thu, Feb 27, 2014 at 02:36:06PM -0800, Yu Dai wrote:
On 14-02-25 04:19 PM, Matt Roper wrote:
On Thu, Feb 20, 2014 at 04:11:14PM -0800, yu@intel.com wrote:
From: Yu(Alex) Dai yu@intel.com
Add zorder property to crtc to control Z-order of sprite and
primary planes. The alpha
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
I could swear this was already happening in the current code...
Also, put the reads and writes in a generic place, so we don't forget
it again when we add runtime PM support to new platforms.
On Thu, 2014-02-27 at 19:26 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Thu, 2014-02-27 at 19:26 -0300, Paulo Zanoni wrote:
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,
On Fri, Feb 28, 2014 at 11:16:33AM +0200, Ville Syrjälä wrote:
Should we use the timer to delay the forcewake release from register
read/write functions too? Or maybe do it only for register
read/write since gen6_gt_force_wake_get/put are rather rare and I
wouldn't expect significant forcewake
In the future we want to be able to specify a per-pipe number of sprites. This
series introduces this with a bit of refactoring first to, hopefully, don't
make the same mistake that v1 did again.
--
Damien
Damien Lespiau (3):
drm/i915: Use a pipe variable to cycle trough the pipes
drm/i915:
I recently fumbled a patch because I wrote twice num_sprites[i], and it
was the right thing to do in only 50% of the cases.
This patch ensures I need to write num_sprites[pipe], ie it should be
self-documented that it's per-pipe number of sprites without having to
look at what is 'i' this time
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 14 +++---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
2 files changed, 14 insertions(+), 6
This macro is similar to for_each_pipe() we already have. Convert the
two call sites we have at the same time.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 16
2 files changed, 9
On Thu, 27 Feb 2014 19:26:39 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
On Thu, 27 Feb 2014 19:26:41 -0300
Paulo Zanoni przan...@gmail.com wrote:
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 ++--
On Thu, 27 Feb 2014 19:26:40 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
---
On Thu, 27 Feb 2014 19:26:43 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
On Thu, 27 Feb 2014 19:26:45 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
On Thu, 27 Feb 2014 19:26:47 -0300
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The only remaining field of the struct was the lock, which was
useless.
v2: - Rebase.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
On Thu, 27 Feb 2014 19:26:46 -0300
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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.
On Thu, 27 Feb 2014 19:26:48 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
---
On Thu, 27 Feb 2014 19:26:42 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
---
On Thu, 27 Feb 2014 19:26:49 -0300
Paulo Zanoni przan...@gmail.com wrote:
+ * Our driver uses the autosuspend delay feature, which means we'll only
really
+ * suspend if we stay with zero refcount for a certain amount of time. The
+ * default value is currently very conservative (see
On Thu, 27 Feb 2014 19:26:44 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
On Thu, 27 Feb 2014 19:26:50 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
On Fri, Feb 28, 2014 at 04:42:14PM +, Damien Lespiau wrote:
This macro is similar to for_each_pipe() we already have. Convert the
two call sites we have at the same time.
Have you considered adding the enum sprite? One day sparse will give us
warnings when we screw up.
-Chris
--
Chris
On Fri, Feb 28, 2014 at 04:42:15PM +, Damien Lespiau wrote:
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!
But today, what's wrong with:
for_each_pipe(pipe) info-num_sprites[pipe] = IS_VLV(dev) ? 2 : 1;
-Chris
--
Chris Wilson, Intel Open
On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
On Thu, 27 Feb 2014 19:26:43 -0300
Paulo Zanoni przan...@gmail.com wrote:
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
On Fri, Feb 28, 2014 at 05:30:02PM +, Chris Wilson wrote:
On Fri, Feb 28, 2014 at 04:42:15PM +, Damien Lespiau wrote:
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!
But today, what's wrong with:
for_each_pipe(pipe)
On Fri, Feb 28, 2014 at 05:37:39PM +, Damien Lespiau wrote:
On Fri, Feb 28, 2014 at 05:30:02PM +, Chris Wilson wrote:
On Fri, Feb 28, 2014 at 04:42:15PM +, Damien Lespiau wrote:
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!
On Fri, 28 Feb 2014 19:38:17 +0200
Imre Deak imre.d...@intel.com wrote:
On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
On Thu, 27 Feb 2014 19:26:43 -0300
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We had these
On Fri, Feb 28, 2014 at 05:49:20PM +, Chris Wilson wrote:
On Fri, Feb 28, 2014 at 05:37:39PM +, Damien Lespiau wrote:
On Fri, Feb 28, 2014 at 05:30:02PM +, Chris Wilson wrote:
On Fri, Feb 28, 2014 at 04:42:15PM +, Damien Lespiau wrote:
In the future, we need to be able to
2014-02-28 14:15 GMT-03:00 Jesse Barnes jbar...@virtuousgeek.org:
On Thu, 27 Feb 2014 19:26:46 -0300
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
When other platforms add runtime PM support they will also need to
disable interrupts, so move the variable
On Fri, 2014-02-28 at 09:55 -0800, Jesse Barnes wrote:
On Fri, 28 Feb 2014 19:38:17 +0200
Imre Deak imre.d...@intel.com wrote:
On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
On Thu, 27 Feb 2014 19:26:43 -0300
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni
We don't want to suffer scheduling delay when turning off the GPU after
waking it up to touch registers. Ideally, we only want to keep the GPU
awake for the register access sequence, with a single forcewake dance on
the first access and release immediately after the last. We set a timer
on the
2014-02-28 15:20 GMT-03:00 Imre Deak imre.d...@intel.com:
On Fri, 2014-02-28 at 09:55 -0800, Jesse Barnes wrote:
On Fri, 28 Feb 2014 19:38:17 +0200
Imre Deak imre.d...@intel.com wrote:
On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
On Thu, 27 Feb 2014 19:26:43 -0300
Paulo
On Fri, Feb 28, 2014 at 06:03:11PM +0200, Ville Syrjälä wrote:
On Thu, Feb 27, 2014 at 03:44:04PM -0800, Matt Roper wrote:
On Thu, Feb 27, 2014 at 02:36:06PM -0800, Yu Dai wrote:
On 14-02-25 04:19 PM, Matt Roper wrote:
On Thu, Feb 20, 2014 at 04:11:14PM -0800, yu@intel.com wrote:
2014-02-28 5:44 GMT-03:00 Chris Wilson ch...@chris-wilson.co.uk:
On Thu, Feb 27, 2014 at 07:26:34PM -0300, Paulo Zanoni wrote:
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
On Fri, Feb 28, 2014 at 04:38:28PM -0300, Paulo Zanoni wrote:
Another thing worth mentioning, is that at hsw_restore_lcpll we expect
the forcewake count to be always zero. So we could do some other kind
of trick relying on that, but I don't think it's very future-proof.
Actually, having read
2014-02-28 10:50 GMT-03:00 Imre Deak imre.d...@intel.com:
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
If we always initialize kref for the context, even if we are using fake
contexts for hangstats when there is no hw support, we can forgo the
dance to dereference the ctx-obj and inspect whether we are permitted
to use kref inside i915_gem_context_reference() and _unreference().
My ulterior motive
Hi
2014-02-27 9:23 GMT-03:00 ville.syrj...@linux.intel.com:
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
2014-02-27 9:23 GMT-03:00 ville.syrj...@linux.intel.com:
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,
2014-02-27 9:23 GMT-03:00 ville.syrj...@linux.intel.com:
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.
2014-02-27 9:23 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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.
Hi all this series enable PSR on Baytrail.
This is basically the patch drm/i915: Add Baytrail PSR support. patch
split in small patches to make the review easier.
This version contains almost all suggestions and bikesheds I got on that
single patch and more fixes.
Thanks,
Rodrigo.
Rodrigo Vivi
This patch allows system to safely recover after kms_psr_sink_crc check
or any other similar case that might fail when PSR is enabled.
Ville made and sent me this patch after noticing that primary plane enabled
bit was set during test case and unset after failure. What was causing a hard
and
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_suspend.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 56785e8..77a2194 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++
Also do not cache aux info. That info could be related to another panel.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
Let's be more conservative and protect platforms that don't
support PSR from unecessary interactions.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git
v2: Avoid more than one setup. Removing initialization
and trusting allocation. (By Paulo Zanoni).
v3: rebase.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 ++
Add debugfs support for Baytrail considering that on Baytrail we can
have PSR on pipe A or pipe B and we don't have any kind of
performance counter as we have on other platforms that support PSR.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 36
This patch just introduce registers and functions for PSR Baytrail.
It is important to highlight this patch doesn't work alone.
Baytrail PSR has some critical PSR-exit trigger issues that are fixed
on following patches.
Also, only on last one we mark baytrail/valleyview as HAS_PSR.
Cc: Ville
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on {busy_ioctl, set_domain, sw_finish and mark_busy}
and update to enable it back it later with a delayed workqueue.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Being more conservative by enabling PSR only on psr_enable function.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
This patch is the last in series that finnaly enable PSR on Baytrail
by adding it to HAS_PSR and calling the propper enable and disable
functions on the right places.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_dp.c |
Baytrail supports per-pipe PSR configuration, however PSR on
PIPE_B isn't working properly. So let's keep it disabled for now.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
Different from core PSR implementation (i.e. Haswell and Broadwell)
Baytrail PSR can be enabled even when source is ok because it
provides way to inactivate PSR whenever any screen updated is done.
Baytrail also doesn't provide any kind of Performance Counters.
Signed-off-by: Rodrigo Vivi
v2: Wait psr enable with timeout and more subtest added.
v3: Add wait for v_blank leeting test more reliable and preparing to
add Baytrail per-pipe tests.
v4: Call busy_ioctl on mmap_gtt to match the real usage and remove the need
of inactivate on set_domain, what was semantically wrong.
I see VIRTUAL1 disconnected in Xorg.0.log, several bugs filed at
freedesktop.org, an announcement of 2.99.901 at
http://lists.freedesktop.org/archives/xorg/2013-September/055988.html and
Google hits on cgit.freedesktop.org/xorg/driver/xf86-video-intel containing
strings intel-virtual-output
On Fri, Feb 28, 2014 at 07:28:41PM -0300, Paulo Zanoni wrote:
2014-02-27 9:23 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We normally use 10Khz units when describing DP link frequency.
Have intel_fdi_link_freq() return the same units. I
74 matches
Mail list logo
