On to, 2016-12-15 at 19:53 +, Michal Wajdeczko wrote:
> We usually use 'client' as identifier for the i915_guc_client.
> For unknown reason, few functions were using 'gc' name.
>
> Signed-off-by: Michal Wajdeczko
Looks good, I'll merge this.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
On 15/12/2016 20:54, Chris Wilson wrote:
On Thu, Dec 15, 2016 at 11:44:13PM +0300, Dan Carpenter wrote:
Hello Tvrtko Ursulin,
The patch a19d6ff29a82: "drm/i915: Small compaction of the engine
init code" from Jun 23, 2016, leads to the following static checker
warning:
drivers/gpu/drm/
On 2016-12-14 11:13 AM, Brian Starkey wrote:
Hi,
On Wed, Dec 14, 2016 at 04:05:04AM -0500, Robert Foss wrote:
From: Gustavo Padovan
Add support for the OUT_FENCE_PTR property to enable setting out
fences for
atomic commits.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
li
On 2016-12-14 11:39 AM, Brian Starkey wrote:
Hi,
On Wed, Dec 14, 2016 at 04:05:05AM -0500, Robert Foss wrote:
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
tests/kms_atomic.c | 186
++---
1 file changed,
On 16/12/2016 08:02, Tvrtko Ursulin wrote:
On 15/12/2016 20:54, Chris Wilson wrote:
On Thu, Dec 15, 2016 at 11:44:13PM +0300, Dan Carpenter wrote:
Hello Tvrtko Ursulin,
The patch a19d6ff29a82: "drm/i915: Small compaction of the engine
init code" from Jun 23, 2016, leads to the following stat
Testcase for plane visibility after atomic modesets. The idea of the test
is the following:
- draw a blue screen with high resolution
- enable a yellow plane, visible, in lower-left corner
- set a new lower resolution mode (1024x768) that makes plane invisible
- check from debugfs 'i915_displa
On 2016-12-14 11:57 AM, Brian Starkey wrote:
On Wed, Dec 14, 2016 at 04:05:07AM -0500, Robert Foss wrote:
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 22 ++
tests/kms_atomic_transition.c | 32 +++
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> When we evict from the GTT to make room for an object, the hole we
> create is put onto the MRU stack inside the drm_mm range manager. On the
> next search pass, we can speed up a PIN_HIGH allocation by referencing
> that stack for the new hol
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
> for walking the list of nodes safe against removal.
>
Most of the diff is about __drm_mm_nodes(mm), which could be split into
own patch and keep the R-b's.
Regards,
== Series Details ==
Series: series starting with [v2,01/40] drm/i915: Use the MRU stack search
after evicting
URL : https://patchwork.freedesktop.org/series/16906/
State : success
== Summary ==
Series 16906v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16906/
On Fri, 16 Dec 2016, Nicholas Mc Guire wrote:
> udelay_range(1, 2) is inefficient and as discussions with Jani Nikula
> unnecessary here. This replaces this
> tight setting with a relaxed delay of min=20 and max=50 which helps
> the hrtimer subsystem optimize timer handling.
>
> Fixes: commit be4
aused the problem by changing the subject line of the patch
> while adding a V2 - because the original subject line was no longer corrct
> (it noted udely) - the V2 patch is marked as "rev 1" in patchwork though.
>
> not quite clear - anyway sorry if I made some sort of a mess
On Fri, Dec 16, 2016 at 07:46:46AM +, Chris Wilson wrote:
> Prime numbers are interesting for testing components that use multiplies
> and divides, such as testing struct drm_mm alignment computations.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/Kconfig | 4 +
>
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> When testing, we want a random but yet reproducible order in which to
> process elements. Here we create an array which is a random (using the
> Tausworthe PRNG) permutation of the order in which to execute.
>
> v2: Tidier code by David Herrm
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Simple first test to just exercise initialisation of struct drm_mm.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_
On Fri, Dec 16, 2016 at 10:31:17AM +0100, Lukas Wunner wrote:
> On Fri, Dec 16, 2016 at 07:46:46AM +, Chris Wilson wrote:
> > Prime numbers are interesting for testing components that use multiplies
> > and divides, such as testing struct drm_mm alignment computations.
> >
> > Signed-off-by: C
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Simple test to just exercise calling the debug dumper on the drm_mm.
>
> Signed-off-by: Chris Wilson
This is rather meta already. Not entirely sure how good of a selftest
this is when we do not validate the generated output, or do you at th
On Fri, Dec 16, 2016 at 11:44:39AM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> > Simple test to just exercise calling the debug dumper on the drm_mm.
> >
> > Signed-off-by: Chris Wilson
>
> This is rather meta already. Not entirely sure how good of a s
On Fri, Dec 16, 2016 at 09:43:54AM +, Chris Wilson wrote:
> On Fri, Dec 16, 2016 at 10:31:17AM +0100, Lukas Wunner wrote:
> > On Fri, Dec 16, 2016 at 07:46:46AM +, Chris Wilson wrote:
> > > Prime numbers are interesting for testing components that use multiplies
> > > and divides, such as t
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> The nodes must be removed in the *reverse* order. This is correct in the
> overview, but backwards in the function description. Whilst here add
> Intel's copyright statement and tweak some formatting.
>
> Signed-off-by: Chris Wilson
It's li
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> Protect ourselves from a caller passing in node.start + node.size that
> will overflow and trick us into reserving that node.
>
> Signed-off-by: Chris Wilson
I was about to suggest an additional check (but didn't). A combined
check is much
On Fri, Dec 16, 2016 at 11:08:10AM +0100, Lukas Wunner wrote:
> On Fri, Dec 16, 2016 at 09:43:54AM +, Chris Wilson wrote:
> > On Fri, Dec 16, 2016 at 10:31:17AM +0100, Lukas Wunner wrote:
> > > On Fri, Dec 16, 2016 at 07:46:46AM +, Chris Wilson wrote:
> > > > Prime numbers are interesting f
From: Manasi Navare
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the li
The two remaining patches from [1], rebased.
BR,
Jani.
[1]
1480984058-552-1-git-send-email-manasi.d.navare@intel.com">http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare@intel.com
Manasi Navare (2):
drm: Add a new connector atomic property for link status
drm/i915:
From: Manasi Navare
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link r
On Thu, Dec 15, 2016 at 05:38:16PM +0100, Michal Wajdeczko wrote:
> On Thu, Dec 15, 2016 at 04:47:06PM +0100, Arkadiusz Hiler wrote:
> > Current version of intel_guc_load() does a lot:
> > - cares about submission
> > - loads huc
> > - implement WA
> >
> > This change offloads some of the logic
== Series Details ==
Series: drm: link status property and DP link training failure handling
URL : https://patchwork.freedesktop.org/series/16912/
State : failure
== Summary ==
Series 16912v1 drm: link status property and DP link training failure handling
https://patchwork.freedesktop.org/api/
On Thu, Dec 15, 2016 at 02:26:29PM -0800, Daniele Ceraolo Spurio wrote:
>
>
> On 15/12/16 07:47, Arkadiusz Hiler wrote:
> > Current version of intel_guc_load() does a lot:
> > - cares about submission
> > - loads huc
> > - implement WA
> >
> > This change offloads some of the logic to intel_u
On Thu, Dec 15, 2016 at 05:22:53PM +0100, Michal Wajdeczko wrote:
> On Thu, Dec 15, 2016 at 04:47:04PM +0100, Arkadiusz Hiler wrote:
> > GuC historically has two "startup" functions called _init() and _setup()
> >
> > Then HuC came with it's _init() and _load().
> >
> > To make naming more consis
On Thu, Dec 15, 2016 at 03:57:01PM +, Chris Wilson wrote:
> On Thu, Dec 15, 2016 at 04:47:04PM +0100, Arkadiusz Hiler wrote:
> > GuC historically has two "startup" functions called _init() and _setup()
> >
> > Then HuC came with it's _init() and _load().
> >
> > To make naming more consistent
A couple of comments below, and some bonus nitpicks.
On Wed, Dec 07, 2016 at 02:04:52PM -0800, Manasi Navare wrote:
> This is the userspace component of the Displayport Compliance
> testing software required for compliance testing of the I915
> Display Port driver. This must be running in order
On Fri, Dec 16, 2016 at 12:47:26PM +0100, Arkadiusz Hiler wrote:
> On Thu, Dec 15, 2016 at 03:57:01PM +, Chris Wilson wrote:
> > On Thu, Dec 15, 2016 at 04:47:04PM +0100, Arkadiusz Hiler wrote:
> > > GuC historically has two "startup" functions called _init() and _setup()
> > >
> > > Then HuC
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> mm->color_adjust() compares the hole with its neighbouring nodes. They
> only abutt before we restrict the hole, so we have to apply color_adjust
> before we apply the range restriction.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas L
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> Remove a superfluous helper as drm_mm_insert_node is equivalent to
> insert_node_in_range with a range of (0, U64_MAX).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technolog
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> Insulate users from changed to the internal hole tracking within
changes ^
> struct drm_mm_node by using an accessor for hole_follows.
>
> Signed-off-by: Chris Wilson
The function name could be soemthing beginning with drm
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
> after drm_mm_scan_add_block() we can further simplify the list
> manipulations when generating the temporary scan-hole.
>
> v2: Highlight the games being played with the
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> A simple assert to ensure that we don't overflow start + size when
> initialising the drm_mm, or its scanner.
>
> In future, we may want to switch to tracking the value of ranges (rather
> than size) so that we can cover the full u64, for exa
From: Tvrtko Ursulin
Commit 3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs
structure only for the enabled engines") introduced the
dynanically allocated engine instances and created an
potential use after free scenario in logical_render_ring_init
where lrc_destroy_wa_ctx_obj could be called af
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
Signed-off-by: Chris Wilson
Cc: Lukas Wunner
---
include/linux/prime_numbers.h | 13 +++
lib/Kconfig
On Fri, Dec 16, 2016 at 01:18:42PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Commit 3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs
> structure only for the enabled engines") introduced the
> dynanically allocated engine instances and created an
> potential use after free scenario
Hi, Linus
This is KVMGT pull for 4.10 as explained by Daniel. The last minute
rebase is to appease git pull-request since the diffstat was obvious
bonghits and somehow included vfio/mdev again despite that was merged
already.
Thanks.
The following changes since commit 9439b3710df688d853eb6cb485
On Fri, Dec 16, 2016 at 03:04:31PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> > Insulate users from changed to the internal hole tracking within
>
> changes ^
>
> > struct drm_mm_node by using an accessor for hole_follows.
> >
> > Sign
On Fri, Dec 16, 2016 at 11:06:25AM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> > A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
> > for walking the list of nodes safe against removal.
> >
>
> Most of the diff is about __drm_mm_
On pe, 2016-12-16 at 13:31 +, Chris Wilson wrote:
> On Fri, Dec 16, 2016 at 03:04:31PM +0200, Joonas Lahtinen wrote:
> >
> > On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> > >
> > > Insulate users from changed to the internal hole tracking within
> >
> > changes ^
>
On Fri, Dec 16, 2016 at 07:46:42AM +, Chris Wilson wrote:
> Mark up the pointers as constant through the API where appropriate.
>
> Signed-off-by: Chris Wilson
Ok merged this and the patch right before, then Chris told me on irc that
I need to stop because he's mixing a v3 of this series.
-D
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range effic
On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> The two remaining patches from [1], rebased.
>
> BR,
> Jani.
>
>
> [1]
> 1480984058-552-1-git-send-email-manasi.d.navare@intel.com">http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare@intel.com
Just for the
On Fri, Dec 16, 2016 at 01:23:23PM +, Chris Wilson wrote:
> Prime numbers are interesting for testing components that use multiplies
> and divides, such as testing DRM's struct drm_mm alignment computations.
>
> v2: Move to lib/, add selftest
>
> Signed-off-by: Chris Wilson
> Cc: Lukas Wunne
== Series Details ==
Series: drm/i915: Fix use after free in logical_render_ring_init
URL : https://patchwork.freedesktop.org/series/16918/
State : success
== Summary ==
Series 16918v1 drm/i915: Fix use after free in logical_render_ring_init
https://patchwork.freedesktop.org/api/1.0/series/169
On Fri, Dec 16, 2016 at 03:46:18PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> > The drm_mm range manager claimed to support top-down insertion, but it
> > was neither searching for the top-most hole that could fit the
> > allocation request nor fitting t
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
Signed-off-by: Chris Wilson
Cc: Lukas Wunner
---
include/li
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Exercise drm_mm_insert_node(), check that we can't overfill a range and
> that the lists are correct after reserving/removing.
>
> v2: Extract helpers for the repeated tests
> v3: Iterate over all allocation flags
>
> Signed-off-by: Chris Wi
Em Qui, 2016-12-15 às 21:59 +0200, Ville Syrjälä escreveu:
> On Thu, Dec 15, 2016 at 05:50:02PM -0200, Paulo Zanoni wrote:
> >
> > Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu:
> > >
> > > On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote:
> > > >
> > > >
> > > > Em Ter,
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Exercise drm_mm_insert_node_in_range(), check that we only allocate from
> the specified range.
>
> v2: Use all allocation flags
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> Using mm->color_adjust makes the eviction scanner much tricker since we
> don't know the actual neighbours of the target hole until after it is
> created (after scanning is complete). To work out whether we need to
> evict the neighbours becau
On Fri, Dec 16, 2016 at 04:14:30PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> > Using mm->color_adjust makes the eviction scanner much tricker since we
> > don't know the actual neighbours of the target hole until after it is
> > created (after scanning
Fairly commonly we want to inspect the node list on the struct drm_mm,
which is buried within an embedded node. Bring it to the surface with a
bit of syntatic sugar.
Note this was intended to be split from commit ad579002c8ec ("drm: Add
drm_mm_for_each_node_safe()") before being applied, but my ti
On 16/12/2016 13:53, Patchwork wrote:
== Series Details ==
Series: drm/i915: Fix use after free in logical_render_ring_init
URL : https://patchwork.freedesktop.org/series/16918/
State : success
== Summary ==
Series 16918v1 drm/i915: Fix use after free in logical_render_ring_init
https://pat
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Check that after applying the driver's color adjustment, eviction
> scanning find a suitable hole.
>
> Signed-off-by: Chris Wilson
> +static int evict_color(struct drm_mm *mm,
> + struct evict_node *nodes,
> +
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Check that after applying the driver's color adjustment, restricted
> eviction scanning find a suitable hole.
>
> Signed-off-by: Chris Wilson
> +static int igt_color_evict_range(void *ignored)
> +{
> + for (mode = evict_modes; mod
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> Acknowledging that we were building up the hole was more useful to me
> when reading the code, than knowing the relationship between this node
> and the previous node.
>
> Signed-off-by: Chris Wilson
I'm not purely against, so if you think
On Thu, Dec 15, 2016 at 10:42:53PM +, Chris Wilson wrote:
> On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote:
> > From: Peter Antoine
> >
> > This patch will allow for getparams to return the status of the HuC.
> > As the HuC has to be validated by the GuC this patch uses the validate
On Fri, 16 Dec 2016, Daniel Vetter wrote:
> On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
>> The two remaining patches from [1], rebased.
>>
>> BR,
>> Jani.
>>
>>
>> [1]
>> 1480984058-552-1-git-send-email-manasi.d.navare@intel.com">http://mid.mail-archive.com/1480984058-552-1-gi
On Fri, Dec 16, 2016 at 04:38:12PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> > Check that after applying the driver's color adjustment, eviction
> > scanning find a suitable hole.
> >
> > Signed-off-by: Chris Wilson
>
>
>
> > +static int evict_colo
On Fri, 2016-12-16 at 12:07 -0200, Paulo Zanoni wrote:
> Em Qui, 2016-12-15 às 21:59 +0200, Ville Syrjälä escreveu:
> >
> > On Thu, Dec 15, 2016 at 05:50:02PM -0200, Paulo Zanoni wrote:
> > >
> > >
> > > Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu:
> > > >
> > > >
> > > > On Thu,
On Fri, Dec 16, 2016 at 04:02:12PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> > Exercise drm_mm_insert_node(), check that we can't overfill a range and
> > that the lists are correct after reserving/removing.
> >
> > v2: Extract helpers for the repeated
On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> Spotted while auditing our ioctl table. Also nuke the
> not-really-kerneldoc comments, we don't document internals and
> definitely don't want to mislead people with the old dragons.
>
> I think with this all the legacy ioctls now have proper
On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> This is not driver interface stuff.
>
Reviewed-by: Sean Paul
> Fixes: 6559c901cb48 ("drm/atomic: add debugfs file to dump out atomic state")
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-off-by: Daniel
On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> The requirements for connector_list locking are a bit tricky:
> - We need to be able to jump over zombie conectors (i.e. with refcount
> == 0, but not yet removed from the list). If instead we require that
> there's no zombies on the list
On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> This is single-threaded setup code, no need for locks. And anyway,
> all properties need to be set up before the driver is registered
> anyway, they can't be hot-added.
>
Reviewed-by: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> dri
On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> If we're unlucky then the registration from a hotplugged connector
> might race with the final registration step on driver load. And since
> MST topology discover is asynchronous that's even somewhat likely.
>
> v2: Also update the kerneldoc
On Thu, Dec 15, 2016 at 10:58 AM, Daniel Vetter wrote:
> Mostly nothing special (except making sure that really all error paths
> and friends call iter_put).
>
> v2: Don't forget the raw connector_list walking in
> drm_helper_move_panel_connectors_to_head. That one unfortunately can't
> be convert
On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> Only static connectors should be left at this point, and we should be
> able to clean them out by simply dropping that last reference still
> around from drm_connector_init.
>
> If that leaves anything behind then we have a driver bug.
>
> Do
On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> - Modeset state needs mode_config->connection mutex, that covers
> figuring out the encoder, and reading properties (since in the
> atomic case those need to look at connector->state).
>
> - Don't hold any locks for stuff that's invariant
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: ca1c03136b168816ac65c5945776908e464fca6b
commit: 45b186f111f1623b257d183920cd4aab16a1acd5 [922/930] drm: Constify the
drm_mm API
config: i386-randconfig-x005-201650 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.
From: Anusha Srivatsa
This patch loads the DMC on GLK. There is a single
firmware image for all steppings on a GLK.
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_csr.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(
From: Michel Thierry
Commit 89b3c3c7ee9d ("drm/i915/glk: Reuse broxton's cdclk code for GLK")
missed a few of occurences of IS_BROXTON() that should have been
coverted to IS_GEN9_LP().
Fixes: 89b3c3c7ee9d ("drm/i915/glk: Reuse broxton's cdclk code for GLK")
Cc: Ander Conselvan de Oliveira
Cc: R
From: Rodrigo Vivi
Besides having the DMC firmware in place and loaded let's
handle runtime suspend and dc9 as we do for Broxton.
Cc: Ander Conselvan de Oliveira
Signed-off-by: Rodrigo Vivi
Reviewed-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++--
1 file
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: ca1c03136b168816ac65c5945776908e464fca6b
commit: 45b186f111f1623b257d183920cd4aab16a1acd5 [922/930] drm: Constify the
drm_mm API
config: x86_64-randconfig-x008-201650 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.
On 15/12/2016 15:47, Arkadiusz Hiler wrote:
Current version of intel_guc_load() does a lot:
- cares about submission
- loads huc
Not yet, no? So instead you could say that you are preparing the
groundworks to make adding in the HuC fit better.
- implement WA
This change offloads some o
On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote:
> From: Peter Antoine
>
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You cannot
On 15/12/2016 15:47, Arkadiusz Hiler wrote:
Currently guc_fw_path values can represent one of three possible states:
1) NULL - device without GuC
2) '\0' - device with GuC but no known firmware
3) else - device with GuC and known firmware
Second case is used only to WARN at the later stage.
On 15/12/2016 22:29, anushasr wrote:
From: Peter Antoine
Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of
On Thu, Dec 15, 2016 at 10:36:40PM +, Srivatsa, Anusha wrote:
> Hi All,
>
> I was wondering if we intend to keep -1 and 2 for the
> enable_guc_submission parameter. Since now we are gating guc loads if
> either guc_submission or enable_huc parameter is set, why have a
> -1(platform default) an
On Fri, Dec 16, 2016 at 03:43:46PM +0100, Arkadiusz Hiler wrote:
> On Thu, Dec 15, 2016 at 10:42:53PM +, Chris Wilson wrote:
> > On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote:
> > > From: Peter Antoine
> > >
> > > This patch will allow for getparams to return the status of the HuC.
On 15/12/2016 22:29, anushasr wrote:
From: Anusha Srivatsa
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-n
On 15/12/2016 22:29, anushasr wrote:
From: Anusha Srivatsa
This patch adds the HuC Loading for the BXT by using
the updated file construction.
Version 1.7 of the HuC firmware.
v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename BXT_FW_MAJOR to BXT_HUC_FW_
Cc: Jeff Mc
On Thu, Dec 15, 2016 at 02:29:49PM -0800, anushasr wrote:
> From: Peter Antoine
>
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
>
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: rebased
On 15/12/2016 22:29, anushasr wrote:
From: Anusha Srivatsa
This patch adds the support to load HuC on KBL
Version 2.0
v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jeff McGee
--
On Fri, Dec 16, 2016 at 04:12:36PM +, Chris Wilson wrote:
> On Fri, Dec 16, 2016 at 03:43:46PM +0100, Arkadiusz Hiler wrote:
> > On Thu, Dec 15, 2016 at 10:42:53PM +, Chris Wilson wrote:
> > > On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote:
> > > > From: Peter Antoine
> > > >
>
On Fri, Dec 16, 2016 at 04:13:14PM +, Tvrtko Ursulin wrote:
>
> On 15/12/2016 22:29, anushasr wrote:
> > From: Anusha Srivatsa
> >
> > The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> > is used for both cases.
> >
> > HuC loading needs to be before GuC loading. The WOPCM
On Fri, Dec 16, 2016 at 05:21:38PM +0100, Arkadiusz Hiler wrote:
> On Fri, Dec 16, 2016 at 04:12:36PM +, Chris Wilson wrote:
> > On Fri, Dec 16, 2016 at 03:43:46PM +0100, Arkadiusz Hiler wrote:
> > > On Thu, Dec 15, 2016 at 10:42:53PM +, Chris Wilson wrote:
> > > > On Thu, Dec 15, 2016 at 0
== Series Details ==
Series: series starting with [v2,01/40] drm/i915: Use the MRU stack search
after evicting (rev3)
URL : https://patchwork.freedesktop.org/series/16906/
State : failure
== Summary ==
CC net/ipv4/tcp_cubic.o
CC net/ipv4/xfrm4_policy.o
LD drivers/net/phy/
On 16/12/2016 16:29, Arkadiusz Hiler wrote:
On Fri, Dec 16, 2016 at 04:13:14PM +, Tvrtko Ursulin wrote:
On 15/12/2016 22:29, anushasr wrote:
From: Anusha Srivatsa
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before G
== Series Details ==
Series: drm: Use drm_mm_nodes() as shorthand for the list of nodes under struct
drm_mm
URL : https://patchwork.freedesktop.org/series/16920/
State : failure
== Summary ==
Series 16920v1 drm: Use drm_mm_nodes() as shorthand for the list of nodes under
struct drm_mm
https:
On Wed, Dec 14, 2016 at 07:14:05PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Dump out more of the DSI configuration details during init.
> This includes pclk, burst_mode_ratio, lane_count, pixel_overlap,
> video_mode_format and reset_timer_val.
>
> v2: Dump more info
== Series Details ==
Series: series starting with [1/3] drm/i915/DMC/GLK: Load DMC on GLK
URL : https://patchwork.freedesktop.org/series/16926/
State : failure
== Summary ==
Series 16926v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16926/revisions/1/mbox/
Tes
+
+fail:
+ /*
+* We've failed to load the firmware :(
+*
+* Decide whether to disable GuC submission and fall back to
+* execlist mode, and whether to hide the error by returning
+* zero or to return -EIO, which the caller will treat as a
+*
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Friday, December 16, 2016 8:31 AM
>To: Hiler, Arkadiusz
>Cc: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to
>getparams
>
>O
>-Original Message-
>From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
>Sent: Friday, December 16, 2016 8:16 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support
>
>
>On 15/12/2016 22:29, a
1 - 100 of 166 matches
Mail list logo
