as-Hellstr-m/locking-ww_mutex-Adjust-to-lockdep-nest_lock-requirements/20230911-170838
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/all/20230911090729.5287-1-thomas.hellst...@linux.intel.com/
patch subject: [RFC PATCH] locking/ww_mutex: Adjust
Arnd Bergmann writes:
Hello Arnd,
> From: Arnd Bergmann
>
> As a result of the recent Kconfig reworks, the default settings for the
> framebuffer interfaces changed in unexpected ways:
>
> Configurations that leave CONFIG_FB disabled but use DRM now get
> DRM_FBDEV_EMULATION by default. This
On September 11, 2023 6:55:32 PM PDT, Dave Airlie wrote:
>On Tue, 12 Sept 2023 at 11:27, Kees Cook wrote:
>>
>> On September 8, 2023 12:59:39 PM PDT, Philipp Stanner
>> wrote:
>> >Hi!
>> >
>> >David Airlie suggested that we could implement new wrappers around
>> >(v)memdup_user() for
Add Matthew Brost to maintainers of GPU scheduler
Signed-off-by: Matthew Brost
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1035fdcaa97..38d96077b35d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7131,6 +7131,7 @@ F:
Wait for pending jobs to be complete before signaling queued jobs. This
ensures dma-fence signaling order correct and also ensures the entity is
not running on the hardware after drm_sched_entity_flush or
drm_sched_entity_fini returns.
Signed-off-by: Matthew Brost
---
Also add a lockdep assert to drm_sched_start_timeout.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
Add generic schedule message interface which sends messages to backend
from the drm_gpu_scheduler main submission thread. The idea is some of
these messages modify some state in drm_sched_entity which is also
modified during submission. By scheduling these messages and submission
in the same
Provide documentation to guide in ways to teardown an entity.
Signed-off-by: Matthew Brost
---
Documentation/gpu/drm-mm.rst | 6 ++
drivers/gpu/drm/scheduler/sched_entity.c | 19 +++
2 files changed, 25 insertions(+)
diff --git a/Documentation/gpu/drm-mm.rst
Add helper to set TDR timeout and restart the TDR with new timeout
value. This will be used in XE, new Intel GPU driver, to trigger the TDR
to cleanup drm_sched_entity that encounter errors.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c | 18 ++
If the TDR is set to a value, it can fire before a job is submitted in
drm_sched_main. The job should be always be submitted before the TDR
fires, fix this ordering.
v2:
- Add to pending list before run_job, start TDR after (Luben, Boris)
Signed-off-by: Matthew Brost
---
DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
scheduler and entity. No priorities or run queue used in this mode.
Intended for devices with firmware schedulers.
v2:
- Drop sched / rq union (Luben)
v3:
- Don't pick entity if stopped in drm_sched_select_entity (Danilo)
If the TDR is set to a very small value it can fire before the run wq is
started in the function drm_sched_start. The run wq is expected to
running when the TDR fires, fix this ordering so this expectation is
always met.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c |
Rather than call free_job and run_job in same work item have a dedicated
work item for each. This aligns with the design and intended use of work
queues.
v2:
- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
timestamp in free_job() work item (Danilo)
Signed-off-by: Matthew Brost
Rather than a global modparam for scheduling policy, move the scheduling
policy to scheduler / entity so user can control each scheduler / entity
policy.
v2:
- s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
- Only include policy in scheduler (Luben)
Signed-off-by: Matthew Brost
---
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first.
This a continuation of a RFC [3] with all comments addressed, ready for
a full review, and hopefully in state which can merged in the near
future. More details of
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.
1. In XE the submission order from multiple drm_sched_entity is not
guaranteed to be the same
Add scheduler submit ready, stop, and start helpers to hide the
implementation details of the scheduler from the drivers.
Signed-off-by: Matthew Brost
---
.../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 15 +++
On Tue, 12 Sept 2023 at 11:27, Kees Cook wrote:
>
> On September 8, 2023 12:59:39 PM PDT, Philipp Stanner
> wrote:
> >Hi!
> >
> >David Airlie suggested that we could implement new wrappers around
> >(v)memdup_user() for duplicating user arrays.
> >
> >This small patch series first implements
On Fri, 2023-09-08 at 21:59 +0200, Philipp Stanner wrote:
> Hi!
>
> David Airlie suggested that we could implement new wrappers around
> (v)memdup_user() for duplicating user arrays.
>
> This small patch series first implements the two new wrapper functions
> memdup_array_user() and
On September 8, 2023 12:59:39 PM PDT, Philipp Stanner
wrote:
>Hi!
>
>David Airlie suggested that we could implement new wrappers around
>(v)memdup_user() for duplicating user arrays.
>
>This small patch series first implements the two new wrapper functions
>memdup_array_user() and
On Mon, Sep 11, 2023 at 2:36 AM Christian König
wrote:
>
> m 11.09.23 um 04:30 schrieb Yong Wu:
> > From: "T.J. Mercier"
> >
> > The docs for dma_heap_get_name were incorrect, and since they were
> > duplicated in the implementation file they were wrong there too.
> >
> > The docs formatting was
On 9/7/23 13:03, Dan Carpenter wrote:
> 2c607edf57db6a Dmitry Osipenko 2023-09-03 @724if (page_offset >=
> num_pages || (!shmem->pages && !shmem->evicted)) {
>
> ^^^
>
On 9/5/23 10:40, Boris Brezillon wrote:
> On Sun, 3 Sep 2023 20:07:18 +0300
> Dmitry Osipenko wrote:
>
>> Use separate flag for tracking page count bumped by shmem->sgt to avoid
>> imbalanced page counter during of drm_gem_shmem_free() time. It's fragile
>> to assume that populated shmem->pages
On 9/5/23 10:20, Boris Brezillon wrote:
> On Sun, 3 Sep 2023 20:07:22 +0300
> Dmitry Osipenko wrote:
>
>> Prepare virtio_gpu_object_create() to addition of memory shrinker support
>> by replacing open-coded drm_gem_shmem_free() with drm_gem_object_put() that
>> decrements GEM refcount to 0,
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
In preparation to deduplicating SSPP subblocks, drop the (unused)
`smart_dma_priority' field from struct dpu_sspp_sub_blks. If it is
needed later (e.g. for SmartDMA v1), it should be added to the SSPP
declarations themselves.
Signed-off-by:
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
The field `id' is not used for subblocks. The handling code usually
knows, which sub-block it is now looking at. Drop the field completely.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 76
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files. For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.
Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in
dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive.
When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY
prefix decorations are sprintf'd into stack-mem for every call.
This string (or part of it) could be cached once its 1st generated,
and retreived
Reserve bit 7 to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with one+ of module:function:sourcfile
- was previously called
- was thus saved in the cache. NOT YET.
Its unclear whether any cache fetch would be faster than 2-3 field
fetches, but theres
Lots of burn-in testing needed before signing, upstreaming.
NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
move macro from test-dynamic-debug.c into header, and refine it.
Distinguish the 2 use cases of DYNDBG_CLASSMAP_PARAM*
1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before
2.DYNDBG_CLASSMAP_PARAM
new
Add some basic info on classmap usage and api
Signed-off-by: Jim Cromie
---
v5- adjustments per Randy Dunlap, me
---
.../admin-guide/dynamic-debug-howto.rst | 60 ++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git
Make the test-module buildable with just CONFIG_DYNAMIC_DEBUG_CORE;
add CFLAGS_$ofile defns to supply -DDYNAMIC_DEBUG_MODULE to cc.
Change the Kconfig entry to allow building with just _CORE, and fix
the help text.
Signed-off-by: Jim Cromie
---
lib/Kconfig.debug | 10 +-
lib/Makefile
DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K
rule: "define once, refer many times".
When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together when
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former. It takes kernel-param arg, so it can complain
about "foo: bad input".
Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c
Add a for_each iterator to walk a counted vector member in a struct
(ie the box), and use it to replace 8 open-coded loops.
Signed-off-by: Jim Cromie
---
v5- parens-on-box-force-precedence
---
lib/dynamic_debug.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff
check for actual changes before announcing them, declutter logs.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index f64d55d191ad..05c777dedf27 100644
---
currently, for verbose=3, these are logged (blank lines for clarity):
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module=""
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn. Disallow this.
And constify new_bits while here.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 insertions(+), 10
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:
echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names
The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 2 +-
lib/dynamic_debug.c | 2 +-
2 files changed, 2
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new. New arg allows caller to specify that only one module
is affected by a prdbgs update.
Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
This series fixes the regression in DRM_USE_DYNAMIC_DEBUG=y
blame analysis: (all mine)
1. my early test scripts did a lot of 'modprobe $m $*',
with dyndbg=.. and debug=.. args
this obscured the lack of drm.debug -> drivers propagation
2. I broke K rule: "define once, refer many times".
This series fixes the regression in DRM_USE_DYNAMIC_DEBUG=y
blame analysis: (all mine)
1. my early test scripts did a lot of 'modprobe $m $*',
with dyndbg=.. and debug=.. args
this obscured the lack of drm.debug -> drivers propagation
2. I broke K rule: "define once, refer many times".
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
From: Marijn Suijten
The SSPP scaler subblk is responsible for reporting its version (via the
.id field, feature bits on the parent SSPP block, and since recently
also from reading a register to supersede a read-but-unset version field
in the
On 9/11/2023 2:45 PM, Dmitry Baryshkov wrote:
From: Marijn Suijten
This pointer callback is never used and should be removed.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
[DB: dropped the helpers completely, which are unused now]
Signed-off-by: Dmitry Baryshkov
---
Currently, dpu_plane_atomic_check() does not check whether the
plane can process the image without exceeding the per chipset
limits for MDP clock. This leads to underflow issues because the
SSPP is not able to complete the processing for the data rate of
the display.
Fail the
It's certainly possible that for large resolutions a single DPU SSPP
cannot process the image without exceeding the MDP clock limits but
it can still process it in multirect mode because the source rectangles
will get divided and can fall within the MDP clock limits.
If the SSPP cannot process
As we have dropped the variadic parts of SSPP sub-blocks declarations,
deduplicate them now, reducing memory cruft.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 16 +--
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 16 +--
In preparation to deduplicating SSPP subblocks, drop the (unused)
`smart_dma_priority' field from struct dpu_sspp_sub_blks. If it is
needed later (e.g. for SmartDMA v1), it should be added to the SSPP
declarations themselves.
Signed-off-by: Dmitry Baryshkov
---
Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
are all related to different versions of the same HW scaling block.
Corresponding driver parts use scaler_blk.version to identify the
correct way to program the hardware. In order to simplify the driver
codepath, merge these
As the subblock info is now mostly gone, inline and drop the macro
DPU_HW_SUBBLK_INFO.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 40 ++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git
After folding QSEED3LITE and QSEED4 feature bits into QSEED3 several
VIG feature masks became equal. Drop these duplicates.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h| 2 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 8
From: Marijn Suijten
The SSPP scaler subblk is responsible for reporting its version (via the
.id field, feature bits on the parent SSPP block, and since recently
also from reading a register to supersede a read-but-unset version field
in the catalog), leaving this global qseed_type field
From: Marijn Suijten
This pointer callback is never used and should be removed.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
[DB: dropped the helpers completely, which are unused now]
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 13
The function _dpu_hw_sspp_setup_scaler3() passes and
dpu_hw_setup_scaler3() uses scaler_blk.version to determine in which way
the scaler (QSEED3) block should be programmed. However up to now we
were not setting this field. Set it now, splitting the vig_sblk data
which has different version
The field `id' is not used for subblocks. The handling code usually
knows, which sub-block it is now looking at. Drop the field completely.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 76 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|
The handling code also usually knows, which sub-block it is now looking
at. Drop unused 'id' field and arguments and merge some of sub-block
declarations.
While we are at it, also fix all VIG subblocks to contain correct scaler
block version and drop the becoming unused QSEED-related feature
On 06/09/2023 16:38, Heikki Krogerus wrote:
On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus
wrote:
On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry Baryshkov wrote:
Hi Heikki,
On Tue, 5 Sept 2023 at 11:50, Heikki Krogerus
From: Arnd Bergmann
As a result of the recent Kconfig reworks, the default settings for the
framebuffer interfaces changed in unexpected ways:
Configurations that leave CONFIG_FB disabled but use DRM now get
DRM_FBDEV_EMULATION by default. This also turns on the deprecated /dev/fb
device nodes
On Tue, Sep 05, 2023 at 01:10:38PM +0200, Danilo Krummrich wrote:
> On 8/29/23 19:37, Danilo Krummrich wrote:
> > On 8/11/23 04:31, Matthew Brost wrote:
> > > DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
> > > scheduler and entity. No priorities or run queue used in this
On 9/10/23 19:11, Stephen Rothwell wrote:
> Hi all,
>
> Please do *not* include material destined for v6.7 in your linux-next
> included branches until *after* v6.6-rc1 has been released. Also,
> do *not* rebase your linu-next included branches onto v6.5.
>
> Changes since 20230908:
>
>
Em 11/09/2023 14:21, Hamza Mahfooz escreveu:
On 9/11/23 13:12, André Almeida wrote:
As suggested by Christian at [0], this patchset merges all debug modules
parameters and creates a new one for disabling soft recovery:
Maybe we can overload the amdgpu_gpu_recovery module option with this.
On 9/11/23 19:49, Danilo Krummrich wrote:
Hi Thomas,
On 9/11/23 19:19, Thomas Hellström wrote:
Hi, Danilo
On 9/9/23 17:31, Danilo Krummrich wrote:
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The abstraction
On Mon, Sep 11, 2023 at 3:14 AM Christian König
wrote:
> Am 11.09.23 um 04:30 schrieb Yong Wu:
> > From: John Stultz
> >
> > This allows drivers who don't want to create their own
> > DMA-BUF exporter to be able to allocate DMA-BUFs directly
> > from existing DMA-BUF Heaps.
> >
> > There is some
I didn't spot anything to nag about. Just hope that warning doesn't
become excessively noisy. These two patches are
Reviewed-by: Juha-Pekka Heikkila
On 4.9.2023 7.16, Ville Syrjala wrote:
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning
Hi Thomas,
On 9/11/23 19:19, Thomas Hellström wrote:
Hi, Danilo
On 9/9/23 17:31, Danilo Krummrich wrote:
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The abstraction
represents a combination of a drm_gem_object
On 9/8/2023 4:30 PM, Dmitry Baryshkov wrote:
On Fri, 8 Sept 2023 at 21:55, Abhinav Kumar wrote:
It's certainly possible that for large resolutions a single DPU SSPP
cannot process the image without exceeding the MDP clock limits but
it can still process it in multirect mode because the
On Tue, 08 Aug 2023, Allen Ballway wrote:
> Cybernet T10C cannot be dimmed without the backlight strobing. Create a
> new quirk to lock the minimum brightness to the highest supported value.
> This aligns the device with its behavior on Windows, which will not
> lower the brightness below
On 9/11/23 13:12, André Almeida wrote:
As suggested by Christian at [0], this patchset merges all debug modules
parameters and creates a new one for disabling soft recovery:
Maybe we can overload the amdgpu_gpu_recovery module option with this.
Or even better merge all the developer module
Hi, Danilo
On 9/9/23 17:31, Danilo Krummrich wrote:
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The abstraction
represents a combination of a drm_gem_object and drm_gpuvm. The
drm_gem_object holds a list of
Create a module option to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
Reviewed-by: Christian König
---
Merge all developer debug options available as separated module
parameters in one, making it obvious that are for developers.
Drop the obsolete module options in favor of the new ones.
Signed-off-by: André Almeida
Reviewed-by: Christian König
---
v3:
- move from include/amd_shared.h to
As suggested by Christian at [0], this patchset merges all debug modules
parameters and creates a new one for disabling soft recovery:
> Maybe we can overload the amdgpu_gpu_recovery module option with this.
> Or even better merge all the developer module parameter into a
> amdgpu_debug option.
On 9/8/2023 4:06 PM, Dmitry Baryshkov wrote:
On Fri, 8 Sept 2023 at 21:56, Abhinav Kumar wrote:
Currently, dpu_plane_atomic_check() does not check whether the
plane can process the image without exceeding the per chipset
limits for MDP clock. This leads to underflow issues because the
SSPP
On Mon, Sep 11, 2023 at 04:45:26PM +0200, Boris Brezillon wrote:
> On Sat, 9 Sep 2023 17:31:13 +0200
> Danilo Krummrich wrote:
>
> > @@ -807,6 +1262,14 @@ drm_gpuvm_bo_destroy(struct kref *kref)
> >
> > drm_gem_gpuva_assert_lock_held(vm_bo->obj);
> >
> > + spin_lock(>extobj.lock);
> >
On 9/11/23 09:54, André Almeida wrote:
Christian, Alex, I think this series is ready to be picked as well.
Can you rebase this onto amd-staging-drm-next
(https://gitlab.freedesktop.org/agd5f/linux)? Since it currently doesn't
apply there.
Em 31/08/2023 12:29, André Almeida escreveu:
As
On Mon, Sep 11, 2023 at 12:35:26PM +0200, Boris Brezillon wrote:
> Hello Danilo,
>
> On Sat, 9 Sep 2023 17:31:13 +0200
> Danilo Krummrich wrote:
>
>
> > @@ -632,6 +661,131 @@
> > * }
> > */
> >
> > +/**
> > + * get_next_vm_bo_from_list() - get the next vm_bo element
> > + * @__gpuvm:
On 9/10/23 19:44, Randy Dunlap wrote:
Fix the typo in the kernel-doc for @replay_mode to prevent
kernel-doc warnings:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:623: warning: Incorrect use
of kernel-doc format: * @replay mode: Replay supported
On 9/8/23 03:54, Jiapeng Chong wrote:
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:2476
link_set_dpms_on() warn: if statement not indented.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6502
Signed-off-by:
On Mon, Sep 11, 2023 at 02:00:35PM +0200, Boris Brezillon wrote:
> On Sat, 9 Sep 2023 17:31:11 +0200
> Danilo Krummrich wrote:
>
> > @@ -240,9 +240,22 @@ struct drm_gpuvm {
> > * @ops: _gpuvm_ops providing the split/merge steps to drivers
> > */
> > const struct drm_gpuvm_ops
Hi,
Le lundi 11 septembre 2023 à 10:30 +0800, Yong Wu a écrit :
> From: John Stultz
>
> This allows drivers who don't want to create their own
> DMA-BUF exporter to be able to allocate DMA-BUFs directly
> from existing DMA-BUF Heaps.
>
> There is some concern that the premise of DMA-BUF heaps
Hi,
On Fri, Sep 8, 2023 at 4:51 AM Fei Shao wrote:
>
> Hi,
>
> On Sat, Sep 2, 2023 at 7:42 AM Douglas Anderson wrote:
> ...
> > @@ -952,6 +960,7 @@ static const struct dev_pm_ops mtk_drm_pm_ops = {
> > static struct platform_driver mtk_drm_platform_driver = {
> > .probe =
Hello there,
Static analyser cppcheck noticed the above problem. Source code is
if (dcfclk_sta_targets[i] < optimal_dcfclk_for_uclk[j] && i <
num_dcfclk_sta_targets) {
Suggest new code:
if (i < num_dcfclk_sta_targets && dcfclk_sta_targets[i] <
On Mon, Sep 11, 2023 at 10:30:37AM +0800, Yong Wu wrote:
> This adds the binding for describing a CMA memory for MediaTek SVP(Secure
> Video Path).
CMA is a Linux thing. How is this related to CMA?
>
> Signed-off-by: Yong Wu
> ---
> .../mediatek,secure_cma_chunkmem.yaml | 42
On 9/7/2023 1:26 AM, Stanislaw Gruszka wrote:
Only compile ivpu_debugfs.c file with CONFIG_DEBUG_FS.
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
On 9/7/2023 1:26 AM, Stanislaw Gruszka wrote:
Use new drm debugfs helpers. This is needed after changes from
commit 78346ebf9f94 ("drm/debugfs: drop debugfs_init() for the render
and accel node v2").
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
On 23/08/2023 15:55, Konrad Dybcio wrote:
A7xx GPUs are - from kernel's POV anyway - basically another generation
of A6xx. They build upon the A650/A660_family advancements, skipping some
writes (presumably more values are preset correctly on reset), adding
some new ones and changing others.
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 992bdddaabfba19bdc77c1c7a4977b2aa41ec891 upstream.
Struct bd6107_platform_data refers to a platform device within
the Linux device hierarchy. The test in
On 9/1/2023 10:48 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
Use struct drm_gem_shmem_object as a base for struct ivpu_bo.
This cuts by 50% the buffer management code.
Signed-off-by: Jacek Lawrynowicz
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 1ca8819320fd84e7d95b04e7668efc5f9fe9fa5c upstream.
Struct lv5207lp_platform_data refers to a platform device within
the Linux device hierarchy. The test in
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 7b91d017f77c1bda56f27c2f4bbb70de7c6eca08 upstream.
Struct gpio_backlight_platform_data refers to a platform device within
the Linux device hierarchy. The test in
On 9/1/2023 10:48 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
Usages of DRM_IVPU_BO_UNCACHED should be replaced by DRM_IVPU_BO_WC.
There is no functional benefit from DRM_IVPU_BO_UNCACHED if these
buffers are never mapped to host VM.
This allows to cut the buffer handling code in the
On 9/1/2023 10:48 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
ivpu_bo_remove_all_bos_from_context() could race with ivpu_bo_free()
when prime buffer was closed after vpu device was closed.
Move the bo_list from context to vdev and use a dedicated lock to
sync it. This list is not
1 - 100 of 238 matches
Mail list logo
