On Thu, Oct 14, 2021 at 5:02 AM wrote:
>
> Hi,
>
> I review the code.
>
> It seems I forget to delete the definition of the variable "inst",I'm sry for
> that.: (
>
> I'll submit another patch soon.
>
I already wrote the patch and pushed it:
On Wed, Oct 13, 2021 at 05:10:39PM -0700, John Harrison wrote:
> On 10/13/2021 13:42, Matthew Brost wrote:
> > Add multi-lrc context registration H2G. In addition a workqueue and
> > process descriptor are setup during multi-lrc context registration as
> > these data structures are needed for
From: Andi Shyti
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create a 'gt/' directory in sysfs which will contain gt0...gtN
directories related to each tile configured in the GPU. Move the
power management files inside those directories.
The
On Wed, 13 Oct 2021 18:07:05 -0700, John Harrison wrote:
>
> On 10/13/2021 15:53, Dixit, Ashutosh wrote:
> >> diff --git a/tests/i915/gem_exec_fair.c b/tests/i915/gem_exec_fair.c
> >> index ef5a450f6..ca9c73c6e 100644
> >> --- a/tests/i915/gem_exec_fair.c
> >> +++ b/tests/i915/gem_exec_fair.c
> >>
On Fri, 8 Oct 2021 at 23:36, Thomas Hellström
wrote:
>
> This patch series introduces failsafe migration blits.
> The reason for this seemingly strange concept is that if the initial
> clearing or readback of LMEM fails for some reason, and we then set up
> either GPU- or CPU ptes to the
On 10/13/2021 15:53, Dixit, Ashutosh wrote:
On Wed, 13 Oct 2021 15:43:17 -0700, wrote:
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So,
On 10/13/2021 13:42, Matthew Brost wrote:
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1
media UMD:
On 10/13/2021 13:42, Matthew Brost wrote:
If an object in the excl or shared slot is a composite fence from a
parallel submit and the current request in the conflict tracking is from
the same parallel context there is no need to enforce ordering as the
ordering is already implicit. Make the
On 10/13/2021 13:42, Matthew Brost wrote:
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arises because with multi-lrc
breadcrumbs there is a handshake between the
On 10/13/2021 13:42, Matthew Brost wrote:
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops.
On 10/13/2021 13:42, Matthew Brost wrote:
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between parent and child is needed, syncing the set of BBs at the
beginning and end of each batch. This is
== Series Details ==
Series: drm/i915/gt: make a gt sysfs group and move power management files
(rev6)
URL : https://patchwork.freedesktop.org/series/73190/
State : failure
== Summary ==
Applying: drm/i915/gt: make a gt sysfs group and move power management files
Using index info to
On 10/13/2021 13:42, Matthew Brost wrote:
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its children. The parent context owns the reset replaying / canceling
requests as needed.
v2:
(John Harrison)
On 10/13/2021 13:42, Matthew Brost wrote:
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the
Hi Lucas,
On Wed, Oct 13, 2021 at 05:04:27PM -0700, Lucas De Marchi wrote:
> On Wed, Oct 13, 2021 at 12:17:38AM +0200, Andi Shyti wrote:
> > From: Andi Shyti
> >
> > The following interfaces:
> >
> > i915_wedged
> > i915_forcewake_user
> >
> > are dependent on gt values. Put them inside gt/
On 10/13/2021 13:42, Matthew Brost wrote:
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harrison)
- Move GuC specific fields into
On 10/13/2021 13:42, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while any user context has scheduling enabled. Returning GT
idle when it is not can cause all sorts of issues throughout the stack.
v2:
(Daniel Vetter)
- Add might_lock
On Wed, Oct 13, 2021 at 12:17:38AM +0200, Andi Shyti wrote:
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
On 10/13/2021 13:42, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight. To do this must
issue the deregister H2G from a worker as context can be destroyed from
an atomic context and taking GT PM ref
On 10/13/2021 13:42, Matthew Brost wrote:
Move guc_id allocation under submission state sub-struct as a future
patch will reuse the spin lock as a global submission state lock. Moving
this into sub-struct makes ownership of fields / lock clear.
v2:
(Docs)
- Add comment for submission_state
On Wed, 13 Oct 2021 15:43:17 -0700, wrote:
>
> From: John Harrison
>
> The gem_exec_fair test is specifically testing scheduler algorithm
> performance. However, GuC does not implement the same algorithm as
> execlist mode and this test is not applicable. So, until sw arch
> approves a new
Ah there are three typos :/
s/deference/dereference for this one and for the 2nd patch as well.
Regards,
Nirmoy
On 10/13/2021 8:35 PM, Nirmoy Das wrote:
Debugfs APIs returns encoded error on failure instead of NULL
and for drm primary/minor debugfs directories, we save the
returned value in
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So, until sw arch
approves a new algorithm and it is implemented in GuC, stop running
the test.
On Thu, Oct 14, 2021 at 01:28:24AM +0300, Imre Deak wrote:
> On Thu, Oct 14, 2021 at 12:54:58AM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 14, 2021 at 12:32:55AM +0300, Imre Deak wrote:
> > > On Wed, Oct 13, 2021 at 11:45:33PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Oct 13, 2021 at 11:27:02PM
Do not check for NULL value as drm.primary->debugfs_root
will either contain a valid pointer or an encoded error
instead of NULL.
CC: Jani Nikula
CC: Joonas Lahtinen
CC: Rodrigo Vivi
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/debugfs_gt.c | 3
Debugfs APIs returns encoded error on failure so use
debugfs_lookup() instead of checking for NULL.
CC: Lukas Wunner
CC: David Airlie
CC: Daniel Vetter
CC: Maarten Lankhorst
CC: Maxime Ripard
CC: Thomas Zimmermann
Signed-off-by: Nirmoy Das
---
drivers/gpu/vga/vga_switcheroo.c | 2 +-
1
For debugfs directory, it is recommended to save the result
and pass over to next debugfs API for creating debugfs
files/directories. Error conditions are handled by debugfs APIs.
CC: Christian Koenig
CC: Huang Rui
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
Debugfs APIs returns encoded error on failure instead of NULL
and for drm primary/minor debugfs directories, we save the
returned value in the dentry pointer and pass it on to drm
drivers to further create debugfs files/directories. Error
conditions are handled by debugfs APIs, so no need to check
On Thu, Oct 14, 2021 at 12:54:58AM +0300, Ville Syrjälä wrote:
> On Thu, Oct 14, 2021 at 12:32:55AM +0300, Imre Deak wrote:
> > On Wed, Oct 13, 2021 at 11:45:33PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 13, 2021 at 11:27:02PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Oct 07, 2021 at
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev6)
URL : https://patchwork.freedesktop.org/series/92789/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10732 -> Patchwork_21334
Summary
---
On Tue, Oct 05, 2021 at 10:23:22PM +0200, Hans de Goede wrote:
> Add support for eDP panels with a built-in privacy screen using the
> new drm_privacy_screen class.
>
> Changes in v3:
> - Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector()
>
> Changes in v2:
> - Call
On Thu, Oct 14, 2021 at 12:32:55AM +0300, Imre Deak wrote:
> On Wed, Oct 13, 2021 at 11:45:33PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 13, 2021 at 11:27:02PM +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 07, 2021 at 11:35:15PM +0300, Imre Deak wrote:
> > > > Future platforms change the
On 21/10/13 09:36PM, Patchwork wrote:
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_21333 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21333,
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev6)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev6)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
96b392951d3d drm/i915/guc: Move GuC guc_id allocation under submission state
sub-struct
== Series Details ==
Series: drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers (rev2)
URL : https://patchwork.freedesktop.org/series/95578/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10732 -> Patchwork_21333
Summary
On Thu, Oct 14, 2021 at 12:01:41AM +0300, Imre Deak wrote:
> On Wed, Oct 13, 2021 at 11:14:42PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 08, 2021 at 03:19:08AM +0300, Imre Deak wrote:
> > > + /* Wa_22011186057 */
> > > + if (IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
> > > + return
On Wed, Oct 13, 2021 at 11:45:33PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 13, 2021 at 11:27:02PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 07, 2021 at 11:35:15PM +0300, Imre Deak wrote:
> > > Future platforms change the location of CCS control planes in CCS
> > > framebuffers, so add
On Tue, Oct 12, 2021 at 05:43:21PM +0300, Jani Nikula wrote:
> Use the new link training delay helpers, fixing the delays for
> 128b/132b.
>
> For existing 8b/10b functionality, this will cause additional 1-byte
> DPCD reads for LTTPR delays instead of using the cached values. It's
> just too
On Tue, Oct 12, 2021 at 05:43:20PM +0300, Jani Nikula wrote:
> The link training delays are different and/or available in different
> DPCD offsets depending on:
>
> - Clock recovery vs. channel equalization
> - DPRX vs. LTTPR
> - 128b/132b vs. 8b/10b
> - DPCD 1.4+ vs. earlier
>
> Add helpers to
On Wed, Oct 13, 2021 at 11:18:27PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 07, 2021 at 11:35:09PM +0300, Imre Deak wrote:
> > Add a tiling atttribute to the modifier descriptor, which let's us
> > get the tiling without listing the modifiers twice.
> >
> > Signed-off-by: Imre Deak
> > ---
> >
On Wed, Oct 13, 2021 at 11:17:04PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 08, 2021 at 03:19:09AM +0300, Imre Deak wrote:
> > Move the function retrieving the format override information for a given
> > format/modifier to intel_fb.c. We can store a pointer to the format list
> > in each
On Wed, 2021-10-13 at 23:39 +0300, Gwan-gyeong Mun wrote:
>
> On 10/11/21 11:53 PM, Souza, Jose wrote:
> > On Thu, 2021-10-07 at 12:31 +0300, Gwan-gyeong Mun wrote:
> > >
> > > On 10/6/21 11:04 PM, Souza, Jose wrote:
> > > > On Wed, 2021-10-06 at 11:50 +0300, Gwan-gyeong Mun wrote:
> > > > >
>
On Wed, Oct 13, 2021 at 11:14:42PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 08, 2021 at 03:19:08AM +0300, Imre Deak wrote:
> > Add a table describing all the framebuffer modifiers used by i915 at one
> > place. This has the benefit of deduplicating the listing of supported
> > modifiers for each
On 21/10/13 03:06PM, Ville Syrjälä wrote:
> > And yes C is dangerous, but also C is verbose. I think one lesson from igt
> > is that too many magic block constructs are bad, it's just not how C
> > works. Definitely not in the kernel, where "oops I got it wrong because it
> > was too clever" is
On Wed, Oct 13, 2021 at 11:27:02PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 07, 2021 at 11:35:15PM +0300, Imre Deak wrote:
> > Future platforms change the location of CCS control planes in CCS
> > framebuffers, so add intel_fb_is_rc_ccs_ctrl_plane() to query for these
>
> Don't we use the term
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arises because with multi-lrc
breadcrumbs there is a handshake between the parent and children to make
forward progress.
Parallel contexts are perma-pinned by the upper layers which makes the
backend implementation rather simple. The parent pins the guc_id and
children increment the parent's pin count on pin to ensure all the
contexts are unpinned before we disable scheduling with the GuC / or
deregister the
The GuC must receive requests in the order submitted for contexts in a
parent-child relationship to function correctly. To ensure this, insert
a submit fence between the current request and last request submitted
for requests / contexts in a parent child relationship. This is
conceptually similar
Assign contexts in parent-child relationship consecutive guc_ids. This
is accomplished by partitioning guc_id space between ones that need to
be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
available guc_ids). The consecutive search is implemented via the bitmap
API.
This
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1
media UMD: https://github.com/intel/media-driver/pull/1252
v2:
(Daniel Vetter)
- Add IGT link
Enable multi-bb execbuf by enabling the set_parallel extension.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet and bypass path have
been updated to
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harrison)
- Move GuC specific fields into sub-struct
- Clean up WQ defines
- Add
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while any user context has scheduling enabled. Returning GT
idle when it is not can cause all sorts of issues throughout the stack.
v2:
(Daniel Vetter)
- Add might_lock annotations to pin / unpin function
v3:
(CI)
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 179 ++
.../drm/i915/selftests/i915_live_selftests.h | 1
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its children. The parent context owns the reset replaying / canceling
requests as needed.
v2:
(John Harrison)
- Simply loop in find active request
- Add
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between parent and child is needed, syncing the set of BBs at the
beginning and end of each batch. This is implemented via custom
emit_bb_start &
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops. First a loop is used to find
all the
Parallel submission create composite fences (dma_fence_array) for excl /
shared slots in objects. The I915_GEM_BUSY IOCTL checks these slots to
determine the busyness of the object. Prior to patch it only check if
the fence in the slot was a i915_request. Update the check to understand
composite
If an object in the excl or shared slot is a composite fence from a
parallel submit and the current request in the conflict tracking is from
the same parallel context there is no need to enforce ordering as the
ordering is already implicit. Make the request conflict tracking
understand this by
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
v2:
(John Harrison)
- Output number children in debugfs
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 52 ++-
1 file
Move guc_id allocation under submission state sub-struct as a future
patch will reuse the spin lock as a global submission state lock. Moving
this into sub-struct makes ownership of fields / lock clear.
v2:
(Docs)
- Add comment for submission_state sub-structure
v3:
(John Harrison)
- Fixup
In GuC parent-child contexts the parent context controls the scheduling,
ensure only the parent does the scheduling operations.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 -
1 file changed, 12 insertions(+), 1
Add logical engine mapping. This is required for split-frame, as
workloads need to be placed on engines in a logically contiguous manner.
v2:
(Daniel Vetter)
- Add kernel doc for new fields
v3:
(Tvrtko)
- Update comment for new logical_mask field
v4:
(John Harrison)
- Update comment for
Expose logical engine instance to user via query engine info IOCTL. This
is required for split-frame workloads as these needs to be placed on
engines in a logically contiguous order. The logical mapping can change
based on fusing. Rather than having user have knowledge of the fusing we
simply just
Calling switch_to_kernel_context isn't needed if the engine PM reference
is taken while all user contexts are pinned as if don't have PM ref that
guarantees that all user contexts scheduling is disabled. By not calling
switch_to_kernel_context we save on issuing a request to the engine.
v2:
Introduce context parent-child relationship. Once this relationship is
created all pinning / unpinning operations are directed to the parent
context. The parent context is responsible for pinning all of its
children and itself.
This is a precursor to the full GuC multi-lrc implementation but
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight. To do this must
issue the deregister H2G from a worker as context can be destroyed from
an atomic context and taking GT PM ref blows up. Previously we took a
runtime PM from
As discussed in [1] we are introducing a new parallel submission uAPI
for the i915 which allows more than 1 BB to be submitted in an execbuf
IOCTL. This is the implemenation for both GuC and execlists.
In addition to selftests in the series, an IGT is available implemented
in the first 4 patches
Update parallel submit doc to point to i915_drm.h
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 --
Documentation/gpu/rfc/i915_scheduler.rst | 4 +-
2 files changed, 2 insertions(+), 124 deletions(-)
On 10/11/21 11:53 PM, Souza, Jose wrote:
On Thu, 2021-10-07 at 12:31 +0300, Gwan-gyeong Mun wrote:
On 10/6/21 11:04 PM, Souza, Jose wrote:
On Wed, 2021-10-06 at 11:50 +0300, Gwan-gyeong Mun wrote:
On 10/6/21 2:18 AM, José Roberto de Souza wrote:
Alderlake-P was getting 'max time under
On Fri, Oct 08, 2021 at 03:19:08AM +0300, Imre Deak wrote:
> bool is_ccs_plane(const struct drm_framebuffer *fb, int plane);
> bool is_gen12_ccs_plane(const struct drm_framebuffer *fb, int plane);
> bool is_gen12_ccs_cc_plane(const struct drm_framebuffer *fb, int plane);
Side note:
We have
The previous patch removed drm_modeset_{lock,unlock}_all, which were the
only users of this field inside the drm_mode_config structure.
Signed-off-by: Fernando Ramos
---
include/drm/drm_mode_config.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/drm/drm_mode_config.h
Functions drm_modeset_lock_all() and drm_modeset_unlock_all() are no
longer used anywhere and can be removed.
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_modeset_lock.c | 94 +-
include/drm/drm_modeset_lock.h | 2 -
2 files changed, 3 insertions(+), 93
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
NOTE:
While this change is similar to the one done two commits ago, it
contains an important extra nuances that I'm going to explain next.
Refactor places using drm_modeset_{lock,unlock}_all() so that they only
appear once per function.
This is needed so that in the next commit I can replace those functions
by the new macros (which use labels that can only appear once per
function).
Signed-off-by: Fernando Ramos
---
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 21 ++---
1 file changed, 14 insertions(+),
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/gma500/psb_device.c | 18 --
1 file changed, 12 insertions(+), 6
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
NOTE:
While the previous two commits were a simple "search and replace", this
time I had to do a bit of refactoring as only one call to
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
NOTE:
I separated this change from the rest of modifications to the i915
driver to point out something special explained next.
The only
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/i915/display/intel_audio.c| 16 ---
.../drm/i915/display/intel_display_debugfs.c
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++-
1 file changed, 10
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/omapdrm/omap_fb.c | 9 ++---
1 file changed, 6 insertions(+),
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 --
1 file changed, 4
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/radeon/radeon_device.c | 21 +++--
drivers/gpu/drm/radeon/radeon_dp_mst.c
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
Reported-by: kernel test robot
---
drivers/gpu/drm/tegra/dsi.c | 6 --
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 +++
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_client_modeset.c | 5 +++--
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
Reported-by: kernel test robot
---
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_display.c | 18
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_client_modeset.c | 9 +++--
1 file changed, 3 insertions(+),
Hi all,
One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
"use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
patch series is about.
You will find two types of changes here:
- Replacing "drm_modeset_lock_all_ctx()" (and surrounding
On Thu, Oct 07, 2021 at 11:35:15PM +0300, Imre Deak wrote:
> Future platforms change the location of CCS control planes in CCS
> framebuffers, so add intel_fb_is_rc_ccs_ctrl_plane() to query for these
Don't we use the term 'ccs_plane' everywhere else?
> planes independently of the platform. This
On Thu, Oct 07, 2021 at 11:35:09PM +0300, Imre Deak wrote:
> Add a tiling atttribute to the modifier descriptor, which let's us
> get the tiling without listing the modifiers twice.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 20
> 1 file
On Fri, Oct 08, 2021 at 03:19:09AM +0300, Imre Deak wrote:
> Move the function retrieving the format override information for a given
> format/modifier to intel_fb.c. We can store a pointer to the format list
> in each modifier's descriptor instead of the corresponding switch/case
> logic,
On Fri, Oct 08, 2021 at 03:19:08AM +0300, Imre Deak wrote:
> Add a table describing all the framebuffer modifiers used by i915 at one
> place. This has the benefit of deduplicating the listing of supported
> modifiers for each platform and checking the support of these modifiers
> on a given
Set look all ok to me, including v2 patches.
Reviewed-by: Juha-Pekka Heikkila
On 7.10.2021 23.35, Imre Deak wrote:
This patchset adds a descriptor table for all modifiers used by i915,
which deduplicates the listing of supported modifiers during plane
initialization and during checking for a
1 - 100 of 206 matches
Mail list logo
