date:20210604

Unused so remove them.

Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c   | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
index b281a4ad152a..90127c1f9e35 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
@@ -362,8 +362,6 @@ void dcn31_link_encoder_enable_dp_output(
const struct dc_link_settings *link_settings,
enum clock_source_id clock_source)
 {
-   struct dcn10_link_encoder *enc10 = TO_DCN10_LINK_ENC(enc);
-
/* Enable transmitter and encoder. */
if (!link_enc_cfg_is_transmitter_mappable(enc->ctx->dc->current_state, 
enc)) {
 
@@ -380,8 +378,6 @@ void dcn31_link_encoder_enable_dp_mst_output(
const struct dc_link_settings *link_settings,
enum clock_source_id clock_source)
 {
-   struct dcn10_link_encoder *enc10 = TO_DCN10_LINK_ENC(enc);
-
/* Enable transmitter and encoder. */
if (!link_enc_cfg_is_transmitter_mappable(enc->ctx->dc->current_state, 
enc)) {
 
@@ -397,8 +393,6 @@ void dcn31_link_encoder_disable_output(
struct link_encoder *enc,
enum signal_type signal)
 {
-   struct dcn10_link_encoder *enc10 = TO_DCN10_LINK_ENC(enc);
-
/* Disable transmitter and encoder. */
if (!link_enc_cfg_is_transmitter_mappable(enc->ctx->dc->current_state, 
enc)) {
 
-- 
2.31.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check

2021-06-04 Thread kernel test robot

Hi Mark,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on linus/master v5.13-rc4 next-20210604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Mark-Yacoub/Verify-Gamma-Degamma-LUT-sizes-in-amdgpu_dm_atomic_check/20210605-010052
base:   git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/69d2510b404de1ebb3ee54e37daff71f1df02a29
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Mark-Yacoub/Verify-Gamma-Degamma-LUT-sizes-in-amdgpu_dm_atomic_check/20210605-010052
git checkout 69d2510b404de1ebb3ee54e37daff71f1df02a29
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:288: 
>> warning: This comment starts with '/**', but isn't a kernel-doc comment. 
>> Refer Documentation/doc-guide/kernel-doc.rst
* Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are 
of


vim +288 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c

   286  
   287  /**
 > 288   * Verifies that the Degamma and Gamma LUTs attached to the 
 > |crtc_state| are of
   289   * the expected size.
   290   * Returns 0 on success.
   291   */
   292  int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
   293  {
   294  const struct drm_color_lut *lut = NULL;
   295  uint32_t size = 0;
   296  
   297  lut = __extract_blob_lut(crtc_state->degamma_lut, );
   298  if (lut && size != MAX_COLOR_LUT_ENTRIES) {
   299  DRM_DEBUG_DRIVER(
   300  "Invalid Degamma LUT size. Should be %u but got 
%u.\n",
   301  MAX_COLOR_LUT_ENTRIES, size);
   302  return -EINVAL;
   303  }
   304  
   305  lut = __extract_blob_lut(crtc_state->gamma_lut, );
   306  if (lut && size != MAX_COLOR_LUT_ENTRIES &&
   307  size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
   308  DRM_DEBUG_DRIVER(
   309  "Invalid Gamma LUT size. Should be %u (or %u 
for legacy) but got %u.\n",
   310  MAX_COLOR_LUT_ENTRIES, 
MAX_COLOR_LEGACY_LUT_ENTRIES,
   311  size);
   312  return -EINVAL;
   313  }
   314  
   315  return 0;
   316  }
   317  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: Modify register access in sdma_v5_2 to use _SOC15 macros

In SRIOV environment, KMD should access SDMA registers
with RLCG if GC indirect access flag enabled.

Using _SOC15 read/write macros ensures that they go
through RLC when the flag is enabled.

Signed-off-by: Rohit Khaire 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 70 +-
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
index 98059bce692f..62bc8bd7f9f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
@@ -495,12 +495,12 @@ static void sdma_v5_2_gfx_stop(struct amdgpu_device *adev)
amdgpu_ttm_set_buffer_funcs_status(adev, false);
 
for (i = 0; i < adev->sdma.num_instances; i++) {
-   rb_cntl = RREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_CNTL));
+   rb_cntl = RREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_CNTL));
rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, RB_ENABLE, 
0);
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, mmSDMA0_GFX_RB_CNTL), 
rb_cntl);
-   ib_cntl = RREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_IB_CNTL));
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_CNTL), rb_cntl);
+   ib_cntl = RREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_IB_CNTL));
ib_cntl = REG_SET_FIELD(ib_cntl, SDMA0_GFX_IB_CNTL, IB_ENABLE, 
0);
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, mmSDMA0_GFX_IB_CNTL), 
ib_cntl);
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_IB_CNTL), ib_cntl);
}
 }
 
@@ -558,11 +558,11 @@ static void sdma_v5_2_ctx_switch_enable(struct 
amdgpu_device *adev, bool enable)
f32_cntl = REG_SET_FIELD(f32_cntl, SDMA0_CNTL,
AUTO_CTXSW_ENABLE, enable ? 1 : 0);
if (enable && amdgpu_sdma_phase_quantum) {
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_PHASE0_QUANTUM),
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_PHASE0_QUANTUM),
   phase_quantum);
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_PHASE1_QUANTUM),
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_PHASE1_QUANTUM),
   phase_quantum);
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_PHASE2_QUANTUM),
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_PHASE2_QUANTUM),
   phase_quantum);
}
WREG32(sdma_v5_2_get_reg_offset(adev, i, mmSDMA0_CNTL), 
f32_cntl);
@@ -620,62 +620,62 @@ static int sdma_v5_2_gfx_resume(struct amdgpu_device 
*adev)
ring = >sdma.instance[i].ring;
wb_offset = (ring->rptr_offs * 4);
 
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_SEM_WAIT_FAIL_TIMER_CNTL), 0);
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_SEM_WAIT_FAIL_TIMER_CNTL), 0);
 
/* Set ring buffer size in dwords */
rb_bufsz = order_base_2(ring->ring_size / 4);
-   rb_cntl = RREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_CNTL));
+   rb_cntl = RREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_CNTL));
rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, RB_SIZE, 
rb_bufsz);
 #ifdef __BIG_ENDIAN
rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, 
RB_SWAP_ENABLE, 1);
rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL,
RPTR_WRITEBACK_SWAP_ENABLE, 1);
 #endif
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, mmSDMA0_GFX_RB_CNTL), 
rb_cntl);
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_CNTL), rb_cntl);
 
/* Initialize the ring buffer's read and write pointers */
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, mmSDMA0_GFX_RB_RPTR), 
0);
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_RPTR_HI), 0);
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, mmSDMA0_GFX_RB_WPTR), 
0);
-   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_WPTR_HI), 0);
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_RPTR), 0);
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_RPTR_HI), 0);
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_WPTR), 0);
+   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
mmSDMA0_GFX_RB_WPTR_HI), 0);
 
/* setup the wptr shadow polling */
wptr_gpu_addr

Re: [PATCH 2/2] drm/amdgpu/dc: fix DCN3.1 FP handling

2021-06-04 Thread Kazlauskas, Nicholas


On 2021-06-04 2:16 p.m., Alex Deucher wrote:

Missing proper DC_FP_START/DC_FP_END.

Signed-off-by: Alex Deucher 


Thanks for catching these.

Series is Reviewed-by: Nicholas Kazlauskas

Regards,
Nicholas Kazlauskas


---
  .../drm/amd/display/dc/dcn31/dcn31_resource.c  | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index af978d2cb25f..0d6cb6caad81 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1633,7 +1633,7 @@ static void dcn31_update_soc_for_wm_a(struct dc *dc, 
struct dc_state *context)
}
  }
  
-static void dcn31_calculate_wm_and_dlg(

+static void dcn31_calculate_wm_and_dlg_fp(
struct dc *dc, struct dc_state *context,
display_e2e_pipe_params_st *pipes,
int pipe_cnt,
@@ -1759,6 +1759,17 @@ static void dcn31_calculate_wm_and_dlg(
dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
  }
  
+static void dcn31_calculate_wm_and_dlg(

+   struct dc *dc, struct dc_state *context,
+   display_e2e_pipe_params_st *pipes,
+   int pipe_cnt,
+   int vlevel)
+{
+   DC_FP_START();
+   dcn31_calculate_wm_and_dlg_fp(dc, context, pipes, pipe_cnt, vlevel);
+   DC_FP_END();
+}
+
  static struct dc_cap_funcs cap_funcs = {
.get_dcc_compression_cap = dcn20_get_dcc_compression_cap
  };
@@ -1890,6 +1901,8 @@ static bool dcn31_resource_construct(
struct dc_context *ctx = dc->ctx;
struct irq_service_init_data init_data;
  
+	DC_FP_START();

+
ctx->dc_bios->regs = _regs;
  
  	pool->base.res_cap = _cap_dcn31;

@@ -2152,10 +2165,13 @@ static bool dcn31_resource_construct(
  
  	dc->cap_funcs = cap_funcs;
  
+	DC_FP_END();

+
return true;
  
  create_fail:
  
+	DC_FP_END();

dcn31_resource_destruct(pool);
  
  	return false;




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/2] drm/amdgpu/dc: fix DCN3.1 FP handling

Missing proper DC_FP_START/DC_FP_END.

Signed-off-by: Alex Deucher 
---
 .../drm/amd/display/dc/dcn31/dcn31_resource.c  | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index af978d2cb25f..0d6cb6caad81 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1633,7 +1633,7 @@ static void dcn31_update_soc_for_wm_a(struct dc *dc, 
struct dc_state *context)
}
 }
 
-static void dcn31_calculate_wm_and_dlg(
+static void dcn31_calculate_wm_and_dlg_fp(
struct dc *dc, struct dc_state *context,
display_e2e_pipe_params_st *pipes,
int pipe_cnt,
@@ -1759,6 +1759,17 @@ static void dcn31_calculate_wm_and_dlg(
dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
 }
 
+static void dcn31_calculate_wm_and_dlg(
+   struct dc *dc, struct dc_state *context,
+   display_e2e_pipe_params_st *pipes,
+   int pipe_cnt,
+   int vlevel)
+{
+   DC_FP_START();
+   dcn31_calculate_wm_and_dlg_fp(dc, context, pipes, pipe_cnt, vlevel);
+   DC_FP_END();
+}
+
 static struct dc_cap_funcs cap_funcs = {
.get_dcc_compression_cap = dcn20_get_dcc_compression_cap
 };
@@ -1890,6 +1901,8 @@ static bool dcn31_resource_construct(
struct dc_context *ctx = dc->ctx;
struct irq_service_init_data init_data;
 
+   DC_FP_START();
+
ctx->dc_bios->regs = _regs;
 
pool->base.res_cap = _cap_dcn31;
@@ -2152,10 +2165,13 @@ static bool dcn31_resource_construct(
 
dc->cap_funcs = cap_funcs;
 
+   DC_FP_END();
+
return true;
 
 create_fail:
 
+   DC_FP_END();
dcn31_resource_destruct(pool);
 
return false;
-- 
2.31.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amdgpu/dc: fix DCN3.1 Makefile for PPC64

Port the necessary changes from previous DCN versions.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
index 439b95d4c120..5dcdc5a858fe 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
@@ -13,12 +13,19 @@
 DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o dcn31_init.o 
dcn31_hubp.o \
dcn31_dccg.o dcn31_optc.o dcn31_dio_link_encoder.o dcn31_panel_cntl.o
 
-CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -msse
+ifdef CONFIG_X86
+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -msse
+endif
+
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
+endif
 
 ifdef CONFIG_CC_IS_GCC
 ifeq ($(call cc-ifversion, -lt, 0701, y), y)
 IS_OLD_GCC = 1
 endif
+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o += -mhard-float
 endif
 
 ifdef IS_OLD_GCC
-- 
2.31.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Use vma_lookup() in amdgpu_ttm_tt_get_user_pages()

On Fri, Jun 4, 2021 at 7:11 AM Christian König
 wrote:
>
> Am 03.06.21 um 18:09 schrieb Liam Howlett:
> > Use vma_lookup() to find the VMA at a specific address.  As vma_lookup()
> > will return NULL if the address is not within any VMA, the start address
> > no longer needs to be validated.
> >
> > Signed-off-by: Liam R. Howlett 
>
> Reviewed-by: Christian König 
>

I'm fine to have this go through whatever tree makes sense.

Acked-by: Alex Deucher 

> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 7cb7ffdd1900..dfb5ca3f8da8 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -680,9 +680,9 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
> > struct page **pages)
> >   return -ESRCH;
> >
> >   mmap_read_lock(mm);
> > - vma = find_vma(mm, start);
> > + vma = vma_lookup(mm, start);
> >   mmap_read_unlock(mm);
> > - if (unlikely(!vma || start < vma->vm_start)) {
> > + if (unlikely(!vma)) {
> >   r = -EFAULT;
> >   goto out_putmm;
> >   }
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Modify GC register access to use _SOC15 macros

2021-06-04 Thread Deucher, Alexander

[Public]

Reviewed-by: Alex Deucher 

From: Khaire, Rohit 
Sent: Friday, June 4, 2021 12:38 PM
To: amd-gfx@lists.freedesktop.org ; Deucher, 
Alexander ; Zhang, Hawking ; 
Deng, Emily ; Liu, Monk ; Zhou, Peng Ju 
; Chen, Horace 
Cc: Ming, Davis ; Khaire, Rohit ; 
Koenig, Christian ; Khaire, Rohit 

Subject: [PATCH] drm/amdgpu: Modify GC register access to use _SOC15 macros

In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.

Using _SOC15 read/write macros ensures that they go
through RLC when flag is enabled.

Signed-off-by: Rohit Khaire 
---
 .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c  | 42 +--
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
index d39cff4a1fe3..1f5620cc3570 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
@@ -95,8 +95,8 @@ static void program_sh_mem_settings_v10_3(struct kgd_dev 
*kgd, uint32_t vmid,

 lock_srbm(kgd, 0, 0, 0, vmid);

-   WREG32(SOC15_REG_OFFSET(GC, 0, mmSH_MEM_CONFIG), sh_mem_config);
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmSH_MEM_BASES), sh_mem_bases);
+   WREG32_SOC15(GC, 0, mmSH_MEM_CONFIG, sh_mem_config);
+   WREG32_SOC15(GC, 0, mmSH_MEM_BASES, sh_mem_bases);
 /* APE1 no longer exists on GFX9 */

 unlock_srbm(kgd);
@@ -129,7 +129,7 @@ static int init_interrupts_v10_3(struct kgd_dev *kgd, 
uint32_t pipe_id)

 lock_srbm(kgd, mec, pipe, 0, 0);

-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCPC_INT_CNTL),
+   WREG32_SOC15(GC, 0, mmCPC_INT_CNTL,
 CP_INT_CNTL_RING0__TIME_STAMP_INT_ENABLE_MASK |
 CP_INT_CNTL_RING0__OPCODE_ERROR_INT_ENABLE_MASK);

@@ -212,10 +212,10 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,

 pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
 mec, pipe, queue_id);
-   value = RREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS));
+   value = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
 value = REG_SET_FIELD(value, RLC_CP_SCHEDULERS, scheduler1,
 ((mec << 5) | (pipe << 3) | queue_id | 0x80));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS), value);
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, value);
 }

 /* HQD registers extend from CP_MQD_BASE_ADDR to CP_HQD_EOP_WPTR_MEM. 
*/
@@ -224,13 +224,13 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,

 for (reg = hqd_base;
  reg <= SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI); reg++)
-   WREG32(reg, mqd_hqd[reg - hqd_base]);
+   WREG32_SOC15_IP(GC, reg, mqd_hqd[reg - hqd_base]);


 /* Activate doorbell logic before triggering WPTR poll. */
 data = REG_SET_FIELD(m->cp_hqd_pq_doorbell_control,
  CP_HQD_PQ_DOORBELL_CONTROL, DOORBELL_EN, 1);
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL), data);
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL, data);

 if (wptr) {
 /* Don't read wptr with get_user because the user
@@ -259,17 +259,17 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,
 guessed_wptr += m->cp_hqd_pq_wptr_lo & ~(queue_size - 1);
 guessed_wptr += (uint64_t)m->cp_hqd_pq_wptr_hi << 32;

-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_LO),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_LO,
lower_32_bits(guessed_wptr));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_HI,
upper_32_bits(guessed_wptr));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR,
lower_32_bits((uint64_t)wptr));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR_HI),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR_HI,
upper_32_bits((uint64_t)wptr));
 pr_debug("%s setting CP_PQ_WPTR_POLL_CNTL1 to %x\n", __func__,
  (uint32_t)get_queue_mask(adev, pipe_id, queue_id));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_PQ_WPTR_POLL_CNTL1),
+   WREG32_SOC15(GC, 0, mmCP_PQ_WPTR_POLL_CNTL1,
(uint32_t)get_queue_mask(adev, pipe_id, queue_id));
 }

@@ -279,7 +279,7 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,
  CP_HQD_EOP_RPTR, INIT_FETCHER, 1));

 data = REG_SET_FIELD(m->cp_hqd_active,

[PATCH] drm/amdgpu: Modify GC register access to use _SOC15 macros

In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.

Using _SOC15 read/write macros ensures that they go
through RLC when flag is enabled.

Signed-off-by: Rohit Khaire 
---
 .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c  | 42 +--
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
index d39cff4a1fe3..1f5620cc3570 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
@@ -95,8 +95,8 @@ static void program_sh_mem_settings_v10_3(struct kgd_dev 
*kgd, uint32_t vmid,
 
lock_srbm(kgd, 0, 0, 0, vmid);
 
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmSH_MEM_CONFIG), sh_mem_config);
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmSH_MEM_BASES), sh_mem_bases);
+   WREG32_SOC15(GC, 0, mmSH_MEM_CONFIG, sh_mem_config);
+   WREG32_SOC15(GC, 0, mmSH_MEM_BASES, sh_mem_bases);
/* APE1 no longer exists on GFX9 */
 
unlock_srbm(kgd);
@@ -129,7 +129,7 @@ static int init_interrupts_v10_3(struct kgd_dev *kgd, 
uint32_t pipe_id)
 
lock_srbm(kgd, mec, pipe, 0, 0);
 
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCPC_INT_CNTL),
+   WREG32_SOC15(GC, 0, mmCPC_INT_CNTL,
CP_INT_CNTL_RING0__TIME_STAMP_INT_ENABLE_MASK |
CP_INT_CNTL_RING0__OPCODE_ERROR_INT_ENABLE_MASK);
 
@@ -212,10 +212,10 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,
 
pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
mec, pipe, queue_id);
-   value = RREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS));
+   value = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
value = REG_SET_FIELD(value, RLC_CP_SCHEDULERS, scheduler1,
((mec << 5) | (pipe << 3) | queue_id | 0x80));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS), value);
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, value);
}
 
/* HQD registers extend from CP_MQD_BASE_ADDR to CP_HQD_EOP_WPTR_MEM. */
@@ -224,13 +224,13 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,
 
for (reg = hqd_base;
 reg <= SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI); reg++)
-   WREG32(reg, mqd_hqd[reg - hqd_base]);
+   WREG32_SOC15_IP(GC, reg, mqd_hqd[reg - hqd_base]);
 
 
/* Activate doorbell logic before triggering WPTR poll. */
data = REG_SET_FIELD(m->cp_hqd_pq_doorbell_control,
 CP_HQD_PQ_DOORBELL_CONTROL, DOORBELL_EN, 1);
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL), data);
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL, data);
 
