[PATCH] drm/amdgpu: VCN 3.0 multiple queue ring reset

2020-12-02 Thread Sonny Jiang 
Signed-off-by: Sonny Jiang 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index 4f718ee803d0..3eaabcfca94a 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -1080,6 +1080,7 @@ static int vcn_v3_0_start_dpg_mode(struct amdgpu_device 
*adev, int inst_idx, boo
 
 static int vcn_v3_0_start(struct amdgpu_device *adev)
 {
+   volatile struct amdgpu_fw_shared *fw_shared;
struct amdgpu_ring *ring;
uint32_t rb_bufsz, tmp;
int i, j, k, r;
@@ -1222,6 +1223,9 @@ static int vcn_v3_0_start(struct amdgpu_device *adev)
tmp = REG_SET_FIELD(tmp, UVD_RBC_RB_CNTL, RB_RPTR_WR_EN, 1);
WREG32_SOC15(VCN, i, mmUVD_RBC_RB_CNTL, tmp);
 
+   fw_shared = adev->vcn.inst[i].fw_shared_cpu_addr;
+   fw_shared->multi_queue.decode_queue_mode |= FW_QUEUE_RING_RESET;
+
/* programm the RB_BASE for ring buffer */
WREG32_SOC15(VCN, i, mmUVD_LMI_RBC_RB_64BIT_BAR_LOW,
lower_32_bits(ring->gpu_addr));
@@ -1234,19 +1238,25 @@ static int vcn_v3_0_start(struct amdgpu_device *adev)
ring->wptr = RREG32_SOC15(VCN, i, mmUVD_RBC_RB_RPTR);
WREG32_SOC15(VCN, i, mmUVD_RBC_RB_WPTR,
lower_32_bits(ring->wptr));
+   fw_shared->multi_queue.decode_queue_mode &= 
~FW_QUEUE_RING_RESET;
+
+   fw_shared->multi_queue.encode_generalpurpose_queue_mode |= 
FW_QUEUE_RING_RESET;
ring = >vcn.inst[i].ring_enc[0];
WREG32_SOC15(VCN, i, mmUVD_RB_RPTR, lower_32_bits(ring->wptr));
WREG32_SOC15(VCN, i, mmUVD_RB_WPTR, lower_32_bits(ring->wptr));
WREG32_SOC15(VCN, i, mmUVD_RB_BASE_LO, ring->gpu_addr);
WREG32_SOC15(VCN, i, mmUVD_RB_BASE_HI, 
upper_32_bits(ring->gpu_addr));
WREG32_SOC15(VCN, i, mmUVD_RB_SIZE, ring->ring_size / 4);
+   fw_shared->multi_queue.encode_generalpurpose_queue_mode &= 
~FW_QUEUE_RING_RESET;
 
+   fw_shared->multi_queue.encode_lowlatency_queue_mode |= 
FW_QUEUE_RING_RESET;
ring = >vcn.inst[i].ring_enc[1];
WREG32_SOC15(VCN, i, mmUVD_RB_RPTR2, lower_32_bits(ring->wptr));
WREG32_SOC15(VCN, i, mmUVD_RB_WPTR2, lower_32_bits(ring->wptr));
WREG32_SOC15(VCN, i, mmUVD_RB_BASE_LO2, ring->gpu_addr);
WREG32_SOC15(VCN, i, mmUVD_RB_BASE_HI2, 
upper_32_bits(ring->gpu_addr));
WREG32_SOC15(VCN, i, mmUVD_RB_SIZE2, ring->ring_size / 4);
+   fw_shared->multi_queue.encode_lowlatency_queue_mode &= 
~FW_QUEUE_RING_RESET;
}
 
return 0;
@@ -1595,6 +1605,7 @@ static int vcn_v3_0_stop(struct amdgpu_device *adev)
 static int vcn_v3_0_pause_dpg_mode(struct amdgpu_device *adev,
   int inst_idx, struct dpg_pause_state *new_state)
 {
+   volatile struct amdgpu_fw_shared *fw_shared;
struct amdgpu_ring *ring;
uint32_t reg_data = 0;
int ret_code;
@@ -1626,6 +1637,8 @@ static int vcn_v3_0_pause_dpg_mode(struct amdgpu_device 
*adev,

~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK);
 
/* Restore */
+   fw_shared = 
adev->vcn.inst[inst_idx].fw_shared_cpu_addr;
+   
fw_shared->multi_queue.encode_generalpurpose_queue_mode |= FW_QUEUE_RING_RESET;
ring = >vcn.inst[inst_idx].ring_enc[0];
ring->wptr = 0;
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_BASE_LO, 
ring->gpu_addr);
@@ -1633,7 +1646,9 @@ static int vcn_v3_0_pause_dpg_mode(struct amdgpu_device 
*adev,
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_SIZE, 
ring->ring_size / 4);
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_RPTR, 
lower_32_bits(ring->wptr));
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_WPTR, 
lower_32_bits(ring->wptr));
+   
fw_shared->multi_queue.encode_generalpurpose_queue_mode &= ~FW_QUEUE_RING_RESET;
 
+   
fw_shared->multi_queue.encode_lowlatency_queue_mode |= FW_QUEUE_RING_RESET;
ring = >vcn.inst[inst_idx].ring_enc[1];
ring->wptr = 0;
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_BASE_LO2, 
ring->gpu_addr);
@@ -1641,6 +1656,7 @@ static int vcn_v3_0_pause_dpg_mode(struct amdgpu_device 
*adev,
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_SIZE2, 
ring->ring_size / 4);
WREG32_SOC15(VCN, inst_idx, mmUVD_RB_RPTR2, 
lower_32_bits(ring->wptr));

Re: [PATCH 2/2] drm: amdgpu: fix a kernel-doc markup

2020-12-02 Thread Alex Deucher 
On Wed, Dec 2, 2020 at 3:45 AM Christian König  wrote:
>
> Am 02.12.20 um 09:27 schrieb Mauro Carvalho Chehab:
> > The function name at kernel-doc markup doesn't match the name
> > of the function:
> >
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting 
> > prototype for amdgpu_debugfs_print_bo_info(). Prototype was for 
> > amdgpu_bo_print_info() instead
> >
> > Fix it.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
>
> Reviewed-by: Christian König 
>

Applied.  Thanks!

Alex

> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > index c6c9723d3d8a..fd7a93c32235 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > @@ -1518,7 +1518,7 @@ uint32_t amdgpu_bo_get_preferred_pin_domain(struct 
> > amdgpu_device *adev,
> >   } while (0)
> >
> >   /**
> > - * amdgpu_debugfs_print_bo_info - print BO info in debugfs file
> > + * amdgpu_bo_print_info - print BO info in debugfs file
> >*
> >* @id: Index or Id of the BO
> >* @bo: Requested BO for printing info
>
> ___
> 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

[pull] amdgpu drm-fixes-5.10

2020-12-02 Thread Alex Deucher 
Hi Dave, Daniel,

Fixes for 5.10.

The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da:

  Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-12-02

for you to fetch changes up to efd6d85a18102241538dd1cc257948a0dbe6fae6:

  drm/amdgpu/vcn3.0: remove old DPG workaround (2020-12-02 22:55:48 -0500)


amd-drm-fixes-5.10-2020-12-02:

amdgpu:
- SMU11 manual fan fix
- Renoir display clock fix
- VCN3 dynamic powergating fix


Arunpravin (1):
  drm/amdgpu/pm/smu11: Fix fan set speed bug

Boyuan Zhang (2):
  drm/amdgpu/vcn3.0: stall DPG when WPTR/RPTR reset
  drm/amdgpu/vcn3.0: remove old DPG workaround

Brandon Syu (1):
  drm/amd/display: Init clock value by current vbios CLKs

 drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c  | 25 --
 .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c  | 13 +--
 drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c |  7 +-
 3 files changed, 36 insertions(+), 9 deletions(-)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-02 Thread Zack Rusin 


> On Dec 2, 2020, at 11:03, Daniel Vetter  wrote:
> 
> On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin  wrote:
>> 
>> 
>> 
>>> On Dec 2, 2020, at 09:27, Thomas Zimmermann  wrote:
>>> 
>>> Hi
>>> 
>>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
 Hi
 Am 30.11.20 um 21:59 schrieb Zack Rusin:
> 
> 
>> On Nov 24, 2020, at 06:38, Thomas Zimmermann  wrote:
>> 
>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
>> drm_device.dev. No functional changes.
>> 
>> Signed-off-by: Thomas Zimmermann 
>> Cc: Roland Scheidegger 
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
> 
> Reviewed-by: Zack Rusin 
 Could you add this patch to the vmwgfx tree?
>>> 
>>> AMD devs indicated that they'd prefer to merge the patchset trough 
>>> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through 
>>> drm-misc-next as well.
>> 
>> Sounds good. I’ll make sure to rebase our latest patch set on top of it when 
>> it’s in. Thanks!
> 
> btw if you want to avoid multi-tree coordination headaches, we can
> also manage vmwgfx in drm-misc and give you & Roland commit rights
> there. Up to you. There is some scripting involved for now (but I hope
> whenever we move to gitlab we could do the checks server-side):

I’d be happy to take you up on that. I would like to move a lot more of our 
development into public repos and reducing the burden of maintaining multiple 
trees would help. Is there a lot of changes to drm core that doesn’t go through 
drm-misc? Or alternatively is drm-misc often pulling from Linus’ master? I’m 
trying to figure out how much would our need to rebase/merge be reduced if we 
just used drm-misc-next/drm-misc-fixes because that would also allow me to 
point some internal testing infrastructure at it as well.

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

RE: [PATCH] drm/amdgpu/powerplay: parse fan table for CI asics

2020-12-02 Thread Quan, Evan 
[AMD Official Use Only - Internal Distribution Only]

Acked-by: Evan Quan 

-Original Message-
From: amd-gfx  On Behalf Of Alex Deucher
Sent: Thursday, December 3, 2020 4:18 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander 
Subject: [PATCH] drm/amdgpu/powerplay: parse fan table for CI asics

Set up all the parameters required for SMU fan control if supported.

Bug: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D201539data=04%7C01%7Cevan.quan%40amd.com%7C5c05d069b0e04d822a1608d896ff5c89%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425370804495239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WNkQfQiTDGtHx7V8pw2vntXXWeOv6KWA1qENo6wiTAw%3Dreserved=0
Signed-off-by: Alex Deucher 
---
 .../amd/pm/powerplay/hwmgr/processpptables.c  | 103 +-
 1 file changed, 102 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
index 48d550d26c6a..182118e3fd5f 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include "processpptables.h"
 #include 
@@ -980,6 +982,8 @@ static int init_thermal_controller(
 struct pp_hwmgr *hwmgr,
 const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
 {
+struct amdgpu_device *adev = hwmgr->adev;
+
 hwmgr->thermal_controller.ucType =
 powerplay_table->sThermalController.ucType;
 hwmgr->thermal_controller.ucI2cLine =
@@ -1004,7 +1008,104 @@ static int init_thermal_controller(
ATOM_PP_THERMALCONTROLLER_NONE != hwmgr->thermal_controller.ucType,
PHM_PlatformCaps_ThermalController);

-hwmgr->thermal_controller.use_hw_fan_control = 1;
+if (powerplay_table->usTableSize >= 
sizeof(ATOM_PPLIB_POWERPLAYTABLE3)) {
+const ATOM_PPLIB_POWERPLAYTABLE3 *powerplay_table3 =
+(const ATOM_PPLIB_POWERPLAYTABLE3 *)powerplay_table;
+
+if (0 == le16_to_cpu(powerplay_table3->usFanTableOffset)) {
+hwmgr->thermal_controller.use_hw_fan_control = 1;
+return 0;
+} else {
+const ATOM_PPLIB_FANTABLE *fan_table =
+(const ATOM_PPLIB_FANTABLE *)(((unsigned long)powerplay_table) +
+  le16_to_cpu(powerplay_table3->usFanTableOffset));
+
+if (1 <= fan_table->ucFanTableFormat) {
+hwmgr->thermal_controller.advanceFanControlParameters.ucTHyst =
+fan_table->ucTHyst;
+hwmgr->thermal_controller.advanceFanControlParameters.usTMin =
+le16_to_cpu(fan_table->usTMin);
+hwmgr->thermal_controller.advanceFanControlParameters.usTMed =
+le16_to_cpu(fan_table->usTMed);
+hwmgr->thermal_controller.advanceFanControlParameters.usTHigh =
+le16_to_cpu(fan_table->usTHigh);
+hwmgr->thermal_controller.advanceFanControlParameters.usPWMMin =
+le16_to_cpu(fan_table->usPWMMin);
+hwmgr->thermal_controller.advanceFanControlParameters.usPWMMed =
+le16_to_cpu(fan_table->usPWMMed);
+hwmgr->thermal_controller.advanceFanControlParameters.usPWMHigh =
+le16_to_cpu(fan_table->usPWMHigh);
+hwmgr->thermal_controller.advanceFanControlParameters.usTMax = 10900;
+hwmgr->thermal_controller.advanceFanControlParameters.ulCycleDelay = 10;
+
+phm_cap_set(hwmgr->platform_descriptor.platformCaps,
+PHM_PlatformCaps_MicrocodeFanControl);
+}
+
+if (2 <= fan_table->ucFanTableFormat) {
+const ATOM_PPLIB_FANTABLE2 *fan_table2 =
+(const ATOM_PPLIB_FANTABLE2 *)(((unsigned long)powerplay_table) +
+   le16_to_cpu(powerplay_table3->usFanTableOffset));
+hwmgr->thermal_controller.advanceFanControlParameters.usTMax =
+le16_to_cpu(fan_table2->usTMax);
+}
+
+if (3 <= fan_table->ucFanTableFormat) {
+const ATOM_PPLIB_FANTABLE3 *fan_table3 =
+(const ATOM_PPLIB_FANTABLE3 *) (((unsigned long)powerplay_table) +
+le16_to_cpu(powerplay_table3->usFanTableOffset));
+
+hwmgr->thermal_controller.advanceFanControlParameters.ucFanControlMode =
+fan_table3->ucFanControlMode;
+
+if ((3 == fan_table->ucFanTableFormat) &&
+(0x67B1 == adev->pdev->device))
+hwmgr->thermal_controller.advanceFanControlParameters.usDefaultMaxFanPWM =
+47;
+else
+hwmgr->thermal_controller.advanceFanControlParameters.usDefaultMaxFanPWM =
+le16_to_cpu(fan_table3->usFanPWMMax);
+
+hwmgr->thermal_controller.advanceFanControlParameters.usDefaultFanOutputSensitivity
 =
+4836;
+hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity =
+le16_to_cpu(fan_table3->usFanOutputSensitivity);
+}
+
+if (6 <= fan_table->ucFanTableFormat) {
+const ATOM_PPLIB_FANTABLE4 *fan_table4 =
+(const ATOM_PPLIB_FANTABLE4 *)(((unsigned long)powerplay_table) +
+   le16_to_cpu(powerplay_table3->usFanTableOffset));
+
+phm_cap_set(hwmgr->platform_descriptor.platformCaps,
+PHM_PlatformCaps_FanSpeedInTableIsRPM);
+
+hwmgr->thermal_controller.advanceFanControlParameters.usDefaultMaxFanRPM =
+le16_to_cpu(fan_table4->usFanRPMMax);
+}
+
+if (7 <= fan_table->ucFanTableFormat) {
+const ATOM_PPLIB_FANTABLE5

Re: [PATCH 2/2] drm/amd/display: add cursor pitch check

2020-12-02 Thread Alex Deucher 
On Wed, Dec 2, 2020 at 4:33 PM Kazlauskas, Nicholas
 wrote:
>
> On 2020-12-02 4:09 p.m., Simon Ser wrote:
> > Replace the width check with a pitch check, which matches DM internals.
> > Add a new check to make sure the pitch (in pixels) matches the width.
> >
> > Signed-off-by: Simon Ser 
> > Cc: Alex Deucher 
> > Cc: Harry Wentland 
> > Cc: Nicholas Kazlauskas 
>
> Series is:
>
> Reviewed-by: Nicholas Kazlauskas 

Applied.  Thanks!

Alex

>
> Regards,
> Nicholas Kazlauskas
>
> > ---
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++
> >   1 file changed, 15 insertions(+), 4 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 9e328101187e..862a59703060 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -8988,6 +8988,7 @@ static int dm_update_plane_state(struct dc *dc,
> >   struct amdgpu_crtc *new_acrtc;
> >   bool needs_reset;
> >   int ret = 0;
> > + unsigned int pitch;
> >
> >
> >   new_plane_crtc = new_plane_state->crtc;
> > @@ -9021,15 +9022,25 @@ static int dm_update_plane_state(struct dc *dc,
> >   return -EINVAL;
> >   }
> >
> > - switch (new_plane_state->fb->width) {
> > + /* Pitch in pixels */
> > + pitch = new_plane_state->fb->pitches[0] / 
> > new_plane_state->fb->format->cpp[0];
> > +
> > + if (new_plane_state->fb->width != pitch) {
> > + DRM_DEBUG_ATOMIC("Cursor FB width %d doesn't 
> > match pitch %d",
> > +  new_plane_state->fb->width,
> > +  pitch);
> > + return -EINVAL;
> > + }
> > +
> > + switch (pitch) {
> >   case 64:
> >   case 128:
> >   case 256:
> > - /* FB width is supported by cursor plane */
> > + /* FB pitch is supported by cursor plane */
> >   break;
> >   default:
> > - DRM_DEBUG_ATOMIC("Bad cursor FB width %d\n",
> > -  new_plane_state->fb->width);
> > + DRM_DEBUG_ATOMIC("Bad cursor FB pitch %d 
> > px\n",
> > +  pitch);
> >   return -EINVAL;
> >   }
> >   }
> >
>
> ___
> 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/amd/display: add debug logs for dm_crtc_helper_atomic_check

