On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote:
>
> On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote:
> > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
> >> Taking rotation into account while checking the plane
> >> and adjusting the sizes accordingly.
> >>
> >> Si
On 12/12/2014 1:03 PM, Singh, Gaurav K wrote:
On 12/10/2014 7:38 PM, Gaurav K Singh wrote:
For CHT changes are required for calculating the correct m,n & p with
minimal error +/- for the required DSI clock, so that the correct
dividor
& ctrl values are written in cck regs for DSI. This patch
We do exactly like this for sprite plane (ie, rotate the rect, then check
scaling and adjust the size accordingly from drm_rect_calc_hscale_relaxed)
That's why I saw the need of this for primary plane as well.
For sprite plane 90 rotation, intel_check_sprite_plane does the adjustments and
the ro
Since we do drm_rect_rotate with 90 rotation, the src->w changes to src->h.
Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser than
the min_hscale (which is no_scaling by default), so it returns -ERANGE.
So, I think we _relaxed is the function which should be called to update
On 12/15/2014 01:06 PM, Daniel Vetter wrote:
On Thu, Dec 11, 2014 at 03:41:34PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Eliminate six needless spin lock/unlock pairs when writing ELSP.
RFC for now with some #define copy and paste.
Signed-off-by: Tvrtko Ursulin
Cc: Dave Gordon
On Tue, 13 Jan 2015, Ander Conselvan de Oliveira
wrote:
> If QUIRK_PIPEA_FORCE is necessary, intel_sanitize_crtc() might trigger
> a mode set. In that case, if pipe A is disabled and pipe B is mapped to
> plane B, that mode set happens before the mapping is fixed. Due to the
> wrong state, the ca
On 01/14/2015 12:47 PM, Jani Nikula wrote:
On Tue, 13 Jan 2015, Ander Conselvan de Oliveira
wrote:
If QUIRK_PIPEA_FORCE is necessary, intel_sanitize_crtc() might trigger
a mode set. In that case, if pipe A is disabled and pipe B is mapped to
plane B, that mode set happens before the mapping is
On Wed, Jan 14, 2015 at 12:50:46PM +0200, Ander Conselvan de Oliveira wrote:
> On 01/14/2015 12:47 PM, Jani Nikula wrote:
> >On Tue, 13 Jan 2015, Ander Conselvan de Oliveira
> > wrote:
> >>If QUIRK_PIPEA_FORCE is necessary, intel_sanitize_crtc() might trigger
> >>a mode set. In that case, if pipe
On Wed, 14 Jan 2015, Ander Conselvan de Oliveira wrote:
> On 01/14/2015 12:47 PM, Jani Nikula wrote:
>> On Tue, 13 Jan 2015, Ander Conselvan de Oliveira
>> wrote:
>>> If QUIRK_PIPEA_FORCE is necessary, intel_sanitize_crtc() might trigger
>>> a mode set. In that case, if pipe A is disabled and pi
Currently, the command parser tries to create a secondary batch exactly
as large as the original, and vmap both. This is open to abuse by
userspace using extremely large batch objects, but only executing very
short batches. For example, this would be if userspace were to implement
a command submiss
Move the madvise logic out of the execbuffer main path into the
relatively rare allocation path, making the execbuffer manipulation less
fragile.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 12 +++-
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 31
If the batch buffer is too large to fit into the aperture and we need a
GTT mapping for relocations, we currently fail. This only applies to a
subset of machines for a subset of environments, quite undesirable. We
can simply check after failing to insert the batch into the GTT as to
whether we only
An interesting bug occurs on Pineview through which the root cause is
that the writes of the PTE values into the GTT is not serialised with
subsequent memory access through the GTT. This is despite there being a
posting read after the GTT update. However, by changing the address of
the posting read
The biggest user of i915_gem_object_get_page() is the relocation
processing during execbuffer. Typically userspace passes in a set of
relocations in sorted order. Sadly, we alternate between relocations
increasing from the start of the buffers, and relocations decreasing
from the end. However the m
On Wed, Jan 14, 2015 at 09:49:36AM +, Jindal, Sonika wrote:
> Since we do drm_rect_rotate with 90 rotation, the src->w changes to src->h.
> Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser than
> the min_hscale (which is no_scaling by default), so it returns -ERANGE.
If
I think I am confused here..
Since sprite plane handles this scaling and rotation in kernel, I thought it
should be taken care in driver for primary as well.
From the test, I don't really change the src sizes for primary as well as
sprite to take care of 90/270 rotation.
-Original Message---
Hi,
On 12/03/2014 07:49 PM, Jesse Barnes wrote:
From: Maarten Lankhorst
This allows users of dma fences to create a android fence.
I couldn't figure out the motivation here vs. just exporting
sync_fence_create ?
Regards,
Tvrtko
Cc: Daniel Vetter
Cc: Jesse Barnes
Signed-off-by: Maart
Hey,
On 14-01-15 15:09, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 12/03/2014 07:49 PM, Jesse Barnes wrote:
>> From: Maarten Lankhorst
>>
>> This allows users of dma fences to create a android fence.
>
> I couldn't figure out the motivation here vs. just exporting
> sync_fence_create ?
Keeping the
On Wed, Jan 14, 2015 at 11:10:54AM +0530, Sonika Jindal wrote:
> Taking rotation into account while checking the plane
> and adjusting the sizes accordingly.
>
> v2: Adding parameter in the callers in the same patch(Matt)
> Removing unnecessary code and allowing scaling(Ville)
>
> Signed-off-
On Tue, Jan 13, 2015 at 02:36:56PM -0800, Ben Widawsky wrote:
> On Tue, Jan 13, 2015 at 09:19:04PM +, O'Rourke, Tom wrote:
> > >Sent: Sunday, January 11, 2015 7:48 PM
> > >To: Widawsky, Benjamin
> > >Cc: Intel GFX
> > >Subject: Re: [Intel-gfx] [PATCH] [v2] intel_frequency: A tool to
> > >manip
On Wed, Jan 14, 2015 at 01:54:06PM +, Jindal, Sonika wrote:
> I think I am confused here..
> Since sprite plane handles this scaling and rotation in kernel, I thought it
> should be taken care in driver for primary as well.
Well, userspace still has to know how the src and dst coordinates rel
On Tue, Jan 13, 2015 at 01:32:52PM +, Chris Wilson wrote:
> Currently we are hitting the WARN inside
> i915_gem_object_set_cache_level() as we can now have an unbound object
> in the GTT write domain (due to 43566dedde54f9 "drm/i915: Broaden
> application of set-domain(GTT)"). To avoid the warn
This (partially) reverts
commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
Author: Chris Wilson
Date: Tue Mar 25 13:23:06 2014 +
drm/i915: Invalidate our pages under memory pressure
It appears given the right workload, that pages which are swapped out
more than once are incorrectly inva
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5581
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 353/353
The core fix was applied in
commit a63b03e2d2477586440741677ecac45bcf28d7b1
Author: Chris Wilson
Date: Tue Jan 6 10:29:35 2015 +
mutex: Always clear owner field upon mutex_unlock()
(note the absence of stable@ tag)
so we can now revert our band-aid commit 226e5ae9e5f910 for -next.
S
Sure, please ignore this patch for now...
Also this one was a wrong version without a needed parenthesis on
transmitter line, so it was actually disabling PSR on CHV.
On Tue, Jan 13, 2015 at 6:46 AM, R, Durgadoss wrote:
>>-Original Message-
>>From: Intel-gfx [mailto:intel-gfx-boun...@lis
On Wed, Jan 14, 2015 at 09:42:24AM -0800, O'Rourke, Tom wrote:
> On Tue, Jan 13, 2015 at 02:36:56PM -0800, Ben Widawsky wrote:
> > On Tue, Jan 13, 2015 at 09:19:04PM +, O'Rourke, Tom wrote:
> > > >Sent: Sunday, January 11, 2015 7:48 PM
> > > >To: Widawsky, Benjamin
> > > >Cc: Intel GFX
> > > >S
On Wed, Jan 14, 2015 at 08:34:31PM +, Chris Wilson wrote:
> This (partially) reverts
>
> commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
> Author: Chris Wilson
> Date: Tue Mar 25 13:23:06 2014 +
>
> drm/i915: Invalidate our pages under memory pressure
>
> It appears given the right w
On Mon, Jan 12, 2015 at 10:14:36AM -0800, Rodrigo Vivi wrote:
> This will be useful for automated test to know for how long to wait for PSR
> to comeback before time out.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
> drivers/gpu/drm/i915/i915_drv.h | 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/14/2015 04:55 PM, Daniel Vetter wrote:
> On Wed, Jan 14, 2015 at 08:34:31PM +, Chris Wilson wrote:
>> This (partially) reverts
>>
>> commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd Author: Chris
>> Wilson Date: Tue Mar 25 13:23:06
>> 20
From: Libin Yang
This patch adds the details dump for audio registers of Cherryview.
Signed-off-by: Libin Yang
---
tools/intel_audio_dump.c | 50
1 file changed, 50 insertions(+)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
So, if we do the source and dst adjustments in userspace, the logic in
intel_check_sprite_plane will not hold good there.
That's how it gets right coordinates and w,h for sprite for 90 rotation.
I thought drm_rect_rotate and other functions are there to handle such
scenarios.
-Original Messa
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5582
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
+ commenters of v1~v3
Thanks,
Yao
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Sean V Kelley
> Sent: Thursday, January 8, 2015 8:35
> To: Intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [RFC PATCH v
+ commenters of v1~v3
Thanks,
Yao
> -Original Message-
> From: Sean V Kelley [mailto:sea...@posteo.de]
> Sent: Thursday, January 8, 2015 8:35
> To: Intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Cheng, Yao; Sean V Kelley
> Subject: [RFC PATCH V4 1/4] drm/i915: add
+ commenters on v1~v3
When locking issue resolved, this patch can be removed.
Thanks,
Yao
> -Original Message-
> From: Sean V Kelley [mailto:sea...@posteo.de]
> Sent: Thursday, January 8, 2015 8:35
> To: Intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Cheng, Yao; S
+ commenters of v1~v3
Thanks,
Yao
> -Original Message-
> From: Sean V Kelley [mailto:sea...@posteo.de]
> Sent: Thursday, January 8, 2015 8:35
> To: Intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Cheng, Yao; Sean V Kelley
> Subject: [RFC PATCH v4 3/4] ipvr: user mod
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5578
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 353/353
On Wed, 14 Jan 2015, Chris Wilson wrote:
> The core fix was applied in
>
> commit a63b03e2d2477586440741677ecac45bcf28d7b1
> Author: Chris Wilson
> Date: Tue Jan 6 10:29:35 2015 +
>
> mutex: Always clear owner field upon mutex_unlock()
>
> (note the absence of stable@ tag)
>
> so we can
Hello Daniel and other maintainers,
While I'm working on drm memory allocator with myself, I've encountered render
ring hang.
And I am noticed that I can diagnose the command streamer's status with the
following registers:
INSTPS: 0x2070
CSCMDOP: 0x220c
CSCMDVLD: 0x2210
INSTDONE_1: 206C
I can
40 matches
Mail list logo
