On Tue, Jun 30, 2015 at 7:13 AM, Thomas Daniel wrote:
> From: Chris Wilson
>
> Userspace can pass in an offset that it presumes the object is located
> at. The kernel will then do its utmost to fit the object into that
> location. The assumption is that userspace is handling its own object
> loca
Hi Linus,
Since Dave is enjoying vacation I figured I'll send you this drm core fix
directly.
Cheers, Daniel
The following changes since commit 8b72ce158cf0dba443e36fc66e0bb29c2580e0b6:
drm: Always enable atomic API (2015-06-24 11:21:35 +1000)
are available in the git repository at:
git:
On Fri, Jul 03, 2015 at 03:40:54PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now all the functions called by other files check whether FBC has been
> initialized. This allows us to drop the checks on the static
> functions.
>
> v2:
> - s/HAS_FBC/dev_priv->display.enable_fbc/ everywher
From: Paulo Zanoni
Now all the functions called by other files check whether FBC has been
initialized. This allows us to drop the checks on the static
functions.
v2:
- s/HAS_FBC/dev_priv->display.enable_fbc/ everywhere but the init
function (Chris).
Suggested-by: Chris Wilson
Signed-off-by
On Fri, Jul 03, 2015 at 02:59:28PM -0300, Paulo Zanoni wrote:
> 2015-07-03 12:56 GMT-03:00 Chris Wilson :
> > On Thu, Jul 02, 2015 at 07:25:14PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> Now all the functions called by other files have the HAS_FBC
> >> protection. This allows us
2015-07-03 12:56 GMT-03:00 Chris Wilson :
> On Thu, Jul 02, 2015 at 07:25:14PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Now all the functions called by other files have the HAS_FBC
>> protection. This allows us to drop the checks for the low level
>> function pointers.
>>
>> Suggeste
On 03/07/2015 12:15, Mika Kuoppala wrote:
Tomas Elf writes:
This patch series introduces the following features:
* Feature 1: TDR (Timeout Detection and Recovery) for gen8 execlist mode.
TDR is an umbrella term for anything that goes into detecting and recovering
from GPU hangs and is a term
On 03/07/2015 17:57, Chris Wilson wrote:
On Fri, Jul 03, 2015 at 05:53:38PM +0100, Arun Siluvery wrote:
This patch only enables support for Gen9, the actual WA will be
initialized in subsequent patches.
The WARN that we use to warn user if WA batch support is not available
for a particular Gen
On Fri, Jul 03, 2015 at 05:53:38PM +0100, Arun Siluvery wrote:
> This patch only enables support for Gen9, the actual WA will be
> initialized in subsequent patches.
>
> The WARN that we use to warn user if WA batch support is not available
> for a particular Gen is replaced with DRM_ERROR as warn
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
Cc: Imre Deak
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/dr
In Indirect context w/a batch buffer,
+WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
Cc: Imre Deak
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c| 9 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +--
2 files changed, 14 insertions(+), 2 deletions(
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
Cc: Imre Deak
Signed-off-by: Arun Siluvery
---
This patch depends on https://patchwork.kernel.org/patch/6715321/, which is
already reviewed by Chris, temporary dependency untill it gets merged.
drivers/gpu/d
This patch only enables support for Gen9, the actual WA will be
initialized in subsequent patches.
The WARN that we use to warn user if WA batch support is not available
for a particular Gen is replaced with DRM_ERROR as warning here doesn't
really add much value.
Cc: Imre Deak
Signed-off-by: Ar
2015-07-03 6:23 GMT-03:00 Dave Gordon :
> On 01/07/15 14:02, Daniel Vetter wrote:
>>
>> On Tue, Jun 30, 2015 at 11:14:54AM -0300, Paulo Zanoni wrote:
>>>
>>> 2015-06-30 10:54 GMT-03:00 Chris Wilson :
On Tue, Jun 30, 2015 at 02:41:09PM +0100, Michel Thierry wrote:
>
> @@ -1109,7 +1
Hi all,
Updated -testing with new stuff:
- dsi improvements (Gaurav)
- bxt ddi dpll hw state readout (Imre)
- chv dvfs support and overall wm improvements for both vlv and chv (Ville)
- ppgtt polish from Mika and Michel
- cdclk support for bxt (Bob Pauwe)
- make frontbuffer tracking more precise
-
On Fri, Jul 03, 2015 at 04:56:31PM +0100, Chris Wilson wrote:
> On Thu, Jul 02, 2015 at 07:25:14PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Now all the functions called by other files have the HAS_FBC
> > protection. This allows us to drop the checks for the low level
> > functio
On Thu, Jul 02, 2015 at 07:25:08PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> With the abstractions created by the last patch, we can move this code
> and the only thing inside intel_fbc.c that knows about dev_priv->mm is
> the code that reads stolen_base.
>
> We also had to move a call
On Thu, Jul 02, 2015 at 07:25:07PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to move the FBC code out of i915_gem_stolen.c, but that code
> directly adds/removes stolen memory nodes. Let's create this
> abstraction, so i915_gme_stolen.c is still in control of all the
> stolen me
On Thu, Jul 02, 2015 at 07:25:09PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Which should protect dev_priv->mm.stolen usage. This will allow us to
> simplify the relationship between stolen memory, FBC and struct_mutex.
>
> v2:
> - Rebase after the stolen_remove_node() dev_priv patch
On Thu, Jul 02, 2015 at 07:25:14PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now all the functions called by other files have the HAS_FBC
> protection. This allows us to drop the checks for the low level
> function pointers.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Paulo Zanoni
On Fri, Jul 03, 2015 at 06:37:59PM +0300, Antti Koskipää wrote:
> >> @@ -239,8 +243,13 @@ struct common_child_dev_config {
> >> u8 not_common2[2];
> >> u8 ddc_pin;
> >> u16 edid_ptr;
> >> + u8 obsolete;
> >> + u8 flags_1;
> >> + u8 not_common3[13];
> >> +
On Fri, Jul 03, 2015 at 02:27:31PM +0100, Arun Siluvery wrote:
> In this WA we need to set GEN8_L3SQCREG4[21:21] and reset it after
> PIPE_CONTROL
> instruction but there is a slight complication as this is applied in WA batch
> where the values are only initialized once.
> Dave identified an issu
On Fri, Jul 03, 2015 at 05:09:31PM +0300, Mika Kuoppala wrote:
> Hi,
>
> Reader might think that I did this for only mark few elsps
> done deeper in callchain. But the reason is that I wanted
> to test more uniqueness guarantees for generation of context ids
> that is passed for hardware. And foun
On 07/03/2015 06:09 PM, Paulo Zanoni wrote:
> 2015-07-03 8:28 GMT-03:00 Antti Koskipaa :
>> An OEM may request increased I_boost beyond the recommended values
>> by specifying an I_boost value to be applied to all swing entries for
>> a port. These override values are specified in VBT.
>>
>> v2: re
On Fri, Jul 03, 2015 at 05:09:38PM +0300, Mika Kuoppala wrote:
> Now when we have requests this deep on call chain, we
> can mark the elsp being submitted when it actually is.
> While we are it, remove unnecessary temp assignment as
> it is already initialized as zero.
Bah, which I think is bad pr
On Fri, Jul 03, 2015 at 04:25:15PM +0100, Damien Lespiau wrote:
> On Fri, Jul 03, 2015 at 06:21:58PM +0300, Ville Syrjälä wrote:
> > > In the old VBT spec I have, each child_dev_config is supposed to have
> > > only 33 bytes. But in this patch you're increasing it to 38. I believe
> > > this is wha
From: Paulo Zanoni
drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_prepare_ddi’:
drivers/gpu/drm/i915/intel_ddi.c:517:6: warning:
‘ddi_translations_fdi’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (ddi_translations_fdi)
^
drivers/gpu/drm/i915/intel_ddi.c:44
On Fri, Jul 03, 2015 at 06:21:58PM +0300, Ville Syrjälä wrote:
> > In the old VBT spec I have, each child_dev_config is supposed to have
> > only 33 bytes. But in this patch you're increasing it to 38. I believe
> > this is what's causing the errors I see when I boot my BDW.
> >
> > Are you sure t
On Fri, Jul 03, 2015 at 12:09:43PM -0300, Paulo Zanoni wrote:
> 2015-07-03 8:28 GMT-03:00 Antti Koskipaa :
> > An OEM may request increased I_boost beyond the recommended values
> > by specifying an I_boost value to be applied to all swing entries for
> > a port. These override values are specified
2015-07-03 8:28 GMT-03:00 Antti Koskipaa :
> An OEM may request increased I_boost beyond the recommended values
> by specifying an I_boost value to be applied to all swing entries for
> a port. These override values are specified in VBT.
>
> v2: rebase and remove unused iboost_bit variable
>
> Issu
2015-07-03 5:22 GMT-03:00 :
> From: Ville Syrjälä
>
> Kill the extra intel_pre_plane_update() I accidentally added in
>
> commit 852eb00dc44ea2b8896e2fa27c6a36a1f697ba5a
> Author: Ville Syrjälä
> Date: Wed Jun 24 22:00:07 2015 +0300
>
> drm/i915: Try to make sure cxsr is disabled around
On Fri, Jul 03, 2015 at 05:09:34PM +0300, Mika Kuoppala wrote:
> In preparation to make intel_lr_context_pin|unpin to accept
> requests, assign ringbuf into request before we call the pinning.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 8 +---
> 1 file change
Now when we have requests this deep on call chain, we
can mark the elsp being submitted when it actually is.
While we are it, remove unnecessary temp assignment as
it is already initialized as zero.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 12 +---
1 file chang
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c3c029a..67ff4
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 8 +++-
drivers/gpu/drm/i915/intel_lrc.c | 31 +++
drivers/gpu/drm/i915/intel_lrc.h | 3 +--
3 files changed, 19 insertions(+), 23 dele
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36f8660
In preparation to make intel_lr_context_pin|unpin to accept
requests, assign ringbuf into request before we call the pinning.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_l
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
in
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
Hi,
Reader might think that I did this for only mark few elsps
done deeper in callchain. But the reason is that I wanted
to test more uniqueness guarantees for generation of context ids
that is passed for hardware. And found out that the current
code structure strips out all the request/context ve
In this WA we need to set GEN8_L3SQCREG4[21:21] and reset it after PIPE_CONTROL
instruction but there is a slight complication as this is applied in WA batch
where the values are only initialized once.
Dave identified an issue with the current implementation where the register
value
is read once a
On Fri, Jul 03, 2015 at 02:35:49PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 03, 2015 at 02:35:48PM +0300, Mika Kahola wrote:
> From EDID we can read and request higher pixel clock than
> our HW can support. This set of patches add checks if
> requested pixel clock is lower than the one supported by the HW.
> The requested mode is discarded if we cannot support
On Fri, Jul 03, 2015 at 02:35:54PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
On Fri, Jul 03, 2015 at 11:28:41AM +0100, Damien Lespiau wrote:
> On Fri, Jul 03, 2015 at 08:41:31AM +0200, Daniel Vetter wrote:
> > > Yeah. My first idea for the gamma stuff was that we'd simply have the
> > > blob property for the data, and then a separate enum property which
> > > decides how we
On Fri, Jul 03, 2015 at 02:35:51PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_debugfs.c | 40 +
1 file c
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index a8f48dd..479c97b 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/g
From: Alex Dai
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes
Turn on interrupt steering to route necessary interrupts to GuC.
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +
2 files changed, 60 inser
intel_guc_fwif.h contains the subset of the GuC interface that we
will need for submission of commands through the GuC. These MUST
be kept in sync with the definitions used by the GuC firmware, and
updates to this file will (or should) be autogenerated from the
source files used to build the firmwa
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use; doorbel
From: Alex Dai
Two new module parameters: "enable_guc_submission" which will turn
on submission of batchbuffers via the GuC (when implemented), and
"guc_log_level" which controls the level of debugging logged by the
GuC and captured by the host.
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordo
This patch series enables command submission via the GuC. In this mode,
instead of the host CPU driving the execlist port directly, it hands
over work items to the GuC, using a doorbell mechanism to tell the GuC
that new items have been added to its work queue. The GuC then dispatches
contexts to t
From: Alex Dai
Add overview design of GuC, plus some key points related to
the implementation.
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
Documentation/DocBook/drm.tmpl | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Docume
From: Alex Dai
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address that is NOT in the
From: Alex Dai
The new node provides access to the status of the common uC loader
code and the GuC-specific loader; also the scratch registers used
for communication between the i915 driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
Issue: VIZ-4884
Si
i915_gem_object_create_from_data() is a generic function to save data
from a plain linear buffer in a new pageable gem object that can later
be accessed by the CPU and/or GPU.
We will need this for the microcontroller firmware loading support code.
Derived from i915_gem_object_write(), originally
Current devices may contain one or more programmable microcontrollers
that need to have a firmware image (aka "binary blob") loaded from an
external medium and transferred to the device's memory.
This file provides common support functions for doing this; they can
then be used by each uC-specific
From: Alex Dai
This uses the common firmware loader to fetch the firmware image,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky. It has been reconstructed to accord
with the common firmwar
From: Alex Dai
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to prepare a context for submission via the
GuC, we need some of the same functions used in execlist mode.
This commit exposes two such functions,
An OEM may request increased I_boost beyond the recommended values
by specifying an I_boost value to be applied to all swing entries for
a port. These override values are specified in VBT.
v2: rebase and remove unused iboost_bit variable
Issue: VIZ-5676
Signed-off-by: Antti Koskipaa
---
drivers
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to SDVO.
Signe
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to HDMI.
Signe
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DVO.
Signed
From EDID we can read and request higher pixel clock than
our HW can support. This set of patches add checks if
requested pixel clock is lower than the one supported by the HW.
The requested mode is discarded if we cannot support the requested
pixel clock. For example for Cherryview
'cvt 2560 1600
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DSI.
Signed
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to LVDS.
Signe
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to TV.
Signed-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to CRT.
Signed
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort.
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort
On 07/02/2015 04:55 PM, Chris Wilson wrote:
> It would be nice if we could reuse one seqno both for internal/external
> fences. If you need to expose a fence ordering within a timeline that is
> based on the creation stamp rather than execution stamp, it seems like
> we could just add such a stamp
Tomas Elf writes:
> This patch series introduces the following features:
>
> * Feature 1: TDR (Timeout Detection and Recovery) for gen8 execlist mode.
>
> TDR is an umbrella term for anything that goes into detecting and recovering
> from GPU hangs and is a term more widely used outside of the up
Whilst discussing possible ways to trigger an invalidate_range on a
userptr with an aliased GGTT mmapping (and so cause a struct_mutex
deadlock), the conclusion is that we can, and we must, prevent any
possible deadlock by avoiding taking the mutex at all during
invalidate_range. This has numerous
On Wed, Jul 01, 2015 at 01:56:30PM +0100, Tvrtko Ursulin wrote:
> >@@ -562,12 +524,20 @@ __i915_gem_userptr_set_active(struct
> >drm_i915_gem_object *obj,
> > */
> > #if defined(CONFIG_MMU_NOTIFIER)
> > if (obj->userptr.mmu_object == NULL)
> >-return;
> >+return 0
On Fri, Jul 03, 2015 at 12:48:03PM +0200, Michał Winiarski wrote:
> On Tue, Jun 30, 2015 at 05:55:31PM +0100, Chris Wilson wrote:
> > The userptr worker allows for a slight race condition where upon there
> > may two or more threads calling get_user_pages for the same object. When
> > we have the a
Chris Wilson writes:
> On Sat, Jul 04, 2015 at 12:27:34AM +0800, bing@intel.com wrote:
>> From: "Niu,Bing"
>>
>> It is found that i915 will not reset gpu under execlist mode when
>> unload module. that will lead to some issues when unload/load module
>> with different submission mode. e.g.
On Tue, Jun 30, 2015 at 05:55:31PM +0100, Chris Wilson wrote:
> The userptr worker allows for a slight race condition where upon there
> may two or more threads calling get_user_pages for the same object. When
> we have the array of pages, then we serialise the update of the object.
> However, the
On Fri, Jul 03, 2015 at 08:41:31AM +0200, Daniel Vetter wrote:
> > Yeah. My first idea for the gamma stuff was that we'd simply have the
> > blob property for the data, and then a separate enum property which
> > decides how we interpret the blob contents. The default for the enum
> > would be the
On Thu, Jul 02, 2015 at 02:44:10PM -0700, Anuj Phogat wrote:
> In case of YF/YS tiled buffers libdrm need not know about the tiling
> format because these buffers don't have hardware support to be tiled
> or detiled through a fenced region. But, libdrm still need to know
> about buffer alignment re
On 07/01/2015 10:26 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This test validates the two parameters (size and flags) GEM_CREATE ioctl.
v2: Added IGT_TEST_DESCRIPTION (Thomas Wood)
Signed-off-by: Ankitprasad Sharma
---
tests/Makefile.sources | 1 +
tests/gem_c
On 07/03/2015 10:16 AM, Chris Wilson wrote:
On Fri, Jul 03, 2015 at 10:05:05AM +0100, Tvrtko Ursulin wrote:
+bool gem_create__has_stolen_support(int fd)
+{
+ static int has_stolen_support = -1;
+
+ if (has_stolen_support < 0) {
+ struct drm_i915_getparam gp;
+ int val =
On 07/01/2015 10:26 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support to verify pread/pwrite for non-shmem backed
objects. It also shows the pread/pwrite speed.
It also tests speeds for pread with and without user side page faults
v2: Rebased to the l
On 01/07/15 14:02, Daniel Vetter wrote:
On Tue, Jun 30, 2015 at 11:14:54AM -0300, Paulo Zanoni wrote:
2015-06-30 10:54 GMT-03:00 Chris Wilson :
On Tue, Jun 30, 2015 at 02:41:09PM +0100, Michel Thierry wrote:
@@ -1109,7 +1109,7 @@ static void setup_sink_crc(void)
set_mode_for_params(&pri
On Fri, Jul 03, 2015 at 10:05:05AM +0100, Tvrtko Ursulin wrote:
> >+bool gem_create__has_stolen_support(int fd)
> >+{
> >+static int has_stolen_support = -1;
> >+
> >+if (has_stolen_support < 0) {
> >+struct drm_i915_getparam gp;
> >+int val = -1;
> >+memset(&gp, 0, siz
On 07/01/2015 10:26 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds the testcases for verifying the new extended
gem_create ioctl. By means of this extended ioctl, memory
placement of the GEM object can be specified, i.e. either
shmem or stolen memory.
These
On Sat, Jul 04, 2015 at 12:27:34AM +0800, bing@intel.com wrote:
> From: "Niu,Bing"
>
> It is found that i915 will not reset gpu under execlist mode when
> unload module. that will lead to some issues when unload/load module
> with different submission mode. e.g. from execlist mode to ring
> b
On Fri, 03 Jul 2015, "Malladi, Kausal" wrote:
> On Friday 03 July 2015 01:33 PM, Jani Nikula wrote:
>> I didn't get the series at all, and it's not in the moderation queue
>> either. The same happened to the last series from Kausal. What gives?
>>
>> BR,
>> Jani.
> Yesterday I realized what was th
On Fri, 03 Jul 2015, Raymond Yau wrote:
> 2015-6-29 下午3:58於 "Jani Nikula" 寫道：
>>
>> On Sat, 27 Jun 2015, Raymond Yau wrote:
>> >> > >
>> >> > > Shall we move or cc this discussion on audio driver side to ALSA
> ML?
>> >> >
>> >> > Oops I thought I had cc'ed these patches to alsa-devel as well whe
Kausal
On Friday 03 July 2015 01:33 PM, Jani Nikula wrote:
On Thu, 02 Jul 2015, Damien Lespiau wrote:
On Wed, Jul 01, 2015 at 09:18:19PM +0530, Kausal Malladi wrote:
From: Kausal Malladi
I didn't get the series at all, and it's not in the moderation queue
either. The same happened to the l
From: Ville Syrjälä
Kill the extra intel_pre_plane_update() I accidentally added in
commit 852eb00dc44ea2b8896e2fa27c6a36a1f697ba5a
Author: Ville Syrjälä
Date: Wed Jun 24 22:00:07 2015 +0300
drm/i915: Try to make sure cxsr is disabled around plane
enable/disable
This fixes a load
From: "Niu,Bing"
It is found that i915 will not reset gpu under execlist mode when
unload module. that will lead to some issues when unload/load module
with different submission mode. e.g. from execlist mode to ring
buffer mode via loading/unloading i915. Because HW is not in a reset
state and re
On Thu, 02 Jul 2015, Damien Lespiau wrote:
> On Wed, Jul 01, 2015 at 09:18:19PM +0530, Kausal Malladi wrote:
>> From: Kausal Malladi
I didn't get the series at all, and it's not in the moderation queue
either. The same happened to the last series from Kausal. What gives?
BR,
Jani.
>>
>> CHV/
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6698
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Thursday, July 2, 2015, Daniel Vetter wrote:
> Transitional drivers might not have all the state frobbing lined up
> yet. But since the initial code has been merged a lot more state was
> added, so we really need this.
>
> Cc: Daniel Stone >
> Signed-off-by: Daniel Vetter >
>
Reviewed-by: Dan
On Thu, Jul 02, 2015 at 04:41:32PM +, Vivi, Rodrigo wrote:
> On Thu, 2015-07-02 at 13:03 -0300, Paulo Zanoni wrote:
> > 2015-06-30 20:42 GMT-03:00 Rodrigo Vivi :
> > > Let's do a frontbuffer invalidation on dirty fb.
> > > To be used for DIRTYFB drm ioctl.
> > >
> > > This patch solves the bigg
98 matches
Mail list logo
