Hello Uma,
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du..
On 15/03/2019 06:56, Tvrtko Ursulin wrote:
On 15/03/2019 00:52, Chris Wilson wrote:
Quoting José Roberto de Souza (2019-03-15 00:42:35)
We don't have any platform that is composed by 2 or more platforms so
we don't need a mask, lets drop it and remove the actual limit of 32
platforms.
Platf
On Thu, Mar 14, 2019 at 5:19 PM Chris Wilson wrote:
>
> Quoting Lucas De Marchi (2019-03-15 00:13:31)
> > With Elkhart Lake being added to the platforms we are almost on the edge
> > of platforms that fits on this 32 bits mask. So bump it to 64 bits to
> > have room for new ones.
> >
> > Cc: José
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com;
On Fri, Mar 15, 2019 at 12:13 AM Tvrtko Ursulin
wrote:
>
>
> On 15/03/2019 06:56, Tvrtko Ursulin wrote:
> >
> > On 15/03/2019 00:52, Chris Wilson wrote:
> >> Quoting José Roberto de Souza (2019-03-15 00:42:35)
> >>> We don't have any platform that is composed by 2 or more platforms so
> >>> we don
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com;
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com;
== Series Details ==
Series: series starting with [1/2] drm/i915/cml: Add CML PCI IDS
URL : https://patchwork.freedesktop.org/series/58013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5749_full -> Patchwork_12465_full
Sum
From: Swati Sharma
Added state checker to validate gamma_lut values. This
reads hardware state, and compares the originally requested
state to the state read from hardware.
This implementation can be used for Gen9+ platforms,
I haven't implemented it for legacy platforms. Just want to get
feedba
On 15/03/2019 07:27, Lucas De Marchi wrote:
On Fri, Mar 15, 2019 at 12:13 AM Tvrtko Ursulin
wrote:
On 15/03/2019 06:56, Tvrtko Ursulin wrote:
On 15/03/2019 00:52, Chris Wilson wrote:
Quoting José Roberto de Souza (2019-03-15 00:42:35)
We don't have any platform that is composed by 2 or m
On 3/11/2019 9:27 AM, Uma Shankar wrote:
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as
== Series Details ==
Series: drm/i915: adding state checker for gamma lut values
URL : https://patchwork.freedesktop.org/series/58039/
State : failure
== Summary ==
Applying: drm/i915: adding state checker for gamma lut values
Using index info to reconstruct a base tree...
M drivers/gpu/
Quoting Rodrigo Vivi (2019-03-15 00:03:43)
> On Thu, Mar 14, 2019 at 10:38:37PM +, Chris Wilson wrote:
> > With the introduction of the separate addressable bits into the device
> > info, we can remove the conflation of the ppgtt size from the ppgtt
> > type.
> >
> > Based on a patch by Bob Pa
Quoting Rodrigo Vivi (2019-03-14 22:53:44)
> On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wilson wrote:
> > The basic setup of the i915_hw_ppgtt is the same between gen6 and gen8,
> > so refactor that into a common routine.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Bob Paauwe
> > Cc: Matthe
Quoting Tvrtko Ursulin (2019-03-14 17:26:19)
>
> On 13/03/2019 14:43, Chris Wilson wrote:
> > Some users require that when a master batch is executed on one particular
> > engine, a companion batch is run simultaneously on a specific slave
> > engine. For this purpose, we introduce virtual engine
Chris Wilson writes:
> With direct submission being disabled while the reset in progress, we
> have a small window where we may forgo the submission of a new request
> and not notice its addition during execlists_reset_finish. To close this
> window, always schedule the submission tasklet on comi
Quoting Mika Kuoppala (2019-03-15 10:10:20)
> Chris Wilson writes:
> > +static inline bool __tasklet_enable(struct tasklet_struct *t)
> > +{
> > + return atomic_dec_and_test(&t->count);
> > +}
> > +
> > #endif /* __I915_GEM_H__ */
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drive
On Thu, 14 Mar 2019, Rodrigo Vivi wrote:
> On Thu, Mar 14, 2019 at 11:29:18AM -0700, Anusha wrote:
>> From: Anusha Srivatsa
>>
>> Comet Lake PCH is based off of Cannon Point(CNP).
>> Add PCI ID for Comet Lake PCH.
>>
>> v2: Code cleanup (DK)
>>
>> Cc: Dhinakaran Pandiyan
>> Cc: Rodrigo Vivi
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-03-15 10:10:20)
>> Chris Wilson writes:
>> > +static inline bool __tasklet_enable(struct tasklet_struct *t)
>> > +{
>> > + return atomic_dec_and_test(&t->count);
>> > +}
>> > +
>> > #endif /* __I915_GEM_H__ */
>> > diff --git a/drivers/gpu/
Quoting Mika Kuoppala (2019-03-15 10:39:25)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-03-15 10:10:20)
> >> Chris Wilson writes:
> >> > +static inline bool __tasklet_enable(struct tasklet_struct *t)
> >> > +{
> >> > + return atomic_dec_and_test(&t->count);
> >> > +}
> >> > +
>
On Wed, Mar 13, 2019 at 11:02:18PM +0530, Anshuman Gupta wrote:
> From: Jyoti Yadav
>
> dmc_loaded() will be used by new test i915_pm_dc.c which will validate
> Display C States. So moving the same to igt_pm library.
> Introduced igt_disable_runtime_pm() inorder to disable runtime suspend
> for t
On Thu, Mar 14, 2019 at 10:52:08AM +0100, John Ogness wrote:
> On 2019-03-14, John Ogness wrote:
> > On 2019-03-14, Daniel Vetter wrote:
> >> That's why we came up with the trylock + immediate bail out design if
> >> that fails. Plus really only render the oops int whatever is the
> >> current di
On Thu, Mar 14, 2019 at 12:44:06PM +, Kazlauskas, Nicholas wrote:
> On 3/14/19 5:50 AM, Daniel Vetter wrote:
> > On Wed, Mar 13, 2019 at 05:41:52PM +, Kazlauskas, Nicholas wrote:
> >> On 3/13/19 1:33 PM, Michel Dänzer wrote:
> >>> On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
>
Enabling pm_lpsp igt tests for Gen11 as well as for all platforms
at least gen9, earlier these test were enabled only haswell and broadwell
platforms.
Signed-off-by: Anshuman Gupta
---
tests/i915/i915_pm_lpsp.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.
Sig
We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.
Sig
On 3/11/2019 9:27 AM, Uma Shankar wrote:
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comme
On 3/11/2019 9:28 AM, Uma Shankar wrote:
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve an
== Series Details ==
Series: drm/i915/icl: split pll functions (rev3)
URL : https://patchwork.freedesktop.org/series/57618/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5750_full -> Patchwork_12467_full
Summary
---
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during earl
Quoting Tvrtko Ursulin (2019-03-15 12:26:33)
> From: Tvrtko Ursulin
>
> Concept of a sub-platform already exist in our code (like ULX and ULT
> platform variants and similar),implemented via the macros which check a
> list of device ids to determine a match.
>
> With this patch we consolidate de
On 15/03/2019 13:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-15 12:26:33)
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
Wi
On Thu, Mar 14, 2019 at 06:37:22PM -0700, Vanshidhar Konda wrote:
> On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
> >> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
> >> >On Thu, Mar 14, 2019 at 0
Quoting Tvrtko Ursulin (2019-03-15 13:32:54)
>
> On 15/03/2019 13:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-15 12:26:33)
> >> From: Tvrtko Ursulin
> >>
> >> Concept of a sub-platform already exist in our code (like ULX and ULT
> >> platform variants and similar),implemented via
Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
define register bitfield masks.
We define the above as wrappers to BIT() and GENMASK() respectively to
force u32 type to go with our register size, and to add compile time
checks on the bit numbers.
The intention is that these
Slightly verbose, but does away with hand rolled shifts. Ties the field
values with the mask defining the field.
Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
to a integer constant expression. But with this, we can ensure the mask
is non-zero, power of 2, fits u32, and the
v4 of [1], rebased and very mildly tweaked, with the intention to merge. I added
Chris' Reviewed-bys despite the rebase.
BR,
Jani.
[1] cover.1551286447.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1551286447.git.jani.nikula@intel.com
Jani Nikula (3):
drm/i915: introduce REG_B
bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
bitfields using the mask alone, with no need for separate shift. Indeed,
the shift is redundant.
We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
in part to force u32 and for consistency with REG_BIT() and
REG_G
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Concept of a sub-platform already exist in our code (like ULX and ULT
> platform variants and similar),implemented via the macros which check a
> list of device ids to determine a match.
>
> With this patc
On 15/03/2019 14:09, Ville Syrjälä wrote:
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to de
== Series Details ==
Series: drm/i915: Introduce concept of a sub-platform
URL : https://patchwork.freedesktop.org/series/58056/
State : failure
== Summary ==
Applying: drm/i915: Introduce concept of a sub-platform
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i91
== Series Details ==
Series: drm/i915: Move intel_engine_mask_t around for use by
i915_request_types.h (rev2)
URL : https://patchwork.freedesktop.org/series/58052/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12474
==
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i
We only need to acquire a wakeref for ourselves for a few operations, as
most either already acquire their own wakeref or imply a wakeref. In
particular, it is i915_gem_set_wedged() that needed us to present it
with a wakeref, which is incongruous with its "use anywhere" ability.
Suggested-by: Yok
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we define a new extension
struct that can be linked i
In later patches, it became apparent that userspace can see a partially
constructed GEM context and begin using it before it was ready, to much
hilarity. Close this window of opportunity by lifting the registration of
the context with userspace (the insertion of the context into the filp's
idr) to
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient i
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on virtual engines that
are local to the context
It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be applied to the newly constructed
context.
v2:
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the user level the context often
represents a singl
On unpinning the intel_context, we remove it from the active list
inside the GEM context. This list is supposed to be guarded by the GEM
context mutex, so remember to take it!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_context.c | 15 +++
drivers/gpu/drm/i915/
For virtual engines, we need to keep the HW context alive while it
remains in use. For regular HW contexts, they are created and kept alive
until the end of the GEM context. For simplicity, generalise the
requirements and keep an active reference to each HW context.
Signed-off-by: Chris Wilson
--
If we use the STORE_DATA_INDEX function we can use a fixed offset and
avoid having to lookup up the engine HWS address. A step closer to being
able to emit the final breadcrumb during request_add rather than later
in the submission interrupt handler.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that w
We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.
Sig
If a test fails, we quite often mark the device as wedged. Provide the
stub functions so that we can wedge the mock device, and avoid exploding
on test failures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109981
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engi
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with a
Define a mutex for the exclusive use of interacting with the per-file
context-idr, that was previously guarded by struct_mutex. This allows us
to reduce the coverage of struct_mutex, with a view to removing the last
bits coordinating GEM context later. (In the short term, we avoid taking
struct_mut
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.
A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we s
We assumed that vm_mmap() would reject an attempt to mmap past the end of
the filp (our object), but we were wrong.
Reported-by: Antonio Argenziano
Testcase: igt/gem_mmap/bad-size
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
v2: Replace global barrier for swapping over the ppgtt and tlbs with a
local context barrier (Tvrtko)
v3: serialise
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev4)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12476
Summary
Quoting Chris Wilson (2019-03-15 15:03:27)
> +static int create_clone(struct i915_user_extension __user *ext, void *data)
> +{
> + static int (* const fn[])(struct i915_gem_context *dst,
> + struct i915_gem_context *src) = {
> + [ilog2(I915_CONTEX
== Series Details ==
Series: series starting with [01/21] drm/i915: Move intel_engine_mask_t around
for use by i915_request_types.h
URL : https://patchwork.freedesktop.org/series/58065/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12477
Quoting Patchwork (2019-03-15 15:44:37)
> == Series Details ==
>
> Series: series starting with [01/21] drm/i915: Move intel_engine_mask_t
> around for use by i915_request_types.h
> URL : https://patchwork.freedesktop.org/series/58065/
> State : failure
>
> == Summary ==
>
> CI Bug Log - chan
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient i
== Series Details ==
Series: drm/i915: Move intel_engine_mask_t around for use by
i915_request_types.h (rev2)
URL : https://patchwork.freedesktop.org/series/58052/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5753_full -> Patchwork_12474_full
On Fri, Mar 15, 2019 at 02:21:57PM +, Tvrtko Ursulin wrote:
>
> On 15/03/2019 14:09, Ville Syrjälä wrote:
> > On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Concept of a sub-platform already exist in our code (like ULX and ULT
> >> platform
On Fri, Mar 15, 2019 at 05:55:19PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 15, 2019 at 02:21:57PM +, Tvrtko Ursulin wrote:
> >
> > On 15/03/2019 14:09, Ville Syrjälä wrote:
> > > On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
> > >> -#define IS_KBL_ULX(dev_priv)(INTEL_DE
On Fri, Mar 15, 2019 at 03:35:04PM +0200, Ville Syrjälä wrote:
On Thu, Mar 14, 2019 at 06:37:22PM -0700, Vanshidhar Konda wrote:
On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote:
>On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
>> On Thu, Mar 14, 2019 at 10:47:56PM
On 15/03/2019 15:55, Ville Syrjälä wrote:
On Fri, Mar 15, 2019 at 02:21:57PM +, Tvrtko Ursulin wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 047d10bdd455..b03fbd2e451a 100644
--- a/drivers/gpu/drm/i915/intel_device_i
On 2019-03-14, Daniel Vetter wrote:
> That's why we came up with the trylock + immediate bail out design if
> that fails. Plus really only render the oops int whatever is the
> current display buffer, so that we don't have to do any hw programming
> at all.
I think this is your best option. The r
Hi Tvrtko,
On Tue, Dec 11, 2018 at 6:06 PM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 11/12/2018 10:14, Ankit Navik wrote:
> > From: Praveen Diwakar
> >
> > This patch will update power clock state register at runtime base on the
> > flag which can set by any governor which c
On 2019-03-14, John Ogness wrote:
> On 2019-03-14, Daniel Vetter wrote:
>> That's why we came up with the trylock + immediate bail out design if
>> that fails. Plus really only render the oops int whatever is the
>> current display buffer, so that we don't have to do any hw
>> programming at all.
Hi Tvrtko,
On Tue, Nov 6, 2018 at 3:14 PM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 06/11/2018 04:13, Ankit Navik wrote:
> > From: Praveen Diwakar
> >
> > This patch gives us the active pending request count which is yet
> > to be submitted to the GPU
> >
> > Signed-off-by:
== Series Details ==
Series: series starting with [01/21] drm/i915: Move intel_engine_mask_t around
for use by i915_request_types.h (rev3)
URL : https://patchwork.freedesktop.org/series/58065/
State : failure
== Summary ==
Applying: drm/i915: Move intel_engine_mask_t around for use by
i915_r
== Series Details ==
Series: drm/i915: Clean up ilk+ csc stuff (rev2)
URL : https://patchwork.freedesktop.org/series/56857/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12478
Summary
---
**SUCCESS*
On Thu, Mar 14, 2019 at 04:01:13PM -0700, José Roberto de Souza wrote:
> There is probably a issue in DMC firmwares(icl_dmc_ver1_07.bin and
> kbl_dmc_ver1_04.bin at least) that causes PSR2 SU to fail after
> exiting DC6 if EDP_PSR_TP1_TP3_SEL is kept in PSR_CTL, so for now
> lets workaround the iss
---
drivers/gpu/drm/drm_debugfs.c | 2 +-
drivers/gpu/drm/drm_drv.c | 12
drivers/gpu/drm/drm_prime.c | 2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index f8468eae0503..f7044ff82f9c 100644
-
Wrong branch...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ffs() is 1-indexed, but we want to use it as an index into an array, so
use __ffs() instead.
Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(
On Fri, Mar 15, 2019 at 04:39:33PM +, Chris Wilson wrote:
> ffs() is 1-indexed, but we want to use it as an index into an array, so
> use __ffs() instead.
>
> Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Rev
On Fri, 15 Mar 2019 09:09:11 +
Chris Wilson wrote:
> Quoting Rodrigo Vivi (2019-03-14 22:53:44)
> > On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wilson wrote:
> > > The basic setup of the i915_hw_ppgtt is the same between gen6 and gen8,
> > > so refactor that into a common routine.
> > >
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev4)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5753_full -> Patchwork_12476_full
On Fri, Mar 15, 2019 at 09:55:47AM -0700, Bob Paauwe wrote:
> On Fri, 15 Mar 2019 09:09:11 +
> Chris Wilson wrote:
>
> > Quoting Rodrigo Vivi (2019-03-14 22:53:44)
> > > On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wilson wrote:
> > > > The basic setup of the i915_hw_ppgtt is the same be
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during earl
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consoli
On Fri, 15 Mar 2019 10:01:51 -0700
Rodrigo Vivi wrote:
> On Fri, Mar 15, 2019 at 09:55:47AM -0700, Bob Paauwe wrote:
> > On Fri, 15 Mar 2019 09:09:11 +
> > Chris Wilson wrote:
> >
> > > Quoting Rodrigo Vivi (2019-03-14 22:53:44)
> > > > On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wi
Quoting Tvrtko Ursulin (2019-03-15 17:09:28)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 3d8020888604..e3360a31f8d3 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -677,6 +677,7 @@ st
On 15/03/2019 17:12, Lucas De Marchi wrote:
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to
On 15/03/2019 17:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-15 17:09:28)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3d8020888604..e3360a31f8d3 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_g
== Series Details ==
Series: no-primary
URL : https://patchwork.freedesktop.org/series/58072/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12480
Summary
---
**FAILURE**
Serious unknown changes c
Em sex, 2019-03-15 às 06:56 +, Tvrtko Ursulin escreveu:
> On 15/03/2019 00:52, Chris Wilson wrote:
> > Quoting José Roberto de Souza (2019-03-15 00:42:35)
> > > We don't have any platform that is composed by 2 or more platforms so
> > > we don't need a mask, lets drop it and remove the actual l
From: Bob Paauwe
EHL has a different number of subslices.
Cc: Lucas De Marchi
Signed-off-by: Bob Paauwe
Signed-off-by: Rodrigo Vivi
Reviewed-by: Lucas De Marchi
Link:
https://patchwork.freedesktop.org/patch/msgid/20190313211144.4842-7-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_d
From: James Ausmus
Add known EHL PCI IDs.
v2 (Rodrigo): Removed x86 early quirk. To be sent in a separated
patch cc'ing the appropriated list and maintainers for proper ack.
Cc: Bob Paauwe
Signed-off-by: James Ausmus
Signed-off-by: Rodrigo Vivi
Reviewed-by: José Roberto de Souza
Link:
h
From: Bob Paauwe
Add ElkhartLake as a unique platform as there are some differences
between it and Icelake.
Signed-off-by: Bob Paauwe
Signed-off-by: Rodrigo Vivi
Reviewed-by: Lucas De Marchi
Link:
https://patchwork.freedesktop.org/patch/msgid/20190313211144.4842-2-rodrigo.v...@intel.com
---
From: Lucas De Marchi
Elkhart Lake has a different set of PLLs as compared to Ice Lake,
although programming them is very similar.
Signed-off-by: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
Reviewed-by: José Roberto de Souza
Link:
https://patchwork.freedesktop.org/patch/msgid/20190313211144.
1 - 100 of 155 matches
Mail list logo
