Some HW vblank counters reset due to power management events, which messes
up the vblank counting logic. This leads to screen freezes with user space
waiting on vblank events that may not occur if the counter keeps resetting.
For e.g., After the HW vblank counter resets
[9.007359] [drm:drm_upd
-ENXIO should be returned when operations are banned from changing
backing storage of objects without backing storage.
v3:
- Separate this patch from "Introduce GEM proxy" patch-set. (Joonas)
v2:
- update the patch description and subject to just mention objects w/o
backing storage, instead of
On 11/6/2017 5:43 PM, Chris Wilson wrote:
Quoting Sagar Arun Kamble (2017-11-05 13:39:40)
Before GT device suspend, i915 should release GuC client doorbells by
stopping doorbell controller snooping and doorbell deallocation through
GuC. They need to be acquired again on resume. This will also
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Monday, November 6, 2017 5:01 PM
> To: Zhang, Tina ; alex.william...@redhat.com;
> ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com;
> zhen...@linu
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, November 7, 2017 4:37 AM
> To: Gerd Hoffmann
> Cc: Zhang, Tina ; Tian, Kevin ;
> Daniel Vetter ; intel-gfx@lists.freedesktop.org;
> joonas.lahti...@linux.intel.com; linux-ker...@vger.kernel.
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Monday, November 6, 2017 6:57 PM
> To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi
> A ; dan...@ffwll.ch; ch...@chris-wilson.co.uk
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Joonas Lahtinen
> Sent: Monday, November 6, 2017 7:24 PM
> To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi
> A ; dan...@ffwll.ch; ch...@chris-wilson.co.uk
> Cc: Daniel Vette
From: Jyoti Yadav
Added few subtests to cover below gaps.
1. scaler with pixelformat and tiling.
2. scaler with rotation
3. scaler with multiple planes
4. scaler with multi pipe
5. scaler with clipping/clamping scenario
Signed-off-by: Jyoti Yadav
---
tes
== Series Details ==
Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)
URL : https://patchwork.freedesktop.org/series/33087/
State : failure
== Summary ==
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-hsw) fdo#99912
Test kms_
== Series Details ==
Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)
URL : https://patchwork.freedesktop.org/series/33087/
State : success
== Summary ==
Series 33087v4 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
https://patchwork.freedesktop.org/api/1
This patch, along with the respective ones for Mesa, does fix the gl
timestamp query piglit failures on CNL. So it is
Tested-by: Rafael Antognolli
On Thu, Nov 02, 2017 at 04:29:46PM +, Lionel Landwerlin wrote:
> We use to have this fixed per generation, but starting with CNL userspace
> cann
Since GLK, some plane configuration settings have moved to the
PLANE_COLOR_CTL register. Refactor handling of the register to work like
PLANE_CTL. This also allows us to fix the set/read of the plane Alpha
Mode for GLK+.
v2: Adjust ordering of platform checks to be newest->oldest, drop
redundant c
This driver can use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
I'm resending to get a CI run.
Noralf.
drivers/gpu/drm/i915/intel_display.c | 2 +
== Series Details ==
Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev3)
URL : https://patchwork.freedesktop.org/series/33087/
State : failure
== Summary ==
Series 33087v3 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
https://patchwork.freedesktop.org/api/1
== Series Details ==
Series: drm/i915: Deconstruct struct sgt_dma initialiser
URL : https://patchwork.freedesktop.org/series/33291/
State : warning
== Summary ==
Series 33291v1 drm/i915: Deconstruct struct sgt_dma initialiser
https://patchwork.freedesktop.org/api/1.0/series/33291/revisions/1/m
gcc-4.4 complains about:
struct sgt_dma iter = {
.sg = vma->pages->sgl,
.dma = sg_dma_address(iter.sg),
.max = iter.dma + iter.sg->length,
};
drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen8_ppgtt_insert_4lvl’:
drivers/gpu/drm/
On Mon, 06 Nov 2017 10:05:34 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > > I thought we had agreed to make this behave similar to
> > > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id
> > > and
> > > return the file descriptor as the ioctl return value. Thanks,
> >
> > If we fo
On 11/06/2017 12:16 AM, Sagar Arun Kamble wrote:
Please update the subject to "Implement dynamic WOPCM partitioning"
Also, commit description should be written in present tense form.
Will update it in v2.
On 11/4/2017 5:48 AM, Jackie Li wrote:
Static WOPCM partitioning would lead to GuC loadi
Em Seg, 2017-11-06 às 16:16 -0200, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni writes:
>
> > Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi
> > escreveu:
> > > knowing the assertion triggered on wait_until_enabled() is not
> > > that
> > > useful without knowing what exactly caus
== Series Details ==
Series: tests/kms_plane_scaling: Fix off-by-one plane selection
URL : https://patchwork.freedesktop.org/series/33277/
State : success
== Summary ==
Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
fail -> PASS (shard-hsw) fdo#1
On 11/06/2017 03:59 AM, Joonas Lahtinen wrote:
On Fri, 2017-11-03 at 11:09 -0700, Oscar Mateo wrote:
This is for WAs that need to touch registers that get saved/restored
together with the logical context. The idea is that WAs are "pretty"
static, so a table is more declarative than a programma
== Series Details ==
Series: tests/kms_plane_scaling: Fix off-by-one plane selection
URL : https://patchwork.freedesktop.org/series/33277/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
b9f2abda9503bd55690cf3c2ccf2f20e8fc19ab3 tests/gem_eio: Nerf in-flight-
Hey Gabriel,
I've reviewed and pushed this patch.
Thanks.
Rob.
On Mon, 2017-11-06 at 16:28 -0200, Gabriel Krisman Bertazi wrote:
> Commit ca20170afc6f ("tests/kms_plane_scaling: Add support for
> dynamic
> number of planes") shifted the tested planes by one after the
> refactoring, accidentally
Commit ca20170afc6f ("tests/kms_plane_scaling: Add support for dynamic
number of planes") shifted the tested planes by one after the
refactoring, accidentally ignoring the first plane, which is zero
indexed. A symptom of the issue appears on KBL, where the third plane
is already the shared cursor,
On 11/06/2017 05:24 AM, Ville Syrjälä wrote:
On Fri, Nov 03, 2017 at 05:01:09PM -0700, Jackie Li wrote:
Static WOPCM partitioning would lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.
This patch enabled the dynamical calculation of the
Paulo Zanoni writes:
> Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi escreveu:
>> knowing the assertion triggered on wait_until_enabled() is not that
>> useful without knowing what exactly caused the failure. It might be
>> an
>> user error, like too little stolen memory by the bios
On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Try to fix the code to actually clip the plane to the crtc bound
Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi escreveu:
> knowing the assertion triggered on wait_until_enabled() is not that
> useful without knowing what exactly caused the failure. It might be
> an
> user error, like too little stolen memory by the bios, or an actual
> issue in the
On Mon, Nov 06, 2017 at 04:43:17PM +0100, Maarten Lankhorst wrote:
> Op 06-11-17 om 15:06 schreef Ville Syrjälä:
> > On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote:
> >> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
> >>> Op 01-11-17 om 18:00 schreef Ville Syrjäl
Op 06-11-17 om 15:06 schreef Ville Syrjälä:
> On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote:
>> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
>>> Op 01-11-17 om 18:00 schreef Ville Syrjälä:
On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
Hi,
I see this on an 32-bit acer atom mini-laptop with -rc8+tip:
[2.399416] pipe B vblank wait timed out
[2.399506] [ cut here ]
[2.399533] WARNING: CPU: 1 PID: 22 at
/mnt/kernel/kernel/linux-2.6/drivers/gpu/drm/i915/intel_display.c:12176
intel_atomic_commit_
On Wed, Nov 01, 2017 at 04:20:56PM +0200, Jani Nikula wrote:
> We were recently bitten by drm_edid_to_eld() clearing the connector
> type, and us failing to set it back for DP. Here's a few ELD related
> patches to try to unify ELD handling and make it a bit simpler for
> drivers to get it right.
>
Quoting Ville Syrjälä (2017-11-06 14:43:12)
> On Mon, Nov 06, 2017 at 02:32:50PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2017-11-06 14:23:24)
> > > On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> > > > Ensure that we do not overwrite the cherryview power context by
> >
On Mon, Nov 06, 2017 at 02:32:50PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2017-11-06 14:23:24)
> > On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> > > Ensure that we do not overwrite the cherryview power context by
> > > reserving its range in the stolen allocator; exac
Quoting Ville Syrjälä (2017-11-06 14:23:24)
> On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> > Ensure that we do not overwrite the cherryview power context by
> > reserving its range in the stolen allocator; exactly like how we handle
> > the same reservation for valleyview.
>
> I
== Series Details ==
Series: drm/i915/guc: Assert ctch->vma is allocated
URL : https://patchwork.freedesktop.org/series/33257/
State : failure
== Summary ==
Series 33257v1 drm/i915/guc: Assert ctch->vma is allocated
https://patchwork.freedesktop.org/api/1.0/series/33257/revisions/1/mbox/
Test
On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> Ensure that we do not overwrite the cherryview power context by
> reserving its range in the stolen allocator; exactly like how we handle
> the same reservation for valleyview.
IIRC CHV pctx must live inside the "reserved" region. So
Quoting Michal Wajdeczko (2017-10-26 18:36:55)
> Include GuC and HuC firmware details in captured error state
> to provide additional debug information. To reuse existing
> uc firmware pretty printer, introduce new drm-printer variant
> that works with our i915_error_state_buf output. Also update
>
== Series Details ==
Series: drm/i915: Generalize transcoder looping (rev2)
URL : https://patchwork.freedesktop.org/series/32965/
State : failure
== Summary ==
Series 32965v2 drm/i915: Generalize transcoder looping
https://patchwork.freedesktop.org/api/1.0/series/32965/revisions/2/mbox/
Test
On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
> > Op 01-11-17 om 18:00 schreef Ville Syrjälä:
> > > On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
> > >> Op 01-11-17 om 16:29 schreef Ville Syrj
On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
> Op 01-11-17 om 18:00 schreef Ville Syrjälä:
> > On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
> >> Op 01-11-17 om 16:29 schreef Ville Syrjälä:
> >>> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst
Silence smatch by demonstrating that ctch->vma is allocated
following a successful chch_init()
drivers/gpu/drm/i915/intel_guc_ct.c:204 ctch_open() error:
we previously assumed 'ctch->vma' could be null (see line 197)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
dr
== Series Details ==
Series: series starting with [CI,1/8] drm/i915: Assert guc->stage_desc_pool is
allocated
URL : https://patchwork.freedesktop.org/series/33254/
State : failure
== Summary ==
Series 33254v1 series starting with [CI,1/8] drm/i915: Assert
guc->stage_desc_pool is allocated
ht
== Series Details ==
Series: drm/i915: Assert guc->stage_desc_pool is allocated
URL : https://patchwork.freedesktop.org/series/33248/
State : success
== Summary ==
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-hsw) fdo#99912
Test kms_flip:
Su
On Mon, Nov 06, 2017 at 11:48:33AM +, Chris Wilson wrote:
> Silence smatch by demonstrating that guc->stage_desc_pool is allocated
> following a successful guc_stage_desc_pool_create()
>
> drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init()
> error: we previously assume
As we now record the default HW state and so only emit the "golden"
renderstate once to prepare the HW, there is no advantage in keeping the
renderstate batch around as it will never be used again.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h
To make looping through transcoders in intel_ddi.c more generic, let's switch
to use 'for_each_pipe()' macro to do this.
v2: Add a notion that we are dealing with transcoders instead of pipes (Jani)
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_ddi.c | 11 +++
1 file changed
Silence smatch by demonstrating that guc->stage_desc_pool is allocated
following a successful guc_stage_desc_pool_create()
drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init()
error: we previously assumed 'guc->stage_desc_pool' could be null (see line 1261
Signed-off-by: Ch
From: Tvrtko Ursulin
We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: Chris Wilson
Cc
intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Mi
In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.
Historically, we omi
Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts wit
In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For
On Fri, Nov 03, 2017 at 05:01:09PM -0700, Jackie Li wrote:
> Static WOPCM partitioning would lead to GuC loading failure
> if the GuC/HuC firmware size exceeded current static 512KB
> partition boundary.
>
> This patch enabled the dynamical calculation of the WOPCM aperture
> used by GuC/HuC firmw
Quoting Joonas Lahtinen (2017-11-06 10:47:52)
> On Wed, 2017-10-25 at 16:32 +0100, Chris Wilson wrote:
> > Some tests are designed to exercise the limits of the HW and may trigger
> > unintended side-effects making the machine unusable. This should not be
> > executed by default, but are still usef
Quoting Mika Kuoppala (2017-11-06 11:46:16)
> Chris Wilson writes:
>
> > An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
> > stale object before a fresh allocation") was that not only do we have to
> > serialise concurrent users of llist_del_first(), but we also have to
> > l
== Series Details ==
Series: drm/i915: Lock llist_del_first() vs llist_del_all() (rev2)
URL : https://patchwork.freedesktop.org/series/33241/
State : success
== Summary ==
Test drv_module_reload:
Subgroup basic-reload-inject:
pass -> DMESG-WARN (shard-hsw) fdo#102
On Mon, 2017-11-06 at 12:42 +, Chris Wilson wrote:
> Quoting Oscar Mateo (2017-11-03 18:09:30)
> > This has grown to be a sizable amount of code, so move it to
> > its own file before we try to refactor anything. For the moment,
> > we are leaving behind the WA BB code and the WAs that get appl
Quoting Oscar Mateo (2017-11-03 18:09:30)
> This has grown to be a sizable amount of code, so move it to
> its own file before we try to refactor anything. For the moment,
> we are leaving behind the WA BB code and the WAs that get applied
> (incorrectly) in init_clock_gating, but we will deal with
Quoting Oscar Mateo (2017-11-03 18:09:29)
> GEN8_CONFIG0 (0xD00) is a protected by a lock (bit 31) which is set by
> the BIOS, so there is no way we can enable the three chicken bits
> mandated by the WA (the BIOS should be doing it instead).
>
> v2: Rebased
> v3: Standalone patch
>
> Signed-off-
== Series Details ==
Series: drm/i915: Assert guc->stage_desc_pool is allocated
URL : https://patchwork.freedesktop.org/series/33248/
State : success
== Summary ==
Series 33248v1 drm/i915: Assert guc->stage_desc_pool is allocated
https://patchwork.freedesktop.org/api/1.0/series/33248/revisions
== Series Details ==
Series: drm: i915: remove timeval users
URL : https://patchwork.freedesktop.org/series/33147/
State : failure
== Summary ==
Series 33147v1 drm: i915: remove timeval users
https://patchwork.freedesktop.org/api/1.0/series/33147/revisions/1/mbox/
Test kms_addfb_basic:
Quoting Sagar Arun Kamble (2017-11-05 13:39:40)
> Before GT device suspend, i915 should release GuC client doorbells by
> stopping doorbell controller snooping and doorbell deallocation through
> GuC. They need to be acquired again on resume. This will also resolve
> the driver unload issue with Gu
== Series Details ==
Series: drm/i915: Lock llist_del_first() vs llist_del_all() (rev2)
URL : https://patchwork.freedesktop.org/series/33241/
State : success
== Summary ==
Series 33241v2 drm/i915: Lock llist_del_first() vs llist_del_all()
https://patchwork.freedesktop.org/api/1.0/series/33241/
On Fri, 2017-11-03 at 11:09 -0700, Oscar Mateo wrote:
> This is for WAs that need to touch registers that get saved/restored
> together with the logical context. The idea is that WAs are "pretty"
> static, so a table is more declarative than a programmatic approah.
> Note however that some amount i
Silence smatch by demonstrating that guc->stage_desc_pool is allocated
following a successful guc_stage_desc_pool_create()
drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init()
error: we previously assumed 'guc->stage_desc_pool' could be null (see line 1261
Signed-off-by: Ch
Chris Wilson writes:
> An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
> stale object before a fresh allocation") was that not only do we have to
> serialise concurrent users of llist_del_first(), but we also have to
> lock llist_del_first() vs llist_del_all().
>
> From llist
On Mon, 06 Nov 2017, Joonas Lahtinen wrote:
> + Jani (and Daniel as emeritus maintainer)
>
> On Fri, 2017-11-03 at 10:08 -0700, Rodrigo Vivi wrote:
>> On Fri, Nov 03, 2017 at 08:36:01AM +, Joonas Lahtinen wrote:
>> > On Fri, 2017-11-03 at 00:03 +, Chris Wilson wrote:
>> > > Quoting Rodrigo
On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote:
> GEM proxy is a kind of GEM, whose backing physical memory is pinned
> and produced by guest VM and is used by host as read only. With GEM
> proxy, host is able to access guest physical memory through GEM object
> interface. As GEM proxy is such
An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
stale object before a fresh allocation") was that not only do we have to
serialise concurrent users of llist_del_first(), but we also have to
lock llist_del_first() vs llist_del_all().
From llist.h,
* This can be summarized as
An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
stale object before a fresh allocation") was that not only do we have to
serialise concurrent users of llist_del_first(), but we also have to
lock llist_del_first() vs llist_del_all().
From llist.h,
* This can be summarized as
== Series Details ==
Series: series starting with [v3,1/2] lib/gt: Mark up engine classes
URL : https://patchwork.freedesktop.org/series/33239/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
c8d1ea24d3bfaf11b223bbe22407aeca196d0d89 tests/debugfs_test: Prett
Hi Tina,
Please send this patch alone (or in the beginning of your series), so it can be
merged already.
That'll save you the effort of carrying this patch.
Regards, Joonas
On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote:
> -ENXIO should be returned when operations are banned from changing
== Series Details ==
Series: lib/gt: Mark up engine classes
URL : https://patchwork.freedesktop.org/series/33235/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
c8d1ea24d3bfaf11b223bbe22407aeca196d0d89 tests/debugfs_test: Pretty print
subdirectories
with
We introduce the concept of classes that each engine may belong to.
There may be more than one engine available in each class, but each
engine only belongs to one class. Each class has a unique set of
capabilities and purpose (e.g. 3D rendering or video decode), but
different engines within each cl
A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.
v2: extend back to Sandybridge, ignore non-priv registers that are not
context-saved (remind me w
On Wed, 2017-10-25 at 16:32 +0100, Chris Wilson wrote:
> Some tests are designed to exercise the limits of the HW and may trigger
> unintended side-effects making the machine unusable. This should not be
> executed by default, but are still useful for early platform validation.
>
> References: htt
Quoting Chris Wilson (2017-11-03 10:38:38)
> Quoting Ville Syrjälä (2017-11-03 10:25:17)
> > This problem doesn't seem like it should be specific to HSW. So I wonder
> > if we should start by just reverting that offending patch and move just
> > the watermark thing out to some earlier position in t
+ Jani (and Daniel as emeritus maintainer)
On Fri, 2017-11-03 at 10:08 -0700, Rodrigo Vivi wrote:
> On Fri, Nov 03, 2017 at 08:36:01AM +, Joonas Lahtinen wrote:
> > On Fri, 2017-11-03 at 00:03 +, Chris Wilson wrote:
> > > Quoting Rodrigo Vivi (2017-11-02 23:52:45)
> > > > On Wed, Oct 4, 20
We introduce the concept of classes that each engine may belong to.
There may be more than one engine available in each class, but each
engine only belongs to one class. Each class has a unique set of
capabilities and purpose (e.g. 3D rendering or video decode), but
different engines within each cl
On Sat, Nov 04, 2017 at 03:08:26PM +0100, Hans de Goede wrote:
> Ideally we could use the VBT for this, that would be simple, in
> intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
> connector->display_info.panel_orientation accordingly and call
> drm_connector_init_panel_orientation_p
On Sat, Nov 04, 2017 at 03:08:25PM +0100, Hans de Goede wrote:
> Apply the "panel orientation" drm connector prop to the primary plane so
> that fbcon and fbdev using userspace programs display the right way up.
>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
> Signed-off-by: Hans de
On Sat, Nov 04, 2017 at 03:08:24PM +0100, Hans de Goede wrote:
> On some devices the LCD panel is mounted in the casing in such a way that
> the up/top side of the panel does not match with the top side of the
> device (e.g. it is mounted upside-down).
>
> This commit adds the necessary infra for
On Sat, Nov 04, 2017 at 03:08:23PM +0100, Hans de Goede wrote:
> Some x86 clamshell design devices use portrait tablet screens and a display
> engine which cannot rotate in hardware, so the firmware just leaves things
> as is and we cannot figure out that the display is oriented non upright
> from
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Monday, November 6, 2017 4:49 PM
> To: Zhang, Tina ; alex.william...@redhat.com;
> ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com;
> zhen...@linu
Hi,
> > I thought we had agreed to make this behave similar to
> > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id
> > and
> > return the file descriptor as the ioctl return value. Thanks,
>
> If we follow VFIO_GROUP_GET_DEVICE_FD, we would lose flags
> functionality.
> Zhi an
Hi,
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + *struct
> vfio_device_query_gfx_plane)
> + *
> + * Set the drm_plane_type and flags, then retrieve the gfx plane
> info.
> + *
> + * flags supported:
> + * - VFIO_GFX_PLANE_TYPE
Hi,
> +static struct pixel_format bdw_pixel_formats[] = {
> + {DRM_FORMAT_C8, 8, "8-bit Indexed"},
> +static struct pixel_format skl_pixel_formats[] = {
> + {DRM_FORMAT_YUYV, 16, "16-bit packed YUYV (8:8:8:8 MSB-
> V:Y2:U:Y1)"},
Broadwell and Skylake.
What is the state for newer chips
Please update the subject to "Implement dynamic WOPCM partitioning"
Also, commit description should be written in present tense form.
On 11/4/2017 5:48 AM, Jackie Li wrote:
Static WOPCM partitioning would lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
part
90 matches
Mail list logo