if (wptr) {
/* Don't read wptr with get_user because the user
@@ -259,17 +259,17 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,
guessed_wptr += m->cp_hqd_pq_wptr_lo & ~(queue_size - 1);
guessed_wptr += (uint64_t)m->cp_hqd_pq_wptr_hi << 32;
 
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_LO),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_LO,
   lower_32_bits(guessed_wptr));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_HI,
   upper_32_bits(guessed_wptr));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR,
   lower_32_bits((uint64_t)wptr));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR_HI),
+   WREG32_SOC15(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR_HI,
   upper_32_bits((uint64_t)wptr));
pr_debug("%s setting CP_PQ_WPTR_POLL_CNTL1 to %x\n", __func__,
 (uint32_t)get_queue_mask(adev, pipe_id, queue_id));
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_PQ_WPTR_POLL_CNTL1),
+   WREG32_SOC15(GC, 0, mmCP_PQ_WPTR_POLL_CNTL1,
   (uint32_t)get_queue_mask(adev, pipe_id, queue_id));
}
 
@@ -279,7 +279,7 @@ static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, 
uint32_t pipe_id,
 CP_HQD_EOP_RPTR, INIT_FETCHER, 1));
 
data = REG_SET_FIELD(m->cp_hqd_active, CP_HQD_ACTIVE, ACTIVE, 1);
-   WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_ACTIVE), data);
+   WREG32_SOC15(GC, 0, mmCP_HQD_ACTIVE, data);
 
release_queue(kgd);
 
@@ -350,7 +350,7 @@ static int hqd_dump_v10_3(struct kgd_dev *kgd,
if (WARN_ON_ONCE(i >= HQD_N_REGS))  \
break;  \
(*dump)[i][0] = (addr) << 2;\
-

[PATCH] treewide: Add missing semicolons to __assign_str uses

2021-06-04 Thread Joe Perches

The __assign_str macro has an unusual ending semicolon but the vast
majority of uses of the macro already have semicolon termination.

$ git grep -P '\b__assign_str\b' | wc -l
551
$ git grep -P '\b__assign_str\b.*;' | wc -l
480

Add semicolons to the __assign_str() uses without semicolon termination
and all the other uses without semicolon termination via additional defines
that are equivalent to __assign_str() with the eventual goal of removing
the semicolon from the __assign_str() macro definition.

Link: 
https://lore.kernel.org/lkml/1e068d21106bb6db05b735b4916bb420e6c9842a.ca...@perches.com/

Signed-off-by: Joe Perches 
---

Resending without all the direct cc's, only the mailing lists as
it seems not to have gone through via vger.

Compiled x84-64 allyesconfig

On Fri, 2021-06-04 at 12:21 -0400, Steven Rostedt wrote:
> I have no problem taking a clean up patch that adds semicolons to all
> use cases of "__assign_str()" and ever remove the one from where it is
> defined. As long as it doesn't break any builds, I'm fine with that.

Removing the semicolon from the macro definition is left for another patch.

 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  | 14 
 drivers/gpu/drm/lima/lima_trace.h  |  2 +-
 drivers/infiniband/hw/hfi1/trace_misc.h|  4 +--
 drivers/infiniband/hw/hfi1/trace_rc.h  |  4 +--
 drivers/infiniband/hw/hfi1/trace_tid.h |  6 ++--
 drivers/infiniband/hw/hfi1/trace_tx.h  |  8 ++---
 drivers/infiniband/sw/rdmavt/trace_cq.h|  4 +--
 drivers/infiniband/sw/rdmavt/trace_mr.h|  2 +-
 drivers/infiniband/sw/rdmavt/trace_qp.h|  4 +--
 drivers/infiniband/sw/rdmavt/trace_rc.h|  2 +-
 drivers/infiniband/sw/rdmavt/trace_tx.h|  4 +--
 drivers/misc/mei/mei-trace.h   |  6 ++--
 .../net/ethernet/marvell/octeontx2/af/rvu_trace.h  | 12 +++
 drivers/net/fjes/fjes_trace.h  |  4 +--
 drivers/usb/cdns3/cdnsp-trace.h|  2 +-
 fs/nfs/nfs4trace.h |  6 ++--
 fs/nfs/nfstrace.h  |  4 +--
 include/trace/events/btrfs.h   |  2 +-
 include/trace/events/dma_fence.h   |  4 +--
 include/trace/events/rpcgss.h  |  4 +--
 include/trace/events/sunrpc.h  | 40 +++---
 net/mac80211/trace.h   |  2 +-
 22 files changed, 70 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 0527772fe1b80..d855cb53c7e09 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -176,10 +176,10 @@ TRACE_EVENT(amdgpu_cs_ioctl,
 
TP_fast_assign(
   __entry->sched_job_id = job->base.id;
-  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job));
   __entry->context = 
job->base.s_fence->finished.context;
   __entry->seqno = job->base.s_fence->finished.seqno;
-  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name)
+  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name);
   __entry->num_ibs = job->num_ibs;
   ),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u, 
ring_name=%s, num_ibs=%u",
@@ -201,10 +201,10 @@ TRACE_EVENT(amdgpu_sched_run_job,
 
TP_fast_assign(
   __entry->sched_job_id = job->base.id;
-  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job));
   __entry->context = 
job->base.s_fence->finished.context;
   __entry->seqno = job->base.s_fence->finished.seqno;
-  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name)
+  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name);
   __entry->num_ibs = job->num_ibs;
   ),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u, 
ring_name=%s, num_ibs=%u",
@@ -229,7 +229,7 @@ TRACE_EVENT(amdgpu_vm_grab_id,
 
TP_fast_assign(
   __entry->pasid = vm->pasid;
-  __assign_str(ring, ring->name)
+  __assign_str(ring, ring->name);
   __entry->vmid = job->vmid;
   __entry->vm_hub = ring->funcs->vmhub,
   __entry->pd_addr = job->vm_pd_addr;
@@ -424,7 +424,7 @@ TRACE_EVENT(amdgpu_vm_flush,

Re: [PATCH] drm/amdgpu: Enable RLCG read/write interface for Sienna Cichlid

2021-06-04 Thread Deucher, Alexander

[Public]

Reviewed-by: Alex Deucher 

From: amd-gfx  on behalf of Rohit Khaire 

Sent: Friday, June 4, 2021 11:24 AM
To: amd-gfx@lists.freedesktop.org ; Deucher, 
Alexander ; Zhang, Hawking ; 
Deng, Emily ; Liu, Monk ; Zhou, Peng Ju 
; Chen, Horace 
Cc: Ming, Davis ; Khaire, Rohit ; 
Koenig, Christian 
Subject: [PATCH] drm/amdgpu: Enable RLCG read/write interface for Sienna Cichlid

Enable this only for Sienna Cichild
since only Navi12 and Sienna Cichlid support SRIOV

Signed-off-by: Rohit Khaire 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 4a50c4e9aea0..29017b18470d 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -9217,7 +9217,6 @@ static void gfx_v10_0_set_rlc_funcs(struct amdgpu_device 
*adev)
 switch (adev->asic_type) {
 case CHIP_NAVI10:
 case CHIP_NAVI14:
-   case CHIP_SIENNA_CICHLID:
 case CHIP_NAVY_FLOUNDER:
 case CHIP_VANGOGH:
 case CHIP_DIMGREY_CAVEFISH:
@@ -9225,6 +9224,7 @@ static void gfx_v10_0_set_rlc_funcs(struct amdgpu_device 
*adev)
 adev->gfx.rlc.funcs = _v10_0_rlc_funcs;
 break;
 case CHIP_NAVI12:
+   case CHIP_SIENNA_CICHLID:
 adev->gfx.rlc.funcs = _v10_0_rlc_funcs_sriov;
 break;
 default:
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C8cb0fce709d24222678708d9276ce550%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637584170934932543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=lI7ogfd1EhAtkxo1eAnPXB1LtGGCcJzD9BmfJ0hLJKk%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: Enable RLCG read/write interface for Sienna Cichlid

Enable this only for Sienna Cichild
since only Navi12 and Sienna Cichlid support SRIOV

Signed-off-by: Rohit Khaire 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 4a50c4e9aea0..29017b18470d 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -9217,7 +9217,6 @@ static void gfx_v10_0_set_rlc_funcs(struct amdgpu_device 
*adev)
switch (adev->asic_type) {
case CHIP_NAVI10:
case CHIP_NAVI14:
-   case CHIP_SIENNA_CICHLID:
case CHIP_NAVY_FLOUNDER:
case CHIP_VANGOGH:
case CHIP_DIMGREY_CAVEFISH:
@@ -9225,6 +9224,7 @@ static void gfx_v10_0_set_rlc_funcs(struct amdgpu_device 
*adev)
adev->gfx.rlc.funcs = _v10_0_rlc_funcs;
break;
case CHIP_NAVI12:
+   case CHIP_SIENNA_CICHLID:
adev->gfx.rlc.funcs = _v10_0_rlc_funcs_sriov;
break;
default:
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Modify register access in sdma_v5_2 to use _SOC15 macros

On Fri, Jun 4, 2021 at 3:08 PM Rohit Khaire  wrote:
>
> In SRIOV environment, KMD should access SDMA registers
> with RLCG if GC indirect access flag enabled.
>
> Using _SOC15 read/write macros ensures that they go
> through RLC when the flag is enabled.
>
> Signed-off-by: Rohit Khaire 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 70 +-
>  1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c 
> b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
> index 98059bce692f..62bc8bd7f9f2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
> @@ -495,12 +495,12 @@ static void sdma_v5_2_gfx_stop(struct amdgpu_device 
> *adev)
> amdgpu_ttm_set_buffer_funcs_status(adev, false);
>
> for (i = 0; i < adev->sdma.num_instances; i++) {
> -   rb_cntl = RREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_CNTL));
> +   rb_cntl = RREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, 
> i, mmSDMA0_GFX_RB_CNTL));
> rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, 
> RB_ENABLE, 0);
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_CNTL), rb_cntl);
> -   ib_cntl = RREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_IB_CNTL));
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_CNTL), rb_cntl);
> +   ib_cntl = RREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, 
> i, mmSDMA0_GFX_IB_CNTL));
> ib_cntl = REG_SET_FIELD(ib_cntl, SDMA0_GFX_IB_CNTL, 
> IB_ENABLE, 0);
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_IB_CNTL), ib_cntl);
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_IB_CNTL), ib_cntl);
> }
>  }
>
> @@ -558,11 +558,11 @@ static void sdma_v5_2_ctx_switch_enable(struct 
> amdgpu_device *adev, bool enable)
> f32_cntl = REG_SET_FIELD(f32_cntl, SDMA0_CNTL,
> AUTO_CTXSW_ENABLE, enable ? 1 : 0);
> if (enable && amdgpu_sdma_phase_quantum) {
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_PHASE0_QUANTUM),
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_PHASE0_QUANTUM),
>phase_quantum);
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_PHASE1_QUANTUM),
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_PHASE1_QUANTUM),
>phase_quantum);
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_PHASE2_QUANTUM),
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_PHASE2_QUANTUM),
>phase_quantum);
> }
> WREG32(sdma_v5_2_get_reg_offset(adev, i, mmSDMA0_CNTL), 
> f32_cntl);
> @@ -620,62 +620,62 @@ static int sdma_v5_2_gfx_resume(struct amdgpu_device 
> *adev)
> ring = >sdma.instance[i].ring;
> wb_offset = (ring->rptr_offs * 4);
>
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_SEM_WAIT_FAIL_TIMER_CNTL), 0);
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_SEM_WAIT_FAIL_TIMER_CNTL), 0);
>
> /* Set ring buffer size in dwords */
> rb_bufsz = order_base_2(ring->ring_size / 4);
> -   rb_cntl = RREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_CNTL));
> +   rb_cntl = RREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, 
> i, mmSDMA0_GFX_RB_CNTL));
> rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, RB_SIZE, 
> rb_bufsz);
>  #ifdef __BIG_ENDIAN
> rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, 
> RB_SWAP_ENABLE, 1);
> rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL,
> RPTR_WRITEBACK_SWAP_ENABLE, 1);
>  #endif
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_CNTL), rb_cntl);
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_CNTL), rb_cntl);
>
> /* Initialize the ring buffer's read and write pointers */
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_RPTR), 0);
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_RPTR_HI), 0);
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_WPTR), 0);
> -   WREG32(sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_WPTR_HI), 0);
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
> mmSDMA0_GFX_RB_RPTR), 0);
> +   WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i, 
>

[PATCH] treewide: Add missing semicolons to __assign_str uses

2021-06-04 Thread Joe Perches

The __assign_str macro has an unusual ending semicolon but the vast
majority of uses of the macro already have semicolon termination.

$ git grep -P '\b__assign_str\b' | wc -l
551
$ git grep -P '\b__assign_str\b.*;' | wc -l
480

Add semicolons to the __assign_str() uses without semicolon termination
and all the other uses without semicolon termination via additional defines
that are equivalent to __assign_str() with the eventual goal of removing
the semicolon from the __assign_str() macro definition.

Link: 
https://lore.kernel.org/lkml/1e068d21106bb6db05b735b4916bb420e6c9842a.ca...@perches.com/

Signed-off-by: Joe Perches 
---

Compiled x84-64 allyesconfig

On Fri, 2021-06-04 at 12:21 -0400, Steven Rostedt wrote:
> I have no problem taking a clean up patch that adds semicolons to all
> use cases of "__assign_str()" and ever remove the one from where it is
> defined. As long as it doesn't break any builds, I'm fine with that.

Removing the semicolon from the macro definition is left for another patch.

 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  | 14 
 drivers/gpu/drm/lima/lima_trace.h  |  2 +-
 drivers/infiniband/hw/hfi1/trace_misc.h|  4 +--
 drivers/infiniband/hw/hfi1/trace_rc.h  |  4 +--
 drivers/infiniband/hw/hfi1/trace_tid.h |  6 ++--
 drivers/infiniband/hw/hfi1/trace_tx.h  |  8 ++---
 drivers/infiniband/sw/rdmavt/trace_cq.h|  4 +--
 drivers/infiniband/sw/rdmavt/trace_mr.h|  2 +-
 drivers/infiniband/sw/rdmavt/trace_qp.h|  4 +--
 drivers/infiniband/sw/rdmavt/trace_rc.h|  2 +-
 drivers/infiniband/sw/rdmavt/trace_tx.h|  4 +--
 drivers/misc/mei/mei-trace.h   |  6 ++--
 .../net/ethernet/marvell/octeontx2/af/rvu_trace.h  | 12 +++
 drivers/net/fjes/fjes_trace.h  |  4 +--
 drivers/usb/cdns3/cdnsp-trace.h|  2 +-
 fs/nfs/nfs4trace.h |  6 ++--
 fs/nfs/nfstrace.h  |  4 +--
 include/trace/events/btrfs.h   |  2 +-
 include/trace/events/dma_fence.h   |  4 +--
 include/trace/events/rpcgss.h  |  4 +--
 include/trace/events/sunrpc.h  | 40 +++---
 net/mac80211/trace.h   |  2 +-
 22 files changed, 70 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 0527772fe1b80..d855cb53c7e09 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -176,10 +176,10 @@ TRACE_EVENT(amdgpu_cs_ioctl,
 
TP_fast_assign(
   __entry->sched_job_id = job->base.id;
-  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job));
   __entry->context = 
job->base.s_fence->finished.context;
   __entry->seqno = job->base.s_fence->finished.seqno;
-  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name)
+  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name);
   __entry->num_ibs = job->num_ibs;
   ),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u, 
ring_name=%s, num_ibs=%u",
@@ -201,10 +201,10 @@ TRACE_EVENT(amdgpu_sched_run_job,
 
TP_fast_assign(
   __entry->sched_job_id = job->base.id;
-  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+  __assign_str(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job));
   __entry->context = 
job->base.s_fence->finished.context;
   __entry->seqno = job->base.s_fence->finished.seqno;
-  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name)
+  __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name);
   __entry->num_ibs = job->num_ibs;
   ),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u, 
ring_name=%s, num_ibs=%u",
@@ -229,7 +229,7 @@ TRACE_EVENT(amdgpu_vm_grab_id,
 
TP_fast_assign(
   __entry->pasid = vm->pasid;
-  __assign_str(ring, ring->name)
+  __assign_str(ring, ring->name);
   __entry->vmid = job->vmid;
   __entry->vm_hub = ring->funcs->vmhub,
   __entry->pd_addr = job->vm_pd_addr;
@@ -424,7 +424,7 @@ TRACE_EVENT(amdgpu_vm_flush,
 ),
 
TP_fast_assign(
-  __assign_str(ring, ring->name)
+

RE: [PATCH] drm/amdgpu: Fix incorrect register offsets for Sienna Cichlid

2021-06-04 Thread Khaire, Rohit

[AMD Official Use Only]

Thanks. I will fix that check.

Rohit

From: Deucher, Alexander 
Sent: June 4, 2021 10:56 AM
To: Khaire, Rohit ; amd-gfx@lists.freedesktop.org; Zhang, 
Hawking ; Deng, Emily ; Liu, Monk 
; Zhou, Peng Ju ; Chen, Horace 

Cc: Ming, Davis ; Koenig, Christian 

Subject: Re: [PATCH] drm/amdgpu: Fix incorrect register offsets for Sienna 
Cichlid


[AMD Official Use Only]

checks should be adev->asic_type >= CHIP_SIENNA_CICHLID so we cover other 
gfx10.3 asics as well.  With that fixed:
Reviewed-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: Khaire, Rohit mailto:rohit.kha...@amd.com>>
Sent: Friday, June 4, 2021 10:49 AM
To: amd-gfx@lists.freedesktop.org 
mailto:amd-gfx@lists.freedesktop.org>>; Deucher, 
Alexander mailto:alexander.deuc...@amd.com>>; Zhang, 
Hawking mailto:hawking.zh...@amd.com>>; Deng, Emily 
mailto:emily.d...@amd.com>>; Liu, Monk 
mailto:monk@amd.com>>; Zhou, Peng Ju 
mailto:pengju.z...@amd.com>>; Chen, Horace 
mailto:horace.c...@amd.com>>
Cc: Ming, Davis mailto:davis.m...@amd.com>>; Khaire, Rohit 
mailto:rohit.kha...@amd.com>>; Koenig, Christian 
mailto:christian.koe...@amd.com>>; Khaire, Rohit 
mailto:rohit.kha...@amd.com>>
Subject: [PATCH] drm/amdgpu: Fix incorrect register offsets for Sienna Cichlid

RLC_CP_SCHEDULERS and RLC_SPARE_INT0 have different
offsets for Sienna Cichlid

Signed-off-by: Rohit Khaire mailto:rohit.kha...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 11a64ca8a5ec..1e1ce1e49c70 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -177,6 +177,9 @@
 #define mmGC_THROTTLE_CTRL_Sienna_Cichlid  0x2030
 #define mmGC_THROTTLE_CTRL_Sienna_Cichlid_BASE_IDX 0

+#define mmRLC_SPARE_INT_0_Sienna_Cichlid   0x4ca5
+#define mmRLC_SPARE_INT_0_Sienna_Cichlid_BASE_IDX  1
+
 #define GFX_RLCG_GC_WRITE_OLD   (0x8 << 28)
 #define GFX_RLCG_GC_WRITE   (0x0 << 28)
 #define GFX_RLCG_GC_READ(0x1 << 28)
@@ -1489,8 +1492,15 @@ static u32 gfx_v10_rlcg_rw(struct amdgpu_device *adev, 
u32 offset, u32 v, uint32
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG0_BASE_IDX] 
+ mmSCRATCH_REG2) * 4;
 scratch_reg3 = adev->rmmio +
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG1_BASE_IDX] 
+ mmSCRATCH_REG3) * 4;
-   spare_int = adev->rmmio +
-   (adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_BASE_IDX] + 
mmRLC_SPARE_INT) * 4;
+
+   if (adev->asic_type == CHIP_SIENNA_CICHLID) {
+   spare_int = adev->rmmio +
+   
(adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_0_Sienna_Cichlid_BASE_IDX]
++ mmRLC_SPARE_INT_0_Sienna_Cichlid) * 4;
+   } else {
+   spare_int = adev->rmmio +
+   
(adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_BASE_IDX] + mmRLC_SPARE_INT) * 4;
+   }

 grbm_cntl = adev->reg_offset[GC_HWIP][0][mmGRBM_GFX_CNTL_BASE_IDX] + 
mmGRBM_GFX_CNTL;
 grbm_idx = adev->reg_offset[GC_HWIP][0][mmGRBM_GFX_INDEX_BASE_IDX] + 
mmGRBM_GFX_INDEX;
@@ -7410,9 +7420,15 @@ static int gfx_v10_0_hw_fini(void *handle)
 if (amdgpu_sriov_vf(adev)) {
 gfx_v10_0_cp_gfx_enable(adev, false);
 /* Program KIQ position of RLC_CP_SCHEDULERS during destroy */
-   tmp = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
-   tmp &= 0xff00;
-   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, tmp);
+   if (adev->asic_type == CHIP_SIENNA_CICHLID) {
+   tmp = RREG32_SOC15(GC, 0, 
mmRLC_CP_SCHEDULERS_Sienna_Cichlid);
+   tmp &= 0xff00;
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS_Sienna_Cichlid, 
tmp);
+   } else {
+   tmp = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
+   tmp &= 0xff00;
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, tmp);
+   }

 return 0;
 }
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Fix incorrect register offsets for Sienna Cichlid

2021-06-04 Thread Deucher, Alexander

[AMD Official Use Only]

checks should be adev->asic_type >= CHIP_SIENNA_CICHLID so we cover other 
gfx10.3 asics as well.  With that fixed:
Reviewed-by: Alex Deucher 


From: Khaire, Rohit 
Sent: Friday, June 4, 2021 10:49 AM
To: amd-gfx@lists.freedesktop.org ; Deucher, 
Alexander ; Zhang, Hawking ; 
Deng, Emily ; Liu, Monk ; Zhou, Peng Ju 
; Chen, Horace 
Cc: Ming, Davis ; Khaire, Rohit ; 
Koenig, Christian ; Khaire, Rohit 

Subject: [PATCH] drm/amdgpu: Fix incorrect register offsets for Sienna Cichlid

RLC_CP_SCHEDULERS and RLC_SPARE_INT0 have different
offsets for Sienna Cichlid

Signed-off-by: Rohit Khaire 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 11a64ca8a5ec..1e1ce1e49c70 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -177,6 +177,9 @@
 #define mmGC_THROTTLE_CTRL_Sienna_Cichlid  0x2030
 #define mmGC_THROTTLE_CTRL_Sienna_Cichlid_BASE_IDX 0

+#define mmRLC_SPARE_INT_0_Sienna_Cichlid   0x4ca5
+#define mmRLC_SPARE_INT_0_Sienna_Cichlid_BASE_IDX  1
+
 #define GFX_RLCG_GC_WRITE_OLD   (0x8 << 28)
 #define GFX_RLCG_GC_WRITE   (0x0 << 28)
 #define GFX_RLCG_GC_READ(0x1 << 28)
@@ -1489,8 +1492,15 @@ static u32 gfx_v10_rlcg_rw(struct amdgpu_device *adev, 
u32 offset, u32 v, uint32
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG0_BASE_IDX] 
+ mmSCRATCH_REG2) * 4;
 scratch_reg3 = adev->rmmio +
(adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG1_BASE_IDX] 
+ mmSCRATCH_REG3) * 4;
-   spare_int = adev->rmmio +
-   (adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_BASE_IDX] + 
mmRLC_SPARE_INT) * 4;
+
+   if (adev->asic_type == CHIP_SIENNA_CICHLID) {
+   spare_int = adev->rmmio +
+   
(adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_0_Sienna_Cichlid_BASE_IDX]
++ mmRLC_SPARE_INT_0_Sienna_Cichlid) * 4;
+   } else {
+   spare_int = adev->rmmio +
+   
(adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_BASE_IDX] + mmRLC_SPARE_INT) * 4;
+   }

 grbm_cntl = adev->reg_offset[GC_HWIP][0][mmGRBM_GFX_CNTL_BASE_IDX] + 
mmGRBM_GFX_CNTL;
 grbm_idx = adev->reg_offset[GC_HWIP][0][mmGRBM_GFX_INDEX_BASE_IDX] + 
mmGRBM_GFX_INDEX;
@@ -7410,9 +7420,15 @@ static int gfx_v10_0_hw_fini(void *handle)
 if (amdgpu_sriov_vf(adev)) {
 gfx_v10_0_cp_gfx_enable(adev, false);
 /* Program KIQ position of RLC_CP_SCHEDULERS during destroy */
-   tmp = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
-   tmp &= 0xff00;
-   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, tmp);
+   if (adev->asic_type == CHIP_SIENNA_CICHLID) {
+   tmp = RREG32_SOC15(GC, 0, 
mmRLC_CP_SCHEDULERS_Sienna_Cichlid);
+   tmp &= 0xff00;
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS_Sienna_Cichlid, 
tmp);
+   } else {
+   tmp = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
+   tmp &= 0xff00;
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, tmp);
+   }

 return 0;
 }
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: Fix incorrect register offsets for Sienna Cichlid

RLC_CP_SCHEDULERS and RLC_SPARE_INT0 have different
offsets for Sienna Cichlid

Signed-off-by: Rohit Khaire 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 11a64ca8a5ec..1e1ce1e49c70 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -177,6 +177,9 @@
 #define mmGC_THROTTLE_CTRL_Sienna_Cichlid  0x2030
 #define mmGC_THROTTLE_CTRL_Sienna_Cichlid_BASE_IDX 0
 
+#define mmRLC_SPARE_INT_0_Sienna_Cichlid   0x4ca5
+#define mmRLC_SPARE_INT_0_Sienna_Cichlid_BASE_IDX  1
+
 #define GFX_RLCG_GC_WRITE_OLD  (0x8 << 28)
 #define GFX_RLCG_GC_WRITE  (0x0 << 28)
 #define GFX_RLCG_GC_READ   (0x1 << 28)
@@ -1489,8 +1492,15 @@ static u32 gfx_v10_rlcg_rw(struct amdgpu_device *adev, 
u32 offset, u32 v, uint32
   (adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG0_BASE_IDX] + 
mmSCRATCH_REG2) * 4;
scratch_reg3 = adev->rmmio +
   (adev->reg_offset[GC_HWIP][0][mmSCRATCH_REG1_BASE_IDX] + 
mmSCRATCH_REG3) * 4;
-   spare_int = adev->rmmio +
-   (adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_BASE_IDX] + 
mmRLC_SPARE_INT) * 4;
+
+   if (adev->asic_type == CHIP_SIENNA_CICHLID) {
+   spare_int = adev->rmmio +
+   
(adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_0_Sienna_Cichlid_BASE_IDX]
++ mmRLC_SPARE_INT_0_Sienna_Cichlid) * 4;
+   } else {
+   spare_int = adev->rmmio +
+   
(adev->reg_offset[GC_HWIP][0][mmRLC_SPARE_INT_BASE_IDX] + mmRLC_SPARE_INT) * 4;
+   }
 
grbm_cntl = adev->reg_offset[GC_HWIP][0][mmGRBM_GFX_CNTL_BASE_IDX] + 
mmGRBM_GFX_CNTL;
grbm_idx = adev->reg_offset[GC_HWIP][0][mmGRBM_GFX_INDEX_BASE_IDX] + 
mmGRBM_GFX_INDEX;
@@ -7410,9 +7420,15 @@ static int gfx_v10_0_hw_fini(void *handle)
if (amdgpu_sriov_vf(adev)) {
gfx_v10_0_cp_gfx_enable(adev, false);
/* Program KIQ position of RLC_CP_SCHEDULERS during destroy */
-   tmp = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
-   tmp &= 0xff00;
-   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, tmp);
+   if (adev->asic_type == CHIP_SIENNA_CICHLID) {
+   tmp = RREG32_SOC15(GC, 0, 
mmRLC_CP_SCHEDULERS_Sienna_Cichlid);
+   tmp &= 0xff00;
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS_Sienna_Cichlid, 
tmp);
+   } else {
+   tmp = RREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS);
+   tmp &= 0xff00;
+   WREG32_SOC15(GC, 0, mmRLC_CP_SCHEDULERS, tmp);
+   }
 
return 0;
}
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation

2021-06-04 Thread Sider, Graham

Thanks Evan and Lijo. Keep in mind that the ASIC dependent DWORD with those 
bits is still being kept. That said, I have no problem with listing them out 
separately in the new field as well. I'll make the ASICs that don't support 
VR_MEM1/LIQUID1 map to VR_MEM0/LIQUID0 and not touch the *1 bits. If you have a 
problem with this approach let me know.

Best,
Graham

-Original Message-
From: Lazar, Lijo  
Sent: Friday, June 4, 2021 12:52 AM
To: Quan, Evan ; Sider, Graham ; 
amd-gfx@lists.freedesktop.org
Cc: Kasiviswanathan, Harish ; Sakhnovitch, 
Elena (Elen) 
Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation

[AMD Official Use Only]

A modified version of 2  -  
List all the possible ones and merge those which mean the same - ex: 
terminology changes like THM and TEMP.

In the mail earlier, I meant to list them out separately as the intention is to 
convey the throttle reason to the user- it's better to point out the exact 
regulator which is heating up. 

Thanks,
Lijo

-Original Message-
From: Quan, Evan 
Sent: Friday, June 4, 2021 7:47 AM
To: Lazar, Lijo ; Sider, Graham ; 
amd-gfx@lists.freedesktop.org
Cc: Kasiviswanathan, Harish ; Sakhnovitch, 
Elena (Elen) 
Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation

[AMD Official Use Only]

Thanks Lijo and Graham. Yes, I know that only some specific ASICs support 
VR_MEM1 and LIQUID1.
However, the problem is about the design:
1. should we just list those which are commonly supported by all ASICs.
2. Or we list all the possible throttlers and mask out those unsupported for 
some specific ASICs

