== Series Details ==
Series: drm/i915/sprite: Fix race of vblank irq vs wait in vblank evasion (rev2)
URL : https://patchwork.freedesktop.org/series/11427/
State : warning
== Summary ==
Series 11427v2 drm/i915/sprite: Fix race of vblank irq vs wait in vblank evasion
http://patchwork.freedeskto
== Series Details ==
Series: drm/i915/skl: Set dirty_pipes to active_crtcs, not ~0
URL : https://patchwork.freedesktop.org/series/11425/
State : failure
== Summary ==
Series 11425v1 drm/i915/skl: Set dirty_pipes to active_crtcs, not ~0
http://patchwork.freedesktop.org/api/1.0/series/11425/revi
tree from next-20160822 for today.
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Durgadoss R
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes.
Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code that calculates the pll
so that it doesn't depend on crtc state.
This will be used for acquiring port pll when doing
upfront link training.
Reviewed-by: Durgadoss R
Signed-off-by: Manasi Navare
---
From: Jim Bride
Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code does not directly depend on
crtc state, so that the code can be used for upfront link training.
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 131 ++
From: Ander Conselvan de Oliveira
The value of ddi_pll_sel is derived from the selection of shared dpll,
so just calculate the final value when necessary.
v2: Actually remove it from crtc state and delete remaining usages. (CI)
Reviewed-by: Durgadoss R
Signed-off-by: Ander Conselvan de Oliveir
From: Durgadoss R
Split out of bxt_ddi_pll_select() the logic that calculates the pll
dividers and dpll_hw_state into a new function that doesn't depend on
crtc state. This will be used for enabling the port pll when doing
upfront link training.
v2:
* Refactored code so that bxt_clk_div need not
From: Ander Conselvan de Oliveira
Split intel_ddi_pre_enable() into encoder type specific versions that
don't depend on crtc_state. The necessary parameters are passed as
function arguments. This split will be necessary for implementing DP
upfront link training.
v2:
* Rebased onto kernel v4.7 (J
From: Patchwork [patchw...@emeril.freedesktop.org]
Sent: Thursday, August 18, 2016 11:28 PM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Ro.CI.BAT: failure for drm/i915/dp/mst: Validate modes against the
available link bandwidth
==
On Mon, Aug 22, 2016 at 11:31:31AM -0400, Lyude wrote:
> Hope this didn't take too long! Here's the backported versions of the patches
> you had trouble applying to stable. The patch for FBC won't be necessary as
> that is already present in 4.7.y.
>
> Cheers,
> Lyude
Thanks, but what are t
On Wed, Aug 10, 2016 at 10:06:32AM -, Patchwork wrote:
> == Series Details ==
>
> Series: Enable upfront link training on DDI platforms (rev2)
> URL : https://patchwork.freedesktop.org/series/10821/
> State : failure
>
> == Summary ==
>
> Series 10821v2 Enable upfront link training on DDI
On Sat, Aug 20, 2016 at 11:46:19AM +0200, David Weinehall wrote:
> On Fri, Aug 19, 2016 at 04:33:49PM -0700, Manasi Navare wrote:
> > Get the PLLs for HSW/BDW using the platform specific function
> > and add hooks for enabling upfront link training on HSW and BDW.
> >
> > Signed-off-by: Manasi Nav
On Sat, Aug 20, 2016 at 11:46:19AM +0200, David Weinehall wrote:
> On Fri, Aug 19, 2016 at 04:33:49PM -0700, Manasi Navare wrote:
> > Get the PLLs for HSW/BDW using the platform specific function
> > and add hooks for enabling upfront link training on HSW and BDW.
> >
> > Signed-off-by: Manasi Nav
On Mon, Aug 22, 2016 at 06:21:47PM +0100, Chris Wilson wrote:
> When we check whether we are in the danger region before a vblank at the
> start of a pipe update, the irq must be enabled. This is so that as
> decide whether or not to sleep there is no race between us and the irq
> delivery - i.e. w
On Mon, Aug 22, 2016 at 06:15:53PM +0100, Chris Wilson wrote:
> Hmm, prepare_to_wait() itself has a might_sleep() check, preventing the
> preempt fun. The challenge is that we do not want to be interrupted
> once we decide to apply the update (reading the scanline) - but that
> read has to be after
When we check whether we are in the danger region before a vblank at the
start of a pipe update, the irq must be enabled. This is so that as
decide whether or not to sleep there is no race between us and the irq
delivery - i.e. we want to immediately wake up if the irq arrives
before we try to slee
On Mon, Aug 22, 2016 at 05:56:24PM +0100, Chris Wilson wrote:
> When we check whether we are in the danger region before a vblank at the
> start of a pipe update, the irq must be enabled. This is so that as
> decide whether or not to sleep there is no race between us and the irq
> delivery - i.e. w
When we check whether we are in the danger region before a vblank at the
start of a pipe update, the irq must be enabled. This is so that as
decide whether or not to sleep there is no race between us and the irq
delivery - i.e. we want to immediately wake up if the irq arrives
before we try to slee
Using intel_state->active_crtcs allows us to more easily check whether
or not we've updated all of the CRTCs that needed ddb updates since we
can just do:
mask_of_crtcs_we_updated == intel_state->wm_results.dirty_pipes
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 f
== Series Details ==
Series: Finally fix watermarks (rev11)
URL : https://patchwork.freedesktop.org/series/10276/
State : failure
== Summary ==
Applying: drm/i915/gen6+: Interpret mailbox error flags
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i915_reg.h
M
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
On Fri, Aug 19, 2016 at 05:45:02PM +0100, Chris Wilson wrote:
> As we do many register reads within a very short period of time, hold
> the GMBUS powerwell from start to finish.
>
> Signed-off-by: Chris Wilson
> Cc: David Weinehall
Looks good, works well.
Reviewed-by: David Weinehall
> ---
>
While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA ge
This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Acked-by: Daniel Vetter
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
1 file ch
Unfortunately, there's two situations where we lose hpd right now:
- Runtime suspend
- When we've shut off all of the power wells on Valleyview/Cherryview
While it would be nice if this didn't cause issues, this has the
ability to get us in some awkward states where a user won't be able to
get t
One of the things preventing us from using polling is the fact that
calling valleyview_crt_detect_hotplug() when there's a VGA cable
connected results in sending another hotplug. With polling enabled when
HPD is disabled, this results in a scenario like this:
- We enable power wells and reset the
Hope this didn't take too long! Here's the backported versions of the patches
you had trouble applying to stable. The patch for FBC won't be necessary as
that is already present in 4.7.y.
Cheers,
Lyude
Lyude (4):
drm/i915/vlv: Make intel_crt_reset() per-encoder
drm/i915/vlv: Reset the
On 22/08/2016 15:39, John Harrison wrote:
On 03/08/2016 16:36, Dave Gordon wrote:
To make sense of the output of the parallel execution test (preferably
without reading the source!), we need to see the various measurements
that it makes, specifically: time/batch on each engine separately, total
On Mon, Aug 22, 2016 at 02:43:04PM +0200, Maarten Lankhorst wrote:
> Op 18-08-16 om 15:34 schreef Daniel Vetter:
> > On Tue, Aug 09, 2016 at 05:04:06PM +0200, Maarten Lankhorst wrote:
> >> conn_state is passed as argument now, if anything required conn_state
> >> they can get it without having to l
On Mon, Aug 22, 2016 at 10:06:22AM +0200, Maarten Lankhorst wrote:
> Op 18-08-16 om 15:30 schreef Daniel Vetter:
> > On Tue, Aug 09, 2016 at 05:04:04PM +0200, Maarten Lankhorst wrote:
> >> This is mostly code churn, with exception of a few places:
> >> - intel_display.c has changes in intel_sanitiz
On 03/08/2016 16:36, Dave Gordon wrote:
The parallel execution test in gem_exec_nop chooses a pessimal
distribution of work to multiple engines; specifically, it
round-robins one batch to each engine in turn. As the workloads
are trivial (NOPs), this results in each engine becoming idle
between b
On Tue, Aug 09, 2016 at 05:04:03PM +0200, Maarten Lankhorst wrote:
> This cleans up another possible use of the connector list,
> encoder->crtc is legacy state and should not be used.
>
> With the atomic state as argument it's easy to find the encoder from
> the connector it belongs to.
>
> intel
== Series Details ==
Series: drm/i915: Fix nesting of filelist_mutex vs struct_mutex in
i915_ppgtt_info (rev2)
URL : https://patchwork.freedesktop.org/series/11411/
State : failure
== Summary ==
Series 11411v2 drm/i915: Fix nesting of filelist_mutex vs struct_mutex in
i915_ppgtt_info
http://
An unlikely ABBA deadlock in debugfs that no one has reported.
[ 284.922349] ==
[ 284.922355] [ INFO: possible circular locking dependency detected ]
[ 284.922361] 4.8.0-rc2+ #430 Tainted: GW
[ 284.922366]
On Sun, 21 Aug 2016, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fixes the following sparse warning:
>
> drivers/gpu/drm/i915/intel_hotplug.c:480:6: warning:
> symbol 'i915_hpd_poll_init_work' was not declared. Should it be static?
>
> Also move the '{' to new line.
Thanks for the patch, but we'
Op 18-08-16 om 15:34 schreef Daniel Vetter:
> On Tue, Aug 09, 2016 at 05:04:06PM +0200, Maarten Lankhorst wrote:
>> conn_state is passed as argument now, if anything required conn_state
>> they can get it without having to look it up.
> Commit message seems off, this has been dead code before. It s
On Mon, 22 Aug 2016, Chris Wilson wrote:
> On Mon, Aug 22, 2016 at 03:09:48PM +0300, Jani Nikula wrote:
>>
>> On Mon, 22 Aug 2016, Chris Wilson wrote:
>> > [ 284.922349] ==
>> > [ 284.922355] [ INFO: possible circular locking dependency detec
On Mon, 22 Aug 2016, Chris Wilson wrote:
> [ 284.922349] ==
> [ 284.922355] [ INFO: possible circular locking dependency detected ]
> [ 284.922361] 4.8.0-rc2+ #430 Tainted: GW
> [ 284.922366] --
On Mon, Aug 22, 2016 at 03:09:48PM +0300, Jani Nikula wrote:
>
> On Mon, 22 Aug 2016, Chris Wilson wrote:
> > [ 284.922349] ==
> > [ 284.922355] [ INFO: possible circular locking dependency detected ]
> > [ 284.922361] 4.8.0-rc2+ #430 Tainted
== Series Details ==
Series: drm/i915: Fix nesting of filelist_mutex vs struct_mutex in
i915_ppgtt_info
URL : https://patchwork.freedesktop.org/series/11411/
State : warning
== Summary ==
Series 11411v1 drm/i915: Fix nesting of filelist_mutex vs struct_mutex in
i915_ppgtt_info
http://patchwo
On Mon, Aug 22, 2016 at 02:39:30PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > If the engine isn't being retired (worker starvation?) then it is
> > possible for us to repeatedly observe that between consecutive
> > hangchecks the seqno on the ring to be the same and there remain
> >
On Mon, Aug 22, 2016 at 02:21:16PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-22 at 09:03 +0100, Chris Wilson wrote:
> > This is a golden oldie! We can shave a couple of locked instructions for
> > about 10% of the per-object overhead by not taking an extra kref whilst
> > reserving objects for
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[ 284.922349] ==
[ 284.922355] [ INFO: possible circular locking dependency detected ]
[ 284.922361] 4.8.0-rc2+ #430 Tainted: GW
[ 284.922366] ---
[ 284.922371] cat/1197 is trying to
Op 17-08-16 om 21:55 schreef Lyude:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them
On ma, 2016-08-22 at 09:03 +0100, Chris Wilson wrote:
> With full-ppgtt, we want the user to have full control over their memory
> layout, with a separate instance per context. Forcing them to use a
> shared memory layout for !RCS not only duplicates the amount of work we
> have to do, but also def
On ma, 2016-08-22 at 08:44 +0100, Chris Wilson wrote:
> As we never need to directly access the pages we allocate for scratch and
> the pagetables, and always remap them into the GTT through the dma
> remapper, we do not need to limit the allocations to lowmem i.e. we can
> pass in the __GFP_HIGHME
On Mon, Aug 22, 2016 at 01:59:31PM +0300, David Weinehall wrote:
> Just like with sysfs, we do some major overhaul.
>
> Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
> INTEL_, etc.). This has the side effect that a bunch of functions
> now get dev_priv passed instead of dev.
>
>
Joonas Lahtinen writes:
> On ma, 2016-08-22 at 08:44 +0100, Chris Wilson wrote:
>> As the scratch page is no longer shared between all VM, and each has
>> their own, forgo the small allocation and simply embed the scratch page
>> struct into the i915_address_space.
>>
>> Signed-off-by: Chris Wil
Just like with sysfs, we do some major overhaul.
Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.
All calls to INTEL_INFO()->gen have been replaced with
INTEL_GEN().
We want ac
Just like with sysfs, we do some major overhaul.
Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.
All calls to INTEL_INFO()->gen have been replaced with
INTEL_GEN().
We want ac
We currently have a mix of struct device *device, struct device *kdev,
and struct device *dev (the latter forcing us to refer to
struct drm_device as something else than the normal dev).
To simplify things, always use kdev when referring to struct device.
v2: Replace the dev_to_drm_minor() macro
This patch series aims to do some cleanup of our driver.
Patch 1, 2, and 4 should be fairly non-controversial.
Patch 3 and 5 does major cleanups of i915_sysfs and i915_debugfs,
respectively. Due to the nature of these patches they are rather
big, but that's mainly because they change the parameter
Fix minor whitespace issues plus a typo.
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e6069057eb98..2cb40026b476 100644
--- a/dr
In an effort to simplify things for a future push of dev_priv instead
of dev wherever possible, always take pdev via dev_priv where
feasible, eliminating the direct access from dev. Right now this
only eliminates a few cases of dev, but it also obviates that we pass
dev into a lot of functions wher
Various cleanup for i915_sysfs.c; we now use dev_priv whenever
possible. The kdev_to_drm_minor() helper function has been
replaced by one that converts from struct device *
to struct drm_i915_private *.
We already have a seemingly identical helper (kdev_to_i915())
in i915_drv.h. But that one canno
On Mon, Aug 22, 2016 at 01:32:40PM +0300, David Weinehall wrote:
> This patch series aims to do some cleanup of our driver.
> Patch 1, 2, and 4 should be fairly non-controversial.
> Patch 3 and 5 does major cleanups of i915_sysfs and i915_debugfs,
> respectively. Due to the nature of these patches
On Wed, Aug 17, 2016 at 08:00:09PM +, Zanoni, Paulo R wrote:
> Em Qua, 2016-08-17 às 20:49 +0100, Chris Wilson escreveu:
> > On Wed, Aug 17, 2016 at 04:41:44PM -0300, Paulo Zanoni wrote:
> > >
> > > From: Chris Wilson
> > >
> > > intel_fbc_pre_update() depends upon the new state being alread
Hi Tom,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience)
On ma, 2016-08-22 at 08:44 +0100, Chris Wilson wrote:
> As the scratch page is no longer shared between all VM, and each has
> their own, forgo the small allocation and simply embed the scratch page
> struct into the i915_address_space.
>
> Signed-off-by: Chris Wilson
A fairly mechanical change.
On Mon, Aug 22, 2016 at 10:55:22AM +0200, Daniel Vetter wrote:
> This issue here is (I think) purely theoretical, since a compiler
> would need to be especially foolish to recompute the value of
> i915_gem_request_completed right after it was already used. Hence the
> additional barrier() is also n
On ma, 2016-08-22 at 08:44 +0100, Chris Wilson wrote:
> Since by design, if not entirely by practice, nothing is allowed to
> access the scratch page we use to background fill the VM, then we do not
> need to ensure that it is coherent between the CPU and GPU.
> set_pages_uc() does a stop_machine()
== Series Details ==
Series: drm/i915: Ensure consistent control flow __i915_gem_active_get_rcu
URL : https://patchwork.freedesktop.org/series/11403/
State : failure
== Summary ==
Series 11403v1 drm/i915: Ensure consistent control flow
__i915_gem_active_get_rcu
http://patchwork.freedesktop.or
Hi Tom,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience)
Just like with sysfs, we do some major overhaul.
Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.
All calls to INTEL_INFO()->gen have been replaced with
INTEL_GEN().
We want ac
Various cleanup for i915_sysfs.c; we now use dev_priv whenever
possible. The kdev_to_drm_minor() helper function has been
replaced by one that converts from struct device *
to struct drm_i915_private *.
We already have a seemingly identical helper (kdev_to_i915())
in i915_drv.h. But that one canno
This patch series aims to do some cleanup of our driver.
Patch 1, 2, and 4 should be fairly non-controversial.
Patch 3 and 5 does major cleanups of i915_sysfs and i915_debugfs,
respectively. Due to the nature of these patches they are rather
big, but that's mainly because they change the parameter
We currently have a mix of struct device *device, struct device *kdev,
and struct device *dev (the latter forcing us to refer to
struct drm_device as something else than the normal dev).
To simplify things, always use kdev when referring to struct device.
v2: Replace the dev_to_drm_minor() macro
On pe, 2016-08-19 at 12:56 +0100, Chris Wilson wrote:
> The passed in flag that distinguishes i915_gem_pin_display from
> i915_gem_gtt is from node->info_ent->data not the data function
> parameter.
>
> Fixes: 6da8482936c7 ("drm/i915: Focus debugfs/i915_gem_pinned to show...")
> Signed-off-by: Chr
== Series Details ==
Series: drm/i915: Fix assert_sprites_disabled for SKL+
URL : https://patchwork.freedesktop.org/series/11401/
State : failure
== Summary ==
Series 11401v1 drm/i915: Fix assert_sprites_disabled for SKL+
http://patchwork.freedesktop.org/api/1.0/series/11401/revisions/1/mbox
On Mon, Aug 22, 2016 at 10:42:33AM +0200, Maarten Lankhorst wrote:
> On skylake+ the primary plane is plane 0, and plane 1 is the first
> sprite plane. Other callsites handle this correctly.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file change
This issue here is (I think) purely theoretical, since a compiler
would need to be especially foolish to recompute the value of
i915_gem_request_completed right after it was already used. Hence the
additional barrier() is also not really a restriction.
But I believe this to be at least permissible
Hi Tom,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to r
On skylake+ the primary plane is plane 0, and plane 1 is the first
sprite plane. Other callsites handle this correctly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display
== Series Details ==
Series: series starting with [1/3] drm/i915: Stop marking the unaccessible
scratch page as UC
URL : https://patchwork.freedesktop.org/series/11398/
State : failure
== Summary ==
Series 11398v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/113
Hi Tom,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to r
Op 18-08-16 om 16:05 schreef Lyude Paul:
> On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 17-08-16 om 21:55 schreef Lyude:
>>> Since the watermark calculations for Skylake are still broken, we're apt
>>> to hitting underruns very easily under multi-monitor configuratio
Hi Tom,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience)
On Sun, Aug 21, 2016 at 02:15:33PM +0100, Chris Wilson wrote:
> The generic atomic helper likes to skip a prepare_plane_fb() if it
> decides that the plane->fb is unchanged. This is wrong for us for a
> couple of reasons:
>
> - if the pipe is reconfigured (i.e. a size change) but the framebuffer
As i915.enable_cmd_parser is an unsafe option, make it read-only at
runtime. Now that it is constant, we can use the value determined during
initialisation as to whether we need the cmdparser at execbuffer time.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 21 ---
Soft-pinning depends upon being able to check for availabilty of an
inverval and evict overlapping object fro a drm_mm range manager very
quickly. Currently it uses a linear list which makes performance dire,
and softpinning not a suitable replacement.
It also helps if the routine reports the corr
As we never need to directly access the pages we allocate for scratch and
the pagetables, and always remap them into the GTT through the dma
remapper, we do not need to limit the allocations to lowmem i.e. we can
pass in the __GFP_HIGHMEM flag to the page allocation.
For backwards compatibility, e
On Mon, Aug 22, 2016 at 10:02:52AM +0200, Daniel Vetter wrote:
> On Sun, Aug 21, 2016 at 02:15:33PM +0100, Chris Wilson wrote:
> > The generic atomic helper likes to skip a prepare_plane_fb() if it
> > decides that the plane->fb is unchanged. This is wrong for us for a
> > couple of reasons:
> >
>
On Sat, Aug 20, 2016 at 10:39:12AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> Send SLPC shutdown event during disable, suspend, and reset
> operations. Sending shutdown event while already shutdown
> is OK.
>
> v2: return void instead of ignored error code (Paulo)
>
> v5: Removed
On Sat, Aug 20, 2016 at 10:39:01AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> Expose host2guc_action for use by SLPC in intel_slpc.c.
>
> Expose functions to allocate and release objects used
> by GuC to be used for SLPC shared memory object.
>
> v5: Updated function names as they
On Sat, Aug 20, 2016 at 10:39:00AM +0530, Sagar Arun Kamble wrote:
> For Gen9, RPM suspend is failing if rps.enabled=false. This is needed for
> other platforms as RC6 and RPS enabling is indicated by rps.enabled.
> RPM Suspend depends only on RC6, so we need to remove the check of
> rps.enabled.
On Sat, Aug 20, 2016 at 10:39:10AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> When SLPC is controlling requested frequency, the rps.cur_freq
> value is not used to make the frequency request.
>
> Before using rps.cur_freq in sysfs or debugfs, read
> requested frequency from registe
On Sat, Aug 20, 2016 at 10:39:11AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> Add host2guc SLPC reset event and send reset event
> during enable.
>
> v2: extract host2guc_slpc to handle slpc status code
> coding style changes (Paulo)
>
> v5: Removed WARN_ON for checking msb of
On Fri, Aug 19, 2016 at 04:33:49PM -0700, Manasi Navare wrote:
> Get the PLLs for HSW/BDW using the platform specific function
> and add hooks for enabling upfront link training on HSW and BDW.
>
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 ++
> drivers/gpu/drm/i9
On Sat, Aug 20, 2016 at 10:39:04AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> i915.enable_slpc is used to override the default for slpc usage.
> The expected values are -1=auto, 0=disabled [default], 1=enabled.
>
> slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1.
On Sat, Aug 20, 2016 at 10:39:06AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> On platforms with SLPC support: call intel_slpc_*()
> functions from corresponding intel_*_gt_powersave()
> functions; and do not use rps functions.
>
> v2: return void instead of ignored error code (Paul
On Sat, Aug 20, 2016 at 10:39:02AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> Add has_slpc capablity flag to indicate GuC firmware
> supports single loop power control (SLPC). SLPC is
> a replacement for some host-based power management
> features.
>
> v2: fix whitespace (Sagar)
>
On Fri, Aug 19, 2016 at 04:33:47PM -0700, Manasi Navare wrote:
> From: Jim Bride
>
> Split the PLL selection code out of the BXT upfront link training
> implementation and into a stand-alone function in order to allow
> for the implementation of a platform neutral upfront link training
> function
On Sat, Aug 20, 2016 at 10:39:09AM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> SLPC shared data is used to pass information
> to/from SLPC in GuC firmware.
>
> For Skylake, platform sku type and slice count
> are identified from device id and fuse values.
>
> Support for other plat
Op 18-08-16 om 15:30 schreef Daniel Vetter:
> On Tue, Aug 09, 2016 at 05:04:04PM +0200, Maarten Lankhorst wrote:
>> This is mostly code churn, with exception of a few places:
>> - intel_display.c has changes in intel_sanitize_encoder
>> - intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post
When choosing a slot for an execbuffer, we ideally want to use the same
address as last time (so that we don't have to rebind it) and the same
address as expected by the user (so that we don't have to fixup any
relocations pointing to it). If we first try to bind the incoming
execbuffer->offset fro
This simply hides the EAGAIN caused by userptr when userspace causes
resource contention. However, it is quite beneficial with highly
contended userptr users as we avoid repeating the setup costs and
kernel-user context switches.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c
We only need the active reference to keep the object alive after the
handle has been deleted (so as to prevent a synchronous gem_close). Why
the pay the price of a kref on every execbuf when we can insert that
final active ref just in time for the handle deletion?
Signed-off-by: Chris Wilson
---
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active loca
1 - 100 of 115 matches
Mail list logo
