On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
>
> On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> > On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > > Hi,
> > > Re-sending this patch-set following the release of our user-space TPC
> > > compiler and runtim
Am 14.09.21 um 22:03 schrieb Linus Torvalds:
On Tue, Sep 14, 2021 at 12:48 PM Alex Deucher wrote:
On Tue, Sep 7, 2021 at 6:25 AM Christian König wrote:
Reviewed-by: Christian König
Is one of you going to push this to drm-misc?
I was assuming it was there already.
I guess I'll just app
Am 14.09.21 um 19:31 schrieb Matthew Auld:
On Tue, 14 Sept 2021 at 10:03, Christian König wrote:
Am 14.09.21 um 10:50 schrieb Matthew Auld:
Add new flag to indicate special shmem based tt, which can directly
handle swapping itself, and should be visible to some shrinker.
As part of this we sh
On 14/09/2021 19:04, Matthew Brost wrote:
On Tue, Sep 14, 2021 at 09:34:08AM +0100, Tvrtko Ursulin wrote:
8<
Today we have:
for_each intel_engines: // intel_engines is a flat list of all engines
intel_engine_setup()
You propose to change it to:
for_each engine_class:
for 0.
On Tue, 14 Sep 2021, Vasily Khoruzhick wrote:
> On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula
> wrote:
>>
>> On Tue, 14 Sep 2021, Lyude Paul wrote:
>> > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
>> >> On Mon, 13 Sep 2021, Vasily Khoruzhick wrote:
>> >> > Panel in my Dell XPS 7590, th
On 09/14, Iago Toral Quiroga wrote:
> The hardware sets the TMUWCF bit back to 0 when the TMU write
> combiner flush completes so we should be checking for that instead
> of the L2TFLS bit.
>
> Fixes spurious Vulkan CTS failures in:
> dEQP-VK.binding_model.descriptorset_random.*
Hi Iago,
makes se
Hello,
My static analysis tool reports a possible ABBA deadlock in the amdgpu
driver in Linux 5.10:
amdgpu_debugfs_process_reg_op()
mutex_lock(&adev->grbm_idx_mutex); --> Line 250 (Lock A)
mutex_lock(&adev->pm.mutex); --> Line 259 (Lock B)
amdgpu_set_power_dpm_force_performance_level()
On Wed, 2021-09-15 at 09:57 +0100, Melissa Wen wrote:
> On 09/14, Iago Toral Quiroga wrote:
> > The hardware sets the TMUWCF bit back to 0 when the TMU write
> > combiner flush completes so we should be checking for that instead
> > of the L2TFLS bit.
> >
> > Fixes spurious Vulkan CTS failures in:
The hardware sets the TMUWCF bit back to 0 when the TMU write
combiner flush completes so we should be checking for that instead
of the L2TFLS bit.
v2 (Melissa Wen):
- Add Signed-off-by and Fixes tags.
- Change the error message for the timeout to be more clear.
Fixes spurious Vulkan CTS fail
Am 14.09.21 um 15:50 schrieb Daniel Vetter:
On Thu, Sep 09, 2021 at 09:10:39AM +0200, Christian König wrote:
Am 08.09.21 um 20:27 schrieb Daniel Vetter:
On Tue, Sep 07, 2021 at 11:28:23AM +0200, Christian König wrote:
Am 07.09.21 um 11:05 schrieb Daniel Vetter:
On Tue, Sep 07, 2021 at 08:22:2
On Sat, 11 Sep 2021, Imran Khan wrote:
> To print stack entries into a buffer, users of stackdepot,
> first get a list of stack entries using stack_depot_fetch
> and then print this list into a buffer using stack_trace_snprint.
> Provide a helper in stackdepot for this purpose.
> Also change above
On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote:
> I don't love it, a new C file and an out-of-line call to then call back
> to a static inline that for most configuration will return false ... but
> whatever :)
Yeah, hch thinks it'll cause a big mess otherwise:
https://lore.kern
Am 14.09.21 um 15:07 schrieb Tvrtko Ursulin:
On 14/09/2021 12:25, Christian König wrote:
Am 14.09.21 um 12:53 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
[SNIP]
+ if (fence) {
+ fence = dma_fence_get_rcu(fence);
+ } else if (all_fences && curso
Fixes the following splat:
i915: Running i915_gem_mman_live_selftests/igt_mmap
[ cut here ]
WARNING: CPU: 3 PID: 5654 at include/linux/mmap_lock.h:164 find_vma+0x4e/0xb0
Modules linked in: i915(+) vgem fuse snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic led
Am 14.09.21 um 14:47 schrieb Tvrtko Ursulin:
On 14/09/2021 13:32, Christian König wrote:
Am 14.09.21 um 14:27 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
This is maybe even a fix since the RCU usage here looks incorrect.
What you think is incorrect? Pointless extra
From: Colin Ian King
Don't populate the read-only array states on the stack but instead it
static. Also makes the object code smaller.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
From: Colin Ian King
Don't populate the read-only array encoded_lanes on the stack but instead it
static. Also makes the object code smaller by 97 bytes:
Before:
textdatabss dechex filename
388998064 0 46963 b773 ./drivers/gpu/drm/radeon/r600_dpm.o
After:
te
From: Tvrtko Ursulin
It is not very useful to have code which tries to report a rapidly
transient state which will not report anything majority of the time,
especially since it is currently only used from
/i915_gem_framebuffers.
Signed-off-by: Tvrtko Ursulin
Acked-by: Christian König
Cc: Danie
Yes, I think so as well. Andrey can you push this?
Christian.
Am 15.09.21 um 00:59 schrieb Grodzovsky, Andrey:
AFAIK this one is independent.
Christian, can you confirm ?
Andrey
*From:* amd-gfx on behalf of
Alex Deuche
On Tue, 14 Sep 2021 22:05:36 +0200, Paul Kocialkowski wrote:
> The Xylon LogiCVC is a display controller implemented as programmable
> logic in Xilinx FPGAs.
>
> Signed-off-by: Paul Kocialkowski
> Acked-by: Rob Herring
> ---
> .../display/xylon,logicvc-display.yaml| 302
On Fri, 10 Sep 2021, Randy Dunlap wrote:
> Hi,
>
> I would like to use QHD resolution (2560x1440) with my shiny new
> computer and display. That resolution works if I boot Windows 10
> (cough).
>
> What do I need to do to use that resolution in Linux?
>
> I first tried openSUSE 15.3 (kernel 5.3.18
On Wed, 15 Sept 2021 at 12:00, Maarten Lankhorst
wrote:
>
> Fixes the following splat:
>
> i915: Running i915_gem_mman_live_selftests/igt_mmap
> [ cut here ]
> WARNING: CPU: 3 PID: 5654 at include/linux/mmap_lock.h:164 find_vma+0x4e/0xb0
> Modules linked in: i915(+) vgem fu
On Wed, 2021-08-18 at 18:56 +0100, Melissa Wen wrote:
> Add support to attach generic extensions on job submission.
> This patch is a second prep work to enable multiple syncobjs on job
> submission. With this work, when the job submission interface needs
> to be extended to accomodate a new featur
Op 15-09-2021 om 15:19 schreef Matthew Auld:
> On Wed, 15 Sept 2021 at 12:00, Maarten Lankhorst
> wrote:
>> Fixes the following splat:
>>
>> i915: Running i915_gem_mman_live_selftests/igt_mmap
>> [ cut here ]
>> WARNING: CPU: 3 PID: 5654 at include/linux/mmap_lock.h:164 fin
On Fri, 10 Sep 2021, Daniele Ceraolo Spurio
wrote:
> Ahead of the PXP implementation, define the relevant define flag and
> kconfig option.
>
> v2: flip kconfig default to N. Some machines have IFWIs that do not
> support PXP, so we need it to be an opt-in until we add support to query
> the caps
While investigating a lockup at startup on Powerbook 3400C, it was
identified that the fbdev driver generates alignment exception at
startup:
--- interrupt: 600 at memset+0x60/0xc0
NIP: c0021414 LR: c03fc49c CTR: 7fff
REGS: ca021c10 TRAP: 0600 Tainted: GW
On Fri, 10 Sep 2021, Daniele Ceraolo Spurio
wrote:
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> new file mode 100644
> index ..e87550fb9821
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -0,0 +1,35 @@
> +/* SPDX-Lic
On Fri, 30 Jul 2021 16:41:29 -0400
Harry Wentland wrote:
> Use the new DRM RFC doc section to capture the RFC previously only
> described in the cover letter at
> https://patchwork.freedesktop.org/series/89506/
>
> v3:
> * Add sections on single-plane and multi-plane HDR
> * Describe approach
From: Ville Syrjälä
Fix the bad copy-pasta in the scaling_mode docs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e0a30e0ee86a..3b
Reviewed-by: Simon Ser
On Mon, 16 Aug 2021 15:37:23 +0200
sebast...@sebastianwick.net wrote:
> On 2021-08-16 14:40, Harry Wentland wrote:
> > On 2021-08-16 7:10 a.m., Brian Starkey wrote:
> >> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
> >>> Hello Brian,
> >>> (+Uma in cc)
> >>>
> >>> Thanks
https://bugzilla.kernel.org/show_bug.cgi?id=214413
Bug ID: 214413
Summary: Kernel oops on boot for amdgpu (in
si_dpm_set_power_state)
Product: Drivers
Version: 2.5
Kernel Version: 5.14.4
Hardware: All
OS
On 9/14/2021 12:13 PM, Rodrigo Vivi wrote:
On Fri, Sep 10, 2021 at 08:36:22AM -0700, Daniele Ceraolo Spurio wrote:
From: "Huang, Sean Z"
During the power event S3+ sleep/resume, hardware will lose all the
encryption keys for every hardware session, even though the
session state might still
On Wed, Sep 15, 2021 at 7:36 AM Colin King wrote:
>
> From: Colin Ian King
>
> Don't populate the read-only array encoded_lanes on the stack but instead it
> static. Also makes the object code smaller by 97 bytes:
>
> Before:
>textdatabss dechex filename
> 388998064
On Tue, Sep 07, 2021 at 07:44:44PM +0200, Thierry Reding wrote:
> On Tue, Sep 07, 2021 at 10:33:24AM -0500, Rob Herring wrote:
> > On Fri, Sep 3, 2021 at 10:36 AM Thierry Reding
> > wrote:
> > >
> > > On Fri, Sep 03, 2021 at 09:36:33AM -0500, Rob Herring wrote:
> > > > On Fri, Sep 3, 2021 at 8:52
On Wed, Sep 15, 2021 at 08:11:54AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 9/14/2021 12:13 PM, Rodrigo Vivi wrote:
> > On Fri, Sep 10, 2021 at 08:36:22AM -0700, Daniele Ceraolo Spurio wrote:
> > > From: "Huang, Sean Z"
> > >
> > > During the power event S3+ sleep/resume, hardware will los
On Wed, Sep 15, 2021 at 04:29:50PM +0300, Jani Nikula wrote:
> On Fri, 10 Sep 2021, Daniele Ceraolo Spurio
> wrote:
> > Ahead of the PXP implementation, define the relevant define flag and
> > kconfig option.
> >
> > v2: flip kconfig default to N. Some machines have IFWIs that do not
> > support
On 09/15, Iago Toral wrote:
> On Wed, 2021-08-18 at 18:56 +0100, Melissa Wen wrote:
> > Add support to attach generic extensions on job submission.
> > This patch is a second prep work to enable multiple syncobjs on job
> > submission. With this work, when the job submission interface needs
> > to
On Wed, 2021-09-15 at 17:28 +0100, Melissa Wen wrote:
> On 09/15, Iago Toral wrote:
> > On Wed, 2021-08-18 at 18:56 +0100, Melissa Wen wrote:
(...)
> > >
> > > /**
> > > @@ -248,6 +266,15 @@ struct drm_v3d_submit_tfu {
> > > __u32 in_sync;
> > > /* Sync object to signal when the TFU job is do
Hi Jason, Greg, Daniel, DRM folks,
In DRM-debug currently, drm_debug_enabled() is called a lot to decide
whether or not to write debug messages. Each test is cheap, but costs
continue with uptime. DYNAMIC_DEBUG "dyndbg", when built with
JUMP_LABEL, replaces each of those tests with a patchable N
dd-exec-queries accepts a separate module arg (so it can support
$module.dyndbg cmdline arg), add it to the vpr-info for more context.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
i
add "bootparam" to format. no functional changes.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index dfe1e6a857bc..da91ff507117 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_de
change current v*pr_info() calls to fit this new scheme:
-1 module add/remove, callsite counts - a few v2s here now
-2 command ingest, splitting
-3 command parsing - many v1s here now
-4 per-site changes - was v2
2 is new, to isolate a problem where a stress-test script (which feeds
large multi-c
On qemu --smp 3 runs, remove-module can get called 3 times.
Instead, print once at end, if entry was found and removed.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index eac6c6
`echo $cmd > control` can be finicky with respect to quoting (mostly
wrt * expansion), so lets not complicate things by adding our own in
debug messages. Quote as <%s> instead of '%s' or \"%s\"
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 16
1 file changed, 8 insertions
This example uses dyndbg as a core/kernel param; it is a (fake) module
param. Using it as given gets an "Unknown command line parameters:"
warning. Fix the broken example.
Signed-off-by: Jim Cromie
---
Documentation/admin-guide/dynamic-debug-howto.rst | 6 ++
1 file changed, 2 insertions(+
when `echo $cmd > control` contains multiple queries, extra query
separators (;\n) can parse as empty statements. This is normal, and
pr-info on empty command is just noise. Also change varname.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 13 +++--
1 file changed, 7 insertions(
DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, var, bitmap_desc, @bit_descs)
allows users to create a drm.debug style (bitmap) sysfs interface,
mapping each bit to a pr_debug "category".
Unlike drm, dyndbg has no coding of "category", but it can select a
set of pr_debugs with a substr match on their form
Taking embedded spaces out of existing prefixes makes them better
class-prefixes; simplifying the extra quoting needed otherwise:
$> echo format "^gvt: core:" +p >control
Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched for.
no code changes, good for rc
Signed-off-by: Jim Cromie
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index b439ae1921b8..ebb22166ace1 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -5
The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM. Following the interface model of
drm.debug, add a parameter to map bits to these categorizations.
DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"dyndbg bitmap desc",
_DD_c
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these already use DRM debug API, so are controllable using
drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13
different class-prefixes matching ~/^\[[_A-Z]+\]:/
Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to cre
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names). There are thousands of these callsites, each
categorized in this systematized way.
These callsites can be enabled at runtime by their cate
Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg"
branch.
Then convert the "dyndbg" branch's code to a macro, so that the
pr_debug() get its callsite info from the invoking function, instead
of from drm_debug_enabl
There are blocks of DRM_DEBUG calls, consolidate their args into
single calls. With dynamic-debug in use, each callsite consumes 56
bytes of callsite data, and this patch removes about 65 calls, so
it saves ~3.5kb.
no functional changes.
RFC: this creates multi-line log messages, does that break
With DRM_USE_DYNAMIC_DEBUG, each callsite record requires 56 bytes.
We can combine 12 into one here and save ~620 bytes.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +--
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/g
Hi,
On Tue, Sep 14, 2021 at 7:50 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2021-09-14 19:17:03)
> > Hi,
> >
> > On Tue, Sep 14, 2021 at 5:29 PM Stephen Boyd wrote:
> > >
> > > Quoting Philip Chen (2021-09-14 16:28:44)
> > > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > > > b
On Wed, Sep 08, 2021 at 05:58:31PM -0500, Tom Lendacky wrote:
> This patch series provides a generic helper function, cc_platform_has(),
> to replace the sme_active(), sev_active(), sev_es_active() and
> mem_encrypt_active() functions.
>
> It is expected that as new confidential computing technolo
On Wed, Sep 15, 2021 at 09:24:15AM +0100, Tvrtko Ursulin wrote:
>
> On 14/09/2021 19:04, Matthew Brost wrote:
> > On Tue, Sep 14, 2021 at 09:34:08AM +0100, Tvrtko Ursulin wrote:
> > >
>
> 8<
>
> > > Today we have:
> > >
> > > for_each intel_engines: // intel_engines is a flat list of all engin
Le 15/09/2021 à 12:08, Borislav Petkov a écrit :
On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote:
I don't love it, a new C file and an out-of-line call to then call back
to a static inline that for most configuration will return false ... but
whatever :)
Yeah, hch thinks it
On 9/15/21 9:46 AM, Borislav Petkov wrote:
Sathya,
if you want to prepare the Intel variant intel_cc_platform_has() ontop
of those and send it to me, that would be good because then I can
integrate it all in one branch which can be used to base future work
ontop.
I have a Intel variant patc
Changes in v2:
- Fixed compilation error [1] due to typo in patch-3 (stack_depot_print
used in place of stack_depot_snprint)
This compilation error appears with CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y
and this was missed by my test config (x86_64_defconfig)
[1] https://patchwork.freedesktop.o
stack_depot_save allocates slabs that will be used for storing
objects in future.If this slab allocation fails we may get to
a situation where space allocation for a new stack_record fails,
causing stack_depot_save to return 0 as handle.
If user of this handle ends up invoking stack_depot_fetch wit
To print a stack entries, users of stackdepot, first
use stack_depot_fetch to get a list of stack entries
and then use stack_trace_print to print this list.
Provide a helper in stackdepot to print stack entries
based on stackdepot handle.
Also change above mentioned users to use this helper.
Signe
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
Signed-off-b
On 09/15, Iago Toral Quiroga wrote:
> The hardware sets the TMUWCF bit back to 0 when the TMU write
> combiner flush completes so we should be checking for that instead
> of the L2TFLS bit.
>
> v2 (Melissa Wen):
> - Add Signed-off-by and Fixes tags.
> - Change the error message for the timeout
Recent rework, which made HDMI PHY driver a platform device, inadvertely
reversed clock setup order. HW is very touchy about it. Proper way is to
handle controllers resets and clocks first and HDMI PHYs second.
Currently, without this fix, first mode set completely fails (nothing on
HDMI monitor)
Pushed
Andrey
On 2021-09-15 7:45 a.m., Christian König wrote:
Yes, I think so as well. Andrey can you push this?
Christian.
Am 15.09.21 um 00:59 schrieb Grodzovsky, Andrey:
AFAIK this one is independent.
Christian, can you confirm ?
Andrey
--
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?
Tom already told you to look at the previous threads. Let's read them
together. This one, for example:
htt
In commit:
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page mapping and -index members
we started setting the page->mapping and page->index to point to the
virtual address space, if the pages were faul
Now that setting page->index shouldn't be needed anymore, we are just
left with setting page->mapping, and here it looks like amdgpu is the
only user, where pointing the page->mapping at the dev_mapping is used
to verify that the pages do indeed belong to the device, if userspace
later tries to tou
No longer used it seems.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
include/drm/ttm/ttm_tt.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 89b15d673b22..842ce756213c 100644
--- a/include/drm/ttm/ttm_tt
Move it to inline kernel-doc, otherwise we can't add empty lines it
seems. Also drop the kernel-doc for pages_list, which doesn't seem to
exist, and get rid of all the strange holes.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
include/drm/ttm/ttm_tt.h | 57
It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.
Suggested-by: Christian König
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 -
In commit:
commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom
Date: Fri Jan 3 11:17:18 2014 +0100
drm/ttm: Refuse to fault (prime-) imported pages
we introduced the restriction that imported pages should not be directly
mappable through TTM(this also extends to userp
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
update the shrinker visible lists immediately. This at least simplifies
the next patch, and does make the behaviour more obvious. The potential
downside is that make_unshrinkable now grabs a global lock even when the
object itself
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/d
We currently just evict lmem objects to system memory when under memory
pressure. For this case we lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets migrated
Enable shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e758de336b96..
On 8/20/2021 15:44, 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.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/g
On 9/14/2021 12:51 PM, Lucas De Marchi wrote:
The clflush calls here aren't doing anything since we are not writting
something and flushing the cache lines to be visible to GuC. Here the
intention seems to be to make sure whatever GuC has written is visible
to the CPU before we read them. Howe
On 8/20/2021 15:44, Matthew Brost wrote:
In GuC parent-child contexts the parent context controls the scheduling,
ensure only the parent does the scheduling operations.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 24 ++-
1 file changed, 18
On 9/15/2021 12:24, Belgaumkar, Vinay wrote:
On 9/14/2021 12:51 PM, Lucas De Marchi wrote:
The clflush calls here aren't doing anything since we are not writting
something and flushing the cache lines to be visible to GuC. Here the
intention seems to be to make sure whatever GuC has written is v
In capture_vma() Coverity complains of a possible buffer overrun. Even
though this is a static function where all call sites can be checked,
limiting the copy length could save some future grief.
CID 93300 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
4. fixed_size_dest: You might overr
On Wed, Sep 15, 2021 at 12:21:35PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, 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-
On Wed, Sep 15, 2021 at 12:24:41PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > In GuC parent-child contexts the parent context controls the scheduling,
> > ensure only the parent does the scheduling operations.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > .../
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> From: Rajat Jain
>
> Add support for generic electronic privacy screen properties, that
> can be added by systems that have an integrated EPS.
>
> Changes in v2 (Hans de Goede)
> - Create 2 properties, "privacy-screen sw-state" and
> "p
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> On some new laptops the LCD panel has a builtin electronic privacy-screen.
> We want to export this functionality as a property on the drm connector
> object. But often this functionality is not exposed on the GPU but on some
> other (ACPI)
On 8/20/2021 15:44, Matthew Brost wrote:
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
On 9/15/2021 12:31, Matthew Brost wrote:
On Wed, Sep 15, 2021 at 12:21:35PM -0700, John Harrison wrote:
On 8/20/2021 15:44, 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 s
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> Add support for privacy-screen consumers to register a notifier to
> be notified of external (e.g. done by the hw itself on a hotkey press)
> state changes.
>
> Reviewed-by: Emil Velikov
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu
From: Sean Paul
Hello again,
This is the second version of the HDCP helper patchset. See version 1
here: https://patchwork.freedesktop.org/series/94623/
In this second version, I've fixed up the oopsies exposed by 0-day and
yamllint and incorporated early review feedback from the dt/dts reviews.
On Wed, Sep 15, 2021 at 01:23:19PM -0700, John Harrison wrote:
> On 9/15/2021 12:31, Matthew Brost wrote:
> > On Wed, Sep 15, 2021 at 12:21:35PM -0700, John Harrison wrote:
> > > On 8/20/2021 15:44, Matthew Brost wrote:
> > > > Add multi-lrc context registration H2G. In addition a workqueue and
> >
From: Sean Paul
This patch moves the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-2-s...@poorly
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, simply return
true if the content protection value is changing and let the driver
decide whether a modeset is required or not.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.4745
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to
From: Sean Paul
This patch expands upon the HDCP helper library to manage HDCP
enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could m
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-6-s...@poorly.run
#v1
Changes in v2:
-No
1 - 100 of 148 matches
Mail list logo