BR
Evan
> -Original Message-
> From: Lazar, Lijo 
> Sent: Thursday, June 3, 2021 10:01 PM
> To: Sider, Graham ; Quan, Evan 
> ; amd-gfx@lists.freedesktop.org
> Cc: Kasiviswanathan, Harish ; 
> Sakhnovitch, Elena (Elen) 
> Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler 
> translation
> 
> [AMD Official Use Only]
> 
> VR_*0/1 reflect the throttle status of separate voltage rails - 
> availability of both depends on board and FW capability to query their 
> temperature.
> 
> Thanks,
> Lijo
> 
> -Original Message-
> From: Sider, Graham 
> Sent: Thursday, June 3, 2021 6:41 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Lazar, Lijo ; Kasiviswanathan, Harish 
> ; Sakhnovitch, Elena (Elen) 
> 
> Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler 
> translation
> 
> Some ASICs use a single VR_MEM bit, whereas others split it into
> VR_MEM0 and VR_MEM1. To avoid confusion, we've combined the VR_MEM0 
> and
> VR_MEM1 bits on those ASICs. For consistency we did the same with
> LIQUID0 and LIQUID1.
> 
> -Original Message-
> From: Quan, Evan 
> Sent: Wednesday, June 2, 2021 12:37 AM
> To: Sider, Graham ; amd- 
> g...@lists.freedesktop.org
> Cc: Lazar, Lijo ; Kasiviswanathan, Harish 
> ; Sider, Graham 
> ; Sakhnovitch, Elena (Elen) 
> 
> Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler 
> translation
> 
> [AMD Official Use Only]
> 
> 
> 
> > -Original Message-
> > From: amd-gfx  On Behalf Of 
> > Graham Sider
> > Sent: Wednesday, June 2, 2021 2:12 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Lazar, Lijo ; Kasiviswanathan, Harish 
> > ; Sider, Graham 
> > ; Sakhnovitch, Elena (Elen) 
> > 
> > Subject: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation
> >
> > Perform dependent to independent throttle status translation for 
> > navi1x. Makes use of lookup table navi1x_throttler_map.
> >
> > Signed-off-by: Graham Sider 
> > ---
> >  .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 43
> > +++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > index 78fe13183e8b..bf376b1be08d 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > @@ -238,6 +238,28 @@ static struct cmn2asic_mapping 
> > navi10_workload_map[PP_SMC_POWER_PROFILE_COUNT] =
> > WORKLOAD_MAP(PP_SMC_POWER_PROFILE_CUSTOM,
> > WORKLOAD_PPLIB_CUSTOM_BIT),
> >  };
> >
> > +static const uint8_t navi1x_throttler_map[] = {
> > +   [THROTTLER_TEMP_EDGE_BIT]   =
> > (SMU_THROTTLER_TEMP_EDGE_BIT),
> > +   [THROTTLER_TEMP_HOTSPOT_BIT]=
> > (SMU_THROTTLER_TEMP_HOTSPOT_BIT),
> > +   [THROTTLER_TEMP_MEM_BIT]=
> > (SMU_THROTTLER_TEMP_MEM_BIT),
> > +   [THROTTLER_TEMP_VR_GFX_BIT] =
> > (SMU_THROTTLER_TEMP_VR_GFX_BIT),
> > +   [THROTTLER_TEMP_VR_MEM0_BIT]=
> > (SMU_THROTTLER_TEMP_VR_MEM_BIT),
> > +   [THROTTLER_TEMP_VR_MEM1_BIT]=
> > (SMU_THROTTLER_TEMP_VR_MEM_BIT),
> [Quan, Evan] I'm wondering why you map the two ASIC dependent bits to 
> the same non ASIC independent bit. Instead of defining two non ASIC 
> independent bits.
> > +   [THROTTLER_TEMP_VR_SOC_BIT] =
> > (SMU_THROTTLER_TEMP_VR_SOC_BIT),
> > +   [THROTTLER_TEMP_LIQUID0_BIT]=
> >

Re: [PATCH v4] drm/amdgpu: Don't flush/invalidate HDP for APUs and A+A

2021-06-04 Thread Eric Huang




On 2021-06-04 7:31 a.m., Christian König wrote:

Am 02.06.21 um 21:18 schrieb Eric Huang:

Integrate two generic functions to determine if HDP
flush is needed for all Asics.

Signed-off-by: Eric Huang 


Nice work, just one more idea below.

But patch is Reviewed-by: Christian König  
either way if you implement that or not.



---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h    |  5 
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c   |  4 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 15 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c    |  6 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c |  2 +-
  7 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

index 7533c2677933..2d5dac573425 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1348,6 +1348,11 @@ int amdgpu_device_baco_enter(struct drm_device 
*dev);

  int amdgpu_device_baco_exit(struct drm_device *dev);
  bool amdgpu_device_is_headless(struct amdgpu_device *adev);
  +void amdgpu_device_flush_hdp(struct amdgpu_device *adev,
+    struct amdgpu_ring *ring);
+void amdgpu_device_invalidate_hdp(struct amdgpu_device *adev,
+    struct amdgpu_ring *ring);
+
  /* atpx handler */
  #if defined(CONFIG_VGA_SWITCHEROO)
  void amdgpu_register_atpx_handler(void);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c

index 4c61a67d0016..900c2dbce934 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -697,7 +697,7 @@ bool amdgpu_amdkfd_have_atomics_support(struct 
kgd_dev *kgd)

    void amdgpu_amdkfd_debug_mem_fence(struct kgd_dev *kgd)
  {
-    amdgpu_asic_flush_hdp((struct amdgpu_device *) kgd, NULL);
+    amdgpu_device_flush_hdp((struct amdgpu_device *) kgd, NULL);
  }
    int amdgpu_amdkfd_send_close_event_drain_irq(struct kgd_dev *kgd,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index 9c4d33f649f7..7f687ea58834 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -362,9 +362,9 @@ void amdgpu_device_vram_access(struct 
amdgpu_device *adev, loff_t pos,

  if (write) {
  memcpy_toio(addr, buf, count);
  mb();
-    amdgpu_asic_flush_hdp(adev, NULL);
+    amdgpu_device_flush_hdp(adev, NULL);
  } else {
-    amdgpu_asic_invalidate_hdp(adev, NULL);
+    amdgpu_device_invalidate_hdp(adev, NULL);
  mb();
  memcpy_fromio(buf, addr, count);
  }
@@ -5548,3 +5548,32 @@ bool amdgpu_device_is_headless(struct 
amdgpu_device *adev)
  /* Check if it is NV's VGA class while VCN is harvest, it is 
headless*/

  return nv_is_headless_sku(adev->pdev);
  }
+
+void amdgpu_device_flush_hdp(struct amdgpu_device *adev,
+    struct amdgpu_ring *ring)
+{
+#ifdef CONFIG_X86_64
+    if (adev->flags & AMD_IS_APU)
+    return;
+#endif
+    if (adev->gmc.xgmi.connected_to_cpu)
+    return;
+
+    if (ring && ring->funcs->emit_hdp_flush)
+    amdgpu_ring_emit_hdp_flush(ring);
+    else
+    amdgpu_asic_flush_hdp(adev, ring);
+}
+
+void amdgpu_device_invalidate_hdp(struct amdgpu_device *adev,
+    struct amdgpu_ring *ring)
+{
+#ifdef CONFIG_X86_64
+    if (adev->flags & AMD_IS_APU)
+    return;
+#endif
+    if (adev->gmc.xgmi.connected_to_cpu)
+    return;
+
+    amdgpu_asic_invalidate_hdp(adev, ring);
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c

index 5562b5c90c03..0e3a46ff38e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -250,7 +250,7 @@ int amdgpu_gart_unbind(struct amdgpu_device 
*adev, uint64_t offset,

  }
  }
  mb();
-    amdgpu_asic_flush_hdp(adev, NULL);
+    amdgpu_device_flush_hdp(adev, NULL);


It might make sense to move the memory barrier into the 
amdgpu_device_flush_hdp() function as well, but I'm not 100% sure of 
that.


Christian.


Thanks for your review. mb() depends on the caller from current codes. I 
am not sure if every caller need it either. So I will not change the 
scheme on this patch.


Regards,
Eric



  for (i = 0; i < adev->num_vmhubs; i++)
  amdgpu_gmc_flush_gpu_tlb(adev, 0, i, 0);
  @@ -328,7 +328,7 @@ int amdgpu_gart_bind(struct amdgpu_device 
*adev, uint64_t offset,

  return r;
    mb();
-    amdgpu_asic_flush_hdp(adev, NULL);
+    amdgpu_device_flush_hdp(adev, NULL);
  for (i = 0; i < adev->num_vmhubs; i++)
  amdgpu_gmc_flush_gpu_tlb(adev, 0, i, 0);
  return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c

RE: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb location

2021-06-04 Thread Luo, Zhigang

[AMD Official Use Only]

The policy is defined by our virtualization team to guarantee end user 
experience and reduce maintenance work.

Added David, virtualization team architect.

David, could you help to add more comments?

Thanks,
Zhigang

-Original Message-
From: Christian König 
Sent: June 4, 2021 9:46 AM
To: Luo, Zhigang ; Deng, Emily ; Liu, 
Shaoyun ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb 
location

Well, but are you the one defining the compatibility policy?

See usually Linux kernel code compatibility policy is that existing stuff needs 
to work forever.

We could argue a bit that the hypervisor components are not open source nor 
uAPI, but that argument is rather thin.

Christian.

Am 04.06.21 um 15:23 schrieb Luo, Zhigang:
> [AMD Official Use Only]
>
> Here is our hypervisor driver compatibility policy:
>  - Host.y supports Guest.y-1, Guest.y, Guest.y+1
>  - Guest.y supported by Host.y-1, Host.y,Host.y+1
>
> Host driver had the feature for gfx9 2 years ago. So, this change meet our 
> compatibility policy.
>
> Thanks,
> Zhigang
>
> -Original Message-
> From: Christian König 
> Sent: June 4, 2021 7:14 AM
> To: Deng, Emily ; Liu, Shaoyun
> ; Luo, Zhigang ;
> amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from
> getting fb location
>
> I was just about to question the same thing.
>
> It looks really good to me to have that cleaned up, but if this breaks with 
> older versions of the hypervisor then it is a bit questionable change.
>
> Regards,
> Christian.
>
> Am 04.06.21 um 03:13 schrieb Deng, Emily:
>> Do we need to consider backward compatibility?
>>
>>
>> Best wishes
>> Emily Deng
>>
>>
>>> -Original Message-
>>> From: amd-gfx  On Behalf Of
>>> Liu, Shaoyun
>>> Sent: Thursday, June 3, 2021 11:10 PM
>>> To: Luo, Zhigang ;
>>> amd-gfx@lists.freedesktop.org
>>> Cc: Luo, Zhigang 
>>> Subject: RE: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from
>>> getting fb location
>>>
>>> [AMD Official Use Only]
>>>
>>> Looks ok to me .
>>>
>>> Reviewed-By : Shaoyun.liu 
>>>
>>> -Original Message-
>>> From: amd-gfx  On Behalf Of
>>> Zhigang Luo
>>> Sent: Thursday, June 3, 2021 10:13 AM
>>> To: amd-gfx@lists.freedesktop.org
>>> Cc: Luo, Zhigang 
>>> Subject: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from
>>> getting fb location
>>>
>>> host driver programmed fb location registers for vf, no need to check 
>>> anymore.
>>>
>>> Signed-off-by: Zhigang Luo 
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 +
>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>> index ceb3968d8326..1c2d9fde9021 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>> @@ -1292,10 +1292,7 @@ static int gmc_v9_0_late_init(void *handle)
>>> static void gmc_v9_0_vram_gtt_location(struct amdgpu_device *adev,
>>>   struct amdgpu_gmc *mc) {
>>> -u64 base = 0;
>>> -
>>> -if (!amdgpu_sriov_vf(adev))
>>> -base = adev->mmhub.funcs->get_fb_location(adev);
>>> +u64 base = adev->mmhub.funcs->get_fb_location(adev);
>>>
>>>   /* add the xgmi offset of the physical node */
>>>   base += adev->gmc.xgmi.physical_node_id * adev-
 gmc.xgmi.node_segment_size;
>>> --
>>> 2.17.1
>>>
>>> ___
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
>>> s
>>> ts.fre
>>> edesktop.org%2Fmailman%2Flistinfo%2Famd-
>>> gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
>>> d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
>>> 7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
>>> ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0
>>> ___
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
>>> s
>>> ts.fre
>>> edesktop.org%2Fmailman%2Flistinfo%2Famd-
>>> gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
>>> d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
>>> 7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
>>> ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>> t
>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7CZ
>> h
>> igang.Luo%40amd.com%7C9b87dfa195ed4e84a8c808d92749e416%7C3dd8961fe488
>> 4
>>

Re: [PATCH 1/1] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

2021-06-04 Thread Harry Wentland

On 2021-06-04 9:16 a.m., Werner Sembach wrote:
> convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
> integer had the cases for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.
> 
> Signed-off-by: Werner Sembach 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 389eff96fcf6..6e82889271d5 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6515,6 +6515,10 @@ static int convert_dc_color_depth_into_bpc (enum 
> dc_color_depth display_color_de
>   return 14;
>   case COLOR_DEPTH_161616:
>   return 16;
> + case COLOR_DEPTH_999:
> + return 9;
> + case COLOR_DEPTH_11:
> + return 11;

The color_depth returned by convert_color_depth_from_display_info will never 
return
9 or 11 bpc color depth. If we add these we should add them in all places where
they're needed and test the whole sequence.

I'm a bit surprised to find DC has support for 9 bpc and 11 bpc color depth but 
am
not sure how well tested that is.

Harry

>   default:
>   break;
>   }
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property

2021-06-04 Thread Ville Syrjälä

On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
> This commits implements the "active bpc" drm property for the Intel GPU 
> driver.
> 
> Signed-off-by: Werner Sembach 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 13 +
>  drivers/gpu/drm/i915/display/intel_dp.c  |  8 ++--
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  4 +++-
>  drivers/gpu/drm/i915/display/intel_hdmi.c|  4 +++-
>  4 files changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 64e9107d70f7..f7898d9d7438 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc_state *new_crtc_state, *old_crtc_state;
>   struct intel_crtc *crtc;
> + struct drm_connector *connector;
> + struct drm_connector_state *new_conn_state;
>   u64 put_domains[I915_MAX_PIPES] = {};
>   intel_wakeref_t wakeref = 0;
>   int i;
> @@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   }
>   intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
>  
> + /* Extract information from crtc to communicate it to userspace as 
> connector properties */
> + for_each_new_connector_in_state(>base, connector, 
> new_conn_state, i) {
> + struct drm_crtc *crtc = new_conn_state->crtc;
> + if (crtc) {
> + new_crtc_state = 
> to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));

intel_atomic_get_new_crtc_state()

> + new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 
> 3;
> + }
> + else
> + new_conn_state->active_bpc = 0;
> + }

This also seems too late. I think the whole thing should be
done somewhere around the normal swap_state() stuff.

> +
>   /*
>* Defer the cleanup of the old state to a separate worker to not
>* impede the current task (userspace for blocking modesets) that
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 642c60f3d9b1..67826ba976ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
> struct drm_connector *connect
>   intel_attach_force_audio_property(connector);
>  
>   intel_attach_broadcast_rgb_property(connector);
> - if (HAS_GMCH(dev_priv))
> + if (HAS_GMCH(dev_priv)) {
>   drm_connector_attach_max_bpc_property(connector, 6, 10);
> - else if (DISPLAY_VER(dev_priv) >= 5)
> + drm_connector_attach_active_bpc_property(connector, 6, 10);
> + }
> + else if (DISPLAY_VER(dev_priv) >= 5) {
>   drm_connector_attach_max_bpc_property(connector, 6, 12);
> + drm_connector_attach_active_bpc_property(connector, 6, 12);
> + }
>  
>   /* Register HDMI colorspace for case of lspcon */
>   if (intel_bios_is_lspcon_present(dev_priv, port)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2daa3f67791e..5a1869dc2210 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -844,8 +844,10 @@ static struct drm_connector 
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>*/
>   connector->max_bpc_property =
>   intel_dp->attached_connector->base.max_bpc_property;
> - if (connector->max_bpc_property)
> + if (connector->max_bpc_property) {
>   drm_connector_attach_max_bpc_property(connector, 6, 12);
> + drm_connector_attach_active_bpc_property(connector, 6, 12);
> + }
>  
>   return connector;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index d69f0a6dc26d..8af78b27b6ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi 
> *intel_hdmi, struct drm_connector *c
>   drm_object_attach_property(>base,
>   
> connector->dev->mode_config.hdr_output_metadata_property, 0);
>  
> - if (!HAS_GMCH(dev_priv))
> + if (!HAS_GMCH(dev_priv)) {
>   drm_connector_attach_max_bpc_property(connector, 8, 12);
> + drm_connector_attach_active_bpc_property(connector, 8, 12);
> + }
>  }
>  
>  /*
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

Re: [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-04 Thread Ville Syrjälä

On Fri, Jun 04, 2021 at 07:17:21PM +0200, Werner Sembach wrote:
> Add a new general drm property "active bpc" which can be used by graphic 
> drivers
> to report the applied bit depth per pixel back to userspace.
> 
> While "max bpc" can be used to change the color depth, there was no way to 
> check
> which one actually got used. While in theory the driver chooses the 
> best/highest
> color depth within the max bpc setting a user might not be fully aware what 
> his
> hardware is or isn't capable off. This is meant as a quick way to double check
> the setup.
> 
> In the future, automatic color calibration for screens might also depend on 
> this
> information available.
> 
> Signed-off-by: Werner Sembach 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c |  2 ++
>  drivers/gpu/drm/drm_connector.c   | 40 +++
>  include/drm/drm_connector.h   | 15 
>  3 files changed, 57 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 268bb69c2e2f..7ae4e40936b5 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = 0;
>   } else if (property == connector->max_bpc_property) {
>   *val = state->max_requested_bpc;
> + } else if (property == connector->active_bpc_property) {
> + *val = state->active_bpc;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..5f42a5be5822 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1195,6 +1195,13 @@ static const struct drm_prop_enum_list 
> dp_colorspaces[] = {
>   *   drm_connector_attach_max_bpc_property() to create and attach the
>   *   property to the connector during initialization.
>   *
> + * active bpc:
> + *   This read-only range property is used by userspace check the bit depth
> + *   actually applied by the GPU driver after evaluation all hardware
> + *   capabilities and max bpc. Drivers to use the function
> + *   drm_connector_attach_active_bpc_property() to create and attach the
> + *   property to the connector during initialization.
> + *
>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -2150,6 +2157,39 @@ int drm_connector_attach_max_bpc_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>  
> +/**
> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
> + * @connector: connector to attach active bpc property on.
> + * @min: The minimum bit depth supported by the connector.
> + * @max: The maximum bit depth supported by the connector.
> + *
> + * This is used to check the applied bit depth on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
> +   int min, int max)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + prop = connector->active_bpc_property;
> + if (!prop) {
> + prop = drm_property_create_range(dev, 0, "active bpc", min, 
> max);

Should be immutable.

Also wondering what the semantics of this should be when eg. DSC
is active?

> + if (!prop)
> + return -ENOMEM;
> +
> + connector->active_bpc_property = prop;
> + }
> +
> + drm_object_attach_property(>base, prop, 0);
> + connector->state->active_bpc = 0;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
> +
>  /**
>   * drm_connector_set_vrr_capable_property - sets the variable refresh rate
>   * capable property for a connector
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 1922b278ffad..c58cba2b6afe 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -781,6 +781,13 @@ struct drm_connector_state {
>*/
>   u8 max_bpc;
>  
> + /**
> +  * @active_bpc: Read only property set by the GPU driver to the actually
> +  * applied bit depth of the pixels after evaluating all hardware
> +  * limitations.
> +  */
> + u8 active_bpc;
> +
>   /**
>* @hdr_output_metadata:
>* DRM blob property for HDR output metadata
> @@ -1380,6 +1387,12 @@ struct drm_connector {
>*/
>   struct drm_property *max_bpc_property;
>  
> + /**
> +  * @active_bpc_property: Default connector property for the active bpc
> +  * to be driven out of the connector.
> +  */
> + struct drm_property *active_bpc_property;
> +
>

RE: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb location

2021-06-04 Thread Luo, Zhigang

[AMD Official Use Only]

Here is our hypervisor driver compatibility policy:
- Host.y supports Guest.y-1, Guest.y, Guest.y+1
- Guest.y supported by Host.y-1, Host.y,Host.y+1

Host driver had the feature for gfx9 2 years ago. So, this change meet our 
compatibility policy.

Thanks,
Zhigang

-Original Message-
From: Christian König 
Sent: June 4, 2021 7:14 AM
To: Deng, Emily ; Liu, Shaoyun ; Luo, 
Zhigang ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb 
location

I was just about to question the same thing.

It looks really good to me to have that cleaned up, but if this breaks with 
older versions of the hypervisor then it is a bit questionable change.

Regards,
Christian.

Am 04.06.21 um 03:13 schrieb Deng, Emily:
> Do we need to consider backward compatibility?
>
>
> Best wishes
> Emily Deng
>
>
>> -Original Message-
>> From: amd-gfx  On Behalf Of
>> Liu, Shaoyun
>> Sent: Thursday, June 3, 2021 11:10 PM
>> To: Luo, Zhigang ; amd-gfx@lists.freedesktop.org
>> Cc: Luo, Zhigang 
>> Subject: RE: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from
>> getting fb location
>>
>> [AMD Official Use Only]
>>
>> Looks ok to me .
>>
>> Reviewed-By : Shaoyun.liu 
>>
>> -Original Message-
>> From: amd-gfx  On Behalf Of
>> Zhigang Luo
>> Sent: Thursday, June 3, 2021 10:13 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Luo, Zhigang 
>> Subject: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from
>> getting fb location
>>
>> host driver programmed fb location registers for vf, no need to check 
>> anymore.
>>
>> Signed-off-by: Zhigang Luo 
>> ---
>> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>> index ceb3968d8326..1c2d9fde9021 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>> @@ -1292,10 +1292,7 @@ static int gmc_v9_0_late_init(void *handle)
>> static void gmc_v9_0_vram_gtt_location(struct amdgpu_device *adev,
>>  struct amdgpu_gmc *mc)
>> {
>> -u64 base = 0;
>> -
>> -if (!amdgpu_sriov_vf(adev))
>> -base = adev->mmhub.funcs->get_fb_location(adev);
>> +u64 base = adev->mmhub.funcs->get_fb_location(adev);
>>
>>  /* add the xgmi offset of the physical node */
>>  base += adev->gmc.xgmi.physical_node_id * adev-
>>> gmc.xgmi.node_segment_size;
>> --
>> 2.17.1
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>> ts.fre
>> edesktop.org%2Fmailman%2Flistinfo%2Famd-
>> gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
>> d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
>> 7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
>> ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>> ts.fre
>> edesktop.org%2Fmailman%2Flistinfo%2Famd-
>> gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
>> d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
>> 7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
>> ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7CZh
> igang.Luo%40amd.com%7C9b87dfa195ed4e84a8c808d92749e416%7C3dd8961fe4884
> e608e11a82d994e183d%7C0%7C0%7C637584020581460118%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000sdata=3S6ZEnCCMHHlfc%2B6xmLDz7Bgn91Is7EIpMS7WRxq0Jo%3D
> reserved=0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4 2/2] radeon: use memcpy_to/fromio for UVD fw upload

Applied with the RB fixed.

Thanks!

Alex

On Fri, Jun 4, 2021 at 7:53 AM Chen Li  wrote:
>
>
> I met a gpu addr bug recently and the kernel log
> tells me the pc is memcpy/memset and link register is
> radeon_uvd_resume.
>
> As we know, in some architectures, optimized memcpy/memset
> may not work well on device memory. Trival memcpy_toio/memset_io
> can fix this problem.
>
> BTW, amdgpu has already done it in:
> commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
> that's why it has no this issue on the same gpu and platform.
>
> Signed-off-by: Chen Li 
> Reviewed-by: Christian König
> ---
>  drivers/gpu/drm/radeon/radeon_uvd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 85a1f2c31749..753da95e6abb 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -288,7 +288,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> if (rdev->uvd.vcpu_bo == NULL)
> return -EINVAL;
>
> -   memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
> +   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr, rdev->uvd_fw->data, 
> rdev->uvd_fw->size);
>
> size = radeon_bo_size(rdev->uvd.vcpu_bo);
> size -= rdev->uvd_fw->size;
> @@ -296,7 +296,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> ptr = rdev->uvd.cpu_addr;
> ptr += rdev->uvd_fw->size;
>
> -   memset(ptr, 0, size);
> +   memset_io((void __iomem *)ptr, 0, size);
>
> return 0;
>  }
> --
> 2.31.1
>
>
>
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4 1/2] radeon: fix coding issues reported from sparse

