On Wed, Mar 19, 2014 at 01:45:46PM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
Any clue how you intend to use this for a commit message (I'm actually
curious)? Also, the subject is wrong, you're counting size, not
quantity. Anyhoo, looks correct.
Reviewed-by: Ben Widawsky
> ---
>
On Mon, Mar 17, 2014 at 07:43:35PM +, Rob Bradford wrote:
> From: Rob Bradford
>
> This test has the following subtests:
> - test_correct for correctness of the data
> - test_map_unmap checks for mapping idempotency
> - test_reprime checks for dma-buf creation idempotency
> - test_forked chec
Programming it outside of the rp0-rp1 range is considered a programming
error. Since we do not know that the previous value would actually be in
the range, program something we've read from the hardware, and therefore
know will work.
This is potentially an issue for platforms whose ranges are outs
With the renamed RPS struct members, it's easier to skip the local
variables which no longer clarify anything, and if anything just make
the code harder to read.
The real motivation for this patch is actually the next patch, which
attempts to consolidate some of the functionality.
Cc: Jeff McGee
The names of the struct members for RPS are stupid. Every time I need to
do anything in this code I have to spend a significant amount of time to
remember what it all means. By renaming the variables (and adding the
comments) I hope to clear up the situation. Indeed doing this make some
upcoming pa
this leaves a temporarily awkward min_delay (the soft limit) with the
new min_freq (the hardware limit). It's fixed in the next patch.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
d
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ab9e992..9486396 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++
The existing code (which I changed last) was very convoluted. I believe
it was attempting to skip the overclock portion if the previous pcode
write failed. When I last touched the code, I was preserving this
behavior. There is some benefit to doing it that way in that if the
first pcode access fail
It is tested and looking fairly stable now, so turn it on. It wasn't
intentionally turned off originally :P
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm
Ben Widawsky (12):
drm/i915: Reorganize the overclock code
drm/i915: Fix coding style for RPS
drm/i915: Store the HW min frequency as min_freq
drm/i915: Rename and comment all the RPS *stuff*
drm/i915: Remove extraneous MMIO for RPS
drm/i915: remove rps local variables
drm/i915/bdw:
Introduced:
commit b8a5ff8d7c676a04e0da5ec16bb068dd39459042
Author: Jeff McGee
Date: Tue Feb 4 11:37:01 2014 -0600
drm/i915: Update rps interrupt limits
Cc: Jeff McGee
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_sysfs.c | 20 ++--
1 file changed, 10 inserti
RC6 works a lot like HW contexts in that when the GPU enters RC6 it
saves away the state to a context, and loads it upon wake.
It's to be somewhat expected that BIOS will not set up valid GPU state.
As a result, if loading bad state can cause the GPU to get angry, it
would make sense then that we
The values created at initialization must always exist to use the
interface. Reading them again is confusing, and pointless.
More cleanups are coming in the next patch. Since I am not 100% certain,
moreover on BYT, (though I am extremely close to that) that there is no
need to leave the MMIO here,
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.
The patch is mostly a copy-paste of the existing snb+ code, with updates
to the relevant parts requiring changes to the
We have a need for duplicated parsing of the RP_STATE_CAPS register (and
the setting of the associated fields). To reuse some code, we can
extract the function into a simple helper.
This patch also addresses the fact that we missed doing this for gen8,
something we should have done anyway.
This c
On Tue, Mar 04, 2014 at 03:30:14PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2014 at 10:27:20PM -0800, Ben Widawsky wrote:
> > RC6 works a lot like HW contexts in that when the GPU enters RC6 it
> > saves away the state to a context, and loads it upon wake.
> >
> > It's to be somewhat expected
On Wed, Mar 19, 2014 at 09:54:48PM +, Chris Wilson wrote:
> As Broadwell has an increased virtual address size, it requires more
> than 32 bits to store offsets into its address space. This includes the
> debug registers to track the current HEAD of the individual rings, which
> may be anywhere
As Broadwell has an increased virtual address size, it requires more
than 32 bits to store offsets into its address space. This includes the
debug registers to track the current HEAD of the individual rings, which
may be anywhere within the per-process address spaces. In order to find
the full loca
On Tue, 2014-03-18 at 14:59 +0200, Jani Nikula wrote:
> From: Chris Wilson
>
> 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
> ap
On Wed, Mar 19, 2014 at 09:28:32AM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 11:20:09AM -0700, Ben Widawsky wrote:
> > On Fri, Mar 07, 2014 at 08:10:24PM -0300, Paulo Zanoni wrote:
> > > From: Paulo Zanoni
> > >
> > > Instead of trying to clear it again. It should already be masked an
On Wed, Mar 19, 2014 at 09:36:04AM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 01:53:53PM -0700, Ben Widawsky wrote:
> > On Fri, Mar 07, 2014 at 08:10:16PM -0300, Paulo Zanoni wrote:
> > > From: Paulo Zanoni
> > >
> > > Hi
> > >
> > > This is basically a rebase of "[PATCH 00/19] ILK+ i
On Wed, Mar 19, 2014 at 01:45:45PM +, Chris Wilson wrote:
> The idea of printing objects used by each process is to judge how each
> process is using them. This means that we need to evaluate whether the
> object is bound for that particular process, rather than just whether it
> is bound into
On Wed, Mar 19, 2014 at 05:07:53PM +0200, Imre Deak wrote:
> On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Currently, when our driver becomes idle for i915.pc8_timeout (default:
> > 5s) we enable PC8, so we save some power, but not everything we can.
> > Th
On Wed, 19 Mar 2014, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 01:53:56PM -0700, Siva Chandra wrote:
>> On Tue, Mar 18, 2014 at 1:06 PM, Jesse Barnes
>> wrote:
>> > On Tue, 18 Mar 2014 12:51:07 -0700
>> > Siva Chandra wrote:
>> >
>> >> This property helps one turn PSR "on" and "off" via xr
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because we merged the PC8 and runtime PM features, so calling
> intel_runtime_pm_get now has the same meaning, and we plan to just
> remove hsw_disable_package_c8 for this exact reason.
>
> My first patch tried to co
On Wed, Mar 19, 2014 at 4:05 PM, Chris Wilson wrote:
> On Tue, Mar 18, 2014 at 10:26:04AM +0100, Daniel Vetter wrote:
>> Extract all this logic into a new helper function
>> semaphore_wait_to_signaller_ring because:
>>
>> - The current code has way too much magic.
>>
>> - The current code doesn't
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 do
On Sat, Mar 08, 2014 at 01:51:18PM +0530, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> This patch enables property for changin the pixel format
> of plane to enable/disable pre-multiplied alpha format.
> Client has to set BIT(DRM_BLEND_PREMULTIPLIED_ALPHA) | 0x0/0x1
> to disable/enabl
On Fri, 2014-03-07 at 20:08 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Currently, when our driver becomes idle for i915.pc8_timeout (default:
> 5s) we enable PC8, so we save some power, but not everything we can.
> Then, while PC8 is enabled, if we stay idle for more
> autosuspend_delay_
On Wed, Mar 19, 2014 at 09:44:38AM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 01:53:56PM -0700, Siva Chandra wrote:
> > On Tue, Mar 18, 2014 at 1:06 PM, Jesse Barnes
> > wrote:
> > > On Tue, 18 Mar 2014 12:51:07 -0700
> > > Siva Chandra wrote:
> > >
> > >> This property helps one turn
On Tue, Mar 18, 2014 at 10:26:04AM +0100, Daniel Vetter wrote:
> Extract all this logic into a new helper function
> semaphore_wait_to_signaller_ring because:
>
> - The current code has way too much magic.
>
> - The current code doesn't look at bi16, which encodes VECS signallers
> on HSW. Thos
Hi Dave -
Two additional fixes on top of my last pull as promised, one for a 3.14
specific regression, one cc: stable.
This clears up my backlog, at least of anything non-controversial.
BR,
Jani.
The following changes since commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b:
drm/i915: Don't e
On Wed, Mar 19, 2014 at 01:11:26PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote:
> > Intel hardware allows the primary plane to be disabled independently of
> > the CRTC. Provide custom primary plane handling to allow this.
> >
> > Cc: Intel Graphics De
On its own, "git push origin" will do something different depending on
the the push.default option. So let's speficy the full local:remote
branch here.
Signed-off-by: Damien Lespiau
---
qf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qf b/qf
index 9838ffc..2e856b5 100755
-
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4e1787ee8f37..9cc1c9360238 100644
--- a/drivers/gpu/drm/i915/i915_deb
The idea of printing objects used by each process is to judge how each
process is using them. This means that we need to evaluate whether the
object is bound for that particular process, rather than just whether it
is bound into the global GTT.
v2: Restore the non-full-ppgtt path for simplicity as
On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote:
> Intel hardware allows the primary plane to be disabled independently of
> the CRTC. Provide custom primary plane handling to allow this.
>
> Cc: Intel Graphics Development
> Signed-off-by: Matt Roper
Overall this is imo a new featur
On Tue, Mar 18, 2014 at 05:22:55PM -0700, Matt Roper wrote:
> 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
From: Tvrtko Ursulin
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized and synchronized userptr
From: Tvrtko Ursulin
No need for the old test case once the new one was added.
Signed-off-by: Tvrtko Ursulin
---
tests/.gitignore | 1 -
tests/Makefile.sources | 1 -
tests/gem_vmap_blits.c | 344 -
3 files changed, 346 deletions(-)
de
From: Tvrtko Ursulin
This patch series replaces the old vmap with the new userptr test case
and also adds a benchmark for the new feature.
Tested against version 21 of the kernel patch.
Tvrtko Ursulin (3):
tests/gem_userptr_blits: Expanded userptr test cases
tests/gem_vmap_blits: Remove obs
From: Tvrtko Ursulin
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers on common address space
operati
On Wed, Mar 19, 2014 at 03:31:41AM +, Chang, Junxiao wrote:
> Reviewed-by: Junxiao Chang
Queued for -next, thanks for the patch&review.
-Daniel
>
> Thanks,
> Junxiao
>
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Wednesday, March 19, 2014 10:32 AM
> T
On Tue, 18 Mar 2014, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:48:28PM +0100, Daniel Vetter wrote:
>> On Tue, Mar 18, 2014 at 02:59:04PM +0200, Jani Nikula wrote:
>> > From: Chris Wilson
>> >
>> > We have reports of heavy screen corruption if we try to use the stolen
>> > memory reserved
On Wed, Mar 19, 2014 at 10:39:03AM +0200, Timo Aaltonen wrote:
> On 19.03.2014 01:09, Ben Widawsky wrote:
> > Apparently it is wiped out from under us, and we get some really fun
> > caching artifacts upon resume (it seems to be WB for all types by
> > default).
> >
> > Reported-by: James Ausmus
On Tue, Mar 18, 2014 at 01:53:56PM -0700, Siva Chandra wrote:
> On Tue, Mar 18, 2014 at 1:06 PM, Jesse Barnes
> wrote:
> > On Tue, 18 Mar 2014 12:51:07 -0700
> > Siva Chandra wrote:
> >
> >> This property helps one turn PSR "on" and "off" via xrandr.
> >> The default value is same as that of the
On 19.03.2014 01:09, Ben Widawsky wrote:
> Apparently it is wiped out from under us, and we get some really fun
> caching artifacts upon resume (it seems to be WB for all types by
> default).
>
> Reported-by: James Ausmus
> Signed-off-by: Ben Widawsky
Excellent!
Bugzilla: https://bugs.freedesk
On Tue, Mar 18, 2014 at 01:53:53PM -0700, Ben Widawsky wrote:
> On Fri, Mar 07, 2014 at 08:10:16PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Hi
> >
> > This is basically a rebase of "[PATCH 00/19] ILK+ interrupt improvements",
> > which
> > was sent to the mailing list on Januar
On Tue, Mar 18, 2014 at 11:20:09AM -0700, Ben Widawsky wrote:
> On Fri, Mar 07, 2014 at 08:10:24PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Instead of trying to clear it again. It should already be masked and
> > disabled and zeroed at preinstall/uninstall.
> >
> > Signed-off-by
On Tue, Mar 18, 2014 at 05:22:58PM -0700, Matt Roper wrote:
> Legacy cursor ioctls took GEM buffer handles from userspace directly
> whereas the new unified plane handling assigns drm_framebuffer's to
> cursor planes. Splitting the code that actually updates the cursor
> plane from the code that h
On Wed, Mar 19, 2014 at 8:26 AM, Chris Wilson wrote:
> On Tue, Mar 18, 2014 at 05:41:54PM -0700, Ben Widawsky wrote:
>> On Tue, Mar 18, 2014 at 04:31:03PM +0100, Daniel Vetter wrote:
>> > This is a regression introduced in
>> >
>> > commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd
>> > Author: Chri
On Tue, Mar 18, 2014 at 05:41:54PM -0700, Ben Widawsky wrote:
> On Tue, Mar 18, 2014 at 04:31:03PM +0100, Daniel Vetter wrote:
> > This is a regression introduced in
> >
> > commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd
> > Author: Chris Wilson
> > Date: Thu Mar 13 12:00:29 2014 +
> >
>
On Wed, Mar 19, 2014 at 2:54 AM, Ben Widawsky wrote:
> On Tue, Mar 18, 2014 at 09:18:42PM -0400, Steven Rostedt wrote:
>> On Wed, 19 Mar 2014 11:53:50 +1100
>> Stephen Rothwell wrote:
>>
>>
>> > Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers
>> > from ring buffer in evict e
On Wed, Mar 19, 2014 at 1:41 AM, Ben Widawsky
wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index e4d2b9f15ae2..9faee49f210d 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1608,8 +1608,6 @@ int i915_
54 matches
Mail list logo
