Update kernel interface with new I915_GETPARAM ioctl entries for
pooled EU and min no. of eus in a pool. Add a wrapping function
for each parameter. Userspace drivers need these values when decide
the thread count. This kernel enabled pooled eu by default for BXT
and for fused down 2x6 parts it is
If BXT pooled EU enable, the 3*6 EUs is split into 2 pooled, so change
the sub slice to 2.
For min no. of eu in pool, only affact fused down 2*6 BXT devices,
because beignet don't support these devices now, add assert only.
assert.
This patch is based on kernel patch:
https://patchwork.freedeskto
== Series Details ==
Series: drm/i915: Serialise presentation with imported dmabufs (rev2)
URL : https://patchwork.freedesktop.org/series/8689/
State : failure
== Summary ==
Series 8689v2 drm/i915: Serialise presentation with imported dmabufs
http://patchwork.freedesktop.org/api/1.0/series/868
Op 14-06-16 om 23:52 schreef Matt Roper:
> On Wed, Jun 08, 2016 at 05:22:41PM +0200, Chi Ding wrote:
>> From: Maarten Lankhorst
>>
>> This commit saves watermark for each plane in vlv_wm_state to prepare
>> for two-level watermark because we'll compute and save intermediate and
>> optimal watermar
== Series Details ==
Series: Cruft removal around drm_master
URL : https://patchwork.freedesktop.org/series/8700/
State : success
== Summary ==
Series 8700v1 Cruft removal around drm_master
http://patchwork.freedesktop.org/api/1.0/series/8700/revisions/1/mbox
Test kms_flip:
Subgroup b
Hi all,
Booting 4.6.2 on a Dell XPS 15 9550, nouveau dynamically powers down
the discrete GPU [1], tripping an interesting i915 warning [2].
Let me know if more information or debug is useful!
Thanks,
Daniel
-- [1]
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::00:02.0
1:DIS:
> From: Wang, Zhi A
> Sent: Tuesday, June 14, 2016 9:21 PM
>
> 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 wi
On Tue, 2016-06-14 at 00:09 +, Vivi, Rodrigo wrote:
> On Wed, 2016-06-08 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> > PSR in CHV, unlike HSW, can get activated even if vblanks interrupts
> > are
> > enabled. But, the pipe is not expected to generate timings signals
> > when PSR is active. Spe
On Mon, 2016-05-23 at 10:57 +0200, Patrik Jakobsson wrote:
> On Wed, May 18, 2016 at 01:24:12PM +0300, Mika Kuoppala wrote:
> > Patrik Jakobsson writes:
> >
> > > [ text/plain ]
> > > Load specific firmware versions for the DMC instead of using
> > > symbolic
> > > links. The currently recommende
On Tue, Jun 14, 2016 at 07:40:54AM -0700, Ding, ChiX wrote:
> Hi Maarten
> Thanks for the reply. Please correct me if I'm wrong :
> If the intermediate watermark is bigger than any of the old and the new, then
> it's not really safe.
> It could be bigger than the FIFO size.
>
> I did some tests
On Wed, Jun 08, 2016 at 05:22:43PM +0200, Chi Ding wrote:
> From: Maarten Lankhorst
>
This patch needs a commit message. Those of us actively working on
watermarks right now understand the end goal for two-stage watermarks,
but I don't think most other developers looking at this code (or
bisect
On Wed, Jun 08, 2016 at 05:22:42PM +0200, Chi Ding wrote:
> From: Maarten Lankhorst
>
> This commit changs some functions to operate on intel_crtc_state rather
> than the base CRTC objects in order to transit to atomic
I'd add a little bit more justification to this message.
The reason we want
On Wed, Jun 08, 2016 at 05:22:41PM +0200, Chi Ding wrote:
> From: Maarten Lankhorst
>
> This commit saves watermark for each plane in vlv_wm_state to prepare
> for two-level watermark because we'll compute and save intermediate and
> optimal watermark and fifo size for each plane.
>
> Signed-off
Hi Dave,
More misc stuff all over:
- best_encoder cleanup from Boris.
- drm_simple_display_pipe helpers from Noralf. Looks really neat imo, and
there's 2-3 in-flight drivers which look like they could/should use it.
Anyway, with this we have now helpers and everything in place to write
drive
Hi Dave,
Jani's out sick, so pull request from me as an exception. Most of it
prepped by Jani, I just smashed Lyude's fix on top. Pretty much all
regression fixes, or black screens.
There's the 8/6bpc dither regression fix from Mario outstanding - I pinged
you about acking the drm core part earli
obj->base.dma_buf represents a dma-buf exported from this object (for
use by others). On the contrary, obj->base.import_attach represents the
source dma-buf that was used to create this object (if any). When
serialising with third parties, we need to wait on their rendering via
the import attachmen
On Tue, Jun 14, 2016 at 05:45:24PM +0200, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 04:03:57PM +0100, Chris Wilson wrote:
> > obj->base.dma_buf represents a dma-buf exported from this object (for
> > use by others). On the contrary, ob->base.import_attach represents the
> > source dma-buf that
Like with drm_master_open protect it with a check for primary_client
to make it clear that this can't happen on render/control nodes.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 37 +
drivers/gpu/drm/drm_fops.c | 35 ++
There can only be one current master, and it's for the overall device.
Render/control minors don't support master-based auth at all.
This simplifies the master logic a lot, at least in my eyes: All these
additional pointer chases are just confusing.
While doing the conversion I spotted some locki
Master-based auth only exists for the legacy/primary drm_minor, hence
there can only be one per device. The goal here is to untangle the
epic dereference games of minor->master and master->minor which is
just massively confusing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c |
It's related, and soon authmagic will also use the master_mutex.
There is an ever-so-slightly semantic change here:
- authmagic will only be cleaned up for primary_client drm_minors. But
it's impossible to create authmagic on render/control nodes, so this
is fine.
- The cleanup is moved down a
Again this is neatly protected by the dev->master_mutex now. There is
a driver callback both for set and drop, but it's only used by vmwgfx.
And vmwgfx has it's own solid locking for shared resources (besides
dev->master_mutex), hence is all safe. Let's drop another place where
the drm legacy bkl i
Lots of arm drivers get this wrong and for most arm boards this is the
right thing actually. And anyway with most loaders you want to chase
sysfs links anyway to figure out which dri device you want.
This will fix dmesg noise for rockchip and sti.
Also add a fallback to driver->name for entirely
- Group declarations for separate files (drm_bridge.c, drm_edid.c)
- Move declarations only used within drm.ko to drm_crtc_internal.h
- drm_property_type_valid to drm_crtc.c, its only callsite
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 7 ++
drivers/gpu/drm/drm_crtc
All protected by dev->master_mutex. And there's no driver callbacks,
which means no need to sync with old dri1 horror show drivers at all.
Hence safe to drop the drm legacy BKL from these paths.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+
Simplifies cleanup, and there's no reason drivers should ever care
about authmagic at all - it's all handled in the core.
And with that, Ladies and Gentlemen, it's time to pop the champagen
and celebrate: dev->struct_mutex is now officially gone from modern
drivers, and if a driver is using gem_fr
GEM stopped using those a while ago, and no one should ever
need to use them again to debug legacy horror show drivers.
Nuke it all. Aside: It would kinda be nice if we'd have some
generic debugfs dumps for at least kms ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs.c | 3 --
Another place gone where modern drivers could have hit
dev->struct_mutex.
To avoid too deeply nesting control flow rework it a bit.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/d
For modern drivers pretty much the only thing drm_master does is
handling authentication for the primary/legacy drm_minor node. Instead
of having it all over drm files, move it all together into drm_auth.c.
This patch just does code-motion, follow up patches will also extract
the master logic from
A few things:
- Rename the cleanup function from drm_master_release to
drm_legacy_lock_release. It doesn't relase any master stuff, but
just the legacy hw lock.
- Hide it in drm_lock.c, which allows us to make a few more functions
static in there. To avoid forward decl we need to shuffle the
And pull out the primary_client check to make it really obvious that
this can't happen on control/render nodes. Bonus that we can avoid the
master lock in this case.
v2: Don't leak locks on error path (and simplify control flow while
at it), reported by Julia.
Cc: Julia Lawall
Signed-off-by: Dan
Hi all,
These are the final bits of my dev->struct_mutex crusade, taking care of a few
things related to drm_master. Since I just couldnt' grok this dense web of
legacy dungeons, also includes some cleanups. On top of that also patches to
mark auth and master ioctls as DRM_UNLOCKED, which means th
Simply split intel_atomic_commit in half and place the new
nonblocking commit helpers at the right spots.
NOTE: There's still trouble with obj->frontbuffer bits getting mangled
when pipelining atomic commits.
v2:
- Remove the check for nonblocking which returned -EINVAL.
- Do wait for requests in
== Series Details ==
Series: drm/i915/ilk: Don't disable SSC source if it's in use
URL : https://patchwork.freedesktop.org/series/8690/
State : success
== Summary ==
Series 8690v1 drm/i915/ilk: Don't disable SSC source if it's in use
http://patchwork.freedesktop.org/api/1.0/series/8690/revisio
On Tue, Jun 14, 2016 at 08:27:57AM +0200, Maarten Lankhorst wrote:
> Op 13-06-16 om 16:45 schreef Daniel Vetter:
> > On Thu, Jun 09, 2016 at 01:36:50PM +0200, Maarten Lankhorst wrote:
> >> This will make it more likely that intermediary watermarks cause fifo
> >> underruns, which is useful when wri
On Tue, Jun 14, 2016 at 04:03:57PM +0100, Chris Wilson wrote:
> obj->base.dma_buf represents a dma-buf exported from this object (for
> use by others). On the contrary, ob->base.import_attach represents the
> source dma-buf that was used to create this object (if any). When
> serialising with third
== Series Details ==
Series: drm/i915: Serialise presentation with imported dmabufs
URL : https://patchwork.freedesktop.org/series/8689/
State : success
== Summary ==
Series 8689v1 drm/i915: Serialise presentation with imported dmabufs
http://patchwork.freedesktop.org/api/1.0/series/8689/revis
Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enabl
obj->base.dma_buf represents a dma-buf exported from this object (for
use by others). On the contrary, ob->base.import_attach represents the
source dma-buf that was used to create this object (if any). When
serialising with third parties, we want to wait on their rendering via
the import attachment
Regards
Shashank
On 6/14/2016 7:46 PM, Ville Syrjälä wrote:
On Mon, Jun 13, 2016 at 06:58:19PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The video DIP can be used with DP ports as well. So let's at least rea
On Mon, Jun 13, 2016 at 06:58:19PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The video DIP can be used with DP ports as well. So let's at least read
> > out the state, and disable all infoframe
The dmesg warning message issue has been reported at:
https://bugs.freedesktop.org/show_bug.cgi?id=96448
> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Tuesday, June 14, 2016 4:52 PM
> To: Wang, Zhi A
> Cc: intel-gfx@lists.freedesktop.org
> Subje
On 14/06/16 14:42, Dave Gordon wrote:
On 14/06/16 06:27, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: updates to GuC doorbell handling (rev2)
URL : https://patchwork.freedesktop.org/series/8553/
State : failure
== Summary ==
Series 8553v2 drm/i915/guc: updates to GuC doorbel
== Series Details ==
Series: Introduce the implementation of GVT context (rev9)
URL : https://patchwork.freedesktop.org/series/7208/
State : warning
== Summary ==
Series 7208v9 Introduce the implementation of GVT context
http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/9/mbox
Te
On 14/06/16 06:27, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: updates to GuC doorbell handling (rev2)
URL : https://patchwork.freedesktop.org/series/8553/
State : failure
== Summary ==
Series 8553v2 drm/i915/guc: updates to GuC doorbell handling
http://patchwork.freedesktop.
On 13/06/16 10:35, Tvrtko Ursulin wrote:
On 10/06/16 17:50, Dave Gordon wrote:
These registers are not actually writable by the CPU; only the GuC can
actually program them. So let's not do writes that have no effect.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c
This patch introduces an option for configuring the ring buffer size
of a LRC context after the context creation.
v9:
- Fix an identation issue. (Chris)
v8:
- Rename the data member in i915_gem_context. (Chris)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Z
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:
-
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 L
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, ri
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 configur
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
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Kevin Tian
Signed-off-by: Zhi Wang
--
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. (
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
Cc: Joonas Lahtinen
Signed-off-by: Zhi Wang
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 (Joo
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 cont
On 13/06/16 10:13, Tvrtko Ursulin wrote:
On 10/06/16 18:29, Dave Gordon wrote:
Convert all static functions in i915_guc_submission.c that currently
take a 'dev' pointer to take 'dev_priv' instead (there are three,
guc_client_alloc(), guc_client_free(), and gem_allocate_guc_obj().
Signed-off-by
On Tue, Jun 14, 2016 at 10:21:02AM +0200, Maarten Lankhorst wrote:
> Op 13-06-16 om 16:13 schreef Daniel Vetter:
> > This is part of what atomic must implement. And it's also required
> > to be able to use the helper nonblocking support.
> >
> > v2: Always send out the drm event, remove the planes_
On Tue, Jun 14, 2016 at 02:24:20PM +0200, Maarten Lankhorst wrote:
> The patch was reverted as part of the original nonblocking commit
> support, but is required for any kind of nonblocking commit.
>
> This is required to let fbc updates run async. It has a lot of
> checks whether certain locks ar
The patch was reverted as part of the original nonblocking commit
support, but is required for any kind of nonblocking commit.
This is required to let fbc updates run async. It has a lot of
checks whether certain locks are taken, which can be removed when
the relevant states are passed in as point
On 13/06/16 17:57, Dave Gordon wrote:
This version doesn't update the doorbell bitmap, as that will
be done when the selected doorbell is associated with a client.
The call is now slightly earlier, just on the general principle
that potentially-failing operations should be done as early as
poss
On 13/06/16 17:57, Dave Gordon wrote:
This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.
There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
is sn
On 13/06/16 16:51, John Harrison wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 07edaed..f8f60bb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1019,9 +1019,13 @@ static int i915_workqueues_init(struct
On 06/06/16 07:26, Arun Siluvery wrote:
On 03/06/2016 16:28, Patchwork wrote:
== Series Details ==
Series: BXT Pooled EU kernel support and WA patches (rev3)
URL : https://patchwork.freedesktop.org/series/8200/
State : warning
== Summary ==
Series 8200v3 BXT Pooled EU kernel support and WA
== Series Details ==
Series: series starting with [1/3] RFC: drm: Restrict vblank ioctl to master
URL : https://patchwork.freedesktop.org/series/8674/
State : failure
== Summary ==
Applying: RFC: drm: Restrict vblank ioctl to master
Applying: drm: Mark authmagic ioctls as unlocked
fatal: sha1
All protected by dev->master_mutex. And there's no driver callbacks,
which means no need to sync with old dri1 horror show drivers at all.
Hence safe to drop the drm legacy BKL from these paths.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+
Again this is neatly protected by the dev->master_mutex now. There is
a driver callback both for set and drop, but it's only used by vmwgfx.
And vmwgfx has it's own solid locking for shared resources (besides
dev->master_mutex), hence is all safe. Let's drop another place where
the drm legacy bkl i
Somehow this escaped us, this is a KMS ioctl which should only be used
by the master (which is the thing that's also in control of kms
resources). Everything else is bound to result in fail.
Clients shouldn't have a trouble coping with this, since a pile of
drivers don't support vblank waits (or j
Op 13-06-16 om 16:13 schreef Daniel Vetter:
> This is part of what atomic must implement. And it's also required
> to be able to use the helper nonblocking support.
>
> v2: Always send out the drm event, remove the planes_changed check.
Hey,
There used to be a patch to add a test in kms_atomic for
Chris Wilson writes:
> Remove some redundant kernel messages as we deduce a hung GPU and
> capture the error state.
>
> v2: Fix "hang" vs "no progress" message whilst I was there
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_irq.c | 41
> ++--
Op 13-06-16 om 16:13 schreef Daniel Vetter:
> Simply split intel_atomic_commit in half and place the new
> nonblocking commit helpers at the right spots.
>
> NOTE: There's still trouble with obj->frontbuffer bits getting mangled
> when pipelining atomic commits.
>
> v2:
> - Remove the check for non
71 matches
Mail list logo