Applied.  Thanks!

Alex

On Fri, Jun 4, 2021 at 7:53 AM Chen Li  wrote:
>
>
> Also fix some coding issues reported from sparse.
>
> Signed-off-by: Chen Li 
> Acked-by: Christian König 
> ---
>  drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index dfa9fdbe98da..85a1f2c31749 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -152,9 +152,11 @@ int radeon_uvd_init(struct radeon_device *rdev)
>
> rdev->uvd.fw_header_present = true;
>
> -   family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
> -   version_major = (le32_to_cpu(hdr->ucode_version) >> 
> 24) & 0xff;
> -   version_minor = (le32_to_cpu(hdr->ucode_version) >> 
> 8) & 0xff;
> +   family_id = (__force u32)(hdr->ucode_version) & 0xff;
> +   version_major = (le32_to_cpu((__force 
> __le32)(hdr->ucode_version))
> +>> 24) & 0xff;
> +   version_minor = (le32_to_cpu((__force 
> __le32)(hdr->ucode_version))
> +>> 8) & 0xff;
> DRM_INFO("Found UVD firmware Version: %u.%u Family 
> ID: %u\n",
>  version_major, version_minor, family_id);
>
> @@ -791,17 +793,17 @@ int radeon_uvd_get_create_msg(struct radeon_device 
> *rdev, int ring,
> return r;
>
> /* stitch together an UVD create msg */
> -   writel(cpu_to_le32(0x0de4), [0]);
> +   writel((__force u32)cpu_to_le32(0x0de4), [0]);
> writel(0x0, (void __iomem *)[1]);
> -   writel(cpu_to_le32(handle), [2]);
> +   writel((__force u32)cpu_to_le32(handle), [2]);
> writel(0x0, [3]);
> writel(0x0, [4]);
> writel(0x0, [5]);
> writel(0x0, [6]);
> -   writel(cpu_to_le32(0x0780), [7]);
> -   writel(cpu_to_le32(0x0440), [8]);
> +   writel((__force u32)cpu_to_le32(0x0780), [7]);
> +   writel((__force u32)cpu_to_le32(0x0440), [8]);
> writel(0x0, [9]);
> -   writel(cpu_to_le32(0x01b37000), [10]);
> +   writel((__force u32)cpu_to_le32(0x01b37000), [10]);
> for (i = 11; i < 1024; ++i)
> writel(0x0, [i]);
>
> @@ -827,9 +829,9 @@ int radeon_uvd_get_destroy_msg(struct radeon_device 
> *rdev, int ring,
> return r;
>
> /* stitch together an UVD destroy msg */
> -   writel(cpu_to_le32(0x0de4), [0]);
> -   writel(cpu_to_le32(0x0002), [1]);
> -   writel(cpu_to_le32(handle), [2]);
> +   writel((__force u32)cpu_to_le32(0x0de4), [0]);
> +   writel((__force u32)cpu_to_le32(0x0002), [1]);
> +   writel((__force u32)cpu_to_le32(handle), [2]);
> writel(0x0, [3]);
> for (i = 4; i < 1024; ++i)
> writel(0x0, [i]);
> --
> 2.31.1
>
>
>
>
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 0/4] Add "activ bpc" drm property and use it in AMD and Intel driver

I started work on my proposal for better color handling in Linux display
drivers: https://lkml.org/lkml/2021/5/12/764

Since the first read-only property is now implemented for amdgpu and i915 I
wanted to collect some feedback, since the other two read-only properties will
be quite similar, I hope.

I have already commited the first patch in this series independently as it fixes
a function already in use.

The actuall update of the values is implemented in patch three and four in the
atomic_commit_tail() function of amdgpu and i915 respectifly. It does get
updated more often than needed with the current approach, but without harm since
just the same value is written again. A check if the update is required would be
the same amount of computation. Let me know if you know a better place to put
the update than attomic_commit_tail().


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 3/4] drm/amd/display: Add handling for new "active bpc" property

This commits implements the "active bpc" drm property for the AMD GPU driver.

Signed-off-by: Werner Sembach 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 18 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c|  4 +++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6e82889271d5..52a057c585b1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7519,8 +7519,10 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
 
-   if (!aconnector->mst_port)
+   if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   }
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
aconnector->base.state->max_bpc = (connector_type == 
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -8890,6 +8892,20 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(state, connector, new_con_state, i) {
+   struct drm_crtc *crtc = new_con_state->crtc;
+   if (crtc) {
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+   if (dm_new_crtc_state->stream)
+   new_con_state->active_bpc = 
convert_dc_color_depth_into_bpc(
+   
dm_new_crtc_state->stream->timing.display_color_depth);
+   }
+   else
+   new_con_state->active_bpc = 0;
+   }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
  new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9b221db526dc..2a8dc6b2c6c7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -397,8 +397,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
}
 
connector->max_bpc_property = master->base.max_bpc_property;
-   if (connector->max_bpc_property)
+   if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 8, 16);
+   drm_connector_attach_active_bpc_property(>base, 8, 
16);
+   }
 
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.

While "max bpc" can be used to change the color depth, there was no way to check
which one actually got used. While in theory the driver chooses the best/highest
color depth within the max bpc setting a user might not be fully aware what his
hardware is or isn't capable off. This is meant as a quick way to double check
the setup.

In the future, automatic color calibration for screens might also depend on this
information available.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  2 ++
 drivers/gpu/drm/drm_connector.c   | 40 +++
 include/drm/drm_connector.h   | 15 
 3 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..7ae4e40936b5 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+   } else if (property == connector->active_bpc_property) {
+   *val = state->active_bpc;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..5f42a5be5822 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1195,6 +1195,13 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * drm_connector_attach_max_bpc_property() to create and attach the
  * property to the connector during initialization.
  *
+ * active bpc:
+ * This read-only range property is used by userspace check the bit depth
+ * actually applied by the GPU driver after evaluation all hardware
+ * capabilities and max bpc. Drivers to use the function
+ * drm_connector_attach_active_bpc_property() to create and attach the
+ * property to the connector during initialization.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -2150,6 +2157,39 @@ int drm_connector_attach_max_bpc_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
 
+/**
+ * drm_connector_attach_active_bpc_property - attach "active bpc" property
+ * @connector: connector to attach active bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used to check the applied bit depth on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
+ int min, int max)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   prop = connector->active_bpc_property;
+   if (!prop) {
+   prop = drm_property_create_range(dev, 0, "active bpc", min, 
max);
+   if (!prop)
+   return -ENOMEM;
+
+   connector->active_bpc_property = prop;
+   }
+
+   drm_object_attach_property(>base, prop, 0);
+   connector->state->active_bpc = 0;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
 /**
  * drm_connector_set_vrr_capable_property - sets the variable refresh rate
  * capable property for a connector
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..c58cba2b6afe 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -781,6 +781,13 @@ struct drm_connector_state {
 */
u8 max_bpc;
 
+   /**
+* @active_bpc: Read only property set by the GPU driver to the actually
+* applied bit depth of the pixels after evaluating all hardware
+* limitations.
+*/
+   u8 active_bpc;
+
/**
 * @hdr_output_metadata:
 * DRM blob property for HDR output metadata
@@ -1380,6 +1387,12 @@ struct drm_connector {
 */
struct drm_property *max_bpc_property;
 
+   /**
+* @active_bpc_property: Default connector property for the active bpc
+* to be driven out of the connector.
+*/
+   struct drm_property *active_bpc_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
 #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_with_quirk(
int width, int height);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,

[PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property

This commits implements the "active bpc" drm property for the Intel GPU driver.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/i915/display/intel_display.c | 13 +
 drivers/gpu/drm/i915/display/intel_dp.c  |  8 ++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  4 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c|  4 +++-
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 64e9107d70f7..f7898d9d7438 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
struct intel_crtc *crtc;
+   struct drm_connector *connector;
+   struct drm_connector_state *new_conn_state;
u64 put_domains[I915_MAX_PIPES] = {};
intel_wakeref_t wakeref = 0;
int i;
@@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
}
intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
 
+   /* Extract information from crtc to communicate it to userspace as 
connector properties */
+   for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {
+   struct drm_crtc *crtc = new_conn_state->crtc;
+   if (crtc) {
+   new_crtc_state = 
to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));
+   new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 
3;
+   }
+   else
+   new_conn_state->active_bpc = 0;
+   }
+
/*
 * Defer the cleanup of the old state to a separate worker to not
 * impede the current task (userspace for blocking modesets) that
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 642c60f3d9b1..67826ba976ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
-   if (HAS_GMCH(dev_priv))
+   if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
-   else if (DISPLAY_VER(dev_priv) >= 5)
+   drm_connector_attach_active_bpc_property(connector, 6, 10);
+   }
+   else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+   }
 
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2daa3f67791e..5a1869dc2210 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -844,8 +844,10 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 */
connector->max_bpc_property =
intel_dp->attached_connector->base.max_bpc_property;
-   if (connector->max_bpc_property)
+   if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+   drm_connector_attach_active_bpc_property(connector, 6, 12);
+   }
 
return connector;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index d69f0a6dc26d..8af78b27b6ce 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
drm_object_attach_property(>base,

connector->dev->mode_config.hdr_output_metadata_property, 0);
 
-   if (!HAS_GMCH(dev_priv))
+   if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+   drm_connector_attach_active_bpc_property(connector, 8, 12);
+   }
 }
 
 /*
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/4] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 389eff96fcf6..6e82889271d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6515,6 +6515,10 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 14;
case COLOR_DEPTH_161616:
return 16;
+   case COLOR_DEPTH_999:
+   return 9;
+   case COLOR_DEPTH_11:
+   return 11;
default:
break;
}
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/display: Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check

2021-06-04 Thread Mark Yacoub

From: Mark Yacoub 

For each CRTC state, check the size of Gamma and Degamma LUTs  so
unexpected and larger sizes wouldn't slip through.

TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes

Signed-off-by: Mark Yacoub 
Change-Id: I9d513a38e8ac2af1b4bf802e1feb1a4d726fba4c
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  1 +
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 40 ---
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 38d497d30dba8..f6cd522b42a80 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9402,6 +9402,9 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
dm_old_crtc_state->dsc_force_changed == false)
continue;
 
+   if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
+   goto fail;
+
if (!new_crtc_state->enable)
continue;
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 8bfe901cf2374..1b77cd2612691 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -541,6 +541,7 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
 #define MAX_COLOR_LEGACY_LUT_ENTRIES 256
 
 void amdgpu_dm_init_color_mod(void);
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state);
 int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc);
 int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc,
  struct dc_plane_state *dc_plane_state);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 157fe4efbb599..da6f9fcc0b415 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -284,6 +284,37 @@ static int __set_input_tf(struct dc_transfer_func *func,
return res ? 0 : -ENOMEM;
 }
 
+/**
+ * Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are of
+ * the expected size.
+ * Returns 0 on success.
+ */
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
+{
+   const struct drm_color_lut *lut = NULL;
+   uint32_t size = 0;
+
+   lut = __extract_blob_lut(crtc_state->degamma_lut, );
+   if (lut && size != MAX_COLOR_LUT_ENTRIES) {
+   DRM_DEBUG_DRIVER(
+   "Invalid Degamma LUT size. Should be %u but got %u.\n",
+   MAX_COLOR_LUT_ENTRIES, size);
+   return -EINVAL;
+   }
+
+   lut = __extract_blob_lut(crtc_state->gamma_lut, );
+   if (lut && size != MAX_COLOR_LUT_ENTRIES &&
+   size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
+   DRM_DEBUG_DRIVER(
+   "Invalid Gamma LUT size. Should be %u (or %u for 
legacy) but got %u.\n",
+   MAX_COLOR_LUT_ENTRIES, MAX_COLOR_LEGACY_LUT_ENTRIES,
+   size);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /**
  * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream.
  * @crtc: amdgpu_dm crtc state
@@ -317,14 +348,11 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state 
*crtc)
bool is_legacy;
int r;
 
-   degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
-   if (degamma_lut && degamma_size != MAX_COLOR_LUT_ENTRIES)
-   return -EINVAL;
+   if ((r = amdgpu_dm_verify_lut_sizes(>base)))
+   return r;
 
+   degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
regamma_lut = __extract_blob_lut(crtc->base.gamma_lut, _size);
-   if (regamma_lut && regamma_size != MAX_COLOR_LUT_ENTRIES &&
-   regamma_size != MAX_COLOR_LEGACY_LUT_ENTRIES)
-   return -EINVAL;
 
has_degamma =
degamma_lut && !__is_lut_linear(degamma_lut, degamma_size);
-- 
2.32.0.rc1.229.g3e70b5a671-goog

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check

2021-06-04 Thread Mark Yacoub

From: Mark Yacoub 

For each CRTC state, check the size of Gamma and Degamma LUTs  so
unexpected and larger sizes wouldn't slip through.

TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes

Signed-off-by: Mark Yacoub 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  1 +
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 40 ---
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 38d497d30dba8..f6cd522b42a80 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9402,6 +9402,9 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
dm_old_crtc_state->dsc_force_changed == false)
continue;
 
+   if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
+   goto fail;
+
if (!new_crtc_state->enable)
continue;
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 8bfe901cf2374..1b77cd2612691 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -541,6 +541,7 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
 #define MAX_COLOR_LEGACY_LUT_ENTRIES 256
 
 void amdgpu_dm_init_color_mod(void);
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state);
 int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc);
 int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc,
  struct dc_plane_state *dc_plane_state);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 157fe4efbb599..da6f9fcc0b415 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -284,6 +284,37 @@ static int __set_input_tf(struct dc_transfer_func *func,
return res ? 0 : -ENOMEM;
 }
 
+/**
+ * Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are of
+ * the expected size.
+ * Returns 0 on success.
+ */
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
+{
+   const struct drm_color_lut *lut = NULL;
+   uint32_t size = 0;
+
+   lut = __extract_blob_lut(crtc_state->degamma_lut, );
+   if (lut && size != MAX_COLOR_LUT_ENTRIES) {
+   DRM_DEBUG_DRIVER(
+   "Invalid Degamma LUT size. Should be %u but got %u.\n",
+   MAX_COLOR_LUT_ENTRIES, size);
+   return -EINVAL;
+   }
+
+   lut = __extract_blob_lut(crtc_state->gamma_lut, );
+   if (lut && size != MAX_COLOR_LUT_ENTRIES &&
+   size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
+   DRM_DEBUG_DRIVER(
+   "Invalid Gamma LUT size. Should be %u (or %u for 
legacy) but got %u.\n",
+   MAX_COLOR_LUT_ENTRIES, MAX_COLOR_LEGACY_LUT_ENTRIES,
+   size);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /**
  * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream.
  * @crtc: amdgpu_dm crtc state
@@ -317,14 +348,11 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state 
*crtc)
bool is_legacy;
int r;
 
-   degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
-   if (degamma_lut && degamma_size != MAX_COLOR_LUT_ENTRIES)
-   return -EINVAL;
+   if ((r = amdgpu_dm_verify_lut_sizes(>base)))
+   return r;
 
+   degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
regamma_lut = __extract_blob_lut(crtc->base.gamma_lut, _size);
-   if (regamma_lut && regamma_size != MAX_COLOR_LUT_ENTRIES &&
-   regamma_size != MAX_COLOR_LEGACY_LUT_ENTRIES)
-   return -EINVAL;
 
has_degamma =
degamma_lut && !__is_lut_linear(degamma_lut, degamma_size);
-- 
2.32.0.rc1.229.g3e70b5a671-goog

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check

2021-06-04 Thread Mark Yacoub

Ignore this patch, in favor of (
https://patchwork.freedesktop.org/series/91023/), which appends the commit
title with drm/amd/display.


On Fri, Jun 4, 2021 at 12:59 PM Mark Yacoub  wrote:

> From: Mark Yacoub 
>
> For each CRTC state, check the size of Gamma and Degamma LUTs  so
> unexpected and larger sizes wouldn't slip through.
>
> TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
>
> Signed-off-by: Mark Yacoub 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  1 +
>  .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 40 ---
>  3 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 38d497d30dba8..f6cd522b42a80 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9402,6 +9402,9 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> dm_old_crtc_state->dsc_force_changed == false)
> continue;
>
> +   if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
> +   goto fail;
> +
> if (!new_crtc_state->enable)
> continue;
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 8bfe901cf2374..1b77cd2612691 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -541,6 +541,7 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device
> *dev);
>  #define MAX_COLOR_LEGACY_LUT_ENTRIES 256
>
>  void amdgpu_dm_init_color_mod(void);
> +int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state);
>  int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc);
>  int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc,
>   struct dc_plane_state
> *dc_plane_state);
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 157fe4efbb599..da6f9fcc0b415 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -284,6 +284,37 @@ static int __set_input_tf(struct dc_transfer_func
> *func,
> return res ? 0 : -ENOMEM;
>  }
>
> +/**
> + * Verifies that the Degamma and Gamma LUTs attached to the |crtc_state|
> are of
> + * the expected size.
> + * Returns 0 on success.
> + */
> +int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
> +{
> +   const struct drm_color_lut *lut = NULL;
> +   uint32_t size = 0;
> +
> +   lut = __extract_blob_lut(crtc_state->degamma_lut, );
> +   if (lut && size != MAX_COLOR_LUT_ENTRIES) {
> +   DRM_DEBUG_DRIVER(
> +   "Invalid Degamma LUT size. Should be %u but got
> %u.\n",
> +   MAX_COLOR_LUT_ENTRIES, size);
> +   return -EINVAL;
> +   }
> +
> +   lut = __extract_blob_lut(crtc_state->gamma_lut, );
> +   if (lut && size != MAX_COLOR_LUT_ENTRIES &&
> +   size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
> +   DRM_DEBUG_DRIVER(
> +   "Invalid Gamma LUT size. Should be %u (or %u for
> legacy) but got %u.\n",
> +   MAX_COLOR_LUT_ENTRIES,
> MAX_COLOR_LEGACY_LUT_ENTRIES,
> +   size);
> +   return -EINVAL;
> +   }
> +
> +   return 0;
> +}
> +
>  /**
>   * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC
> stream.
>   * @crtc: amdgpu_dm crtc state
> @@ -317,14 +348,11 @@ int amdgpu_dm_update_crtc_color_mgmt(struct
> dm_crtc_state *crtc)
> bool is_legacy;
> int r;
>
> -   degamma_lut = __extract_blob_lut(crtc->base.degamma_lut,
> _size);
> -   if (degamma_lut && degamma_size != MAX_COLOR_LUT_ENTRIES)
> -   return -EINVAL;
> +   if ((r = amdgpu_dm_verify_lut_sizes(>base)))
> +   return r;
>
> +   degamma_lut = __extract_blob_lut(crtc->base.degamma_lut,
> _size);
> regamma_lut = __extract_blob_lut(crtc->base.gamma_lut,
> _size);
> -   if (regamma_lut && regamma_size != MAX_COLOR_LUT_ENTRIES &&
> -   regamma_size != MAX_COLOR_LEGACY_LUT_ENTRIES)
> -   return -EINVAL;
>
> has_degamma =
> degamma_lut && !__is_lut_linear(degamma_lut, degamma_size);
> --
> 2.32.0.rc1.229.g3e70b5a671-goog
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm: amdgpu: Remove unneeded semicolon in amdgpu_vm.c

Applied.  Thanks!

Alex

On Fri, Jun 4, 2021 at 3:03 AM Christian König
 wrote:
>
> Am 03.06.21 um 05:28 schrieb Wan Jiabing:
> > Fix following coccicheck warning:
> > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1726:2-3: Unneeded semicolon
> >
> > Signed-off-by: Wan Jiabing 
>
> Reviewed-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > index 2460371..231745b 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > @@ -1723,7 +1723,7 @@ int amdgpu_vm_bo_update_mapping(struct amdgpu_device 
> > *adev,
> >
> >   amdgpu_res_next(, num_entries * AMDGPU_GPU_PAGE_SIZE);
> >   start = tmp;
> > - };
> > + }
> >
> >   r = vm->update_funcs->commit(, fence);
> >
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH][next] drm/amd/pm: Fix fall-through warning for Clang

Applied.  Thanks!

Alex

On Fri, Jun 4, 2021 at 1:05 AM Gustavo A. R. Silva
 wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva 
> ---
> JFYI: We had thousands of these sorts of warnings and now we are down
>   to just 22 in linux-next. This is one of those last remaining
>   warnings. :)
>
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c 
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> index 8f71f6a4bb49..43c3f6e755e7 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> @@ -831,6 +831,7 @@ static int smu10_dpm_force_dpm_level(struct pp_hwmgr 
> *hwmgr,
> break;
> case AMD_DPM_FORCED_LEVEL_MANUAL:
> data->fine_grain_enabled = 1;
> +   break;
> case AMD_DPM_FORCED_LEVEL_PROFILE_EXIT:
> default:
> break;
> --
> 2.27.0
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH V2 3/5] drm/amdgpu: correct the audio function initial Dstate





On 6/4/2021 3:28 PM, Evan Quan wrote:

On driver loading, the ASIC is in D0 state. The bundled
audio function should be in the same state also.

Change-Id: I136e196be7633e95883a7f6c33963f7583e9bad1
Signed-off-by: Evan Quan 
---
V1->V2:
   - Lijo: include the code in a seperate API for better readability
   - limit the change for Navi10 and later dGPUs
   - comments more about the background
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 40 +
  1 file changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index c354ffa62483..e9f2161738d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -123,6 +123,22 @@ void amdgpu_register_gpu_instance(struct amdgpu_device 
*adev)
mutex_unlock(_info.mutex);
  }
  
+static void amdgpu_get_audio_func(struct amdgpu_device *adev)

+{
+   struct pci_dev *p = NULL;
+
+   p = pci_get_domain_bus_and_slot(pci_domain_nr(adev->pdev->bus),
+   adev->pdev->bus->number, 1);
+   if (p) {
+   pm_runtime_get_sync(>dev);
+
+   pm_runtime_mark_last_busy(>dev);
+   pm_runtime_put_autosuspend(>dev);
+
+   pci_dev_put(p);
+   }
+}
+
  /**
   * amdgpu_driver_load_kms - Main load function for KMS.
   *
@@ -212,9 +228,33 @@ int amdgpu_driver_load_kms(struct amdgpu_device *adev, 
unsigned long flags)
DPM_FLAG_MAY_SKIP_RESUME);
pm_runtime_use_autosuspend(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, 5000);
+
pm_runtime_allow(dev->dev);
+
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
+
+   /*
+* For runpm implemented via BACO, PMFW will handle the
+* timing for BACO in and out:
+*   - put ASIC into BACO state only when both video and
+* audio functions are in D3 state.
+*   - pull ASIC out of BACO state when either video or
+* audio function is in D0 state.
+* Also, at startup, PMFW assumes both functions are in
+* D0 state.
+*
+* So if snd driver was loaded prior to amdgpu driver
+* and audio function was put into D3 state behind PMFW's
+* back, the BACO may not correctly kicks in and out.
+*
+* Via amdgpu_get_audio_func() below, the audio function
+* is guarded to be in D0 correctly.
+*/


On a second look at the comments - should runpm _get on audio dev be 
done before doing device_init (so that it's in D0 while FW is getting 
loaded) and put done here?


Thanks,
Lijo


+   if (amdgpu_device_supports_baco(dev) &&
+   !(adev->flags & AMD_IS_APU) &&
+   (adev->asic_type >= CHIP_NAVI10))
+   amdgpu_get_audio_func(adev);
}
  
  	if (amdgpu_acpi_smart_shift_update(dev, AMDGPU_SS_DRV_LOAD))



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH V2 4/5] drm/amd/pm: clear the cached dpm feature status





On 6/4/2021 3:28 PM, Evan Quan wrote:

For some ASICs, the real dpm feature disablement job is handled by
PMFW during baco reset and custom pptable loading. Cached dpm feature
status need to be cleared to pair that.

Change-Id: I9e37d80e13599833301c04711b097fb37c2e41f9
Signed-off-by: Evan Quan 
---
V1->V2:
   - correct the setting for baco bit(pointed out by Lijo)
---
  drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h   |  6 +
  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 19 --
  .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   |  1 +
  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  1 +
  drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c| 25 +++
  drivers/gpu/drm/amd/pm/swsmu/smu_cmn.h|  3 +++
  drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |  1 +
  7 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
index fb7438224872..3f9b2a839a37 100644
--- a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
@@ -937,6 +937,12 @@ struct pptable_funcs {
 */
int (*disable_all_features_with_exception)(struct smu_context *smu, 
enum smu_feature_mask mask);
  
+	/**

+* @clear_cached_dpm_feature_status_with_exception: Clear cached dpm 
feature status with
+*  exception to those in 

+*/
+   int (*clear_cached_dpm_feature_status_with_exception)(struct 
smu_context *smu, enum smu_feature_mask mask);
+


Since this is a just a utility function which clears sw bitmask without 
touching hardware, do we need a ppt_func? In case that is needed, we 
already have this - smu_cmn_disable_all_features_with_exception. So, 
can't this remain as a standalone smu_cmn function which can be called 
from anywhere? Nowadays, I get a red alert when a ppt_func gets added :)


Thanks,
Lijo


/**
 * @notify_display_change: Enable fast memory clock switching.
 *
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c 
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index c9a31556e077..aba475d06507 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1352,6 +1352,16 @@ static int smu_hw_init(void *handle)
return 0;
  }
  
+static void smu_reset_cached_dpm_feature_status(struct smu_context *smu)

+{
+   struct smu_feature *feature = >smu_feature;
+
+   mutex_lock(>mutex);
+   bitmap_zero(feature->enabled, feature->feature_num);
+   bitmap_zero(feature->supported, feature->feature_num);
+   mutex_unlock(>mutex);
+}
+
  static int smu_disable_dpms(struct smu_context *smu)
  {
struct amdgpu_device *adev = smu->adev;
@@ -1374,16 +1384,21 @@ static int smu_disable_dpms(struct smu_context *smu)
 */
if (smu->uploading_custom_pp_table &&
(adev->asic_type >= CHIP_NAVI10) &&
-   (adev->asic_type <= CHIP_DIMGREY_CAVEFISH))
+   (adev->asic_type <= CHIP_DIMGREY_CAVEFISH)) {
+   smu_reset_cached_dpm_feature_status(smu);
return 0;
+   }
  
  	/*

 * For Sienna_Cichlid, PMFW will handle the features disablement 
properly
 * on BACO in. Driver involvement is unnecessary.
 */
if ((adev->asic_type == CHIP_SIENNA_CICHLID) &&
-use_baco)
+use_baco) {
+   smu_clear_cached_dpm_feature_status_with_exception(smu,
+  
SMU_FEATURE_BACO_BIT);
return 0;
+   }
  
  	/*

 * For gpu reset, runpm and hibernation through BACO,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index afd4bd850c63..8c3ea20fb0f6 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -3083,6 +3083,7 @@ static const struct pptable_funcs navi10_ppt_funcs = {
.get_enabled_mask = smu_cmn_get_enabled_mask,
.feature_is_enabled = smu_cmn_feature_is_enabled,
.disable_all_features_with_exception = 
smu_cmn_disable_all_features_with_exception,
+   .clear_cached_dpm_feature_status_with_exception = 
smu_cmn_clear_cached_dpm_feature_status_with_exception,
.notify_display_change = smu_v11_0_notify_display_change,
.set_power_limit = smu_v11_0_set_power_limit,
.init_max_sustainable_clocks = smu_v11_0_init_max_sustainable_clocks,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index b4a2bb0f3f4c..14a14c30ee5e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -3886,6 +3886,7 @@ static const struct pptable_funcs 
sienna_cichlid_ppt_funcs = {
.get_enabled_mask = smu_cmn_get_enabled_mask,

RE: [PATCH 3/3] drm/amd/pm: Use generic BACO function for smu11 ASICs

[Public]

Series is reviewed-by: Evan Quan 

From: Lazar, Lijo 
Sent: Friday, June 4, 2021 5:12 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Quan, Evan ; 
Feng, Kenneth 
Subject: [PATCH 3/3] drm/amd/pm: Use generic BACO function for smu11 ASICs


[Public]

Remove ASIC specific functions for BACO support check. Use generic smu11
function instead.

Signed-off-by: Lijo Lazar mailto:lijo.la...@amd.com>>
---
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c| 12 +---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c  | 12 +---
.../gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c  | 12 +---
3 files changed, 3 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index 5c248accc4a6..5959019f51ad 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -2162,16 +2162,6 @@ static void arcturus_get_unique_id(struct smu_context 
*smu)
   sprintf(adev->serial, "%llx", id);
}

-static bool arcturus_is_baco_supported(struct smu_context *smu)
-{
-  struct amdgpu_device *adev = smu->adev;
-
-  if (!smu_v11_0_baco_is_support(smu) || amdgpu_sriov_vf(adev))
-  return false;
-
-  return true;
-}
-
static int arcturus_set_df_cstate(struct smu_context *smu,
 enum 
pp_df_cstate state)
{
@@ -2406,7 +2396,7 @@ static const struct pptable_funcs arcturus_ppt_funcs = {
   .register_irq_handler = smu_v11_0_register_irq_handler,
   .set_azalia_d3_pme = smu_v11_0_set_azalia_d3_pme,
   .get_max_sustainable_clocks_by_dc = 
smu_v11_0_get_max_sustainable_clocks_by_dc,
-  .baco_is_support= arcturus_is_baco_supported,
+ .baco_is_support = smu_v11_0_baco_is_support,
   .baco_get_state = smu_v11_0_baco_get_state,
   .baco_set_state = smu_v11_0_baco_set_state,
   .baco_enter = smu_v11_0_baco_enter,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 31e9cc3f3ea0..74a8c676e22c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -2257,16 +2257,6 @@ static int 
navi10_overdrive_get_gfx_clk_base_voltage(struct smu_context *smu,
   return 0;
}

-static bool navi10_is_baco_supported(struct smu_context *smu)
-{
-  struct amdgpu_device *adev = smu->adev;
-
-  if (amdgpu_sriov_vf(adev) || (!smu_v11_0_baco_is_support(smu)))
-  return false;
-
-  return true;
-}
-
static int navi10_set_default_od_settings(struct smu_context *smu)
{
   OverDriveTable_t *od_table =
@@ -3102,7 +3092,7 @@ static const struct pptable_funcs navi10_ppt_funcs = {
   .register_irq_handler = smu_v11_0_register_irq_handler,
   .set_azalia_d3_pme = smu_v11_0_set_azalia_d3_pme,
   .get_max_sustainable_clocks_by_dc = 
smu_v11_0_get_max_sustainable_clocks_by_dc,
-  .baco_is_support= navi10_is_baco_supported,
+ .baco_is_support = smu_v11_0_baco_is_support,
   .baco_get_state = smu_v11_0_baco_get_state,
   .baco_set_state = smu_v11_0_baco_set_state,
   .baco_enter = smu_v11_0_baco_enter,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 6614dbb723be..f01e919e1f89 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -2100,16 +2100,6 @@ static int sienna_cichlid_run_btc(struct smu_context 
*smu)
   return smu_cmn_send_smc_msg(smu, SMU_MSG_RunDcBtc, NULL);
}

-static bool sienna_cichlid_is_baco_supported(struct smu_context *smu)
-{
-  struct amdgpu_device *adev = smu->adev;
-
-  if (amdgpu_sriov_vf(adev) || (!smu_v11_0_baco_is_support(smu)))
-  return false;
-
-  return true;
-}
-
static bool sienna_cichlid_is_mode1_reset_supported(struct smu_context *smu)
{
   struct amdgpu_device *adev = smu->adev;
@@ -3882,7 +3872,7 @@ static const struct pptable_funcs 
sienna_cichlid_ppt_funcs = {
   .register_irq_handler = smu_v11_0_register_irq_handler,
   .set_azalia_d3_pme = smu_v11_0_set_azalia_d3_pme,
   .get_max_sustainable_clocks_by_dc = 
smu_v11_0_get_max_sustainable_clocks_by_dc,
-  .baco_is_support= sienna_cichlid_is_baco_supported,
+ .baco_is_support = smu_v11_0_baco_is_support,
   .baco_get_state = smu_v11_0_baco_get_state,
   .baco_set_state = smu_v11_0_baco_set_state,
   .baco_enter = smu_v11_0_baco_enter,
--

[PATCH V2 4/5] drm/amd/pm: clear the cached dpm feature status

For some ASICs, the real dpm feature disablement job is handled by
PMFW during baco reset and custom pptable loading. Cached dpm feature
status need to be cleared to pair that.

Change-Id: I9e37d80e13599833301c04711b097fb37c2e41f9
Signed-off-by: Evan Quan 
---
V1->V2:
  - correct the setting for baco bit(pointed out by Lijo)
---
 drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h   |  6 +
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 19 --
 .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   |  1 +
 .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  1 +
 drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c| 25 +++
 drivers/gpu/drm/amd/pm/swsmu/smu_cmn.h|  3 +++
 drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |  1 +
 7 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
index fb7438224872..3f9b2a839a37 100644
--- a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
@@ -937,6 +937,12 @@ struct pptable_funcs {
 */
int (*disable_all_features_with_exception)(struct smu_context *smu, 
enum smu_feature_mask mask);
 
+   /**
+* @clear_cached_dpm_feature_status_with_exception: Clear cached dpm 
feature status with
+*  exception to those 
in 
+*/
+   int (*clear_cached_dpm_feature_status_with_exception)(struct 
smu_context *smu, enum smu_feature_mask mask);
+
/**
 * @notify_display_change: Enable fast memory clock switching.
 *
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c 
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index c9a31556e077..aba475d06507 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1352,6 +1352,16 @@ static int smu_hw_init(void *handle)
return 0;
 }
 
+static void smu_reset_cached_dpm_feature_status(struct smu_context *smu)
+{
+   struct smu_feature *feature = >smu_feature;
+
+   mutex_lock(>mutex);
+   bitmap_zero(feature->enabled, feature->feature_num);
+   bitmap_zero(feature->supported, feature->feature_num);
+   mutex_unlock(>mutex);
+}
+
 static int smu_disable_dpms(struct smu_context *smu)
 {
struct amdgpu_device *adev = smu->adev;
@@ -1374,16 +1384,21 @@ static int smu_disable_dpms(struct smu_context *smu)
 */
if (smu->uploading_custom_pp_table &&
(adev->asic_type >= CHIP_NAVI10) &&
-   (adev->asic_type <= CHIP_DIMGREY_CAVEFISH))
+   (adev->asic_type <= CHIP_DIMGREY_CAVEFISH)) {
+   smu_reset_cached_dpm_feature_status(smu);
return 0;
+   }
 
/*
 * For Sienna_Cichlid, PMFW will handle the features disablement 
properly
 * on BACO in. Driver involvement is unnecessary.
 */
if ((adev->asic_type == CHIP_SIENNA_CICHLID) &&
-use_baco)
+use_baco) {
+   smu_clear_cached_dpm_feature_status_with_exception(smu,
+  
SMU_FEATURE_BACO_BIT);
return 0;
+   }
 
/*
 * For gpu reset, runpm and hibernation through BACO,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index afd4bd850c63..8c3ea20fb0f6 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -3083,6 +3083,7 @@ static const struct pptable_funcs navi10_ppt_funcs = {
.get_enabled_mask = smu_cmn_get_enabled_mask,
.feature_is_enabled = smu_cmn_feature_is_enabled,
.disable_all_features_with_exception = 
smu_cmn_disable_all_features_with_exception,
+   .clear_cached_dpm_feature_status_with_exception = 
smu_cmn_clear_cached_dpm_feature_status_with_exception,
.notify_display_change = smu_v11_0_notify_display_change,
.set_power_limit = smu_v11_0_set_power_limit,
.init_max_sustainable_clocks = smu_v11_0_init_max_sustainable_clocks,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index b4a2bb0f3f4c..14a14c30ee5e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -3886,6 +3886,7 @@ static const struct pptable_funcs 
sienna_cichlid_ppt_funcs = {
.get_enabled_mask = smu_cmn_get_enabled_mask,
.feature_is_enabled = smu_cmn_feature_is_enabled,
.disable_all_features_with_exception = 
smu_cmn_disable_all_features_with_exception,
+   .clear_cached_dpm_feature_status_with_exception = 
smu_cmn_clear_cached_dpm_feature_status_with_exception,
.notify_display_change = NULL,
.set_power_limit = smu_v11_0_set_power_limit,
.init_max_sustainable_clocks =

[PATCH V2 5/5] drm/amd/pm: correct the dpm features disablement for Navi1x

For BACO scenario, PMFW will handle the dpm features disablement
and interaction with RLC properly. Driver involvement is unnecessary
and error prone.

Change-Id: I19363fc08568be4b7d3f2ec6eba21ccf8fff6c37
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c 
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index aba475d06507..0fac45012e16 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1393,7 +1393,8 @@ static int smu_disable_dpms(struct smu_context *smu)
 * For Sienna_Cichlid, PMFW will handle the features disablement 
properly
 * on BACO in. Driver involvement is unnecessary.
 */
