On 15/03/2019 18:40, Lucas De Marchi wrote:
On Fri, Mar 15, 2019 at 05:31:05PM +, Tvrtko Ursulin wrote:
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 (
Signed-off-by: Chris Wilson
---
tests/i915/gem_mmap_gtt.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index 107218864..fa25912bf 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.
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
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
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
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
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
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
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 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
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
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:
From: Tvrtko Ursulin
Check can use the already defined and separate device info for this
platform in conjunction with the IS_MOBILE check. So remove this instance
of device id from the header file.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Chris Wilson
-
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
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
From: Tvrtko Ursulin
This allows the IS_PINEVIEW_ macros to be removed and avoid
duplication of device ids already defined in i915_pciids.h.
!IS_MOBILE check can be used in place of existing IS_PINEVIEW_G call
sites.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
When we return pages to the system, we ensure that they are marked as
being in the CPU domain since any external access is uncontrolled and we
must assume the worst. This means that we need to always flush the pages
on acquisition if we need to use them on the GPU, and from the beginning
have used
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
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
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/
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
On 18/03/2019 09:52, 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 consolidate device ids chec
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
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
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
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
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.
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
--
On 18/03/2019 09:51, Chris Wilson wrote:
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_en
On 18/03/2019 09:51, Chris Wilson wrote:
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
Quoting Tvrtko Ursulin (2019-03-18 10:31:57)
>
> On 18/03/2019 09:51, Chris Wilson wrote:
> > 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 qu
On 18/03/2019 09:51, Chris Wilson wrote:
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!
Fixes: ?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_cont
Quoting Tvrtko Ursulin (2019-03-18 10:21:41)
>
> On 18/03/2019 09:51, Chris Wilson wrote:
> > 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
On Wed, Mar 06, 2019 at 06:30:05PM -0300, Rodrigo Siqueira wrote:
> Hi Liviu,
>
> I’m using your patchset to guide my implementation of writeback in the
> VKMS, so, first of all, thanks :)
>
> During my work, I noticed that you’re setting the drmSetClientCap()
> before drmModeGetResources() which
Quoting Tvrtko Ursulin (2019-03-18 10:39:44)
>
> On 18/03/2019 09:51, Chris Wilson wrote:
> > 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!
>
> Fixes: ?
It is
On 18/03/2019 10:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-18 10:31:57)
On 18/03/2019 09:51, Chris Wilson wrote:
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 complet
On 18/03/2019 10:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-18 10:21:41)
On 18/03/2019 09:51, Chris Wilson wrote:
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 effe
On 18/03/2019 10:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-18 10:39:44)
On 18/03/2019 09:51, Chris Wilson wrote:
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
Quoting Chris Wilson (2019-03-18 09:51:47)
> 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!
>
Fixes: 7e3d9a59410d ("drm/i915: Track active engines within a context"
Quoting Tvrtko Ursulin (2019-03-18 10:46:28)
>
> On 18/03/2019 10:37, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-18 10:31:57)
> >>
> >> On 18/03/2019 09:51, Chris Wilson wrote:
> >>> As the final request on a ring may hold the reference to this ring (via
> >>> retiring the last pinned
Op 15-03-2019 om 20:54 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> We're currently leaving the CUS enabled if we disable the
> master plane directly after scanning out NV12.
>
> Could perhaps cause the selected slave plane to misbehave
> if we try to use it for scanning out something non-NV12
Quoting Tvrtko Ursulin (2019-03-18 09:52:56)
> From: Tvrtko Ursulin
>
> This allows the IS_PINEVIEW_ macros to be removed and avoid
> duplication of device ids already defined in i915_pciids.h.
>
> !IS_MOBILE check can be used in place of existing IS_PINEVIEW_G call
> sites.
>
> Signed-off-by:
Quoting Tvrtko Ursulin (2019-03-18 09:52:57)
> From: Tvrtko Ursulin
> Check can use the already defined and separate device info for this
That doesn't read very well:
IS_IRONLAKE_M can use the already defined intel_device_info.is_mobile
for this platform, so remove the instance of Ironlake's mo
Quoting Tvrtko Ursulin (2019-03-18 09:52:58)
> 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
Op 18-03-2019 om 12:04 schreef Maarten Lankhorst:
> Op 15-03-2019 om 20:54 schreef Ville Syrjala:
>> From: Ville Syrjälä
>>
>> We're currently leaving the CUS enabled if we disable the
>> master plane directly after scanning out NV12.
>>
>> Could perhaps cause the selected slave plane to misbehave
Quoting Chris Wilson (2019-03-14 11:44:37)
> Quoting Tvrtko Ursulin (2019-03-14 11:33:43)
> > I am only wondering what happens to reads/write to the trailing area?
> > Does shmemfs expands the backing store for this mmap and we just end up
> > with otherwise unused chunk at the end?
>
> My expec
Quoting Chris Wilson (2019-03-18 12:10:12)
> Quoting Chris Wilson (2019-03-14 11:44:37)
> > Quoting Tvrtko Ursulin (2019-03-14 11:33:43)
> > > I am only wondering what happens to reads/write to the trailing area?
> > > Does shmemfs expands the backing store for this mmap and we just end up
> > >
Quoting Chris Wilson (2019-03-14 07:58:29)
> We assumed that vm_mmap() would reject an attempt to mmap past the end of
> the filp (our object), but we were wrong.
Applications that tried to use the mmap beyond the end of the object
would be greeted by a SIGBUS.
> Reported-by: Antonio Argenziano
This patch series adds new tests to validate Display C states.
DC states like DC5 and DC6 are validated during PSR entry/exit
and during DPMS on/off cycle.
Sending new revision of patch series after addressing review comments and
other relevant changes.
1. Changing the name of test from "pm_dc" t
From: Jyoti Yadav
Currently this test validates DC5 upon PSR entry for supported platforms.
Added new file for compilation inside Makefile and Meson.
v2: Used the debugfs entry for DC counters instead of Registers.
Used shorter names for variables.
Introduced timeout to read DC counters.
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 the function which support dc9.
v2: Simplify the comment section.
v3: Remove
From: Jyoti Yadav
Added new subtest for DC6 entry during DPMS on/off cycle.
During DPMS on/off cycle DC6 counter is incremented.
v2: Renamed the subtest name.
v3: Rebased.
v4: Addressed review comment by replacing igt_display_init() to
igt_display_require(), changes got done in patch set 2.
From: Jyoti Yadav
Added new subtest for DC5 entry during DPMS on/off cycle.
During DPMS on/off cycle DC5 counter is incremented.
v2: Rename the subtest with meaningful name.
v3: Rebased.
v4: Addressed review comments by removing leftover code
cleanup().
v5: Addressed the review comment by re
From: Jyoti Yadav
This patch add subtest to check DC6 entry on PSR for the supported
platforms.
v2: Rename the subtest with more meaningful name.
v3: Rebased.
v4: Rebased, to fix compilation error in psr_enable().
Addressed review comment by fixing typo in comment description
of DC6 PSR
On 18/03/2019 09:51, Chris Wilson wrote:
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
Quoting Chris Wilson (2019-03-14 09:58:29)
> 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: J
Quoting Tvrtko Ursulin (2019-03-18 12:54:00)
>
> On 18/03/2019 09:51, Chris Wilson wrote:
> > 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, genera
Quoting Chris Wilson (2019-03-18 12:56:12)
> Quoting Tvrtko Ursulin (2019-03-18 12:54:00)
> >
> > On 18/03/2019 09:51, Chris Wilson wrote:
> > > 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
> > > u
On 18/03/2019 09:51, Chris Wilson wrote:
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 it
On 18/03/2019 09:51, Chris Wilson wrote:
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.
Sig
On 18/03/2019 10:56, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-18 10:46:28)
On 18/03/2019 10:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-18 10:31:57)
On 18/03/2019 09:51, Chris Wilson wrote:
As the final request on a ring may hold the reference to this ring (via
retir
On 18/03/2019 12:57, Chris Wilson wrote:
Quoting Chris Wilson (2019-03-18 12:56:12)
Quoting Tvrtko Ursulin (2019-03-18 12:54:00)
On 18/03/2019 09:51, Chris Wilson wrote:
For virtual engines, we need to keep the HW context alive while it
remains in use. For regular HW contexts, they are creat
On Fri, Mar 15, 2019 at 03:18:38PM -0700, Radhakrishna Sripada wrote:
> Fixes the clock-gating issue when pipe scaling is enabled.
> (Lineage #2006604312)
>
> Cc: Rodrigo Vivi
> Cc: Anusha Srivatsa
> Cc: Aditya Swarup
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_di
On Fri, Mar 15, 2019 at 05:45:26PM -0700, Lucas De Marchi wrote:
> The caller already knows what platform that is and what register should
> be used. Instead of keep adding if/else chains on a leaf functions,
> let the caller pass the register.
>
> We read cfgcr0 twice for CNL, but we were already
On Mon, Mar 18, 2019 at 09:52:56AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This allows the IS_PINEVIEW_ macros to be removed and avoid
> duplication of device ids already defined in i915_pciids.h.
>
> !IS_MOBILE check can be used in place of existing IS_PINEVIEW_G call
> sites.
>
Quoting Tvrtko Ursulin (2019-03-18 10:48:42)
>
> On 18/03/2019 10:40, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-18 10:21:41)
> >>
> >> On 18/03/2019 09:51, Chris Wilson wrote:
> >>> We want to use intel_engine_mask_t inside i915_request.h, which means
> >>> extracting it from the gen
On Sat, Mar 16, 2019 at 11:00:23AM -0300, Rodrigo Siqueira wrote:
> The kms_flip test relies on VBlank support, and this situation may
> exclude some virtual drivers to take advantage of this set of tests.
> This commit adds a mechanism that checks if a module has VBlank. If the
> target module has
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sprite.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 268fb34ff0e2..862fc172042f 100644
--- a/dri
On Mon, Mar 18, 2019 at 03:07:18PM +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/driv
This replaces [1] and [2]. The main changes since then:
- A device link between i915 and HDA (added meanwhile as a separate
change).
- Split the CDCLK change to happen before or after any updates
to the pipe depending on whether we're increasing or decreasing
CDCLK.
- Wait for vblank after a
From: Ville Syrjälä
CDCLK has to be at least twice the BLCK regardless of audio. Audio
driver has to probe using this hook and increase the clock even in
absence of any display.
v2: Use atomic refcount for get_power, put_power so that we can
call each once(Abhay).
v3: Reset power well 2 to a
From: Ville Syrjälä
If we have only a single active pipe and the cdclk change only requires
the cd2x divider to be updated bxt+ can do the update with forcing a full
modeset on the pipe. Try to hook that up.
v2:
- Wait for vblank after an optimized CDCLK change.
- Avoid optimization if the pipe
== Series Details ==
Series: series starting with [1/3] drm/i915: Split Pineview device info into
desktop and mobile
URL : https://patchwork.freedesktop.org/series/58123/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7e0ef0a2b5cc drm/i915: Split Pineview device info into deskt
== Series Details ==
Series: series starting with [1/3] drm/i915: Split Pineview device info into
desktop and mobile
URL : https://patchwork.freedesktop.org/series/58123/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Split Pineview device i
On Fri, 15 Mar 2019, Rodrigo Vivi wrote:
> On Fri, Mar 15, 2019 at 03:56:17PM +0200, Jani Nikula wrote:
>> v4 of [1], rebased and very mildly tweaked, with the intention to merge.
>
> before it starts conflicting again :)
>
>> I added
>> Chris' Reviewed-bys despite the rebase.
>
> Acked-by: Rodrig
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.
v2:
Op 18-03-2019 om 15:18 schreef Ville Syrjälä:
> On Mon, Mar 18, 2019 at 03:07:18PM +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_sprite.c | 29 +++--
>> 1 file changed, 19 insertions(+), 10 deletions(-)
>>
>> diff
Quoting Maarten Lankhorst (2019-03-13 13:21:46)
> Hey Sean and Joonas,
>
> One more pull request for the hdr-formats topic branch. FP16 support
> is now also implemented.
>
> Can this be pulled to drm-misc-next and dinq?
Pulled to drm-intel-next-queued.
Regards, Joonas
>
> ~Maarten
>
> topic
== Series Details ==
Series: series starting with [1/3] drm/i915: Split Pineview device info into
desktop and mobile
URL : https://patchwork.freedesktop.org/series/58123/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5765 -> Patchwork_12495
===
On 18/03/2019 13:56, Ville Syrjälä wrote:
On Mon, Mar 18, 2019 at 09:52:56AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This allows the IS_PINEVIEW_ macros to be removed and avoid
duplication of device ids already defined in i915_pciids.h.
!IS_MOBILE check can be used in place of exis
We no longer allow mixed C99 and kernel types, and the preference is to
use kernel types exclusively. Fix the C99 types that have crept in since
the mass conversion. No functional changes.
Cc: Juha-Pekka Heikkila
Cc: Kevin Strasser
Cc: Ramalingam C
Cc: Swati Sharma
Cc: Ville Syrjälä
Signed-of
On Mon, Mar 18, 2019 at 06:00:19PM +0200, Jani Nikula wrote:
> We no longer allow mixed C99 and kernel types, and the preference is to
> use kernel types exclusively. Fix the C99 types that have crept in since
> the mass conversion. No functional changes.
>
> Cc: Juha-Pekka Heikkila
> Cc: Kevin S
We've been free of deprecated drmP.h includes for a while, but one crept
in. Fend it off.
Cc: José Roberto de Souza
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_psr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_ps
From: Ville Syrjälä
The current intel_color_check() is a mess, and worse yet it is
in fact incorrect for several platforms. The hardware has
evolved quite a bit over the years, so let's just go for a clean
split between the platforms by turning this into a vfunc.
The actual work to split it up wi
From: Ville Syrjälä
Since CHV has the CGM unit we require a custom implementation
of .color_check().
This fixes the computation of gamma_enable as previously we
left it enabled even when were using the CGM gamma instead.
Now we turn off the legacy LUT unless it's actually required.
Signed-off-b
From: Ville Syrjälä
Apart from CHV the other gmch platforms don't currently
require much work in .color_check(). So let's start by
extracting i9xx_color_check().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 33 +-
1 file changed, 28 insertio
From: Ville Syrjälä
Unlike the earlier platforms GLK has dedicated degamma and gamma
LUTs. And quite curiously the degamma LUT is actually controlled
via the PLANE_COLOR_CTL CSC enable bit. Hence we must compute
gamma_enable and csc_enable differently to pre-GLK platforms.
Signed-off-by: Ville S
From: Ville Syrjälä
ICL is rather easy when it comes to .color_check() as it
finally provides us with a full color pipeline with
individual knobs for each stage.
We'll also start bypassing each LUT individually when
it is not needed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel
From: Ville Syrjälä
In prepartion for per-platform color_check() functions extract the
common code into a separate function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 68 ++
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/
From: Ville Syrjälä
Don't load the linear degamma LUT on ICL. The hardware no longer
has any silly linkages between the CSC enable and degamma LUT
enable so the degamma LUT is only needed when it's actually
enabled.
Also add comments to explain the situation on GLK.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
intel_color_check() is mess. Blow it up into clean platform sized
chunks. Also eliminate some redundant linear LUT loads as a result.
Ville Syrjälä (10):
drm/i915: Extract check_luts()
drm/i915: Turn intel_color_check() into a vfunc
drm/i915: Extract i9xx_color_check()
From: Ville Syrjälä
With everything else moved out of the way only ilk+
remains using _intel_color_check(). Streamline the logic
into ilk_color_check().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 70 --
1 file changed, 27 insertions(+), 43
From: Ville Syrjälä
Provide a separate .color_check() for BDW+ where we currently
provide the split gamma mode etc.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel
From: Ville Syrjälä
We now bypass the legacy LUT when it's not needed, so
no point in filling it up with a linear LUT.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/
On Fri, 15 Mar 2019 12:32:22 -0700
"Souza, Jose" wrote:
> On Fri, 2019-03-15 at 12:19 -0700, Rodrigo Vivi wrote:
> > 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 m
On 18/03/2019 09:51, Chris Wilson wrote:
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 inser
On Fri, 15 Mar 2019 10:57:11 -0700
Rodrigo Vivi wrote:
> From: Anusha Srivatsa
>
> EHL uses the same firmware as ICL.
Reviewed-by: Bob Paauwe
>
> Cc: Bob Paauwe
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Rodrigo Vivi
> Reviewed-by: Lucas De Marchi
> Link:
> https://patchwork.fre
On 18/03/2019 09:51, Chris Wilson wrote:
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. (I
Quoting Tvrtko Ursulin (2019-03-18 16:22:12)
>
> On 18/03/2019 09:51, Chris Wilson wrote:
> > +static int gem_context_register(struct i915_gem_context *ctx,
> > + struct drm_i915_file_private *fpriv)
> > +{
> > + int ret;
> > +
>
> Assert struct mutex for now? With
Quoting Chris Wilson (2019-03-18 16:30:58)
> Quoting Tvrtko Ursulin (2019-03-18 16:22:12)
> >
> > On 18/03/2019 09:51, Chris Wilson wrote:
> > > +static int gem_context_register(struct i915_gem_context *ctx,
> > > + struct drm_i915_file_private *fpriv)
> > > +{
> > > +
1 - 100 of 184 matches
Mail list logo