2020-12-02 Thread Alex Deucher 
On Wed, Dec 2, 2020 at 4:06 PM Simon Ser  wrote:
>
> Instead of silently failing the atomic check, explain what happened via
> a debug log. This makes it easier for user-space to figure out why
> something failed.
>
> Signed-off-by: Simon Ser 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Cc: Nicholas Kazlauskas 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> 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 862a59703060..313501cc39fc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6068,8 +6068,10 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc 
> *crtc,
>  * userspace which stops using the HW cursor altogether in response 
> to the resulting EINVAL.
>  */
> if (crtc_state->enable &&
> -   !(crtc_state->plane_mask & drm_plane_mask(crtc->primary)))
> +   !(crtc_state->plane_mask & drm_plane_mask(crtc->primary))) {
> +   DRM_DEBUG_ATOMIC("Can't enable a CRTC without enabling the 
> primary plane\n");
> return -EINVAL;
> +   }
>
> /* In some use cases, like reset, no stream is attached */
> if (!dm_crtc_state->stream)
> @@ -6078,6 +6080,7 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc 
> *crtc,
> if (dc_validate_stream(dc, dm_crtc_state->stream) == DC_OK)
> return 0;
>
> +   DRM_DEBUG_ATOMIC("Failed DC stream validation\n");
> return ret;
>  }
>
> --
> 2.29.2
>
>
> ___
> 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 2/2] drm/amd/display: add cursor pitch check

2020-12-02 Thread Kazlauskas, Nicholas 

On 2020-12-02 4:09 p.m., Simon Ser wrote:

Replace the width check with a pitch check, which matches DM internals.
Add a new check to make sure the pitch (in pixels) matches the width.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 


