Hi Guys:
I'm trying to make GVT-g as a sub-module of i915 in the next version
patchset. The basic idea is to introduce a "gvt-g pre-enabled state" in i915. I
think it should be a kernel option.
When this kernel option is enabled by user, i915 will do GGTT partition and
save HW initial MMIO sn
On Sat, May 21, 2016 at 03:59:16PM +0100, Lukas Wunner wrote:
> So far we've got one condition when DRM drivers need to defer probing
> on a dual GPU system and it's coded separately into each of the relevant
> drivers. As suggested by Daniel Vetter, deduplicate that code in the
> drivers and move
On Mon, 23 May 2016, Daniel Vetter wrote:
> On Sat, May 21, 2016 at 03:59:16PM +0100, Lukas Wunner wrote:
>> So far we've got one condition when DRM drivers need to defer probing
>> on a dual GPU system and it's coded separately into each of the relevant
>> drivers. As suggested by Daniel Vetter,
On Fri, 20 May 2016, Chris wrote:
> I'm still seeing this periodically, previous to today it happened on
> April 24th. Doesn't matter what I'm doing the video will freeze however
> the cursor will still move. Only option is to SSH in to the system from
> my tablet and do a reboot.
>
> Note: This h
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> Kernel does not have automation support for DP compliance Link
> training tests. So the Link Training test handler should return
> a TEST_NAK.
Is this test activated by short or long pulse? The commit message of commit
09b1eb130e43 ("drm/i9
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> This patch addresses a few issues from the original patch for
> DP Compliance EDID test support submitted by
> Todd Previte
Do you mean commit 559be30cb74d ("drm/i915: Implement the intel_dp_autotest_edid
function for DP EDID complaince tes
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> From: Jim Bride
>
> For DP compliance we need to be able to control the output color
> type for the pipe associated with the DP port. To do this we rely
> on the intel_dp_test_force_bpc debugfs file and the associated value
> stored in str
On 21 May 2016 at 15:08, Lukas Wunner wrote:
> Hi Emil,
>
> On Fri, May 20, 2016 at 12:41:04AM +0100, Emil Velikov wrote:
>> On 19 May 2016 at 15:39, Lukas Wunner wrote:
>> > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev)
>> > +{
>> > + if ((pdev->class >> 8) == PCI_CLASS_DIS
On Fri, 20 May 2016, Ander Conselvan de Oliveira
wrote:
> In commit f9476a6c6d0c ("drm/i915: Refactor platform specifics out of
> intel_get_shared_dpll()"), the ibx_get_dpll() function lacked an error
> check, that can lead to a NULL pointer dereference when trying to enable
> pipe C.
>
> BUG: un
On Mon, 23 May 2016, Oliver Leitner wrote:
> I am having a problem on my HP Compaq 610 Laptop with its built in intel
> graphics chip. It is causing me a kernel Panic.
There is no kernel panic in your dmesg. There is a WARNING with a
backtrace.
What other symptoms do you have besides the warning
On 20/05/16 13:19, Chris Wilson wrote:
On Fri, May 20, 2016 at 01:04:13PM +0100, Tvrtko Ursulin wrote:
+ p = &b->waiters.rb_node;
+ while (*p) {
+ parent = *p;
+ if (wait->seqno == to_wait(parent)->seqno) {
+ /* We have multiple wait
On 20/05/16 13:20, Chris Wilson wrote:
On Thu, May 19, 2016 at 04:44:03PM +0100, Tvrtko Ursulin wrote:
On 19/05/16 12:32, Chris Wilson wrote:
Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as
we only need to compute the elapsed time for a timed wait.
v2: Eliminate the u
On 20/05/16 13:23, Chris Wilson wrote:
On Fri, May 20, 2016 at 01:07:29PM +0100, Tvrtko Ursulin wrote:
On 19/05/16 14:13, Chris Wilson wrote:
On Thu, May 19, 2016 at 01:50:51PM +0100, Tvrtko Ursulin wrote:
On 19/05/16 12:32, Chris Wilson wrote:
The queue only ever contains at most one item
On Mon, 23 May 2016, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/gpu/drm/i915/i915_trace.h:10:0,
> from drivers/gpu/drm/i915/i915_drv.h:2735,
>
On Wed, May 18, 2016 at 01:24:12PM +0300, Mika Kuoppala wrote:
> Patrik Jakobsson writes:
>
> > [ text/plain ]
> > Load specific firmware versions for the DMC instead of using symbolic
> > links. The currently recommended versions are: SKL 1.26, KBL 1.01 and
> > BXT 1.07.
> >
> > Certain DMC vers
On 22/05/16 14:02, Chris Wilson wrote:
Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target diff
On 22/05/16 14:02, Chris Wilson wrote:
Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep anno
On Thu, 19 May 2016, Chris Wilson wrote:
> Using a tasklet for an irq bottom-half is the preferred form as it
> should ensure minimal latency from the irq to execution of the tasklet.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_d
On 22/05/16 14:02, Chris Wilson wrote:
i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.
Sig
On 22/05/16 14:02, Chris Wilson wrote:
As these are wrappers around kref_get/kref_put() it is preferable to
follow the naming convention and use the same verb get/put in our
wrapper names for manipulating a reference to the context.
Not so sure about this one. We got objects, framebuffers and
On Mon, May 23, 2016 at 12:12:30PM +0300, Jani Nikula wrote:
> > #define ACPI_EV_DISPLAY_SWITCH (1<<0)
> > @@ -814,11 +807,11 @@ void intel_opregion_fini(struct drm_device *dev)
> > if (!opregion->header)
> > return;
> >
> > + tasklet_kill(&dev_priv->opregion.asle_task);
> > +
On 22/05/16 14:02, Chris Wilson wrote:
We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (
On Mon, May 23, 2016 at 10:17:01AM +0100, Tvrtko Ursulin wrote:
>
> On 22/05/16 14:02, Chris Wilson wrote:
> >As these are wrappers around kref_get/kref_put() it is preferable to
> >follow the naming convention and use the same verb get/put in our
> >wrapper names for manipulating a reference to t
On 22/05/16 14:02, Chris Wilson wrote:
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
Makes sense.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
On 22/05/16 14:02, Chris Wilson wrote:
Print the context's owner (via the pid under file_priv) under debugfs.
Note that since this was originally introducing
dev_priv->kernel_context, there are a couple of leftover minor chunks.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Laht
On 22/05/16 14:02, Chris Wilson wrote:
Just move the kernel_context memboer of drm_i915_private next to the
engines it is associated with.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_g
On Mon, May 23, 2016 at 10:33:24AM +0100, Tvrtko Ursulin wrote:
> >@@ -313,30 +311,14 @@ i915_gem_create_context(struct drm_device *dev,
> > if (IS_ERR(ctx))
> > return ctx;
> >
> >-if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
> >-/* We may need to do
On Mon, May 23, 2016 at 10:42:42AM +0100, Tvrtko Ursulin wrote:
>
>
> On 22/05/16 14:02, Chris Wilson wrote:
> >Print the context's owner (via the pid under file_priv) under debugfs.
> >
> >Note that since this was originally introducing
> >dev_priv->kernel_context, there are a couple of leftover
On to, 2016-05-19 at 16:17 +0100, Chris Wilson wrote:
> -int
> -i915_gem_init_userptr(struct drm_device *dev)
> +void i915_gem_init_userptr(struct drm_i915_private *dev_priv)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> mutex_init(&dev_priv->mm_lock);
> hash_init(dev
On Sat, 21 May 2016, Lukas Wunner wrote:
> Hi Emil,
>
> On Fri, May 20, 2016 at 12:41:04AM +0100, Emil Velikov wrote:
>> On 19 May 2016 at 15:39, Lukas Wunner wrote:
>> > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev)
>> > +{
>> > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY
On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote:
> >@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
> > * for now who owns a GuC client. But for future owner of GuC
> > * client, need to make sure lrc is pinned prior to enter here.
On Mon, 23 May 2016, Chris Wilson wrote:
> On Mon, May 23, 2016 at 12:12:30PM +0300, Jani Nikula wrote:
>> > #define ACPI_EV_DISPLAY_SWITCH (1<<0)
>> > @@ -814,11 +807,11 @@ void intel_opregion_fini(struct drm_device *dev)
>> >if (!opregion->header)
>> >return;
>> >
>> > + task
On 22/05/16 14:02, Chris Wilson wrote:
struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joo
On 22/05/16 14:02, Chris Wilson wrote:
Pack the integers and related types together inside the struct.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git
On Mon, May 23, 2016 at 11:26:13AM +0100, Tvrtko Ursulin wrote:
> >@@ -400,7 +412,7 @@ int i915_gem_context_init(struct drm_device *dev)
> > return PTR_ERR(ctx);
> > }
> >
> >-if (ctx->legacy_hw_ctx.rcs_state) {
> >+if (ctx->engine[RCS].state) {
>
> Maybe now put a comment
On Fri, May 20, 2016 at 05:23:56PM +0100, Chris Wilson wrote:
> On Fri, May 20, 2016 at 07:00:18PM +0300, Imre Deak wrote:
> > On pe, 2016-05-20 at 18:20 +0300, Marius Vlad wrote:
> > > Either we return $IGT_EXIT_FAILURE or remove it entirely (like in
> > > this
> > > patch). If rmmod returns non-z
Add missing DisplayPort downstream port types. The introduced
new port types are DP++ and Wireless.
Signed-off-by: Mika Kahola
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5a848e7..e384c7f 10
Read from DPCD receiver capability field the max allowed
pixel clock and bits per component for DP to VGA converter.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 46
drivers/gpu/drm/i915/intel_drv.h | 2 ++
include/drm/drm_dp_helper.
Prep work for DP branch device handling
This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards
- DP to VGA
- DP to DVI
- DP to HDMI
- DP++ dual mode
- Wireless WiGig
DPCD register
Prep work to improve DP branch device handling.
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rat
Read from DPCD receiver capability field for the following
features:
- max TMDS clock rate
- max bits per component
- single or dual link support
- high color depth support
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
include/drm/drm_dp_helper.h | 14 +++
Read from DPCD receiver capability field for the
DP to Wireless converter. The only supported wireless
technology on DP1.3 spec is WiGig display extension. If WiGig
display extension is present, then read out the
- number of wde tx on device
- the number of wde txs that can be concurrently activ
Read device ID for DisplayPort branch devices. The device
ID is defined in DPCD register 0x503 and it is mandatory field
for DP branch devices.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 8 insertions(+)
dif
Read from DPCD receiver capability field for DP to HDMI
converter. The features for DP to HDMI converter are
- max TMDS characther clock rate
- max bits per component
- support for conversion from 3D frame sequential to frame pack
- support for YCBCR422 pass through
- support for YCBCR420 pas
Read from DPCD receiver capability field for the
DP++ devices. The features are
- max TMDS charachter clock
- max bits per component
- support for conversion from 3D frame sequential to
frame pack
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 4
include/drm/drm_dp
Read DisplayPort branch device info from through debugfs
interface.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_debugfs.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debug
For DP branch devices DPCD register may define the max supported
pixel rate for VGA dongles. This patch adds a check if DPCD register
value is less than current setting for pixel rate.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 22 ++
include/drm/drm_dp_
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel
On 23/05/16 11:17, Chris Wilson wrote:
On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote:
@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
* for now who owns a GuC client. But for future owner of GuC
* client, need to make
On Mon, May 23, 2016 at 11:55:16AM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/16 11:17, Chris Wilson wrote:
> >On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote:
> >>>@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
> >>>* for now who owns a GuC cl
== Series Details ==
Series: drm/i915: DP branch devices (rev3)
URL : https://patchwork.freedesktop.org/series/6658/
State : success
== Summary ==
Series 6658v3 drm/i915: DP branch devices
http://patchwork.freedesktop.org/api/1.0/series/6658/revisions/3/mbox
Test gem_exec_flush:
Subgr
As these are wrappers around kref_get/kref_put() it is preferable to
follow the naming convention and use the same verb get/put in our
wrapper names for manipulating a reference to the context.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv
The essence of this series is to just rename the anonymous struct inside
intel_context. But since it involves churn, I added some sweetner into
the miex (and more churn)!
[PATCH v2 04/11] drm/i915: Rename i915_gem_context_reference/unreference()
Long term plan is to migrate all of our reference
struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.
v2: Only pin the default context for legacy mode (the object only exists
for legacy, but adding i9
Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target different users. The outer
struct is API / use
Pack the integers and related types together inside the struct.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/
Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep annotations are invaluable.
Signed-off-by: Ch
Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).
v2: Mark the file_priv as closed.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
v2: Throw away the user_handle on failure to allocate the ppgtt.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtine
We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (the logical context
state, the registers,
i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursul
Just move the kernel_context member of drm_i915_private next to the
engines it is associated with.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_guc_submission.c
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..3d14
From: Ville Syrjälä
Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 126
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> This video pattern test function gets invoked through the
> compliance test handler on a HPD short pulse if the test type is
> set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> reads to read the requested test pattern, video p
== Series Details ==
Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context
URL : https://patchwork.freedesktop.org/series/7564/
State : success
== Summary ==
Series 7564v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7564/revisions/1/mbox
On 23/05/16 12:34, Chris Wilson wrote:
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
v2: Throw away the user_handle on failure to allocate the ppgtt.
Signed-off-by: Chris Wils
On Mon, May 23, 2016 at 01:50:47PM +0300, Mika Kahola wrote:
> Read from DPCD receiver capability field the max allowed
> pixel clock and bits per component for DP to VGA converter.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 46
> ++
On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:
> >@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
> > return PTR_ERR(ctx);
> > }
> >
> >+if (ctx->legacy_hw_ctx.rcs_state) {
> >+int ret;
> >+
> >+/* We may need to do
On 23/05/16 12:34, Chris Wilson wrote:
Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).
v2: Mark the file_priv as closed.
Signed-off-by: Chris Wilson
Cc
Noticed while discussing CRC tests with Ville that this was totally
wrong.
v2: Ville pointed out that it only does not block when opened using
igt_pipe_crc_new_nonblocking. Still different from
igt_pipe_crc_collect_crc, which will always block.
v3: Fix type (Ville).
Cc: Ville Syrjälä
Acked-by:
On 23/05/16 13:16, Chris Wilson wrote:
On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
+ if (ctx->legacy_hw_ctx.rcs_state) {
+ int ret;
+
+
On 23/05/16 12:34, Chris Wilson wrote:
Blah blah blah, this, for that, etc... commit message ofc. :)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff
On Mon, May 23, 2016 at 01:31:25PM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/16 12:34, Chris Wilson wrote:
>
> Blah blah blah, this, for that, etc... commit message ofc. :)
>
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
> >Cc: Joonas Lahtinen
> >---
> > drivers/gpu/drm/i915/i915_debu
From: Ville Syrjälä
Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.
v2: Just igt_warn() instead of igt_require() for unique crc check (Dan
One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
can compare the number of allocated objects and who owns them, a
discrepancy here often indicates a kernel bug. One allocator of unreported
objects is for backing context objects, so include those in the listing.
v2: Take fil
On 20/05/2016 11:42, Tvrtko Ursulin wrote:
From: Dave Gordon
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* o
On 20/05/16 12:15, Patchwork wrote:
== Series Details ==
Series: Enable GuC submission (rev3)
URL : https://patchwork.freedesktop.org/series/7153/
State : failure
== Summary ==
Series 7153v3 Enable GuC submission
http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/3/mbox
Test dr
Some small fixes to make CI more happy.
First is a fix to make all blocking calls wait for update to complete, so any
call
done right doesn't have to block on it or return -EBUSY.
pin_count was limited to 15, so many cursor updates in a single vblank would
cause it to reach the limit
and a warn
With nonblocking unpin there can be many cursor pins before they're
cleared by the next page flip.
Fix this by extending pin_count to the full 32-bit to prevent a
WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
Cc: Ville Syrjälä
Reported-by: Chris Wilson
Signed-off-by: Maarten Lank
Doing a page flip right after setcrtc would fail because part of the update is
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on
ro-bdw-i7-5600u.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/
Hi,
[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915
Doing a page flip right after setcrtc would fail because part of the update is
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on
ro-bdw-i7-5600u.
Signed-off-by: Maarten Lankhorst
---
Oops, strippe
Hi,
[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915
On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We've never actually enabled or unmasked the GSE interrupt on BDW+,
> even though the interrupt handler was always prepared for it.
> Let's enable it and see what happens.
>
> Credit to Mark Kettenis who fixed this
Prefer passing struct drm_i915_private to internal interfaces as this
saves us having to dance between drm_device and our native struct. The
savings hare are small (only 70 bytes of unrequired dancing), but
progressive!
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_d
Current intel_opregion_init is called during the driver registration
phase and intel_opregion_fini from the unregistration phase. Rename the
functions show that this is clear from their names. The phases tell us
what we expect the existing hw state to be, e.g. whether interrupts are
still enabled e
This reverts commit d55dbd06bb5e1399aba9ab5227465339d1bbefff.
It lacks a description, removes the flip trace point,
doesn't handle -EBUSY if a flip is already queued
and needs to be redone.
Signed-off-by: Maarten Lankhorst
Cc: Ville Syrjälä
---
Patch 3/2 which CI probably doesn't handle correct
From: Ville Syrjälä
SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
in an infinite batch buffer loop. The GPU apparently hogs something
critical and CPUs start to lose interrupts and whatnot. We can keep
the system limping along by unmasking some interrupts in
GEN6_PMINTRMSK
On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote:
> On Fri, 20 May 2016, Chris wrote:
> > I'm still seeing this periodically, previous to today it happened on
> > April 24th. Doesn't matter what I'm doing the video will freeze however
> > the cursor will still move. Only option is to SSH in to
From: Ville Syrjälä
On SNB (at least) it's dangeruopus to hang the GPU with an infinite
batch buffer loop while RPS is disabled. The only thing that keeps
the system going in such circumstances are the internal RPS timers,
so we should never feed the GPU with RPS disabled unless we want to
risk a
On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote:
> Hi Guys:
> I'm trying to make GVT-g as a sub-module of i915 in the next
> version patchset. The basic idea is to introduce a "gvt-g pre-enabled
> state" in i915. I think it should be a kernel option.
>
Could not the GGTT partitioning be do
From: Ville Syrjälä
Based on my observations GPU reset doesn't clobber the RPS state, so
frobbing with RPS around GPU reset seems rather pointless. Just get
rid of it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 11 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
d
On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen
wrote:
> On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote:
>> Hi Guys:
>> I'm trying to make GVT-g as a sub-module of i915 in the next
>> version patchset. The basic idea is to introduce a "gvt-g pre-enabled
>> state" in i915. I think it should
On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
> With nonblocking unpin there can be many cursor pins before they're
> cleared by the next page flip.
>
> Fix this by extending pin_count to the full 32-bit to prevent a
> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUN
On Mon, 23 May 2016, Chris wrote:
> On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote:
>> On Fri, 20 May 2016, Chris wrote:
>> > I'm still seeing this periodically, previous to today it happened on
>> > April 24th. Doesn't matter what I'm doing the video will freeze however
>> > the cursor wil
On Mon, May 23, 2016 at 05:09:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
> in an infinite batch buffer loop. The GPU apparently hogs something
> critical and CPUs start to lose interrupts and wha
== Series Details ==
Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context
(rev2)
URL : https://patchwork.freedesktop.org/series/7564/
State : failure
== Summary ==
Series 7564v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7564/revisions
On Mon, May 23, 2016 at 05:09:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Based on my observations GPU reset doesn't clobber the RPS state, so
> frobbing with RPS around GPU reset seems rather pointless. Just get
> rid of it.
>
> Signed-off-by: Ville Syrjälä
Test
1 - 100 of 137 matches
Mail list logo
