My OCD just couldn't let this slide. Spotted while reviewing Ville's
patch to only flip planes when we have FBC.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 4
On Thu, Jan 09, 2014 at 03:17:25PM -0800, Ben Widawsky wrote:
> On Tue, Jan 07, 2014 at 10:47:18AM +, Chris Wilson wrote:
> > On Tue, Jan 07, 2014 at 08:10:33AM +0100, Daniel Vetter wrote:
> > > On Sat, Dec 28, 2013 at 01:31:49PM -0800, Ben Widawsky wrote:
> > > > The initialized flag is used t
On Wed, Jan 08, 2014 at 09:27:29PM +0100, Daniel Vetter wrote:
> A regression in the topic/ppgtt branch introduce in
>
> commit 87d60b63e0371529faaed0667d457e5022964010
> Author: Ben Widawsky
> Date: Fri Dec 6 14:11:29 2013 -0800
>
> drm/i915: Add PPGTT dumper
>
> The issue is that we're
Hi everyone,
I recently got a new Macbook Pro, which I dual-booted into Ubuntu 13.10
(Linux kernel 3.11). My previous computers were from 2008 and used ATI
or Nvidia graphics cards. The new one (with Intel HD 4000 integrated
graphics, core i7, no other graphics card) seems to cause me a lot
On Tue, Jan 07, 2014 at 11:45:14AM +, Chris Wilson wrote:
> Freeing a request triggers the destruction of the context. This needs to
> occur after all objects are themselves unbound from the context, and so
> the free request needs to occur after the object release during retire.
>
> This tidi
On Tue, Jan 07, 2014 at 08:53:36AM +0100, Daniel Vetter wrote:
> On Thu, Jan 02, 2014 at 07:50:33PM -1000, Ben Widawsky wrote:
> > This will allow mesa to determine if it needs to create a context, or
> > can reuse the default context. Reusing the default context saves memory,
> > and startup time.
On Tue, Jan 07, 2014 at 10:47:18AM +, Chris Wilson wrote:
> On Tue, Jan 07, 2014 at 08:10:33AM +0100, Daniel Vetter wrote:
> > On Sat, Dec 28, 2013 at 01:31:49PM -0800, Ben Widawsky wrote:
> > > The initialized flag is used to specify a context has been initialized
> > > and it's context is saf
This is useful for debugging as we then know that the first entry is
always the global GTT, and all later entries the per-process GTT VM.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_
The current error state harks back to the era of just a single VM. For
full-ppgtt, we capture every bo on every VM. It behoves us to then print
every bo for every VM, which we currently fail to do and so miss vital
information in the error state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i
Yay, I'm really happy that after fbc testcases for psr are now also
shaping up. Some small stuff below.
-Daniel
On Thu, Jan 9, 2014 at 8:47 PM, Rodrigo Vivi wrote:
> This debugfs interface will allow intel-gpu-tools test case
> to verify if screen has been updated properly on cases like PSR.
>
>
This debugfs interface will allow intel-gpu-tools test case
to verify if screen has been updated properly on cases like PSR.
Since the current target is PSR we will provide only the CRC check
for eDP panels. We can latter extend it to all available DP panels.
---
drivers/gpu/drm/i915/i915_debugfs
>> This completely breaks the ABI. Nak.
If you remember, before doing any stolen memory related changes, we had
consulted you. We went ahead with these changes, after getting a nod from your
side.
This idea of allocating the User created frame buffers came from your side only.
We didn't had the
Hello,
The check_crtc_state() routine in drivers/gpu/drm/i915/intel_display.c
contains a whole bunch of WARN() statements (and so do other routines
in this source file, but this is the one I'm presently concerned
about). Is it really necessary for these to be WARN?
I don't see how it does any go
On Thu, Jan 09, 2014 at 07:28:51PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> Many of the fields from Gen6 have gone away for vlv. Strip all those
> fields that are not relevent and try to update fields that we care
> about. This patch give information about current RP & RC status and
On Wed, 8 Jan 2014, Daniel Vetter wrote:
> On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote:
> > On Tue, 7 Jan 2014, Daniel Vetter wrote:
> >
> > > I really want users to report these issues, and excessive WARNs seems
> > > to be the only way to get those reports. Please boot with
> > >
On Thu, Jan 09, 2014 at 05:21:49PM +0530, akash.g...@intel.com wrote:
> From: akashgoe
>
> The following changes leads to stable behavior, especially
> when playing 3D Apps, benchmarks.
>
> Added 4 new rendering specific Workarounds
> 1. WaTlbInvalidateStoreDataBefore :-
> Before pipecontro
On Thu, Jan 09, 2014 at 03:11:39PM +, Chris Wilson wrote:
> At first glance, it seems reasonable that a currently unbound bo during
> i915_vma_unbind() could only arrive there by an interrupted execbuffer
> that never successfully bound. However, inserting a BUG, viz
>
> diff --git a/drivers/g
Hi Chris,
During the development of runtime power management we faced some random issue
around RC6 during the suspend. After some analyzing, we found by following the
flow of doing Forcewake Get before the RC6 Disable and forcewake Put after we
enable the RC6 solved most of the issues.
This p
At first glance, it seems reasonable that a currently unbound bo during
i915_vma_unbind() could only arrive there by an interrupted execbuffer
that never successfully bound. However, inserting a BUG, viz
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index b52c38d63
intel_init_dpio() isn't called during resume, so we won't set the CRI
clock enable bit during that time. Move the enabling to
intel_reset_dpio() instead.
Note that the HW reset value for this bit is 1, so probably this patch
won't make any difference. We should still make the setting explicit,
sin
VGA detection requires the reference clock to be on, so make sure this
is the case.
This fixes VGA hotplug/manual detection where all pipes are off and so
we would normally disable all clocks.
v2:
- Instead of disabling PSR clock gating, force the reference clock on
through the DPLL_A register.
From: Deepak S
With RC6 enabled, BYT has an HW issue in determining the right
Gfx busyness.
WA for Turbo + RC6: Use SW based Gfx busy-ness detection to decide
on increasing/decreasing the freq. This logic will monitor C0
counters of render/media power-wells over EI period and takes
necessary acti
On Thu, Jan 09, 2014 at 07:28:27PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> We need do forcewake before Disabling RC6, This is what the BIOS
> expects while going into suspend.
What suspend are we talking about? When does the BIOS run, how is that
serialised with the get/put of forc
From: Deepak S
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for
From: Deepak S
Below patches addes WA to set Gfx freq while clock are down. Also, added a WA
to enables both RC6 and Turbo work together.
Deepak S (3):
drm/i915: Disable/Enable PM Intrrupts based on the current freq.
drm/i915/vlv: WA to fix Voltage not getting dropped to Vmin when Gfx
i
From: Deepak S
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPe, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPe then move GFx down.
v2: remove vlv_update_rps
From: Deepak S
Many of the fields from Gen6 have gone away for vlv. Strip all those
fields that are not relevent and try to update fields that we care
about. This patch give information about current RP & RC status and
individual Wells.
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/i915_deb
From: Deepak S
RC6 should be enabled only if the PCBR register is programmed properly
either BIOS or Gfx. This patches address the case where PCBR
allocation fails due buggy BIOS or due to stolen memory allocation
failed.
v2: Add #define for magic numbers (Daniel)
v3: Use VLV_PCBR_ADDR_SHIFT in
From: Deepak S
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.
v2: updated commit message. (Daniel)
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/int
On Thu, 09 Jan 2014, akash.g...@intel.com wrote:
> From: akashgoe
>
> The following changes leads to stable behavior, especially
> when playing 3D Apps, benchmarks.
>
> Added 4 new rendering specific Workarounds
> 1. WaTlbInvalidateStoreDataBefore :-
> Before pipecontrol with TLB invalidate s
From: Akash Goel
This adds support for using the write-enable bit in the GTT entry for VLV.
This is handled via a read-only flag in the GEM buffer object which
is then used to check if the write-enable bit has to be set or not
when writing the GTT entries.
Currently by default only the Batch buff
Hi
On Thu, Jan 9, 2014 at 1:11 PM, Damien Lespiau wrote:
> On Wed, Jan 08, 2014 at 09:26:51PM +0100, Daniel Vetter wrote:
>> > So the parent structure is expected to have "struct drm_device" at
>> > offset 0? I'd rather like to see a "drm_dev_init()" alongside
>> > drm_dev_alloc() similar to devi
On Wed, Jan 08, 2014 at 09:26:51PM +0100, Daniel Vetter wrote:
> > So the parent structure is expected to have "struct drm_device" at
> > offset 0? I'd rather like to see a "drm_dev_init()" alongside
> > drm_dev_alloc() similar to device_initialize().
>
> Yeah, I think for subclassing we want driv
From: akashgoe
The following changes leads to stable behavior, especially
when playing 3D Apps, benchmarks.
Added 4 new rendering specific Workarounds
1. WaTlbInvalidateStoreDataBefore :-
Before pipecontrol with TLB invalidate set,
need 2 store data commands
2. WaReadAfterWriteHazard :
On Thu, Jan 09, 2014 at 04:56:39PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> Using MMIO based flips now on VLV for Media power well residency optimization.
> The blitter ring is currently being used just for the command streamer based
> flip calls. For pure 3D workloads, with MMIO
On Thu, Jan 09, 2014 at 04:56:37PM +0530, akash.g...@intel.com wrote:
> The other alternative of having Render ring based flip calls is not being
> used, as that option adversly affects the performance (FPS) of certain 3D Apps
> Also going forward, for newer platforms like CHV, the atomic flips wil
From: Akash Goel
MMIO flips will replace the blitter command streamer based flips on VLV.
Created our own private workqueue for handling the MMIO based flips,
so as to avoid the block of the display thread (who issued the flip ioctl),
due to the synchronization needed between the Rendering & flip
From: Akash Goel
Using MMIO based flips now on VLV for Media power well residency optimization.
The blitter ring is currently being used just for the command streamer based
flip calls. For pure 3D workloads, with MMIO flips, there will be no use of
blitter ring and this will ensure the 100% resid
From: Akash Goel
Replaced blitter command streamer based flips with MMIO flips on VLV.
This is for Media power well residency optimization. The blitter ring
is currently being used just for the command streamer based flip calls.
For pure 3D workloads, with MMIO flips, there will be no use of bli
On Thu, Jan 09, 2014 at 10:58:35AM +0100, Daniel Vetter wrote:
> On Thu, Jan 09, 2014 at 09:45:21AM +, Chris Wilson wrote:
> > On Thu, Jan 09, 2014 at 11:00:17AM +0530, akash.g...@intel.com wrote:
> > > From: Akash Goel
> > >
> > > The 'offset' field of the 'scatterlist' structure was wrongly
On Thu, Jan 09, 2014 at 09:45:21AM +, Chris Wilson wrote:
> On Thu, Jan 09, 2014 at 11:00:17AM +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
> >
> > The 'offset' field of the 'scatterlist' structure was wrongly
> > programmed with the offset value from the base of stolen area,
> > w
Sorry we have never received the i915_gem_exec.c file .
Please share that, we don't see it in the drm-intel-next also.
Best Regards
Akash
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, January 09, 2014 3:16 PM
To: Goel, Akash
Cc: intel-gfx@lists
On Thu, Jan 09, 2014 at 11:01:02AM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> On VLV, 64MB of system memory was being reserved for stolen
> area, but ~8MB of it was being utilized.
> Increased the utilization of Stolen area by allocating
> User created Frame buffers(only X Tiled) f
On Thu, Jan 09, 2014 at 11:01:56AM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
Did I not ever send i915_gem_exec.c which does this correctly?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@li
On Thu, Jan 09, 2014 at 11:00:17AM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> The 'offset' field of the 'scatterlist' structure was wrongly
> programmed with the offset value from the base of stolen area,
> whereas this field indicates the offset from where the interested
> data st
Re-adding mailing-lists so everyone can learn.
On Thu, Jan 9, 2014 at 9:49 AM, Goel, Akash wrote:
> Then at last I did the following :-
> 1. git format-patch -7 --cover-letter
> 2. git send-email -identity=otc-external -cover-letter.patch
> 3. git send-email -identity=otc-external
> 0001-drm
Hi Akash, please check your git sendemail.thread configuration (or
format.thread for format-patch) to make the patches in-reply-to the
cover letter.
Thanks,
Jani.
On Thu, 09 Jan 2014, akash.g...@intel.com wrote:
> From: Akash Goel
>
> These patches are mainly for increasing the utilization
> o
47 matches
Mail list logo
