Ville Syrjälä writes:
>> @@ -651,7 +651,14 @@ static int i915_drm_suspend_late(struct drm_device
>> *drm_dev)
>> }
>>
>> pci_disable_device(drm_dev->pdev);
>> -pci_set_power_state(drm_dev->pdev, PCI_D3hot);
>> +/*
>> + * During hibernation on some GM45 platforms the BIOS
On Thu, Feb 26, 2015 at 06:47:14PM +0100, Quentin Casasnovas wrote:
> On Thu, Feb 26, 2015 at 05:10:17PM +, Chris Wilson wrote:
> > Not all of the DVO functions were checking the return value from their
> > i2c routines when reading registers. This could lead to us feeding
> > garbage values ba
From: Joe Konno
In instances where cursor sizes change, as in Chromium Ozone/Freon,
watermarks should be recomputed. There should be no hard-coded
assumptions about cursor widths. This was corrected originally here:
commit 64f962e3e38bf6f40bbd2462f8380dee0369e1bf
Author: Chris Wilson
Hi,
I'm having a few problems with i915 on my Broadwell Thinkpad
(T450s, i7-5600U) with kernel 3.19, apparently suspend/resume related.
During every suspend/resume cycle, I see this in my kernel log after
wakeup:
PM: Entering mem sleep
Suspending console(s) (use no_console_suspend to debug)
(thr
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5829
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -3 281/281
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_drv.h between commit b3a38998f042 ("drm/i915:
Fix a use after free, and unbalanced refcounting") from the
drm-intel-fixes tree and commit 98e1bd4ae68e ("drm/i915: Cache ringbuf
pointer in request str
Reviewed-by: Rodrigo Vivi
On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> UMS is gone, this is dead code.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 95
> -
> 1 file changed, 37 insertions(+), 58 deletions(-)
>
>
Reviewed-by: Rodrigo Vivi
On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> UMS is dead, yay!
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.c | 113
> ++--
> 1 file changed, 52 insertions(+), 61 deletions(-)
>
> diff --git a/d
Reviewed-by: Rodrigo Vivi
On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> Again, good riddance to UMS!
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.c | 49
> +++--
> 1 file changed, 23 insertions(+), 26 deletions(-)
>
> dif
I believe this patch is on the wrong series, right?
I'm afraid I don't know what was this race neither the two-step reset
to be able to review this comment remove.
Please give me some pointers to check that.
On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> With the two-step reset counter
Reviewed-by: Rodrigo Vivi
On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> Hooray!
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915
On Thu, Feb 26, 2015 at 2:48 PM, Joe Konno
wrote:
>
> From: Joe Konno
>
> In instances where cursor sizes change, as in Chromium Ozone/Freon,
> watermarks should be recomputed. There should be no hard-coded
> assumptions about cursor widths. This was corrected originally here:
>
> commit 64f9
On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> Lots of lines to remove!
Great clean up! :)
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 133 -
> drivers/gpu/drm/i915/i915_suspend.c | 215 +-
> drivers/gpu/drm/i915/i915_ums.c |
Reviewed-by: Rodrigo Vivi
On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> Mostly just checks in i915-private modeset ioctls.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ---
> drivers/gpu/drm/i915/intel_opregion.c | 6 ++
> drivers/gpu/drm/i91
Hi Mika,
On 2/26/2015 2:26 AM, Mika Kahola wrote:
In a case when DP link has been once trained we can reuse
the existing link training parameters i.e. voltage swing
and pre-emphasis levels from cache when there is a need to
restart link training. In a case of eDP we initially try
to train the li
Now that we store the reason string in the fbc structure, we are
duplicating the no FBC reason info. We can just reuse the string pointer
instead.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 13 -
drivers/gpu/drm/i915/intel_fbc.c | 31 +++-
There was a bit of duplicated logic here and we can have easier code to deal
with when adding a reason why we decided to disable FBC: we don't need to add
an enum, change the debugfs logic and code the check (3 sites), we can just
code the check (1 site).
That also removes 50 lines of code, which
No need to duplicate the logic and strings in debugfs, we can just reuse
the ones from when we disabled FBC.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 50 +++--
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_fb
How we log the reason to disable FBC isn't very normalized and we can
store the logic to only display the string once directly in
set_no_fbc_reason() instead of having ifs all over the place.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_fbc.c | 47 +++-
no_fbc_reason was a much better name, and now that we only store the
reason as a string, we can reuse that name.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_fbc.c| 12 ++--
3 fi
On Thu, Feb 26, 2015 at 02:48:44PM -0800, Joe Konno wrote:
> From: Joe Konno
>
> In instances where cursor sizes change, as in Chromium Ozone/Freon,
> watermarks should be recomputed. There should be no hard-coded
> assumptions about cursor widths. This was corrected originally here:
>
> com
The bare "Test requirement: modes" message is too cryptic, I had to go and
read the source code to understand the missing requirement.
Signed-off-by: Marc Herbert
---
If there is a different message that you would like to push yourself
then please don't mind me - I think ANY message would do.
On Thursday 26 February 2015 09:38 PM, Chris Wilson wrote:
On Thu, Feb 26, 2015 at 08:46:57PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in C6
in case of media
We've been leaking the framebuffers that get created inside the
legacy -> universal cursor compatibility layer and nobody noticed. Add
an i-g-t test to check debugfs and ensure we end up the same number of
framebuffers we started with after performing cursor operations.
Cc: Chris Wilson
Signed-o
Hi,
Did anybody get a chance to look into these patches?
The first patch in the series is merged in -nightly
Thanks,
Sonika
-Original Message-
From: Jindal, Sonika
Sent: Saturday, February 21, 2015 11:12 AM
To: intel-gfx@lists.freedesktop.org
Cc: ville.syrj...@linux.intel.com; Jindal, S
On Tue, 24 Feb 2015, Jani Nikula wrote:
> On Mon, 23 Feb 2015, "Daniel, Thomas" wrote:
>>> -Original Message-
>>> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
>>> Of
>>> Nick Hoath
>>> Sent: Thursday, February 19, 2015 4:31 PM
>>> To: intel-gfx@lists.freedes
On Thu, Feb 26, 2015 at 06:29:45PM -0700, Todd Previte wrote:
> Hi Mika,
>
> On 2/26/2015 2:26 AM, Mika Kahola wrote:
> > In a case when DP link has been once trained we can reuse
> > the existing link training parameters i.e. voltage swing
> > and pre-emphasis levels from cache when there is a ne
On Fri, 27 Feb 2015, Todd Previte wrote:
> Hi Mika,
>
> On 2/26/2015 2:26 AM, Mika Kahola wrote:
>> In a case when DP link has been once trained we can reuse
>> the existing link training parameters i.e. voltage swing
>> and pre-emphasis levels from cache when there is a need to
>> restart link tr
On Thu, 26 Feb 2015, Chris Wilson wrote:
> When we takeover from the BIOS and install our interrupt handler, the
> BIOS may have left us a few surprises in the form of spontaneous
> interrupts. (This is especially likely on hardware like 965gm where
> display fifo underruns are continuous and the
101 - 129 of 129 matches
Mail list logo
