Describe structs and enums used to set blend mode properties to MPC
blocks. Some pieces of information are already available as code
comments, and were just formatted. Others were collected and summarised
from discusssions on AMD issue tracker[1][2].
[1] https://gitlab.freedesktop.org/drm/amd/-/is
AMD GPU display manager (DM) maps DRM pixel blend modes (None,
Pre-multiplied, Coverage) to MPC hw blocks through blend configuration
options. Describe relevant elements and how to set and test them to get
the expected DRM blend mode on DCN hw.
Signed-off-by: Melissa Wen
---
.../gpu/amdgpu/displ
Add details about color correction capabilities and explain a bit about
differences between DC hw generations and also how they are mapped
between DRM and DC interface. Two schemas for DCN 2.0 and 3.0 (converted
to svg from the original png) is included to illustrate it. They were
obtained from a d
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.
v2:
- rebase to amd-staging-drm-next
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
-
Patches 1 and 2 describe DM mapping of DRM color correction properties
to DC interface and where detached from 3D LUT RFC series [1]. Patches 3
and 4 describe MPC block programming that matches the three DRM blend
modes and came from previous work [2][3] and discussions on AMD issue
tracker. Let me
Although dcn31_update_soc_for_wm_a() is only called in dml/dcn31/dcn31_fpu by
dc->res_pool->funcs->update_soc_for_wm_a(dc, context), it's declared in
dcn31_resource that is not FPU protected. Move this function to dcn31_fpu
file as part of the work to isolate FPU code.
Signed-off-by: Melissa Wen
[AMD Official Use Only - General]
Reviewed-by: Yang Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Kenneth Feng
Sent: Saturday, July 16, 2022 12:43 PM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH] drm/amd/pm: enable mode1 reset fo
Am 15.07.22 um 17:25 schrieb Dong, Ruijing:
[AMD Official Use Only - General]
Why exactly do we need a new define for this? Essentially the encode queue is
extended with new functionality, isn't it?
So I think we should just stick to AMDGPU_HW_IP_VCN_ENC and not add an alias
for it.
Yes, it
>From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
both encoding and decoding jobs, it re-uses the same
queue number of AMDGPU_HW_IP_VCN_ENC.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by: Ruijing Dong
---
include/uapi/drm/amdgpu_drm.h | 6 ++
Hi Russell,
On Fri, Jul 15, 2022 at 12:34 AM Russell Currey wrote:
>
> Hi Linus,
>
> On Wed, 2022-07-13 at 14:32 -0700, Linus Torvalds wrote:
> > On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher
> > wrote:
> > >
> > > If you want to apply Guenter's patch original patch:
> > > https://patchwork.freed
This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
for current 5.19.0-rc6
Changes since the last version:
- Fixed problems with migration during long-term pinning in
get_user_pages
- Open coded vm_normal_lru_pages as suggested in previous code review
- Update hmm_gup_test with mor
Hi Ruijing,
ok in this case please prepare a kernel patch and send it to the mailing
list with full description why we do this change.
Thanks,
Christian.
Am 15.07.22 um 15:33 schrieb Dong, Ruijing:
[AMD Official Use Only - General]
Hi Christian,
You are right, when process the libdrm code
Am 14.07.22 um 12:12 schrieb Arunpravin Paneer Selvam:
User reported gpu page fault when running graphics applications
and in some cases garbaged graphics are observed as soon as X
starts. This patch fixes all the issues.
Fixed the typecast issue for fpfn and lpfn variables, thus
preventing the
enable mode1 reset for smu_v13_0_7 since it's missing.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/soc21.c | 1 +
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c
b/driv
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
-Original Message-
From: Dong, Ruijing
Sent: July 15, 2022 4:04 PM
To: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Liu, Leo ;
Dong, Ruijing
Subject: [PATCH v4] drm/amdgpu: add HW_IP_VCN_UNIFIED type
This commit moves phanton FPU stream to dcn32_fpu file.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../drm/amd/display/dc/dcn32/dcn32_resource.c | 89 +--
.../drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 84 +
.../d
From: Wayne Lin
[Why & How]
Correct few problems below to have debugfs trigger_hotplug entry
supports mst case
* Adjust the place for acquiring the hpd_lock. We'll also access
dc_link when simulate unplug
* When detect the connector is a mst root, call
reset_cur_dp_mst_topology() to simulate
On 2022-07-11 21:56, Alex Sierra wrote:
[WHY]
Unified memory with xnack off should be tracked, as userptr mappings
and legacy allocations do. To avoid oversuscribe system memory when
xnack off.
[How]
Exposing functions reserve_mem_limit and unreserve_mem_limit to SVM
API and call them on every pr
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
lib/test_hmm.c | 11 +--
lib/test_hmm_uapi.h |
[WHY]
Unified memory with xnack off should be tracked, as userptr mappings
and legacy allocations do. To avoid oversuscribe system memory when
xnack off.
[How]
Exposing functions reserve_mem_limit and unreserve_mem_limit to SVM
API and call them on every prange creation and free.
Signed-off-by: Al
We want to calculate the DTB clock values when DSC is enabled; however,
this is not the current behavior implemented in DCN32. Right now, DML is
trying to calculate DSC values even if DSC is disabled; as a result, we
can have a hard hang due to wrong clock calculation. This commit fixes
this issue
From: Chris Park
[Why]
Cursor size can update without MALL cache update.
Update the register on cursor attribute as well.
[How]
Update cursor MALL cache on cursor attribute update.
Reviewed-by: Alvin Lee
Acked-by: Alan Liu
Signed-off-by: Chris Park
---
.../gpu/drm/amd/display/dc/dcn32/dcn32
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair
From: Wenjing Liu
[why]
Number of DSC slices is an input to DML with high dependency
on display specific capability. This isn't something DML can decide
on its own. DML has to use the original number of DSC slices input
to DML during validation without modification. Otherwise the
computed DSC del
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
Also
With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not support LRU lists, NUMA migration or THP.
Callers to follow_page() currently do
The objective is to test device migration mechanism in pages marked
as COW, for private and coherent device type. In case of writing to
COW private page(s), a page fault will migrate pages back to system
memory first. Then, these pages will be duplicated. In case of COW
device coherent type, pages
From: Alistair Popple
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these pages.
From: Taimur Hassan
[Why]
For certain MPO configurations, DML will split a pipe after DET buffer has
already been allocated by driver, resulting in allocation of more DET
segments than the configurable return buffer has, causing underflow.
[How]
Determine during DET override calculation whether
From: Vladimir Stempen
[Why]
VM enabled in IP configuration causes UCLK not
reaching DPM0. The expectation for VM enable should
be that KMD will indicate to DAL when VM is enabled,
then DAL will set the bit accordingly
[How]
Set gpuvm_enable to zero in DCN3_20 and DCN3_21 resource.
Reviewed-by:
From: Alvin Lee
Update DML to configure drr_display in vba struct.
Reviewed-by: Dmytro Laktyushkin
Acked-by: Alan Liu
Signed-off-by: Alvin Lee
---
drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h | 1 +
drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c | 1 +
2 files changed
The intention is to test hmm device coherent type under different get
user pages paths. Also, test gup with FOLL_LONGTERM flag set in
device coherent pages. These pages should get migrated back to system
memory.
Signed-off-by: Alex Sierra
Reviewed-by: Alistair Popple
---
tools/testing/selftests
Move get_optimal_ntuple to the FPU code and call it inside
insert_entry_into_table_sorted.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../drm/amd/display/dc/dcn32/dcn32_resource.c | 28 ---
.../drm/amd/display/dc/dml/dcn32/dcn32_f
The function dcn32_helper_populate_phantom_dlg_params uses FPU
operations. For this reason, this commit moves this function to the
dcn32_fpu file, and we ensure that we only invoke it under the
kernel_fpu protection.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo S
From: Alvin Lee
[Description]
In general cases we want to keep the dram clock change requirement (we
prefer configs that support MCLK switch). Only override to false for
SubVP.
Acked-by: Alan Liu
Signed-off-by: Alvin Lee
---
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 10 +
[AMD Official Use Only - General]
Reviewed-by: Leo Liu
-Original Message-
From: Dong, Ruijing
Sent: July 15, 2022 12:09 PM
To: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Liu, Leo ;
Dong, Ruijing
Subject: [PATCH v3] drm/amdgpu: add comments to HW_IP_VCN_
From: Wayne Lin
[Why & How]
In order to leverage igt tool to maintain mst feature, expose new
debugfs entry "mst_progress_status".
In our dm flow, record down the result of each phase of mst and user
can examine the mst result by checking whether each phase get completed
successfully.
Reviewed-
We are working to isolate FPU operations inside the DML folder, and the
file dcn32_clk_mgr has some of these operations. This commit moves the
FPU operations inside the clock manager and creates the dcn32_fpu file
to aggregate those operations. Note that there is no functional change
ere, just movi
From: Aric Cyr
This version brings along following fixes:
- Isolate FPU operation for DCN32/321 under the DML folder
- Create a specific file for CRTC and plane based on amdgpu_dm
- Fix DSC issues
- Update DML logic
Acked-by: Alan Liu
Signed-off-by: Aric Cyr
---
drivers/gpu/drm/amd/display/d
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
- Isolate FPU operation for DCN32/321 under the DML folder
- Create a specific file for CRTC and plane based on amdgpu_dm
- Fix DSC issues
- Updates tp DML logic
Cc: Daniel Wheeler
Thanks
Siqueira
Alvin Lee (2):
From: Wayne Lin
[Why & How]
Add "is_mst_connector" debugfs entry to help distinguish whether
a connector is in a mst topology or not.
Access it with the following command:
cat /sys/kernel/debug/dri/0/DP-X/is_mst_connector
Result:
- "root" stands for the root connector of the topology
- "bra
Move dcn32_calculate_wm_and_dlg from dcn32 resources to the FPU code.
Additionally, this commit adds an interface to it.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../drm/amd/display/dc/dcn32/dcn32_resource.c | 196 +-
.../drm/am
This commit fully move the missing FPU operations from dcn321 resource
to dcn321 fpu. It also remove those FPU flags from the Makefile.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dc/dcn321/Makefile| 25 -
.../amd/disp
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
It looks like many of the code related to SubVP uses FPU operation, and
we have many static functions that are part of this feature. This commit
is a little bit large, but it only moves SubVP operation from one file
to another, and I had to do it in a single change due to dependencies
between funct
The final part of the DCN32 code that uses FPU is the bounding box code,
and this commit move it to dcn32_fpu.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../drm/amd/display/dc/dcn32/dcn32_resource.c | 460 +
.../drm/amd/display/d
The file dcn321_resource has a lot of FPU operations that should be
inside the dml folder. This commit introduces the dcn321_fpu file and
moves some of the FPU operation functions to this new file.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../a
The function dcn32_predict_pipe_split uses FPU operations. This commit
moves this function to the dcn32_fpu file, and we ensure that we only
invoke it under the kernel_fpu protection.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../drm/amd/display
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only sup
[Why]
The amdgpu_dm file contains most of the code that works as an interface
between DRM API and DC. As a result, this file becomes very large since
it comprises multiple abstractions such as CRTC manipulation.
[How]
This commit extracts the CRTC code to its specific file named
amdgpu_dm_crtc. Th
From: Jun Lei
[why]
Unbounded request logic in resource/DML has some issues where unbounded
request is being enabled incorrectly. SW today enables unbounded request
unconditionally in hardware, on the assumption that HW can always
support it in single pipe scenarios.
This worked until now becaus
From: Jun Lei
Remove an unused variable "remove_disconnect_edp" which was a workaround
bit.
Acked-by: Alan Liu
Signed-off-by: Jun Lei
---
drivers/gpu/drm/amd/display/dc/dc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/d
From: Taimur Hassan
[Why & How]
There are cases where the pipes populated are not all at the top
of the pipes list under context. Loop through all pipes for DET
allocation instead of just the number of populated ones, even if
some unpopulated pipes are iterated through unnecessarily.
Reviewed-by
This is the final commit from the FPU isolation for DCN32 and for this
reason we can finally remove flags related to FPU.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dcn32/Makefile | 28 ---
1 file ch
Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.
Signed
From: Wayne Lin
[Why & How]
Need to leverage this function out of dc_link.c. Change it to public.
Reviewed-by: Hersen Wu
Acked-by: Alan Liu
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
drivers/gpu/drm/amd/display/dc/dc_link.h | 3 +++
2 files change
Move dlg params calculation to the FPU folder and make it static.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Siqueira
---
.../drm/amd/display/dc/dcn32/dcn32_resource.c | 485 +
.../drm/amd/display/dc/dcn32/dcn32_resource.h | 6 -
.../drm/amd
[Why]
The amdgpu_dm file contains most of the code that works as an interface
between DRM API and DC. As a result, this file becomes very large since
it comprises multiple abstractions such as plane manipulation.
[How]
This commit extracts the plane code to its specific file named
amdgpu_dm_plane.
>From VCN4, HW_IP_VCN_ENC will be used as unified queue,
and support both encoding and decoding jobs, HW_IP_VCN_DEC
is retired from VCN4.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by: Ruijing Dong
---
include/uapi/drm/amdgpu_drm.h | 7 +++
1 file
On 2022-07-15 05:28, Zhu, Jiadong wrote:
[AMD Official Use Only - General]
Updated some comments
-Original Message-
From: Zhu, Jiadong
Sent: Friday, July 15, 2022 5:13 PM
To: Christian König ;
amd-gfx@lists.freedesktop.org; Grodzovsky, Andrey
Cc: Huang, Ray ; Liu, Aaron
Subject: RE
From: Wayne Lin
[Why]
When CONFIG_DRM_AMD_SECURE_DISPLAY is enabled, it will try
to register vertical interrupt 0 for specific task.
Currently, only dcn10 have defined relevant info for vertical interrupt
0. If we enable CONFIG_DRM_AMD_SECURE_DISPLAY for other dcn ASIC, will
get DC_IRQ_SOURCE_IN
The insert_entry_into_table_sorted function uses FPU operation and calls
other static functions support. This commit moves the insert entry
function with all the required struct and static functions to the FPU
file.
Reviewed-by: Harry Wentland
Acked-by: Rodrigo Siqueira
Signed-off-by: Rodrigo Si
Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Snapshot test case updated to read memory device type first and based
on that, get the proper returned results migrat
Am 15.07.22 um 16:44 schrieb Ruijing Dong:
Define HW_IP_VCN_UNIFIED type the same as HW_IP_VCN_ENC.
VCN4 support for libdrm needs a new definition for
the unified queue, so that it can align to the kernel.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by
[AMD Official Use Only - General]
>> Why exactly do we need a new define for this? Essentially the encode queue
>> is extended with new functionality, isn't it?
>> So I think we should just stick to AMDGPU_HW_IP_VCN_ENC and not add an alias
>> for it.
Yes, it extended the encode queue to includ
[AMD Official Use Only - General]
Hi Christian,
You are right, when process the libdrm code review (not committed yet), we
realized the corresponding file needs to align to the kernel.
So we will need to have this header file changed first, then to process libdrm
code again.
Thanks,
Ruijing
-
is_pinnable_page() and folio_is_pinnable() were renamed to
is_longterm_pinnable_page() and folio_is_longterm_pinnable()
respectively. These functions are used in the FOLL_LONGTERM flag
context.
Signed-off-by: Alex Sierra
Reviewed-by: David Hildenbrand
---
include/linux/mm.h | 8
mm/gup
[WHY]
It makes more sense to have these helpers in zone specific header
file, rather than the generic mm.h
Signed-off-by: Alex Sierra
---
include/linux/memremap.h | 2 +-
include/linux/mm.h | 78 ---
include/linux/mmzone.h | 80 +++
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
Reviewed-by: David H
Hi Dave, Daniel,
One more stable fix for 5.19.
The following changes since commit 3283c83eb6fcfbda8ea03d7149d8e42e71c5d45e:
drm/amd/display: Ensure valid event timestamp for cursor-only commits
(2022-07-13 12:20:37 -0400)
are available in the Git repository at:
https://gitlab.freedesktop.
On 7/15/22 10:19, Christian König wrote:
>> -struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment
>> *attach,
>> - enum dma_data_direction direction)
>> +struct sg_table *
>> +dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
>> + enum
On 7/15/22 09:50, Christian König wrote:
> Am 15.07.22 um 02:52 schrieb Dmitry Osipenko:
>> Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the
>> attachment to the i915 dma-buf. In order to let all drivers utilize
>> shared
>> wait-wound context during attachment in a general
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these pages. These are
coherent and
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked functions for the case where DRM core now holds
the loc
On Thu, Jul 14, 2022 at 7:24 PM Guenter Roeck wrote:
> On 7/14/22 09:48, Linus Torvalds wrote:
> > And some look positively strange. Like that
> >
> >drivers/mfd/asic3.c: error: unused variable 'asic'
> > [-Werror=unused-variable]: => 941:23
> >
> > which is clearly used three lines later by
On 7/14/2022 9:11 PM, Alistair Popple wrote:
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fai
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
> Thanks, Hans:
>
> On 7/12/22 14:38, Hans de Goede wrote:
>> On some new laptop designs a new Nvidia specific WMI interface is present
>> which gives info about panel brightness control and may allow controlling
>> the brightness through this inte
This patch moves the non-dynamic dma-buf users over to the dynamic
locking specification. From now on all dma-buf importers are responsible
for holding dma-buf's reservation lock around operations performed over
dma-bufs. This strict locking convention prevents dead lock situation for
dma-buf impor
Define HW_IP_VCN_UNIFIED type the same as HW_IP_VCN_ENC.
VCN4 support for libdrm needs a new definition for
the unified queue, so that it can align to the kernel.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by: Ruijing Dong
---
include/uapi/drm/amdgpu_
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Signed-off-by: Dmitry Osipenko
---
d
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs.
This common locking convention allows us to utilize reservation lock more
b
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Sig
Hi,
On 7/12/22 22:24, Daniel Dadap wrote:
> I'll ask around to see if there's some DMI property we can match in order to
> detect whether a system is expected to use the EC backlight driver: if so,
> maybe we can avoid the WMI interactions in patch 16/29 of this series.
> Although I suppose eve
Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the
attachment to the i915 dma-buf. In order to let all drivers utilize shared
wait-wound context during attachment in a general way, make dma-buf core to
acquire the ww context internally for the attachment operation and update
i
Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later on we will make the "unlocked"
functions to take
Às 13:45 de 14/07/22, Maíra Canal escreveu:
> Based on the dml30_CalculateWriteBackDISPCLK, it separates the
> DISPCLK calculations on three variables, making no functional changes, in
> order
> to make it more readable and better express that three values are being
> compared
> on dml_max.
>
>
86 matches
Mail list logo
