On Wed, Jun 08, 2016 at 11:30:24AM -0400, Zhi Wang wrote:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index cbc84e6..344b5d3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2478,7 +2478,8 @@ static int
On Wed, Jun 08, 2016 at 05:55:23PM +0300, Imre Deak wrote:
> On ke, 2016-06-08 at 17:50 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote:
> > > On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre
On Fri, Jun 03, 2016 at 08:21:50PM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote:
> > On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> > > > On Wed, May 25, 2016 at
On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> > superfluous because the framebuffer will subsequently be unregistered by
> >
On ke, 2016-06-08 at 17:50 +0300, Ville Syrjälä wrote:
> On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote:
> > On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote:
> > > > We can check the power state of the PHY data and
On Wed, Jun 08, 2016 at 05:28:31PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > [ text/plain ]
> > On Tue, Jun 07, 2016 at 02:52:18PM -, Patchwork wrote:
> >> == Series Details ==
> >>
> >> Series: gen9 workarounds v3
> >> URL :
== Series Details ==
Series: Introduce the implementation of GVT context (rev6)
URL : https://patchwork.freedesktop.org/series/7208/
State : warning
== Summary ==
Series 7208v6 Introduce the implementation of GVT context
http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/6/mbox
On Wed, Jun 08, 2016 at 11:30:18AM -0400, Zhi Wang wrote:
> Bing Niu (1):
> drm/i915: Introduce host graphics memory partition for GVT-g
>
> Zhi Wang (9):
> drm/i915: Factor out i915_pvinfo.h
> drm/i915: Use offsetof() to calculate the offset of members in PVINFO
> page
> drm/i915:
On Wed, Jun 08, 2016 at 04:47:48PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 15:35 schreef Ville Syrjälä:
> > On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote:
> >> Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> >>> On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst
These helpers will be needed by the next patch, so factor them out.
No functional change.
v2:
- Move the refcount==0 WARN to the new put helper. (Ville)
CC: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c
On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote:
> On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote:
> > > We can check the power state of the PHY data and common lanes as
> > > reported by the PHY. Do this in case we
So far we configured a static lane latency optimization during driver
loading/resuming. The specification changed at one point and now this
configuration depends on the lane count, so move the configuration
to modeset time accordingly.
It's not clear when this lane configuration takes effect. The
We can check the power state of the PHY data and common lanes as
reported by the PHY. Do this in case we need to debug problems where the
PHY gets stuck in an unexpected state.
Note that I only check these when the lanes are expected to be powered
on purpose, since it's not clear at what point
Sure. That's a good idea. :)
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, June 08, 2016 7:01 PM
> To: Wang, Zhi A
> Cc: Lv, Zhiyuan ; Tian, Kevin ;
>
Sure. Will improve that in v9.
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, June 08, 2016 7:09 PM
> To: Wang, Zhi A
> Cc: Lv, Zhiyuan ; Tian, Kevin ;
>
This patch introduces an option for configuring the ring buffer size
of a LRC context after the context creation.
v8:
- Rename the data member in i915_gem_context. (Chris)
Reviewed-by: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by:
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
v7:
- Refine the URL link in Kconfig. (Joonas)
- Refine the introduction of GVT-g host support in Kconfig.
Currently the addressing mode bit in context descriptor is statically
generated from the configuration of system-wide PPGTT usage model.
GVT-g will load the PPGTT shadow page table by itself and probably one
guest is using a different addressing mode with i915 host. The addressing
mode bits of a
This patch introduces an approach to track the execlist context status
change.
GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.
This function is
This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.
Only GVT-g will create this kinds of GEM context currently.
v8:
-
v5:
- Let functions take struct drm_i915_private *. (Tvrtko)
- Fold vGPU related active check into the inner functions. (Kevin)
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Suggested-by: Kevin Tian
This patchset introduces the implementation of GVT context. GVT
context is a special GEM context used by GVT-g. GVT-g uses it as the shadow
context.It doesn't have a drm client nor a PPGTT. And it requires a larger
ring buffer with several special features need by GVT-g workload scheduler
like
To get the offset of the members in PVINFO page, offsetof() looks much
better than the tricky approach in current code.
v7:
- Move "offsetof()" modification into a dedicated patch. (Joonas)
Suggested-by: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
From: Bing Niu
This patch introduces host graphics memory partition when GVT-g
is enabled.
Under GVT-g, i915 host driver only owned limited graphics resources,
others are managed by GVT-g resource allocator and kept for other vGPUs.
v7:
- Add comments about low/high GM
GVT workload scheduler needs special host LRC contexts, the so called
"shadow LRC context" to submit guest workload to host i915. During the
guest workload submission, workload scheduler fills the shadow LRC
context with the content of guest LRC context: engine context is copied
without changes,
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.
v7:
- Split the "offsetof" modification into a dedicated patch. (Joonas)
v3:
- Use offsetof to calculate the member offset of PVINFO structure
== Series Details ==
Series: drm/i915/bxt: Fix DDI PHY setup for low resolutions (rev4)
URL : https://patchwork.freedesktop.org/series/8414/
State : failure
== Summary ==
Applying: drm/i915/bxt: Wait for PHY1 GRC calibration synchronously
Applying: drm/i915/bxt: Sanitiy check the PHY lane
On Wed, Jun 08, 2016 at 11:30:25AM -0400, Zhi Wang wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 66fdb8d..6a79c8c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -879,6 +879,7 @@ struct i915_gem_context {
I'll second this idea.
With small typo fixed on commit message this is
Reviewed-by: Mika Kahola
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, June 8, 2016
== Series Details ==
Series: Support for creating/using Stolen memory backed objects (rev17)
URL : https://patchwork.freedesktop.org/series/659/
State : success
== Summary ==
Series 659v17 Support for creating/using Stolen memory backed objects
0x as an illegal command confuses the command execution
on gen9 so that the next BB start will get ignored, causing a runaway
head past the bb end. This delays the hang detection substantially
as hangcheck then observes only a non progressing seqno.
Omit the bad instruction on gen8+ and
On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather than looping through encoders to see which encoder types
> are being driven by the pipe, add an output_types bitmask into
> the crtc state and populate
Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
>> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
>> to 10s.
> Does it still find the problem reliably on CHV pipe C (if you remove the
> kernel w/a)?
Yeah, a
On Wed, Jun 08, 2016 at 02:15:25PM +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 01:41:46PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Move the encoder cloning check to happen earlier in the modeset. The
> > main benefit will
On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> > On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
> >> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
> >> to 10s.
> > Does it still find
On Wed, Jun 08, 2016 at 11:43:57AM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:55:25PM +0100, Chris Wilson wrote:
> > Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for
> > i915_gem_object_ggtt_pin(), spare us the confustion and remove it.
> > Removing it now
Hi!
> Could you try to apply the following patch [1], hopefully this fixes
> the issue for you.
>
> [1] https://patchwork.freedesktop.org/patch/89111/
I updated the kernel, applied the patch and yes, that helped.
Thanks!
Make sure that injected hang is detected below time threshold.
This ensures that we fail if hang was of no-progress type instead
of a stuck engine.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 23
On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
> to 10s.
Does it still find the problem reliably on CHV pipe C (if you remove the
kernel w/a)?
>
> Cc: Ville Syrjälä
>
On Wed, Jun 08, 2016 at 01:41:46PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Move the encoder cloning check to happen earlier in the modeset. The
> main benefit will be that the debug output from a failed modeset will
> be less confusing
On 08/06/16 11:55, Dave Gordon wrote:
During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.
Perhaps a
On Wed, Jun 08, 2016 at 01:25:31PM +0200, Maarten Lankhorst wrote:
> There is a extra call to igt_pipe_crc_start that is not matched to any
> stop. Because of this the exit handler tries to reset the crc source on
> exit while the pipe disabled. This causes fails with -EIO:
>
>
On Wed, Jun 08, 2016 at 02:25:25PM +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Rather than looping through encoders to see which encoder types
> > are being driven by
On Wed, Jun 08, 2016 at 01:44:27PM +0100, Tvrtko Ursulin wrote:
>
> On 08/06/16 13:34, Chris Wilson wrote:
> >On Wed, Jun 08, 2016 at 12:47:28PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 08/06/16 12:24, Chris Wilson wrote:
> >>>On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote:
>
OK. Will do in the next version. :)
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, June 08, 2016 11:05 AM
> To: Wang, Zhi A ; ch...@chris-wilson.co.uk; Lv, Zhiyuan
> ; Tian, Kevin
Patch title s/ballon/balloon/.
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote:
> This function needs to be changed to have a proper goto teardown path.
> Destructors/fini functions are only expected to be called after a
> successful initialization, so calling it at random phase in init function
Good idea. :)
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, June 08, 2016 10:13 AM
> To: Wang, Zhi A
> Cc: Lv, Zhiyuan ; Tian, Kevin ;
> tvrtko.ursu...@linux.intel.com;
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote:
> Currently the addressing mode bit in context descriptor is statically
> generated from the configuration of system-wide PPGTT usage model.
>
> GVT-g will load the PPGTT shadow page table by itself and probably one
> guest is using a different
On ke, 2016-06-08 at 08:04 +0100, Chris Wilson wrote:
> On Tue, Jun 07, 2016 at 11:18:46AM -0400, Zhi Wang wrote:
> >
> > This patch introduces the support of LRC context single submission.
> > As GVT context may come from different guests, which require different
> > configuration of render
Use our ioctl overload to enable kcov capture around every ioctl.
---
lib/igt_aux.c | 84 +++
lib/igt_aux.h | 5
2 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index fb1dac2..71067b3
A small utility for extracting kernel coverage using
/sys/kernel/debug/kcov.
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_debugfs.c| 20 ++
lib/igt_debugfs.h| 1 +
lib/igt_kcov.c | 188
On Fri, Jun 03, 2016 at 05:36:29PM +0100, Chris Wilson wrote:
> Ideally, we want to automagically have the GPU respond to the
> instantaneous load by reclocking itself. However, reclocking occurs
> relatively slowly, and to the client waiting for a result from the GPU,
> too late. To compensate
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote:
> To get the offset of the members in PVINFO page, offsetof() looks much
> better than the tricky approach in current code.
>
> v7:
>
> - Move "offsetof()" modification into a dedicated patch. (Joonas)
>
> Signed-off-by: Zhi Wang
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote:
> v5:
> - Let functions take struct drm_i915_private *. (Tvrtko)
>
> - Fold vGPU related active check into the inner functions. (Kevin)
>
I already reviewed this patch, so you should add Reviewed-by: and Cc:
tags. Also good to add Cc: tag for
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C
cursor fail"
URL : https://patchwork.freedesktop.org/series/8431/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/intel_dp_mst.o
CC [M] drivers/gpu/drm/i915/intel_dp.o
CC [M]
On Fri, Jun 03, 2016 at 11:20:19AM +0100, Chris Wilson wrote:
> On Fri, Jun 03, 2016 at 03:44:09PM +0530, Goel, Akash wrote:
> >
> >
> > On 6/3/2016 12:45 PM, Daniel Vetter wrote:
> > >On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote:
> > >>On Thu, 2016-06-02 at 10:16 +, Daniel
On ti, 2016-06-07 at 23:01 +0100, Chris Wilson wrote:
> On Tue, Jun 07, 2016 at 11:18:45AM -0400, Zhi Wang wrote:
> >
> > This patch introduces an approach to track the execlist context status
> > change.
> >
> > GVT-g uses GVT context as the "shadow context". The content inside GVT
> > context
On Fri, Jun 03, 2016 at 05:08:34PM +0100, Chris Wilson wrote:
> We can forgo queuing the hangcheck from the start of every request to
> until we wait upon a request. This reduces the overhead of every
> request, but may increase the latency of detecting a hang. Howeever, if
> nothing every waits
On Fri, Jun 03, 2016 at 05:08:47PM +0100, Chris Wilson wrote:
> We have testcases to ensure that seqno wraparound works fine, so we can
> forgo forcing everyone to encounter seqno wraparound during early
> uptime. seqno wraparound incurs a full GPU stall so not forcing it
> will eliminate one
On ke, 2016-06-08 at 09:41 +0300, Ander Conselvan De Oliveira wrote:
> On Tue, 2016-06-07 at 21:24 +0300, Imre Deak wrote:
> > So far we configured a static lane latency optimization during driver
> > loading/resuming. The specification changed at one point and now this
> > configuration depends
On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote:
> We only need to force a switch to the kernel context placeholder during
> eviction. All other uses of i915_gpu_idle() just want to wait until
> existing work on the GPU is idle. Rename i915_gpu_idle() to
> i915_gem_wait_for_idle() to avoid
Hi,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.7-rc2 next-20160608]
[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/Akshu-Agrawal/Revert-drm-i915-Workaround
On ti, 2016-06-07 at 15:29 +, Wang, Zhi A wrote:
>
> >
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Friday, June 03, 2016 12:40 PM
> > To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org;
> >
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote:
> As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
> host (GVT-g kernel device model), factor it out for better code structure.
>
> v7:
> - Split the "offsetof" modification into a dedicated patch. (Joonas)
>
> v3:
> -
On 07/06/16 21:00, Chris Wilson wrote:
On Tue, Jun 07, 2016 at 02:23:34PM +0100, Tvrtko Ursulin wrote:
On 07/06/16 11:54, Dave Gordon wrote:
On 07/06/16 09:43, Patchwork wrote:
== Series Details ==
Series: series starting with [1/3] drm/i915/guc: fix GuC
loading/submission check
URL :
Sure. Moving code in one patch, "offsetof()" guy will be in another patch
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, June 08, 2016 10:55 AM
> To: Wang, Zhi A ; ch...@chris-wilson.co.uk; Lv, Zhiyuan
>
This reverts commit ef8dd37af85a8f37ca3a29074647511e52c56181.
Will use cropped cursor image for -ve co-ordinates instead of using
swcursor. Advantages of cropped cursor being, it will work for non X11
based platform like Chrome and also will use hwcursor.
Signed-off-by: Akshu Agrawal
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote:
> This patch introduces the very basic framework of GVT-g device model,
> includes basic prototypes, definitions, initialization.
>
> v7:
> - Refine the URL link in Kconfig. (Joonas)
> - Refine the introduction of GVT-g host support in Kconfig.
CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
this we crop the cursor image for by -ve X value and thus use '0' as
least X value.
Signed-off-by: Akshu Agrawal
---
drivers/gpu/drm/i915/intel_display.c | 113 +++
On ke, 2016-06-08 at 08:08 +0100, Chris Wilson wrote:
> On Tue, Jun 07, 2016 at 11:18:43AM -0400, Zhi Wang wrote:
> >
> > This patch introduces an option for configuring the ring buffer size
> > of a LRC context after the context creation.
> >
> > Signed-off-by: Zhi Wang
>
On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote:
> CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
> this we crop the cursor image for by -ve X value and thus use '0' as
> least X value.
You're talking about "-ve" here and there's absolutely no "-ve" anywhere
On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote:
> The module init/exit routines are a wrapper around the PCI device
> init/exit, so move them across.
>
> Note that in order to avoid exporting the driver struct, instead of
> manipulating driver.features inside i915_init we instead opt to
On Fri, Jun 03, 2016 at 05:36:38PM +0100, Chris Wilson wrote:
> dma-buf provides a generic fence class for interoperation between
> drivers. Internally we use the request structure as a fence, and so with
> only a little bit of interfacing we can rebase those requests on top of
> dma-buf fences.
On Wed, Jun 08, 2016 at 10:42:58AM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:08:34PM +0100, Chris Wilson wrote:
> > We can forgo queuing the hangcheck from the start of every request to
> > until we wait upon a request. This reduces the overhead of every
> > request, but may
On pe, 2016-06-03 at 12:36 +, Tian, Kevin wrote:
> >
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Friday, May 27, 2016 7:32 PM
> >
> > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote:
> > >
> > > For me I think maybe i915 could save the snapshot for GVT,
On Fri, Jun 03, 2016 at 05:36:25PM +0100, Chris Wilson wrote:
> Just to see if anyone is awake this series takes us to the VMA leak fix.
> Just the tip of the iceberg when it comes to VMA fixes...
Read through it. I think it'd be good (although yes, painful) if we could
untangle the ring/engine
On Fri, Jun 03, 2016 at 05:55:25PM +0100, Chris Wilson wrote:
> Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for
> i915_gem_object_ggtt_pin(), spare us the confustion and remove it.
> Removing it now simplifies later patches to change the i915_vma_pin()
> (and friends)
On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote:
> >+static int intel_breadcrumbs_signaler(void *arg)
> >+{
> >+struct intel_engine_cs *engine = arg;
> >+struct intel_breadcrumbs *b = >breadcrumbs;
> >+struct signal *signal;
> >+
> >+/* Install ourselves with high
From: Ankitprasad Sharma
This patch series adds support for creating/using Stolen memory backed
objects.
Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory,
From: Chris Wilson
Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page
On Fri, Jun 03, 2016 at 05:55:42PM +0100, Chris Wilson wrote:
> We only need to take the struct_mutex if the object is pinned to the
> display engine and so requires checking for clflush. (The race with
> userspace pinning the object to a framebuffer is irrelevant.)
>
> v2: Use access once for
On Wed, Jun 08, 2016 at 11:57:21AM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:55:37PM +0100, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
>
> Shouldn't we only do this as a last resort, i.e. in the oom notifier?
> Commit message is a bit sparse on
On Wed, Jun 08, 2016 at 11:59:25AM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:55:42PM +0100, Chris Wilson wrote:
> > We only need to take the struct_mutex if the object is pinned to the
> > display engine and so requires checking for clflush. (The race with
> > userspace pinning the
On Wed, Jun 08, 2016 at 12:02:01PM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote:
> > Since we are not concerned with userspace racing itself with set-tiling
> > (the order is indeterminant even if we take a lock), then we can safely
> > read back the
On 08/06/16 09:40, Daniel Vetter wrote:
On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote:
CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
this we crop the cursor image for by -ve X value and thus use '0' as
least X value.
You're talking about "-ve" here and
On 08/06/16 11:01, Chris Wilson wrote:
On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote:
On 03/06/16 17:08, Chris Wilson wrote:
With only a single callsite for intel_engine_cs->irq_get and ->irq_put,
we can reduce the code size by moving the common preamble into the
caller, and
From: Ville Syrjälä
Now that we have the output_types bitmask in the crtc state, we
can use it to indicate in which mode we want to drive the DDI
encoders. For pre-DDI output_types will instead indicate what
kind of cloning is being done, but as DDI platforms don't
From: Ville Syrjälä
Move the encoder cloning check to happen earlier in the modeset. The
main benefit will be that the debug output from a failed modeset will
be less confusing as output_types can not indicate an invalid
configuration during the later computation
From: Ville Syrjälä
has_dsi_encoder was introduced to indicate that the pipe is driving
a DSI encoder. Now that we have the output_types bitmask that can
tell us the same thing, let's just kill has_dsi_encoder.
v2: Rebase, handle BXT DSI transcoder, rewrote commit
From: Ville Syrjälä
INTEL_OUTPUT_DISPLAYPORT hsa been bugging me for a long time. It always
looks out of place besides INTEL_OUTPUT_EDP and INTEL_OUTPUT_DP_MST.
Let's just rename it to INTEL_OUTPUT_DP.
v2: Rebase
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Use the new output_types bitmask instead of has_dp_encoder.
To make it less oainlful provide a small helper
(intel_crtc_has_dp_encoder()) to do the bitsy stuff.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
A bunch of places still look for DP encoders manually. Just call
intel_crtc_has_dp_encoder(). Note that many of these places don't
look for EDP or DP_MST, but it's still fine to replace them because
* for audio we don't enable audio on eDP
From: Ville Syrjälä
With the output_types bitmask there's no need to loop through
the encoders anymore when checking for HDMI+non-HDMI cloning.
v2: Use output_types bitmask
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Since we now have the output_types bitmaks in the crtc state, there's no
need to iterate through all the encoders to see if an LVDS or SDVO/HDMI
encoder might be present.
Signed-off-by: Ville Syrjälä
---
On Mon, Jun 06, 2016 at 03:55:18PM +0100, Tvrtko Ursulin wrote:
>
> On 03/06/16 17:08, Chris Wilson wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >b/drivers/gpu/drm/i915/i915_irq.c
> >index 2a736f4a0fe5..4013ad92cdc6 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++
On Mon, Jun 06, 2016 at 04:34:27PM +0100, Tvrtko Ursulin wrote:
>
> On 03/06/16 17:08, Chris Wilson wrote:
> >If we flag the seqno as potentially stale upon receiving an interrupt,
> >we can use that information to reduce the frequency that we apply the
> >heavyweight coherent seqno read (i.e. if
On 08/06/16 10:35, Chris Wilson wrote:
On Mon, Jun 06, 2016 at 04:34:27PM +0100, Tvrtko Ursulin wrote:
On 03/06/16 17:08, Chris Wilson wrote:
If we flag the seqno as potentially stale upon receiving an interrupt,
we can use that information to reduce the frequency that we apply the
On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote:
> Since we are not concerned with userspace racing itself with set-tiling
> (the order is indeterminant even if we take a lock), then we can safely
> read back the single obj->tiling_mode and do the static lookup of
> swizzle mode
On Fri, Jun 03, 2016 at 05:55:47PM +0100, Chris Wilson wrote:
> The error state is purposefully racy as we expect it to be called at any
> time and so have avoided any locking whilst capturing the crash dump.
> However, with multi-engine GPUs and multiple CPUs, those races can
> manifest into
On Wed, Jun 08, 2016 at 11:14:23AM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:36:38PM +0100, Chris Wilson wrote:
> > static inline struct drm_i915_gem_request *
> > +to_request(struct fence *fence)
> > +{
> > + /* We assume that NULL fence/request are interoperable */
> > +
1 - 100 of 194 matches
Mail list logo