On Fri, May 13, 2016 at 09:22:03AM +0300, Joonas Lahtinen wrote:
> On to, 2016-05-12 at 12:19 +0100, Chris Wilson wrote:
> > Under full-ppgtt, access to the global GTT is carefully regulated
> > through hardware functions (i.e. userspace cannot read and write to
> > arbitrary locations in the GGTT
On Thu, May 12, 2016 at 10:06:34PM +0100, john.c.harri...@intel.com wrote:
> +void i915_gem_request_notify(struct intel_engine_cs *engine, bool
> fence_locked)
> +{
> + struct drm_i915_gem_request *req, *req_next;
> + unsigned long flags;
> u32 seqno;
>
> - seqno = req->engine-
On Fri, 13 May 2016, Scott Long wrote:
> Jean-Sébastien and other developers have been discussing a new approach
> for post-3.8.13 updates. Instead of maintaining a large set of changes,
> the plan is to keep the driver as close as possible to the upstream Linux
> version, and use straightforward
On to, 2016-05-12 at 15:28 +0100, Chris Wilson wrote:
> Currently for handling the extra hibernation phases we just call the
> equivalent suspend/resume phases. In the next couple of patches, I wish
> to specialise the hibernation phases to reduce the amount of work
> required for handling GEM obje
On to, 2016-05-12 at 15:28 +0100, Chris Wilson wrote:
> When creating the hibernation image, the CPU will read the pages of all
> objects and thus conflict with our domain tracking. We need to update
> our domain tracking to accurately reflect the state on restoration.
>
> v2: Perform the domain t
On Thu, May 12, 2016 at 10:06:31PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The fence object used inside the request structure requires a sequence
> number. Although this is not used by the i915 driver itself, it could
> potentially be used by non-i915 code if the fence i
On Thu, May 12, 2016 at 10:06:36PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The notify function can be called many times without the seqno
> changing. Some are to prevent races due to the requirement of not
> enabling interrupts until requested. However, when interrupts a
On to, 2016-05-12 at 15:28 +0100, Chris Wilson wrote:
> Now that we mark the object domains for having been restored from the
> hibernation image, we not need to flush everything during resume and
> can instead rely on the normal domain tracking to flush only when
> required. The only caveat here a
On Thu, May 12, 2016 at 10:06:30PM +0100, john.c.harri...@intel.com wrote:
> Added support for possible RCU usage of fence object (Review comments
> by Maarten Lankhorst).
You mean like
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet&id=001f3468762ca49137b5658f2aa58507dbfa4a05
?
-C
On to, 2016-05-12 at 15:28 +0100, Chris Wilson wrote:
> Under full-ppgtt, access to the global GTT is carefully regulated
> through hardware functions (i.e. userspace cannot read and write to
> arbitrary locations in the GGTT via the GPU). With this restriction in
> place, we can forgo clearing sta
On Thu, 12 May 2016 20:06:53 +0200,
Imre Deak wrote:
>
> User may pass nomodeset or i915.modeset=0 option to disable i915 KMS
> explicitly. Although this itself works fine, it breaks the weak
> dependency the HD-audio driver requires, and it's the reason the
> delayed component binding isn't impl
Following a GPU hang, we break out of the request loop in order to
unlock the struct_mutex for use by the GPU reset. However, if we retire
all the requests at that moment, we cannot identify the guilty request
after performing the reset.
v2: Not automatically retiring requests forces us to recheck
== Series Details ==
Series: series starting with [1/2] drm/i915: Stop retiring requests from
busy-ioctl (rev2)
URL : https://patchwork.freedesktop.org/series/7059/
State : failure
== Summary ==
Series 7059v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7059/rev
Prefix struct dpll with intel_ to follow the convention in the driver.
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 76 +
On 12/05/16 11:25, Chris Wilson wrote:
In order to reduce the workload of the caller, we do not want to
actually have to retire requests of others when checking the status of
this object.
Wrt the subject, and from wait ioctl as well.
Also i915_gem_object_sync / i915_gem_execbuffer_move_to_gpu
On Thu, 2016-05-12 at 15:12 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915: Remove intel_clock_t typedef
> URL : https://patchwork.freedesktop.org/series/6718/
> State : failure
>
> == Summary ==
>
> Series 6718v1 Series without cover letter
> ht
> On May 13, 2016, at 1:34 AM, Jani Nikula wrote:
>
> On Fri, 13 May 2016, Scott Long wrote:
>> Jean-Sébastien and other developers have been discussing a new approach
>> for post-3.8.13 updates. Instead of maintaining a large set of changes,
>> the plan is to keep the driver as close as possib
Chris Wilson writes:
> [ text/plain ]
> Following a GPU hang, we break out of the request loop in order to
> unlock the struct_mutex for use by the GPU reset. However, if we retire
> all the requests at that moment, we cannot identify the guilty request
> after performing the reset.
>
> v2: Not a
On Fri, May 13, 2016 at 09:38:54AM +0100, Tvrtko Ursulin wrote:
>
> On 12/05/16 11:25, Chris Wilson wrote:
> >In order to reduce the workload of the caller, we do not want to
> >actually have to retire requests of others when checking the status of
> >this object.
>
> Wrt the subject, and from wa
On 13/05/16 09:50, Chris Wilson wrote:
On Fri, May 13, 2016 at 09:38:54AM +0100, Tvrtko Ursulin wrote:
On 12/05/16 11:25, Chris Wilson wrote:
In order to reduce the workload of the caller, we do not want to
actually have to retire requests of others when checking the status of
this object.
On 13/05/2016 08:39, Chris Wilson wrote:
On Thu, May 12, 2016 at 10:06:31PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The fence object used inside the request structure requires a sequence
number. Although this is not used by the i915 driver itself, it could
potentially be us
On 13/05/2016 08:27, Chris Wilson wrote:
On Thu, May 12, 2016 at 10:06:34PM +0100, john.c.harri...@intel.com wrote:
+void i915_gem_request_notify(struct intel_engine_cs *engine, bool fence_locked)
+{
+ struct drm_i915_gem_request *req, *req_next;
+ unsigned long flags;
u32 se
== Series Details ==
Series: drm/i915: Rename struct dpll to struct intel_dpll
URL : https://patchwork.freedesktop.org/series/7128/
State : failure
== Summary ==
Series 7128v1 drm/i915: Rename struct dpll to struct intel_dpll
http://patchwork.freedesktop.org/api/1.0/series/7128/revisions/1/mbo
On Fri, May 13, 2016 at 11:43:25AM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > [ text/plain ]
> > Following a GPU hang, we break out of the request loop in order to
> > unlock the struct_mutex for use by the GPU reset. However, if we retire
> > all the requests at that moment, we can
The get-reset-stats ioctls wasn't waiting for a pending reset before
reporting its statistics, and so was ignoring a hang generated by the
context that should have been reported against said context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file changed,
The get-reset-stats ioctl reports upon the statistics (number of hangs,
be it as a victim or the guilty party) of a particular context. It is
semantically better as being part of i915_gem_context.c user interface,
as opposed to the hardware level access of intel_uncore.c
Signed-off-by: Chris Wilso
== Series Details ==
Series: series starting with [1/2] drm/i915: Stop retiring requests from
busy-ioctl (rev4)
URL : https://patchwork.freedesktop.org/series/7059/
State : failure
== Summary ==
Applying: drm/i915: Stop retiring requests from busy-ioctl
Applying: drm/i915: Complete pending re
Chris Wilson writes:
> [ text/plain ]
> The get-reset-stats ioctl reports upon the statistics (number of hangs,
> be it as a victim or the guilty party) of a particular context. It is
> semantically better as being part of i915_gem_context.c user interface,
> as opposed to the hardware level acce
On Fri, 2016-05-13 at 09:48 +0200, Takashi Iwai wrote:
> On Thu, 12 May 2016 20:06:53 +0200,
> Imre Deak wrote:
> >
> > User may pass nomodeset or i915.modeset=0 option to disable i915 KMS
> > explicitly. Although this itself works fine, it breaks the weak
> > dependency the HD-audio driver requi
On Fri, 13 May 2016 11:50:09 +0200,
Imre Deak wrote:
>
> On Fri, 2016-05-13 at 09:48 +0200, Takashi Iwai wrote:
> > On Thu, 12 May 2016 20:06:53 +0200,
> > Imre Deak wrote:
> > >
> > > User may pass nomodeset or i915.modeset=0 option to disable i915 KMS
> > > explicitly. Although this itself wor
On 13/05/2016 08:44, Chris Wilson wrote:
On Thu, May 12, 2016 at 10:06:30PM +0100, john.c.harri...@intel.com wrote:
Added support for possible RCU usage of fence object (Review comments
by Maarten Lankhorst).
You mean like
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet&id=001f3
Chris Wilson writes:
> [ text/plain ]
> The get-reset-stats ioctls wasn't waiting for a pending reset before
> reporting its statistics, and so was ignoring a hang generated by the
> context that should have been reported against said context.
>
> Signed-off-by: Chris Wilson
This is the fix we
In order to reduce the workload of the caller, we do not want to
actually have to retire requests of others when checking the busy status
of this object. This applies to both busy/wait ioctls as the wait ioctl
has a semantically equivalent mode to the busy ioctl.
At the present time, this is only
Chris Wilson writes:
> [ text/plain ]
> In order to reduce the workload of the caller, we do not want to
> actually have to retire requests of others when checking the status of
> this object.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c
On Fri, 2016-05-13 at 12:04 +0200, Takashi Iwai wrote:
> On Fri, 13 May 2016 11:50:09 +0200,
> Imre Deak wrote:
> >
> > On Fri, 2016-05-13 at 09:48 +0200, Takashi Iwai wrote:
> > > On Thu, 12 May 2016 20:06:53 +0200,
> > > Imre Deak wrote:
> > > >
> > > > User may pass nomodeset or i915.modeset=0
This allows us to test that RMFB works as intended by the original abi.
We create a framebuffer and try to remove the framebuffer from a crtc
using fd closing or rmfb ioctl.
Signed-off-by: Maarten Lankhorst
---
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b73f48d95568..c223c
Chris Wilson writes:
> [ text/plain ]
> Following a GPU hang, we break out of the request loop in order to
> unlock the struct_mutex for use by the GPU reset. However, if we retire
> all the requests at that moment, we cannot identify the guilty request
> after performing the reset.
>
> v2: Not a
The get-reset-stats ioctl reports upon the statistics (number of hangs,
be it as a victim or the guilty party) of a particular context. It is
semantically better as being part of i915_gem_context.c user interface,
as opposed to the hardware level access of intel_uncore.c
Signed-off-by: Chris Wilso
The get-reset-stats ioctls wasn't waiting for a pending reset before
reporting its statistics, and so was ignoring a hang generated by the
context that should have been reported against said context.
Signed-off-by: Chris Wilson
Tested-by: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gp
Following a GPU hang, we break out of the request loop in order to
unlock the struct_mutex for use by the GPU reset. However, if we retire
all the requests at that moment, we cannot identify the guilty request
after performing the reset.
v2: Not automatically retiring requests forces us to recheck
In order to reduce the workload of the caller, we do not want to
actually have to retire requests of others when checking the busy status
of this object. This applies to both busy/wait ioctls as the wait ioctl
has a semantically equivalent mode to the busy ioctl.
At the present time, this is only
== Series Details ==
Series: series starting with [v2] drm/i915: Stop retiring requests from
busy/wait ioctls (rev5)
URL : https://patchwork.freedesktop.org/series/7059/
State : failure
== Summary ==
Applying: drm/i915: Stop retiring requests from busy/wait ioctls
Applying: drm/i915: Complete
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Move get-reset-stats ioctl from
intel_uncore.c to i915_gem_context.c
URL : https://patchwork.freedesktop.org/series/7136/
State : failure
== Summary ==
Series 7136v1 Series without cover letter
http://patchwork.freedesktop.o
basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to
be aproximately equal with the estimated number.
This is a false negative, one of the reasons being the precision lost when
truncating a fractional number.
Fixed this by using floating point arithmetic.
Cc: Jani Nikula
On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote:
> basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to
> be aproximately equal with the estimated number.
>
> This is a false negative, one of the reasons being the precision lost when
> truncating a fractional
On Fri, May 13, 2016 at 01:00:33PM +0100, Chris Wilson wrote:
> On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote:
> > basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to
> > be aproximately equal with the estimated number.
> >
> > This is a false negative, on
On Thu, 2016-05-12 at 15:31 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix a few code checker errors
> URL : https://patchwork.freedesktop.org/series/7071/
> State : failure
>
> == Summary ==
>
> Series 7071v1 drm/i915: Fix a few code checker errors
> http://patchwork
> I don't have any FreeBSD experience and I don't know what kind of team
> of developers you have, but it is my educated guess that you'll have
> plenty of more productive things to do than trying to maintain a
> significant amount of delta with upstream while also trying to stay
> up-to-date.
I a
Hello intel-gfx,
I'd like to offer a heads-up on the ongoing work in the FreeBSD project
to update to a contemporary version of the i915 driver.
For context, some background information on the earlier approaches we've
taken to import the i915 driver in FreeBSD. In the past, developers often
rewor
On 13.05.2016 15:00, Chris Wilson wrote:
On Fri, May 13, 2016 at 02:45:09PM +0300, Gabriel Feceoru wrote:
basic-flip-vs-wf_vblank subtest sometimes fails asserting counted frames to
be aproximately equal with the estimated number.
This is a false negative, one of the reasons being the precisi
On Fri, May 13, 2016 at 03:24:32PM +0300, Imre Deak wrote:
> On Thu, 2016-05-12 at 15:31 +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Fix a few code checker errors
> > URL : https://patchwork.freedesktop.org/series/7071/
> > State : failure
> >
> > == Summary ==
>
On Thu, May 12, 2016 at 03:28:15PM +0100, Chris Wilson wrote:
> Now that we mark the object domains for having been restored from the
> hibernation image, we not need to flush everything during resume and
> can instead rely on the normal domain tracking to flush only when
> required. The only cavea
On Thu, May 12, 2016 at 03:28:16PM +0100, Chris Wilson wrote:
> Under full-ppgtt, access to the global GTT is carefully regulated
> through hardware functions (i.e. userspace cannot read and write to
> arbitrary locations in the GGTT via the GPU). With this restriction in
> place, we can forgo clea
On Thu, 12 May 2016, Scott Long wrote:
> I'd like to offer a heads-up on the ongoing work in the FreeBSD project
> to update to a contemporary version of the i915 driver.
I inadvertently let this through the moderation while Scott had reposted
as subscriber. Please ignore this one and keep the co
This patch includes enabling render decompression (RC) after checking
all the requirements (format, tiling, rotation etc.).
TODO:
1. Disable stereo 3D when render decomp is enabled (bit 7:6)
2. Render decompression must not be used in VTd pass-through mode
3. Program hashing select CHICKEN_MISC1 b
== Series Details ==
Series: series starting with [1/2] drm: Add aux plane verification in addFB2
(rev3)
URL : https://patchwork.freedesktop.org/series/4641/
State : failure
== Summary ==
Applying: drm: Add aux plane verification in addFB2
Applying: drm/i915: Render decompression support for
Fairly simple stuff, pushed the series to igt.
BR,
Jani.
On Thu, 12 May 2016, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> tools/intel_bios_reader.c | 52
> +++
> 1 file changed, 30 insertions(+), 22 deletions(-)
>
> diff --git a/tools/i
Also make the code more readable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100fa3122..a8c79f6512a4 100644
--- a/drivers/gpu/d
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b70f05c..bb0b6f64000e 100644
--- a/
Hi,
This series moves all of the calls to vlv_dpio_{read,write} to
intel_dpio_phy.c. I think it simplifies the surrounding code a bit.
Thanks,
Ander
Ander Conselvan de Oliveira (6):
drm/i915: Rename struct dpll to struct intel_dpll
drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_d
Hide the dpio details of setting up the dplls on VLV/CHV to
intel_dpio_phy.c. This will allow the prepare and enable pll functions
to be merged in a follow up. It also creates a better split of the code
where most of the dpio access are concentrated in one place.
Signed-off-by: Ander Conselvan de
Reading the dividers depends on sideband messaging, so it fits well if
the other functions in intel_dpio_phy.c. The new function will also be
used in a future patch.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.
Prefix struct dpll with intel_ to follow the convention in the driver.
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 76 +
Reading the dividers depends on sideband messaging, so it fits well if
the other functions in intel_dpio_phy.c. The new function will also be
used in a future patch.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.
This simplifies the pll enable/disable a code a bit and hides the
sideband message neatly in intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 19 ++-
drivers/gpu/drm/i915/intel
With the bulk of the dpio code moved out of the vlv/chv prepare pll
functions into intel_dpio_phy.c, those functions became simple enough
that they can be merged with the pll enabling function, that always
succeeds the prepare call.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm
On Fri, May 13, 2016 at 05:15:01PM +0300, Ander Conselvan de Oliveira wrote:
> Reading the dividers depends on sideband messaging, so it fits well if
> the other functions in intel_dpio_phy.c. The new function will also be
> used in a future patch.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
On 13/05/16 15:04, Jani Nikula wrote:
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
ind
On Fri, May 13, 2016 at 05:15:03PM +0300, Ander Conselvan de Oliveira wrote:
> This simplifies the pll enable/disable a code a bit and hides the
> sideband message neatly in intel_dpio_phy.c.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
For al
When creating the hibernation image, the CPU will read the pages of all
objects and thus conflict with our domain tracking. We need to update
our domain tracking to accurately reflect the state on restoration.
v2: Perform the domain tracking inside freeze, before the image is
written, rather than
Currently for handling the extra hibernation phases we just call the
equivalent suspend/resume phases. In the next couple of patches, I wish
to specialise the hibernation phases to reduce the amount of work
required for handling GEM objects.
v2: There are more! Don't forget the freeze phases.
Sig
Now that we mark the object domains for having been restored from the
hibernation image, we not need to flush everything during resume and
can instead rely on the normal domain tracking to flush only when
required. The only caveat here are objects that are pinned for use by
the hardware, whose cont
On Fri, May 13, 2016 at 05:15:02PM +0300, Ander Conselvan de Oliveira wrote:
> Reading the dividers depends on sideband messaging, so it fits well if
> the other functions in intel_dpio_phy.c. The new function will also be
> used in a future patch.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
>
> On 13/05/16 15:04, Jani Nikula wrote:
> >This is more robust for assignments and comparisons.
> >
> >Signed-off-by: Jani Nikula
> >---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
The knowledge of how to derive the relevant client from the request
should be localised within i915_guc_submission.c; the LRC code shouldn't
have to know about the internal details of the GuC submission process.
And all the information the GuC code needs should be encapsulated in (or
reachable from
The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
On 10/05/16 15:37, Tvrtko Ursulin wrote:
On 06/05/16 17:39, Dave Gordon wrote:
On 29/04/16 16:03, Tvrtko Ursulin wrote:
[snip]
+goto fail;
+if (fw_path == NULL)
+goto fail;
+if (*fw_path == '\0') {
+DRM_ERROR("No GuC firmware known for this platform\n");
It
Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)
We'll also add a counter to the GuC client statistics, to see ho
This patchset covers various GuC-related changes, but most important of
these are (1) splitting the original "enable_guc_submission" parameter
into separate flags for loading GuC firmware vs. using the GuC for job
submission [PATCH 3/7], and (2) actually enabling GuC submission by
default on suitab
Mostly little optimisations and future-proofing against code breakage.
For instance, if the driver is correctly following the submission
protocol, the "out of space" condition is impossible, so the previous
runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic
effect in development an
This patch simply changes the default value of "enable_guc_submission"
from 0 (never) to -1 (auto). This means that GuC submission will be
used if the platform has a GuC, the GuC supports the request submission
protocol, and any required GuC firmwware was successfully loaded. If any
of these condit
For now, anything with a GuC requires uCode loading, and then supports
command submission once loaded. But these are logically distinct from
simply "having a GuC", so we need a separate macro for the latter. Then,
various tests should use this new macro rather than HAS_GUC_UCODE() or
testing enable
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* of the GuC for batch
submission once the firmware is loaded.
In a
On Thu, May 12, 2016 at 10:52:11PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Pre-calculate SKL-style atomic watermarks (final CI run) (rev2)
> URL : https://patchwork.freedesktop.org/series/7075/
> State : success
Maarten confirmed on IRC that his r-b stands for the updated ver
On Fri, May 13, 2016 at 05:14:58PM +0300, Ander Conselvan de Oliveira wrote:
> Prefix struct dpll with intel_ to follow the convention in the driver.
>
> Cc: Ville Syrjälä
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i9
On Fri, 13 May 2016, Chris Wilson wrote:
> On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
>>
>> On 13/05/16 15:04, Jani Nikula wrote:
>> >This is more robust for assignments and comparisons.
>> >
>> >Signed-off-by: Jani Nikula
>> >---
>> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
From: Ville Syrjälä
My ILK was very unhappy runnin BAT tests. Caused by watermark fail during
resume.
Here's the smallest fix I thought of.
Ville Syrjälä (2):
drm/i915: Don't leave old junk in ilk active watermarks on readout
drm/i915: Ignore stale wm register values on resume on ilk-bdw
From: Ville Syrjälä
When we read out the watermark state from the hardware we're supposed to
transfer that into the active watermarks, but currently we fail to any
part of the active watermarks that isn't explicitly written. Let's clear
it all upfront.
Looks like this has been like this since th
From: Ville Syrjälä
When we resume the watermark register may contain some BIOS leftovers,
or just the hardware reset values. We should ignore those as the
pipes will be off anyway, and so frobbing around with intermediate
watermarks doesn't make much sense.
In fact I think we should just throw
== Series Details ==
Series: series starting with [RESEND,1/2] drm/i915: make device info bitfield
flags bools
URL : https://patchwork.freedesktop.org/series/7149/
State : failure
== Summary ==
Series 7149v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7149/revi
On 13/05/16 15:47, Jani Nikula wrote:
On Fri, 13 May 2016, Chris Wilson wrote:
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
On 13/05/16 15:04, Jani Nikula wrote:
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i
On 13/05/16 15:04, Jani Nikula wrote:
Also make the code more readable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 547100fa31
On 13/05/16 15:36, Dave Gordon wrote:
The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).
Signed-off-by: Dave Gordon
---
drivers/gpu
This reverts commit a633ad03c6a0e96eecfd4933ea0dffb68ed40e07 as it
completely breaks building the gem_concurrent_blit tests.
---
tests/Makefile.am | 12 +++-
tests/Makefile.sources | 22 ++
2 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/tests/Makef
From: Ville Syrjälä
DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
about. However error paths everyone cares about, so hiding the error
debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS
for those instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm
On 13/05/16 15:36, Dave Gordon wrote:
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* of the GuC for batch
subm
On 13/05/16 15:36, Dave Gordon wrote:
Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)
We'll also add a counte
On 13/05/16 15:36, Dave Gordon wrote:
For now, anything with a GuC requires uCode loading, and then supports
command submission once loaded. But these are logically distinct from
simply "having a GuC", so we need a separate macro for the latter. Then,
various tests should use this new macro rath
== Series Details ==
Series: Move dpio access out of intel_display.c
URL : https://patchwork.freedesktop.org/series/7150/
State : failure
== Summary ==
Series 7150v1 Move dpio access out of intel_display.c
http://patchwork.freedesktop.org/api/1.0/series/7150/revisions/1/mbox
Test drv_hangman:
1 - 100 of 147 matches
Mail list logo
