== Series Details ==
Series: drm: update locking for modesetting (rev6)
URL : https://patchwork.freedesktop.org/series/93864/
State : failure
== Summary ==
Applying: drm: fix null ptr dereference in drm_master_release
Applying: drm: convert drm_device.master_mutex into a rwsem
Applying: drm: l
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can race
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.
To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl p
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map
There is a clear separation between functions that read or change
these attributes. Hence, c
drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:
1. Error path in drm_open_helper
drm_open():
drm_open_helper():
drm_master_open():
drm_new_set_master(); <--- returns -
Hi,
I updated the patch set with some suggestions by Daniel Vetter, and
dropped the patches after patch 4 so that we can stick the landing for
avoiding races with modesetting rights before dealing with the tricky
spinlock.
Overall, this series fixes races with modesetting rights, and converts
drm
On 26/8/21 9:21 pm, Daniel Vetter wrote:
On Thu, Aug 26, 2021 at 10:01:22AM +0800, Desmond Cheong Zhi Xi wrote:
Previously, master_lookup_lock was introduced in
commit 0b0860a3cf5e ("drm: serialize drm_file.master with a new
spinlock") to serialize accesses to drm_file.master. This then allowed
Hi Ayaz,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20210830]
[cannot apply to v5.14]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
drivers/gpu/drm/i915/gt/intel_mocs.c:496:5: warning: symbol 'get_ctx_reg_count'
was not declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
intel_mocs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt
Hi Umesh,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20210830]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.14]
[If your
Hi Ayaz,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20210830]
[cannot apply to v5.14]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi Ayaz,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20210830]
[cannot apply to v5.14]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
== Series Details ==
Series: Enable triggered perf query for Xe_HP (rev2)
URL : https://patchwork.freedesktop.org/series/93357/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10538 -> Patchwork_20922
Summary
---
**FAI
Hi Ayaz,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20210830]
[cannot apply to v5.14]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 26/8/21 8:59 pm, Daniel Vetter wrote:
On Thu, Aug 26, 2021 at 10:01:19AM +0800, Desmond Cheong Zhi Xi wrote:
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
c
== Series Details ==
Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)
URL : https://patchwork.freedesktop.org/series/93570/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10537_full -> Patchwork_20921_full
Summary
--
On 26/8/21 5:58 pm, Daniel Vetter wrote:
On Thu, Aug 26, 2021 at 10:01:18AM +0800, Desmond Cheong Zhi Xi wrote:
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mu
On 8/27/2021 6:27 PM, Daniele Ceraolo Spurio wrote:
From: Vitaly Lubart
Export PAVP client to work with i915 driver,
for binding it uses kernel component framework.
v2:drop debug prints, refactor match code to match mei_hdcp (Tomas)
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkle
Hi Jani,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20210830]
[cannot apply to v5.14]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
== Series Details ==
Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL : https://patchwork.freedesktop.org/series/94168/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10537_full -> Patchwork_20920_full
Summar
On Fri, 2021-08-27 at 20:53 +, Patchwork wrote:
Patch Details
Series: series starting with [CI,1/3] drm/i915/display: Drop PSR support from
HSW and BDW (rev2)
URL:https://patchwork.freedesktop.org/series/94112/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patch
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report can be found faster if we can sample the HW tail and
head registers when the report was triggered. Whitelist OA buffer
specific registers.
v2:
-
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow non-privileged
user to trigger reports.
Whitelist registers only if perf_stream_paranoid is set to 0. In
i915_perf_open_ioctl, this setting is checked and the whitelist is
en
From: Piotr Maciejewski
A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.
v2: Separate code from other patches (Lionel)
v3: Reset PMON enable when disabling perf to save power (Lionel)
v4: Use intel_uncore_rm
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggere
This is a revival of the patch series to support triggered perf query reports
from here - https://patchwork.freedesktop.org/series/83831/
The patches were not pushed earlier because corresponding UMD changes were
missing. This revival addresses UMD changes in GPUvis for this series. GPUvis
uses th
Refactor intel_engine_apply_whitelist into locked and unlocked versions
so that a caller who already has the lock can apply whitelist.
v2: Fix sparse warning
v3: (Chris)
- Drop prefix and suffix for static function
- Use longest to shortest line ordering for variable declaration
Signed-off-by: Um
From: Chris Wilson
Strip the encoded bits from the register offset so that we only use the
address for looking up the RING_NONPRIV entry.
Signed-off-by: Chris Wilson
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +
1 file changed,
From: Chris Wilson
The OA subsystem would like to enable its privileged clients access to
the OA registers from execbuf. This requires temporarily removing the
HW validation from those registers for the duration of the OA client,
for which we need to allow OA to dynamically adjust the set of
RING
From: Chris Wilson
Switch the search and grow code of the _wa_add to use _wa_index and
_wa_list_grow.
Signed-off-by: Chris Wilson
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 124 +++-
1 file changed, 71 insertions(+), 53 deletions(-)
d
On Thu, Aug 05, 2021 at 12:47:05PM +0200, Daniel Vetter wrote:
> Specifically document the new/clarified rules around how the shared
> fences do not have any ordering requirements against the exclusive
> fence.
>
> But also document all the things a bit better, given how central
> struct dma_resv
== Series Details ==
Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)
URL : https://patchwork.freedesktop.org/series/93570/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10537 -> Patchwork_20921
Summary
---
**SUC
== Series Details ==
Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL : https://patchwork.freedesktop.org/series/94168/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10537 -> Patchwork_20920
Summary
---
== Series Details ==
Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL : https://patchwork.freedesktop.org/series/94168/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gp
On Mon, Aug 30, 2021 at 10:31:28AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote:
> > On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> > > From: Maor Gottlieb
> > >
> > > Changelog:
> > > v4:
> > > * Unify sg_free_table_entries wi
On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote:
> On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> > From: Maor Gottlieb
> >
> > Changelog:
> > v4:
> > * Unify sg_free_table_entries with __sg_free_table
> > v3: https://lore.kernel.org/lkml/cover.1627551226.git.le
== Series Details ==
Series: drm/i915/display: debugfs cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/94164/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10536_full -> Patchwork_20919_full
Summary
---
On Thu, Aug 26, 2021 at 01:37:34PM -0400, Rodrigo Vivi wrote:
> On Fri, Aug 20, 2021 at 08:26:14PM +0300, Ville Syrjälä wrote:
> > On Fri, Aug 20, 2021 at 03:52:59PM +0800, Kai-Heng Feng wrote:
> > > Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> > > fast+narrow link on eDP
From: Sreedhar Telukuntla
Initialize the L3CC table as part of mocs initalization to program
LNCFCMOCSx registers, so that the mocs settings are available for
selection for subsequent memory transactions in driver load path.
Signed-off-by: Sreedhar Telukuntla
Signed-off-by: Ayaz A Siddiqui
---
From: Apoorva Singh
Blitter commands which do not have MOCS fields rely on
cacheability of BlitterCacheControlRegister which was mapped
to index 0 by default.Once we changed the MOCS value of
index 0 to L3 WB, tests like gem_linear_blits started failing
due to a change in cacheability from UC to
Some platform like XEHPSVD does not have Renderer engines. since
read_l3cc_table() is guarded by renderer class due to that check
of L3CC table was not being performed on those platforms.
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 4 ++--
1 file changed, 2 inser
In order to program unused and reserved mocs entries to L3_WB,
we need to create a separate mocs table for alderlake.
This patch will also covers wa_1608975824.
Cc: Chris P Wilson
Cc: Lucas De Marchi
Reviewed-by: Matt Roper
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915/gt/intel_mo
Historically we've initialized all undefined/reserved entries in
a platform's MOCS table to the contents of table entry #1 (i.e.,
I915_MOCS_PTE).
Going forward, we can't assume that table entry #1 will always
contain suitable values to use for undefined/reserved table
indices. We'll allow a platfor
Cache-control registers for Command Stream(CMD_CCTL) are used
to set catchability for memory writes and reads outputted by
Command Streamers on Gen12 onward platforms.
These registers need to point un-cached(UC) MOCS index.
Cc: Matt Roper
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915
From: Srinivasan Shanmugam
Few registers need to be programmed with
appropriate MOCS indexes for proper functioning.
As of now, there are two categories of registers that
need to be programmed, these are engine power domains
register and engine state context register.
A framework is being added
Now there are lots of Command and registers that require mocs index
programming.
So propagating mocs_index from mocs to gt so that it can be
used directly without having platform-specific checks.
Cc: CQ Tang
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 4
d
Gen >= 12 onwards MOCS table doesn't have a setting for PTE
so I915_MOCS_PTE is not a valid index and it will have different
MOCS values are based on the platform.
To detect these kinds of misprogramming, all the unspecified and
reserved MOCS indexes are set to WB_L3. TGL/RKL unspecified MOCS
inde
On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> From: Maor Gottlieb
>
> Changelog:
> v4:
> * Unify sg_free_table_entries with __sg_free_table
> v3: https://lore.kernel.org/lkml/cover.1627551226.git.leo...@nvidia.com/
> * Rewrote to new API suggestion
> * Split for more patches
== Series Details ==
Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it
URL : https://patchwork.freedesktop.org/series/94161/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10536_full -> Patchwork_20916_full
On Mon, Aug 30, 2021 at 01:29:01PM +0300, Jani Nikula wrote:
> The VESA Organization Vendor-Specific Data Block, defined in VESA
> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
> stream count and segment pixel overlap.
>
> DisplayID v1.3 has Appendix B: DisplayID as an EDID
== Series Details ==
Series: drm/i915/display: debugfs cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/94164/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10536 -> Patchwork_20919
Summary
---
**SUCCES
Prefer the intel_ types. No functional changes.
v2: Fix build.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_connector.c | 2 +-
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 3 ++-
drivers/gpu/drm/i915/display/intel_display_debugfs.h | 6 +++---
3 files chang
Hi,
On Tue, Aug 17, 2021 at 10:43 PM Anisse Astier wrote:
>
> This patch series is for making the GPD Win Max display usable with
> Linux.
>
> The GPD Win Max is a small laptop, and its eDP panel does not send an
> EDID over DPCD; the EDID is instead available in the intel opregion, in
> mailbox
== Series Details ==
Series: drm/i915: Short-term pinning and async eviction.
URL : https://patchwork.freedesktop.org/series/94162/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10536 -> Patchwork_20917
Summary
---
*
== Series Details ==
Series: drm/i915/display: debugfs cleanups
URL : https://patchwork.freedesktop.org/series/94164/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drive
== Series Details ==
Series: drm/i915: Short-term pinning and async eviction.
URL : https://patchwork.freedesktop.org/series/94162/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/dr
== Series Details ==
Series: drm/i915: Short-term pinning and async eviction.
URL : https://patchwork.freedesktop.org/series/94162/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa0ce1cd930e drm/i915: Move __i915_gem_free_object to ttm_bo_destroy
667b39786fe3 drm/i915: Remove u
== Series Details ==
Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it
URL : https://patchwork.freedesktop.org/series/94161/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10536 -> Patchwork_20916
Summary
-
Prefer the intel_ types. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_connector.c | 2 +-
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 3 ++-
drivers/gpu/drm/i915/display/intel_display_debugfs.h | 4 ++--
3 files changed, 5 insertions(+
Failures to register debugfs should be ignored anyway, so stop
propagating errors altogether for clarity and simplicity. No functional
changes.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 19 +--
.../drm/i915/display/intel_display_debugfs.h |
The debugfs file shows it's not capable, don't duplicate the info.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/
Clean up the LPSP capability printout. No functional changes.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 44 +++
1 file changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu
Clean up the LPSP status printout. No functional changes.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 37 ++-
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm
Some minor cleanupi of the display debugfs code.
BR,
Jani.
Jani Nikula (5):
drm/i915/debugfs: clean up LPSP status
drm/i915/debugfs: clean up LPSP capable
drm/i915/debugfs: register LPSP capability on all platforms
drm/i915/display: stop returning errors from debugfs registration
drm/i
== Series Details ==
Series: drm/displayid: VESA vendor block and drm/i915 MSO use of it
URL : https://patchwork.freedesktop.org/series/94161/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./d
Am 30.08.21 um 09:48 schrieb Thomas Hellström:
The code was making a copy of a struct ttm_resource. However,
recently the struct ttm_resources were allowed to be subclassed and
also were allowed to be malloced, hence the driver could end up assuming
the copy we handed it was subclassed and wor
When reworking the code to move the eviction fence to the object,
the best code is removed code.
Remove some functions that are unused, and change the function definition
if it's only used in 1 place.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_active.c | 28 +++--
When we implement delayed destroy, we may have a second
call to the delete_mem_notify() handler, while free_object()
only should be called once.
Move it to bo->destroy(), to ensure it's only called once.
This fixes some weird memory corruption issues with delayed
destroy when async eviction is use
Call drop_pages with the gem object lock held, instead of the other
way around. This will allow us to drop the vma bindings with the
gem object lock held.
We plan to require the object lock for unpinning in the future,
and this is an easy target.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available after the moving
fence is signaled, and pinning a cpu map will only work aft
Big delta, but boils down to moving set_pages to i915_vma.c, and removing
the special handling, all callers use the defaults anyway. We only remap
in ggtt, so default case will fall through.
Because we still don't require locking in i915_vma_unpin(), handle this by
using xchg in get_pages(), as it
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 48 ---
dr
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.c| 9 -
drivers/gpu/drm/i915/i915_vma.h| 6 +++---
drivers/gpu/d
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 40 +
1 file changed, 5 inserti
We forgot to call intel_runtime_pm_put on error, fix it!
Signed-off-by: Maarten Lankhorst
Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: # v5.13+
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 7 +--
1 file changed, 5 insertio
Expose the fence to ttm_bo->moving, which will get picked up by i915
through the i915_gem_object_get_moving_fence call. Should be sufficient
for the needs we have.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 104
1 file changed, 54 inse
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created. It just has to look real
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
protected by the object lock.
This removes the need to unpin, which is done by just releasing the
lock.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 64 ++-
drivers/gpu/drm
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 1f07ac4e0672..df81a0dc481e 100644
--- a/drivers/gpu/
We want to remove more members of i915_vma, which requires the locking to be
held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to the
object may be held by th
We want to get rid of i915_vma tracking to simplify the code and
lifetimes. Add a way to set/put the moving fence, in preparation for
removing the tracking.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 15 +++
drivers/gpu/drm/i915/gem/i915_gem_obj
i915_vma_wait_for_bind needs the vma lock held, fix the caller.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 40 +++--
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915
This allows us to finally get rid of all the assumptions that vma->obj is NULL.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/mock_engine.c | 35 ---
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/dri
Use a single null-terminated array for simplicity instead of a linked
list. This might slightly speed up execbuf when many vma's may be marked
as capture, but definitely removes an allocation from a signaling path.
We are not allowed to allocate memory in eb_move_to_gpu, but we can't
enforce it ye
gen6_ppgtt_unpin_all is unused, kill it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 ---
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_pp
Remove some parts of the i915_vma api, ensure obj->vma always exists,
and finally force the object lock to be taken when calling i915_vma_unbind
is called.
With this, locking is a lot cleaner, and we no longer need all the if
(!obj->vma) checks.
We kill off the locking around i915_vma->set/get pa
On Mon, 30 Aug 2021, Jani Nikula wrote:
> The VESA Organization Vendor-Specific Data Block, defined in VESA
> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
> stream count and segment pixel overlap.
>
> DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
> describi
DisplayID v2.0 changes the data block identifiers and product types (now
called primary use cases).
Signed-off-by: Jani Nikula
---
include/drm/drm_displayid.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayi
Now that we have MSO pixel overlap in display info, use it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index
MSO will require segment pixel overlap information from the
EDID. Postpone MSO init until after we've read and cached the EDID.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/dis
The VESA Organization Vendor-Specific Data Block, defined in VESA
DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
stream count and segment pixel overlap.
DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
describing how DisplayID sections may be embedded in EDID ex
Make the values easier to read. Also add DisplayID Structure version and
revision information (this is different from the spec version).
Signed-off-by: Jani Nikula
---
include/drm/drm_displayid.h | 57 +++--
1 file changed, 29 insertions(+), 28 deletions(-)
diff
We need the DisplayID VESA vendor block data for properly configuring
eDP MSO (Multi-SST Operation) pixel overlap.
I haven't actually tested this on a panel that requires the overlap, but
this is all pretty straightforward to prepare for that use case.
BR,
Jani.
Jani Nikula (5):
drm/displayid:
On Fri, 27 Aug 2021, Jani Nikula wrote:
> From: Animesh Manna
>
> UHBR modes has higher link rate and added new values for programming
> mpll of SNPS phy. No change in sequence, only the pll parameters
> are different for UHBR modes.
>
> Signed-off-by: Animesh Manna
> Signed-off-by: Jani Nikula
On Fri, 27 Aug 2021, Ville Syrjälä wrote:
> On Thu, Aug 26, 2021 at 05:18:30PM +0300, Jani Nikula wrote:
>> Apparently the last reader of i915->active_pipes was removed with commit
>> ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder"), and
>> now it's only ever written to. Remove it
== Series Details ==
Series: drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource
URL : https://patchwork.freedesktop.org/series/94154/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10534_full -> Patchwork_20915_full
On Mon, Aug 30, 2021 at 09:48:35AM +0200, Thomas Hellström wrote:
> The code was making a copy of a struct ttm_resource. However,
> recently the struct ttm_resources were allowed to be subclassed and
> also were allowed to be malloced, hence the driver could end up assuming
> the copy we handed it
On Thu, Aug 26, 2021 at 09:16:25AM -0700, Rob Clark wrote:
> On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
> >
> > There's only one exclusive slot, and we must not break the ordering.
> >
> > Adding a new exclusive fence drops all previous fences from the
> > dma_resv. To avoid violating the
On Thu, Aug 05, 2021 at 12:46:57PM +0200, Daniel Vetter wrote:
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-arm-...@vger.kernel
On Mon, 30 Aug 2021 at 17:48, Thomas Hellström
wrote:
>
> The code was making a copy of a struct ttm_resource. However,
> recently the struct ttm_resources were allowed to be subclassed and
> also were allowed to be malloced, hence the driver could end up assuming
> the copy we handed it was subcl
1 - 100 of 106 matches
Mail list logo
