RE: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp

[Zhang, Yifan]

[Public]

Hi Aaron,

Yes, the cache info are different. But this diff is intentional to workaround 
the discovery table lacks cache info in GC 11.0.1 issue. The workaround will be 
removed after discovery table finishes integrating cache info. Given they 
already have a test version, we can pend this patch until they finish 
integration.

Best Regards,
Yifan

-Original Message-
From: Liu, Aaron  
Sent: Friday, September 2, 2022 9:44 AM
To: Huang, Tim ; Zhang, Yifan ; 
amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Du, Xiaojian 

Subject: RE: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp

[Public]

Hi Yifan,

Yellow carp's cache info cannot be duplicated to GC_11_0_1.

Different point to GC_11_0_1:
TCP L1  Cache size is 32 
GL1 Data Cache size per SA is 256

Others looks good to me 

--
Best Regards
Aaron Liu

> -Original Message-
> From: amd-gfx  On Behalf Of 
> Huang, Tim
> Sent: Friday, September 2, 2022 6:44 AM
> To: Zhang, Yifan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Du, Xiaojian 
> 
> Subject: RE: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow 
> carp
> 
> [Public]
> 
> [Public]
> 
> Reviewed-by: Tim Huang 
> 
> Best Regards,
> Tim Huang
> 
> 
> 
> -Original Message-
> From: Zhang, Yifan 
> Sent: Thursday, September 1, 2022 3:30 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Tim 
> ; Du, Xiaojian ; Zhang, Yifan 
> 
> Subject: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp
> 
> Current discovery table doesn't have cache info for GC 11.0.1, thus 
> can't be parsed like other GC 11, this patch to match GC 11.0.1 cache 
> info to yellow carp
> 
> Signed-off-by: Yifan Zhang 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 24b414cff3ec..1c500bfb0b28 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -1516,11 +1516,11 @@ static int kfd_fill_gpu_cache_info(struct 
> kfd_dev *kdev,
> case IP_VERSION(10, 3, 3):
> case IP_VERSION(10, 3, 6): /* TODO: Double check these 
> on production silicon */
> case IP_VERSION(10, 3, 7): /* TODO: Double check these 
> on production silicon */
> +   case IP_VERSION(11, 0, 1): /* TODO: Double check these 
> +on production silicon */
> pcache_info = yellow_carp_cache_info;
> num_of_cache_types = 
> ARRAY_SIZE(yellow_carp_cache_info);
> break;
> case IP_VERSION(11, 0, 0):
> -   case IP_VERSION(11, 0, 1):
> case IP_VERSION(11, 0, 2):
> case IP_VERSION(11, 0, 3):
> pcache_info = cache_info;
> --
> 2.37.1

RE: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp

[Liu, Aaron]

[Public]

Hi Yifan,

Yellow carp's cache info cannot be duplicated to GC_11_0_1.

Different point to GC_11_0_1:
TCP L1  Cache size is 32 
GL1 Data Cache size per SA is 256

Others looks good to me 

--
Best Regards
Aaron Liu

> -Original Message-
> From: amd-gfx  On Behalf Of
> Huang, Tim
> Sent: Friday, September 2, 2022 6:44 AM
> To: Zhang, Yifan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Du, Xiaojian
> 
> Subject: RE: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp
> 
> [Public]
> 
> [Public]
> 
> Reviewed-by: Tim Huang 
> 
> Best Regards,
> Tim Huang
> 
> 
> 
> -Original Message-
> From: Zhang, Yifan 
> Sent: Thursday, September 1, 2022 3:30 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Tim
> ; Du, Xiaojian ; Zhang,
> Yifan 
> Subject: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp
> 
> Current discovery table doesn't have cache info for GC 11.0.1, thus can't be
> parsed like other GC 11, this patch to match GC 11.0.1 cache info to yellow
> carp
> 
> Signed-off-by: Yifan Zhang 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 24b414cff3ec..1c500bfb0b28 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -1516,11 +1516,11 @@ static int kfd_fill_gpu_cache_info(struct kfd_dev
> *kdev,
> case IP_VERSION(10, 3, 3):
> case IP_VERSION(10, 3, 6): /* TODO: Double check these on
> production silicon */
> case IP_VERSION(10, 3, 7): /* TODO: Double check these on
> production silicon */
> +   case IP_VERSION(11, 0, 1): /* TODO: Double check these
> +on production silicon */
> pcache_info = yellow_carp_cache_info;
> num_of_cache_types = 
> ARRAY_SIZE(yellow_carp_cache_info);
> break;
> case IP_VERSION(11, 0, 0):
> -   case IP_VERSION(11, 0, 1):
> case IP_VERSION(11, 0, 2):
> case IP_VERSION(11, 0, 3):
> pcache_info = cache_info;
> --
> 2.37.1

RE: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp

[Huang, Tim]

[Public]

Reviewed-by: Tim Huang 

Best Regards,
Tim Huang



-Original Message-
From: Zhang, Yifan 
Sent: Thursday, September 1, 2022 3:30 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, Tim 
; Du, Xiaojian ; Zhang, Yifan 

Subject: [PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp

Current discovery table doesn't have cache info for GC 11.0.1, thus can't be 
parsed like other GC 11, this patch to match GC 11.0.1 cache info to yellow carp

Signed-off-by: Yifan Zhang 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 24b414cff3ec..1c500bfb0b28 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -1516,11 +1516,11 @@ static int kfd_fill_gpu_cache_info(struct kfd_dev *kdev,
case IP_VERSION(10, 3, 3):
case IP_VERSION(10, 3, 6): /* TODO: Double check these on 
production silicon */
case IP_VERSION(10, 3, 7): /* TODO: Double check these on 
production silicon */
+   case IP_VERSION(11, 0, 1): /* TODO: Double check these on 
production
+silicon */
pcache_info = yellow_carp_cache_info;
num_of_cache_types = ARRAY_SIZE(yellow_carp_cache_info);
break;
case IP_VERSION(11, 0, 0):
-   case IP_VERSION(11, 0, 1):
case IP_VERSION(11, 0, 2):
case IP_VERSION(11, 0, 3):
pcache_info = cache_info;
--
2.37.1

[linux-next:master] BUILD REGRESSION e47eb90a0a9ae20b82635b9b99a8d0979b757ad8

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: e47eb90a0a9ae20b82635b9b99a8d0979b757ad8  Add linux-next specific 
files for 20220901

Error/Warning reports:

https://lore.kernel.org/linux-media/202209020437.exeodmfe-...@intel.com
https://lore.kernel.org/llvm/202208312208.hjwleien-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

drivers/base/regmap/regmap-mmio.c:221:17: error: implicit declaration of 
function 'writesb'; did you mean 'writeb'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:224:17: error: implicit declaration of 
function 'writesw'; did you mean 'writew'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:227:17: error: implicit declaration of 
function 'writesl'; did you mean 'writel'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:231:17: error: implicit declaration of 
function 'writesq'; did you mean 'writeq'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:231:17: error: implicit declaration of 
function 'writesq'; did you mean 'writesl'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:358:17: error: implicit declaration of 
function 'readsb'; did you mean 'readb'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:361:17: error: implicit declaration of 
function 'readsw'; did you mean 'readw'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:364:17: error: implicit declaration of 
function 'readsl'; did you mean 'readl'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:368:17: error: implicit declaration of 
function 'readsq'; did you mean 'readq'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:368:17: error: implicit declaration of 
function 'readsq'; did you mean 'readsl'? 
[-Werror=implicit-function-declaration]
drivers/clk/clk.c:1193:6: error: redefinition of 'clk_is_enabled_when_prepared'
drivers/clk/clk.c:866:6: error: redefinition of 'clk_unprepare'
drivers/clk/clk.c:947:5: error: redefinition of 'clk_prepare'
drivers/gpu/drm/amd/amdgpu/imu_v11_0_3.c:139:6: warning: no previous prototype 
for 'imu_v11_0_3_program_rlc_ram' [-Wmissing-prototypes]
drivers/platform/mellanox/mlxreg-lc.c:866 mlxreg_lc_probe() warn: passing zero 
to 'PTR_ERR'
net/ieee802154/nl802154.c:2503:26: error: 'NL802154_CMD_DEL_SEC_LEVEL' 
undeclared here (not in a function); did you mean 
'NL802154_CMD_SET_CCA_ED_LEVEL'?

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allyesconfig
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsw
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesw
|   `-- 
drivers-gpu-drm-amd-amdgpu-imu_v11_0_3.c:warning:no-previous-prototype-for-imu_v11_0_3_program_rlc_ram
|-- alpha-buildonly-randconfig-r003-20220901
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsw
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesq
|   `-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesw
|-- alpha-randconfig-r021-20220901
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsw
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesq
|   `-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesw

Re: [PATCH v2 1/2] drm/amdgpu: Move HDP remapping earlier during init

[Alex Deucher]

How about this?  We should just move HDP remap to gmc hw_init since
that is mainly what uses it anyway.

Alex

On Tue, Aug 30, 2022 at 2:05 PM Alex Deucher  wrote:
>
> On Tue, Aug 30, 2022 at 12:06 PM Lazar, Lijo  wrote:
> >
> >
> >
> > On 8/30/2022 8:39 PM, Alex Deucher wrote:
> > > On Tue, Aug 30, 2022 at 10:45 AM Lazar, Lijo  wrote:
> > >>
> > >>
> > >>
> > >> On 8/30/2022 7:18 PM, Alex Deucher wrote:
> > >>> On Tue, Aug 30, 2022 at 12:05 AM Lazar, Lijo  wrote:
> > 
> > 
> > 
> >  On 8/29/2022 10:20 PM, Alex Deucher wrote:
> > > On Mon, Aug 29, 2022 at 4:18 AM Lijo Lazar  wrote:
> > >>
> > >> HDP flush is used early in the init sequence as part of memory 
> > >> controller
> > >> block initialization. Hence remapping of HDP registers needed for 
> > >> flush
> > >> needs to happen earlier.
> > >>
> > >> This also fixes the Unsupported Request error reported through AER 
> > >> during
> > >> driver load. The error happens as a write happens to the remap offset
> > >> before real remapping is done.
> > >>
> > >> Link: 
> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D216373data=05%7C01%7Clijo.lazar%40amd.com%7Cbe8781fe1b0c41d3bad408da8a99b3d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637974690005710507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=98WWFEcwi2tzyf%2BxnYC%2FK3UcCE5mfXI00qfYGUpt2Sk%3Dreserved=0
> > >>
> > >> The error was unnoticed before and got visible because of the commit
> > >> referenced below. This doesn't fix anything in the commit below, 
> > >> rather
> > >> fixes the issue in amdgpu exposed by the commit. The reference is 
> > >> only
> > >> to associate this commit with below one so that both go together.
> > >>
> > >> Fixes: 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in 
> > >> get_port_device_capability()")
> > >>
> > >> Reported-by: Tom Seewald 
> > >> Signed-off-by: Lijo Lazar 
> > >> Cc: sta...@vger.kernel.org
> > >
> > > How about something like the attached patch rather than these two
> > > patches?  It's a bit bigger but seems cleaner and more defensive in my
> > > opinion.
> > >
> > 
> >  Whenever device goes to suspend/reset and then comes back, remap offset
> >  has to be set back to 0 to make sure it doesn't use the wrong offset
> >  when the register assumes default values again.
> > 
> >  To avoid the if-check in hdp_flush (which is more frequent), another 
> >  way
> >  is to initialize the remap offset to default offset during early init
> >  and hw fini/suspend sequences. It won't be obvious (even with this
> >  patch) as to when remap offset vs default offset is used though.
> > >>>
> > >>> On resume, the common IP is resumed first so it will always be set.
> > >>> The only case that is a problem is init because we init GMC out of
> > >>> order.  We could init common before GMC in amdgpu_device_ip_init().  I
> > >>> think that should be fine, but I wasn't sure if there might be some
> > >>> fallout from that on certain cards.
> > >>>
> > >>
> > >> There are other places where an IP order is forced like in
> > >> amdgpu_device_ip_reinit_early_sriov(). This also may not affect this
> > >> case as remapping is not done for VF.
> > >>
> > >> Agree that a better way is to have the common IP to be inited first.
> > >
> > > How about these patches?
> > >
> >
> > Looks good to me. BTW, is nbio 7.7 for an APU (in which case hdp flush
> > is not expected to be used)?
>
> It would be used in some cases, e.g., GPU VM passthrough where we use
> the BAR rather than the carve out.
>
> Alex
>
>
> >
> > Thanks,
> > Lijo
> >
> > > Alex
> > >
> > >
> > >>
> > >> Thanks,
> > >> Lijo
> > >>
> > >>> Alex
> > >>>
> > 
> >  Thanks,
> >  Lijo
> > 
> > > Alex
> > >
> > >> ---
> > >> v2:
> > >>Take care of IP resume cases (Alex Deucher)
> > >>Add NULL check to nbio.funcs to cover older (GFXv8) ASICs 
> > >> (Felix Kuehling)
> > >>Add more details in commit message and associate with AER 
> > >> patch (Bjorn
> > >> Helgaas)
> > >>
> > >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24 
> > >> ++
> > >> drivers/gpu/drm/amd/amdgpu/nv.c|  6 --
> > >> drivers/gpu/drm/amd/amdgpu/soc15.c |  6 --
> > >> drivers/gpu/drm/amd/amdgpu/soc21.c |  6 --
> > >> 4 files changed, 24 insertions(+), 18 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > >> index ce7d117efdb5..e420118769a5 100644
> > >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > >> +++ 

[PATCH] drm/amd/display: Fix register definitions for DCN32/321

[Aurabindo Pillai]

[Why & How]
Fix the instatiation sequence for MPC registers and add a few other
missing register definitions that were ommited erroneously when copying
them over to enable runtime initialization of reigster offsets for
DCN32/321

Signed-off-by: Aurabindo Pillai 
---
 .../drm/amd/display/dc/dcn32/dcn32_resource.c |  27 +--
 .../drm/amd/display/dc/dcn32/dcn32_resource.h | 216 --
 .../amd/display/dc/dcn321/dcn321_resource.c   |  24 +-
 3 files changed, 166 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
index ef0a6d468a10..9d3b8568351e 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
@@ -461,22 +461,17 @@ static const struct dcn20_dsc_mask dsc_mask = {
 };
 
 static struct dcn30_mpc_registers mpc_regs;
-#define dcn_mpc_regs_init()\
-   ( \
-   MPC_REG_LIST_DCN3_0_RI(0),\
-   MPC_REG_LIST_DCN3_0_RI(1),\
-   MPC_REG_LIST_DCN3_0_RI(2),\
-   MPC_REG_LIST_DCN3_0_RI(3),\
-   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(0),\
-   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(1),\
-   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(2),\
-   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(3),\
-   MPC_MCM_REG_LIST_DCN32_RI(0),\
-   MPC_MCM_REG_LIST_DCN32_RI(1),\
-   MPC_MCM_REG_LIST_DCN32_RI(2),\
-   MPC_MCM_REG_LIST_DCN32_RI(3),\
-   MPC_DWB_MUX_REG_LIST_DCN3_0_RI(0)\
-   )
+
+#define dcn_mpc_regs_init() \
+   MPC_REG_LIST_DCN3_2_RI(0),\
+   MPC_REG_LIST_DCN3_2_RI(1),\
+   MPC_REG_LIST_DCN3_2_RI(2),\
+   MPC_REG_LIST_DCN3_2_RI(3),\
+   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(0),\
+   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(1),\
+   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(2),\
+   MPC_OUT_MUX_REG_LIST_DCN3_0_RI(3),\
+   MPC_DWB_MUX_REG_LIST_DCN3_0_RI(0)
 
 static const struct dcn30_mpc_shift mpc_shift = {
MPC_COMMON_MASK_SH_LIST_DCN32(__SHIFT)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.h 
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.h
index 60d8fad16eee..4c931905223d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.h
@@ -222,7 +222,8 @@ void dcn32_determine_det_override(struct dc_state *context, 
display_e2e_pipe_par
   SRI_ARR(DP_MSA_TIMING_PARAM4, DP, id),   
\
   SRI_ARR(DP_MSE_RATE_CNTL, DP, id), SRI_ARR(DP_MSE_RATE_UPDATE, DP, id),  
\
   SRI_ARR(DP_PIXEL_FORMAT, DP, id), SRI_ARR(DP_SEC_CNTL, DP, id),  
\
-  SRI_ARR(DP_SEC_CNTL2, DP, id), SRI_ARR(DP_SEC_CNTL6, DP, id),
\
+  SRI_ARR(DP_SEC_CNTL1, DP, id), SRI_ARR(DP_SEC_CNTL2, DP, id),
\
+  SRI_ARR(DP_SEC_CNTL5, DP, id), SRI_ARR(DP_SEC_CNTL6, DP, id),
\
   SRI_ARR(DP_STEER_FIFO, DP, id), SRI_ARR(DP_VID_M, DP, id),   
\
   SRI_ARR(DP_VID_N, DP, id), SRI_ARR(DP_VID_STREAM_CNTL, DP, id),  
\
   SRI_ARR(DP_VID_TIMING, DP, id), SRI_ARR(DP_SEC_AUD_N, DP, id),   
\
@@ -735,75 +736,6 @@ void dcn32_determine_det_override(struct dc_state 
*context, display_e2e_pipe_par
 #define MPC_DWB_MUX_REG_LIST_DCN3_0_RI(inst)   
\
   SRII_DWB(DWB_MUX, MUX, MPC_DWB, inst)
 
-#define MPC_MCM_REG_LIST_DCN32_RI(inst)
\
-  ( \
-  SRII(MPCC_MCM_SHAPER_CONTROL, MPCC_MCM, inst),   
\
-  SRII(MPCC_MCM_SHAPER_OFFSET_R, MPCC_MCM, inst),  
\
-  SRII(MPCC_MCM_SHAPER_OFFSET_G, MPCC_MCM, inst),  
\
-  SRII(MPCC_MCM_SHAPER_OFFSET_B, MPCC_MCM, inst),  
\
-  SRII(MPCC_MCM_SHAPER_SCALE_R, MPCC_MCM, inst),   
\
-  SRII(MPCC_MCM_SHAPER_SCALE_G_B, MPCC_MCM, inst), 
\
-  SRII(MPCC_MCM_SHAPER_LUT_INDEX, MPCC_MCM, inst), 
\
-  SRII(MPCC_MCM_SHAPER_LUT_DATA, MPCC_MCM, inst),  
\
-  SRII(MPCC_MCM_SHAPER_LUT_WRITE_EN_MASK, MPCC_MCM, inst), 
\
-  SRII(MPCC_MCM_SHAPER_RAMA_START_CNTL_B, MPCC_MCM, inst), 
\
-  SRII(MPCC_MCM_SHAPER_RAMA_START_CNTL_G, MPCC_MCM, inst), 
\
-  SRII(MPCC_MCM_SHAPER_RAMA_START_CNTL_R, MPCC_MCM, inst), 
\
-  SRII(MPCC_MCM_SHAPER_RAMA_END_CNTL_B, MPCC_MCM, inst),   
\
-  SRII(MPCC_MCM_SHAPER_RAMA_END_CNTL_G, MPCC_MCM, inst),   
\
-  SRII(MPCC_MCM_SHAPER_RAMA_END_CNTL_R, MPCC_MCM, inst),   
\
-  SRII(MPCC_MCM_SHAPER_RAMA_REGION_0_1, MPCC_MCM, inst),   
\
-  SRII(MPCC_MCM_SHAPER_RAMA_REGION_2_3, MPCC_MCM, inst),   
\
-  

RE: [PATCH] drm/amdkfd: Allocate doorbells only when needed

[Bhardwaj, Rajneesh]

[AMD Official Use Only - General]

This seems to have broken CRIU restore. After I revert this, I can get CRIU 
restore working.

From: amd-gfx  On Behalf Of Russell, Kent
Sent: Tuesday, August 23, 2022 8:07 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: Allocate doorbells only when needed

No one else seems to have any thoughts on it, so Reviewed-by: Kent Russell 
mailto:kent.russ...@amd.com>>

 Kent


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Russell, Kent mailto:kent.russ...@amd.com>>
Sent: Monday, August 22, 2022 10:10 AM
To: Kuehling, Felix mailto:felix.kuehl...@amd.com>>; 
amd-gfx@lists.freedesktop.org 
mailto:amd-gfx@lists.freedesktop.org>>
Subject: RE: [PATCH] drm/amdkfd: Allocate doorbells only when needed

[AMD Official Use Only - General]

I can throw an Acked-by: Kent Russell 
mailto:kent.russ...@amd.com>> since we don't have an RB 
yet.

 Kent

> -Original Message-
> From: amd-gfx 
> mailto:amd-gfx-boun...@lists.freedesktop.org>>
>  On Behalf Of Felix
> Kuehling
> Sent: Wednesday, August 3, 2022 2:56 PM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdkfd: Allocate doorbells only when needed
>
> Only allocate doorbells when the first queue is created on a GPU or the
> doorbells need to be mapped into CPU or GPU virtual address space. This
> avoids allocating doorbells unnecessarily and can allow more processes
> to use KFD on multi-GPU systems.
>
> Signed-off-by: Felix Kuehling 
> mailto:felix.kuehl...@amd.com>>
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  | 13 +
>  drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c |  9 +
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c  |  5 -
>  3 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 2b3d8bc8f0aa..907f4711abce 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -327,6 +327,12 @@ static int kfd_ioctl_create_queue(struct file *filep,
> struct kfd_process *p,
>goto err_bind_process;
>}
>
> + if (!pdd->doorbell_index &&
> + kfd_alloc_process_doorbells(dev, >doorbell_index) < 0) {
> + err = -ENOMEM;
> + goto err_alloc_doorbells;
> + }
> +
>/* Starting with GFX11, wptr BOs must be mapped to GART for MES to
> determine work
> * on unmapped queues for usermode queue oversubscription (no
> aggregated doorbell)
> */
> @@ -404,6 +410,7 @@ static int kfd_ioctl_create_queue(struct file *filep, 
> struct
> kfd_process *p,
>if (wptr_bo)
>amdgpu_amdkfd_free_gtt_mem(dev->adev, wptr_bo);
>  err_wptr_map_gart:
> +err_alloc_doorbells:
>  err_bind_process:
>  err_pdd:
>mutex_unlock(>mutex);
> @@ -1092,6 +1099,10 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file
> *filep,
>goto err_unlock;
>}
>offset = kfd_get_process_doorbells(pdd);
> + if (!offset) {
> + err = -ENOMEM;
> + goto err_unlock;
> + }
>} else if (flags & KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP) {
>if (args->size != PAGE_SIZE) {
>err = -EINVAL;
> @@ -2173,6 +2184,8 @@ static int criu_restore_memory_of_gpu(struct
> kfd_process_device *pdd,
>return -EINVAL;
>
>offset = kfd_get_process_doorbells(pdd);
> + if (!offset)
> + return -ENOMEM;

Looks like this is causing CRIU restore failure.

>} else if (bo_bucket->alloc_flags &
> KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP) {
>/* MMIO BOs need remapped bus address */
>if (bo_bucket->size != PAGE_SIZE) {
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> index cb3d2ccc5100..b33798f89ef0 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> @@ -157,6 +157,8 @@ int kfd_doorbell_mmap(struct kfd_dev *dev, struct
> kfd_process *process,
>
>/* Calculate physical address of doorbell */
>address = kfd_get_process_doorbells(pdd);
> + if (!address)
> + return -ENOMEM;
>vma->vm_flags |= VM_IO | VM_DONTCOPY | VM_DONTEXPAND |
> VM_NORESERVE |
>VM_DONTDUMP | VM_PFNMAP;
>
> @@ -275,6 +277,13 @@ uint64_t kfd_get_number_elems(struct kfd_dev *kfd)
>
>  phys_addr_t kfd_get_process_doorbells(struct kfd_process_device *pdd)
>  {
> + if (!pdd->doorbell_index) {
> + int r = kfd_alloc_process_doorbells(pdd->dev,
> + >doorbell_index);
> + if (r)
> + 

Re: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()

[Rodrigo Siqueira Jordao]

On 2022-09-01 10:15, Hamza Mahfooz wrote:

Address the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ 
clause does not guard... [-Wmisleading-indentation]
  3508 | if (update_type != UPDATE_TYPE_FAST)
   | ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
‘if’
  3510 | if (update_type != UPDATE_TYPE_FAST)
   | ^~

Signed-off-by: Hamza Mahfooz 
---
v2: implement feedback from Alvin
---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..9860bf38c547 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc,
  
  	if (update_type != UPDATE_TYPE_FAST)

dc->hwss.post_unlock_program_front_end(dc, context);
-   if (update_type != UPDATE_TYPE_FAST)
-   if (dc->hwss.commit_subvp_config)
-   dc->hwss.commit_subvp_config(dc, context);
+
+   if (update_type != UPDATE_TYPE_FAST)
+   if (dc->hwss.commit_subvp_config)
+   dc->hwss.commit_subvp_config(dc, context);
  
  	/* Since phantom pipe programming is moved to post_unlock_program_front_end,

 * move the SubVP lock to after the phantom pipes have been setup


Reviewed-by: Rodrigo Siqueira 
and applied to amd-staging-drm-next.

Thanks
Siqueira

[PATCH] drm/amd/pm: add missing SetMGpuFanBoostLimitRpm mapping for SMU 13.0.7

[Evan Quan]

Missing SetMGpuFanBoostLimitRpm mapping leads to loading failure for SMU
13.0.7.

Signed-off-by: Evan Quan 
Reviewed-by: Hawking Zhang 
Change-Id: I2ea606ad5089b2612069614349c3a228406ef928
---
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index 4de2fc035dc7..c8f4fe4b6371 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -120,6 +120,7 @@ static struct cmn2asic_msg_mapping 
smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(DisallowGfxOff, PPSMC_MSG_DisallowGfxOff,   
   0),
MSG_MAP(Mode1Reset, PPSMC_MSG_Mode1Reset,  
0),
MSG_MAP(PrepareMp1ForUnload,PPSMC_MSG_PrepareMp1ForUnload,  
   0),
+   MSG_MAP(SetMGpuFanBoostLimitRpm,
PPSMC_MSG_SetMGpuFanBoostLimitRpm, 0),
 };
 
 static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
-- 
2.29.0

Re: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()

[Deucher, Alexander]

[Public]

Acked-by: Alex Deucher 

From: Mahfooz, Hamza 
Sent: Thursday, September 1, 2022 10:15 AM
To: linux-ker...@vger.kernel.org 
Cc: Mahfooz, Hamza ; Wentland, Harry 
; Li, Sun peng (Leo) ; Siqueira, 
Rodrigo ; Deucher, Alexander 
; Koenig, Christian ; Pan, 
Xinhui ; David Airlie ; Daniel Vetter 
; Kazlauskas, Nicholas ; Lei, Jun 
; Somasundaram, Meenakshikumar 
; Lee, Alvin ; Leung, 
Martin ; Tam, Samson ; Hung, Alex 
; Liu, Wenjing ; Aberback, Joshua 
; amd-gfx@lists.freedesktop.org 
; dri-de...@lists.freedesktop.org 

Subject: [PATCH v2] drm/amd/display: fix indentation in 
commit_planes_for_stream()

Address the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ 
clause does not guard... [-Wmisleading-indentation]
 3508 | if (update_type != UPDATE_TYPE_FAST)
  | ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
‘if’
 3510 | if (update_type != UPDATE_TYPE_FAST)
  | ^~

Signed-off-by: Hamza Mahfooz 
---
v2: implement feedback from Alvin
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..9860bf38c547 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc,

 if (update_type != UPDATE_TYPE_FAST)
 dc->hwss.post_unlock_program_front_end(dc, context);
-   if (update_type != UPDATE_TYPE_FAST)
-   if (dc->hwss.commit_subvp_config)
-   dc->hwss.commit_subvp_config(dc, context);
+
+   if (update_type != UPDATE_TYPE_FAST)
+   if (dc->hwss.commit_subvp_config)
+   dc->hwss.commit_subvp_config(dc, context);

 /* Since phantom pipe programming is moved to 
post_unlock_program_front_end,
  * move the SubVP lock to after the phantom pipes have been setup
--
2.37.2

[PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()

[Hamza Mahfooz]

Address the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ 
clause does not guard... [-Wmisleading-indentation]
 3508 | if (update_type != UPDATE_TYPE_FAST)
  | ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
‘if’
 3510 | if (update_type != UPDATE_TYPE_FAST)
  | ^~

Signed-off-by: Hamza Mahfooz 
---
v2: implement feedback from Alvin
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..9860bf38c547 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc,
 
if (update_type != UPDATE_TYPE_FAST)
dc->hwss.post_unlock_program_front_end(dc, context);
-   if (update_type != UPDATE_TYPE_FAST)
-   if (dc->hwss.commit_subvp_config)
-   dc->hwss.commit_subvp_config(dc, context);
+
+   if (update_type != UPDATE_TYPE_FAST)
+   if (dc->hwss.commit_subvp_config)
+   dc->hwss.commit_subvp_config(dc, context);
 
/* Since phantom pipe programming is moved to 
post_unlock_program_front_end,
 * move the SubVP lock to after the phantom pipes have been setup
-- 
2.37.2

RE: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

[Ruhl, Michael J]

>-Original Message-
>From: Dmitry Osipenko 
>Sent: Wednesday, August 31, 2022 11:38 AM
>To: David Airlie ; Gerd Hoffmann ;
>Gurchetan Singh ; Chia-I Wu
>; Daniel Vetter ; Daniel Almeida
>; Gert Wollny ;
>Gustavo Padovan ; Daniel Stone
>; Tomeu Vizoso ;
>Maarten Lankhorst ; Maxime Ripard
>; Thomas Zimmermann ;
>Rob Clark ; Sumit Semwal
>; Christian König ;
>Pan, Xinhui ; Thierry Reding
>; Tomasz Figa ; Marek
>Szyprowski ; Mauro Carvalho Chehab
>; Alex Deucher ; Jani
>Nikula ; Joonas Lahtinen
>; Vivi, Rodrigo ;
>Tvrtko Ursulin ; Thomas Hellström
>; Qiang Yu ; Srinivas
>Kandagatla ; Amol Maheshwari
>; Jason Gunthorpe ; Leon
>Romanovsky ; Gross, Jurgen ; Stefano
>Stabellini ; Oleksandr Tyshchenko
>; Tomi Valkeinen ;
>Russell King ; Lucas Stach ;
>Christian Gmeiner 
>Cc: dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Dmitry
>Osipenko ; linux-me...@vger.kernel.org; linaro-mm-
>s...@lists.linaro.org; amd-gfx@lists.freedesktop.org; intel-
>g...@lists.freedesktop.org; ker...@collabora.com; virtualization@lists.linux-
>foundation.org; linux-r...@vger.kernel.org; linux-arm-
>m...@vger.kernel.org
>Subject: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking
>specification
>
>Prepare i915 driver to the common dynamic dma-buf locking convention
>by starting to use the unlocked versions of dma-buf API functions
>and handling cases where importer now holds the reservation lock.
>
>Signed-off-by: Dmitry Osipenko 
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   |  2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c   | 12 
> .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16 
> 3 files changed, 21 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..07eee1c09aaf 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>*dma_buf,
>   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>   void *vaddr;
>
>-  vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>+  vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
>   if (IS_ERR(vaddr))
>   return PTR_ERR(vaddr);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 389e9f157ca5..7e2a9b02526c 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>drm_i915_private *i915,
>   continue;
>   }
>
>+  /*
>+   * dma_buf_unmap_attachment() requires reservation to be
>+   * locked. The imported GEM shouldn't share reservation lock,
>+   * so it's safe to take the lock.
>+   */
>+  if (obj->base.import_attach)
>+  i915_gem_object_lock(obj, NULL);

There is a lot of stuff going here.  Taking the lock may be premature...

>   __i915_gem_object_pages_fini(obj);

The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where
unmap_attachment is actually called, would it make more sense to make
do the locking there?

Mike


>+
>+  if (obj->base.import_attach)
>+  i915_gem_object_unlock(obj);
>+
>   __i915_gem_free_object(obj);
>
>   /* But keep the pointer alive for RCU-protected lookups */
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index 62c61af77a42..9e3ed634aa0e 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
>   goto out_import;
>   }
>
>-  st = dma_buf_map_attachment(import_attach,
>DMA_BIDIRECTIONAL);
>+  st = dma_buf_map_attachment_unlocked(import_attach,
>DMA_BIDIRECTIONAL);
>   if (IS_ERR(st)) {
>   err = PTR_ERR(st);
>   goto out_detach;
>@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
>   timeout = -ETIME;
>   }
>   err = timeout > 0 ? 0 : timeout;
>-  dma_buf_unmap_attachment(import_attach, st,
>DMA_BIDIRECTIONAL);
>+  dma_buf_unmap_attachment_unlocked(import_attach, st,
>DMA_BIDIRECTIONAL);
> out_detach:
>   dma_buf_detach(dmabuf, import_attach);
> out_import:
>@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
>   goto out_obj;
>   }
>
>-  err = dma_buf_vmap(dmabuf, );
>+  err = dma_buf_vmap_unlocked(dmabuf, );
>   dma_map = err ? NULL : map.vaddr;
>   if (!dma_map) {
>   pr_err("dma_buf_vmap failed\n");
>@@ -337,7 +337,7 @@ static int 

Re: [PATCH] drm/amdgpu: disable the debugger on gfx1036

[Deucher, Alexander]

[Public]

Acked-by: Alex Deucher 

From: amd-gfx  on behalf of Zhang, 
Jesse(Jie) 
Sent: Wednesday, August 31, 2022 9:11 PM
To: Alex Deucher ; amd-gfx@lists.freedesktop.org 

Cc: Zhang, Yifan ; Huang, Ray 
Subject: [PATCH] drm/amdgpu: disable the debugger on gfx1036

[Public]


Disable the debugger on gfx1036.

Signed-off-by: jie1zhan jesse.zh...@amd.com
Change-Id: If1d9608d508d1eb29e6c1de7ac7d1db93d1000b0

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
index 5ab20f6dc291..89ebb3ee9ccc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
@@ -1097,6 +1097,7 @@ bool kfd_dbg_has_supported_firmware(struct kfd_dev *dev)
break;
case IP_VERSION(10, 1, 3): /* Cyan Skillfish */
case IP_VERSION(10, 3, 3): /* Yellow Carp*/
+  case IP_VERSION(10, 3, 6): /* gfx1036*/
firmware_supported = false;
break;
default:

[PATCH 3/9] drm/radeon: convert to using is_hdmi and has_audio from display info

[Jani Nikula]

Prefer the parsed results for is_hdmi and has_audio in display info over
calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
respectively.

Cc: Alex Deucher 
Cc: Christian König 
Cc: "Pan, Xinhui" 
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/radeon/atombios_encoders.c | 10 +-
 drivers/gpu/drm/radeon/evergreen_hdmi.c|  5 ++---
 drivers/gpu/drm/radeon/radeon_audio.c  |  6 +++---
 drivers/gpu/drm/radeon/radeon_connectors.c | 12 ++--
 drivers/gpu/drm/radeon/radeon_display.c|  2 +-
 drivers/gpu/drm/radeon/radeon_encoders.c   |  4 ++--
 6 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 0eae05dfb385..4f9a0b8327fe 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -692,7 +692,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if (radeon_connector->use_digital &&
(radeon_connector->audio == RADEON_AUDIO_ENABLE))
return ATOM_ENCODER_MODE_HDMI;
-   else if 
(drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
+   else if (connector->display_info.is_hdmi &&
 (radeon_connector->audio == RADEON_AUDIO_AUTO))
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
@@ -711,7 +711,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if (radeon_audio != 0) {
if (radeon_connector->audio == RADEON_AUDIO_ENABLE)
return ATOM_ENCODER_MODE_HDMI;
-   else if 
(drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
+   else if (connector->display_info.is_hdmi &&
 (radeon_connector->audio == RADEON_AUDIO_AUTO))
return ATOM_ENCODER_MODE_HDMI;
else
@@ -728,14 +728,14 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if ((dig_connector->dp_sink_type == 
CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP)) {
if (radeon_audio != 0 &&
-   
drm_detect_monitor_audio(radeon_connector_edid(connector)) &&
+   connector->display_info.has_audio &&
ASIC_IS_DCE4(rdev) && !ASIC_IS_DCE5(rdev))
return ATOM_ENCODER_MODE_DP_AUDIO;
return ATOM_ENCODER_MODE_DP;
} else if (radeon_audio != 0) {
if (radeon_connector->audio == RADEON_AUDIO_ENABLE)
return ATOM_ENCODER_MODE_HDMI;
-   else if 
(drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
+   else if (connector->display_info.is_hdmi &&
 (radeon_connector->audio == RADEON_AUDIO_AUTO))
return ATOM_ENCODER_MODE_HDMI;
else
@@ -746,7 +746,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
break;
case DRM_MODE_CONNECTOR_eDP:
if (radeon_audio != 0 &&
-   drm_detect_monitor_audio(radeon_connector_edid(connector)) 
&&
+   connector->display_info.has_audio &&
ASIC_IS_DCE4(rdev) && !ASIC_IS_DCE5(rdev))
return ATOM_ENCODER_MODE_DP_AUDIO;
return ATOM_ENCODER_MODE_DP;
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 5f3078f8ab95..134780283274 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -411,7 +411,7 @@ void evergreen_hdmi_enable(struct drm_encoder *encoder, 
bool enable)
if (enable) {
struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
 
-   if (connector && 
drm_detect_monitor_audio(radeon_connector_edid(connector))) {
+   if (connector && connector->display_info.has_audio) {
WREG32(HDMI_INFOFRAME_CONTROL0 + dig->afmt->offset,
   HDMI_AVI_INFO_SEND | /* enable AVI info frames */
   HDMI_AVI_INFO_CONT | /* required for audio info 
values to be updated */
@@ -449,8 +449,7 @@ void evergreen_dp_enable(struct drm_encoder *encoder, bool 
enable)
if (!dig || !dig->afmt)
return;
 
-   if (enable && connector &&
-   drm_detect_monitor_audio(radeon_connector_edid(connector))) {
+   if (enable && connector && connector->display_info.has_audio) {

Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

[Dmitry Osipenko]

On 9/1/22 09:45, Christian König wrote:
> Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
>> Prepare i915 driver to the common dynamic dma-buf locking convention
>> by starting to use the unlocked versions of dma-buf API functions
>> and handling cases where importer now holds the reservation lock.
>>
>> Signed-off-by: Dmitry Osipenko 
> 
> Acked-by: Christian König , but it's probably
> best if somebody from the Intel guys take a look as well.

+ Chris Wilson, who touched locks of __i915_gem_free_objects() recently

>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   |  2 +-
>>   drivers/gpu/drm/i915/gem/i915_gem_object.c   | 12 
>>   .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16 
>>   3 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index f5062d0c6333..07eee1c09aaf 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>> *dma_buf,
>>   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>>   void *vaddr;
>>   -    vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>> +    vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
>>   if (IS_ERR(vaddr))
>>   return PTR_ERR(vaddr);
>>   diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> index 389e9f157ca5..7e2a9b02526c 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>> drm_i915_private *i915,
>>   continue;
>>   }
>>   +    /*
>> + * dma_buf_unmap_attachment() requires reservation to be
>> + * locked. The imported GEM shouldn't share reservation lock,
>> + * so it's safe to take the lock.
>> + */
>> +    if (obj->base.import_attach)
>> +    i915_gem_object_lock(obj, NULL);
>> +
>>   __i915_gem_object_pages_fini(obj);
>> +
>> +    if (obj->base.import_attach)
>> +    i915_gem_object_unlock(obj);
>> +
>>   __i915_gem_free_object(obj);
>>     /* But keep the pointer alive for RCU-protected lookups */
>> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> index 62c61af77a42..9e3ed634aa0e 100644
>> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> @@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>> drm_i915_private *i915,
>>   goto out_import;
>>   }
>>   -    st = dma_buf_map_attachment(import_attach, DMA_BIDIRECTIONAL);
>> +    st = dma_buf_map_attachment_unlocked(import_attach,
>> DMA_BIDIRECTIONAL);
>>   if (IS_ERR(st)) {
>>   err = PTR_ERR(st);
>>   goto out_detach;
>> @@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>> drm_i915_private *i915,
>>   timeout = -ETIME;
>>   }
>>   err = timeout > 0 ? 0 : timeout;
>> -    dma_buf_unmap_attachment(import_attach, st, DMA_BIDIRECTIONAL);
>> +    dma_buf_unmap_attachment_unlocked(import_attach, st,
>> DMA_BIDIRECTIONAL);
>>   out_detach:
>>   dma_buf_detach(dmabuf, import_attach);
>>   out_import:
>> @@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
>>   goto out_obj;
>>   }
>>   -    err = dma_buf_vmap(dmabuf, );
>> +    err = dma_buf_vmap_unlocked(dmabuf, );
>>   dma_map = err ? NULL : map.vaddr;
>>   if (!dma_map) {
>>   pr_err("dma_buf_vmap failed\n");
>> @@ -337,7 +337,7 @@ static int igt_dmabuf_import(void *arg)
>>     err = 0;
>>   out_dma_map:
>> -    dma_buf_vunmap(dmabuf, );
>> +    dma_buf_vunmap_unlocked(dmabuf, );
>>   out_obj:
>>   i915_gem_object_put(obj);
>>   out_dmabuf:
>> @@ -358,7 +358,7 @@ static int igt_dmabuf_import_ownership(void *arg)
>>   if (IS_ERR(dmabuf))
>>   return PTR_ERR(dmabuf);
>>   -    err = dma_buf_vmap(dmabuf, );
>> +    err = dma_buf_vmap_unlocked(dmabuf, );
>>   ptr = err ? NULL : map.vaddr;
>>   if (!ptr) {
>>   pr_err("dma_buf_vmap failed\n");
>> @@ -367,7 +367,7 @@ static int igt_dmabuf_import_ownership(void *arg)
>>   }
>>     memset(ptr, 0xc5, PAGE_SIZE);
>> -    dma_buf_vunmap(dmabuf, );
>> +    dma_buf_vunmap_unlocked(dmabuf, );
>>     obj = to_intel_bo(i915_gem_prime_import(>drm, dmabuf));
>>   if (IS_ERR(obj)) {
>> @@ -418,7 +418,7 @@ static int igt_dmabuf_export_vmap(void *arg)
>>   }
>>   i915_gem_object_put(obj);
>>   -    err = dma_buf_vmap(dmabuf, );
>> +    err = dma_buf_vmap_unlocked(dmabuf, );
>>   ptr = err ? NULL : map.vaddr;
>>   if (!ptr) {
>>   pr_err("dma_buf_vmap failed\n");
>> @@ -435,7 +435,7 @@ static int 

Re: [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention

[Dmitry Osipenko]

Hello Christian,

On 9/1/22 10:49, Christian König wrote:
> Hi Dmitry,
> 
> I've gone over this multiple times now and while it is still possible
> that we missed something I think that this should land now.

Thank you very much for the review!

> The whole topic is just to complicated that we can 100% sure guarantee
> that there isn't anything wrong with the locking, but lockdep and driver
> testing should allow us to quickly find remaining issues.

At least the most popular drivers should be okay. If anyone will find
issue introduced by this series, then indeed shouldn't be a problem to
fix it later on.

> Do you have commit rights to drm-misc-next or should I push it?

I got the drm-misc commit right two weeks ago, haven't pushed anything
there yet. Please let me try to do the push. I'll let you know if any
kind of help will be needed from you.

I'll wait for more acks/r-bs and then do the push.

-- 
Best regards,
Dmitry

Re: [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

[Dmitry Osipenko]

On 9/1/22 09:50, Christian König wrote:
> Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
>> Prepare Etnaviv driver to the common dynamic dma-buf locking convention
>> by starting to use the unlocked versions of dma-buf API functions.
>>
>> Signed-off-by: Dmitry Osipenko 
> 
> Interesting, where is the matching vmap()?
> 
> Anyway, this patch is Acked-by: Christian König 

Etnaviv maps GEM only once and then unmaps it when GEM is destroyed. The
dma-buf vmapping should happen under the reservation lock, hence only
the release function needs to be changed to the unlocked variant.

Lucas/Christian(Gmeiner), could you please check that I haven't missed
anything?

>> ---
>>   drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> index 3fa2da149639..7031db145a77 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> @@ -65,7 +65,7 @@ static void etnaviv_gem_prime_release(struct
>> etnaviv_gem_object *etnaviv_obj)
>>   struct iosys_map map = IOSYS_MAP_INIT_VADDR(etnaviv_obj->vaddr);
>>     if (etnaviv_obj->vaddr)
>> -    dma_buf_vunmap(etnaviv_obj->base.import_attach->dmabuf, );
>> +   
>> dma_buf_vunmap_unlocked(etnaviv_obj->base.import_attach->dmabuf, );
>>     /* Don't drop the pages for imported dmabuf, as they are not
>>    * ours, just free the array we allocated:
> 


-- 
Best regards,
Dmitry

[PATCH -next] drm/amd/display: remove possible condition with no effect (if == else)

[Yang Li]

Conditional statements have no effect to next process.So remove it.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2028
Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 .../drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c   | 4 
 1 file changed, 4 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
index e4fd540dec0f..8f1c0e12dd86 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
@@ -4663,10 +4663,6 @@ void dml32_CalculateMinAndMaxPrefetchMode(
} else if (AllowForPStateChangeOrStutterInVBlankFinal == 
dm_prefetch_support_uclk_fclk_and_stutter) {
*MinPrefetchMode = 0;
*MaxPrefetchMode = 0;
-   } else if (AllowForPStateChangeOrStutterInVBlankFinal ==
-   dm_prefetch_support_uclk_fclk_and_stutter_if_possible) {
-   *MinPrefetchMode = 0;
-   *MaxPrefetchMode = 3;
} else {
*MinPrefetchMode = 0;
*MaxPrefetchMode = 3;
-- 
2.20.1.7.g153144c

[PATCH -next] drm/amd/display: clean up some inconsistent indentings

[Yang Li]

This if statement is the content of the for statement above it. It
should be indented.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2026
Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
index 9dd705b985b9..0139e98a0aa1 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
@@ -417,8 +417,8 @@ void get_subvp_visual_confirm_color(
for (i = 0; i < dc->res_pool->pipe_count; i++) {
struct pipe_ctx *pipe = >current_state->res_ctx.pipe_ctx[i];
 
-   if (pipe->stream && pipe->stream->mall_stream_config.paired_stream &&
-   pipe->stream->mall_stream_config.type == 
SUBVP_MAIN) {
+   if (pipe->stream && 
pipe->stream->mall_stream_config.paired_stream &&
+   pipe->stream->mall_stream_config.type == SUBVP_MAIN) {
/* SubVP enable - red */
color->color_r_cr = color_value;
enable_subvp = true;
-- 
2.20.1.7.g153144c

[PATCH 0/9] drm: convert to using is_hdmi and has_audio from display info

[Jani Nikula]

The low-hanging fruit of the drm todo item "Replace
drm_detect_hdmi_monitor() with drm_display_info.is_hdmi", with has_audio
changes on top.

I'm afraid not all of these have been even build tested, let alone
actually tested.


BR,
Jani.


Cc: Laurent Pinchart  
Cc: Sandy Huang 
Cc: Heiko Stübner 
Cc: Sandy Huang 
Cc: Heiko Stübner 
Cc: Alain Volmat 
Cc: Russell King 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: "Pan, Xinhui" 
Cc: amd-gfx@lists.freedesktop.org
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: nouv...@lists.freedesktop.org

Jani Nikula (9):
  drm/edid: parse display info has_audio similar to is_hdmi
  drm/nouveau: convert to using is_hdmi and has_audio from display info
  drm/radeon: convert to using is_hdmi and has_audio from display info
  drm/tegra: convert to using is_hdmi from display info
  drm/exynos: convert to using is_hdmi from display info
  drm/i2c/tda998x: convert to using has_audio from display_info
  drm/sti/sti_hdmi: convert to using is_hdmi from display info
  drm/rockchip: cdn-dp: call drm_connector_update_edid_property()
unconditionally
  drm/rockchip: convert to using has_audio from display_info

 drivers/gpu/drm/drm_edid.c  |  6 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c|  5 +++--
 drivers/gpu/drm/i2c/tda998x_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  8 
 drivers/gpu/drm/nouveau/dispnv50/head.c |  8 +---
 drivers/gpu/drm/nouveau/nouveau_connector.c |  2 +-
 drivers/gpu/drm/radeon/atombios_encoders.c  | 10 +-
 drivers/gpu/drm/radeon/evergreen_hdmi.c |  5 ++---
 drivers/gpu/drm/radeon/radeon_audio.c   |  6 +++---
 drivers/gpu/drm/radeon/radeon_connectors.c  | 12 ++--
 drivers/gpu/drm/radeon/radeon_display.c |  2 +-
 drivers/gpu/drm/radeon/radeon_encoders.c|  4 ++--
 drivers/gpu/drm/rockchip/cdn-dp-core.c  |  7 +++
 drivers/gpu/drm/rockchip/inno_hdmi.c|  3 ++-
 drivers/gpu/drm/sti/sti_hdmi.c  | 11 ++-
 drivers/gpu/drm/sti/sti_hdmi.h  |  2 --
 drivers/gpu/drm/tegra/hdmi.c|  9 +
 include/drm/drm_connector.h |  8 
 18 files changed, 55 insertions(+), 55 deletions(-)

-- 
2.34.1

[PATCH -next] drm/amd/display: Simplify bool conversion

[Yang Li]

The result of relational operation is Boolean, and the question mark
expression is redundant.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2027
Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 .../gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
index dc501ee7d01a..e4fd540dec0f 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
@@ -1873,7 +1873,7 @@ void dml32_CalculateSurfaceSizeInMall(
if (UseMALLForStaticScreen[k] == 
dm_use_mall_static_screen_enable)
TotalSurfaceSizeInMALL = TotalSurfaceSizeInMALL + 
SurfaceSizeInMALL[k];
}
-   *ExceededMALLSize =  (TotalSurfaceSizeInMALL <= MALLAllocatedForDCN * 
1024 * 1024 ? false : true);
+   *ExceededMALLSize =  (TotalSurfaceSizeInMALL > MALLAllocatedForDCN * 
1024 * 1024);
 } // CalculateSurfaceSizeInMall
 
 void dml32_CalculateVMRowAndSwath(
-- 
2.20.1.7.g153144c

RE: [PATCH] drm/display: guard if clause

[Chen, Guchun]

Yes, exactly. The logic in two successive if checks of "(update_type != 
UPDATE_TYPE_FAST) " is incorrect still.

Possibly we can update code by dropping one if check as below. Anyway, this 
needs confirm from display team @Lee, Alvin @Lei, Jun.

if (update_type != UPDATE_TYPE_FAST) {
dc->hwss.post_unlock_program_front_end(dc, context);
if (dc->hwss.commit_subvp_config)
dc->hwss.commit_subvp_config(dc, context);
}

Regards,
Guchun

-Original Message-
From: Koenig, Christian  
Sent: Thursday, September 1, 2022 7:07 PM
To: Song, Asher ; amd-gfx@lists.freedesktop.org; Lee, Alvin 
; Lei, Jun ; Chen, Guchun 

Subject: Re: [PATCH] drm/display: guard if clause

Well please adjust the subject line, that should read something like 
"drm/amd/display:..." or "drm/amdgpu:...".

Am 01.09.22 um 11:11 schrieb Asher Song:
> To eliminate the following compiling error, guard if clause.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 
> 'commit_planes_for_stream':
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3521:2: error: this 
> 'if' clause does not guard... [-Werror=misleading-indentation]
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3523:3: note: ...this 
> statement, but the latter is misleadingly indented as if it were guarded by 
> the 'if'
> if (update_type != UPDATE_TYPE_FAST)
> ^~
>
> Signed-off-by: Asher Song 
> ---
>   drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index b49237390cce..66072ac1bb4f 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -3505,11 +3505,12 @@ static void commit_planes_for_stream(struct dc *dc,
>   top_pipe_to_program->stream_res.tg);
>   }
>   
> - if (update_type != UPDATE_TYPE_FAST)
> + if (update_type != UPDATE_TYPE_FAST){
>   dc->hwss.post_unlock_program_front_end(dc, context);
>   if (update_type != UPDATE_TYPE_FAST)
>   if (dc->hwss.commit_subvp_config)
>   dc->hwss.commit_subvp_config(dc, context);
> + }

That looks like a step into the right directly, but please re-read the code:

if (update_type != UPDATE_TYPE_FAST) {

     if (update_type != UPDATE_TYPE_FAST)
     
}

That's certainly still not correct.

Regards,
Christian.


>   
>   /* Since phantom pipe programming is moved to 
> post_unlock_program_front_end,
>* move the SubVP lock to after the phantom pipes have been setup

Re: [PATCH] drm/ttm: update bulk move object of ghost BO

[Christian König]

Am 01.09.22 um 13:11 schrieb Christian König:

Am 01.09.22 um 11:29 schrieb ZhenGuo Yin:

[Why]
Ghost BO is released with non-empty bulk move object. There is a
warning trace:
WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 
ttm_bo_release+0x2e1/0x2f0 [amdttm]

Call Trace:
   amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
   amdttm_bo_put+0x28/0x30 [amdttm]
   amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
   amdgpu_bo_move+0x1a8/0x770 [amdgpu]
   ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
   amdttm_bo_validate+0xbf/0x100 [amdttm]

[How]
The resource of ghost BO should be moved to LRU directly, instead of
using bulk move. The bulk move object of ghost BO should set to NULL
before function ttm_bo_move_to_lru_tail_unlocked.

Fixed:·5b951e487fd6bf5f·("drm/ttm:·fix·bulk·move·handling·v2")
Signed-off-by: ZhenGuo Yin 


Good catch, but the fix is not 100% correct. Please rather just NULL 
the member while initializing the BO structure.


E.g. something like this:

 
 fbo->base.pin_count = 0;
+fbo->base.bulk_move= NULL;
 if (bo->type != ttm_bo_type_sg)
 


On the other hand thinking about it that won't work either.

You need to set bulk_move to NULL manually in an else clauses or 
something like this.


Regards,
Christian.



Thanks,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c

index 1cbfb00c1d65..a90bbbd91910 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -238,6 +238,7 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,

    if (fbo->base.resource) {
  ttm_resource_set_bo(fbo->base.resource, >base);
+    ttm_bo_set_bulk_move(>base, NULL);
  bo->resource = NULL;
  }

Re: [PATCH] drm/ttm: update bulk move object of ghost BO

[Christian König]

Am 01.09.22 um 11:29 schrieb ZhenGuo Yin:

[Why]
Ghost BO is released with non-empty bulk move object. There is a
warning trace:
WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 ttm_bo_release+0x2e1/0x2f0 
[amdttm]
Call Trace:
   amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
   amdttm_bo_put+0x28/0x30 [amdttm]
   amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
   amdgpu_bo_move+0x1a8/0x770 [amdgpu]
   ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
   amdttm_bo_validate+0xbf/0x100 [amdttm]

[How]
The resource of ghost BO should be moved to LRU directly, instead of
using bulk move. The bulk move object of ghost BO should set to NULL
before function ttm_bo_move_to_lru_tail_unlocked.

Fixed:·5b951e487fd6bf5f·("drm/ttm:·fix·bulk·move·handling·v2")
Signed-off-by: ZhenGuo Yin 


Good catch, but the fix is not 100% correct. Please rather just NULL the 
member while initializing the BO structure.


E.g. something like this:

 
 fbo->base.pin_count = 0;
+fbo->base.bulk_move= NULL;
 if (bo->type != ttm_bo_type_sg)
 

Thanks,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1cbfb00c1d65..a90bbbd91910 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -238,6 +238,7 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
  
  	if (fbo->base.resource) {

ttm_resource_set_bo(fbo->base.resource, >base);
+   ttm_bo_set_bulk_move(>base, NULL);
bo->resource = NULL;
}
  

Re: [PATCH] drm/display: guard if clause

[Christian König]

Well please adjust the subject line, that should read something like 
"drm/amd/display:..." or "drm/amdgpu:...".


Am 01.09.22 um 11:11 schrieb Asher Song:

To eliminate the following compiling error, guard if clause.

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 
'commit_planes_for_stream':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3521:2: error: this 'if' 
clause does not guard... [-Werror=misleading-indentation]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3523:3: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
'if'
if (update_type != UPDATE_TYPE_FAST)
^~

Signed-off-by: Asher Song 
---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..66072ac1bb4f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3505,11 +3505,12 @@ static void commit_planes_for_stream(struct dc *dc,
top_pipe_to_program->stream_res.tg);
}
  
-	if (update_type != UPDATE_TYPE_FAST)

+   if (update_type != UPDATE_TYPE_FAST){
dc->hwss.post_unlock_program_front_end(dc, context);
if (update_type != UPDATE_TYPE_FAST)
if (dc->hwss.commit_subvp_config)
dc->hwss.commit_subvp_config(dc, context);
+   }


That looks like a step into the right directly, but please re-read the code:

if (update_type != UPDATE_TYPE_FAST) {

    if (update_type != UPDATE_TYPE_FAST)
    
}

That's certainly still not correct.

Regards,
Christian.


  
  	/* Since phantom pipe programming is moved to post_unlock_program_front_end,

 * move the SubVP lock to after the phantom pipes have been setup

Re: [PATCH] drm/ttm: update bulk move object of ghost BO

[JingWen Chen]

Acked-by: Jingwen Chen 

still need confirmation from Christian

On 9/1/22 5:29 PM, ZhenGuo Yin wrote:
> [Why]
> Ghost BO is released with non-empty bulk move object. There is a
> warning trace:
> WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 ttm_bo_release+0x2e1/0x2f0 
> [amdttm]
> Call Trace:
>   amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
>   amdttm_bo_put+0x28/0x30 [amdttm]
>   amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
>   amdgpu_bo_move+0x1a8/0x770 [amdgpu]
>   ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
>   amdttm_bo_validate+0xbf/0x100 [amdttm]
>
> [How]
> The resource of ghost BO should be moved to LRU directly, instead of
> using bulk move. The bulk move object of ghost BO should set to NULL
> before function ttm_bo_move_to_lru_tail_unlocked.
>
> Fixed:·5b951e487fd6bf5f·("drm/ttm:·fix·bulk·move·handling·v2")
> Signed-off-by: ZhenGuo Yin 
> ---
>  drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 1cbfb00c1d65..a90bbbd91910 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -238,6 +238,7 @@ static int ttm_buffer_object_transfer(struct 
> ttm_buffer_object *bo,
>  
>   if (fbo->base.resource) {
>   ttm_resource_set_bo(fbo->base.resource, >base);
> + ttm_bo_set_bulk_move(>base, NULL);
>   bo->resource = NULL;
>   }
>  

[PATCH] drm/ttm: update bulk move object of ghost BO

[ZhenGuo Yin]

[Why]
Ghost BO is released with non-empty bulk move object. There is a
warning trace:
WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 ttm_bo_release+0x2e1/0x2f0 
[amdttm]
Call Trace:
  amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
  amdttm_bo_put+0x28/0x30 [amdttm]
  amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
  amdgpu_bo_move+0x1a8/0x770 [amdgpu]
  ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
  amdttm_bo_validate+0xbf/0x100 [amdttm]

[How]
The resource of ghost BO should be moved to LRU directly, instead of
using bulk move. The bulk move object of ghost BO should set to NULL
before function ttm_bo_move_to_lru_tail_unlocked.

Fixed:·5b951e487fd6bf5f·("drm/ttm:·fix·bulk·move·handling·v2")
Signed-off-by: ZhenGuo Yin 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1cbfb00c1d65..a90bbbd91910 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -238,6 +238,7 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
 
if (fbo->base.resource) {
ttm_resource_set_bo(fbo->base.resource, >base);
+   ttm_bo_set_bulk_move(>base, NULL);
bo->resource = NULL;
}
 
-- 
2.35.1

[PATCH] drm/display: guard if clause

[Asher Song]

To eliminate the following compiling error, guard if clause.

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 
'commit_planes_for_stream':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3521:2: error: this 'if' 
clause does not guard... [-Werror=misleading-indentation]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3523:3: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
'if'
if (update_type != UPDATE_TYPE_FAST)
^~

Signed-off-by: Asher Song 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..66072ac1bb4f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3505,11 +3505,12 @@ static void commit_planes_for_stream(struct dc *dc,
top_pipe_to_program->stream_res.tg);
}
 
-   if (update_type != UPDATE_TYPE_FAST)
+   if (update_type != UPDATE_TYPE_FAST){
dc->hwss.post_unlock_program_front_end(dc, context);
if (update_type != UPDATE_TYPE_FAST)
if (dc->hwss.commit_subvp_config)
dc->hwss.commit_subvp_config(dc, context);
+   }
 
/* Since phantom pipe programming is moved to 
post_unlock_program_front_end,
 * move the SubVP lock to after the phantom pipes have been setup
-- 
2.25.1

[PATCH V2] drm/amdgpu: TA unload messages are not actually sent to psp when amdgpu is uninstalled

[YiPeng Chai]

V1:
  The psp_cmd_submit_buf function is called by psp_hw_fini to send
TA unload messages to psp to terminate ras, asd and tmr. But when
amdgpu is uninstalled, drm_dev_unplug is called earlier than
psp_hw_fini in amdgpu_pci_remove, the calling order as follows:
static void amdgpu_pci_remove(struct pci_dev *pdev) {
drm_dev_unplug
..
amdgpu_driver_unload_kms->amdgpu_device_fini_hw->...
->.hw_fini->psp_hw_fini->...
->psp_ta_unload->psp_cmd_submit_buf
..
}
The program will return when calling drm_dev_enter in psp_cmd_submit_buf.

So the call to drm_dev_enter in psp_cmd_submit_buf should be
removed, so that the TA unload messages can be sent to the psp
when amdgpu is uninstalled.

V2:
1. Restore psp_cmd_submit_buf to its original code.
2. Move drm_dev_unplug call after amdgpu_driver_unload_kms in
   amdgpu_pci_remove.
3. Since amdgpu_device_fini_hw is called by amdgpu_driver_unload_kms,
   remove the unplug check to release device mmio resource in
   amdgpu_device_fini_hw before calling drm_dev_unplug.

Signed-off-by: YiPeng Chai 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index afaa1056e039..62b26f0e37b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3969,8 +3969,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
 
amdgpu_gart_dummy_page_fini(adev);
 
-   if (drm_dev_is_unplugged(adev_to_drm(adev)))
-   amdgpu_device_unmap_mmio(adev);
+   amdgpu_device_unmap_mmio(adev);
 
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index de7144b06e93..728a0933ea6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2181,8 +2181,6 @@ amdgpu_pci_remove(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
struct amdgpu_device *adev = drm_to_adev(dev);
 
-   drm_dev_unplug(dev);
-
if (adev->pm.rpm_mode != AMDGPU_RUNPM_NONE) {
pm_runtime_get_sync(dev->dev);
pm_runtime_forbid(dev->dev);
@@ -2190,6 +2188,8 @@ amdgpu_pci_remove(struct pci_dev *pdev)
 
amdgpu_driver_unload_kms(dev);
 
+   drm_dev_unplug(dev);
+
/*
 * Flush any in flight DMA operations from device.
 * Clear the Bus Master Enable bit and then wait on the PCIe Device
-- 
2.25.1

Re: [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention

[Christian König]

Hi Dmitry,

I've gone over this multiple times now and while it is still possible 
that we missed something I think that this should land now.


The whole topic is just to complicated that we can 100% sure guarantee 
that there isn't anything wrong with the locking, but lockdep and driver 
testing should allow us to quickly find remaining issues.


Do you have commit rights to drm-misc-next or should I push it?

Thanks,
Christian.

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

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
in accordance to the locking specification. This allows us to utilize
reservation lock more broadly around kernel without fearing of a potential
deadlocks.

This patchset passes all i915 selftests. It was also tested using VirtIO,
Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases
of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate),
which covers majority of kernel drivers since rest of the drivers share
same or similar code paths.

Changelog:

v4: - Added dma_buf_mmap() to the "locking convention" documentation,
   which was missed by accident in v3.

 - Added acks from Christian König, Tomasz Figa and Hans Verkuil that
   they gave to couple v3 patches.

 - Dropped the "_unlocked" postfix from function names that don't have
   the locked variant, as was requested by Christian König.

 - Factored out the per-driver preparations into separate patches
   to ease reviewing of the changes, which is now doable without the
   global dma-buf functions renaming.

 - Factored out the dynamic locking convention enforcements into separate
   patches which add the final dma_resv_assert_held(dmabuf->resv) to the
   dma-buf API functions.

v3: - Factored out dma_buf_mmap_unlocked() and attachment functions
   into aseparate patches, like was suggested by Christian König.

 - Corrected and factored out dma-buf locking documentation into
   a separate patch, like was suggested by Christian König.

 - Intel driver dropped the reservation locking fews days ago from
   its BO-release code path, but we need that locking for the imported
   GEMs because in the end that code path unmaps the imported GEM.
   So I added back the locking needed by the imported GEMs, updating
   the "dma-buf attachment locking specification" patch appropriately.

 - Tested Nouveau+Intel dma-buf import/export combo.

 - Tested udmabuf import to i915/Nouveau/AMDGPU.

 - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed
   to switch to locked dma-buf vmapping in the drm/gem: Take reservation
   lock for vmap/vunmap operations" patch. In a result invalidated the
   Christian's r-b that he gave to v2.

 - Added locked dma-buf vmap/vunmap functions that are needed for fixing
   vmappping of Etnaviv, Panfrost and Lima drivers mentioned above.
   I actually had this change stashed for the drm-shmem shrinker patchset,
   but then realized that it's already needed by the dma-buf patches.
   Also improved my tests to better cover these code paths.

v2: - Changed locking specification to avoid problems with a cross-driver
   ww locking, like was suggested by Christian König. Now the attach/detach
   callbacks are invoked without the held lock and exporter should take the
   lock.

 - Added "locking convention" documentation that explains which dma-buf
   functions and callbacks are locked/unlocked for importers and exporters,
   which was requested by Christian König.

 - Added ack from Tomasz Figa to the V4L patches that he gave to v1.

Dmitry Osipenko (21):
   dma-buf: Add unlocked variant of vmapping functions
   dma-buf: Add unlocked variant of attachment-mapping functions
   drm/gem: Take reservation lock for vmap/vunmap operations
   drm/prime: Prepare to dynamic dma-buf locking specification
   drm/armada: Prepare to dynamic dma-buf locking specification
   drm/i915: Prepare to dynamic dma-buf locking specification
   drm/omapdrm: Prepare to dynamic dma-buf locking specification
   drm/tegra: Prepare to dynamic dma-buf locking specification
   drm/etnaviv: Prepare to dynamic dma-buf locking specification
   RDMA/umem: Prepare to dynamic dma-buf locking specification
   misc: fastrpc: Prepare to dynamic dma-buf locking specification
   xen/gntdev: Prepare to dynamic dma-buf locking specification
   media: videobuf2: Prepare to dynamic dma-buf locking specification
   media: tegra-vde: Prepare to dynamic dma-buf locking specification
   dma-buf: Move dma_buf_vmap() to dynamic locking specification
   dma-buf: Move dma_buf_attach() to dynamic locking specification
   dma-buf: Move dma_buf_map_attachment() to dynamic locking
 specification
   

Re: [PATCH v4 21/21] dma-buf: Remove obsoleted internal lock

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

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.

Acked-by: Christian König 
Signed-off-by: Dmitry Osipenko 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-buf.c | 14 --
  include/linux/dma-buf.h   |  9 -
  2 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 97ce884fad76..772fdd9eeed8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -656,7 +656,6 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
  
  	dmabuf->file = file;
  
-	mutex_init(>lock);

INIT_LIST_HEAD(>attachments);
  
  	mutex_lock(_list.lock);

@@ -1502,7 +1501,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
  int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
  {
struct iosys_map ptr;
-   int ret = 0;
+   int ret;
  
  	iosys_map_clear(map);
  
@@ -1514,28 +1513,25 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)

if (!dmabuf->ops->vmap)
return -EINVAL;
  
-	mutex_lock(>lock);

if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(>vmap_ptr));
*map = dmabuf->vmap_ptr;
-   goto out_unlock;
+   return 0;
}
  
  	BUG_ON(iosys_map_is_set(>vmap_ptr));
  
  	ret = dmabuf->ops->vmap(dmabuf, );

if (WARN_ON_ONCE(ret))
-   goto out_unlock;
+   return ret;
  
  	dmabuf->vmap_ptr = ptr;

dmabuf->vmapping_counter = 1;
  
  	*map = dmabuf->vmap_ptr;
  
-out_unlock:

-   mutex_unlock(>lock);
-   return ret;
+   return 0;
  }
  EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
  
@@ -1577,13 +1573,11 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map)

BUG_ON(dmabuf->vmapping_counter == 0);
BUG_ON(!iosys_map_is_equal(>vmap_ptr, map));
  
-	mutex_lock(>lock);

if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(>vmap_ptr);
}
-   mutex_unlock(>lock);
  }
  EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
  
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h

index f11b5bbc2f37..6fa8d4e29719 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
  
-	/**

-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
-   struct mutex lock;
-
/**
 * @vmapping_counter:
 *

Re: [PATCH v4 20/21] media: videobuf2: Stop using internal dma-buf lock

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

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.

Acked-by: Tomasz Figa 
Acked-by: Hans Verkuil 
Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
  drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +--
  drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +--
  3 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 79f4d8301fbb..555bd40fa472 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -382,18 +382,12 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
  {
struct vb2_dc_attachment *attach = db_attach->priv;
-   /* stealing dmabuf mutex to serialize map/unmap operations */
-   struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
  
-	mutex_lock(lock);

-
sgt = >sgt;
/* return previously mapped sg table */
-   if (attach->dma_dir == dma_dir) {
-   mutex_unlock(lock);
+   if (attach->dma_dir == dma_dir)
return sgt;
-   }
  
  	/* release any previous cache */

if (attach->dma_dir != DMA_NONE) {
@@ -409,14 +403,11 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
DMA_ATTR_SKIP_CPU_SYNC)) {
pr_err("failed to map scatterlist\n");
-   mutex_unlock(lock);
return ERR_PTR(-EIO);
}
  
  	attach->dma_dir = dma_dir;
  
-	mutex_unlock(lock);

-
return sgt;
  }
  
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c

index 36ecdea8d707..36981a5b5c53 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -424,18 +424,12 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
  {
struct vb2_dma_sg_attachment *attach = db_attach->priv;
-   /* stealing dmabuf mutex to serialize map/unmap operations */
-   struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
  
-	mutex_lock(lock);

-
sgt = >sgt;
/* return previously mapped sg table */
-   if (attach->dma_dir == dma_dir) {
-   mutex_unlock(lock);
+   if (attach->dma_dir == dma_dir)
return sgt;
-   }
  
  	/* release any previous cache */

if (attach->dma_dir != DMA_NONE) {
@@ -446,14 +440,11 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
-   mutex_unlock(lock);
return ERR_PTR(-EIO);
}
  
  	attach->dma_dir = dma_dir;
  
-	mutex_unlock(lock);

-
return sgt;
  }
  
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c b/drivers/media/common/videobuf2/videobuf2-vmalloc.c

index 7831bf545874..41db707e43a4 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -267,18 +267,12 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
  {
struct vb2_vmalloc_attachment *attach = db_attach->priv;
-   /* stealing dmabuf mutex to serialize map/unmap operations */
-   struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
  
-	mutex_lock(lock);

-
sgt = >sgt;
/* return previously mapped sg table */
-   if (attach->dma_dir == dma_dir) {
-   mutex_unlock(lock);
+   if (attach->dma_dir == dma_dir)
return sgt;
-   }
  
  	/* release any previous cache */

if (attach->dma_dir != DMA_NONE) {
@@ -289,14 +283,11 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
-   mutex_unlock(lock);
return ERR_PTR(-EIO);
}
  
  	attach->dma_dir = dma_dir;
  
-	mutex_unlock(lock);

-
return sgt;
  }
  

[PATCH] drm/amdkfd: Match GC 11.0.1 cache info to yellow carp

[Yifan Zhang]

Current discovery table doesn't have cache info for GC 11.0.1, thus
can't be parsed like other GC 11, this patch to match GC 11.0.1
cache info to yellow carp

Signed-off-by: Yifan Zhang 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 24b414cff3ec..1c500bfb0b28 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -1516,11 +1516,11 @@ static int kfd_fill_gpu_cache_info(struct kfd_dev *kdev,
case IP_VERSION(10, 3, 3):
case IP_VERSION(10, 3, 6): /* TODO: Double check these on 
production silicon */
case IP_VERSION(10, 3, 7): /* TODO: Double check these on 
production silicon */
+   case IP_VERSION(11, 0, 1): /* TODO: Double check these on 
production silicon */
pcache_info = yellow_carp_cache_info;
num_of_cache_types = ARRAY_SIZE(yellow_carp_cache_info);
break;
case IP_VERSION(11, 0, 0):
-   case IP_VERSION(11, 0, 1):
case IP_VERSION(11, 0, 2):
case IP_VERSION(11, 0, 3):
pcache_info = cache_info;
-- 
2.37.1

Re: [PATCH v4 19/21] dma-buf: Document dynamic locking convention

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Add documentation for the dynamic locking convention. The documentation
tells dma-buf API users when they should take the reservation lock and
when not.

Signed-off-by: Dmitry Osipenko 


Reviewed-by: Christian König 


---
  Documentation/driver-api/dma-buf.rst |  6 +++
  drivers/dma-buf/dma-buf.c| 64 
  2 files changed, 70 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index 36a76cbe9095..622b8156d212 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -119,6 +119,12 @@ DMA Buffer ioctls
  
  .. kernel-doc:: include/uapi/linux/dma-buf.h
  
+DMA-BUF locking convention

+~
+
+.. kernel-doc:: drivers/dma-buf/dma-buf.c
+   :doc: locking convention
+
  Kernel Functions and Structures Reference
  ~
  
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c

index d9130486cb8f..97ce884fad76 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -794,6 +794,70 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
return sg_table;
  }
  
+/**

+ * DOC: locking convention
+ *
+ * In order to avoid deadlock situations between dma-buf exports and importers,
+ * all dma-buf API users must follow the common dma-buf locking convention.
+ *
+ * Convention for importers
+ *
+ * 1. Importers must hold the dma-buf reservation lock when calling these
+ *functions:
+ *
+ * - dma_buf_pin()
+ * - dma_buf_unpin()
+ * - dma_buf_map_attachment()
+ * - dma_buf_unmap_attachment()
+ * - dma_buf_vmap()
+ * - dma_buf_vunmap()
+ *
+ * 2. Importers must not hold the dma-buf reservation lock when calling these
+ *functions:
+ *
+ * - dma_buf_attach()
+ * - dma_buf_dynamic_attach()
+ * - dma_buf_detach()
+ * - dma_buf_export(
+ * - dma_buf_fd()
+ * - dma_buf_get()
+ * - dma_buf_put()
+ * - dma_buf_mmap()
+ * - dma_buf_begin_cpu_access()
+ * - dma_buf_end_cpu_access()
+ * - dma_buf_map_attachment_unlocked()
+ * - dma_buf_unmap_attachment_unlocked()
+ * - dma_buf_vmap_unlocked()
+ * - dma_buf_vunmap_unlocked()
+ *
+ * Convention for exporters
+ *
+ * 1. These _buf_ops callbacks are invoked with unlocked dma-buf
+ *reservation and exporter can take the lock:
+ *
+ * - _buf_ops.attach()
+ * - _buf_ops.detach()
+ * - _buf_ops.release()
+ * - _buf_ops.begin_cpu_access()
+ * - _buf_ops.end_cpu_access()
+ *
+ * 2. These _buf_ops callbacks are invoked with locked dma-buf
+ *reservation and exporter can't take the lock:
+ *
+ * - _buf_ops.pin()
+ * - _buf_ops.unpin()
+ * - _buf_ops.map_dma_buf()
+ * - _buf_ops.unmap_dma_buf()
+ * - _buf_ops.mmap()
+ * - _buf_ops.vmap()
+ * - _buf_ops.vunmap()
+ *
+ * 3. Exporters must hold the dma-buf reservation lock when calling these
+ *functions:
+ *
+ * - dma_buf_move_notify()
+ */
+
  /**
   * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list
   * @dmabuf:   [in]buffer to attach device to.

Re: [PATCH v4 17/21] dma-buf: Move dma_buf_map_attachment() to dynamic locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Move dma-buf attachment mapping functions to the dynamic locking
specification by asserting that the reservation lock is held.

Signed-off-by: Dmitry Osipenko 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-buf.c | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 073942bf5ae9..8e928fe6e8df 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1037,8 +1037,7 @@ struct sg_table *dma_buf_map_attachment(struct 
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
  
-	if (dma_buf_attachment_is_dynamic(attach))

-   dma_resv_assert_held(attach->dmabuf->resv);
+   dma_resv_assert_held(attach->dmabuf->resv);
  
  	if (attach->sgt) {

/*
@@ -1053,7 +1052,6 @@ struct sg_table *dma_buf_map_attachment(struct 
dma_buf_attachment *attach,
}
  
  	if (dma_buf_is_dynamic(attach->dmabuf)) {

-   dma_resv_assert_held(attach->dmabuf->resv);
if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
r = attach->dmabuf->ops->pin(attach);
if (r)
@@ -1142,15 +1140,11 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
  
-	if (dma_buf_attachment_is_dynamic(attach))

-   dma_resv_assert_held(attach->dmabuf->resv);
+   dma_resv_assert_held(attach->dmabuf->resv);
  
  	if (attach->sgt == sg_table)

return;
  
-	if (dma_buf_is_dynamic(attach->dmabuf))

-   dma_resv_assert_held(attach->dmabuf->resv);
-
__unmap_dma_buf(attach, sg_table, direction);
  
  	if (dma_buf_is_dynamic(attach->dmabuf) &&

Re: [PATCH v4 16/21] dma-buf: Move dma_buf_attach() to dynamic locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Move dma-buf attachment API functions to the dynamic locking specification
by taking the reservation lock around the mapping operations. The strict
locking convention prevents deadlock situations for dma-buf importers and
exporters.

Signed-off-by: Dmitry Osipenko 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-buf.c | 20 
  1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ceea4839c641..073942bf5ae9 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -858,8 +858,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
  
+		dma_resv_lock(attach->dmabuf->resv, NULL);

if (dma_buf_is_dynamic(attach->dmabuf)) {
-   dma_resv_lock(attach->dmabuf->resv, NULL);
ret = dmabuf->ops->pin(attach);
if (ret)
goto err_unlock;
@@ -872,8 +872,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_unlock(attach->dmabuf->resv);
+   dma_resv_unlock(attach->dmabuf->resv);
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
@@ -889,8 +888,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
dmabuf->ops->unpin(attach);
  
  err_unlock:

-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_unlock(attach->dmabuf->resv);
+   dma_resv_unlock(attach->dmabuf->resv);
  
  	dma_buf_detach(dmabuf, attach);

return ERR_PTR(ret);
@@ -936,21 +934,19 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
dma_buf_attachment *attach)
if (WARN_ON(!dmabuf || !attach))
return;
  
+	dma_resv_lock(attach->dmabuf->resv, NULL);

+
if (attach->sgt) {
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_lock(attach->dmabuf->resv, NULL);
  
  		__unmap_dma_buf(attach, attach->sgt, attach->dir);
  
-		if (dma_buf_is_dynamic(attach->dmabuf)) {

+   if (dma_buf_is_dynamic(attach->dmabuf))
dmabuf->ops->unpin(attach);
-   dma_resv_unlock(attach->dmabuf->resv);
-   }
}
-
-   dma_resv_lock(dmabuf->resv, NULL);
list_del(>node);
+
dma_resv_unlock(dmabuf->resv);
+
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
  

Re: [PATCH v4 14/21] media: tegra-vde: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare Tegra video decoder driver to the common dynamic dma-buf
locking convention by starting to use the unlocked versions of dma-buf
API functions.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c 
b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
index 69c346148070..1c5b94989aec 100644
--- a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
+++ b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
@@ -38,7 +38,7 @@ static void tegra_vde_release_entry(struct 
tegra_vde_cache_entry *entry)
if (entry->vde->domain)
tegra_vde_iommu_unmap(entry->vde, entry->iova);
  
-	dma_buf_unmap_attachment(entry->a, entry->sgt, entry->dma_dir);

+   dma_buf_unmap_attachment_unlocked(entry->a, entry->sgt, entry->dma_dir);
dma_buf_detach(dmabuf, entry->a);
dma_buf_put(dmabuf);
  
@@ -102,7 +102,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,

goto err_unlock;
}
  
-	sgt = dma_buf_map_attachment(attachment, dma_dir);

+   sgt = dma_buf_map_attachment_unlocked(attachment, dma_dir);
if (IS_ERR(sgt)) {
dev_err(dev, "Failed to get dmabufs sg_table\n");
err = PTR_ERR(sgt);
@@ -152,7 +152,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,
  err_free:
kfree(entry);
  err_unmap:
-   dma_buf_unmap_attachment(attachment, sgt, dma_dir);
+   dma_buf_unmap_attachment_unlocked(attachment, sgt, dma_dir);
  err_detach:
dma_buf_detach(dmabuf, attachment);
  err_unlock:

Re: [PATCH v4 13/21] media: videobuf2: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare V4L2 memory allocators to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.

Acked-by: Tomasz Figa 
Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 ++-
  drivers/media/common/videobuf2/videobuf2-dma-sg.c |  8 
  drivers/media/common/videobuf2/videobuf2-vmalloc.c|  6 +++---
  3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 678b359717c4..79f4d8301fbb 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -101,7 +101,7 @@ static void *vb2_dc_vaddr(struct vb2_buffer *vb, void 
*buf_priv)
if (buf->db_attach) {
struct iosys_map map;
  
-		if (!dma_buf_vmap(buf->db_attach->dmabuf, ))

+   if (!dma_buf_vmap_unlocked(buf->db_attach->dmabuf, ))
buf->vaddr = map.vaddr;
  
  		return buf->vaddr;

@@ -711,7 +711,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
}
  
  	/* get the associated scatterlist for this buffer */

-   sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
+   sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
if (IS_ERR(sgt)) {
pr_err("Error getting dmabuf scatterlist\n");
return -EINVAL;
@@ -722,7 +722,8 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
if (contig_size < buf->size) {
pr_err("contiguous chunk is too small %lu/%lu\n",
   contig_size, buf->size);
-   dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+   dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt,
+ buf->dma_dir);
return -EFAULT;
}
  
@@ -750,10 +751,10 @@ static void vb2_dc_unmap_dmabuf(void *mem_priv)

}
  
  	if (buf->vaddr) {

-   dma_buf_vunmap(buf->db_attach->dmabuf, );
+   dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, );
buf->vaddr = NULL;
}
-   dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+   dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
  
  	buf->dma_addr = 0;

buf->dma_sgt = NULL;
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index fa69158a65b1..36ecdea8d707 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -309,7 +309,7 @@ static void *vb2_dma_sg_vaddr(struct vb2_buffer *vb, void 
*buf_priv)
  
  	if (!buf->vaddr) {

if (buf->db_attach) {
-   ret = dma_buf_vmap(buf->db_attach->dmabuf, );
+   ret = dma_buf_vmap_unlocked(buf->db_attach->dmabuf, 
);
buf->vaddr = ret ? NULL : map.vaddr;
} else {
buf->vaddr = vm_map_ram(buf->pages, buf->num_pages, -1);
@@ -565,7 +565,7 @@ static int vb2_dma_sg_map_dmabuf(void *mem_priv)
}
  
  	/* get the associated scatterlist for this buffer */

-   sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
+   sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
if (IS_ERR(sgt)) {
pr_err("Error getting dmabuf scatterlist\n");
return -EINVAL;
@@ -594,10 +594,10 @@ static void vb2_dma_sg_unmap_dmabuf(void *mem_priv)
}
  
  	if (buf->vaddr) {

-   dma_buf_vunmap(buf->db_attach->dmabuf, );
+   dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, );
buf->vaddr = NULL;
}
-   dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+   dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
  
  	buf->dma_sgt = NULL;

  }
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c 
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 948152f1596b..7831bf545874 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -376,7 +376,7 @@ static int vb2_vmalloc_map_dmabuf(void *mem_priv)
struct iosys_map map;
int ret;
  
-	ret = dma_buf_vmap(buf->dbuf, );

+   ret = dma_buf_vmap_unlocked(buf->dbuf, );
if (ret)
return -EFAULT;
buf->vaddr = map.vaddr;
@@ -389,7 +389,7 @@ static void vb2_vmalloc_unmap_dmabuf(void *mem_priv)
struct vb2_vmalloc_buf *buf = mem_priv;
struct iosys_map map = IOSYS_MAP_INIT_VADDR(buf->vaddr);
  
-	dma_buf_vunmap(buf->dbuf, );

+   dma_buf_vunmap_unlocked(buf->dbuf, );
buf->vaddr = NULL;
  

Re: [PATCH v4 12/21] xen/gntdev: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare gntdev driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/xen/gntdev-dmabuf.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 940e5e9e8a54..4440e626b797 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -600,7 +600,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct 
device *dev,
  
  	gntdev_dmabuf->u.imp.attach = attach;
  
-	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);

+   sgt = dma_buf_map_attachment_unlocked(attach, DMA_BIDIRECTIONAL);
if (IS_ERR(sgt)) {
ret = ERR_CAST(sgt);
goto fail_detach;
@@ -658,7 +658,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct 
device *dev,
  fail_end_access:
dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs, count);
  fail_unmap:
-   dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+   dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_BIDIRECTIONAL);
  fail_detach:
dma_buf_detach(dma_buf, attach);
  fail_free_obj:
@@ -708,8 +708,8 @@ static int dmabuf_imp_release(struct gntdev_dmabuf_priv 
*priv, u32 fd)
attach = gntdev_dmabuf->u.imp.attach;
  
  	if (gntdev_dmabuf->u.imp.sgt)

-   dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
-DMA_BIDIRECTIONAL);
+   dma_buf_unmap_attachment_unlocked(attach, 
gntdev_dmabuf->u.imp.sgt,
+ DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
dma_buf_put(dma_buf);

Re: [PATCH v4 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/misc/fastrpc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 93ebd174d848..6fcfb2e9f7a7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -310,8 +310,8 @@ static void fastrpc_free_map(struct kref *ref)
return;
}
}
-   dma_buf_unmap_attachment(map->attach, map->table,
-DMA_BIDIRECTIONAL);
+   dma_buf_unmap_attachment_unlocked(map->attach, map->table,
+ DMA_BIDIRECTIONAL);
dma_buf_detach(map->buf, map->attach);
dma_buf_put(map->buf);
}
@@ -726,7 +726,7 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int 
fd,
goto attach_err;
}
  
-	map->table = dma_buf_map_attachment(map->attach, DMA_BIDIRECTIONAL);

+   map->table = dma_buf_map_attachment_unlocked(map->attach, 
DMA_BIDIRECTIONAL);
if (IS_ERR(map->table)) {
err = PTR_ERR(map->table);
goto map_err;

Re: [PATCH v4 10/21] RDMA/umem: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare InfiniBand drivers to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/infiniband/core/umem_dmabuf.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/core/umem_dmabuf.c 
b/drivers/infiniband/core/umem_dmabuf.c
index 04c04e6d24c3..43b26bc12288 100644
--- a/drivers/infiniband/core/umem_dmabuf.c
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -26,7 +26,8 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf 
*umem_dmabuf)
if (umem_dmabuf->sgt)
goto wait_fence;
  
-	sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL);

+   sgt = dma_buf_map_attachment_unlocked(umem_dmabuf->attach,
+ DMA_BIDIRECTIONAL);
if (IS_ERR(sgt))
return PTR_ERR(sgt);
  
@@ -102,8 +103,8 @@ void ib_umem_dmabuf_unmap_pages(struct ib_umem_dmabuf *umem_dmabuf)

umem_dmabuf->last_sg_trim = 0;
}
  
-	dma_buf_unmap_attachment(umem_dmabuf->attach, umem_dmabuf->sgt,

-DMA_BIDIRECTIONAL);
+   dma_buf_unmap_attachment_unlocked(umem_dmabuf->attach, umem_dmabuf->sgt,
+ DMA_BIDIRECTIONAL);
  
  	umem_dmabuf->sgt = NULL;

  }

Re: [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare Etnaviv driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.

Signed-off-by: Dmitry Osipenko 


Interesting, where is the matching vmap()?

Anyway, this patch is Acked-by: Christian König 


---
  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 3fa2da149639..7031db145a77 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -65,7 +65,7 @@ static void etnaviv_gem_prime_release(struct 
etnaviv_gem_object *etnaviv_obj)
struct iosys_map map = IOSYS_MAP_INIT_VADDR(etnaviv_obj->vaddr);
  
  	if (etnaviv_obj->vaddr)

-   dma_buf_vunmap(etnaviv_obj->base.import_attach->dmabuf, );
+   dma_buf_vunmap_unlocked(etnaviv_obj->base.import_attach->dmabuf, 
);
  
  	/* Don't drop the pages for imported dmabuf, as they are not

 * ours, just free the array we allocated:

Re: [PATCH v4 08/21] drm/tegra: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare Tegra DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/gpu/drm/tegra/gem.c | 17 +
  1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 81991090adcc..b09b8ab40ae4 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -84,7 +84,7 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device 
*dev, struct host1x_
goto free;
}
  
-		map->sgt = dma_buf_map_attachment(map->attach, direction);

+   map->sgt = dma_buf_map_attachment_unlocked(map->attach, 
direction);
if (IS_ERR(map->sgt)) {
dma_buf_detach(buf, map->attach);
err = PTR_ERR(map->sgt);
@@ -160,7 +160,8 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device 
*dev, struct host1x_
  static void tegra_bo_unpin(struct host1x_bo_mapping *map)
  {
if (map->attach) {
-   dma_buf_unmap_attachment(map->attach, map->sgt, map->direction);
+   dma_buf_unmap_attachment_unlocked(map->attach, map->sgt,
+ map->direction);
dma_buf_detach(map->attach->dmabuf, map->attach);
} else {
dma_unmap_sgtable(map->dev, map->sgt, map->direction, 0);
@@ -181,7 +182,7 @@ static void *tegra_bo_mmap(struct host1x_bo *bo)
if (obj->vaddr) {
return obj->vaddr;
} else if (obj->gem.import_attach) {
-   ret = dma_buf_vmap(obj->gem.import_attach->dmabuf, );
+   ret = dma_buf_vmap_unlocked(obj->gem.import_attach->dmabuf, 
);
return ret ? NULL : map.vaddr;
} else {
return vmap(obj->pages, obj->num_pages, VM_MAP,
@@ -197,7 +198,7 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void 
*addr)
if (obj->vaddr)
return;
else if (obj->gem.import_attach)
-   dma_buf_vunmap(obj->gem.import_attach->dmabuf, );
+   dma_buf_vunmap_unlocked(obj->gem.import_attach->dmabuf, );
else
vunmap(addr);
  }
@@ -461,7 +462,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device 
*drm,
  
  	get_dma_buf(buf);
  
-	bo->sgt = dma_buf_map_attachment(attach, DMA_TO_DEVICE);

+   bo->sgt = dma_buf_map_attachment_unlocked(attach, DMA_TO_DEVICE);
if (IS_ERR(bo->sgt)) {
err = PTR_ERR(bo->sgt);
goto detach;
@@ -479,7 +480,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device 
*drm,
  
  detach:

if (!IS_ERR_OR_NULL(bo->sgt))
-   dma_buf_unmap_attachment(attach, bo->sgt, DMA_TO_DEVICE);
+   dma_buf_unmap_attachment_unlocked(attach, bo->sgt, 
DMA_TO_DEVICE);
  
  	dma_buf_detach(buf, attach);

dma_buf_put(buf);
@@ -508,8 +509,8 @@ void tegra_bo_free_object(struct drm_gem_object *gem)
tegra_bo_iommu_unmap(tegra, bo);
  
  	if (gem->import_attach) {

-   dma_buf_unmap_attachment(gem->import_attach, bo->sgt,
-DMA_TO_DEVICE);
+   dma_buf_unmap_attachment_unlocked(gem->import_attach, bo->sgt,
+ DMA_TO_DEVICE);
drm_prime_gem_destroy(gem, NULL);
} else {
tegra_bo_free(gem->dev, bo);

Re: [Linaro-mm-sig] [PATCH v4 07/21] drm/omapdrm: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare OMAP DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 393f82e26927..8e194dbc9506 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -125,7 +125,7 @@ struct drm_gem_object *omap_gem_prime_import(struct 
drm_device *dev,
  
  	get_dma_buf(dma_buf);
  
-	sgt = dma_buf_map_attachment(attach, DMA_TO_DEVICE);

+   sgt = dma_buf_map_attachment_unlocked(attach, DMA_TO_DEVICE);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
@@ -142,7 +142,7 @@ struct drm_gem_object *omap_gem_prime_import(struct 
drm_device *dev,
return obj;
  
  fail_unmap:

-   dma_buf_unmap_attachment(attach, sgt, DMA_TO_DEVICE);
+   dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_TO_DEVICE);
  fail_detach:
dma_buf_detach(dma_buf, attach);
dma_buf_put(dma_buf);

Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare i915 driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions
and handling cases where importer now holds the reservation lock.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König , but it's probably 
best if somebody from the Intel guys take a look as well.



---
  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   |  2 +-
  drivers/gpu/drm/i915/gem/i915_gem_object.c   | 12 
  .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16 
  3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..07eee1c09aaf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf,
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
void *vaddr;
  
-	vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);

+   vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c

index 389e9f157ca5..7e2a9b02526c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
continue;
}
  
+		/*

+* dma_buf_unmap_attachment() requires reservation to be
+* locked. The imported GEM shouldn't share reservation lock,
+* so it's safe to take the lock.
+*/
+   if (obj->base.import_attach)
+   i915_gem_object_lock(obj, NULL);
+
__i915_gem_object_pages_fini(obj);
+
+   if (obj->base.import_attach)
+   i915_gem_object_unlock(obj);
+
__i915_gem_free_object(obj);
  
  		/* But keep the pointer alive for RCU-protected lookups */

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 62c61af77a42..9e3ed634aa0e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct 
drm_i915_private *i915,
goto out_import;
}
  
-	st = dma_buf_map_attachment(import_attach, DMA_BIDIRECTIONAL);

+   st = dma_buf_map_attachment_unlocked(import_attach, DMA_BIDIRECTIONAL);
if (IS_ERR(st)) {
err = PTR_ERR(st);
goto out_detach;
@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct 
drm_i915_private *i915,
timeout = -ETIME;
}
err = timeout > 0 ? 0 : timeout;
-   dma_buf_unmap_attachment(import_attach, st, DMA_BIDIRECTIONAL);
+   dma_buf_unmap_attachment_unlocked(import_attach, st, DMA_BIDIRECTIONAL);
  out_detach:
dma_buf_detach(dmabuf, import_attach);
  out_import:
@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
goto out_obj;
}
  
-	err = dma_buf_vmap(dmabuf, );

+   err = dma_buf_vmap_unlocked(dmabuf, );
dma_map = err ? NULL : map.vaddr;
if (!dma_map) {
pr_err("dma_buf_vmap failed\n");
@@ -337,7 +337,7 @@ static int igt_dmabuf_import(void *arg)
  
  	err = 0;

  out_dma_map:
-   dma_buf_vunmap(dmabuf, );
+   dma_buf_vunmap_unlocked(dmabuf, );
  out_obj:
i915_gem_object_put(obj);
  out_dmabuf:
@@ -358,7 +358,7 @@ static int igt_dmabuf_import_ownership(void *arg)
if (IS_ERR(dmabuf))
return PTR_ERR(dmabuf);
  
-	err = dma_buf_vmap(dmabuf, );

+   err = dma_buf_vmap_unlocked(dmabuf, );
ptr = err ? NULL : map.vaddr;
if (!ptr) {
pr_err("dma_buf_vmap failed\n");
@@ -367,7 +367,7 @@ static int igt_dmabuf_import_ownership(void *arg)
}
  
  	memset(ptr, 0xc5, PAGE_SIZE);

-   dma_buf_vunmap(dmabuf, );
+   dma_buf_vunmap_unlocked(dmabuf, );
  
  	obj = to_intel_bo(i915_gem_prime_import(>drm, dmabuf));

if (IS_ERR(obj)) {
@@ -418,7 +418,7 @@ static int igt_dmabuf_export_vmap(void *arg)
}
i915_gem_object_put(obj);
  
-	err = dma_buf_vmap(dmabuf, );

+   err = dma_buf_vmap_unlocked(dmabuf, );
ptr = err ? NULL : map.vaddr;
if (!ptr) {
pr_err("dma_buf_vmap failed\n");
@@ -435,7 +435,7 @@ static int igt_dmabuf_export_vmap(void *arg)
memset(ptr, 0xc5, dmabuf->size);
  
  	err = 0;

-   dma_buf_vunmap(dmabuf, );
+   dma_buf_vunmap_unlocked(dmabuf, );
  out:
dma_buf_put(dmabuf);
return err;

Re: [PATCH v4 05/21] drm/armada: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare Armada driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.

Signed-off-by: Dmitry Osipenko 


Acked-by: Christian König 


---
  drivers/gpu/drm/armada/armada_gem.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 5430265ad458..26d10065d534 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -66,8 +66,8 @@ void armada_gem_free_object(struct drm_gem_object *obj)
if (dobj->obj.import_attach) {
/* We only ever display imported data */
if (dobj->sgt)
-   dma_buf_unmap_attachment(dobj->obj.import_attach,
-dobj->sgt, DMA_TO_DEVICE);
+   
dma_buf_unmap_attachment_unlocked(dobj->obj.import_attach,
+ dobj->sgt, 
DMA_TO_DEVICE);
drm_prime_gem_destroy(>obj, NULL);
}
  
@@ -539,8 +539,8 @@ int armada_gem_map_import(struct armada_gem_object *dobj)

  {
int ret;
  
-	dobj->sgt = dma_buf_map_attachment(dobj->obj.import_attach,

-  DMA_TO_DEVICE);
+   dobj->sgt = dma_buf_map_attachment_unlocked(dobj->obj.import_attach,
+   DMA_TO_DEVICE);
if (IS_ERR(dobj->sgt)) {
ret = PTR_ERR(dobj->sgt);
dobj->sgt = NULL;

Re: [PATCH v4 04/21] drm/prime: Prepare to dynamic dma-buf locking specification

[Christian König]

Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:

Prepare DRM prime core to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.

Signed-off-by: Dmitry Osipenko 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/drm_prime.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index eb09e86044c6..20e109a802ae 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -940,7 +940,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct 
drm_device *dev,
  
  	get_dma_buf(dma_buf);
  
-	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);

+   sgt = dma_buf_map_attachment_unlocked(attach, DMA_BIDIRECTIONAL);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
@@ -958,7 +958,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct 
drm_device *dev,
return obj;
  
  fail_unmap:

-   dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+   dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_BIDIRECTIONAL);
  fail_detach:
dma_buf_detach(dma_buf, attach);
dma_buf_put(dma_buf);
@@ -1056,7 +1056,7 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, 
struct sg_table *sg)
  
  	attach = obj->import_attach;

if (sg)
-   dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
+   dma_buf_unmap_attachment_unlocked(attach, sg, 
DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
/* remove the reference */