Series is:

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++
  1 file changed, 15 insertions(+), 4 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 9e328101187e..862a59703060 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8988,6 +8988,7 @@ static int dm_update_plane_state(struct dc *dc,
struct amdgpu_crtc *new_acrtc;
bool needs_reset;
int ret = 0;
+   unsigned int pitch;
  
  
  	new_plane_crtc = new_plane_state->crtc;

@@ -9021,15 +9022,25 @@ static int dm_update_plane_state(struct dc *dc,
return -EINVAL;
}
  
-			switch (new_plane_state->fb->width) {

+   /* Pitch in pixels */
+   pitch = new_plane_state->fb->pitches[0] / 
new_plane_state->fb->format->cpp[0];
+
+   if (new_plane_state->fb->width != pitch) {
+   DRM_DEBUG_ATOMIC("Cursor FB width %d doesn't match 
pitch %d",
+new_plane_state->fb->width,
+pitch);
+   return -EINVAL;
+   }
+
+   switch (pitch) {
case 64:
case 128:
case 256:
-   /* FB width is supported by cursor plane */
+   /* FB pitch is supported by cursor plane */
break;
default:
-   DRM_DEBUG_ATOMIC("Bad cursor FB width %d\n",
-new_plane_state->fb->width);
+   DRM_DEBUG_ATOMIC("Bad cursor FB pitch %d px\n",
+pitch);
return -EINVAL;
}
}



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

[PATCH 2/2] drm/amd/display: add cursor pitch check

2020-12-02 Thread Simon Ser 
Replace the width check with a pitch check, which matches DM internals.
Add a new check to make sure the pitch (in pixels) matches the width.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++
 1 file changed, 15 insertions(+), 4 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 9e328101187e..862a59703060 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8988,6 +8988,7 @@ static int dm_update_plane_state(struct dc *dc,
struct amdgpu_crtc *new_acrtc;
bool needs_reset;
int ret = 0;
+   unsigned int pitch;
 
 
new_plane_crtc = new_plane_state->crtc;
@@ -9021,15 +9022,25 @@ static int dm_update_plane_state(struct dc *dc,
return -EINVAL;
}
 
-   switch (new_plane_state->fb->width) {
+   /* Pitch in pixels */
+   pitch = new_plane_state->fb->pitches[0] / 
new_plane_state->fb->format->cpp[0];
+
+   if (new_plane_state->fb->width != pitch) {
+   DRM_DEBUG_ATOMIC("Cursor FB width %d doesn't 
match pitch %d",
+new_plane_state->fb->width,
+pitch);
+   return -EINVAL;
+   }
+
+   switch (pitch) {
case 64:
case 128:
case 256:
-   /* FB width is supported by cursor plane */
+   /* FB pitch is supported by cursor plane */
break;
default:
-   DRM_DEBUG_ATOMIC("Bad cursor FB width %d\n",
-new_plane_state->fb->width);
+   DRM_DEBUG_ATOMIC("Bad cursor FB pitch %d px\n",
+pitch);
return -EINVAL;
}
}
-- 
2.29.2


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

[PATCH 1/2] drm/amd/display: use FB pitch to fill dc_cursor_attributes

2020-12-02 Thread Simon Ser 
Instead of relying on pitch (in pixels) == width, use the FB pitch. This
is less confusing to readers, and works correctly if we ever support FBs
with a pitch (in pixels) != width.

This also makes the code symmetrical with fill_plane_buffer_attributes.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 35920e5c73e7..9e328101187e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7432,7 +7432,7 @@ static void handle_cursor_update(struct drm_plane *plane,
attributes.rotation_angle= 0;
attributes.attribute_flags.value = 0;
 
-   attributes.pitch = attributes.width;
+   attributes.pitch = afb->base.pitches[0] / afb->base.format->cpp[0];
 
if (crtc_state->stream) {
mutex_lock(>dm.dc_lock);
-- 
2.29.2


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

[PATCH 0/2] drm/amd/display: add cursor pitch check

2020-12-02 Thread Simon Ser 
We were checking the FB width/height, but were not checking its pitch.

This has been tested by running Sway.

Simon Ser (2):
  drm/amd/display: use FB pitch to fill dc_cursor_attributes
  drm/amd/display: add cursor pitch check

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++-
 1 file changed, 16 insertions(+), 5 deletions(-)

-- 
2.29.2


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

[PATCH] drm/amd/display: add debug logs for dm_crtc_helper_atomic_check

2020-12-02 Thread Simon Ser 
Instead of silently failing the atomic check, explain what happened via
a debug log. This makes it easier for user-space to figure out why
something failed.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

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 862a59703060..313501cc39fc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6068,8 +6068,10 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc 
*crtc,
 * userspace which stops using the HW cursor altogether in response to 
the resulting EINVAL.
 */
if (crtc_state->enable &&
-   !(crtc_state->plane_mask & drm_plane_mask(crtc->primary)))
+   !(crtc_state->plane_mask & drm_plane_mask(crtc->primary))) {
+   DRM_DEBUG_ATOMIC("Can't enable a CRTC without enabling the 
primary plane\n");
return -EINVAL;
+   }
 
/* In some use cases, like reset, no stream is attached */
if (!dm_crtc_state->stream)
@@ -6078,6 +6080,7 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc 
*crtc,
if (dc_validate_stream(dc, dm_crtc_state->stream) == DC_OK)
return 0;
 
+   DRM_DEBUG_ATOMIC("Failed DC stream validation\n");
return ret;
 }
 
-- 
2.29.2


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

[PATCH] drm/amdgpu/powerplay: parse fan table for CI asics

2020-12-02 Thread Alex Deucher 
Set up all the parameters required for SMU fan control if supported.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=201539
Signed-off-by: Alex Deucher 
---
 .../amd/pm/powerplay/hwmgr/processpptables.c  | 103 +-
 1 file changed, 102 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
index 48d550d26c6a..182118e3fd5f 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include "processpptables.h"
 #include 
@@ -980,6 +982,8 @@ static int init_thermal_controller(
struct pp_hwmgr *hwmgr,
const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
 {
+   struct amdgpu_device *adev = hwmgr->adev;
+
hwmgr->thermal_controller.ucType =
powerplay_table->sThermalController.ucType;
hwmgr->thermal_controller.ucI2cLine =
@@ -1004,7 +1008,104 @@ static int init_thermal_controller(
   ATOM_PP_THERMALCONTROLLER_NONE != 
hwmgr->thermal_controller.ucType,
   PHM_PlatformCaps_ThermalController);
 
-   hwmgr->thermal_controller.use_hw_fan_control = 1;
+if (powerplay_table->usTableSize >= 
sizeof(ATOM_PPLIB_POWERPLAYTABLE3)) {
+   const ATOM_PPLIB_POWERPLAYTABLE3 *powerplay_table3 =
+   (const ATOM_PPLIB_POWERPLAYTABLE3 *)powerplay_table;
+
+   if (0 == le16_to_cpu(powerplay_table3->usFanTableOffset)) {
+   hwmgr->thermal_controller.use_hw_fan_control = 1;
+   return 0;
+   } else {
+   const ATOM_PPLIB_FANTABLE *fan_table =
+   (const ATOM_PPLIB_FANTABLE *)(((unsigned 
long)powerplay_table) +
+ 
le16_to_cpu(powerplay_table3->usFanTableOffset));
+
+   if (1 <= fan_table->ucFanTableFormat) {
+   
hwmgr->thermal_controller.advanceFanControlParameters.ucTHyst =
+   fan_table->ucTHyst;
+   
hwmgr->thermal_controller.advanceFanControlParameters.usTMin =
+   le16_to_cpu(fan_table->usTMin);
+   
hwmgr->thermal_controller.advanceFanControlParameters.usTMed =
+   le16_to_cpu(fan_table->usTMed);
+   
hwmgr->thermal_controller.advanceFanControlParameters.usTHigh =
+   le16_to_cpu(fan_table->usTHigh);
+   
hwmgr->thermal_controller.advanceFanControlParameters.usPWMMin =
+   le16_to_cpu(fan_table->usPWMMin);
+   
hwmgr->thermal_controller.advanceFanControlParameters.usPWMMed =
+   le16_to_cpu(fan_table->usPWMMed);
+   
hwmgr->thermal_controller.advanceFanControlParameters.usPWMHigh =
+   le16_to_cpu(fan_table->usPWMHigh);
+   
hwmgr->thermal_controller.advanceFanControlParameters.usTMax = 10900;
+   
hwmgr->thermal_controller.advanceFanControlParameters.ulCycleDelay = 10;
+
+   
phm_cap_set(hwmgr->platform_descriptor.platformCaps,
+   
PHM_PlatformCaps_MicrocodeFanControl);
+   }
+
+   if (2 <= fan_table->ucFanTableFormat) {
+   const ATOM_PPLIB_FANTABLE2 *fan_table2 =
+   (const ATOM_PPLIB_FANTABLE2 
*)(((unsigned long)powerplay_table) +
+  
le16_to_cpu(powerplay_table3->usFanTableOffset));
+   
hwmgr->thermal_controller.advanceFanControlParameters.usTMax =
+   le16_to_cpu(fan_table2->usTMax);
+   }
+
+   if (3 <= fan_table->ucFanTableFormat) {
+   const ATOM_PPLIB_FANTABLE3 *fan_table3 =
+   (const ATOM_PPLIB_FANTABLE3 *) 
(((unsigned long)powerplay_table) +
+   
le16_to_cpu(powerplay_table3->usFanTableOffset));
+
+   
hwmgr->thermal_controller.advanceFanControlParameters.ucFanControlMode =
+   fan_table3->ucFanControlMode;
+
+   if ((3 == fan_table->ucFanTableFormat) &&
+   (0x67B1 == adev->pdev->device))
+

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-12-02 Thread Greg KH 
On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:
> 
> On 12/2/20 12:34 PM, Greg KH wrote:
> > On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
> > > On 11/11/20 10:34 AM, Greg KH wrote:
> > > > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> > > > > On 11/10/20 12:59 PM, Greg KH wrote:
> > > > > > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
> > > > > > > Hi, back to this after a long context switch for some higher 
> > > > > > > priority stuff.
> > > > > > > 
> > > > > > > So here I was able eventually to drop all this code and this 
> > > > > > > change here 
> > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C29ff7efb89bd47d8488708d896e86e7c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425272317529134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Vzc3fVofA6%2BMPSqHmBqcWavQLKWU1%2FXKJFun24irLf0%3Dreserved=0
> > > > > > > was enough for me. Seems like while device_remove_file can handle 
> > > > > > > the use
> > > > > > > case where the file and the parent directory already gone,
> > > > > > > sysfs_remove_group goes down in flames in that case
> > > > > > > due to kobj->sd being unset on device removal.
> > > > > > A driver shouldn't ever have to remove individual sysfs groups, the
> > > > > > driver core/bus logic should do it for them automatically.
> > > > > > 
> > > > > > And whenever a driver calls a sysfs_* call, that's a hint that 
> > > > > > something
> > > > > > is not working properly.
> > > > > 
> > > > > Do you mean that while the driver creates the groups and files 
> > > > > explicitly
> > > > > from it's different subsystems it should not explicitly remove each
> > > > > one of them because all of them should be removed at once (and
> > > > > recursively) when the device is being removed ?
> > > > Individual drivers should never add groups/files in sysfs, the driver
> > > > core should do it properly for you if you have everything set up
> > > > properly.  And yes, the driver core will automatically remove them as
> > > > well.
> > > > 
> > > > Please use the default groups attribute for your bus/subsystem and this
> > > > will happen automagically.
> > > 
> > > Hi Greg, I tried your suggestion to hang amdgpu's sysfs
> > > attributes on default attributes in struct device.groups but turns out 
> > > it's
> > > not usable since by the
> > > time i have access to struct device from amdgpu code it has already been
> > > initialized by pci core
> > > (i.e.  past the point where 
> > > device_add->device_add_attrs->device_add_groups
> > > with dev->groups is called)
> > > and so i can't really use it.
> > That's odd, why can't you just set the groups pointer in your pci_driver
> > structure?  That's what it is there for, right?
> 
> I am probably missing something but amdgpu sysfs attrs are per device not
> per driver

Oops, you are right, you want the 'dev_groups' field.  Looks like pci
doesn't export that directly, so you can do:
.driver {
.dev_groups = my_device_groups;
},
in your pci_driver structure.

Or I'm sure the PCI driver maintainer would take a patch like
7d9c1d2f7aca ("USB: add support for dev_groups to struct
usb_device_driver") was done for the USB subsystem, as diving into the
"raw" .driver pointer isn't really that clean or nice in my opinion.

thanks,

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

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-12-02 Thread Andrey Grodzovsky 


On 12/2/20 1:20 PM, Greg KH wrote:

On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:

On 12/2/20 12:34 PM, Greg KH wrote:

On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:

On 11/11/20 10:34 AM, Greg KH wrote:

On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:

On 11/10/20 12:59 PM, Greg KH wrote:

On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:

Hi, back to this after a long context switch for some higher priority stuff.

So here I was able eventually to drop all this code and this change here 
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C13040ab9b50947a95acc08d896eec15d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425299507092187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CIXEl9hWHTAdo7t9yrdtu0OdEIZ3X2GQmJRhDUj28mw%3Dreserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.

A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.

And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.

Do you mean that while the driver creates the groups and files explicitly
from it's different subsystems it should not explicitly remove each
one of them because all of them should be removed at once (and
recursively) when the device is being removed ?

Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly.  And yes, the driver core will automatically remove them as
well.

Please use the default groups attribute for your bus/subsystem and this
will happen automagically.

Hi Greg, I tried your suggestion to hang amdgpu's sysfs
attributes on default attributes in struct device.groups but turns out it's
not usable since by the
time i have access to struct device from amdgpu code it has already been
initialized by pci core
(i.e.  past the point where device_add->device_add_attrs->device_add_groups
with dev->groups is called)
and so i can't really use it.

That's odd, why can't you just set the groups pointer in your pci_driver
structure?  That's what it is there for, right?

I am probably missing something but amdgpu sysfs attrs are per device not
per driver

Oops, you are right, you want the 'dev_groups' field.  Looks like pci
doesn't export that directly, so you can do:
.driver {
.dev_groups = my_device_groups;
},
in your pci_driver structure.

Or I'm sure the PCI driver maintainer would take a patch like
7d9c1d2f7aca ("USB: add support for dev_groups to struct
usb_device_driver") was done for the USB subsystem, as diving into the
"raw" .driver pointer isn't really that clean or nice in my opinion.



Looks like what I need exactly. I will probably start with assigning raw pointer 
just

to push ahead my work and in parallel will probably submit same patch as yours
for PCI subsystem review as the rework to switch to this is really minimal.

Andrey




thanks,

greg k-h

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

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-12-02 Thread Andrey Grodzovsky 


On 12/2/20 12:34 PM, Greg KH wrote:

On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:

On 11/11/20 10:34 AM, Greg KH wrote:

On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:

On 11/10/20 12:59 PM, Greg KH wrote:

On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:

Hi, back to this after a long context switch for some higher priority stuff.

So here I was able eventually to drop all this code and this change here 
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C29ff7efb89bd47d8488708d896e86e7c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425272317529134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Vzc3fVofA6%2BMPSqHmBqcWavQLKWU1%2FXKJFun24irLf0%3Dreserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.

A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.

And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.


Do you mean that while the driver creates the groups and files explicitly
from it's different subsystems it should not explicitly remove each
one of them because all of them should be removed at once (and
recursively) when the device is being removed ?

Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly.  And yes, the driver core will automatically remove them as
well.

Please use the default groups attribute for your bus/subsystem and this
will happen automagically.


Hi Greg, I tried your suggestion to hang amdgpu's sysfs
attributes on default attributes in struct device.groups but turns out it's
not usable since by the
time i have access to struct device from amdgpu code it has already been
initialized by pci core
(i.e.  past the point where device_add->device_add_attrs->device_add_groups
with dev->groups is called)
and so i can't really use it.

That's odd, why can't you just set the groups pointer in your pci_driver
structure?  That's what it is there for, right?


I am probably missing something but amdgpu sysfs attrs are per device not per 
driver
and their life cycle is bound to the device and their location in the sysfs 
topology is
under each device. Putting them as driver default attr will not put them in 
their current per device location
and won't make them automatically be destroyed once a particular device goes 
away, no ?


Andrey





What I can only think of using is creating my own struct attribute_group **
array in amdgpu where I aggregate all
amdgpu sysfs attributes, call device_add_groups in the end of amgpu pci
probe with that array and on device remove call
device_remove_groups with the same array.

Horrid, no, see above :)

thanks,

greg k-h

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

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-12-02 Thread Greg KH 
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
> 
> On 11/11/20 10:34 AM, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> > > On 11/10/20 12:59 PM, Greg KH wrote:
> > > > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
> > > > > Hi, back to this after a long context switch for some higher priority 
> > > > > stuff.
> > > > > 
> > > > > So here I was able eventually to drop all this code and this change 
> > > > > here 
> > > > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9fbfecac94a340dfb68408d886571609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407055896651058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ye8HJR1vidppcOBnlOgVu5GwKD2%2Bb5ztHbiI%2BubKKT0%3Dreserved=0
> > > > > was enough for me. Seems like while device_remove_file can handle the 
> > > > > use
> > > > > case where the file and the parent directory already gone,
> > > > > sysfs_remove_group goes down in flames in that case
> > > > > due to kobj->sd being unset on device removal.
> > > > A driver shouldn't ever have to remove individual sysfs groups, the
> > > > driver core/bus logic should do it for them automatically.
> > > > 
> > > > And whenever a driver calls a sysfs_* call, that's a hint that something
> > > > is not working properly.
> > > 
> > > 
> > > Do you mean that while the driver creates the groups and files explicitly
> > > from it's different subsystems it should not explicitly remove each
> > > one of them because all of them should be removed at once (and
> > > recursively) when the device is being removed ?
> > Individual drivers should never add groups/files in sysfs, the driver
> > core should do it properly for you if you have everything set up
> > properly.  And yes, the driver core will automatically remove them as
> > well.
> > 
> > Please use the default groups attribute for your bus/subsystem and this
> > will happen automagically.
> 
> 
> Hi Greg, I tried your suggestion to hang amdgpu's sysfs
> attributes on default attributes in struct device.groups but turns out it's
> not usable since by the
> time i have access to struct device from amdgpu code it has already been
> initialized by pci core
> (i.e.  past the point where device_add->device_add_attrs->device_add_groups
> with dev->groups is called)
> and so i can't really use it.

That's odd, why can't you just set the groups pointer in your pci_driver
structure?  That's what it is there for, right?

> What I can only think of using is creating my own struct attribute_group **
> array in amdgpu where I aggregate all
> amdgpu sysfs attributes, call device_add_groups in the end of amgpu pci
> probe with that array and on device remove call
> device_remove_groups with the same array.

Horrid, no, see above :)

thanks,

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

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-02 Thread Daniel Vetter 
On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin  wrote:
>
>
>
> > On Dec 2, 2020, at 09:27, Thomas Zimmermann  wrote:
> >
> > Hi
> >
> > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
> >> Hi
> >> Am 30.11.20 um 21:59 schrieb Zack Rusin:
> >>>
> >>>
>  On Nov 24, 2020, at 06:38, Thomas Zimmermann  wrote:
> 
>  Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
>  drm_device.dev. No functional changes.
> 
>  Signed-off-by: Thomas Zimmermann 
>  Cc: Roland Scheidegger 
>  ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
> >>>
> >>> Reviewed-by: Zack Rusin 
> >> Could you add this patch to the vmwgfx tree?
> >
> > AMD devs indicated that they'd prefer to merge the patchset trough 
> > drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through 
> > drm-misc-next as well.
>
> Sounds good. I’ll make sure to rebase our latest patch set on top of it when 
> it’s in. Thanks!

btw if you want to avoid multi-tree coordination headaches, we can
also manage vmwgfx in drm-misc and give you & Roland commit rights
there. Up to you. There is some scripting involved for now (but I hope
whenever we move to gitlab we could do the checks server-side):

https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

2020-12-02 Thread Andrey Grodzovsky 


On 11/11/20 10:34 AM, Greg KH wrote:

On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:

On 11/10/20 12:59 PM, Greg KH wrote:

On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:

Hi, back to this after a long context switch for some higher priority stuff.

So here I was able eventually to drop all this code and this change here 
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C9fbfecac94a340dfb68408d886571609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407055896651058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ye8HJR1vidppcOBnlOgVu5GwKD2%2Bb5ztHbiI%2BubKKT0%3Dreserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.

A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.

And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.



Do you mean that while the driver creates the groups and files explicitly
from it's different subsystems it should not explicitly remove each
one of them because all of them should be removed at once (and
recursively) when the device is being removed ?

Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly.  And yes, the driver core will automatically remove them as
well.

Please use the default groups attribute for your bus/subsystem and this
will happen automagically.



Hi Greg, I tried your suggestion to hang amdgpu's sysfs
attributes on default attributes in struct device.groups but turns out it's not 
usable since by the
time i have access to struct device from amdgpu code it has already been 
initialized by pci core
(i.e.  past the point where device_add->device_add_attrs->device_add_groups with 
dev->groups is called)

and so i can't really use it.

What I can only think of using is creating my own struct attribute_group ** 
array in amdgpu where I aggregate all
amdgpu sysfs attributes, call device_add_groups in the end of amgpu pci probe 
with that array and on device remove call

device_remove_groups with the same array.

Do you maybe have a better suggestion for me ?

Andrey




thanks,

greg k-h


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

Re: [PATCH] tests/amdgpu: Fix a typo

2020-12-02 Thread Luben Tuikov 
Thanks Alex.

Regards,
Luben

On 2020-12-01 09:42, Deucher, Alexander wrote:
> [AMD Official Use Only - Internal Distribution Only]
> 
> 
> Reviewed-by: Alex Deucher 
> 
> libdrm uses gitlab MRs now:
> https://gitlab.freedesktop.org/mesa/drm/-/merge_requests 
> 
> 
> Alex
> 
> --
> *From:* Tuikov, Luben 
> *Sent:* Monday, November 30, 2020 5:12 PM
> *To:* amd-gfx@lists.freedesktop.org 
> *Cc:* Deucher, Alexander ; Tuikov, Luben 
> 
> *Subject:* [PATCH] tests/amdgpu: Fix a typo
>  
> Fix a typo: "TZM" --> "TMZ"
> 
> Signed-off-by: Luben Tuikov 
> ---
>  tests/amdgpu/security_tests.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
> index 9b39e167..351eac82 100644
> --- a/tests/amdgpu/security_tests.c
> +++ b/tests/amdgpu/security_tests.c
> @@ -172,7 +172,7 @@ static void amdgpu_sdma_nop(uint32_t *packet, uint32_t 
> nop_count)
>  }
>  
>  /**
> - * amdgpu_bo_lcopy -- linear copy with TZM set, using sDMA
> + * amdgpu_bo_lcopy -- linear copy with TMZ set, using sDMA
>   * @dev: AMDGPU device to which both buffer objects belong to
>   * @dst: destination buffer object
>   * @src: source buffer object
> -- 
> 2.29.2.404.ge67fbf927d
> 

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

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-02 Thread Zack Rusin 


> On Dec 2, 2020, at 09:27, Thomas Zimmermann  wrote:
> 
> Hi
> 
> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
>> Hi
>> Am 30.11.20 um 21:59 schrieb Zack Rusin:
>>> 
>>> 
 On Nov 24, 2020, at 06:38, Thomas Zimmermann  wrote:
 
 Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
 drm_device.dev. No functional changes.
 
 Signed-off-by: Thomas Zimmermann 
 Cc: Roland Scheidegger 
 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
>>> 
>>> Reviewed-by: Zack Rusin 
>> Could you add this patch to the vmwgfx tree?
> 
> AMD devs indicated that they'd prefer to merge the patchset trough 
> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through 
> drm-misc-next as well.

Sounds good. I’ll make sure to rebase our latest patch set on top of it when 
it’s in. Thanks!

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

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces

2020-12-02 Thread Thomas Zimmermann 

Hi

Am 02.12.20 um 15:02 schrieb Alex Deucher:

On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann  wrote:


Hi

Am 02.12.20 um 09:43 schrieb Christian König:

Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:

Hi

Am 01.12.20 um 11:40 schrieb Christian König:

Reviewed-by: Christian König  on patch #1
and #15.

Acked-by: Christian König  on patch #2 and
#16.


Could you add these patches to the AMD tree?


Alex is usually the one who picks such stuff up.

But when people send out patch sets which mix changes from different
drivers it is more common to push them through drm-misc-next.


I'm OK with drm-misc-next. I just don't want to add too many merge
conflicts in your side.


Yeah, it doesn't matter to me.  I assumed you wanted to land this
whole series so you could move forward with further cleanups.  If we
merge via different trees, you'll have to wait for all of this to come
together again in drm-next.


OK, sure. I'll merge it through drm-misc-next.

Best regards
Thomas



Alex




Best regards
Thomas



Regards,
Christian.



Best regards
Thomas



Regards,
Christian.

Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:

Adhere to kernel coding style.

Signed-off-by: Thomas Zimmermann 
Acked-by: Alex Deucher 
Acked-by: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Christian König 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5f304425c948..da23c0f21311 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4922,8 +4922,8 @@ pci_ers_result_t
amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta
   case pci_channel_io_normal:
   return PCI_ERS_RESULT_CAN_RECOVER;
   /* Fatal error, prepare for slot reset */
-case pci_channel_io_frozen:
-/*
+case pci_channel_io_frozen:
+/*
* Cancel and wait for all TDRs in progress if failing to
* set  adev->in_gpu_reset in amdgpu_device_lock_adev
*
@@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct
pci_dev *pdev)
   goto out;
   }
-adev->in_pci_err_recovery = true;
+adev->in_pci_err_recovery = true;
   r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
   adev->in_pci_err_recovery = false;
   if (r)








--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

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

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-02 Thread Thomas Zimmermann 

Hi

Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:

Hi

Am 30.11.20 um 21:59 schrieb Zack Rusin:



On Nov 24, 2020, at 06:38, Thomas Zimmermann  
wrote:


Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Roland Scheidegger 
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c    | 27 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-


Reviewed-by: Zack Rusin 


Could you add this patch to the vmwgfx tree?


AMD devs indicated that they'd prefer to merge the patchset trough 
drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch 
through drm-misc-next as well.


Best regards
Thomas



Best regards
Thomas



z




___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces

2020-12-02 Thread Alex Deucher 
On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 02.12.20 um 09:43 schrieb Christian König:
> > Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:
> >> Hi
> >>
> >> Am 01.12.20 um 11:40 schrieb Christian König:
> >>> Reviewed-by: Christian König  on patch #1
> >>> and #15.
> >>>
> >>> Acked-by: Christian König  on patch #2 and
> >>> #16.
> >>
> >> Could you add these patches to the AMD tree?
> >
> > Alex is usually the one who picks such stuff up.
> >
> > But when people send out patch sets which mix changes from different
> > drivers it is more common to push them through drm-misc-next.
>
> I'm OK with drm-misc-next. I just don't want to add too many merge
> conflicts in your side.

Yeah, it doesn't matter to me.  I assumed you wanted to land this
whole series so you could move forward with further cleanups.  If we
merge via different trees, you'll have to wait for all of this to come
together again in drm-next.

Alex


>
> Best regards
> Thomas
>
> >
> > Regards,
> > Christian.
> >
> >>
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>> Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
>  Adhere to kernel coding style.
> 
>  Signed-off-by: Thomas Zimmermann 
>  Acked-by: Alex Deucher 
>  Acked-by: Sam Ravnborg 
>  Cc: Alex Deucher 
>  Cc: Christian König 
>  ---
>    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
>    1 file changed, 3 insertions(+), 3 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  index 5f304425c948..da23c0f21311 100644
>  --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>  @@ -4922,8 +4922,8 @@ pci_ers_result_t
>  amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta
>    case pci_channel_io_normal:
>    return PCI_ERS_RESULT_CAN_RECOVER;
>    /* Fatal error, prepare for slot reset */
>  -case pci_channel_io_frozen:
>  -/*
>  +case pci_channel_io_frozen:
>  +/*
> * Cancel and wait for all TDRs in progress if failing to
> * set  adev->in_gpu_reset in amdgpu_device_lock_adev
> *
>  @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct
>  pci_dev *pdev)
>    goto out;
>    }
>  -adev->in_pci_err_recovery = true;
>  +adev->in_pci_err_recovery = true;
>    r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
>    adev->in_pci_err_recovery = false;
>    if (r)
> >>>
> >>
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
> ___
> 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 v2 01/20] drm/amdgpu: Fix trailing whitespaces

2020-12-02 Thread Thomas Zimmermann 

Hi

Am 02.12.20 um 09:43 schrieb Christian König:

Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:

Hi

Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König  on patch #1 
and #15.


Acked-by: Christian König  on patch #2 and 
#16.


Could you add these patches to the AMD tree?


Alex is usually the one who picks such stuff up.

But when people send out patch sets which mix changes from different 
drivers it is more common to push them through drm-misc-next.


I'm OK with drm-misc-next. I just don't want to add too many merge 
conflicts in your side.


Best regards
Thomas



Regards,
Christian.



Best regards
Thomas



Regards,
Christian.

Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:

Adhere to kernel coding style.

Signed-off-by: Thomas Zimmermann 
Acked-by: Alex Deucher 
Acked-by: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

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

index 5f304425c948..da23c0f21311 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4922,8 +4922,8 @@ pci_ers_result_t 
amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta

  case pci_channel_io_normal:
  return PCI_ERS_RESULT_CAN_RECOVER;
  /* Fatal error, prepare for slot reset */
-    case pci_channel_io_frozen:
-    /*
+    case pci_channel_io_frozen:
+    /*
   * Cancel and wait for all TDRs in progress if failing to
   * set  adev->in_gpu_reset in amdgpu_device_lock_adev
   *
@@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct 
pci_dev *pdev)

  goto out;
  }
-    adev->in_pci_err_recovery = true;
+    adev->in_pci_err_recovery = true;
  r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
  adev->in_pci_err_recovery = false;
  if (r)








--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm: amdgpu: fix a kernel-doc markup

2020-12-02 Thread Christian König 

Am 02.12.20 um 09:27 schrieb Mauro Carvalho Chehab:

The function name at kernel-doc markup doesn't match the name
of the function:

drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting 
prototype for amdgpu_debugfs_print_bo_info(). Prototype was for 
amdgpu_bo_print_info() instead

Fix it.

Signed-off-by: Mauro Carvalho Chehab 


Reviewed-by: Christian König 


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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c6c9723d3d8a..fd7a93c32235 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1518,7 +1518,7 @@ uint32_t amdgpu_bo_get_preferred_pin_domain(struct 
amdgpu_device *adev,
} while (0)
  
  /**

- * amdgpu_debugfs_print_bo_info - print BO info in debugfs file
+ * amdgpu_bo_print_info - print BO info in debugfs file
   *
   * @id: Index or Id of the BO
   * @bo: Requested BO for printing info


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

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces

2020-12-02 Thread Christian König 

Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:

Hi

Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König  on patch #1 
and #15.


Acked-by: Christian König  on patch #2 and 
#16.


Could you add these patches to the AMD tree?


Alex is usually the one who picks such stuff up.

But when people send out patch sets which mix changes from different 
drivers it is more common to push them through drm-misc-next.


Regards,
Christian.



Best regards
Thomas



Regards,
Christian.

Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:

Adhere to kernel coding style.

Signed-off-by: Thomas Zimmermann 
Acked-by: Alex Deucher 
Acked-by: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

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

index 5f304425c948..da23c0f21311 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4922,8 +4922,8 @@ pci_ers_result_t 
amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta

  case pci_channel_io_normal:
  return PCI_ERS_RESULT_CAN_RECOVER;
  /* Fatal error, prepare for slot reset */
-    case pci_channel_io_frozen:
-    /*
+    case pci_channel_io_frozen:
+    /*
   * Cancel and wait for all TDRs in progress if failing to
   * set  adev->in_gpu_reset in amdgpu_device_lock_adev
   *
@@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct 
pci_dev *pdev)

  goto out;
  }
-    adev->in_pci_err_recovery = true;
+    adev->in_pci_err_recovery = true;
  r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
  adev->in_pci_err_recovery = false;
  if (r)






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

[PATCH 2/2] drm: amdgpu: fix a kernel-doc markup

2020-12-02 Thread Mauro Carvalho Chehab 
The function name at kernel-doc markup doesn't match the name
of the function:

drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1534: warning: expecting 
prototype for amdgpu_debugfs_print_bo_info(). Prototype was for 
amdgpu_bo_print_info() instead

Fix it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c6c9723d3d8a..fd7a93c32235 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1518,7 +1518,7 @@ uint32_t amdgpu_bo_get_preferred_pin_domain(struct 
amdgpu_device *adev,
} while (0)
 
 /**
- * amdgpu_debugfs_print_bo_info - print BO info in debugfs file
+ * amdgpu_bo_print_info - print BO info in debugfs file
  *
  * @id: Index or Id of the BO
  * @bo: Requested BO for printing info
-- 
2.28.0

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

[PATCH 0/2] Fix some kernel-doc markups with wrong identifiers

2020-12-02 Thread Mauro Carvalho Chehab 
After applying this patch over next-20201201:

   
https://lore.kernel.org/linux-doc/cover.1606823973.git.mchehab+hua...@kernel.org/T/#m0072adc6eb1af595a31fcc3b019cb81ab28c7b9f

There are a couple of new warnings that the kernel-doc prototype
doesn't match the documented function.

This series address them.

Mauro Carvalho Chehab (2):
  asm: sgx.h: fix a typo on a kernel-doc markup
  drm: amdgpu: fix a kernel-doc markup

 arch/x86/include/uapi/asm/sgx.h| 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.28.0


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

Re: [PATCH v2 18/20] drm/virtgpu: Remove references to struct drm_device.pdev

2020-12-02 Thread Gerd Hoffmann 
On Tue, Dec 01, 2020 at 11:35:40AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert virtgpu to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v2 14/20] drm/qxl: Remove references to struct drm_device.pdev

2020-12-02 Thread Gerd Hoffmann 
On Tue, Dec 01, 2020 at 11:35:36AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert qxl to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v2 05/20] drm/cirrus: Remove references to struct drm_device.pdev

2020-12-02 Thread Gerd Hoffmann 
On Tue, Dec 01, 2020 at 11:35:27AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert cirrus to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v2 04/20] drm/bochs: Remove references to struct drm_device.pdev

2020-12-02 Thread Gerd Hoffmann 
On Tue, Dec 01, 2020 at 11:35:26AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert bochs to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Gerd Hoffmann 

Acked-by: Gerd Hoffmann 

> ---
>  drivers/gpu/drm/bochs/bochs_drv.c | 1 -
>  drivers/gpu/drm/bochs/bochs_hw.c  | 4 ++--
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index fd454225fd19..b469624fe40d 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -121,7 +121,6 @@ static int bochs_pci_probe(struct pci_dev *pdev,
>   if (ret)
>   goto err_free_dev;
>  
> - dev->pdev = pdev;
>   pci_set_drvdata(pdev, dev);
>  
>   ret = bochs_load(dev);
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c 
> b/drivers/gpu/drm/bochs/bochs_hw.c
> index dce4672e3fc8..2d7380a9890e 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -110,7 +110,7 @@ int bochs_hw_load_edid(struct bochs_device *bochs)
>  int bochs_hw_init(struct drm_device *dev)
>  {
>   struct bochs_device *bochs = dev->dev_private;
> - struct pci_dev *pdev = dev->pdev;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
>   unsigned long addr, size, mem, ioaddr, iosize;
>   u16 id;
>  
> @@ -201,7 +201,7 @@ void bochs_hw_fini(struct drm_device *dev)
>   release_region(VBE_DISPI_IOPORT_INDEX, 2);
>   if (bochs->fb_map)
>   iounmap(bochs->fb_map);
> - pci_release_regions(dev->pdev);
> + pci_release_regions(to_pci_dev(dev->dev));
>   kfree(bochs->edid);
>  }
>  
> -- 
> 2.29.2
> 

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

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-02 Thread Thomas Zimmermann 

Hi

Am 30.11.20 um 21:59 schrieb Zack Rusin:




On Nov 24, 2020, at 06:38, Thomas Zimmermann  wrote:

Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Roland Scheidegger 
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-


Reviewed-by: Zack Rusin 


Could you add this patch to the vmwgfx tree?

Best regards
Thomas



z



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces

2020-12-02 Thread Thomas Zimmermann 

Hi

Am 01.12.20 um 11:40 schrieb Christian König:
Reviewed-by: Christian König  on patch #1 and 
#15.


Acked-by: Christian König  on patch #2 and #16.


Could you add these patches to the AMD tree?

Best regards
Thomas



Regards,
Christian.

Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:

Adhere to kernel coding style.

Signed-off-by: Thomas Zimmermann 
Acked-by: Alex Deucher 
Acked-by: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

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

index 5f304425c948..da23c0f21311 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4922,8 +4922,8 @@ pci_ers_result_t 
amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta

  case pci_channel_io_normal:
  return PCI_ERS_RESULT_CAN_RECOVER;
  /* Fatal error, prepare for slot reset */
-    case pci_channel_io_frozen:
-    /*
+    case pci_channel_io_frozen:
+    /*
   * Cancel and wait for all TDRs in progress if failing to
   * set  adev->in_gpu_reset in amdgpu_device_lock_adev
   *
@@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct 
pci_dev *pdev)

  goto out;
  }
-    adev->in_pci_err_recovery = true;
+    adev->in_pci_err_recovery = true;
  r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
  adev->in_pci_err_recovery = false;
  if (r)




--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx