Re: [PATCH 1/2] drm/amdgpu: Add comment to function amdgpu_ttm_alloc_gart
Reviewed-by: Christian König for the series.
Am 11.09.20 um 20:25 schrieb Oak Zeng:
Add comments to refect what function does
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 63e5414..8b70445 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1210,7 +1210,12 @@ static int amdgpu_ttm_backend_bind(struct ttm_tt *ttm,
}
/**
- * amdgpu_ttm_alloc_gart - Allocate GART memory for buffer object
+ * amdgpu_ttm_alloc_gart - Make sure buffer object is accessible either
+ * through AGP or GART aperture.
+ *
+ * If bo is accessible through AGP aperture, then use AGP aperture
+ * to access bo; otherwise allocate logical space in GART aperture
+ * and map bo to GART aperture.
*/
int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo)
{
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: drop BOOLEAN define in display part
use bool directly
Signed-off-by: Flora Cui
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +-
drivers/gpu/drm/amd/display/dc/dm_pp_smu.h | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index c5f2216e59c4..6a28fdd50e05 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -810,7 +810,7 @@ pp_nv_set_hard_min_uclk_by_freq(struct pp_smu *pp, int mhz)
}
static enum pp_smu_status pp_nv_set_pstate_handshake_support(
- struct pp_smu *pp, BOOLEAN pstate_handshake_supported)
+ struct pp_smu *pp, bool pstate_handshake_supported)
{
const struct dc_context *ctx = pp->dm;
struct amdgpu_device *adev = ctx->driver_context;
diff --git a/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
b/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
index ae608c329366..3586934df25f 100644
--- a/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
+++ b/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
@@ -30,8 +30,6 @@
* interface to PPLIB/SMU to setup clocks and pstate requirements on SoC
*/
-typedef bool BOOLEAN;
-
enum pp_smu_ver {
/*
* PP_SMU_INTERFACE_X should be interpreted as the interface defined
@@ -240,7 +238,7 @@ struct pp_smu_funcs_nv {
* DC hardware
*/
enum pp_smu_status (*set_pstate_handshake_support)(struct pp_smu *pp,
- BOOLEAN pstate_handshake_supported);
+ bool pstate_handshake_supported);
};
#define PP_SMU_NUM_SOCCLK_DPM_LEVELS 8
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: Power-saving/performance toggles for amdgpu
On Mon, Sep 7, 2020 at 10:30 AM Bastien Nocera wrote: > > Hey, > > I'm currently working on a daemon that allows a UI that will eventually > look like the power mode section in this mockup: > https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/power/power.png > > The daemon: > https://gitlab.freedesktop.org/hadess/power-profiles-daemon > The UI: > https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/816 > > It might be interesting, on some systems, to nudge the GPU drivers > in the direction wanted by the user, either enabling aggressive power- > saving or allowing more power to be used for better temporary > performance. > > I was wondering whether the tweaks > in /sys/class/drm/card*/device/power_profile > and /sys/class/drm/card*/device/power_method were things that this > daemon could and should tweak, or whether it was present solely for > debug purposes and shouldn't be needed even when high performance or > power-saving is wanted: > https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/3 > > Thanks in advance! > On older radeons (e.g., pre-GCN hardware), there were separate power states for battery and AC, but these asics are supported by the radeon kernel driver. None of the hardware supported by amdgpu exposes anything like that anymore. The rest is mainly for profiling and debugging. For more information see the relevant kernel documentation: https://www.kernel.org/doc/html/latest/gpu/amdgpu.html#gpu-power-thermal-controls-and-monitoring I don't think there is anything you'd want to tweak there. Alex ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: add debugfs entry for trigger_hotplug
The 'trigger_hotplug' entry in debugfs is defined but not wired up. This
causes a gcc warning build with W=1.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:2045:37:
warning: ‘dp_trigger_hotplug_debugfs_fops’ defined but not used
[-Wunused-const-variable=]
2045 | static const struct file_operations
dp_trigger_hotplug_debugfs_fops = {
|
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 94fcb086154c..972c780b6293 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -2115,6 +2115,7 @@ static const struct {
{"dsc_pic_height", &dp_dsc_pic_height_debugfs_fops},
{"dsc_chunk_size", &dp_dsc_chunk_size_debugfs_fops},
{"dsc_slice_bpg", &dp_dsc_slice_bpg_offset_debugfs_fops},
+ {"trigger_hotplug", &dp_trigger_hotplug_debugfs_fops},
{"dp_dsc_fec_support", &dp_dsc_fec_support_fops}
};
--
2.25.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
first bad commit: [fc8c70526bd30733ea8667adb8b8ffebea30a8ed] drm/radeon: Prefer lower feedback dividers
Hi, this patch breaks X on my box - it is fully responsive and I can log in into it from another machine but both monitors are black and show this: "The current input timing is not supported by the monitor display. Please change your input timing to 1920x1200@60Hz or any other monitor listed timing as per the monitor specifications." Reverting it fixes the issue. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Workaround RCC_DEV0_EPF0_STRAP0 access issue for SRIOV
On Fri, Sep 11, 2020 at 6:03 PM Rohit Khaire wrote:
>
> Signed-off-by: Rohit Khaire
> ---
> drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
> b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
> index 7429f30398b9..fdfa075e6d5a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
> +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
> @@ -51,8 +51,20 @@ static void nbio_v2_3_remap_hdp_registers(struct
> amdgpu_device *adev)
>
> static u32 nbio_v2_3_get_rev_id(struct amdgpu_device *adev)
> {
> - u32 tmp = RREG32_SOC15(NBIO, 0, mmRCC_DEV0_EPF0_STRAP0);
> + u32 tmp;
>
> + /*
> +* On SRIOV VF RCC_DEV0_EPF0_STRAP is blocked.
> +* So we read rev_id from PCI config space.
> +*/
> + if (amdgpu_sriov_vf(adev)) {
> + pci_read_config_dword(adev->pdev, PCI_REVISION_ID, &tmp);
This is not going to do what you want. The pci revision id is not the
same as the ati rev id. If you actually want the pci revision id, we
already have it in adev->pdev->revision, no need to fetch it directly.
Alex
> + /* Revision ID is the least significant 8 bits */
> + tmp &= 0xFF;
> + return tmp;
> + }
> +
> + tmp = RREG32_SOC15(NBIO, 0, mmRCC_DEV0_EPF0_STRAP0);
> tmp &= RCC_DEV0_EPF0_STRAP0__STRAP_ATI_REV_ID_DEV0_F0_MASK;
> tmp >>= RCC_DEV0_EPF0_STRAP0__STRAP_ATI_REV_ID_DEV0_F0__SHIFT;
>
> --
> 2.17.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] amdgpu/gmc_v9: Warn if SDPIF_MMIO_CNTRL_0 is not set
With IOMMU enabled, if SDPIF_MMIO_CNTRL_0 is not set
appropriately the system hangs without any trace
during S3.
To ease debug and to ensure that the failure, if any,
was caused by a race conditions that disabled write access to
SDPIF_MMIO_CNTRL_0 register, warn the user about it.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index d0645ad3446e..fc2d88dbe828 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -1546,8 +1546,11 @@ static void gmc_v9_0_init_golden_registers(struct
amdgpu_device *adev)
*/
void gmc_v9_0_restore_registers(struct amdgpu_device *adev)
{
- if (adev->asic_type == CHIP_RAVEN)
+ if (adev->asic_type == CHIP_RAVEN) {
WREG32_SOC15(DCE, 0, mmDCHUBBUB_SDPIF_MMIO_CNTRL_0,
adev->gmc.sdpif_register);
+ WARN_ON(adev->gmc.sdpif_register !=
+ RREG32_SOC15(DCE, 0, mmDCHUBBUB_SDPIF_MMIO_CNTRL_0);
+ }
}
/**
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
kernel NULL pointer dereference with dce_aux_transfer_raw
Hi, first I had some enabling link 2 failed: 15 after DPMS, but then I got a NULL pointer dereference later. I'm running 5.8.8 + "Require primary plane to be enabled whenever the CRTC is" 2x 4K DisplayPort monitors. Gnome Wayland desktop, Ubuntu 20.10. sep 14 00:22:01 mammut kernel: [ cut here ] sep 14 00:22:01 mammut kernel: WARNING: CPU: 3 PID: 2113 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:2419 decide_link_settings+0x22e/0x250 [amdgpu] sep 14 00:22:01 mammut kernel: Modules linked in: input_leds joydev overlay snd_hda_codec_realtek snd_hda_codec_generic binfmt_misc ledtrig_audio snd_hda_codec_hdmi edac_mce_amd amdgpu snd_hda_intel snd_intel_dspcfg kvm_amd snd_hda_codec nls_iso8859_1 snd_usb_audio snd_hda_core snd_usbmidi_lib kvm snd_hwdep snd_pcm snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_cl> sep 14 00:22:01 mammut kernel: CPU: 3 PID: 2113 Comm: gnome-shell Tainted: GW OE 5.8.8+ #16 sep 14 00:22:01 mammut kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 5603 07/28/2020 sep 14 00:22:01 mammut kernel: RIP: 0010:decide_link_settings+0x22e/0x250 [amdgpu] sep 14 00:22:01 mammut kernel: Code: 8b 54 24 18 49 89 06 49 89 56 08 e9 05 ff ff ff 48 8b 83 88 00 00 00 48 8b 93 90 00 00 00 49 89 06 49 89 56 08 e9 eb fe ff ff <0f> 0b e9 d5 fe ff ff 8b 4b 5c e9 c3 fe ff ff e8 4e 09 b0 eb 66 66 sep 14 00:22:01 mammut kernel: RSP: 0018:9e508205f5d0 EFLAGS: 00010246 sep 14 00:22:01 mammut kernel: RAX: RBX: 8f2b30e84400 RCX: sep 14 00:22:01 mammut kernel: RDX: 0001 RSI: 9e508205f628 RDI: 8f2b32fa7030 sep 14 00:22:01 mammut kernel: RBP: 9e508205f618 R08: 8f2b32fa7000 R09: 9e508205f5c0 sep 14 00:22:01 mammut kernel: R10: 0001 R11: 0003 R12: 00c34830 sep 14 00:22:01 mammut kernel: R13: 8f2b32fa7000 R14: 9e508205f628 R15: 9e508205f628 sep 14 00:22:01 mammut kernel: FS: 7f16aa242d80() GS:8f2b3e8c() knlGS: sep 14 00:22:01 mammut kernel: CS: 0010 DS: ES: CR0: 80050033 sep 14 00:22:01 mammut kernel: CR2: 558c697954e0 CR3: 0007d304e000 CR4: 003406e0 sep 14 00:22:01 mammut kernel: Call Trace: sep 14 00:22:01 mammut kernel: enable_link_dp+0x14c/0x210 [amdgpu] sep 14 00:22:01 mammut kernel: core_link_enable_stream+0x65b/0x7f0 [amdgpu] sep 14 00:22:01 mammut kernel: dce110_apply_ctx_to_hw+0x590/0x5d0 [amdgpu] sep 14 00:22:01 mammut kernel: dc_commit_state+0x339/0xa10 [amdgpu] sep 14 00:22:01 mammut kernel: ? kfree+0xb8/0x250 sep 14 00:22:01 mammut kernel: ? drm_calc_timestamping_constants+0x10b/0x150 [drm] sep 14 00:22:01 mammut kernel: amdgpu_dm_atomic_commit_tail+0x33e/0x2250 [amdgpu] sep 14 00:22:01 mammut kernel: ? update_load_avg+0x643/0x670 sep 14 00:22:01 mammut kernel: ? __cgroup_account_cputime+0x2f/0x50 sep 14 00:22:01 mammut kernel: ? update_curr+0x78/0x210 sep 14 00:22:01 mammut kernel: ? update_cfs_group+0x9c/0xb0 sep 14 00:22:01 mammut kernel: ? dequeue_entity+0xb6/0x440 sep 14 00:22:01 mammut kernel: ? newidle_balance+0xe8/0x410 sep 14 00:22:01 mammut kernel: ? __switch_to+0x157/0x470 sep 14 00:22:01 mammut kernel: ? finish_task_switch+0x75/0x260 sep 14 00:22:01 mammut kernel: ? ttm_bo_mem_compat+0x28/0x60 [ttm] sep 14 00:22:01 mammut kernel: ? ttm_bo_validate+0x54/0x180 [ttm] sep 14 00:22:01 mammut kernel: ? amdgpu_bo_pin_restricted+0x64/0x2c0 [amdgpu] sep 14 00:22:01 mammut kernel: ? ttm_bo_move_to_lru_tail+0x26/0xd0 [ttm] sep 14 00:22:01 mammut kernel: ? ttm_eu_backoff_reservation+0x5d/0x70 [ttm] sep 14 00:22:01 mammut kernel: ? amdgpu_bo_gpu_offset+0x23/0xa0 [amdgpu] sep 14 00:22:01 mammut kernel: ? dm_plane_helper_prepare_fb+0x136/0x2a0 [amdgpu] sep 14 00:22:01 mammut kernel: ? wait_for_completion_timeout+0xc0/0xf0 sep 14 00:22:01 mammut kernel: commit_tail+0x99/0x130 [drm_kms_helper] sep 14 00:22:01 mammut kernel: drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] sep 14 00:22:01 mammut kernel: amdgpu_dm_atomic_commit+0xbd/0xd0 [amdgpu] sep 14 00:22:01 mammut kernel: drm_atomic_commit+0x4a/0x50 [drm] sep 14 00:22:01 mammut kernel: drm_atomic_helper_set_config+0x7c/0xc0 [drm_kms_helper] sep 14 00:22:01 mammut kernel: drm_mode_setcrtc+0x20b/0x7d0 [drm] sep 14 00:22:01 mammut kernel: ? drm_mode_getcrtc+0x190/0x190 [drm] sep 14 00:22:01 mammut kernel: drm_ioctl_kernel+0xae/0xf0 [drm] sep 14 00:22:01 mammut kernel: drm_ioctl+0x238/0x3d0 [drm] sep 14 00:22:01 mammut kernel: ? drm_mode_getcrtc+0x190/0x190 [drm] sep 14 00:22:01 mammut kernel: amdgpu_drm_ioctl+0x4e/0x80 [amdgpu] sep 14 00:22:01 mammut kernel: ksys_ioctl+0x8e/0xc0 sep 14 00:22:01 mammut kernel: __x64_sys_ioctl+0x1a/0x20 sep 14 00:22:01 mammut kernel: do_syscall_64+0x52/0xc0 sep 14 00:22:01 mammut kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 sep 14 00:22:01 mammut kernel: RIP: 0033:0x7f16af88f31b sep 14 00:22:01 mammut kerne
