On Fri, Feb 28, 2014 at 07:28:41PM -0300, Paulo Zanoni wrote:
> 2014-02-27 9:23 GMT-03:00 :
> > 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 tot
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 and
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
---
te
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.
v5
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
---
drivers/gpu/drm/i915/intel_dp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/
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
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_dp.c | 4
2 files change
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
---
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 Syrj
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
Cc: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915
Being more conservative by enabling PSR only on psr_enable function.
Signed-off-by: Rodrigo Vivi
---
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 b/drivers/gpu/drm/i915/intel_dp.c
index 51be6e7..68b
Let's be more conservative and protect platforms that don't
support PSR from unecessary interactions.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/dr
v2: Avoid more than one setup. Removing initialization
and trusting allocation. (By Paulo Zanoni).
v3: rebase.
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 ++
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 file
Also do not cache aux info. That info could be related to another panel.
Signed-off-by: Rodrigo Vivi
---
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 b/drivers/gpu/drm/i915/intel_dp.c
index 68ba
Signed-off-by: Rodrigo Vivi
---
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
+++ b/drivers/gpu/drm/i915/
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 non-r
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 Viv
2014-02-27 9:23 GMT-03:00 :
> 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ä
A nice simplification!
2014-02-27 9:23 GMT-03:00 :
> 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ä
Reviewed-by: Paulo Zanoni
> --
2014-02-27 9:23 GMT-03:00 :
> 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
Hi
2014-02-27 9:23 GMT-03:00 :
> 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 s
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
2014-02-28 10:50 GMT-03:00 Imre Deak :
> On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
>> 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 a
2014-02-28 12:45 GMT-03:00 Imre Deak :
> On Thu, 2014-02-27 at 19:26 -0300, Paulo Zanoni wrote:
>> 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_
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 5:44 GMT-03:00 Chris Wilson :
> On Thu, Feb 27, 2014 at 07:26:34PM -0300, 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
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
2014-02-28 15:20 GMT-03:00 Imre Deak :
> On Fri, 2014-02-28 at 09:55 -0800, Jesse Barnes wrote:
>> On Fri, 28 Feb 2014 19:38:17 +0200
>> Imre Deak wrote:
>>
>> > On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
>> > > On Thu, 27 Feb 2014 19:26:43 -0300
>> > > Paulo Zanoni 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 and release immediately after the last. We set a timer
on the firs
On Fri, 2014-02-28 at 09:55 -0800, Jesse Barnes wrote:
> On Fri, 28 Feb 2014 19:38:17 +0200
> Imre Deak wrote:
>
> > On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
> > > On Thu, 27 Feb 2014 19:26:43 -0300
> > > Paulo Zanoni wrote:
> > >
> > > > From: Paulo Zanoni
> > > >
> > > > We ha
2014-02-28 14:15 GMT-03:00 Jesse Barnes :
> On Thu, 27 Feb 2014 19:26:46 -0300
> Paulo Zanoni wrote:
>
>> 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: -
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 b
On Fri, 28 Feb 2014 19:38:17 +0200
Imre Deak wrote:
> On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
> > On Thu, 27 Feb 2014 19:26:43 -0300
> > Paulo Zanoni wrote:
> >
> > > From: Paulo Zanoni
> > >
> > > We had these intel_aux_display_runtime_{get,put} abstractions that
> > > would j
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
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) info->n
On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
> On Thu, 27 Feb 2014 19:26:43 -0300
> Paulo Zanoni wrote:
>
> > 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 th
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 Op
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 Wi
On Fri, Feb 28, 2014 at 04:42:13PM +, Damien Lespiau wrote:
> 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-
On Thu, 27 Feb 2014 19:26:50 -0300
Paulo Zanoni wrote:
> 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 in
On Thu, 27 Feb 2014 19:26:44 -0300
Paulo Zanoni wrote:
> 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.
>
> v
On Thu, 27 Feb 2014 19:26:49 -0300
Paulo Zanoni 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 intel_init_runtime_pm)
On Thu, 27 Feb 2014 19:26:42 -0300
Paulo Zanoni wrote:
> 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(-)
>
On Thu, 27 Feb 2014 19:26:48 -0300
Paulo Zanoni wrote:
> 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/g
On Thu, 27 Feb 2014 19:26:46 -0300
Paulo Zanoni wrote:
> 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
> ---
> d
On Thu, 27 Feb 2014 19:26:47 -0300
Paulo Zanoni wrote:
> 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
On Thu, 27 Feb 2014 19:26:45 -0300
Paulo Zanoni wrote:
> 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 anymo
On Thu, 27 Feb 2014 19:26:43 -0300
Paulo Zanoni wrote:
> 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
On Thu, 27 Feb 2014 19:26:40 -0300
Paulo Zanoni wrote:
> 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/i91
On Thu, 27 Feb 2014 19:26:41 -0300
Paulo Zanoni wrote:
> 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(-)
>
> di
On Thu, 27 Feb 2014 19:26:39 -0300
Paulo Zanoni wrote:
> 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 ++--
>
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
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 16
2 files changed, 9 insertions(+), 8 deletions(
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 aro
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
---
drivers/gpu/drm/i915/i915_dma.c | 14 +++---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/d
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:
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 forcew
On Thu, 2014-02-27 at 19:26 -0300, Paulo Zanoni wrote:
> 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
On Thu, 2014-02-27 at 19:26 -0300, Paulo Zanoni wrote:
> 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
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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.
>
> Signed-off-by
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"
> >>
> >>Add "zorder" property to crtc to control Z-order of sprite and
> >>primary planes. The alpha c
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ä
> >
> > 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_w
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because gen6_gt_force_wake_{get,put} should already be responsible for
> getting/putting runtime PM.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 --
> 1
On 2/28/2014 1:37 AM, ville.syrj...@linux.intel.com wrote:
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 fi
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Just to be sure...
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_uncore.c | 8
> 3 files chang
On Fri, 14 Feb 2014, Chris Wilson 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.
>>
>> Regression introduc
On Fri, 2014-02-21 at 15:05 -0300, Paulo Zanoni wrote:
> 2014-02-21 13:52 GMT-03:00 Paulo Zanoni :
> > From: Paulo Zanoni
> >
> > Because we shouldn't be runtime suspended when forcewake is supposed
> > to be enabled.
> >
> > This commit will trigger the WARNs because we currently have a bug
> > w
On Tue, 11 Feb 2014, Imre Deak 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 context fails. R
On Thu, 27 Feb 2014, Ville Syrjälä wrote:
> 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
On Thu, 27 Feb 2014, Chris Wilson 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 equivalent to not r
On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
> 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
On Mon, 2014-02-24 at 11:34 -0300, Paulo Zanoni wrote:
> 2014-02-24 8:23 GMT-03:00 Imre Deak :
> > On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> Otherwise, when we run intel_modeset_check_state we may already be
> >> runtime suspended, and our state check
On Thu, 20 Feb 2014, Shobhit Kumar 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 buffer overflow che
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.
Bugzil
On Thu, Feb 27, 2014 at 07:26:36PM -0300, Paulo Zanoni wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ce582eb..788b165 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6614,7 +6614,7
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 acc
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 firs
On Fri, Feb 21, 2014 at 09:03:35PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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() calls to the .crtc_enable()
On Thu, Feb 27, 2014 at 07:26:34PM -0300, 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
77 matches
Mail list logo