-   if ((adev->asic_type == CHIP_SIENNA_CICHLID) &&
+   if (((adev->asic_type == CHIP_SIENNA_CICHLID) ||
+((adev->asic_type >= CHIP_NAVI10) && (adev->asic_type <= 
CHIP_NAVI12))) &&
 use_baco) {
smu_clear_cached_dpm_feature_status_with_exception(smu,
   
SMU_FEATURE_BACO_BIT);
-- 
2.29.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH V2 2/5] drm/amd/pm: correct the runpm handling for BACO supported ASIC

Via the fSMC_MSG_ArmD3 message, PMFW can properly act on the
Dstate change. Driver involvement for determining the timing for
BACO enter/exit is not needed.

Change-Id: Id9ab5e308ff1873888d0acd822c71b0a303fbb01
Signed-off-by: Evan Quan 
---
V1->V2:
  - limit the changes for Navi1x and Sienna_Cichlid which support
the fSMC_MSG_ArmD3 message
---
 drivers/gpu/drm/amd/pm/inc/smu_v11_0.h|  3 +++
 .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 27 +--
 .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 27 +--
 .../gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c| 11 ++--
 4 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h 
b/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
index a3b28979bc82..1962a5877191 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
@@ -244,6 +244,9 @@ int smu_v11_0_baco_set_state(struct smu_context *smu, enum 
smu_baco_state state)
 int smu_v11_0_baco_enter(struct smu_context *smu);
 int smu_v11_0_baco_exit(struct smu_context *smu);
 
+int smu_v11_0_baco_set_armd3_sequence(struct smu_context *smu,
+ enum smu_v11_0_baco_seq baco_seq);
+
 int smu_v11_0_mode1_reset(struct smu_context *smu);
 
 int smu_v11_0_get_dpm_ultimate_freq(struct smu_context *smu, enum smu_clk_type 
clk_type,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 32a52c1bea07..afd4bd850c63 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -2240,6 +2240,29 @@ static bool navi10_is_baco_supported(struct smu_context 
*smu)
return (val & RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true : false;
 }
 
+static int navi10_baco_enter(struct smu_context *smu)
+{
+   struct amdgpu_device *adev = smu->adev;
+
+   if (adev->in_runpm)
+   return smu_v11_0_baco_set_armd3_sequence(smu, BACO_SEQ_BACO);
+   else
+   return smu_v11_0_baco_enter(smu);
+}
+
+static int navi10_baco_exit(struct smu_context *smu)
+{
+   struct amdgpu_device *adev = smu->adev;
+
+   if (adev->in_runpm) {
+   /* Wait for PMFW handling for the Dstate change */
+   msleep(10);
+   return smu_v11_0_baco_set_armd3_sequence(smu, BACO_SEQ_ULPS);
+   } else {
+   return smu_v11_0_baco_exit(smu);
+   }
+}
+
 static int navi10_set_default_od_settings(struct smu_context *smu)
 {
OverDriveTable_t *od_table =
@@ -3078,8 +3101,8 @@ static const struct pptable_funcs navi10_ppt_funcs = {
.baco_is_support= navi10_is_baco_supported,
.baco_get_state = smu_v11_0_baco_get_state,
.baco_set_state = smu_v11_0_baco_set_state,
-   .baco_enter = smu_v11_0_baco_enter,
-   .baco_exit = smu_v11_0_baco_exit,
+   .baco_enter = navi10_baco_enter,
+   .baco_exit = navi10_baco_exit,
.get_dpm_ultimate_freq = smu_v11_0_get_dpm_ultimate_freq,
.set_soft_freq_limited_range = smu_v11_0_set_soft_freq_limited_range,
.set_default_od_settings = navi10_set_default_od_settings,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 095492bd635f..b4a2bb0f3f4c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -2106,6 +2106,29 @@ static bool sienna_cichlid_is_baco_supported(struct 
smu_context *smu)
return (val & RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true : false;
 }
 
+static int sienna_cichlid_baco_enter(struct smu_context *smu)
+{
+   struct amdgpu_device *adev = smu->adev;
+
+   if (adev->in_runpm)
+   return smu_v11_0_baco_set_armd3_sequence(smu, BACO_SEQ_BACO);
+   else
+   return smu_v11_0_baco_enter(smu);
+}
+
+static int sienna_cichlid_baco_exit(struct smu_context *smu)
+{
+   struct amdgpu_device *adev = smu->adev;
+
+   if (adev->in_runpm) {
+   /* Wait for PMFW handling for the Dstate change */
+   msleep(10);
+   return smu_v11_0_baco_set_armd3_sequence(smu, BACO_SEQ_ULPS);
+   } else {
+   return smu_v11_0_baco_exit(smu);
+   }
+}
+
 static bool sienna_cichlid_is_mode1_reset_supported(struct smu_context *smu)
 {
struct amdgpu_device *adev = smu->adev;
@@ -3881,8 +3904,8 @@ static const struct pptable_funcs 
sienna_cichlid_ppt_funcs = {
.baco_is_support= sienna_cichlid_is_baco_supported,
.baco_get_state = smu_v11_0_baco_get_state,
.baco_set_state = smu_v11_0_baco_set_state,
-   .baco_enter = smu_v11_0_baco_enter,
-   .baco_exit = smu_v11_0_baco_exit,
+   .baco_enter = sienna_cichlid_baco_enter,
+   .baco_exit = sienna_cichlid_baco_exit,
.mode1_reset_is_support = sienna_cichlid_is_mode1_reset_supported,

[PATCH V2 1/5] drm/amd/pm: drop the incomplete fix for Navi14 runpm issue

As the fix by adding PPSMC_MSG_PrepareMp1ForUnload is proved to
be incomplete. Another fix(see link below) has been sent out.
Link: 
https://lore.kernel.org/linux-pci/20210602021255.939090-1-evan.q...@amd.com/

Change-Id: I2a39688cdf9009885594663cd9ec99d4cfca0088
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |  5 +---
 .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 26 +--
 2 files changed, 2 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 55378c6b9722..09ee34312268 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -2176,10 +2176,7 @@ static int psp_load_smu_fw(struct psp_context *psp)
if ((amdgpu_in_reset(adev) &&
 ras && adev->ras_enabled &&
 (adev->asic_type == CHIP_ARCTURUS ||
- adev->asic_type == CHIP_VEGA20)) ||
-(adev->in_runpm &&
- adev->asic_type >= CHIP_NAVI10 &&
- adev->asic_type <= CHIP_NAVI12)) {
+ adev->asic_type == CHIP_VEGA20))) {
ret = amdgpu_dpm_set_mp1_state(adev, PP_MP1_STATE_UNLOAD);
if (ret) {
DRM_WARN("Failed to set MP1 state prepare for 
reload\n");
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index d28236ba0018..32a52c1bea07 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -431,30 +431,6 @@ static int navi10_store_powerplay_table(struct smu_context 
*smu)
return 0;
 }
 
-static int navi10_set_mp1_state(struct smu_context *smu,
-   enum pp_mp1_state mp1_state)
-{
-   struct amdgpu_device *adev = smu->adev;
-   uint32_t mp1_fw_flags;
-   int ret = 0;
-
-   ret = smu_cmn_set_mp1_state(smu, mp1_state);
-   if (ret)
-   return ret;
-
-   if (mp1_state == PP_MP1_STATE_UNLOAD) {
-   mp1_fw_flags = RREG32_PCIE(MP1_Public |
-  (smnMP1_FIRMWARE_FLAGS & 
0x));
-
-   mp1_fw_flags &= ~MP1_FIRMWARE_FLAGS__INTERRUPTS_ENABLED_MASK;
-
-   WREG32_PCIE(MP1_Public |
-   (smnMP1_FIRMWARE_FLAGS & 0x), mp1_fw_flags);
-   }
-
-   return 0;
-}
-
 static int navi10_setup_pptable(struct smu_context *smu)
 {
int ret = 0;
@@ -3119,7 +3095,7 @@ static const struct pptable_funcs navi10_ppt_funcs = {
.get_fan_parameters = navi10_get_fan_parameters,
.post_init = navi10_post_smu_init,
.interrupt_work = smu_v11_0_interrupt_work,
-   .set_mp1_state = navi10_set_mp1_state,
+   .set_mp1_state = smu_cmn_set_mp1_state,
 };
 
 void navi10_set_ppt_funcs(struct smu_context *smu)
-- 
2.29.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH V2 3/5] drm/amdgpu: correct the audio function initial Dstate

On driver loading, the ASIC is in D0 state. The bundled
audio function should be in the same state also.

Change-Id: I136e196be7633e95883a7f6c33963f7583e9bad1
Signed-off-by: Evan Quan 
---
V1->V2:
  - Lijo: include the code in a seperate API for better readability
  - limit the change for Navi10 and later dGPUs
  - comments more about the background
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 40 +
 1 file changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index c354ffa62483..e9f2161738d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -123,6 +123,22 @@ void amdgpu_register_gpu_instance(struct amdgpu_device 
*adev)
mutex_unlock(_info.mutex);
 }
 
+static void amdgpu_get_audio_func(struct amdgpu_device *adev)
+{
+   struct pci_dev *p = NULL;
+
+   p = pci_get_domain_bus_and_slot(pci_domain_nr(adev->pdev->bus),
+   adev->pdev->bus->number, 1);
+   if (p) {
+   pm_runtime_get_sync(>dev);
+
+   pm_runtime_mark_last_busy(>dev);
+   pm_runtime_put_autosuspend(>dev);
+
+   pci_dev_put(p);
+   }
+}
+
 /**
  * amdgpu_driver_load_kms - Main load function for KMS.
  *
@@ -212,9 +228,33 @@ int amdgpu_driver_load_kms(struct amdgpu_device *adev, 
unsigned long flags)
DPM_FLAG_MAY_SKIP_RESUME);
pm_runtime_use_autosuspend(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, 5000);
+
pm_runtime_allow(dev->dev);
+
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
+
+   /*
+* For runpm implemented via BACO, PMFW will handle the
+* timing for BACO in and out:
+*   - put ASIC into BACO state only when both video and
+* audio functions are in D3 state.
+*   - pull ASIC out of BACO state when either video or
+* audio function is in D0 state.
+* Also, at startup, PMFW assumes both functions are in
+* D0 state.
+*
+* So if snd driver was loaded prior to amdgpu driver
+* and audio function was put into D3 state behind PMFW's
+* back, the BACO may not correctly kicks in and out.
+*
+* Via amdgpu_get_audio_func() below, the audio function
+* is guarded to be in D0 correctly.
+*/
+   if (amdgpu_device_supports_baco(dev) &&
+   !(adev->flags & AMD_IS_APU) &&
+   (adev->asic_type >= CHIP_NAVI10))
+   amdgpu_get_audio_func(adev);
}
 
if (amdgpu_acpi_smart_shift_update(dev, AMDGPU_SS_DRV_LOAD))
-- 
2.29.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb location


Well, but are you the one defining the compatibility policy?

See usually Linux kernel code compatibility policy is that existing 
stuff needs to work forever.


We could argue a bit that the hypervisor components are not open source 
nor uAPI, but that argument is rather thin.


Christian.

Am 04.06.21 um 15:23 schrieb Luo, Zhigang:

[AMD Official Use Only]

Here is our hypervisor driver compatibility policy:
 - Host.y supports Guest.y-1, Guest.y, Guest.y+1
 - Guest.y supported by Host.y-1, Host.y,Host.y+1

Host driver had the feature for gfx9 2 years ago. So, this change meet our 
compatibility policy.

Thanks,
Zhigang

-Original Message-
From: Christian König 
Sent: June 4, 2021 7:14 AM
To: Deng, Emily ; Liu, Shaoyun ; Luo, 
Zhigang ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb 
location

I was just about to question the same thing.

It looks really good to me to have that cleaned up, but if this breaks with 
older versions of the hypervisor then it is a bit questionable change.

Regards,
Christian.

Am 04.06.21 um 03:13 schrieb Deng, Emily:

Do we need to consider backward compatibility?


Best wishes
Emily Deng



-Original Message-
From: amd-gfx  On Behalf Of
Liu, Shaoyun
Sent: Thursday, June 3, 2021 11:10 PM
To: Luo, Zhigang ; amd-gfx@lists.freedesktop.org
Cc: Luo, Zhigang 
Subject: RE: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from
getting fb location

[AMD Official Use Only]

Looks ok to me .

Reviewed-By : Shaoyun.liu 

-Original Message-
From: amd-gfx  On Behalf Of
Zhigang Luo
Sent: Thursday, June 3, 2021 10:13 AM
To: amd-gfx@lists.freedesktop.org
Cc: Luo, Zhigang 
Subject: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from
getting fb location

host driver programmed fb location registers for vf, no need to check anymore.

Signed-off-by: Zhigang Luo 
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index ceb3968d8326..1c2d9fde9021 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -1292,10 +1292,7 @@ static int gmc_v9_0_late_init(void *handle)
static void gmc_v9_0_vram_gtt_location(struct amdgpu_device *adev,
  struct amdgpu_gmc *mc)
{
-u64 base = 0;
-
-if (!amdgpu_sriov_vf(adev))
-base = adev->mmhub.funcs->get_fb_location(adev);
+u64 base = adev->mmhub.funcs->get_fb_location(adev);

  /* add the xgmi offset of the physical node */
  base += adev->gmc.xgmi.physical_node_id * adev-

gmc.xgmi.node_segment_size;

--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
ts.fre
edesktop.org%2Fmailman%2Flistinfo%2Famd-
gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
ts.fre
edesktop.org%2Fmailman%2Flistinfo%2Famd-
gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7CZh
igang.Luo%40amd.com%7C9b87dfa195ed4e84a8c808d92749e416%7C3dd8961fe4884
e608e11a82d994e183d%7C0%7C0%7C637584020581460118%7CUnknown%7CTWFpbGZsb
3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
7C1000sdata=3S6ZEnCCMHHlfc%2B6xmLDz7Bgn91Is7EIpMS7WRxq0Jo%3D
reserved=0


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 0/1] drm/amd/display: Add missing cases

Rev 2: Fix small typo in commit message.


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/1] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the cases for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 389eff96fcf6..6e82889271d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6515,6 +6515,10 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 14;
case COLOR_DEPTH_161616:
return 16;
+   case COLOR_DEPTH_999:
+   return 9;
+   case COLOR_DEPTH_11:
+   return 11;
default:
break;
}
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/3] drm/amd/pm: Add VF check to BACO support check

[Public]

For smuv11, check for VF also during BACO check.

Signed-off-by: Lijo Lazar 
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
index 362696208fd8..e1e1c268f661 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
@@ -1483,7 +1483,7 @@ bool smu_v11_0_baco_is_support(struct smu_context *smu)
{
   struct smu_baco_context *smu_baco = >smu_baco;
-  if (!smu_baco->platform_support)
+ if (amdgpu_sriov_vf(smu->adev) || !smu_baco->platform_support)
   return false;
/* Arcturus does not support this bit mask */
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 3/3] drm/amd/pm: Use generic BACO function for smu11 ASICs

[Public]

Remove ASIC specific functions for BACO support check. Use generic smu11
function instead.

Signed-off-by: Lijo Lazar 
---
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c| 12 +---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c  | 12 +---
.../gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c  | 12 +---
3 files changed, 3 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index 5c248accc4a6..5959019f51ad 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -2162,16 +2162,6 @@ static void arcturus_get_unique_id(struct smu_context 
*smu)
   sprintf(adev->serial, "%llx", id);
}
-static bool arcturus_is_baco_supported(struct smu_context *smu)
-{
-  struct amdgpu_device *adev = smu->adev;
-
-  if (!smu_v11_0_baco_is_support(smu) || amdgpu_sriov_vf(adev))
-  return false;
-
-  return true;
-}
-
static int arcturus_set_df_cstate(struct smu_context *smu,
 enum 
pp_df_cstate state)
{
@@ -2406,7 +2396,7 @@ static const struct pptable_funcs arcturus_ppt_funcs = {
   .register_irq_handler = smu_v11_0_register_irq_handler,
   .set_azalia_d3_pme = smu_v11_0_set_azalia_d3_pme,
   .get_max_sustainable_clocks_by_dc = 
smu_v11_0_get_max_sustainable_clocks_by_dc,
-  .baco_is_support= arcturus_is_baco_supported,
+ .baco_is_support = smu_v11_0_baco_is_support,
   .baco_get_state = smu_v11_0_baco_get_state,
   .baco_set_state = smu_v11_0_baco_set_state,
   .baco_enter = smu_v11_0_baco_enter,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 31e9cc3f3ea0..74a8c676e22c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -2257,16 +2257,6 @@ static int 
navi10_overdrive_get_gfx_clk_base_voltage(struct smu_context *smu,
   return 0;
}
-static bool navi10_is_baco_supported(struct smu_context *smu)
-{
-  struct amdgpu_device *adev = smu->adev;
-
-  if (amdgpu_sriov_vf(adev) || (!smu_v11_0_baco_is_support(smu)))
-  return false;
-
-  return true;
-}
-
static int navi10_set_default_od_settings(struct smu_context *smu)
{
   OverDriveTable_t *od_table =
@@ -3102,7 +3092,7 @@ static const struct pptable_funcs navi10_ppt_funcs = {
   .register_irq_handler = smu_v11_0_register_irq_handler,
   .set_azalia_d3_pme = smu_v11_0_set_azalia_d3_pme,
   .get_max_sustainable_clocks_by_dc = 
smu_v11_0_get_max_sustainable_clocks_by_dc,
-  .baco_is_support= navi10_is_baco_supported,
+ .baco_is_support = smu_v11_0_baco_is_support,
   .baco_get_state = smu_v11_0_baco_get_state,
   .baco_set_state = smu_v11_0_baco_set_state,
   .baco_enter = smu_v11_0_baco_enter,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 6614dbb723be..f01e919e1f89 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -2100,16 +2100,6 @@ static int sienna_cichlid_run_btc(struct smu_context 
*smu)
   return smu_cmn_send_smc_msg(smu, SMU_MSG_RunDcBtc, NULL);
}
-static bool sienna_cichlid_is_baco_supported(struct smu_context *smu)
-{
-  struct amdgpu_device *adev = smu->adev;
-
-  if (amdgpu_sriov_vf(adev) || (!smu_v11_0_baco_is_support(smu)))
-  return false;
-
-  return true;
-}
-
static bool sienna_cichlid_is_mode1_reset_supported(struct smu_context *smu)
{
   struct amdgpu_device *adev = smu->adev;
@@ -3882,7 +3872,7 @@ static const struct pptable_funcs 
sienna_cichlid_ppt_funcs = {
   .register_irq_handler = smu_v11_0_register_irq_handler,
   .set_azalia_d3_pme = smu_v11_0_set_azalia_d3_pme,
   .get_max_sustainable_clocks_by_dc = 
smu_v11_0_get_max_sustainable_clocks_by_dc,
-  .baco_is_support= sienna_cichlid_is_baco_supported,
+ .baco_is_support = smu_v11_0_baco_is_support,
   .baco_get_state = smu_v11_0_baco_get_state,
   .baco_set_state = smu_v11_0_baco_set_state,
   .baco_enter = smu_v11_0_baco_enter,
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/3] drm/amd/pm: Read BIF STRAP also for BACO check

[Public]

Avoid reading BIF STRAP each time for BACO capability. Read the STRAP
value while checking BACO capability in PPTable.

Signed-off-by: Lijo Lazar 
---
.../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 25 -
.../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 27 ++-
.../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 27 ++-
3 files changed, 59 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index 1735a96dd307..5c248accc4a6 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -380,16 +380,31 @@ static int arcturus_set_default_dpm_table(struct 
smu_context *smu)
   return 0;
}
-static int arcturus_check_powerplay_table(struct smu_context *smu)
+static void arcturus_check_bxco_support(struct smu_context *smu)
{
   struct smu_table_context *table_context = >smu_table;
   struct smu_11_0_powerplay_table *powerplay_table =
   table_context->power_play_table;
   struct smu_baco_context *smu_baco = >smu_baco;
+ struct amdgpu_device *adev = smu->adev;
+ uint32_t val;
if (powerplay_table->platform_caps & 
SMU_11_0_PP_PLATFORM_CAP_BACO ||
-  powerplay_table->platform_caps & 
SMU_11_0_PP_PLATFORM_CAP_MACO)
-  smu_baco->platform_support = true;
+ powerplay_table->platform_caps & 
SMU_11_0_PP_PLATFORM_CAP_MACO) {
+ val = RREG32_SOC15(NBIO, 0, mmRCC_BIF_STRAP0);
+ smu_baco->platform_support =
+ (val & 
RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true :
+   
  false;
+ }
+}
+
+static int arcturus_check_powerplay_table(struct smu_context *smu)
+{
+ struct smu_table_context *table_context = >smu_table;
+ struct smu_11_0_powerplay_table *powerplay_table =
+ table_context->power_play_table;
+
+ arcturus_check_bxco_support(smu);
table_context->thermal_controller_type =
   powerplay_table->thermal_controller_type;
@@ -2150,13 +2165,11 @@ static void arcturus_get_unique_id(struct smu_context 
*smu)
static bool arcturus_is_baco_supported(struct smu_context *smu)
{
   struct amdgpu_device *adev = smu->adev;
-  uint32_t val;
if (!smu_v11_0_baco_is_support(smu) || amdgpu_sriov_vf(adev))
   return false;
-  val = RREG32_SOC15(NBIO, 0, mmRCC_BIF_STRAP0);
-  return (val & RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true : 
false;
+ return true;
}
 static int arcturus_set_df_cstate(struct smu_context *smu,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 78fe13183e8b..31e9cc3f3ea0 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -340,19 +340,34 @@ navi10_get_allowed_feature_mask(struct smu_context *smu,
   return 0;
}
-static int navi10_check_powerplay_table(struct smu_context *smu)
+static void navi10_check_bxco_support(struct smu_context *smu)
{
   struct smu_table_context *table_context = >smu_table;
   struct smu_11_0_powerplay_table *powerplay_table =
   table_context->power_play_table;
   struct smu_baco_context *smu_baco = >smu_baco;
+ struct amdgpu_device *adev = smu->adev;
+ uint32_t val;
+
+ if (powerplay_table->platform_caps & 
SMU_11_0_PP_PLATFORM_CAP_BACO ||
+ powerplay_table->platform_caps & 
SMU_11_0_PP_PLATFORM_CAP_MACO) {
+ val = RREG32_SOC15(NBIO, 0, mmRCC_BIF_STRAP0);
+ smu_baco->platform_support =
+ (val & 
RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true :
+   
  false;
+ }
+}
+
+static int navi10_check_powerplay_table(struct smu_context *smu)
+{
+ struct smu_table_context *table_context = >smu_table;
+ struct smu_11_0_powerplay_table *powerplay_table =
+ table_context->power_play_table;
if (powerplay_table->platform_caps & 
SMU_11_0_PP_PLATFORM_CAP_HARDWAREDC)
   smu->dc_controlled_by_gpio = true;
-  if (powerplay_table->platform_caps & 
SMU_11_0_PP_PLATFORM_CAP_BACO ||
-

Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] ERROR Waiting for fences timed out!"

2021-06-04 Thread Michel Dänzer

On 2021-06-04 2:33 p.m., Alex Deucher wrote:
> On Fri, Jun 4, 2021 at 3:47 AM Michel Dänzer  wrote:
>>
>> On 2021-05-19 3:57 p.m., Alex Deucher wrote:
>>> On Wed, May 19, 2021 at 4:48 AM Michel Dänzer  wrote:

 On 2021-05-19 12:05 a.m., Alex Deucher wrote:
> On Tue, May 18, 2021 at 10:11 AM Michel Dänzer  wrote:
>>
>> On 2021-05-17 11:33 a.m., xgqt wrote:
>>> Hello!
>>>
>>> I run a AMD laptop "81NC Lenovo IdeaPad S340-15API" - AMD Ryzen 5 3500U 
>>> with Radeon Vega 8 Graphics.
>>> Recently some breakages started happening for me. In about 1h after 
>>> boot-up while using a KDE desktop machine GUI would freeze. Sometimes 
>>> it would be possible to move the mouse but the rest will be frozen. 
>>> Screen may start blinking or go black.
>>>
>>> I'm not sure if this is my kernel, firmware or the hardware.
>>> I don't understands dmesg that's why I'm guessing, but I think it is 
>>> the firmware since this behavior started around 2021-05-15.
>>> From my Portage logs I see that I updated my firmware on 2021-05-14 at 
>>> 18:16:06.
>>> So breakages started with my kernel: 5.10.27 and FW: 20210511.
>>> After breakage I jumped to a older kernel 5.4.97 and compiled 5.12.4. I 
>>> didn't notice a breakage on 5.4.97 but system ran ~40 minutes.
>>> So I booted to newly compiled 5.12.4 where I was ~1h and it broke.
>>> After that I booted to 5.4.97 again and downgraded my FW.
>>> While I'm writing this I'm booted to kernel: 5.12.4 with FW: 20210315.
>>>
>>> I also described my situation on the Gentoo bugzilla: 
>>> https://bugs.gentoo.org/790566
>>>
>>> "dmesg.log" attached here is from the time machine run fine (at the 
>>> moment); "errors_sat_may_15_072825_pm_cest_2021.log" is a dmesg log 
>>> from the time system broke
>>>
>>> Can I get any help with this? What are the next steps I should take? 
>>> Any other files I should provide?
>>
>> I've hit similar hangs with a Lenovo ThinkPad E595 (Ryzen 7 3700U / 
>> Picasso / RAVEN 0x1002:0x15D8 0x17AA:0x5124 0xC1). I'm also suspecting 
>> them to be firware related. The hangs occurred with firmware from the 
>> AMD 20.50 release. I'm currently running with firmware from the 20.40 
>> release, no hang in almost 2 weeks (the hangs happened within 1-2 days 
>> after boot).
>
> Can you narrow down which firmware(s) cause the problem?

 I'll try, but note I'm not really sure yet my hangs were related to 
 firmware (only). Anyway, I'll try narrowing it down.
>>>
>>> Thanks.  Does this patch help?
>>> https://patchwork.freedesktop.org/patch/433701/
>>
>> Unfortunately not. After no hangs for two weeks with older firmware, I just 
>> got a hang again within a day with newer firmware and a kernel with this fix.
>>
>>
>> I'll try and narrow down which firmware triggers it now. Does Picasso use 
>> the picasso_*.bin ones only, or others as well?
> 
> The picasso ones and raven_dmcu.bin.

Thanks. raven_dmcu.bin hasn't changed, so I'm trying to bisect the 8 Picasso 
ones which have changed:

picasso_asd.bin
picasso_ce.bin
picasso_me.bin
picasso_mec2.bin
picasso_mec.bin
picasso_pfp.bin
picasso_sdma.bin
picasso_vcn.bin


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.

Signed-off-by: Werner Sembach 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 389eff96fcf6..6e82889271d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6515,6 +6515,10 @@ static int convert_dc_color_depth_into_bpc (enum 
dc_color_depth display_color_de
return 14;
case COLOR_DEPTH_161616:
return 16;
+   case COLOR_DEPTH_999:
+   return 9;
+   case COLOR_DEPTH_11:
+   return 11;
default:
break;
}
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Re: [BUG] Data race when use PACKET3_DMA_DATA?

2021-06-04 Thread Chen Lei

Thanks very much. I get it now.

 -Original Messages-
 From: "Christian König" 
 Sent Time: 2021-06-04 15:40:08 (Friday)
 To: "Chen Lei" , "Alex Deucher" 

 Cc: "amd-gfx list" 
 Subject: Re: [BUG] Data race when use PACKET3_DMA_DATA?

 Hi,

 I think your problem comes from the missing understanding that the 
 hardware is heavily pipelined.

 In other words commands you send to the hardware just kick of 
 asynchronously processing, e.g. a CP DMA command just kicks a copy 
 operation but the CP then continue executing commands.

 Same thing for a RELEASE_MEM packet, it just kicks of an operation to 
 write a value to an address when all Compute or 3D rendering is completed.

 But if you want to synchronize execution of the CP commands you still 
 need to block for that valuie to be written or otherwise the CP will 
 just keep going with the next command.

 Regards,
 Christian.

 Am 03.06.21 um 05:37 schrieb Chen Lei:
  I had seperated the dispatch packet and DMA DATA packet into 2 IBs, 
and called the amdgpu_cs_ioctl twice.
  If I was not mistaken, the `amdgpu_ib_schedule` would emit fence 
packets for each amdgpu_cs_ioctl call.
  Did I need to insert the fence packet explicitly after the dispatch 
packet?

   -Original Messages-
   From: "Alex Deucher" 
   Sent Time: 2021-06-03 10:11:46 (Thursday)
   To: "Chen Lei" 
   Cc: "amd-gfx list" 
   Subject: Re: Re: [BUG] Data race when use PACKET3_DMA_DATA?

   On Wed, Jun 2, 2021 at 8:29 PM Chen Lei  
wrote:

Hi Alex. Thanks for your quick reply.
I first submit the OpenCL kernel packet and then submit the 
DMA DATA packet. And the OpenCL kernel reads the value written by the DMA DATA 
packet.
If I understand you correctly, that is because the CP 
engine continues on to process the DMA DATA packet after launching the OpenCL 
kernel. If so, is there any way to sync the CP engine until the OpenCL kernel 
is complete?

   Once the kernel has been dispatched to the shader cores, the CP 
will
   continue to execute packets in the queue.  If you want it to 
wait for
   the pipeline to drain you'll need to insert a fence packet (e.g.,
   RELEASE_MEM).

   Alex

 -Original Messages-
 From: "Alex Deucher" 
 Sent Time: 2021-06-02 21:37:51 (Wednesday)
 To: "Chen Lei" 
 Cc: "amd-gfx list" 
 Subject: Re: [BUG] Data race when use PACKET3_DMA_DATA?

 On Wed, Jun 2, 2021 at 8:44 AM Chen Lei 
 wrote:

  Hi, I noticed that there are two ways to do DMA 
for amd gpu: the SDMA copy packet and the PM4 dma packet.

  I had tested the PM4 dma packet:  
PACKET3_DMA_DATA. In most of time, it works.

  But when I launch an OpenCL kernel followed by a 
host-to-gpu DMA packet, it seems that the OpenCL kernel read the new value 
written by the following DMA packet.

  Both the OpenCL kernel and the PM4 dma packet are 
submitted using the amdgpu_cs_ioctl, and they are submitted to the same ring.

  I was not family with the hardware details. 
According to my understanding, because the ring is FIFO, there is no need for 
any explicit synchronization between the OpenCL kernel launch packet and the 
dma packet. So the result looked weird. And when I add the synchronization(i.e. 
amdgpu_cs_wait_ioctl) before the dma packet, everything is OK.

  Was it a hardware bug or did I miss something?

 The CP DMA engine is separate from the various CP 
micro engines.  When
 there is a DMA DATA packet, the DMA operation is 
offloaded to the CP
 DMA engine and the CP engine that processed the packet 
continues on to
 the next packet.  You need to use the ENGINE_SEL and 
CP_SYNC bits in
 the DMA DATA packet to specify the behavior you want.  
The ENGINE_SEL
 bit selects which CP engine processes the packet (PFP 
or ME) and the
 CP_SYNC bit stops further packet processing on the 
selected engine
 until the DMA is complete.

 Alex

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  ___
  amd-gfx mailing list
  amd-gfx@lists.freedesktop.org
  https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4 2/2] radeon: use memcpy_to/fromio for UVD fw upload


Am 04.06.21 um 10:43 schrieb Chen Li:

I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
Reviewed-by: Christian König


Reviewed-by: Christian König 

Alex will probably now pick them up for upstreaming.

Christian.


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

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..753da95e6abb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
  
-	memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);

+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr, rdev->uvd_fw->data, 
rdev->uvd_fw->size);
  
  	size = radeon_bo_size(rdev->uvd.vcpu_bo);

size -= rdev->uvd_fw->size;
@@ -296,7 +296,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
  
-	memset(ptr, 0, size);

+   memset_io((void __iomem *)ptr, 0, size);
  
  	return 0;

  }


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload




Am 04.06.21 um 10:28 schrieb Chen Li:

On Fri, 04 Jun 2021 16:08:26 +0800,
Christian König wrote:



Am 04.06.21 um 09:53 schrieb Chen Li:

I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
---
   drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
   1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..55abf9a9623b 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
   -memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
+   rdev->uvd_fw->data,
+   rdev->uvd_fw->size);

The coding style still looks wrong here, e.g. it is indented to far to the right
and data/size can be on one line.

It's really werid that the patch before being replyed has not this coding style 
issue and do always indent the same with previous memcpy(in all of v1, v2 and 
v3),
you can check at 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fpatch%2F87im2ufhyz.wl-chenli%40uniontech.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C3faf061c19b54a68e72508d92732cd5e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637583921450406148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b0726ORwyeLQsKVzqjfZEMaU4Vi543szpFYoHekPMIU%3Dreserved=0
 Cannot figure out what happened, sorry.

I'll take merge them in single line in the next series, thanks.


It's not much of an issue, just make sure that checkpatch.pl doesn't 
complain.


Christian.


Apart from that the patch is Reviewed-by: Christian König


Regards,
Christian.


size = radeon_bo_size(rdev->uvd.vcpu_bo);
size -= rdev->uvd_fw->size;
@@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
   -memset(ptr, 0, size);
+   memset_io((void __iomem *)ptr, 0, size);
return 0;
   }







___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] ERROR Waiting for fences timed out!"

On Fri, Jun 4, 2021 at 3:47 AM Michel Dänzer  wrote:
>
> On 2021-05-19 3:57 p.m., Alex Deucher wrote:
> > On Wed, May 19, 2021 at 4:48 AM Michel Dänzer  wrote:
> >>
> >> On 2021-05-19 12:05 a.m., Alex Deucher wrote:
> >>> On Tue, May 18, 2021 at 10:11 AM Michel Dänzer  wrote:
> 
>  On 2021-05-17 11:33 a.m., xgqt wrote:
> > Hello!
> >
> > I run a AMD laptop "81NC Lenovo IdeaPad S340-15API" - AMD Ryzen 5 3500U 
> > with Radeon Vega 8 Graphics.
> > Recently some breakages started happening for me. In about 1h after 
> > boot-up while using a KDE desktop machine GUI would freeze. Sometimes 
> > it would be possible to move the mouse but the rest will be frozen. 
> > Screen may start blinking or go black.
> >
> > I'm not sure if this is my kernel, firmware or the hardware.
> > I don't understands dmesg that's why I'm guessing, but I think it is 
> > the firmware since this behavior started around 2021-05-15.
> > From my Portage logs I see that I updated my firmware on 2021-05-14 at 
> > 18:16:06.
> > So breakages started with my kernel: 5.10.27 and FW: 20210511.
> > After breakage I jumped to a older kernel 5.4.97 and compiled 5.12.4. I 
> > didn't notice a breakage on 5.4.97 but system ran ~40 minutes.
> > So I booted to newly compiled 5.12.4 where I was ~1h and it broke.
> > After that I booted to 5.4.97 again and downgraded my FW.
> > While I'm writing this I'm booted to kernel: 5.12.4 with FW: 20210315.
> >
> > I also described my situation on the Gentoo bugzilla: 
> > https://bugs.gentoo.org/790566
> >
> > "dmesg.log" attached here is from the time machine run fine (at the 
> > moment); "errors_sat_may_15_072825_pm_cest_2021.log" is a dmesg log 
> > from the time system broke
> >
> > Can I get any help with this? What are the next steps I should take? 
> > Any other files I should provide?
> 
>  I've hit similar hangs with a Lenovo ThinkPad E595 (Ryzen 7 3700U / 
>  Picasso / RAVEN 0x1002:0x15D8 0x17AA:0x5124 0xC1). I'm also suspecting 
>  them to be firware related. The hangs occurred with firmware from the 
>  AMD 20.50 release. I'm currently running with firmware from the 20.40 
>  release, no hang in almost 2 weeks (the hangs happened within 1-2 days 
>  after boot).
> >>>
> >>> Can you narrow down which firmware(s) cause the problem?
> >>
> >> I'll try, but note I'm not really sure yet my hangs were related to 
> >> firmware (only). Anyway, I'll try narrowing it down.
> >
> > Thanks.  Does this patch help?
> > https://patchwork.freedesktop.org/patch/433701/
>
> Unfortunately not. After no hangs for two weeks with older firmware, I just 
> got a hang again within a day with newer firmware and a kernel with this fix.
>
>
> I'll try and narrow down which firmware triggers it now. Does Picasso use the 
> picasso_*.bin ones only, or others as well?

The picasso ones and raven_dmcu.bin.

Thanks,

Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/pm: Remove BACO check for aldebaran

2021-06-04 Thread Zhang, Hawking

[Public]

Reviewed-by: Hawking Zhang 

