RE: [PATCH] drm/amdgpu: fix gfx hang during suspend with video playback
> -Original Message-
> From: Huang, Ray
> Sent: Friday, April 3, 2020 6:29 PM
> To: Liang, Prike
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Quan, Evan ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with video
> playback
>
> On Fri, Apr 03, 2020 at 06:05:55PM +0800, Huang Rui wrote:
> > On Fri, Apr 03, 2020 at 05:22:28PM +0800, Liang, Prike wrote:
> > >
> > > > -Original Message-
> > > > From: Huang, Ray
> > > > Sent: Friday, April 3, 2020 2:27 PM
> > > > To: Liang, Prike
> > > > Cc: amd-gfx@lists.freedesktop.org; Quan, Evan
> ;
> > > > Deucher, Alexander ; Kuehling, Felix
> > > >
> > > > Subject: Re: [PATCH] drm/amdgpu: fix gfx hang during suspend with
> > > > video playback
> > > >
> > > > (+ Felix)
> > > >
> > > > On Fri, Apr 03, 2020 at 12:07:53PM +0800, Liang, Prike wrote:
> > > > > The system will be hang up during S3 as SMU is pending at GC not
> > > > > respose the register CP_HQD_ACTIVE access request and this issue
> > > > > can be fixed by adding RLC safe mode guard before each HQD
> > > > > map/unmap retrive opt.
> > > >
> > > > We need more information for the issue, does the map/unmap is
> > > > required for MAP_QUEUES/UNMAP_QUEUES packets or writing with
> MMIO or both?
> > > >
> > > [Prike] The issue hang up at MP1 was trying to read register
> > > RSMU_RESIDENCY_COUNTER_GC but did not get response from GFX,
> since GFX was busy at reading register CP_HQD_ACTIVE.
> > > Moreover, when disabled GFXOFF this issue also can't see so there is
> > > likely to perform register accessed at GFXOFF CGPG/CGCG enter stage.
> > > As for only this issue, that seems just MMIO access failed case which
> occurred under QUEUE map/unmap status check.
> > >
> >
> > While we start to do S3, we will disable gfxoff at start of suspend.
> > Then in this point, the gfx should be always in "on" state.
> >
> > > > From your patch, you just protect the kernel kiq and user queue.
> > > > What about other kernel compute queues? HIQ?
> > > >
> > > [Prike] So far just find the KIQ/CPQ/DIQ map/unmap will inquire the
> > > CP_HQD_ACTIVE status by MMIO accessing, therefore just guard the KIQ
> and some type user queue now. Regarding HIQ map and ummap which used
> the method of submitting configuration packet.
> > >
> >
> > KIQ itself init/unit should be always under gfx on state. Can you give
> > a check the result if not add enter/exit rlc safe mode around it?
>
> Wait... In your case, the system didn't load any user queues because no
> ROCm based application is running. So the issue is probably caused by KIQ
> itself init/unit, can you confirm?
[Prike] This improper register access is under performing MQD destroy
during amdkfd suspend period. For the KIQ UNI process may not need the RLC
guard as GFX CGPG has been disabled at the early suspend period.
If have concern the other case over guard will send a patch for simplify it.
>
> Thanks,
> Ray
>
> >
> > Hi Felix, maybe we need to use packets with kiq to map all user queues.
> >
> > Thanks,
> > Ray
> >
> > > > Thanks,
> > > > Ray
> > > >
> > > > >
> > > > > Signed-off-by: Prike Liang
> > > > > Tested-by: Mengbing Wang
> > > > > ---
> > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 6
> ++
> > > > > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4
> > > > > 2 files changed, 10 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > > index df841c2..e265063 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> > > > > @@ -232,6 +232,7 @@ int kgd_gfx_v9_hqd_load(struct kgd_dev *kgd,
> > > > > void
> > > > *mqd, uint32_t pipe_id,
> > > > > uint32_t *mqd_hqd;
> > > > > uint32_t reg, hqd_base, data;
> > > > >
> > > > > + amdgpu_gfx_rlc_enter_safe_mode(adev);
> > > > > m = get_mqd(mqd);
> > > > >
> > > > > acquire_queue(kgd, pipe_id, queue_id); @@ -299,6 +300,7 @@ int
> > > > > kgd_gfx_v9_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t
> > > > > pipe_id,
> > > > >
> > > > > release_queue(kgd);
> > > > >
> > > > > + amdgpu_gfx_rlc_exit_safe_mode(adev);
> > > > > return 0;
> > > > > }
> > > > >
> > > > > @@ -497,6 +499,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct
> > > > > kgd_dev
> > > > *kgd, uint64_t queue_address,
> > > > > bool retval = false;
> > > > > uint32_t low, high;
> > > > >
> > > > > + amdgpu_gfx_rlc_enter_safe_mode(adev);
> > > > > acquire_queue(kgd, pipe_id, queue_id);
> > > > > act = RREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_ACTIVE));
> > > > > if (act) {
> > > > > @@ -508,6 +511,7 @@ bool kgd_gfx_v9_hqd_is_occupied(struct
> > > > > kgd_dev
> > > > *kgd, uint64_t queue_address,
> > > > > retval = true;
> > > > > }
> > > > > release_queue(kgd);
RE: [PATCH] drm/amdgpu: resolve mGPU RAS query instability
[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Hawking Zhang Per discussion, please have a separated patch to replace all the "DRM_INFO" with "dev_info" in per IP query_ras_error_count callback function so that we will have clear picture on which errors are from which nodes when harvest all the RAS errors in one gpu recovery worker. Regards, Hawking From: Clements, John Sent: Tuesday, April 7, 2020 11:03 To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ; Chen, Guchun ; Li, Dennis ; Zhou1, Tao Subject: [PATCH] drm/amdgpu: resolve mGPU RAS query instability [AMD Official Use Only - Internal Distribution Only] Submitting patch to resolve issue when upon receiving an uncorrectable ras error, RAS ISR gets triggered on all GPU node creating a race condition between querying the RAS errors and entering the GPU reset sequence ___ 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 HDCP caps debugfs
Reviewed-by: Rodrigo Siqueira
On 04/01, Bhawanpreet Lakha wrote:
> Add debugfs to get HDCP capability. This is also useful for
> kms_content_protection igt test.
>
> Use:
> cat /sys/kernel/debug/dri/0/DP-1/hdcp_sink_capability
> cat /sys/kernel/debug/dri/0/HDMI-A-1/hdcp_sink_capability
>
> Signed-off-by: Bhawanpreet Lakha
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 61 +++
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 47 ++
> drivers/gpu/drm/amd/display/dc/dc_link.h | 4 ++
> 3 files changed, 112 insertions(+)
>
> 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 0461fecd68db..4b695f6a80c6 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
> @@ -838,6 +838,44 @@ static int vrr_range_show(struct seq_file *m, void *data)
> return 0;
> }
>
> +#ifdef CONFIG_DRM_AMD_DC_HDCP
> +/*
> + * Returns the HDCP capability of the Display (1.4 for now).
> + *
> + * NOTE* Not all HDMI displays report their HDCP caps even when they are
> capable.
> + * Since its rare for a display to not be HDCP 1.4 capable, we set HDMI as
> always capable.
> + *
> + * Example usage: cat /sys/kernel/debug/dri/0/DP-1/hdcp_sink_capability
> + * or cat /sys/kernel/debug/dri/0/HDMI-A-1/hdcp_sink_capability
> + */
> +static int hdcp_sink_capability_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
> + bool hdcp_cap, hdcp2_cap;
> +
> + if (connector->status != connector_status_connected)
> + return -ENODEV;
> +
> + seq_printf(m, "%s:%d HDCP version: ", connector->name,
> connector->base.id);
> +
> + hdcp_cap = dc_link_is_hdcp14(aconnector->dc_link);
> + hdcp2_cap = dc_link_is_hdcp22(aconnector->dc_link);
> +
> +
> + if (hdcp_cap)
> + seq_printf(m, "%s ", "HDCP1.4");
> + if (hdcp2_cap)
> + seq_printf(m, "%s ", "HDCP2.2");
> +
> + if (!hdcp_cap && !hdcp2_cap)
> + seq_printf(m, "%s ", "None");
> +
> + seq_puts(m, "\n");
> +
> + return 0;
> +}
> +#endif
> /* function description
> *
> * generic SDP message access for testing
> @@ -964,6 +1002,9 @@ DEFINE_SHOW_ATTRIBUTE(dmub_fw_state);
> DEFINE_SHOW_ATTRIBUTE(dmub_tracebuffer);
> DEFINE_SHOW_ATTRIBUTE(output_bpc);
> DEFINE_SHOW_ATTRIBUTE(vrr_range);
> +#ifdef CONFIG_DRM_AMD_DC_HDCP
> +DEFINE_SHOW_ATTRIBUTE(hdcp_sink_capability);
> +#endif
>
> static const struct file_operations dp_link_settings_debugfs_fops = {
> .owner = THIS_MODULE,
> @@ -1019,12 +1060,23 @@ static const struct {
> {"test_pattern", _phy_test_pattern_fops},
> {"output_bpc", _bpc_fops},
> {"vrr_range", _range_fops},
> +#ifdef CONFIG_DRM_AMD_DC_HDCP
> + {"hdcp_sink_capability", _sink_capability_fops},
> +#endif
> {"sdp_message", _message_fops},
> {"aux_dpcd_address", _dpcd_address_debugfs_fops},
> {"aux_dpcd_size", _dpcd_size_debugfs_fops},
> {"aux_dpcd_data", _dpcd_data_debugfs_fops}
> };
>
> +#ifdef CONFIG_DRM_AMD_DC_HDCP
> +static const struct {
> + char *name;
> + const struct file_operations *fops;
> +} hdmi_debugfs_entries[] = {
> + {"hdcp_sink_capability", _sink_capability_fops}
> +};
> +#endif
> /*
> * Force YUV420 output if available from the given mode
> */
> @@ -1093,6 +1145,15 @@ void connector_debugfs_init(struct amdgpu_dm_connector
> *connector)
> connector->debugfs_dpcd_address = 0;
> connector->debugfs_dpcd_size = 0;
>
> +#ifdef CONFIG_DRM_AMD_DC_HDCP
> + if (connector->base.connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> + for (i = 0; i < ARRAY_SIZE(hdmi_debugfs_entries); i++) {
> + debugfs_create_file(hdmi_debugfs_entries[i].name,
> + 0644, dir, connector,
> + hdmi_debugfs_entries[i].fops);
> + }
> + }
> +#endif
> }
>
> /*
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index 49c63e27dfe9..e8b5d7a22ce7 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -515,6 +515,53 @@ static void link_disconnect_remap(struct dc_sink
> *prev_sink, struct dc_link *lin
> }
>
> #if defined(CONFIG_DRM_AMD_DC_HDCP)
> +bool dc_link_is_hdcp14(struct dc_link *link)
> +{
> + bool ret = false;
> +
> + switch (link->connector_signal) {
> + case SIGNAL_TYPE_DISPLAY_PORT:
> + case SIGNAL_TYPE_DISPLAY_PORT_MST:
> + ret = link->hdcp_caps.bcaps.bits.HDCP_CAPABLE;
> + break;
> + case
Re: [PATCH 1/2] drm/amd/display: query hdcp capability during link detect
Reviewed-by: Rodrigo Siqueira
On 04/01, Bhawanpreet Lakha wrote:
> [Why]
> Query the hdcp caps of a link, it is useful and can be reported to the user
>
> [How]
> Create a query function and call it during link detect
>
> Signed-off-by: Bhawanpreet Lakha
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 56
> drivers/gpu/drm/amd/display/dc/dc.h | 41 +
> drivers/gpu/drm/amd/display/dc/dc_link.h | 3 +
> .../gpu/drm/amd/display/dc/hdcp/hdcp_msg.c| 89 +++
> .../gpu/drm/amd/display/include/hdcp_types.h | 7 ++
> 5 files changed, 196 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index a93997ff0419..49c63e27dfe9 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -514,6 +514,50 @@ static void link_disconnect_remap(struct dc_sink
> *prev_sink, struct dc_link *lin
> link->local_sink = prev_sink;
> }
>
> +#if defined(CONFIG_DRM_AMD_DC_HDCP)
> +static void query_hdcp_capability(enum signal_type signal, struct dc_link
> *link)
> +{
> + struct hdcp_protection_message msg22;
> + struct hdcp_protection_message msg14;
> +
> + memset(, 0, sizeof(struct hdcp_protection_message));
> + memset(, 0, sizeof(struct hdcp_protection_message));
> + memset(link->hdcp_caps.rx_caps.raw, 0,
> + sizeof(link->hdcp_caps.rx_caps.raw));
> +
> + if ((link->connector_signal == SIGNAL_TYPE_DISPLAY_PORT &&
> + link->ddc->transaction_type ==
> + DDC_TRANSACTION_TYPE_I2C_OVER_AUX) ||
> + link->connector_signal == SIGNAL_TYPE_EDP) {
> + msg22.data = link->hdcp_caps.rx_caps.raw;
> + msg22.length = sizeof(link->hdcp_caps.rx_caps.raw);
> + msg22.msg_id = HDCP_MESSAGE_ID_RX_CAPS;
> + } else {
> + msg22.data = >hdcp_caps.rx_caps.fields.version;
> + msg22.length = sizeof(link->hdcp_caps.rx_caps.fields.version);
> + msg22.msg_id = HDCP_MESSAGE_ID_HDCP2VERSION;
> + }
> + msg22.version = HDCP_VERSION_22;
> + msg22.link = HDCP_LINK_PRIMARY;
> + msg22.max_retries = 5;
> + dc_process_hdcp_msg(signal, link, );
> +
> + if (signal == SIGNAL_TYPE_DISPLAY_PORT || signal ==
> SIGNAL_TYPE_DISPLAY_PORT_MST) {
> + enum hdcp_message_status status = HDCP_MESSAGE_UNSUPPORTED;
> +
> + msg14.data = >hdcp_caps.bcaps.raw;
> + msg14.length = sizeof(link->hdcp_caps.bcaps.raw);
> + msg14.msg_id = HDCP_MESSAGE_ID_READ_BCAPS;
> + msg14.version = HDCP_VERSION_14;
> + msg14.link = HDCP_LINK_PRIMARY;
> + msg14.max_retries = 5;
> +
> + status = dc_process_hdcp_msg(signal, link, );
> + }
> +
> +}
> +#endif
> +
> static void read_current_link_settings_on_detect(struct dc_link *link)
> {
> union lane_count_set lane_count_set = { {0} };
> @@ -606,6 +650,12 @@ static bool detect_dp(struct dc_link *link,
> dal_ddc_service_set_transaction_type(link->ddc,
>
> sink_caps->transaction_type);
>
> +#if defined(CONFIG_DRM_AMD_DC_HDCP)
> + /* In case of fallback to SST when topology discovery
> below fails
> + * HDCP caps will be querried again later by the upper
> layer (caller
> + * of this function). */
> + query_hdcp_capability(SIGNAL_TYPE_DISPLAY_PORT_MST,
> link);
> +#endif
> /*
>* This call will initiate MST topology discovery. Which
>* will detect MST ports and add new DRM connector DRM
> @@ -975,6 +1025,9 @@ static bool dc_link_detect_helper(struct dc_link *link,
>* TODO debug why Dell 2413 doesn't like
>* two link trainings
>*/
> +#if defined(CONFIG_DRM_AMD_DC_HDCP)
> + query_hdcp_capability(sink->sink_signal, link);
> +#endif
>
> // verify link cap for SST non-seamless boot
> if (!perform_dp_seamless_boot)
> @@ -988,6 +1041,9 @@ static bool dc_link_detect_helper(struct dc_link *link,
> sink = prev_sink;
> prev_sink = NULL;
> }
> +#if defined(CONFIG_DRM_AMD_DC_HDCP)
> + query_hdcp_capability(sink->sink_signal, link);
> +#endif
> }
>
> /* HDMI-DVI Dongle */
> diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
> b/drivers/gpu/drm/amd/display/dc/dc.h
> index 92123b0d1196..9235d04c32dc 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc.h
> @@ -29,6 +29,9 @@
> #include "dc_types.h"
> #include "grph_object_defs.h"
>
Re: [PATCH 6/6] kernel: set USER_DS in kthread_use_mm
On Sat, Apr 04, 2020 at 11:41:01AM +0200, Christoph Hellwig wrote:
> Some architectures like arm64 and s390 require USER_DS to be set for
> kernel threads to access user address space, which is the whole purpose
> of kthread_use_mm, but other like x86 don't. That has lead to a huge
> mess where some callers are fixed up once they are tested on said
> architectures, while others linger around and yet other like io_uring
> try to do "clever" optimizations for what usually is just a trivial
> asignment to a member in the thread_struct for most architectures.
>
> Make kthread_use_mm set USER_DS, and kthread_unuse_mm restore to the
> previous value instead.
>
> Signed-off-by: Christoph Hellwig
I'm ok with vhost bits:
Acked-by: Michael S. Tsirkin
> ---
> drivers/usb/gadget/function/f_fs.c | 4
> drivers/vhost/vhost.c | 3 ---
> fs/io-wq.c | 8 ++--
> fs/io_uring.c | 4
> kernel/kthread.c | 6 ++
> 5 files changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index d9e48bd7c692..a1198f4c527c 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -824,13 +824,9 @@ static void ffs_user_copy_worker(struct work_struct
> *work)
> bool kiocb_has_eventfd = io_data->kiocb->ki_flags & IOCB_EVENTFD;
>
> if (io_data->read && ret > 0) {
> - mm_segment_t oldfs = get_fs();
> -
> - set_fs(USER_DS);
> kthread_use_mm(io_data->mm);
> ret = ffs_copy_to_iter(io_data->buf, ret, _data->data);
> kthread_unuse_mm(io_data->mm);
> - set_fs(oldfs);
> }
>
> io_data->kiocb->ki_complete(io_data->kiocb, ret, ret);
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 1787d426a956..b5229ae01d3b 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -333,9 +333,7 @@ static int vhost_worker(void *data)
> struct vhost_dev *dev = data;
> struct vhost_work *work, *work_next;
> struct llist_node *node;
> - mm_segment_t oldfs = get_fs();
>
> - set_fs(USER_DS);
> kthread_use_mm(dev->mm);
>
> for (;;) {
> @@ -365,7 +363,6 @@ static int vhost_worker(void *data)
> }
> }
> kthread_unuse_mm(dev->mm);
> - set_fs(oldfs);
> return 0;
> }
>
> diff --git a/fs/io-wq.c b/fs/io-wq.c
> index 83c2868eff2a..75cc2f31816d 100644
> --- a/fs/io-wq.c
> +++ b/fs/io-wq.c
> @@ -168,7 +168,6 @@ static bool __io_worker_unuse(struct io_wqe *wqe, struct
> io_worker *worker)
> dropped_lock = true;
> }
> __set_current_state(TASK_RUNNING);
> - set_fs(KERNEL_DS);
> kthread_unuse_mm(worker->mm);
> mmput(worker->mm);
> worker->mm = NULL;
> @@ -420,14 +419,11 @@ static void io_wq_switch_mm(struct io_worker *worker,
> struct io_wq_work *work)
> mmput(worker->mm);
> worker->mm = NULL;
> }
> - if (!work->mm) {
> - set_fs(KERNEL_DS);
> + if (!work->mm)
> return;
> - }
> +
> if (mmget_not_zero(work->mm)) {
> kthread_use_mm(work->mm);
> - if (!worker->mm)
> - set_fs(USER_DS);
> worker->mm = work->mm;
> /* hang on to this mm */
> work->mm = NULL;
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 367406381044..c332a34e8b34 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -5871,15 +5871,12 @@ static int io_sq_thread(void *data)
> struct io_ring_ctx *ctx = data;
> struct mm_struct *cur_mm = NULL;
> const struct cred *old_cred;
> - mm_segment_t old_fs;
> DEFINE_WAIT(wait);
> unsigned long timeout;
> int ret = 0;
>
> complete(>completions[1]);
>
> - old_fs = get_fs();
> - set_fs(USER_DS);
> old_cred = override_creds(ctx->creds);
>
> timeout = jiffies + ctx->sq_thread_idle;
> @@ -5985,7 +5982,6 @@ static int io_sq_thread(void *data)
> if (current->task_works)
> task_work_run();
>
> - set_fs(old_fs);
> if (cur_mm) {
> kthread_unuse_mm(cur_mm);
> mmput(cur_mm);
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index 316db17f6b4f..9e27d01b6d78 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -52,6 +52,7 @@ struct kthread {
> unsigned long flags;
> unsigned int cpu;
> void *data;
> + mm_segment_t oldfs;
> struct completion parked;
> struct completion exited;
> #ifdef CONFIG_BLK_CGROUP
> @@ -1235,6 +1236,9 @@ void kthread_use_mm(struct mm_struct *mm)
>
> if (active_mm != mm)
> mmdrop(active_mm);
> +
> + to_kthread(tsk)->oldfs = get_fs();
> + set_fs(USER_DS);
> }
>
[PATCH v3] drm/amdkfd: Provide SMI events watch
When the compute is malfunctioning or performance drops, the system admin
will use SMI (System Management Interface) tool to monitor/diagnostic what
went wrong. This patch provides an event watch interface for the user
space to register events they are interested. After the event is
registered, the user can use annoymous file descriptor's poll function
with wait-time specified to wait for the event to happen. Once the event
happens, the user can use read() to retrieve information related to the
event.
VM fault event is done in this patch.
v2: - remove UNREGISTER and add event ENABLE/DISABLE
- correct kfifo usage
- move event message API to kfd_ioctl.h
v3: send the event msg in text than in binary
Signed-off-by: Amber Lin
---
drivers/gpu/drm/amd/amdkfd/Makefile | 1 +
drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c | 2 +
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 30
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 2 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 13 ++
drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 174 +++
drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h | 42 ++
include/uapi/linux/kfd_ioctl.h | 32 -
9 files changed, 296 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.h
diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile
b/drivers/gpu/drm/amd/amdkfd/Makefile
index 6147462..e1e4115 100644
--- a/drivers/gpu/drm/amd/amdkfd/Makefile
+++ b/drivers/gpu/drm/amd/amdkfd/Makefile
@@ -53,6 +53,7 @@ AMDKFD_FILES := $(AMDKFD_PATH)/kfd_module.o \
$(AMDKFD_PATH)/kfd_int_process_v9.o \
$(AMDKFD_PATH)/kfd_dbgdev.o \
$(AMDKFD_PATH)/kfd_dbgmgr.o \
+ $(AMDKFD_PATH)/kfd_smi_events.o \
$(AMDKFD_PATH)/kfd_crat.o
ifneq ($(CONFIG_AMD_IOMMU_V2),)
diff --git a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
index 9f59ba9..24b4717 100644
--- a/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
@@ -24,6 +24,7 @@
#include "kfd_events.h"
#include "cik_int.h"
#include "amdgpu_amdkfd.h"
+#include "kfd_smi_events.h"
static bool cik_event_interrupt_isr(struct kfd_dev *dev,
const uint32_t *ih_ring_entry,
@@ -107,6 +108,7 @@ static void cik_event_interrupt_wq(struct kfd_dev *dev,
ihre->source_id == CIK_INTSRC_GFX_MEM_PROT_FAULT) {
struct kfd_vm_fault_info info;
+ kfd_smi_event_update_vmfault(dev, pasid);
kfd_process_vm_fault(dev->dqm, pasid);
memset(, 0, sizeof(info));
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index f8fa03a..591ac28 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -39,6 +39,7 @@
#include "kfd_device_queue_manager.h"
#include "kfd_dbgmgr.h"
#include "amdgpu_amdkfd.h"
+#include "kfd_smi_events.h"
static long kfd_ioctl(struct file *, unsigned int, unsigned long);
static int kfd_open(struct inode *, struct file *);
@@ -1243,6 +1244,32 @@ static int kfd_ioctl_acquire_vm(struct file *filep,
struct kfd_process *p,
return ret;
}
+/* Handle requests for watching SMI events */
+static int kfd_ioctl_smi_events(struct file *filep,
+ struct kfd_process *p, void *data)
+{
+ struct kfd_ioctl_smi_events_args *args = data;
+ struct kfd_dev *dev;
+
+ dev = kfd_device_by_id(args->gpu_id);
+ if (!dev)
+ return -EINVAL;
+
+ switch (args->op) {
+ case KFD_SMI_EVENTS_REGISTER:
+ /* register the device */
+ return kfd_smi_event_register(dev, >data);
+ case KFD_SMI_EVENTS_ENABLE:
+ /* subscribe events to the device */
+ return kfd_smi_event_enable(dev, args->events);
+ case KFD_SMI_EVENTS_DISABLE:
+ /* unsubscribe events */
+ return kfd_smi_event_disable(dev, args->events);
+ }
+
+ return -EINVAL;
+}
+
bool kfd_dev_is_large_bar(struct kfd_dev *dev)
{
struct kfd_local_mem_info mem_info;
@@ -1827,6 +1854,9 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
AMDKFD_IOCTL_DEF(AMDKFD_IOC_ALLOC_QUEUE_GWS,
kfd_ioctl_alloc_queue_gws, 0),
+
+ AMDKFD_IOCTL_DEF(AMDKFD_IOC_SMI_EVENTS,
+ kfd_ioctl_smi_events, 0),
};
#define AMDKFD_CORE_IOCTL_COUNTARRAY_SIZE(amdkfd_ioctls)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 0491ab2..6ac6f31 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++
Re: [PATCH] device_cgroup: Cleanup cgroup eBPF device filter code
On 4/4/20 12:37 AM, Roman Gushchin wrote:
On Fri, Apr 03, 2020 at 07:55:28PM +0200, Odin Ugedal wrote:
Original cgroup v2 eBPF code for filtering device access made it
possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF
filtering. Change
commit 4b7d4d453fc4 ("device_cgroup: Export devcgroup_check_permission")
reverted this, making it required to set it to y.
Since the device filtering (and all the docs) for cgroup v2 is no longer
a "device controller" like it was in v1, someone might compile their
kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF
filter will not be invoked, and all processes will be allowed access
to all devices, no matter what the eBPF filter says.
Signed-off-by: Odin Ugedal
The patch makes perfect sense to me.
Acked-by: Roman Gushchin
Tejun, I presume you'll pick this up (given the files this fix touches)?
Thanks,
Daniel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] PCI/P2PDMA: Add additional AMD ZEN root ports to the whitelist
According to the hw architect, pre-ZEN parts support
p2p writes and ZEN parts support both p2p reads and writes.
Add entries for Zen parts Raven (0x15d0) and Renoir (0x1630).
Cc: Christian König
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/pci/p2pdma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 9a8a38384121..91a4c987399d 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -282,6 +282,8 @@ static const struct pci_p2pdma_whitelist_entry {
} pci_p2pdma_whitelist[] = {
/* AMD ZEN */
{PCI_VENDOR_ID_AMD, 0x1450, 0},
+ {PCI_VENDOR_ID_AMD, 0x15d0, 0},
+ {PCI_VENDOR_ID_AMD, 0x1630, 0},
/* Intel Xeon E5/Core i7 */
{PCI_VENDOR_ID_INTEL, 0x3c00, REQ_SAME_HOST_BRIDGE},
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Print UTCL2 client ID on a gpuvm fault
Am 06.04.20 um 20:46 schrieb Alex Deucher: On Mon, Apr 6, 2020 at 1:42 PM Oak Zeng wrote: UTCL2 client ID is useful information to get which UTCL2 client caused the gpuvm fault. Print it out for debug purpose Change-Id: I733d0127b0ee53aa788f194cefa53cbb55b49c11 Signed-off-by: Oak Zeng Reviewed-by: Alex Deucher Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 +++ drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c index 78d769e..94a6096 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c @@ -170,6 +170,9 @@ static int gmc_v10_0_process_interrupt(struct amdgpu_device *adev, dev_err(adev->dev, "GCVM_L2_PROTECTION_FAULT_STATUS:0x%08X\n", status); + dev_err(adev->dev, "\t Faulty UTCL2 client ID: 0x%lx\n", + REG_GET_FIELD(status, + GCVM_L2_PROTECTION_FAULT_STATUS, CID)); dev_err(adev->dev, "\t MORE_FAULTS: 0x%lx\n", REG_GET_FIELD(status, GCVM_L2_PROTECTION_FAULT_STATUS, MORE_FAULTS)); diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c index 8606f87..fecdbc4 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c @@ -362,6 +362,9 @@ static int gmc_v9_0_process_interrupt(struct amdgpu_device *adev, dev_err(adev->dev, "VM_L2_PROTECTION_FAULT_STATUS:0x%08X\n", status); + dev_err(adev->dev, "\t Faulty UTCL2 client ID: 0x%lx\n", + REG_GET_FIELD(status, + VM_L2_PROTECTION_FAULT_STATUS, CID)); dev_err(adev->dev, "\t MORE_FAULTS: 0x%lx\n", REG_GET_FIELD(status, VM_L2_PROTECTION_FAULT_STATUS, MORE_FAULTS)); -- 2.7.4 ___ 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 1/2] drm/amd/display: query hdcp capability during link detect
Both patches look good to me.
The series is Reviewed-by: Mikita Lipski
Thanks,
Mikita
On 2020-04-01 5:00 p.m., Bhawanpreet Lakha wrote:
[Why]
Query the hdcp caps of a link, it is useful and can be reported to the user
[How]
Create a query function and call it during link detect
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 56
drivers/gpu/drm/amd/display/dc/dc.h | 41 +
drivers/gpu/drm/amd/display/dc/dc_link.h | 3 +
.../gpu/drm/amd/display/dc/hdcp/hdcp_msg.c| 89 +++
.../gpu/drm/amd/display/include/hdcp_types.h | 7 ++
5 files changed, 196 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index a93997ff0419..49c63e27dfe9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -514,6 +514,50 @@ static void link_disconnect_remap(struct dc_sink
*prev_sink, struct dc_link *lin
link->local_sink = prev_sink;
}
+#if defined(CONFIG_DRM_AMD_DC_HDCP)
+static void query_hdcp_capability(enum signal_type signal, struct dc_link
*link)
+{
+ struct hdcp_protection_message msg22;
+ struct hdcp_protection_message msg14;
+
+ memset(, 0, sizeof(struct hdcp_protection_message));
+ memset(, 0, sizeof(struct hdcp_protection_message));
+ memset(link->hdcp_caps.rx_caps.raw, 0,
+ sizeof(link->hdcp_caps.rx_caps.raw));
+
+ if ((link->connector_signal == SIGNAL_TYPE_DISPLAY_PORT &&
+ link->ddc->transaction_type ==
+ DDC_TRANSACTION_TYPE_I2C_OVER_AUX) ||
+ link->connector_signal == SIGNAL_TYPE_EDP) {
+ msg22.data = link->hdcp_caps.rx_caps.raw;
+ msg22.length = sizeof(link->hdcp_caps.rx_caps.raw);
+ msg22.msg_id = HDCP_MESSAGE_ID_RX_CAPS;
+ } else {
+ msg22.data = >hdcp_caps.rx_caps.fields.version;
+ msg22.length = sizeof(link->hdcp_caps.rx_caps.fields.version);
+ msg22.msg_id = HDCP_MESSAGE_ID_HDCP2VERSION;
+ }
+ msg22.version = HDCP_VERSION_22;
+ msg22.link = HDCP_LINK_PRIMARY;
+ msg22.max_retries = 5;
+ dc_process_hdcp_msg(signal, link, );
+
+ if (signal == SIGNAL_TYPE_DISPLAY_PORT || signal ==
SIGNAL_TYPE_DISPLAY_PORT_MST) {
+ enum hdcp_message_status status = HDCP_MESSAGE_UNSUPPORTED;
+
+ msg14.data = >hdcp_caps.bcaps.raw;
+ msg14.length = sizeof(link->hdcp_caps.bcaps.raw);
+ msg14.msg_id = HDCP_MESSAGE_ID_READ_BCAPS;
+ msg14.version = HDCP_VERSION_14;
+ msg14.link = HDCP_LINK_PRIMARY;
+ msg14.max_retries = 5;
+
+ status = dc_process_hdcp_msg(signal, link, );
+ }
+
+}
+#endif
+
static void read_current_link_settings_on_detect(struct dc_link *link)
{
union lane_count_set lane_count_set = { {0} };
@@ -606,6 +650,12 @@ static bool detect_dp(struct dc_link *link,
dal_ddc_service_set_transaction_type(link->ddc,
sink_caps->transaction_type);
+#if defined(CONFIG_DRM_AMD_DC_HDCP)
+ /* In case of fallback to SST when topology discovery
below fails
+* HDCP caps will be querried again later by the upper
layer (caller
+* of this function). */
+ query_hdcp_capability(SIGNAL_TYPE_DISPLAY_PORT_MST,
link);
+#endif
/*
* This call will initiate MST topology discovery. Which
* will detect MST ports and add new DRM connector DRM
@@ -975,6 +1025,9 @@ static bool dc_link_detect_helper(struct dc_link *link,
* TODO debug why Dell 2413 doesn't like
* two link trainings
*/
+#if defined(CONFIG_DRM_AMD_DC_HDCP)
+ query_hdcp_capability(sink->sink_signal, link);
+#endif
// verify link cap for SST non-seamless boot
if (!perform_dp_seamless_boot)
@@ -988,6 +1041,9 @@ static bool dc_link_detect_helper(struct dc_link *link,
sink = prev_sink;
prev_sink = NULL;
}
+#if defined(CONFIG_DRM_AMD_DC_HDCP)
+ query_hdcp_capability(sink->sink_signal, link);
+#endif
}
/* HDMI-DVI Dongle */
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 92123b0d1196..9235d04c32dc 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -29,6 +29,9 @@
#include "dc_types.h"
#include "grph_object_defs.h"
#include "logger_types.h"
+#if defined(CONFIG_DRM_AMD_DC_HDCP)
Re: [PATCH 30/36] drm/amd/display: Avoid create MST prop after registration
On Mon, Apr 6, 2020 at 2:52 PM Rodrigo Siqueira wrote: > > Ok, I'll just push the patch to our repository. Sounds good. Please note the other issue Michel mentioned below. We need a fix for that as well for 5.7. Thanks, Alex > > Thanks > > On 04/06, Alex Deucher wrote: > > On Mon, Apr 6, 2020 at 2:44 PM Rodrigo Siqueira > > wrote: > > > > > > Hi Michel, > > > > > > I'm going to apply the patchset by the end of the day at AMD repository. > > > Is that ok for you? Or do you need this patch on drm-misc-next? > > > > I can cherry-pick the changes over to 5.7 fixes once we've addressed > > all the issues. > > > > Alex > > > > > > > > Best Regards > > > > > > On 04/06, Michel Dänzer wrote: > > > > On 2020-04-05 10:41 p.m., Rodrigo Siqueira wrote: > > > > > From: "Jerry (Fangzhi) Zuo" > > > > > > > > > > [Why] > > > > > Prop are created at boot stage, and not allowed to create new prop > > > > > after device registration. > > > > > > > > > > [How] > > > > > Reuse the connector property from SST if exist. > > > > > > > > > > Signed-off-by: Jerry (Fangzhi) Zuo > > > > > Reviewed-by: Hersen Wu > > > > > Acked-by: Rodrigo Siqueira > > > > This patch is needed in 5.7, or one gets the WARNINGs I reported in > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Famd-gfx%2F2020-April%2F048017.htmldata=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540368991sdata=%2FGtnTlXrRSzZM7M4KApZO1FFVCJjuJ8cur74s2ZNz0E%3Dreserved=0 > > > > when an MST display is connected. > > > > > > > > Note that this patch doesn't fix all of those, there's also one > > > > triggered by dm_dp_add_mst_connector => drm_encoder_init. > > > > > > > > git grep mst_encoders drivers/gpu/drm/i915/ > > > > > > > > shows how the i915 driver deals with this. > > > > > > > > Can you guys take care of that for 5.7 as well? > > > > > > > > > > > > -- > > > > Earthling Michel Dänzer | > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2Fdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540373986sdata=ckUT0WFeLWopbqY6SG%2Bg69i%2F3O6cTkSTWqBAyFHg3iw%3Dreserved=0 > > > > Libre software enthusiast | Mesa and X developer > > > > > > -- > > > Rodrigo Siqueira > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsiqueira.tech%2Fdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540373986sdata=%2BkwwR38PUel4j21WGo%2FxPMoXS%2BLnEQ4ax1yGxI%2F5xHc%3Dreserved=0 > > > ___ > > > 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=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540373986sdata=VlEy9R5us1VevQmtUJjen%2FrVoi0F8bjIAh%2FwffiCP2k%3Dreserved=0 > > -- > Rodrigo Siqueira > https://siqueira.tech ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 30/36] drm/amd/display: Avoid create MST prop after registration
Ok, I'll just push the patch to our repository. Thanks On 04/06, Alex Deucher wrote: > On Mon, Apr 6, 2020 at 2:44 PM Rodrigo Siqueira > wrote: > > > > Hi Michel, > > > > I'm going to apply the patchset by the end of the day at AMD repository. > > Is that ok for you? Or do you need this patch on drm-misc-next? > > I can cherry-pick the changes over to 5.7 fixes once we've addressed > all the issues. > > Alex > > > > > Best Regards > > > > On 04/06, Michel Dänzer wrote: > > > On 2020-04-05 10:41 p.m., Rodrigo Siqueira wrote: > > > > From: "Jerry (Fangzhi) Zuo" > > > > > > > > [Why] > > > > Prop are created at boot stage, and not allowed to create new prop > > > > after device registration. > > > > > > > > [How] > > > > Reuse the connector property from SST if exist. > > > > > > > > Signed-off-by: Jerry (Fangzhi) Zuo > > > > Reviewed-by: Hersen Wu > > > > Acked-by: Rodrigo Siqueira > > > This patch is needed in 5.7, or one gets the WARNINGs I reported in > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Famd-gfx%2F2020-April%2F048017.htmldata=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540368991sdata=%2FGtnTlXrRSzZM7M4KApZO1FFVCJjuJ8cur74s2ZNz0E%3Dreserved=0 > > > when an MST display is connected. > > > > > > Note that this patch doesn't fix all of those, there's also one > > > triggered by dm_dp_add_mst_connector => drm_encoder_init. > > > > > > git grep mst_encoders drivers/gpu/drm/i915/ > > > > > > shows how the i915 driver deals with this. > > > > > > Can you guys take care of that for 5.7 as well? > > > > > > > > > -- > > > Earthling Michel Dänzer | > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2Fdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540373986sdata=ckUT0WFeLWopbqY6SG%2Bg69i%2F3O6cTkSTWqBAyFHg3iw%3Dreserved=0 > > > Libre software enthusiast | Mesa and X developer > > > > -- > > Rodrigo Siqueira > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsiqueira.tech%2Fdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540373986sdata=%2BkwwR38PUel4j21WGo%2FxPMoXS%2BLnEQ4ax1yGxI%2F5xHc%3Dreserved=0 > > ___ > > 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=02%7C01%7CRodrigo.Siqueira%40amd.com%7Cc277a51490f94ed99a2508d7da5af6f0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217956540373986sdata=VlEy9R5us1VevQmtUJjen%2FrVoi0F8bjIAh%2FwffiCP2k%3Dreserved=0 -- Rodrigo Siqueira https://siqueira.tech signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 30/36] drm/amd/display: Avoid create MST prop after registration
On Mon, Apr 6, 2020 at 2:44 PM Rodrigo Siqueira wrote: > > Hi Michel, > > I'm going to apply the patchset by the end of the day at AMD repository. > Is that ok for you? Or do you need this patch on drm-misc-next? I can cherry-pick the changes over to 5.7 fixes once we've addressed all the issues. Alex > > Best Regards > > On 04/06, Michel Dänzer wrote: > > On 2020-04-05 10:41 p.m., Rodrigo Siqueira wrote: > > > From: "Jerry (Fangzhi) Zuo" > > > > > > [Why] > > > Prop are created at boot stage, and not allowed to create new prop > > > after device registration. > > > > > > [How] > > > Reuse the connector property from SST if exist. > > > > > > Signed-off-by: Jerry (Fangzhi) Zuo > > > Reviewed-by: Hersen Wu > > > Acked-by: Rodrigo Siqueira > > This patch is needed in 5.7, or one gets the WARNINGs I reported in > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Famd-gfx%2F2020-April%2F048017.htmldata=02%7C01%7CRodrigo.Siqueira%40amd.com%7C82562d6efc6a4c85afd108d7da3c7490%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217825519023312sdata=h7ZVldKMgP%2FWkMVpjn%2BX6fytKoNZi24lFjOdS3QMUts%3Dreserved=0 > > when an MST display is connected. > > > > Note that this patch doesn't fix all of those, there's also one > > triggered by dm_dp_add_mst_connector => drm_encoder_init. > > > > git grep mst_encoders drivers/gpu/drm/i915/ > > > > shows how the i915 driver deals with this. > > > > Can you guys take care of that for 5.7 as well? > > > > > > -- > > Earthling Michel Dänzer | > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2Fdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7C82562d6efc6a4c85afd108d7da3c7490%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217825519028304sdata=h9fm4x4B3Kn1U4bloZbLeZTbjygZCHIgoyroaEW9%2B3s%3Dreserved=0 > > Libre software enthusiast | Mesa and X developer > > -- > Rodrigo Siqueira > https://siqueira.tech > ___ > 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: Print UTCL2 client ID on a gpuvm fault
On Mon, Apr 6, 2020 at 1:42 PM Oak Zeng wrote: > > UTCL2 client ID is useful information to get which > UTCL2 client caused the gpuvm fault. Print it out > for debug purpose > > Change-Id: I733d0127b0ee53aa788f194cefa53cbb55b49c11 > Signed-off-by: Oak Zeng Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 +++ > drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c > b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c > index 78d769e..94a6096 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c > @@ -170,6 +170,9 @@ static int gmc_v10_0_process_interrupt(struct > amdgpu_device *adev, > dev_err(adev->dev, > "GCVM_L2_PROTECTION_FAULT_STATUS:0x%08X\n", > status); > + dev_err(adev->dev, "\t Faulty UTCL2 client ID: > 0x%lx\n", > + REG_GET_FIELD(status, > + GCVM_L2_PROTECTION_FAULT_STATUS, CID)); > dev_err(adev->dev, "\t MORE_FAULTS: 0x%lx\n", > REG_GET_FIELD(status, > GCVM_L2_PROTECTION_FAULT_STATUS, > MORE_FAULTS)); > diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c > b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c > index 8606f87..fecdbc4 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c > @@ -362,6 +362,9 @@ static int gmc_v9_0_process_interrupt(struct > amdgpu_device *adev, > dev_err(adev->dev, > "VM_L2_PROTECTION_FAULT_STATUS:0x%08X\n", > status); > + dev_err(adev->dev, "\t Faulty UTCL2 client ID: > 0x%lx\n", > + REG_GET_FIELD(status, > + VM_L2_PROTECTION_FAULT_STATUS, CID)); > dev_err(adev->dev, "\t MORE_FAULTS: 0x%lx\n", > REG_GET_FIELD(status, > VM_L2_PROTECTION_FAULT_STATUS, MORE_FAULTS)); > -- > 2.7.4 > > ___ > 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 30/36] drm/amd/display: Avoid create MST prop after registration
Hi Michel, I'm going to apply the patchset by the end of the day at AMD repository. Is that ok for you? Or do you need this patch on drm-misc-next? Best Regards On 04/06, Michel Dänzer wrote: > On 2020-04-05 10:41 p.m., Rodrigo Siqueira wrote: > > From: "Jerry (Fangzhi) Zuo" > > > > [Why] > > Prop are created at boot stage, and not allowed to create new prop > > after device registration. > > > > [How] > > Reuse the connector property from SST if exist. > > > > Signed-off-by: Jerry (Fangzhi) Zuo > > Reviewed-by: Hersen Wu > > Acked-by: Rodrigo Siqueira > This patch is needed in 5.7, or one gets the WARNINGs I reported in > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Famd-gfx%2F2020-April%2F048017.htmldata=02%7C01%7CRodrigo.Siqueira%40amd.com%7C82562d6efc6a4c85afd108d7da3c7490%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217825519023312sdata=h7ZVldKMgP%2FWkMVpjn%2BX6fytKoNZi24lFjOdS3QMUts%3Dreserved=0 > when an MST display is connected. > > Note that this patch doesn't fix all of those, there's also one > triggered by dm_dp_add_mst_connector => drm_encoder_init. > > git grep mst_encoders drivers/gpu/drm/i915/ > > shows how the i915 driver deals with this. > > Can you guys take care of that for 5.7 as well? > > > -- > Earthling Michel Dänzer | > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com%2Fdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7C82562d6efc6a4c85afd108d7da3c7490%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217825519028304sdata=h9fm4x4B3Kn1U4bloZbLeZTbjygZCHIgoyroaEW9%2B3s%3Dreserved=0 > Libre software enthusiast | Mesa and X developer -- Rodrigo Siqueira https://siqueira.tech signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote: > > On 2020-04-06 6:34 p.m., Rob Clark wrote: > > > > The ideal thing would be to be able to click any jobs that we want to > > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > > to automatically trigger dependencies of that job (meson-arm64, and > > arm_build+arm_test). But not sure if that is a thing gitlab can do. > > Not that I know of. The dependency handling is still pretty rudimentary > in general. > > > > Triggering just the first container jobs and having everything from > > there run automatically would be ok if the current rules to filter out > > unneeded jobs still apply, ie. a panfrost change isn't triggering > > freedreno CI jobs and visa versa. But tbh I don't understand enough > > of what that MR is doing to understand if that is what it does. (It > > was suggested on IRC that this is probably what it does.) > > It is. Filtered jobs don't exist at all in the pipeline, so they can't > be triggered by any means. :) > ahh, ok, I didn't realize that.. thx for the explaination BR, -R ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: Print UTCL2 client ID on a gpuvm fault
UTCL2 client ID is useful information to get which UTCL2 client caused the gpuvm fault. Print it out for debug purpose Change-Id: I733d0127b0ee53aa788f194cefa53cbb55b49c11 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 +++ drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c index 78d769e..94a6096 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c @@ -170,6 +170,9 @@ static int gmc_v10_0_process_interrupt(struct amdgpu_device *adev, dev_err(adev->dev, "GCVM_L2_PROTECTION_FAULT_STATUS:0x%08X\n", status); + dev_err(adev->dev, "\t Faulty UTCL2 client ID: 0x%lx\n", + REG_GET_FIELD(status, + GCVM_L2_PROTECTION_FAULT_STATUS, CID)); dev_err(adev->dev, "\t MORE_FAULTS: 0x%lx\n", REG_GET_FIELD(status, GCVM_L2_PROTECTION_FAULT_STATUS, MORE_FAULTS)); diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c index 8606f87..fecdbc4 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c @@ -362,6 +362,9 @@ static int gmc_v9_0_process_interrupt(struct amdgpu_device *adev, dev_err(adev->dev, "VM_L2_PROTECTION_FAULT_STATUS:0x%08X\n", status); + dev_err(adev->dev, "\t Faulty UTCL2 client ID: 0x%lx\n", + REG_GET_FIELD(status, + VM_L2_PROTECTION_FAULT_STATUS, CID)); dev_err(adev->dev, "\t MORE_FAULTS: 0x%lx\n", REG_GET_FIELD(status, VM_L2_PROTECTION_FAULT_STATUS, MORE_FAULTS)); -- 2.7.4 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: gitlab.fd.o financial situation and impact on services
On 2020-04-06 6:34 p.m., Rob Clark wrote: > > The ideal thing would be to be able to click any jobs that we want to > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > to automatically trigger dependencies of that job (meson-arm64, and > arm_build+arm_test). But not sure if that is a thing gitlab can do. Not that I know of. The dependency handling is still pretty rudimentary in general. > Triggering just the first container jobs and having everything from > there run automatically would be ok if the current rules to filter out > unneeded jobs still apply, ie. a panfrost change isn't triggering > freedreno CI jobs and visa versa. But tbh I don't understand enough > of what that MR is doing to understand if that is what it does. (It > was suggested on IRC that this is probably what it does.) It is. Filtered jobs don't exist at all in the pipeline, so they can't be triggered by any means. :) -- 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: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote: > > On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > strictly > > > > pre-merge CI. > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > click first the container jobs.. then wait.. then the build jobs.. > > then wait some more.. and then finally the actual runners. That would > > be a real step back in terms of usefulness of CI.. one might call it a > > regression :-( > > I think that's mostly a complaint about the conditionals we've written > so far, tbh. As I commented on the bug, when I clicked the container > job (which the rules happen to have evaluated to being "manual"), every > job (recursively) downstream of it got enqueued, which isn't what > you're describing. So I think if you can describe the UX you'd like we > can write rules to make that reality. Ok, I was fearing that we'd have to manually trigger each stage of dependencies in the pipeline. Which wouldn't be so bad except that gitlab makes you wait for the previous stage to complete before triggering the next one. The ideal thing would be to be able to click any jobs that we want to run, say "arm64_a630_gles31", and for gitlab to realize that it needs to automatically trigger dependencies of that job (meson-arm64, and arm_build+arm_test). But not sure if that is a thing gitlab can do. Triggering just the first container jobs and having everything from there run automatically would be ok if the current rules to filter out unneeded jobs still apply, ie. a panfrost change isn't triggering freedreno CI jobs and visa versa. But tbh I don't understand enough of what that MR is doing to understand if that is what it does. (It was suggested on IRC that this is probably what it does.) BR, -R ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH net-next] drm/amd/display: Fix link_detect_sink()
On 2020-04-06 5:19 a.m., Dan Carpenter wrote:
This TODO stub originally had curly braces but we deleted them as part
of a clean up. Unfortunately that changes the behavior of the code
because now the switch statement is part of the if statement. Smatch
complains that the indenting doesn't make sense.
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:425
link_detect_sink() warn: if statement not indented
Also I changed "ZAZTODO" to just "TODO". The ZAZ isn't used anywhere
else.
Fixes: 621514aa4140 ("drm/amd/display: codestyle cleanup on dc_link file until
detect_dp func")
Signed-off-by: Dan Carpenter
I'd prefer just dropping the block, but either method is:
Reviewed-by: Nicholas Kazlauskas
Since that previous patch broke most sink detection...
Regards,
Nicholas Kazlauskas
---
Another idea is we should just delete this stub. Stub code is generally
against kernel style. I can send a V2 if people want.
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index a93997ff0419..188670d374a3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -423,7 +423,7 @@ static enum signal_type link_detect_sink(struct dc_link
*link,
/* PCIE detects the actual connector on add-on board */
if (link->link_id.id == CONNECTOR_ID_PCIE)
- /* ZAZTODO implement PCIE add-on card detection */
+ ; /* TODO implement PCIE add-on card detection */
switch (link->link_id.id) {
case CONNECTOR_ID_HDMI_TYPE_A: {
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/6] kernel: move use_mm/unuse_mm to kthread.c
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig: > These helpers are only for use with kernel threads, and I will tie them > more into the kthread infrastructure going forward. Also move the > prototypes to kthread.h - mmu_context.h was a little weird to start with > as it otherwise contains very low-level MM bits. > > Signed-off-by: Christoph Hellwig Acked-by: Felix Kuehling Thanks for cleaning up the unnecessary includes in amdgpu. Regards, Felix > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 + > .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 1 - > .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 1 - > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 - > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 2 - > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 2 - > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- > drivers/usb/gadget/function/f_fs.c| 2 +- > drivers/usb/gadget/legacy/inode.c | 2 +- > drivers/vhost/vhost.c | 1 - > fs/aio.c | 1 - > fs/io-wq.c| 1 - > fs/io_uring.c | 1 - > include/linux/kthread.h | 5 ++ > include/linux/mmu_context.h | 5 -- > kernel/kthread.c | 56 > mm/Makefile | 2 +- > mm/mmu_context.c | 64 --- > 18 files changed, 66 insertions(+), 85 deletions(-) > delete mode 100644 mm/mmu_context.c > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > index 4db143c19dcc..bce5e93fefc8 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > @@ -27,6 +27,7 @@ > > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > index 6529caca88fe..35d4a5ab0228 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > @@ -22,7 +22,6 @@ > #include > #include > #include > -#include > #include > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > index 4ec6d0c03201..b1655054b919 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > @@ -19,7 +19,6 @@ > * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > * OTHER DEALINGS IN THE SOFTWARE. > */ > -#include > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "gc/gc_10_1_0_offset.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > index 0b7e78748540..7d01420c0c85 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > @@ -20,8 +20,6 @@ > * OTHER DEALINGS IN THE SOFTWARE. > */ > > -#include > - > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "cikd.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > index ccd635b812b5..635cd1a26bed 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > @@ -20,8 +20,6 @@ > * OTHER DEALINGS IN THE SOFTWARE. > */ > > -#include > - > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "gfx_v8_0.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > index df841c2ac5e7..c7fd0c47b254 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > @@ -19,8 +19,6 @@ > * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > * OTHER DEALINGS IN THE SOFTWARE. > */ > -#include > - > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "gc/gc_9_0_offset.h" > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c > b/drivers/gpu/drm/i915/gvt/kvmgt.c > index 5848400620b4..dee01c371bf5 100644 > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c > @@ -31,7 +31,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > diff --git a/drivers/usb/gadget/function/f_fs.c > b/drivers/usb/gadget/function/f_fs.c > index c81023b195c3..c57b1b2507c6 100644 > --- a/drivers/usb/gadget/function/f_fs.c > +++ b/drivers/usb/gadget/function/f_fs.c > @@ -32,7 +32,7 @@ > #include > > #include > -#include > +#include > #include > #include > > diff --git
Re: [PATCH 5/6] kernel: better document the use_mm/unuse_mm API contract
Am 2020-04-04 um 5:41 a.m. schrieb Christoph Hellwig:
> Switch the function documentation to kerneldoc comments, and add
> WARN_ON_ONCE asserts that the calling thread is a kernel thread and
> does not have ->mm set (or has ->mm set in the case of unuse_mm).
>
> Also give the functions a kthread_ prefix to better document the
> use case.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +--
> drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +--
> drivers/usb/gadget/function/f_fs.c | 4 +--
> drivers/usb/gadget/legacy/inode.c | 4 +--
> drivers/vhost/vhost.c | 4 +--
> fs/io-wq.c | 6 ++--
> fs/io_uring.c | 6 ++--
> include/linux/kthread.h| 4 +--
> kernel/kthread.c | 33 +++---
> mm/oom_kill.c | 6 ++--
> mm/vmacache.c | 4 +--
> 11 files changed, 39 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index bce5e93fefc8..63db84e09408 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -192,9 +192,9 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev
> *dst, struct kgd_dev *s
> if ((mmptr) == current->mm) { \
> valid = !get_user((dst), (wptr)); \
> } else if (current->flags & PF_KTHREAD) { \
> - use_mm(mmptr); \
> + kthread_use_mm(mmptr); \
> valid = !get_user((dst), (wptr)); \
> - unuse_mm(mmptr);\
> + kthread_unuse_mm(mmptr);\
> } \
> pagefault_enable(); \
> } \
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index dee01c371bf5..92e9b340dbc2 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -2048,7 +2048,7 @@ static int kvmgt_rw_gpa(unsigned long handle, unsigned
> long gpa,
> if (kthread) {
> if (!mmget_not_zero(kvm->mm))
> return -EFAULT;
> - use_mm(kvm->mm);
> + kthread_use_mm(kvm->mm);
> }
>
> idx = srcu_read_lock(>srcu);
> @@ -2057,7 +2057,7 @@ static int kvmgt_rw_gpa(unsigned long handle, unsigned
> long gpa,
> srcu_read_unlock(>srcu, idx);
>
> if (kthread) {
> - unuse_mm(kvm->mm);
> + kthread_unuse_mm(kvm->mm);
> mmput(kvm->mm);
> }
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index c57b1b2507c6..d9e48bd7c692 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -827,9 +827,9 @@ static void ffs_user_copy_worker(struct work_struct *work)
> mm_segment_t oldfs = get_fs();
>
> set_fs(USER_DS);
> - use_mm(io_data->mm);
> + kthread_use_mm(io_data->mm);
> ret = ffs_copy_to_iter(io_data->buf, ret, _data->data);
> - unuse_mm(io_data->mm);
> + kthread_unuse_mm(io_data->mm);
> set_fs(oldfs);
> }
>
> diff --git a/drivers/usb/gadget/legacy/inode.c
> b/drivers/usb/gadget/legacy/inode.c
> index 8b5233888bf8..a05552bc2ff8 100644
> --- a/drivers/usb/gadget/legacy/inode.c
> +++ b/drivers/usb/gadget/legacy/inode.c
> @@ -462,9 +462,9 @@ static void ep_user_copy_worker(struct work_struct *work)
> struct kiocb *iocb = priv->iocb;
> size_t ret;
>
> - use_mm(mm);
> + kthread_use_mm(mm);
> ret = copy_to_iter(priv->buf, priv->actual, >to);
> - unuse_mm(mm);
> + kthread_unuse_mm(mm);
> if (!ret)
> ret = -EFAULT;
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 4e9ce54869af..1787d426a956 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -336,7 +336,7 @@ static int vhost_worker(void *data)
> mm_segment_t oldfs = get_fs();
>
> set_fs(USER_DS);
> - use_mm(dev->mm);
> + kthread_use_mm(dev->mm);
>
> for (;;) {
> /* mb paired w/ kthread_stop */
> @@ -364,7 +364,7 @@ static int vhost_worker(void *data)
> schedule();
> }
> }
> - unuse_mm(dev->mm);
> + kthread_unuse_mm(dev->mm);
> set_fs(oldfs);
> return 0;
> }
> diff --git
Re: [PATCH 1/6] amdgpu: a NULL ->mm does not mean a thread is a kthread
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig:
> Use the proper API instead.
>
> Fixes: 70539bd795002 ("drm/amd: Update MEC HQD loading code for KFD")
> Signed-off-by: Christoph Hellwig
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index 13feb313e9b3..4db143c19dcc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -190,7 +190,7 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev
> *dst, struct kgd_dev *s
> pagefault_disable();\
> if ((mmptr) == current->mm) { \
> valid = !get_user((dst), (wptr)); \
> - } else if (current->mm == NULL) { \
> + } else if (current->flags & PF_KTHREAD) { \
> use_mm(mmptr); \
> valid = !get_user((dst), (wptr)); \
> unuse_mm(mmptr);\
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: Re-enable FRU check for most models v4
[AMD Official Use Only - Internal Distribution Only]
Ignore this one, needed to update the commit
Kent
> -Original Message-
> From: Russell, Kent
> Sent: Monday, April 6, 2020 11:51 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Russell, Kent
> Subject: [PATCH] drm/amdgpu: Re-enable FRU check for most models v4
>
> There is 1 VG20 DID that does not have the FRU on there, and trying to read
> that will cause a hang. For now, check for the gaming DID until a proper fix
> can
> be implemented. This re-enables serial number reporting for server cards
>
> v2: Add ASIC check
> v3: Don't default to true for pre-VG20
> v4: Use DID instead of parsing the VBIOS
>
> Signed-off-by: Kent Russell
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> index bfe4259f9508..9d17761721de 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
> @@ -20,6 +20,8 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> *
> */
> +#include
> +
> #include "amdgpu.h"
> #include "amdgpu_i2c.h"
> #include "smu_v11_0_i2c.h"
> @@ -31,8 +33,16 @@
>
> bool is_fru_eeprom_supported(struct amdgpu_device *adev) {
> - /* TODO: Resolve supported ASIC type */
> -
> + /* TODO: Gaming SKUs don't have the FRU EEPROM.
> + * Use this hack to address hangs on modprobe on gaming SKUs
> + * until a proper solution can be implemented by only supporting
> + * it on Arcturus, and the explicit chip IDs for VG20 Server cards
> + */
> + if ((adev->asic_type == CHIP_ARCTURUS) ||
> + (adev->asic_type == CHIP_VEGA20 && adev->pdev->device ==
> 0x66a0) ||
> + (adev->asic_type == CHIP_VEGA20 && adev->pdev->device ==
> 0x66a1) ||
> + (adev->asic_type == CHIP_VEGA20 && adev->pdev->device ==
> 0x66a4))
> + return true;
> return false;
> }
>
> --
> 2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: Re-enable FRU check for most models v4
There is at least 1 VG20 DID that does not have an FRU, and trying to read
that will cause a hang. For now, explicitly support reading the FRU for
Arcturus and for the WKS VG20 DIDs, and skip for everything else.
This re-enables serial number reporting for server cards
v2: Add ASIC check
v3: Don't default to true for pre-VG20
v4: Use DID instead of parsing the VBIOS
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..9d17761721de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -20,6 +20,8 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
+#include
+
#include "amdgpu.h"
#include "amdgpu_i2c.h"
#include "smu_v11_0_i2c.h"
@@ -31,8 +33,16 @@
bool is_fru_eeprom_supported(struct amdgpu_device *adev)
{
- /* TODO: Resolve supported ASIC type */
-
+ /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this hack to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented by only supporting
+* it on Arcturus, and the explicit chip IDs for VG20 Server cards
+*/
+ if ((adev->asic_type == CHIP_ARCTURUS) ||
+ (adev->asic_type == CHIP_VEGA20 && adev->pdev->device == 0x66a0) ||
+ (adev->asic_type == CHIP_VEGA20 && adev->pdev->device == 0x66a1) ||
+ (adev->asic_type == CHIP_VEGA20 && adev->pdev->device == 0x66a4))
+ return true;
return false;
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: Re-enable FRU check for most models v4
There is 1 VG20 DID that does not have the FRU on there, and trying to read
that will cause a hang. For now, check for the gaming DID until a proper
fix can be implemented. This re-enables serial number reporting for
server cards
v2: Add ASIC check
v3: Don't default to true for pre-VG20
v4: Use DID instead of parsing the VBIOS
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
index bfe4259f9508..9d17761721de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
@@ -20,6 +20,8 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
+#include
+
#include "amdgpu.h"
#include "amdgpu_i2c.h"
#include "smu_v11_0_i2c.h"
@@ -31,8 +33,16 @@
bool is_fru_eeprom_supported(struct amdgpu_device *adev)
{
- /* TODO: Resolve supported ASIC type */
-
+ /* TODO: Gaming SKUs don't have the FRU EEPROM.
+* Use this hack to address hangs on modprobe on gaming SKUs
+* until a proper solution can be implemented by only supporting
+* it on Arcturus, and the explicit chip IDs for VG20 Server cards
+*/
+ if ((adev->asic_type == CHIP_ARCTURUS) ||
+ (adev->asic_type == CHIP_VEGA20 && adev->pdev->device == 0x66a0) ||
+ (adev->asic_type == CHIP_VEGA20 && adev->pdev->device == 0x66a1) ||
+ (adev->asic_type == CHIP_VEGA20 && adev->pdev->device == 0x66a4))
+ return true;
return false;
}
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I think that's mostly a complaint about the conditionals we've written so far, tbh. As I commented on the bug, when I clicked the container job (which the rules happen to have evaluated to being "manual"), every job (recursively) downstream of it got enqueued, which isn't what you're describing. So I think if you can describe the UX you'd like we can write rules to make that reality. But I don't really know which jobs are most expensive in terms of bandwidth, or storage, or CPUs, and even if I knew those I don't know how to map those to currency. So I'm not sure if the UI we'd like would minimize the cost the way we'd like. - ajax ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 30/36] drm/amd/display: Avoid create MST prop after registration
On 2020-04-05 10:41 p.m., Rodrigo Siqueira wrote: > From: "Jerry (Fangzhi) Zuo" > > [Why] > Prop are created at boot stage, and not allowed to create new prop > after device registration. > > [How] > Reuse the connector property from SST if exist. > > Signed-off-by: Jerry (Fangzhi) Zuo > Reviewed-by: Hersen Wu > Acked-by: Rodrigo Siqueira This patch is needed in 5.7, or one gets the WARNINGs I reported in https://lists.freedesktop.org/archives/amd-gfx/2020-April/048017.html when an MST display is connected. Note that this patch doesn't fix all of those, there's also one triggered by dm_dp_add_mst_connector => drm_encoder_init. git grep mst_encoders drivers/gpu/drm/i915/ shows how the i915 driver deals with this. Can you guys take care of that for 5.7 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: [PATCH] drm/amdgpu/display: fix logic inversion in program_timing_sync()
Ping again?
Alex
On Thu, Feb 20, 2020 at 8:27 AM Alex Deucher wrote:
>
> On Tue, Feb 4, 2020 at 9:06 AM Kazlauskas, Nicholas
> wrote:
> >
> > Comments inline.
> >
> > On 2020-02-03 4:07 p.m., Alex Deucher wrote:
> > > Ping?
> > >
> > > On Fri, Jan 10, 2020 at 3:11 PM Alex Deucher
> > > wrote:
> > >>
> > >> It looks like we should be reducing the group size when we don't
> > >> have a plane rather than when we do.
> > >>
> > >> Bug: https://gitlab.freedesktop.org/drm/amd/issues/781
> > >> Fixes: 5fc0cbfad45648 ("drm/amd/display: determine if a pipe is synced
> > >> by plane state")
> > >> Signed-off-by: Alex Deucher
> > >> ---
> > >> drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ++--
> > >> 1 file changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > >> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > >> index 3d89904003f0..01b27726d9c5 100644
> > >> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > >> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > >> @@ -1003,9 +1003,9 @@ static void program_timing_sync(
> > >> status->timing_sync_info.master = false;
> > >>
> > >> }
> > >> - /* remove any other pipes with plane as they have
> > >> already been synced */
> > >> + /* remove any other pipes without plane as they have
> > >> already been synced */
> >
> > This took a while to wrap my head around but I think I understand what
> > this was originally trying to do.
> >
> > The original logic seems to have been checking for blanked streams and
> > trying to remove anything that was blanked from the group to try and
> > avoid having to enable timing synchronization.
> >
> > However, the logic for blanked is *not* the same as having a
> > plane_state. Technically you can drive an OTG without anything connected
> > in the front end and it'll just draw out the back color - which is
> > distinct from having the OTG be blanked.
> >
> > The problem is really this iteration below:
> >
> > >> for (j = j + 1; j < group_size; j++) {
> >
> > There could still be pipes in here (depending on the ordering) that have
> > planes and could be synchronized with the master OTG. I think starting
> > at j + 1 is a mistake for this logic as well.
> >
> > I wonder if we can just drop this loop altogether. If we add planes or
> > unblank the OTG later then we'll still want the synchronization.
> >
> > Dymtro, Wenjing - feel free to correct my understanding if I'm mistaken
> > about this.
>
> Ping? Any thoughts on this? It would be nice to get this fixed.
>
> Alex
>
>
> >
> > Regards,
> > Nicholas Kazlauskas
> >
> > >> - if (pipe_set[j]->plane_state) {
> > >> + if (!pipe_set[j]->plane_state) {
> > >> group_size--;
> > >> pipe_set[j] = pipe_set[group_size];
> > >> j--;
> > >> --
> > >> 2.24.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] drm/amdgpu: add SPM golden settings for Navi10(v2)
[AMD Official Use Only - Internal Distribution Only] Thanks very much Alex! From: Alex Deucher Sent: Monday, April 6, 2020 22:29 To: Yin, Tianci (Rico) Cc: amd-gfx list ; Deucher, Alexander ; Xu, Feifei ; Zhang, Hawking ; Hesik, Christopher Subject: Re: [PATCH] drm/amdgpu: add SPM golden settings for Navi10(v2) On Mon, Apr 6, 2020 at 10:26 AM Tianci Yin wrote: > > From: "Tianci.Yin" > > Add RLC_SPM golden settings > > Change-Id: I616e127171293d915cb3a05dee02f51cec8d8f6f > Signed-off-by: Tianci.Yin Reviewed-by: Alex Deucher ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: add SPM golden settings for Navi10(v2)
On Mon, Apr 6, 2020 at 10:26 AM Tianci Yin wrote: > > From: "Tianci.Yin" > > Add RLC_SPM golden settings > > Change-Id: I616e127171293d915cb3a05dee02f51cec8d8f6f > Signed-off-by: Tianci.Yin Reviewed-by: Alex Deucher ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: add SPM golden settings for Navi10(v2)
From: "Tianci.Yin"
Add RLC_SPM golden settings
Change-Id: I616e127171293d915cb3a05dee02f51cec8d8f6f
Signed-off-by: Tianci.Yin
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1059
1 file changed, 1059 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 70edbbf84338..19d9bdba0453 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -138,6 +138,1062 @@ static const struct soc15_reg_golden
golden_settings_gc_10_0_nv10[] =
/* Pending on emulation bring up */
};
+static const struct soc15_reg_golden golden_settings_gc_rlc_spm_10_0_nv10[] =
+{
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xe000, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0x28),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0x9),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_ADDR,
0x, 0x8),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_DATA,
0x, 0x1b),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x1),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_ADDR,
0x, 0x8),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x1),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_SE_SAMPLEDELAY_IND_DATA,
0x, 0x1b),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0x20),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xe),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0xc8),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xf),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0xcc),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xf),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0xd0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xf),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0xd4),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xf),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0x24),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xf),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0x24),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xf),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0x4),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0x11),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0x8),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_DATA,
0x, 0xf),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRLC_SPM_GLB_SAMPLEDELAY_IND_ADDR,
0x, 0x0),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGRBM_GFX_INDEX, 0xff, 0x0),
+
Re: [PATCH 1/1] drm/amd/powerplay: fix a typo
On Mon, Apr 6, 2020 at 4:08 AM Nirmoy Das wrote:
>
> Util -> Until
> Fixes: 720de5122254e86 (drm/amd/powerplay: implement the is_dpm_running())
>
> Signed-off-by: Nirmoy Das
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> index ff73a735b888..95eb44515e36 100644
> --- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> @@ -896,7 +896,7 @@ static int renoir_read_sensor(struct smu_context *smu,
> static bool renoir_is_dpm_running(struct smu_context *smu)
> {
> /*
> -* Util now, the pmfw hasn't exported the interface of SMU
> +* Until now, the pmfw hasn't exported the interface of SMU
> * feature mask to APU SKU so just force on all the feature
> * at early initial stage.
> */
> --
> 2.26.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: AMD DC graphics display code enables -mhard-float, -msse, -msse2 without any visible FPU state protection
On Sun, Apr 05, 2020 at 12:19:30PM +0900, Masami Hiramatsu wrote:
> > @@ -269,14 +269,14 @@ d4: AAM Ib (i64)
> > d5: AAD Ib (i64)
> > d6:
> > d7: XLAT/XLATB
> > -d8: ESC
> > -d9: ESC
> > -da: ESC
> > -db: ESC
> > -dc: ESC
> > -dd: ESC
> > -de: ESC
> > -df: ESC
> > +d8: FPU
> > +d9: FPU
> > +da: FPU
> > +db: FPU
> > +dc: FPU
> > +dd: FPU
> > +de: FPU
> > +df: FPU
>
> I don't want to use FPU since Intel SDM is still using ESC because it
> is co-processor escape code.
But we all know that co-processor is x87. Can we then perhaps put in
'x87' as an escape code instead of 'ESC' ?
> Here is the new patch.
>
> From d7eca4946ab3f0d08ad1268f49418f8655aaf57c Mon Sep 17 00:00:00 2001
> From: Masami Hiramatsu
> Date: Fri, 3 Apr 2020 16:58:22 +0900
> Subject: [PATCH] x86: insn: Add insn_is_fpu()
>
> Add insn_is_fpu(insn) which tells that the insn is
> whether touch the MMX/XMM/YMM register or the instruction
> of FP coprocessor.
>
> Signed-off-by: Masami Hiramatsu
arch/x86/mm/extable.o: warning: objtool: ex_handler_fprestore()+0x8b: fpu_safe
hint not an FPU instruction
008b 36b: 48 0f ae 0d 00 00 00fxrstor64 0x0(%rip)# 373
arch/x86/kvm/x86.o: warning: objtool: kvm_load_guest_fpu.isra.0()+0x1fa:
fpu_safe hint not an FPU instruction
01fa1d2fa: 48 0f ae 4b 40 fxrstor64 0x40(%rbx)
Also, all the VMX bits seems to qualify as FPU (I can't remember seeing
that previously):
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_apic_eoi_induced()+0x20: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_apic_write()+0x20: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_invlpg()+0x20: FPU instruction
outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_get_interrupt_shadow()+0x1c: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_decache_cr4_guest_bits()+0x5a:
FPU instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_decache_cr0_guest_bits()+0x5a:
FPU instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_io()+0x24: FPU instruction
outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_apic_access()+0x39: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_get_idt()+0x57: FPU instruction
outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_get_exit_info()+0x58: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_get_gdt()+0x57: FPU instruction
outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_guest_apic_has_interrupt()+0xf8:
FPU instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_nmi_allowed()+0x98: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0xb3: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_get_nmi_mask()+0x8a: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_get_rflags()+0x99: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_ept_misconfig()+0x22: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_interrupt_allowed()+0x8d: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_write_pml_buffer()+0x1c5: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_invpcid()+0x26a: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_read_guest_seg_ar()+0x9b: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_read_guest_seg_selector()+0x96:
FPU instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_read_guest_seg_base()+0x9b: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_get_segment()+0x2da: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmwrite_error()+0x161: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: exec_controls_set.isra.0()+0x5a: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: handle_dr()+0x1bc: FPU instruction
outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: update_exception_bitmap()+0x136: FPU
instruction outside of kernel_fpu_{begin,end}()
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_set_interrupt_shadow()+0x8b: FPU
instruction outside of kernel_fpu_{begin,end}()
Re: [PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.
Am 06.04.20 um 14:31 schrieb James Zhu:
On 2020-04-06 3:03 a.m., Christian König wrote:
Am 03.04.20 um 17:54 schrieb James Zhu:
On 2020-04-03 11:37 a.m., Alex Deucher wrote:
On Fri, Apr 3, 2020 at 8:52 AM James Zhu wrote:
VCN shared memory needs restore after wake up during S3 test.
How big is the shared memory? It might be better to allocate the
memory once at sw_init and then free it in sw_fini rather than
allocating and freeing in every suspend/resume.
Hi Alex,
After alignment, it is only 4k. I can change it as you suggest.
Does this needs to stay at the same place after a suspend/resume?
See we only backup the firmware manually because we otherwise can't
guarantee that it will be moved back to the same place after resume.
Yes, this is the case.. FW request the same for their resume processing.
If that isn't an issue for the shared bo we could just unpin it on
suspend and pin it again on resume.
BTW: What is that used for and why can't it be part of the VCN
firmware BO?
Logically it is used for FW and driver sharing some settings
conveniently. If you suggest it can be added into VCN BO, then it will
simply the implementation.
As long as this is only used by the kernel driver it sounds like it is
best put into the VCN BO as well, yes.
Regards,
Christian.
Thanks and Best Regards!
James Zhu
Thanks,
Christian.
Best Regards!
James
Alex
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 26
++
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d653a18..5891390 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -205,6 +205,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device
*adev)
if (adev->vcn.harvest_config & (1 << j))
continue;
+ kvfree(adev->vcn.inst[j].saved_shm_bo);
amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
>vcn.inst[j].fw_shared_gpu_addr,
(void
**)>vcn.inst[j].fw_shared_cpu_addr);
@@ -254,6 +255,18 @@ int amdgpu_vcn_suspend(struct amdgpu_device
*adev)
return -ENOMEM;
memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
+
+ if (adev->vcn.inst[i].fw_shared_bo == NULL)
+ return 0;
+
+ size =
amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+ ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+ adev->vcn.inst[i].saved_shm_bo = kvmalloc(size,
GFP_KERNEL);
+ if (!adev->vcn.inst[i].saved_shm_bo)
+ return -ENOMEM;
+
+ memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
}
return 0;
}
@@ -291,6 +304,19 @@ int amdgpu_vcn_resume(struct amdgpu_device
*adev)
}
memset_io(ptr, 0, size);
}
+
+ if (adev->vcn.inst[i].fw_shared_bo == NULL)
+ return -EINVAL;
+
+ size =
amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+ ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+ if (adev->vcn.inst[i].saved_shm_bo != NULL) {
+ memcpy_toio(ptr,
adev->vcn.inst[i].saved_shm_bo, size);
+ kvfree(adev->vcn.inst[i].saved_shm_bo);
+ adev->vcn.inst[i].saved_shm_bo = NULL;
+ } else
+ memset_io(ptr, 0, size);
}
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index f739e1a..bd77dae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
atomic_t dpg_enc_submission_cnt;
void *fw_shared_cpu_addr;
uint64_t fw_shared_gpu_addr;
+ void *saved_shm_bo;
};
struct amdgpu_vcn {
--
2.7.4
___
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=02%7C01%7CJames.Zhu%40amd.com%7Ccf00d8be2e994e71381808d7d9f8a0d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217534184643911sdata=pjIqtWZKO5768HmBOjH1fhjZMPScuyBUg%2FprxH2QWc4%3Dreserved=0
___
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=02%7C01%7CJames.Zhu%40amd.com%7Ccf00d8be2e994e71381808d7d9f8a0d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217534184643911sdata=pjIqtWZKO5768HmBOjH1fhjZMPScuyBUg%2FprxH2QWc4%3Dreserved=0
Re: [PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.
On 2020-04-06 3:03 a.m., Christian König wrote:
Am 03.04.20 um 17:54 schrieb James Zhu:
On 2020-04-03 11:37 a.m., Alex Deucher wrote:
On Fri, Apr 3, 2020 at 8:52 AM James Zhu wrote:
VCN shared memory needs restore after wake up during S3 test.
How big is the shared memory? It might be better to allocate the
memory once at sw_init and then free it in sw_fini rather than
allocating and freeing in every suspend/resume.
Hi Alex,
After alignment, it is only 4k. I can change it as you suggest.
Does this needs to stay at the same place after a suspend/resume?
See we only backup the firmware manually because we otherwise can't
guarantee that it will be moved back to the same place after resume.
Yes, this is the case.. FW request the same for their resume processing.
If that isn't an issue for the shared bo we could just unpin it on
suspend and pin it again on resume.
BTW: What is that used for and why can't it be part of the VCN
firmware BO?
Logically it is used for FW and driver sharing some settings
conveniently. If you suggest it can be added into VCN BO, then it will
simply the implementation.
Thanks and Best Regards!
James Zhu
Thanks,
Christian.
Best Regards!
James
Alex
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 26
++
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d653a18..5891390 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -205,6 +205,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device *adev)
if (adev->vcn.harvest_config & (1 << j))
continue;
+ kvfree(adev->vcn.inst[j].saved_shm_bo);
amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
>vcn.inst[j].fw_shared_gpu_addr,
(void
**)>vcn.inst[j].fw_shared_cpu_addr);
@@ -254,6 +255,18 @@ int amdgpu_vcn_suspend(struct amdgpu_device
*adev)
return -ENOMEM;
memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
+
+ if (adev->vcn.inst[i].fw_shared_bo == NULL)
+ return 0;
+
+ size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+ ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+ adev->vcn.inst[i].saved_shm_bo = kvmalloc(size,
GFP_KERNEL);
+ if (!adev->vcn.inst[i].saved_shm_bo)
+ return -ENOMEM;
+
+ memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
}
return 0;
}
@@ -291,6 +304,19 @@ int amdgpu_vcn_resume(struct amdgpu_device *adev)
}
memset_io(ptr, 0, size);
}
+
+ if (adev->vcn.inst[i].fw_shared_bo == NULL)
+ return -EINVAL;
+
+ size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+ ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+ if (adev->vcn.inst[i].saved_shm_bo != NULL) {
+ memcpy_toio(ptr,
adev->vcn.inst[i].saved_shm_bo, size);
+ kvfree(adev->vcn.inst[i].saved_shm_bo);
+ adev->vcn.inst[i].saved_shm_bo = NULL;
+ } else
+ memset_io(ptr, 0, size);
}
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index f739e1a..bd77dae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
atomic_t dpg_enc_submission_cnt;
void *fw_shared_cpu_addr;
uint64_t fw_shared_gpu_addr;
+ void *saved_shm_bo;
};
struct amdgpu_vcn {
--
2.7.4
___
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=02%7C01%7CJames.Zhu%40amd.com%7Ccf00d8be2e994e71381808d7d9f8a0d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217534184643911sdata=pjIqtWZKO5768HmBOjH1fhjZMPScuyBUg%2FprxH2QWc4%3Dreserved=0
___
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=02%7C01%7CJames.Zhu%40amd.com%7Ccf00d8be2e994e71381808d7d9f8a0d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637217534184643911sdata=pjIqtWZKO5768HmBOjH1fhjZMPScuyBUg%2FprxH2QWc4%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[bug report] drm/amd/display: Add ABM driver implementation
Hello Wyatt Wood, This is a semi-automatic email about new static checker warnings. The patch 16012806e697: "drm/amd/display: Add ABM driver implementation" from Feb 20, 2020, leads to the following Smatch complaint: drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:661 dmcu_load_iram() warn: variable dereferenced before check 'dmcu' (see line 659) drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c 658 bool result = false; 659 struct abm *abm = dmcu->ctx->dc->res_pool->abm; ^^ The patch adds a dereference 660 661 if (dmcu == NULL && abm == NULL) 662 return false; 663 664 if (dmcu && !dmcu->funcs->is_dmcu_initialized(dmcu)) And it also adds NULL checking on dmcu. 665 return true; 666 667 memset(_table, 0, sizeof(ram_table)); 668 regards, dan carpenter ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH net-next] drm/amd/display: Fix link_detect_sink()
This TODO stub originally had curly braces but we deleted them as part
of a clean up. Unfortunately that changes the behavior of the code
because now the switch statement is part of the if statement. Smatch
complains that the indenting doesn't make sense.
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:425
link_detect_sink() warn: if statement not indented
Also I changed "ZAZTODO" to just "TODO". The ZAZ isn't used anywhere
else.
Fixes: 621514aa4140 ("drm/amd/display: codestyle cleanup on dc_link file until
detect_dp func")
Signed-off-by: Dan Carpenter
---
Another idea is we should just delete this stub. Stub code is generally
against kernel style. I can send a V2 if people want.
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index a93997ff0419..188670d374a3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -423,7 +423,7 @@ static enum signal_type link_detect_sink(struct dc_link
*link,
/* PCIE detects the actual connector on add-on board */
if (link->link_id.id == CONNECTOR_ID_PCIE)
- /* ZAZTODO implement PCIE add-on card detection */
+ ; /* TODO implement PCIE add-on card detection */
switch (link->link_id.id) {
case CONNECTOR_ID_HDMI_TYPE_A: {
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/1] drm/amd/powerplay: fix a typo
Util -> Until
Fixes: 720de5122254e86 (drm/amd/powerplay: implement the is_dpm_running())
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index ff73a735b888..95eb44515e36 100644
--- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
@@ -896,7 +896,7 @@ static int renoir_read_sensor(struct smu_context *smu,
static bool renoir_is_dpm_running(struct smu_context *smu)
{
/*
-* Util now, the pmfw hasn't exported the interface of SMU
+* Until now, the pmfw hasn't exported the interface of SMU
* feature mask to APU SKU so just force on all the feature
* at early initial stage.
*/
--
2.26.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/vcn: add shared menory restore after wake up from sleep.
Am 03.04.20 um 17:54 schrieb James Zhu:
On 2020-04-03 11:37 a.m., Alex Deucher wrote:
On Fri, Apr 3, 2020 at 8:52 AM James Zhu wrote:
VCN shared memory needs restore after wake up during S3 test.
How big is the shared memory? It might be better to allocate the
memory once at sw_init and then free it in sw_fini rather than
allocating and freeing in every suspend/resume.
Hi Alex,
After alignment, it is only 4k. I can change it as you suggest.
Does this needs to stay at the same place after a suspend/resume?
See we only backup the firmware manually because we otherwise can't
guarantee that it will be moved back to the same place after resume.
If that isn't an issue for the shared bo we could just unpin it on
suspend and pin it again on resume.
BTW: What is that used for and why can't it be part of the VCN firmware BO?
Thanks,
Christian.
Best Regards!
James
Alex
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 26
++
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index d653a18..5891390 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -205,6 +205,7 @@ int amdgpu_vcn_sw_fini(struct amdgpu_device *adev)
if (adev->vcn.harvest_config & (1 << j))
continue;
+ kvfree(adev->vcn.inst[j].saved_shm_bo);
amdgpu_bo_free_kernel(>vcn.inst[j].fw_shared_bo,
>vcn.inst[j].fw_shared_gpu_addr,
(void
**)>vcn.inst[j].fw_shared_cpu_addr);
@@ -254,6 +255,18 @@ int amdgpu_vcn_suspend(struct amdgpu_device *adev)
return -ENOMEM;
memcpy_fromio(adev->vcn.inst[i].saved_bo, ptr, size);
+
+ if (adev->vcn.inst[i].fw_shared_bo == NULL)
+ return 0;
+
+ size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+ ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+ adev->vcn.inst[i].saved_shm_bo = kvmalloc(size,
GFP_KERNEL);
+ if (!adev->vcn.inst[i].saved_shm_bo)
+ return -ENOMEM;
+
+ memcpy_fromio(adev->vcn.inst[i].saved_shm_bo, ptr, size);
}
return 0;
}
@@ -291,6 +304,19 @@ int amdgpu_vcn_resume(struct amdgpu_device *adev)
}
memset_io(ptr, 0, size);
}
+
+ if (adev->vcn.inst[i].fw_shared_bo == NULL)
+ return -EINVAL;
+
+ size = amdgpu_bo_size(adev->vcn.inst[i].fw_shared_bo);
+ ptr = adev->vcn.inst[i].fw_shared_cpu_addr;
+
+ if (adev->vcn.inst[i].saved_shm_bo != NULL) {
+ memcpy_toio(ptr,
adev->vcn.inst[i].saved_shm_bo, size);
+ kvfree(adev->vcn.inst[i].saved_shm_bo);
+ adev->vcn.inst[i].saved_shm_bo = NULL;
+ } else
+ memset_io(ptr, 0, size);
}
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index f739e1a..bd77dae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -194,6 +194,7 @@ struct amdgpu_vcn_inst {
atomic_t dpg_enc_submission_cnt;
void *fw_shared_cpu_addr;
uint64_t fw_shared_gpu_addr;
+ void *saved_shm_bo;
};
struct amdgpu_vcn {
--
2.7.4
___
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=02%7C01%7CJames.Zhu%40amd.com%7C46c4773164334ec712b708d7d7e4ebd6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637215250518903143sdata=Mj%2FgeXKkiNVFUUsyKAesC5eaanDg%2FvQQpQe1rhT9uek%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] PCI/P2PDMA: Add additional AMD ZEN root ports to the whitelist
Am 03.04.20 um 21:38 schrieb Alex Deucher:
According to the hw architect, pre-ZEN parts support
p2p writes and ZEN parts support both p2p reads and writes.
Add entries for Zen parts Raven (0x15d0) and Renoir (0x1630).
Cc: Christian König
Signed-off-by: Alex Deucher
Acked-by: Christian König
---
drivers/pci/p2pdma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 9a8a38384121..91a4c987399d 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -282,6 +282,8 @@ static const struct pci_p2pdma_whitelist_entry {
} pci_p2pdma_whitelist[] = {
/* AMD ZEN */
{PCI_VENDOR_ID_AMD, 0x1450, 0},
+ {PCI_VENDOR_ID_AMD, 0x15d0, 0},
+ {PCI_VENDOR_ID_AMD, 0x1630, 0},
/* Intel Xeon E5/Core i7 */
{PCI_VENDOR_ID_INTEL, 0x3c00, REQ_SAME_HOST_BRIDGE},
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
