Chris Wilson writes:
> Since we coordinate with the execlists tasklet using a locked schedule
> operation that ensures that after we set the engine->irq_posted we
> always have an invocation of the tasklet, we do not need to use a locked
> operation to set the engine->irq_posted itself.
>
> Signe
Chris Wilson writes:
> My original intention was for i915_sw_fence to be the base class and
> provide the reference count for the container. This was from starting
> with a design to handle async_work. In practice, for i915 we embed
> fences into structs which have their own independent reference
On Thu, 11 May 2017, Daniel Vetter wrote:
> On Thu, May 11, 2017 at 12:57:20PM +0300, Jani Nikula wrote:
>> Face the fact, there are Display Port sink and branch devices out there
>> in the wild that don't follow the Display Port specifications, or they
>> have bugs, or just otherwise require spec
Chris Wilson writes:
> Explicitly assign the default priority, and give it a name. After much
> discussion, we have chosen to call it I915_PRIORITY_NORMAL!
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 1 +
> drivers/gpu/drm/i915
On Fri, May 12, 2017 at 10:43:31AM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > My original intention was for i915_sw_fence to be the base class and
> > provide the reference count for the container. This was from starting
> > with a design to handle async_work. In practice, for i915
Hi Matt,
Thanks for review,
On Friday 12 May 2017 05:51 AM, Matt Roper wrote:
On Mon, May 08, 2017 at 05:18:51PM +0530, Mahesh Kumar wrote:
This series implements new DDB allocation algorithm to solve the cases,
where we have sufficient DDB available to enable multiple planes, But
due to the
Hi,
On Friday 12 May 2017 05:52 AM, Matt Roper wrote:
On Mon, May 08, 2017 at 05:18:53PM +0530, Mahesh Kumar wrote:
This patch adds few wrapper to perform fixed_point_16_16 operations
mul_u32_fixed_16_16_round_up : Multiplies u32 and fixed_16_16_t
variables & re
Hi,
> If the contents of the framebuffer change or if the parameters of the
> framebuffer change? I can't image that creating a new dmabuf fd for
> every visual change within the framebuffer would be efficient, but I
> don't have any concept of what a dmabuf actually does.
Ok, some background:
From: Matthew Auld
If a vma is already bound to a ppgtt, we incorrectly call
allocate_va_range again when doing a PIN_UPDATE, which will result in
over accounting within our paging structures, such that when we do
unbind something we don't actually destroy the structures and end up
inadvertently
On Fri, May 12, 2017 at 10:14:23AM +0100, Chris Wilson wrote:
> From: Matthew Auld
>
> If a vma is already bound to a ppgtt, we incorrectly call
> allocate_va_range again when doing a PIN_UPDATE, which will result in
> over accounting within our paging structures, such that when we do
> unbind so
Add full ppgtt capability check in guest i915 driver and enable the full
ppgtt in guest only when device mode supports.
Changes since v1:
- Use u32 instead of uint32_t. (Joonas)
- Rewrite the vgpu full ppgtt capability checking logic. (Joonas)
- Some coding style refine. (Joonas)
Signed-off-by: T
This patch is to provide full ppgtt capability for guest i915 driver.
Changes since v1:
- Move VGT_CAPS_FULL_PPGTT introduction to patch 2/4. (Joonas)
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/i915/gvt/vgpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.
This patchset fixs guest i915 full ppgtt block issue in device model and
enables the full ppgtt functionality to guest i915 driver when device model
with the fixed patch can support this capability.
Changes since last version:
- Refine code with coding style.
- Rewrite the guest vgpu full ppgtt ch
vgt_caps is used for guest i915 driver to get the vgpu capabilities from
the device model. VGT_CPAS_FULL_PPGTT is one of the capabilities type to
let guest i915 dirver know that the guest i915 full ppgtt is supported by
device model.
Changes since v1:
- Use u32 instead of uint32_t (Joonas)
- Move
Guest i915 driver may update the ppgtt table just before this workload
is going to be submitted to the hardware by device model. This case
wasn't handled well by device model before, due to the small time
window between removing old ppgtt entry and adding the new one. Errors
occur when the workload
On Thu, May 11, 2017 at 06:07:42PM +0800, Chuanxiao Dong wrote:
> initialised is fixup by the GVT shadow context as true to avoid the init
> from the host because it cannot take the settings from the host. Add a
> check to let host driver only overwrite it when the init callback is NULL
During exe
On Fri, May 12, 2017 at 10:49:24AM +0100, Chris Wilson wrote:
> On Thu, May 11, 2017 at 06:07:42PM +0800, Chuanxiao Dong wrote:
> > initialised is fixup by the GVT shadow context as true to avoid the init
> > from the host because it cannot take the settings from the host. Add a
> > check to let ho
From: Chuanxiao Dong
During execlist_context_deferred_alloc() we presumed that the context is
uninitialised (we only just allocated the state object for it!) and
chose to optimise away the later call to engine->init_context() if
engine->init_context were NULL. This breaks with GVT's contexts that
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, May 12, 2017 6:11 PM
> To: Dong, Chuanxiao ; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: set initialised only when
> init_c
On 12 May 2017 at 10:31, Chris Wilson wrote:
> On Fri, May 12, 2017 at 10:14:23AM +0100, Chris Wilson wrote:
>> From: Matthew Auld
>>
>> If a vma is already bound to a ppgtt, we incorrectly call
>> allocate_va_range again when doing a PIN_UPDATE, which will result in
>> over accounting within our
== Series Details ==
Series: drm/i915: don't do allocate_va_range again on pin update
URL : https://patchwork.freedesktop.org/series/24342/
State : warning
== Summary ==
Series 24342v1 drm/i915: don't do allocate_va_range again on pin update
https://patchwork.freedesktop.org/api/1.0/series/243
When running testlist for CI iot would be good to know if
the state of the GPU is as expected. This adds a subtest to check
if the GPU is wedged.
Signed-off-by: Marta Lofstedt
---
tests/Makefile.sources| 1 +
tests/initial_state.c | 52 +++
Thanks Chris! Have a nice weekend. :)
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, May 12, 2017 6:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Dong, Chuanxiao ; Chris Wilson
>
> Subject: [PATCH v2] drm/i915: set initialised only when ini
== Series Details ==
Series: Enable guest linux i915 full ppgtt functionality (rev2)
URL : https://patchwork.freedesktop.org/series/24271/
State : success
== Summary ==
Series 24271v2 Enable guest linux i915 full ppgtt functionality
https://patchwork.freedesktop.org/api/1.0/series/24271/revisi
This basically reverts commit 465418c6064c
("drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7")
with small addition - marking it as affecting KBL as well.
It was incorrectly considered fixed in production steppings.
References: HSD#2126385, HSD#2131381, HSDES#1504433555, BSID#0764
Cc:
Constructing the name takes the majority of the time for allocating a
sync_file to wrap a fence, and the name is very rarely used (only via
the sync_file status user interface). To reduce the impact on the common
path (that of creating sync_file to pass around), defer the construction
of the name u
== Series Details ==
Series: drm/i915: set initialised only when init_context callback is NULL (rev2)
URL : https://patchwork.freedesktop.org/series/24286/
State : success
== Summary ==
Series 24286v2 drm/i915: set initialised only when init_context callback is NULL
https://patchwork.freedeskt
On Fri, May 12, 2017 at 11:34:21AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: set initialised only when init_context callback is NULL
> (rev2)
> URL : https://patchwork.freedesktop.org/series/24286/
> State : success
>
> == Summary ==
>
> Series 24286v2 drm/i915: set
== Series Details ==
Series: drm/i915/gen9: Reintroduce WaEnableYV12BugFixInHalfSliceChicken7
URL : https://patchwork.freedesktop.org/series/24351/
State : success
== Summary ==
Series 24351v1 drm/i915/gen9: Reintroduce WaEnableYV12BugFixInHalfSliceChicken7
https://patchwork.freedesktop.org/ap
From: Tvrtko Ursulin
The high level goal of this script is to programatically analyze
the simulated media workloads (gem_wsim) by finding an optimal
load balancing strategy, and also detecting any possible
shortcomings of the same.
When run without command line arguments script will run through
Chris Wilson writes:
> My original intention was for i915_sw_fence to be the base class and
> provide the reference count for the container. This was from starting
> with a design to handle async_work. In practice, for i915 we embed
> fences into structs which have their own independent reference
Arkadiusz Hiler writes:
> This basically reverts commit 465418c6064c
> ("drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7")
> with small addition - marking it as affecting KBL as well.
s/KBL/GLK
Reviewed-by: Mika Kuoppala
>
> It was incorrectly considered fixed in production steppi
On Fri, May 12, 2017 at 11:01:02AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: don't do allocate_va_range again on pin update
> URL : https://patchwork.freedesktop.org/series/24342/
> State : warning
>
> == Summary ==
>
> Series 24342v1 drm/i915: don't do allocate_va_r
On Tue, May 9, 2017 at 9:02 AM, Lv Zheng wrote:
> Since notification side has been changed to always notify kernel listeners
> using _LID returning value. Now listeners needn't invoke acpi_lid_open(),
> it should use a spec suggested control method lid device usage model:
> register lid notificati
Hi Lv,
I am trying to reduce the number of parallel discussion we have on the
same subject, but there is something here I can't let you have.
On Fri, May 12, 2017 at 8:08 AM, Zheng, Lv wrote:
> Hi,
>
> If my previous reply is not persuasive enough.
> Let me do that in a different way.
>
>> From:
Hi Chris,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.11 next-20170512]
[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/dma-buf-sync-file-Defer-creation
The commit name "Add a test to capture the state of the GPU" should
likely be renamed to "Add a test that checks the current state of the
driver".
On 12/05/17 14:07, Marta Lofstedt wrote:
When running testlist for CI iot would be good to know if
iot -> it
the state of the GPU is as expecte
On Fri, 12 May 2017, "Pandiyan, Dhinakaran"
wrote:
> On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
>> There are some panel that
>> (1) does not support display backlight enable via AUX
>> (2) support display backlight adjustment via AUX
>> (3) support display backlight enable v
On Fri, May 12, 2017 at 04:08:48PM +0300, Martin Peres wrote:
> The commit name "Add a test to capture the state of the GPU" should
> likely be renamed to "Add a test that checks the current state of
> the driver".
>
> On 12/05/17 14:07, Marta Lofstedt wrote:
> >When running testlist for CI iot wo
On Friday 12 May 2017 05:53 AM, Matt Roper wrote:
On Mon, May 08, 2017 at 05:18:58PM +0530, Mahesh Kumar wrote:
DDB minimum requirement may exceed the allocated DDB for CRTC/Pipe. This
patch make changes to fail the flip if minimum requirement for pipe
exceeds the total ddb allocated to the pi
Hi,
On Friday 12 May 2017 05:53 AM, Matt Roper wrote:
On Mon, May 08, 2017 at 05:18:59PM +0530, Mahesh Kumar wrote:
This patch cleanup/reorganises the watermark calculation functions.
This patch also make use of already available macro
"drm_atomic_crtc_state_for_each_plane_state" to walk throu
Currently the timer is armed for 1ms after the first use and is killed
immediately, dropping the forcewake as early as possible. However, for
very frequent operations the forcewake dance has a large impact on
latency and keeping the timer alive until we are idle is preferred. To
achieve this, if we
Storing both the mask and the id is redundant as we can trivially
compute one from the other. As the mask is more frequently used, remove
the id.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.
Hi Chris,
Thanks for the patch!
2017-05-12 Chris Wilson :
> Constructing the name takes the majority of the time for allocating a
> sync_file to wrap a fence, and the name is very rarely used (only via
> the sync_file status user interface). To reduce the impact on the common
> path (that of cre
== Series Details ==
Series: series starting with [1/2] drm/i915: Compute the fw_domain id from the
mask
URL : https://patchwork.freedesktop.org/series/24359/
State : failure
== Summary ==
Series 24359v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24359/revisi
In earlier patch 789a625 we were enabling send function only
after successful init. For completeness, we should make sure
that we disable it on fini.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 3 +++
1
Buffer based command transport can replace MMIO based mechanism.
It may be used to perform host-2-guc and guc-to-host communication.
Portions of this patch are based on work by:
Michel Thierry
Robert Beckett
Daniele Ceraolo Spurio
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
This is just for CI testing, *** DO NOT MERGE ***
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..abd2894 100
On Fri, May 12, 2017 at 03:02:58PM +, Michal Wajdeczko wrote:
> In earlier patch 789a625 we were enabling send function only
> after successful init. For completeness, we should make sure
> that we disable it on fini.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Joonas Lahtinen
> Cc: Daniele Ce
On Fri, May 12, 2017 at 04:17:00PM +0100, Chris Wilson wrote:
> On Fri, May 12, 2017 at 03:02:58PM +, Michal Wajdeczko wrote:
> > In earlier patch 789a625 we were enabling send function only
> > after successful init. For completeness, we should make sure
> > that we disable it on fini.
> >
>
== Series Details ==
Series: series starting with [1/3] drm/i915/guc: Disable send function on fini
URL : https://patchwork.freedesktop.org/series/24363/
State : success
== Summary ==
Series 24363v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24363/revisions/1/
On Fri, May 12, 2017 at 03:02:59PM +, Michal Wajdeczko wrote:
> Buffer based command transport can replace MMIO based mechanism.
> It may be used to perform host-2-guc and guc-to-host communication.
Hmm, sad to see a ringbuffer used for synchronous comms.
> Portions of this patch are based on
On Fri, 12 May 2017 11:12:05 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > If the contents of the framebuffer change or if the parameters of the
> > framebuffer change? I can't image that creating a new dmabuf fd for
> > every visual change within the framebuffer would be efficient, but I
> > don't
On Fri, 12 May 2017 06:56:03 +
"Chen, Xiaoguang" wrote:
> Hi Gerd,
>
> >-Original Message-
> >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> >Behalf Of Gerd Hoffmann
> >Sent: Thursday, May 11, 2017 9:28 PM
> >To: Chen, Xiaoguang
> >Cc: Tian, Kevin ; in
On 5/10/2017 12:45 PM, Daniel Vetter wrote:
On Wed, May 10, 2017 at 10:38 AM, Tvrtko Ursulin
wrote:
On 09/05/2017 19:11, Dmitry Rogozhkin wrote:
On 5/9/2017 8:51 AM, Tvrtko Ursulin wrote:
On 09/05/2017 16:29, Chris Wilson wrote:
On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrot
We have always excluded the top-page of the Global GTT to prevent
prefetching past the end of the address space. We have been lax about
applying this restriction to the per-process GTT, but there is no reason
to believe that the hw restriction is any less severe.
Signed-off-by: Chris Wilson
---
On Fri, May 12, 2017 at 06:49:09PM +0100, Chris Wilson wrote:
> We have always excluded the top-page of the Global GTT to prevent
> prefetching past the end of the address space. We have been lax about
> applying this restriction to the per-process GTT, but there is no reason
> to believe that the
On Fri, May 12, 2017 at 6:14 AM, Jani Nikula
wrote:
> On Fri, 12 May 2017, "Pandiyan, Dhinakaran"
> wrote:
> > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
> >> There are some panel that
> >> (1) does not support display backlight enable via AUX
> >> (2) support display backl
== Series Details ==
Series: drm/i915: Exclude top-page for ppgtt as well as ggtt
URL : https://patchwork.freedesktop.org/series/24366/
State : success
== Summary ==
Series 24366v1 drm/i915: Exclude top-page for ppgtt as well as ggtt
https://patchwork.freedesktop.org/api/1.0/series/24366/revis
On Fri, May 12, 2017 at 04:52:04PM +0100, Chris Wilson wrote:
> On Fri, May 12, 2017 at 03:02:59PM +, Michal Wajdeczko wrote:
> > Buffer based command transport can replace MMIO based mechanism.
> > It may be used to perform host-2-guc and guc-to-host communication.
>
> Hmm, sad to see a ringb
Constructing the name takes the majority of the time for allocating a
sync_file to wrap a fence, and the name is very rarely used (only via
the sync_file status user interface). To reduce the impact on the common
path (that of creating sync_file to pass around), defer the construction
of the name u
On 12 May 2017 at 18:49, Chris Wilson wrote:
> We have always excluded the top-page of the Global GTT to prevent
> prefetching past the end of the address space. We have been lax about
> applying this restriction to the per-process GTT, but there is no reason
> to believe that the hw restriction i
On Fri, May 12, 2017 at 08:53:15PM +0200, Michal Wajdeczko wrote:
> On Fri, May 12, 2017 at 04:52:04PM +0100, Chris Wilson wrote:
> > On Fri, May 12, 2017 at 03:02:59PM +, Michal Wajdeczko wrote:
> > > + if (!ctch->vma) {
> > > + /* allocate vma */
> > > + vma = intel_guc_alloca
On Fri, May 12, 2017 at 06:55:35PM +0100, Chris Wilson wrote:
> On Fri, May 12, 2017 at 06:49:09PM +0100, Chris Wilson wrote:
> > We have always excluded the top-page of the Global GTT to prevent
> > prefetching past the end of the address space. We have been lax about
> > applying this restriction
== Series Details ==
Series: dma-buf/sync-file: Defer creation of sync_file->name (rev2)
URL : https://patchwork.freedesktop.org/series/24353/
State : success
== Summary ==
Series 24353v2 dma-buf/sync-file: Defer creation of sync_file->name
https://patchwork.freedesktop.org/api/1.0/series/2435
On Fri, 2017-05-12 at 11:10 -0700, Puthikorn Voravootivat wrote:
>
>
> On Fri, May 12, 2017 at 6:14 AM, Jani Nikula
> wrote:
> On Fri, 12 May 2017, "Pandiyan, Dhinakaran"
> wrote:
> > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat
> wrote:
> >>
trace_i915_gem_evict_everything and trace_i915_gem_ring_flush stopped
being used when their parent functions were removed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_trace.h | 72 +--
1 file changed, 17 insertions(+), 55 deletions(-)
diff --git
The tracepoints need some tlc, in particular we've neglected to update
them for the 64b era.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_trace.h | 42 +++
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_t
On 12/05/17 12:06, Chris Wilson wrote:
On Fri, May 12, 2017 at 06:55:35PM +0100, Chris Wilson wrote:
On Fri, May 12, 2017 at 06:49:09PM +0100, Chris Wilson wrote:
We have always excluded the top-page of the Global GTT to prevent
prefetching past the end of the address space. We have been lax
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix some tracepoints to capture
full 64b
URL : https://patchwork.freedesktop.org/series/24374/
State : success
== Summary ==
Series 24374v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24374/revi
On 5/8/2017 11:31 AM, Michel Thierry wrote:
On 4/29/2017 7:19 AM, Chris Wilson wrote:
On Thu, Apr 27, 2017 at 04:12:42PM -0700, Michel Thierry wrote:
From: Arun Siluvery
...
+}
+
intel_prepare_reset(dev_priv);
set_bit(I915_RESET_HANDOFF, &dev_priv->gpu_error.flags);
@@ -2680,
On Fri, May 12, 2017 at 01:55:11PM -0700, Michel Thierry wrote:
> On 5/8/2017 11:31 AM, Michel Thierry wrote:
> >On 4/29/2017 7:19 AM, Chris Wilson wrote:
> >>On Thu, Apr 27, 2017 at 04:12:42PM -0700, Michel Thierry wrote:
> >>>From: Arun Siluvery
> >>>
> ...
> >>>+}
> >>>+
> >>> intel_pre
On 5/12/2017 2:09 PM, Chris Wilson wrote:
On Fri, May 12, 2017 at 01:55:11PM -0700, Michel Thierry wrote:
On 5/8/2017 11:31 AM, Michel Thierry wrote:
On 4/29/2017 7:19 AM, Chris Wilson wrote:
On Thu, Apr 27, 2017 at 04:12:42PM -0700, Michel Thierry wrote:
From: Arun Siluvery
...
+}
Currently the timer is armed for 1ms after the first use and is killed
immediately, dropping the forcewake as early as possible. However, for
very frequent operations the forcewake dance has a large impact on
latency and keeping the timer alive until we are idle is preferred. To
achieve this, if we
On Mon, May 08, 2017 at 05:19:01PM +0530, Mahesh Kumar wrote:
> This patch implements new DDB allocation algorithm as per HW team
> recommendation. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to work.
> It al
== Series Details ==
Series: series starting with [1/2] drm/i915: Compute the fw_domain id from the
mask (rev2)
URL : https://patchwork.freedesktop.org/series/24359/
State : warning
== Summary ==
Series 24359v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24359
On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
> Read desired PWM frequency from panel vbt and calculate the
> value for divider in DPCD address 0x724 and 0x728 to have
> as many bits as possible for PWM duty cyle for granularity of
> brightness adjustment while the frequency is s
On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:
> On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
> > Read desired PWM frequency from panel vbt and calculate the
> > value for divider in DPCD address 0x724 and 0x728 to have
> > as many
78 matches
Mail list logo