Regards,
Hawking
From: Lazar, Lijo 
Sent: Friday, June 4, 2021 14:59
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Feng, Kenneth 
; Wang, Kevin(Yang) 
Subject: [PATCH] drm/amd/pm: Remove BACO check for aldebaran


[Public]

BACO/MACO is not applicable for aldebaran. Remove the redundant check.

Signed-off-by: Lijo Lazar mailto:lijo.la...@amd.com>>
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 7 ---
1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index 7a1abb3d6a7a..6ee9c4186f02 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -355,13 +355,6 @@ static int aldebaran_check_powerplay_table(struct 
smu_context *smu)
   struct smu_table_context *table_context = >smu_table;
   struct smu_13_0_powerplay_table *powerplay_table =
   table_context->power_play_table;
-  struct smu_baco_context *smu_baco = >smu_baco;
-
-  mutex_lock(_baco->mutex);
-  if (powerplay_table->platform_caps & 
SMU_13_0_PP_PLATFORM_CAP_BACO ||
-  powerplay_table->platform_caps & 
SMU_13_0_PP_PLATFORM_CAP_MACO)
-  smu_baco->platform_support = true;
-  mutex_unlock(_baco->mutex);

table_context->thermal_controller_type =
   powerplay_table->thermal_controller_type;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: remove redundant assignment of variable k


Am 03.06.21 um 14:34 schrieb Colin King:

From: Colin Ian King 

The variable k is being assigned a value that is never read, the
assignment is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 2a7bed66d50b..f545dc1248b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -278,7 +278,7 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct 
amdgpu_bo *bo,
write_seqcount_end(>seq);
  
  	/* Drop the references to the removed fences or move them to ef_list */

-   for (i = j, k = 0; i < old->shared_count; ++i) {
+   for (i = j; i < old->shared_count; ++i) {
struct dma_fence *f;
  
  		f = rcu_dereference_protected(new->shared[i],


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload

On Fri, 04 Jun 2021 16:31:28 +0800,
Christian König wrote:
> 
> 
> 
> Am 04.06.21 um 10:28 schrieb Chen Li:
> > On Fri, 04 Jun 2021 16:08:26 +0800,
> > Christian König wrote:
> >> 
> >> 
> >> Am 04.06.21 um 09:53 schrieb Chen Li:
> >>> I met a gpu addr bug recently and the kernel log
> >>> tells me the pc is memcpy/memset and link register is
> >>> radeon_uvd_resume.
> >>> 
> >>> As we know, in some architectures, optimized memcpy/memset
> >>> may not work well on device memory. Trival memcpy_toio/memset_io
> >>> can fix this problem.
> >>> 
> >>> BTW, amdgpu has already done it in:
> >>> commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw 
> >>> upload"),
> >>> that's why it has no this issue on the same gpu and platform.
> >>> 
> >>> Signed-off-by: Chen Li 
> >>> ---
> >>>drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> >>> b/drivers/gpu/drm/radeon/radeon_uvd.c
> >>> index 85a1f2c31749..55abf9a9623b 100644
> >>> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> >>> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> >>> @@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> >>>   if (rdev->uvd.vcpu_bo == NULL)
> >>>   return -EINVAL;
> >>>-  memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, 
> >>> rdev->uvd_fw->size);
> >>> + memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
> >>> + rdev->uvd_fw->data,
> >>> + rdev->uvd_fw->size);
> >> The coding style still looks wrong here, e.g. it is indented to far to the 
> >> right
> >> and data/size can be on one line.
> > It's really werid that the patch before being replyed has not this coding 
> > style issue and do always indent the same with previous memcpy(in all of 
> > v1, v2 and v3),
> > you can check at 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fpatch%2F87im2ufhyz.wl-chenli%40uniontech.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C3faf061c19b54a68e72508d92732cd5e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637583921450406148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b0726ORwyeLQsKVzqjfZEMaU4Vi543szpFYoHekPMIU%3Dreserved=0
> >  Cannot figure out what happened, sorry.
> > 
> > I'll take merge them in single line in the next series, thanks.
> 
> It's not much of an issue, just make sure that checkpatch.pl doesn't complain.

Yes, have already done checkpatch in all these series.
> 
> Christian.
> 
> >> Apart from that the patch is Reviewed-by: Christian König
> >> 
> >> 
> >> Regards,
> >> Christian.
> >> 
> >>>   size = radeon_bo_size(rdev->uvd.vcpu_bo);
> >>>   size -= rdev->uvd_fw->size;
> >>> @@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> >>>   ptr = rdev->uvd.cpu_addr;
> >>>   ptr += rdev->uvd_fw->size;
> >>>-  memset(ptr, 0, size);
> >>> + memset_io((void __iomem *)ptr, 0, size);
> >>>   return 0;
> >>>}
> >> 
> >> 
> > 
> 
> 
> 


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload

On Fri, 04 Jun 2021 16:08:26 +0800,
Christian König wrote:
> 
> 
> 
> Am 04.06.21 um 09:53 schrieb Chen Li:
> > I met a gpu addr bug recently and the kernel log
> > tells me the pc is memcpy/memset and link register is
> > radeon_uvd_resume.
> > 
> > As we know, in some architectures, optimized memcpy/memset
> > may not work well on device memory. Trival memcpy_toio/memset_io
> > can fix this problem.
> > 
> > BTW, amdgpu has already done it in:
> > commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
> > that's why it has no this issue on the same gpu and platform.
> > 
> > Signed-off-by: Chen Li 
> > ---
> >   drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> > b/drivers/gpu/drm/radeon/radeon_uvd.c
> > index 85a1f2c31749..55abf9a9623b 100644
> > --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> > +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> > @@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> > if (rdev->uvd.vcpu_bo == NULL)
> > return -EINVAL;
> >   - memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
> > +   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
> > +   rdev->uvd_fw->data,
> > +   rdev->uvd_fw->size);
> 
> The coding style still looks wrong here, e.g. it is indented to far to the 
> right
> and data/size can be on one line.

It's really werid that the patch before being replyed has not this coding style 
issue and do always indent the same with previous memcpy(in all of v1, v2 and 
v3),
you can check at 
https://patchwork.kernel.org/project/dri-devel/patch/87im2ufhyz.wl-che...@uniontech.com/
 Cannot figure out what happened, sorry.

I'll take merge them in single line in the next series, thanks.
> 
> Apart from that the patch is Reviewed-by: Christian König
> 
> 
> Regards,
> Christian.
> 
> > size = radeon_bo_size(rdev->uvd.vcpu_bo);
> > size -= rdev->uvd_fw->size;
> > @@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> > ptr = rdev->uvd.cpu_addr;
> > ptr += rdev->uvd_fw->size;
> >   - memset(ptr, 0, size);
> > +   memset_io((void __iomem *)ptr, 0, size);
> > return 0;
> >   }
> 
> 
> 


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v4 2/2] radeon: use memcpy_to/fromio for UVD fw upload



I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
Reviewed-by: Christian König
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..753da95e6abb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
 
-   memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr, rdev->uvd_fw->data, 
rdev->uvd_fw->size);
 
size = radeon_bo_size(rdev->uvd.vcpu_bo);
size -= rdev->uvd_fw->size;
@@ -296,7 +296,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
 
-   memset(ptr, 0, size);
+   memset_io((void __iomem *)ptr, 0, size);
 
return 0;
 }
-- 
2.31.1




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v4 1/2] radeon: fix coding issues reported from sparse



Also fix some coding issues reported from sparse.

Signed-off-by: Chen Li 
Acked-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index dfa9fdbe98da..85a1f2c31749 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -152,9 +152,11 @@ int radeon_uvd_init(struct radeon_device *rdev)
 
rdev->uvd.fw_header_present = true;
 
-   family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
-   version_major = (le32_to_cpu(hdr->ucode_version) >> 24) 
& 0xff;
-   version_minor = (le32_to_cpu(hdr->ucode_version) >> 8) 
& 0xff;
+   family_id = (__force u32)(hdr->ucode_version) & 0xff;
+   version_major = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 24) & 0xff;
+   version_minor = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 8) & 0xff;
DRM_INFO("Found UVD firmware Version: %u.%u Family ID: 
%u\n",
 version_major, version_minor, family_id);
 
@@ -791,17 +793,17 @@ int radeon_uvd_get_create_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD create msg */
-   writel(cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
writel(0x0, (void __iomem *)[1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
writel(0x0, [4]);
writel(0x0, [5]);
writel(0x0, [6]);
-   writel(cpu_to_le32(0x0780), [7]);
-   writel(cpu_to_le32(0x0440), [8]);
+   writel((__force u32)cpu_to_le32(0x0780), [7]);
+   writel((__force u32)cpu_to_le32(0x0440), [8]);
writel(0x0, [9]);
-   writel(cpu_to_le32(0x01b37000), [10]);
+   writel((__force u32)cpu_to_le32(0x01b37000), [10]);
for (i = 11; i < 1024; ++i)
writel(0x0, [i]);
 
@@ -827,9 +829,9 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD destroy msg */
-   writel(cpu_to_le32(0x0de4), [0]);
-   writel(cpu_to_le32(0x0002), [1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0002), [1]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
for (i = 4; i < 1024; ++i)
writel(0x0, [i]);
-- 
2.31.1





___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v3 0/2] use memcpy_to/fromio for UVD fw upload




changelog:
v1->v2: split sparse and memcp/memset fix
v2->v3: fix coding issue and misuse of le32_to_cpu

Chen Li (2):
  radeon: fix coding issues reported from sparse
  radeon: use memcpy_to/fromio for UVD fw upload

 drivers/gpu/drm/radeon/radeon_uvd.c | 30 -
 1 file changed, 17 insertions(+), 13 deletions(-)

-- 
2.31.1



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v3 1/2] radeon: fix coding issues reported from sparse



Also fix some coding issues reported from sparse.

Signed-off-by: Chen Li 
Acked-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index dfa9fdbe98da..85a1f2c31749 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -152,9 +152,11 @@ int radeon_uvd_init(struct radeon_device *rdev)
 
rdev->uvd.fw_header_present = true;
 
-   family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
-   version_major = (le32_to_cpu(hdr->ucode_version) >> 24) 
& 0xff;
-   version_minor = (le32_to_cpu(hdr->ucode_version) >> 8) 
& 0xff;
+   family_id = (__force u32)(hdr->ucode_version) & 0xff;
+   version_major = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 24) & 0xff;
+   version_minor = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 8) & 0xff;
DRM_INFO("Found UVD firmware Version: %u.%u Family ID: 
%u\n",
 version_major, version_minor, family_id);
 
@@ -791,17 +793,17 @@ int radeon_uvd_get_create_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD create msg */
-   writel(cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
writel(0x0, (void __iomem *)[1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
writel(0x0, [4]);
writel(0x0, [5]);
writel(0x0, [6]);
-   writel(cpu_to_le32(0x0780), [7]);
-   writel(cpu_to_le32(0x0440), [8]);
+   writel((__force u32)cpu_to_le32(0x0780), [7]);
+   writel((__force u32)cpu_to_le32(0x0440), [8]);
writel(0x0, [9]);
-   writel(cpu_to_le32(0x01b37000), [10]);
+   writel((__force u32)cpu_to_le32(0x01b37000), [10]);
for (i = 11; i < 1024; ++i)
writel(0x0, [i]);
 
@@ -827,9 +829,9 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, 
int ring,
return r;
 
/* stitch together an UVD destroy msg */
-   writel(cpu_to_le32(0x0de4), [0]);
-   writel(cpu_to_le32(0x0002), [1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0002), [1]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
for (i = 4; i < 1024; ++i)
writel(0x0, [i]);
-- 
2.31.1



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload



I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..55abf9a9623b 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
 
-   memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
+   rdev->uvd_fw->data,
+   rdev->uvd_fw->size);
 
size = radeon_bo_size(rdev->uvd.vcpu_bo);
size -= rdev->uvd_fw->size;
@@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
 
-   memset(ptr, 0, size);
+   memset_io((void __iomem *)ptr, 0, size);
 
return 0;
 }
-- 
2.31.1



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v4 0/2] use memcpy_to/fromio for UVD fw upload



changelog:
v1->v2: split sparse and memcp/memset fix
v2->v3: fix coding issue and misuse of le32_to_cpu
v3->v4: merge memcpy_toio's arguments to one line
Chen Li (2):
  radeon: fix coding issues reported from sparse
  radeon: use memcpy_to/fromio for UVD fw upload

 drivers/gpu/drm/radeon/radeon_uvd.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

-- 
2.31.1



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4] drm/amdgpu: Don't flush/invalidate HDP for APUs and A+A


Am 02.06.21 um 21:18 schrieb Eric Huang:

Integrate two generic functions to determine if HDP
flush is needed for all Asics.

Signed-off-by: Eric Huang 


Nice work, just one more idea below.

But patch is Reviewed-by: Christian König  
either way if you implement that or not.



---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  5 
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c   |  4 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 15 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|  6 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c |  2 +-
  7 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 7533c2677933..2d5dac573425 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1348,6 +1348,11 @@ int amdgpu_device_baco_enter(struct drm_device *dev);
  int amdgpu_device_baco_exit(struct drm_device *dev);
  bool amdgpu_device_is_headless(struct amdgpu_device *adev);
  
+void amdgpu_device_flush_hdp(struct amdgpu_device *adev,

+   struct amdgpu_ring *ring);
+void amdgpu_device_invalidate_hdp(struct amdgpu_device *adev,
+   struct amdgpu_ring *ring);
+
  /* atpx handler */
  #if defined(CONFIG_VGA_SWITCHEROO)
  void amdgpu_register_atpx_handler(void);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 4c61a67d0016..900c2dbce934 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -697,7 +697,7 @@ bool amdgpu_amdkfd_have_atomics_support(struct kgd_dev *kgd)
  
  void amdgpu_amdkfd_debug_mem_fence(struct kgd_dev *kgd)

  {
-   amdgpu_asic_flush_hdp((struct amdgpu_device *) kgd, NULL);
+   amdgpu_device_flush_hdp((struct amdgpu_device *) kgd, NULL);
  }
  
  int amdgpu_amdkfd_send_close_event_drain_irq(struct kgd_dev *kgd,

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9c4d33f649f7..7f687ea58834 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -362,9 +362,9 @@ void amdgpu_device_vram_access(struct amdgpu_device *adev, 
loff_t pos,
if (write) {
memcpy_toio(addr, buf, count);
mb();
-   amdgpu_asic_flush_hdp(adev, NULL);
+   amdgpu_device_flush_hdp(adev, NULL);
} else {
-   amdgpu_asic_invalidate_hdp(adev, NULL);
+   amdgpu_device_invalidate_hdp(adev, NULL);
mb();
memcpy_fromio(buf, addr, count);
}
@@ -5548,3 +5548,32 @@ bool amdgpu_device_is_headless(struct amdgpu_device 
*adev)
  /* Check if it is NV's VGA class while VCN is harvest, it is headless*/
  return nv_is_headless_sku(adev->pdev);
  }
+
+void amdgpu_device_flush_hdp(struct amdgpu_device *adev,
+   struct amdgpu_ring *ring)
+{
+#ifdef CONFIG_X86_64
+   if (adev->flags & AMD_IS_APU)
+   return;
+#endif
+   if (adev->gmc.xgmi.connected_to_cpu)
+   return;
+
+   if (ring && ring->funcs->emit_hdp_flush)
+   amdgpu_ring_emit_hdp_flush(ring);
+   else
+   amdgpu_asic_flush_hdp(adev, ring);
+}
+
+void amdgpu_device_invalidate_hdp(struct amdgpu_device *adev,
+   struct amdgpu_ring *ring)
+{
+#ifdef CONFIG_X86_64
+   if (adev->flags & AMD_IS_APU)
+   return;
+#endif
+   if (adev->gmc.xgmi.connected_to_cpu)
+   return;
+
+   amdgpu_asic_invalidate_hdp(adev, ring);
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 5562b5c90c03..0e3a46ff38e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -250,7 +250,7 @@ int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t 
offset,
}
}
mb();
-   amdgpu_asic_flush_hdp(adev, NULL);
+   amdgpu_device_flush_hdp(adev, NULL);


It might make sense to move the memory barrier into the 
amdgpu_device_flush_hdp() function as well, but I'm not 100% sure of that.


Christian.


for (i = 0; i < adev->num_vmhubs; i++)
amdgpu_gmc_flush_gpu_tlb(adev, 0, i, 0);
  
@@ -328,7 +328,7 @@ int amdgpu_gart_bind(struct amdgpu_device *adev, uint64_t offset,

return r;
  
  	mb();

-   amdgpu_asic_flush_hdp(adev, NULL);
+   amdgpu_device_flush_hdp(adev, NULL);
for (i = 0; i < adev->num_vmhubs; i++)
amdgpu_gmc_flush_gpu_tlb(adev, 0, i, 0);
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c

Re: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb location


I was just about to question the same thing.

It looks really good to me to have that cleaned up, but if this breaks 
with older versions of the hypervisor then it is a bit questionable change.


Regards,
Christian.

Am 04.06.21 um 03:13 schrieb Deng, Emily:

Do we need to consider backward compatibility?


Best wishes
Emily Deng



-Original Message-
From: amd-gfx  On Behalf Of Liu,
Shaoyun
Sent: Thursday, June 3, 2021 11:10 PM
To: Luo, Zhigang ; amd-gfx@lists.freedesktop.org
Cc: Luo, Zhigang 
Subject: RE: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb
location

[AMD Official Use Only]

Looks ok to me .

Reviewed-By : Shaoyun.liu 

-Original Message-
From: amd-gfx  On Behalf Of Zhigang
Luo
Sent: Thursday, June 3, 2021 10:13 AM
To: amd-gfx@lists.freedesktop.org
Cc: Luo, Zhigang 
Subject: [PATCH 1/5] drm/amdgpu: remove sriov vf checking from getting fb
location

host driver programmed fb location registers for vf, no need to check anymore.

Signed-off-by: Zhigang Luo 
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index ceb3968d8326..1c2d9fde9021 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -1292,10 +1292,7 @@ static int gmc_v9_0_late_init(void *handle)  static
void gmc_v9_0_vram_gtt_location(struct amdgpu_device *adev,
struct amdgpu_gmc *mc)
{
-   u64 base = 0;
-
-   if (!amdgpu_sriov_vf(adev))
-   base = adev->mmhub.funcs->get_fb_location(adev);
+   u64 base = adev->mmhub.funcs->get_fb_location(adev);

/* add the xgmi offset of the physical node */
base += adev->gmc.xgmi.physical_node_id * adev-

gmc.xgmi.node_segment_size;

--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fre
edesktop.org%2Fmailman%2Flistinfo%2Famd-
gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fre
edesktop.org%2Fmailman%2Flistinfo%2Famd-
gfxdata=04%7C01%7CEmily.Deng%40amd.com%7Cd41e78b1a3af4f08ff
d108d926a1a2d8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63
7583297946242271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Nsz
ZyRZHCxj%2FIJ1hYoSrkv3LpTmF9FbchpNMtQ2GE5M%3Dreserved=0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Use vma_lookup() in amdgpu_ttm_tt_get_user_pages()


Am 03.06.21 um 18:09 schrieb Liam Howlett:

Use vma_lookup() to find the VMA at a specific address.  As vma_lookup()
will return NULL if the address is not within any VMA, the start address
no longer needs to be validated.

Signed-off-by: Liam R. Howlett 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7cb7ffdd1900..dfb5ca3f8da8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -680,9 +680,9 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
return -ESRCH;
  
  	mmap_read_lock(mm);

-   vma = find_vma(mm, start);
+   vma = vma_lookup(mm, start);
mmap_read_unlock(mm);
-   if (unlikely(!vma || start < vma->vm_start)) {
+   if (unlikely(!vma)) {
r = -EFAULT;
goto out_putmm;
}


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/pm: Remove BACO check for aldebaran

[Public]

BACO/MACO is not applicable for aldebaran. Remove the redundant check.

Signed-off-by: Lijo Lazar 
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 7 ---
1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index 7a1abb3d6a7a..6ee9c4186f02 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -355,13 +355,6 @@ static int aldebaran_check_powerplay_table(struct 
smu_context *smu)
   struct smu_table_context *table_context = >smu_table;
   struct smu_13_0_powerplay_table *powerplay_table =
   table_context->power_play_table;
-  struct smu_baco_context *smu_baco = >smu_baco;
-
-  mutex_lock(_baco->mutex);
-  if (powerplay_table->platform_caps & 
SMU_13_0_PP_PLATFORM_CAP_BACO ||
-  powerplay_table->platform_caps & 
SMU_13_0_PP_PLATFORM_CAP_MACO)
-  smu_baco->platform_support = true;
-  mutex_unlock(_baco->mutex);
table_context->thermal_controller_type =
   powerplay_table->thermal_controller_type;
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdkfd: add sdma poison consumption handling

2021-06-04 Thread Li, Dennis

[AMD Official Use Only]

This patch looks good to me.

Reviewed-by: Dennis Li

-Original Message-
From: Zhang, Hawking  
Sent: Friday, June 4, 2021 12:58 PM
To: amd-gfx@lists.freedesktop.org; Li, Dennis ; Deucher, 
Alexander ; Kuehling, Felix 
Cc: Zhang, Hawking 
Subject: [PATCH] drm/amdkfd: add sdma poison consumption handling

Follow the same apporach as GFX to handle SDMA poison consumption. Send SIGBUS 
to application when receives SDMA_ECC interrupt and issue gpu reset either mode 
2 or mode 1 to get the engine back

Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 7 ++-
 drivers/gpu/drm/amd/amdkfd/soc15_int.h  | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
index 02dd12774261..2e2b616c1bb7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
@@ -309,8 +309,13 @@ static void event_interrupt_wq_v9(struct kfd_dev *dev,
   client_id == SOC15_IH_CLIENTID_SDMA5 ||
   client_id == SOC15_IH_CLIENTID_SDMA6 ||
   client_id == SOC15_IH_CLIENTID_SDMA7) {
-   if (source_id == SOC15_INTSRC_SDMA_TRAP)
+   if (source_id == SOC15_INTSRC_SDMA_TRAP) {
kfd_signal_event_interrupt(pasid, context_id0 & 
0xfff, 28);
+   } else if (source_id == SOC15_INTSRC_SDMA_ECC) {
+   kfd_signal_poison_consumed_event(dev, pasid);
+   amdgpu_amdkfd_gpu_reset(dev->kgd);
+   return;
+   }
} else if (client_id == SOC15_IH_CLIENTID_VMC ||
   client_id == SOC15_IH_CLIENTID_VMC1 ||
   client_id == SOC15_IH_CLIENTID_UTCL2) { diff --git 
a/drivers/gpu/drm/amd/amdkfd/soc15_int.h 
b/drivers/gpu/drm/amd/amdkfd/soc15_int.h
index 0bc0b25cb410..daf3c44547d3 100644
--- a/drivers/gpu/drm/amd/amdkfd/soc15_int.h
+++ b/drivers/gpu/drm/amd/amdkfd/soc15_int.h
@@ -30,6 +30,7 @@
 #define SOC15_INTSRC_SQ_INTERRUPT_MSG  239
 #define SOC15_INTSRC_VMC_FAULT 0
 #define SOC15_INTSRC_SDMA_TRAP 224
+#define SOC15_INTSRC_SDMA_ECC  220
 
 
 #define SOC15_CLIENT_ID_FROM_IH_ENTRY(entry) (le32_to_cpu(entry[0]) & 0xff)
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdkfd: add sdma poison consumption handling

2021-06-04 Thread Hawking Zhang

Follow the same apporach as GFX to handle SDMA
poison consumption. Send SIGBUS to application
when receives SDMA_ECC interrupt and issue gpu
reset either mode 2 or mode 1 to get the engine
back

Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 7 ++-
 drivers/gpu/drm/amd/amdkfd/soc15_int.h  | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
index 02dd12774261..2e2b616c1bb7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
@@ -309,8 +309,13 @@ static void event_interrupt_wq_v9(struct kfd_dev *dev,
   client_id == SOC15_IH_CLIENTID_SDMA5 ||
   client_id == SOC15_IH_CLIENTID_SDMA6 ||
   client_id == SOC15_IH_CLIENTID_SDMA7) {
-   if (source_id == SOC15_INTSRC_SDMA_TRAP)
+   if (source_id == SOC15_INTSRC_SDMA_TRAP) {
kfd_signal_event_interrupt(pasid, context_id0 & 
0xfff, 28);
+   } else if (source_id == SOC15_INTSRC_SDMA_ECC) {
+   kfd_signal_poison_consumed_event(dev, pasid);
+   amdgpu_amdkfd_gpu_reset(dev->kgd);
+   return;
+   }
} else if (client_id == SOC15_IH_CLIENTID_VMC ||
   client_id == SOC15_IH_CLIENTID_VMC1 ||
   client_id == SOC15_IH_CLIENTID_UTCL2) {
diff --git a/drivers/gpu/drm/amd/amdkfd/soc15_int.h 
b/drivers/gpu/drm/amd/amdkfd/soc15_int.h
index 0bc0b25cb410..daf3c44547d3 100644
--- a/drivers/gpu/drm/amd/amdkfd/soc15_int.h
+++ b/drivers/gpu/drm/amd/amdkfd/soc15_int.h
@@ -30,6 +30,7 @@
 #define SOC15_INTSRC_SQ_INTERRUPT_MSG  239
 #define SOC15_INTSRC_VMC_FAULT 0
 #define SOC15_INTSRC_SDMA_TRAP 224
+#define SOC15_INTSRC_SDMA_ECC  220
 
 
 #define SOC15_CLIENT_ID_FROM_IH_ENTRY(entry) (le32_to_cpu(entry[0]) & 0xff)
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation

[AMD Official Use Only]

A modified version of 2  -  
List all the possible ones and merge those which mean the same - ex: 
terminology changes like THM and TEMP.

In the mail earlier, I meant to list them out separately as the intention is to 
convey the throttle reason to the user- it's better to point out the exact 
regulator which is heating up. 

Thanks,
Lijo

-Original Message-
From: Quan, Evan  
Sent: Friday, June 4, 2021 7:47 AM
To: Lazar, Lijo ; Sider, Graham ; 
amd-gfx@lists.freedesktop.org
Cc: Kasiviswanathan, Harish ; Sakhnovitch, 
Elena (Elen) 
Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation

[AMD Official Use Only]

Thanks Lijo and Graham. Yes, I know that only some specific ASICs support 
VR_MEM1 and LIQUID1.
However, the problem is about the design:
1. should we just list those which are commonly supported by all ASICs.
2. Or we list all the possible throttlers and mask out those unsupported for 
some specific ASICs

BR
Evan
> -Original Message-
> From: Lazar, Lijo 
> Sent: Thursday, June 3, 2021 10:01 PM
> To: Sider, Graham ; Quan, Evan 
> ; amd-gfx@lists.freedesktop.org
> Cc: Kasiviswanathan, Harish ; 
> Sakhnovitch, Elena (Elen) 
> Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler 
> translation
> 
> [AMD Official Use Only]
> 
> VR_*0/1 reflect the throttle status of separate voltage rails - 
> availability of both depends on board and FW capability to query their 
> temperature.
> 
> Thanks,
> Lijo
> 
> -Original Message-
> From: Sider, Graham 
> Sent: Thursday, June 3, 2021 6:41 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Lazar, Lijo ; Kasiviswanathan, Harish 
> ; Sakhnovitch, Elena (Elen) 
> 
> Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler 
> translation
> 
> Some ASICs use a single VR_MEM bit, whereas others split it into 
> VR_MEM0 and VR_MEM1. To avoid confusion, we've combined the VR_MEM0 
> and
> VR_MEM1 bits on those ASICs. For consistency we did the same with
> LIQUID0 and LIQUID1.
> 
> -Original Message-
> From: Quan, Evan 
> Sent: Wednesday, June 2, 2021 12:37 AM
> To: Sider, Graham ; amd- 
> g...@lists.freedesktop.org
> Cc: Lazar, Lijo ; Kasiviswanathan, Harish 
> ; Sider, Graham 
> ; Sakhnovitch, Elena (Elen) 
> 
> Subject: RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler 
> translation
> 
> [AMD Official Use Only]
> 
> 
> 
> > -Original Message-
> > From: amd-gfx  On Behalf Of 
> > Graham Sider
> > Sent: Wednesday, June 2, 2021 2:12 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Lazar, Lijo ; Kasiviswanathan, Harish 
> > ; Sider, Graham 
> > ; Sakhnovitch, Elena (Elen) 
> > 
> > Subject: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation
> >
> > Perform dependent to independent throttle status translation for 
> > navi1x. Makes use of lookup table navi1x_throttler_map.
> >
> > Signed-off-by: Graham Sider 
> > ---
> >  .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 43
> > +++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > index 78fe13183e8b..bf376b1be08d 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> > @@ -238,6 +238,28 @@ static struct cmn2asic_mapping 
> > navi10_workload_map[PP_SMC_POWER_PROFILE_COUNT] =
> > WORKLOAD_MAP(PP_SMC_POWER_PROFILE_CUSTOM,
> > WORKLOAD_PPLIB_CUSTOM_BIT),
> >  };
> >
> > +static const uint8_t navi1x_throttler_map[] = {
> > +   [THROTTLER_TEMP_EDGE_BIT]   =
> > (SMU_THROTTLER_TEMP_EDGE_BIT),
> > +   [THROTTLER_TEMP_HOTSPOT_BIT]=
> > (SMU_THROTTLER_TEMP_HOTSPOT_BIT),
> > +   [THROTTLER_TEMP_MEM_BIT]=
> > (SMU_THROTTLER_TEMP_MEM_BIT),
> > +   [THROTTLER_TEMP_VR_GFX_BIT] =
> > (SMU_THROTTLER_TEMP_VR_GFX_BIT),
> > +   [THROTTLER_TEMP_VR_MEM0_BIT]=
> > (SMU_THROTTLER_TEMP_VR_MEM_BIT),
> > +   [THROTTLER_TEMP_VR_MEM1_BIT]=
> > (SMU_THROTTLER_TEMP_VR_MEM_BIT),
> [Quan, Evan] I'm wondering why you map the two ASIC dependent bits to 
> the same non ASIC independent bit. Instead of defining two non ASIC 
> independent bits.
> > +   [THROTTLER_TEMP_VR_SOC_BIT] =
> > (SMU_THROTTLER_TEMP_VR_SOC_BIT),
> > +   [THROTTLER_TEMP_LIQUID0_BIT]=
> > (SMU_THROTTLER_TEMP_LIQUID_BIT),
> > +   [THROTTLER_TEMP_LIQUID1_BIT]=
> > (SMU_THROTTLER_TEMP_LIQUID_BIT),
> [Quan, Evan] Same question here and for Patch4.
> 
> BR
> Evan
> > +   [THROTTLER_TDC_GFX_BIT] =
> > (SMU_THROTTLER_TDC_GFX_BIT),
> > +   [THROTTLER_TDC_SOC_BIT] =
> > (SMU_THROTTLER_TDC_SOC_BIT),
> > +   [THROTTLER_PPT0_BIT]=
> > (SMU_THROTTLER_PPT0_BIT),
> > +   [THROTTLER_PPT1_BIT]=
> > (SMU_THROTTLER_PPT1_BIT),
> > +   [THROTTLER_PPT2_BIT]=
> > (SMU_THROTTLER_PPT2_BIT),
> > +   [THROTTLER_PPT3_BIT]=
> > (SMU_THROTTLER_PPT3_BIT),
> > +   [THROTTLER_FIT_BIT]

RE: [PATCH 4/5] drm/amd/pm: clear the cached dpm feature status

[AMD Official Use Only]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Thursday, June 3, 2021 7:04 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH 4/5] drm/amd/pm: clear the cached dpm feature status
> 
> 
> 
> On 6/3/2021 10:26 AM, Evan Quan wrote:
> > For some ASICs, the real dpm feature disablement job is handled by
> > PMFW during baco reset and custom pptable loading. Cached dpm feature
> > status need to be cleared to pair that.
> >
> > Change-Id: I9e37d80e13599833301c04711b097fb37c2e41f9
> > Signed-off-by: Evan Quan 
> > ---
> >   drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 18
> --
> >   1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > index c9a31556e077..fd7b1b8edeb7 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > @@ -1352,6 +1352,16 @@ static int smu_hw_init(void *handle)
> > return 0;
> >   }
> >
> > +static void smu_reset_cached_dpm_feature_status(struct smu_context
> > +*smu) {
> > +   struct smu_feature *feature = >smu_feature;
> > +
> > +   mutex_lock(>mutex);
> > +   bitmap_zero(feature->enabled, feature->feature_num);
> > +   bitmap_zero(feature->supported, feature->feature_num);
> 
> This will clear also clear the BACO feature status. Won't that affect using 
> baco
> exit for runtime pm resume?
[Quan, Evan] Yes, you are right. Will update it.
Regards,
Evan
> 
> Thanks,
> Lijo
> 
> > +   mutex_unlock(>mutex);
> > +}
> > +
> >   static int smu_disable_dpms(struct smu_context *smu)
> >   {
> > struct amdgpu_device *adev = smu->adev; @@ -1374,16 +1384,20
> @@
> > static int smu_disable_dpms(struct smu_context *smu)
> >  */
> > if (smu->uploading_custom_pp_table &&
> > (adev->asic_type >= CHIP_NAVI10) &&
> > -   (adev->asic_type <= CHIP_DIMGREY_CAVEFISH))
> > +   (adev->asic_type <= CHIP_DIMGREY_CAVEFISH)) {
> > +   smu_reset_cached_dpm_feature_status(smu);
> > return 0;
> > +   }
> >
> > /*
> >  * For Sienna_Cichlid, PMFW will handle the features disablement
> properly
> >  * on BACO in. Driver involvement is unnecessary.
> >  */
> > if ((adev->asic_type == CHIP_SIENNA_CICHLID) &&
> > -use_baco)
> > +use_baco) {
> > +   smu_reset_cached_dpm_feature_status(smu);
> > return 0;
> > +   }
> >
> > /*
> >  * For gpu reset, runpm and hibernation through BACO,
> >
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 3/5] drm/amdgpu: correct the audio function initial Dstate

[AMD Official Use Only]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Thursday, June 3, 2021 7:09 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH 3/5] drm/amdgpu: correct the audio function initial
> Dstate
> 
> 
> 
> On 6/3/2021 10:26 AM, Evan Quan wrote:
> > On driver loading, the ASIC is in D0 state. The bundled audio function
> > should be in the same state also.
> >
> > Change-Id: I136e196be7633e95883a7f6c33963f7583e9bad1
> > Signed-off-by: Evan Quan 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 14 ++
> >   1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index c354ffa62483..9d497b4f8e34 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -137,6 +137,7 @@ int amdgpu_driver_load_kms(struct
> amdgpu_device *adev, unsigned long flags)
> > struct drm_device *dev;
> > struct pci_dev *parent;
> > int r, acpi_status;
> > +   struct pci_dev *p = NULL;
> >
> > dev = adev_to_drm(adev);
> >
> > @@ -212,9 +213,22 @@ int amdgpu_driver_load_kms(struct
> amdgpu_device *adev, unsigned long flags)
> >
>   DPM_FLAG_MAY_SKIP_RESUME);
> > pm_runtime_use_autosuspend(dev->dev);
> > pm_runtime_set_autosuspend_delay(dev->dev, 5000);
> > +
> > pm_runtime_allow(dev->dev);
> > +
> > pm_runtime_mark_last_busy(dev->dev);
> > pm_runtime_put_autosuspend(dev->dev);
> > +
> > +   p = pci_get_domain_bus_and_slot(pci_domain_nr(adev-
> >pdev->bus),
> > +   adev->pdev->bus->number, 1);
> 
> For the sake of readability, it's better to wrap this as get_audio_dev or 
> similar.
[Quan, Evan] Sounds good to me. Will update it in V2.
BR
Evan
> 
> Thanks,
> Lijo
> 
> > +   if (p) {
> > +   pm_runtime_get_sync(>dev);
> > +
> > +   pm_runtime_mark_last_busy(>dev);
> > +   pm_runtime_put_autosuspend(>dev);
> > +
> > +   pci_dev_put(p);
> > +   }
> > }
> >
> > if (amdgpu_acpi_smart_shift_update(dev,
> AMDGPU_SS_DRV_LOAD))
> >
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 2/2] radeon: use memcpy_to/fromio for UVD fw upload




Am 04.06.21 um 09:53 schrieb Chen Li:

I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
---
  drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..55abf9a9623b 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
  
-	memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);

+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
+   rdev->uvd_fw->data,
+   rdev->uvd_fw->size);


The coding style still looks wrong here, e.g. it is indented to far to 
the right and data/size can be on one line.


Apart from that the patch is Reviewed-by: Christian König 



Regards,
Christian.

  
  	size = radeon_bo_size(rdev->uvd.vcpu_bo);

size -= rdev->uvd_fw->size;
@@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
  
-	memset(ptr, 0, size);

+   memset_io((void __iomem *)ptr, 0, size);
  
  	return 0;

  }


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] ERROR Waiting for fences timed out!"

2021-06-04 Thread Michel Dänzer

On 2021-05-19 3:57 p.m., Alex Deucher wrote:
> On Wed, May 19, 2021 at 4:48 AM Michel Dänzer  wrote:
>>
>> On 2021-05-19 12:05 a.m., Alex Deucher wrote:
>>> On Tue, May 18, 2021 at 10:11 AM Michel Dänzer  wrote:

 On 2021-05-17 11:33 a.m., xgqt wrote:
> Hello!
>
> I run a AMD laptop "81NC Lenovo IdeaPad S340-15API" - AMD Ryzen 5 3500U 
> with Radeon Vega 8 Graphics.
> Recently some breakages started happening for me. In about 1h after 
> boot-up while using a KDE desktop machine GUI would freeze. Sometimes it 
> would be possible to move the mouse but the rest will be frozen. Screen 
> may start blinking or go black.
>
> I'm not sure if this is my kernel, firmware or the hardware.
> I don't understands dmesg that's why I'm guessing, but I think it is the 
> firmware since this behavior started around 2021-05-15.
> From my Portage logs I see that I updated my firmware on 2021-05-14 at 
> 18:16:06.
> So breakages started with my kernel: 5.10.27 and FW: 20210511.
> After breakage I jumped to a older kernel 5.4.97 and compiled 5.12.4. I 
> didn't notice a breakage on 5.4.97 but system ran ~40 minutes.
> So I booted to newly compiled 5.12.4 where I was ~1h and it broke.
> After that I booted to 5.4.97 again and downgraded my FW.
> While I'm writing this I'm booted to kernel: 5.12.4 with FW: 20210315.
>
> I also described my situation on the Gentoo bugzilla: 
> https://bugs.gentoo.org/790566
>
> "dmesg.log" attached here is from the time machine run fine (at the 
> moment); "errors_sat_may_15_072825_pm_cest_2021.log" is a dmesg log from 
> the time system broke
>
> Can I get any help with this? What are the next steps I should take? Any 
> other files I should provide?

 I've hit similar hangs with a Lenovo ThinkPad E595 (Ryzen 7 3700U / 
 Picasso / RAVEN 0x1002:0x15D8 0x17AA:0x5124 0xC1). I'm also suspecting 
 them to be firware related. The hangs occurred with firmware from the AMD 
 20.50 release. I'm currently running with firmware from the 20.40 release, 
 no hang in almost 2 weeks (the hangs happened within 1-2 days after boot).
>>>
>>> Can you narrow down which firmware(s) cause the problem?
>>
>> I'll try, but note I'm not really sure yet my hangs were related to firmware 
>> (only). Anyway, I'll try narrowing it down.
> 
> Thanks.  Does this patch help?
> https://patchwork.freedesktop.org/patch/433701/

Unfortunately not. After no hangs for two weeks with older firmware, I just got 
a hang again within a day with newer firmware and a kernel with this fix.


I'll try and narrow down which firmware triggers it now. Does Picasso use the 
picasso_*.bin ones only, or others as well?


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [BUG] Data race when use PACKET3_DMA_DATA?

Hi,

I think your problem comes from the missing understanding that the
hardware is heavily pipelined.

In other words commands you send to the hardware just kick of
asynchronously processing, e.g. a CP DMA command just kicks a copy
operation but the CP then continue executing commands.

Same thing for a RELEASE_MEM packet, it just kicks of an operation to
write a value to an address when all Compute or 3D rendering is completed.

But if you want to synchronize execution of the CP commands you still
need to block for that valuie to be written or otherwise the CP will
just keep going with the next command.

Regards,
Christian.

Am 03.06.21 um 05:37 schrieb Chen Lei:

I had seperated the dispatch packet and DMA DATA packet into 2 IBs, and called
the amdgpu_cs_ioctl twice.
If I was not mistaken, the `amdgpu_ib_schedule` would emit fence packets for
each amdgpu_cs_ioctl call.
Did I need to insert the fence packet explicitly after the dispatch packet?

-Original Messages-
From: "Alex Deucher"
Sent Time: 2021-06-03 10:11:46 (Thursday)
To: "Chen Lei"
Cc: "amd-gfx list"
Subject: Re: Re: [BUG] Data race when use PACKET3_DMA_DATA?

On Wed, Jun 2, 2021 at 8:29 PM Chen Lei wrote:

Hi Alex. Thanks for your quick reply.
I first submit the OpenCL kernel packet and then submit the DMA DATA
packet. And the OpenCL kernel reads the value written by the DMA DATA packet.
If I understand you correctly, that is because the CP engine
continues on to process the DMA DATA packet after launching the OpenCL kernel. If so,
is there any way to sync the CP engine until the OpenCL kernel is complete?

Once the kernel has been dispatched to the shader cores, the CP will
continue to execute packets in the queue. If you want it to wait for
the pipeline to drain you'll need to insert a fence packet (e.g.,
RELEASE_MEM).

Alex

-Original Messages-
From: "Alex Deucher"
Sent Time: 2021-06-02 21:37:51 (Wednesday)
To: "Chen Lei"
Cc: "amd-gfx list"
Subject: Re: [BUG] Data race when use PACKET3_DMA_DATA?

On Wed, Jun 2, 2021 at 8:44 AM Chen Lei
wrote:

Hi, I noticed that there are two ways to do DMA for amd
gpu: the SDMA copy packet and the PM4 dma packet.

I had tested the PM4 dma packet: PACKET3_DMA_DATA. In most
of time, it works.

But when I launch an OpenCL kernel followed by a
host-to-gpu DMA packet, it seems that the OpenCL kernel read the new value written by the
following DMA packet.

Both the OpenCL kernel and the PM4 dma packet are submitted
using the amdgpu_cs_ioctl, and they are submitted to the same ring.

I was not family with the hardware details. According to my
understanding, because the ring is FIFO, there is no need for any explicit synchronization
between the OpenCL kernel launch packet and the dma packet. So the result looked weird. And
when I add the synchronization(i.e. amdgpu_cs_wait_ioctl) before the dma packet, everything is
OK.

Was it a hardware bug or did I miss something?

The CP DMA engine is separate from the various CP micro engines.
When
there is a DMA DATA packet, the DMA operation is offloaded to
the CP
DMA engine and the CP engine that processed the packet continues
on to
the next packet. You need to use the ENGINE_SEL and CP_SYNC
bits in
the DMA DATA packet to specify the behavior you want. The
ENGINE_SEL
bit selects which CP engine processes the packet (PFP or ME) and
the
CP_SYNC bit stops further packet processing on the selected
engine
until the DMA is complete.

Alex

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 0/7] libdrm tests for hot-unplug feature

2021-06-04 Thread Andrey Grodzovsky




On 2021-06-03 10:53 p.m., Alex Deucher wrote:

On Thu, Jun 3, 2021 at 9:37 PM Dave Airlie  wrote:

On Fri, 4 Jun 2021 at 07:20, Alex Deucher  wrote:

Please open a gitlab MR for these.


I'd really prefer these tests all get migrated out of here into igt. I
don't think libdrm_amdgpu really should have tests that test the
kernel level infrastructure.




I am also a bit confused now what's the policy about libdrm - is it
being slowly deprecated ?
What tests should go to IGT and what to libdrm ?
The kernel feature itself is strictly amdgpu specific and not generic
DRM level feature - why then it's not a good fit for amdgpu tester ?



We are providing equivalent patches for IGT as well.  There are some
teams and customers that would prefer to stick with libdrm_amdgpu.



Here are the patches in my cloned gitlab repo - 
https://gitlab.freedesktop.org/agrodzov/igt-gpu-tools/-/commits/master

and I sent today for review to igt-...@lists.freedesktop.org too.

Andrey





I know some people at AMD had issues in the past with igt because the
i might have stood for intel back in time, but at this point I think
we should be moving past that.

I don't think that was ever an issue.  It's more that some teams built
a bunch of infrastructure that used libdrm tests and haven't had the
resources to switch to IGT yet.

Alex

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 2/2] radeon: use memcpy_to/fromio for UVD fw upload





Am 04.06.21 um 05:04 schrieb Chen Li:

I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li 
---
  drivers/gpu/drm/radeon/radeon_uvd.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 85a1f2c31749..0d6a5cfa2abf 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -288,7 +288,9 @@ int radeon_uvd_resume(struct radeon_device *rdev)
if (rdev->uvd.vcpu_bo == NULL)
return -EINVAL;
  
-	memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);

+   memcpy_toio((void __iomem *)rdev->uvd.cpu_addr,
+   rdev->uvd_fw->data,
+   le32_to_cpu((__force 
__le32)rdev->uvd_fw->size));


The le32_to_cpu and coding style looks wrong here. The uvd_fw->size is 
always in CPU byte order and is used as such.


And please keep in mind that architectures where memcpy() on MMIO 
doesn't work in the kernel usually doesn't work in userspace as well.


So this is actually now necessary a valid workaround.

Christian.

  
  	size = radeon_bo_size(rdev->uvd.vcpu_bo);

size -= rdev->uvd_fw->size;
@@ -296,7 +298,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
  
-	memset(ptr, 0, size);

+   memset_io((void __iomem *)ptr, 0, size);
  
  	return 0;

  }


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 1/2] radeon: fix coding issues reported from sparse


Am 04.06.21 um 05:02 schrieb Chen Li:

Also fix some coding issue reported from sparse.

Signed-off-by: Chen Li 


Acked-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
  1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index dfa9fdbe98da..85a1f2c31749 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -152,9 +152,11 @@ int radeon_uvd_init(struct radeon_device *rdev)
  
  			rdev->uvd.fw_header_present = true;
  
-			family_id = le32_to_cpu(hdr->ucode_version) & 0xff;

-   version_major = (le32_to_cpu(hdr->ucode_version) >> 24) 
& 0xff;
-   version_minor = (le32_to_cpu(hdr->ucode_version) >> 8) 
& 0xff;
+   family_id = (__force u32)(hdr->ucode_version) & 0xff;
+   version_major = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 24) & 0xff;
+   version_minor = (le32_to_cpu((__force 
__le32)(hdr->ucode_version))
+>> 8) & 0xff;
DRM_INFO("Found UVD firmware Version: %u.%u Family ID: 
%u\n",
 version_major, version_minor, family_id);
  
@@ -791,17 +793,17 @@ int radeon_uvd_get_create_msg(struct radeon_device *rdev, int ring,

return r;
  
  	/* stitch together an UVD create msg */

-   writel(cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
writel(0x0, (void __iomem *)[1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
writel(0x0, [4]);
writel(0x0, [5]);
writel(0x0, [6]);
-   writel(cpu_to_le32(0x0780), [7]);
-   writel(cpu_to_le32(0x0440), [8]);
+   writel((__force u32)cpu_to_le32(0x0780), [7]);
+   writel((__force u32)cpu_to_le32(0x0440), [8]);
writel(0x0, [9]);
-   writel(cpu_to_le32(0x01b37000), [10]);
+   writel((__force u32)cpu_to_le32(0x01b37000), [10]);
for (i = 11; i < 1024; ++i)
writel(0x0, [i]);
  
@@ -827,9 +829,9 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, int ring,

return r;
  
  	/* stitch together an UVD destroy msg */

-   writel(cpu_to_le32(0x0de4), [0]);
-   writel(cpu_to_le32(0x0002), [1]);
-   writel(cpu_to_le32(handle), [2]);
+   writel((__force u32)cpu_to_le32(0x0de4), [0]);
+   writel((__force u32)cpu_to_le32(0x0002), [1]);
+   writel((__force u32)cpu_to_le32(handle), [2]);
writel(0x0, [3]);
for (i = 4; i < 1024; ++i)
writel(0x0, [i]);


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm: amdgpu: Remove unneeded semicolon in amdgpu_vm.c


Am 03.06.21 um 05:28 schrieb Wan Jiabing:

Fix following coccicheck warning:
./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1726:2-3: Unneeded semicolon

Signed-off-by: Wan Jiabing 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 2460371..231745b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1723,7 +1723,7 @@ int amdgpu_vm_bo_update_mapping(struct amdgpu_device 
*adev,
  
  		amdgpu_res_next(, num_entries * AMDGPU_GPU_PAGE_SIZE);

start = tmp;
-   };
+   }
  
  	r = vm->update_funcs->commit(, fence);
  


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH v3 4/8] drm/amd/pm: Add navi1x throttler translation