RE: [PATCH] drm/amd/pm: bug fix for the runtime pm BACO
[AMD Official Use Only]
Tested and Reviewed-by: Jack Gui
-Original Message-
From: Kenneth Feng
Sent: Friday, August 6, 2021 10:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Gui, Jack ; Feng, Kenneth
Subject: [PATCH] drm/amd/pm: bug fix for the runtime pm BACO
In some systems only MACO is supported. This is to fix the prolbem that runtime
pm is enabled but BACO is not supported. MACO will be handled seperately.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 90e40aacb8f6..261ef8ca862e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -353,8 +353,7 @@ static void sienna_cichlid_check_bxco_support(struct
smu_context *smu)
struct amdgpu_device *adev = smu->adev;
uint32_t val;
- if (powerplay_table->platform_caps & SMU_11_0_7_PP_PLATFORM_CAP_BACO ||
- powerplay_table->platform_caps & SMU_11_0_7_PP_PLATFORM_CAP_MACO) {
+ if (powerplay_table->platform_caps & SMU_11_0_7_PP_PLATFORM_CAP_BACO)
+{
val = RREG32_SOC15(NBIO, 0, mmRCC_BIF_STRAP0);
smu_baco->platform_support =
(val & RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true :
--
2.17.1
[PATCH] drm/amd/pm: bug fix for the runtime pm BACO
In some systems only MACO is supported. This is to fix the prolbem
that runtime pm is enabled but BACO is not supported. MACO will be
handled seperately.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 90e40aacb8f6..261ef8ca862e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -353,8 +353,7 @@ static void sienna_cichlid_check_bxco_support(struct
smu_context *smu)
struct amdgpu_device *adev = smu->adev;
uint32_t val;
- if (powerplay_table->platform_caps & SMU_11_0_7_PP_PLATFORM_CAP_BACO ||
- powerplay_table->platform_caps & SMU_11_0_7_PP_PLATFORM_CAP_MACO) {
+ if (powerplay_table->platform_caps & SMU_11_0_7_PP_PLATFORM_CAP_BACO) {
val = RREG32_SOC15(NBIO, 0, mmRCC_BIF_STRAP0);
smu_baco->platform_support =
(val & RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true :
--
2.17.1
[pull] amdgpu drm-fixes-5.14
Hi Dave, Daniel, Same pull, more S-o-b. The following changes since commit d28e2568ac26fff351c846bf74ba6ca5dded733e: Merge tag 'amd-drm-fixes-5.14-2021-07-28' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-07-29 17:20:29 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.14-2021-08-05 for you to fetch changes up to e00f543d3596c71201438d967877138ab33bb3de: drm/amdgpu: add DID for beige goby (2021-08-05 21:02:29 -0400) amd-drm-fixes-5.14-2021-08-05: amdgpu: - Fix potential out-of-bounds read when updating GPUVM mapping - Renoir powergating fix - Yellow Carp updates - 8K fix for navi1x - Beige Goby updates and new DIDs - Fix DMUB firmware version output - EDP fix - pmops config fix Bing Guo (2): drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X drm/amd/display: Increase stutter watermark for dcn303 Chengming Gui (1): drm/amdgpu: add DID for beige goby Jude Shih (1): drm/amd/display: Fix resetting DCN3.1 HW when resuming from S4 Qingqing Zhuo (1): drm/amd/display: workaround for hard hang on HPD on native DP Randy Dunlap (1): drm/amdgpu: fix checking pmops when PM_SLEEP is not enabled Shirish S (1): drm/amdgpu/display: fix DMUB firmware version info Wesley Chalmers (1): drm/amd/display: Assume LTTPR interop for DCN31+ Xiaomeng Hou (1): drm/amd/pm: update yellow carp pmfw interface version Yifan Zhang (1): drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir. xinhui pan (1): drm/amdgpu: Fix out-of-bounds read when update mapping drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 7 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 3 ++- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 21 - drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c| 21 ++--- drivers/gpu/drm/amd/display/dc/dc.h | 2 ++ drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- .../gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 20 .../gpu/drm/amd/display/dc/dcn303/dcn303_resource.c | 4 ++-- .../gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 16 drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 8 +--- drivers/gpu/drm/amd/pm/inc/smu_v13_0.h | 2 +- 14 files changed, 83 insertions(+), 31 deletions(-)
RE: [PATCH v2 00/14] drm: Make DRM's IRQ helpers legacy
Hi Thomas,
> -Original Message-
> From: Thomas Zimmermann
> Sent: Wednesday, August 4, 2021 12:11 AM
> To: Chrisanthus, Anitha ; Sam Ravnborg
>
> Cc: dan...@ffwll.ch; airl...@linux.ie; alexander.deuc...@amd.com;
> christian.koe...@amd.com; liviu.du...@arm.com; brian.star...@arm.com;
> bbrezil...@kernel.org; nicolas.fe...@microchip.com;
> maarten.lankho...@linux.intel.com; mrip...@kernel.org; ste...@agner.ch;
> alison.w...@nxp.com; patrik.r.jakobs...@gmail.com; robdcl...@gmail.com;
> Dea, Edmund J ; s...@poorly.run;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> jyri.sa...@iki.fi; to...@kernel.org; dan.sned...@microchip.com;
> tomi.valkei...@ideasonboard.com; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org; linux-arm-
> m...@vger.kernel.org; freedr...@lists.freedesktop.org
> Subject: Re: [PATCH v2 00/14] drm: Make DRM's IRQ helpers legacy
>
> Hi
>
> Am 03.08.21 um 20:36 schrieb Chrisanthus, Anitha:
> > Hi Thomas,
> > Can you please hold off on applying the kmb patch, I am seeing some issues
> while testing. Modetest works, but video playback only plays once, and it
> fails
> the second time with this patch.
>
> Sounds a bit like the testing issue at [1]. For testing, you need the
> latest drm-misc-next or drm-tip. Specifically, you need commit
> 1e4cd78ed493 ("drm: Don't test for IRQ support in VBLANK ioctls").
You are right, with the above patch video plays fine. It's all good now! Sorry
about the confusion.
>
> Let me know whether this works for you.
>
> Best regards
> Thomas
>
> [1] https://patchwork.freedesktop.org/patch/447057/?series=93078=1
>
> >
> > Thanks,
> > Anitha
> >
> >
> >> -Original Message-
> >> From: Sam Ravnborg
> >> Sent: Tuesday, August 3, 2021 8:05 AM
> >> To: Thomas Zimmermann
> >> Cc: dan...@ffwll.ch; airl...@linux.ie; alexander.deuc...@amd.com;
> >> christian.koe...@amd.com; liviu.du...@arm.com;
> brian.star...@arm.com;
> >> bbrezil...@kernel.org; nicolas.fe...@microchip.com;
> >> maarten.lankho...@linux.intel.com; mrip...@kernel.org;
> ste...@agner.ch;
> >> alison.w...@nxp.com; patrik.r.jakobs...@gmail.com; Chrisanthus, Anitha
> >> ; robdcl...@gmail.com; Dea, Edmund J
> >> ; s...@poorly.run; shawn...@kernel.org;
> >> s.ha...@pengutronix.de; ker...@pengutronix.de; jyri.sa...@iki.fi;
> >> to...@kernel.org; dan.sned...@microchip.com;
> >> tomi.valkei...@ideasonboard.com; amd-gfx@lists.freedesktop.org; dri-
> >> de...@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org; linux-
> arm-
> >> m...@vger.kernel.org; freedr...@lists.freedesktop.org
> >> Subject: Re: [PATCH v2 00/14] drm: Make DRM's IRQ helpers legacy
> >>
> >> Hi Thomas,
> >>
> >> On Tue, Aug 03, 2021 at 11:06:50AM +0200, Thomas Zimmermann wrote:
> >>> DRM's IRQ helpers are only helpful for old, non-KMS drivers. Move
> >>> the code behind CONFIG_DRM_LEGACY. Convert KMS drivers to Linux
> >>> IRQ interfaces.
> >>>
> >>> DRM provides IRQ helpers for setting up, receiving and removing IRQ
> >>> handlers. It's an abstraction over plain Linux functions. The code
> >>> is mid-layerish with several callbacks to hook into the rsp drivers.
> >>> Old UMS driver have their interrupts enabled via ioctl, so these
> >>> abstractions makes some sense. Modern KMS manage all their interrupts
> >>> internally. Using the DRM helpers adds indirection without benefits.
> >>>
> >>> Most KMS drivers already use Linux IRQ functions instead of DRM's
> >>> abstraction layer. Patches 1 to 12 convert the remaining ones.
> >>> The patches also resolve a bug for devices without assigned interrupt
> >>> number. DRM helpers don't test for IRQ_NOTCONNECTED, so drivers do
> >>> not detect if the device has no interrupt assigned.
> >>>
> >>> Patch 13 removes an unused function.
> >>>
> >>> Patch 14 moves the DRM IRQ helpers behind CONFIG_DRM_LEGACY. Only
> >>> the old non-KMS drivers still use the functionality.
> >>>
> >>> v2:
> >>> * drop IRQ_NOTCONNECTED test from atmel-hlcdc (Sam)
> >>> * use devm_request_irq() in atmel-hlcdc (Sam)
> >>> * unify variable names in arm/hlcdc (Sam)
> >>>
> >>> Thomas Zimmermann (14):
> >>
> >> The following patches are all:
> >> Acked-by: Sam Ravnborg
> >>
> >>>drm/fsl-dcu: Convert to Linux IRQ interfaces
> >>>drm/gma500: Convert to Linux IRQ interfaces
> >>>drm/kmb: Convert to Linux IRQ interfaces
> >>>drm/msm: Convert to Linux IRQ interfaces
> >>>drm/mxsfb: Convert to Linux IRQ interfaces
> >>>drm/tidss: Convert to Linux IRQ interfaces
> >>>drm/vc4: Convert to Linux IRQ interfaces
> >>>drm: Remove unused devm_drm_irq_install()
> >>
> >> The remaining patches I either skipped or already had a feedback from
> >> me or I asked a question.
> >>
> >>Sam
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
Re: [PATCHv2 1/2] drm/amd/amdgpu embed hw_fence into amdgpu_job
On 2021-08-05 4:31 a.m., Jingwen Chen wrote:
From: Jack Zhang
Why: Previously hw fence is alloced separately with job.
It caused historical lifetime issues and corner cases.
The ideal situation is to take fence to manage both job
and fence's lifetime, and simplify the design of gpu-scheduler.
How:
We propose to embed hw_fence into amdgpu_job.
1. We cover the normal job submission by this method.
2. For ib_test, and submit without a parent job keep the
legacy way to create a hw fence separately.
v2:
use AMDGPU_FENCE_FLAG_EMBED_IN_JOB_BIT to show that the fence is
embeded in a job.
Signed-off-by: Jingwen Chen
Signed-off-by: Jack Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 63 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 35
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h| 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
8 files changed, 84 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 7b46ba551cb2..3003ee1c9487 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -714,7 +714,6 @@ int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum
kgd_engine_type engine,
ret = dma_fence_wait(f, false);
err_ib_sched:
- dma_fence_put(f);
amdgpu_job_free(job);
err:
return ret;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 536005bff24a..277128846dd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1414,7 +1414,7 @@ static void amdgpu_ib_preempt_mark_partial_job(struct
amdgpu_ring *ring)
continue;
}
job = to_amdgpu_job(s_job);
- if (preempted && job->fence == fence)
+ if (preempted && (>hw_fence) == fence)
/* mark the job as preempted */
job->preemption_status |= AMDGPU_IB_PREEMPTED;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 7495911516c2..5e29d797a265 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -129,30 +129,46 @@ static u32 amdgpu_fence_read(struct amdgpu_ring *ring)
*
* @ring: ring the fence is associated with
* @f: resulting fence object
+ * @job: job the fence is embeded in
* @flags: flags to pass into the subordinate .emit_fence() call
*
* Emits a fence command on the requested ring (all asics).
* Returns 0 on success, -ENOMEM on failure.
*/
-int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f,
+int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f, struct
amdgpu_job *job,
unsigned flags)
{
struct amdgpu_device *adev = ring->adev;
- struct amdgpu_fence *fence;
+ struct dma_fence *fence;
+ struct amdgpu_fence *am_fence;
struct dma_fence __rcu **ptr;
uint32_t seq;
int r;
- fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL);
- if (fence == NULL)
- return -ENOMEM;
+ if (job == NULL) {
+ /* create a sperate hw fence */
+ am_fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC);
+ if (am_fence == NULL)
+ return -ENOMEM;
+ fence = _fence->base;
+ am_fence->ring = ring;
+ } else {
+ /* take use of job-embedded fence */
+ fence = >hw_fence;
+ job->ring = ring;
If you would make hw_fence of type amdgpu_fence
you could probably avoid the special job->ring = ring
See more in related comment at the bottom
+ }
seq = ++ring->fence_drv.sync_seq;
- fence->ring = ring;
- dma_fence_init(>base, _fence_ops,
+ dma_fence_init(fence, _fence_ops,
>fence_drv.lock,
adev->fence_context + ring->idx,
seq);
+
+ if (job != NULL) {
+ /* mark this fence has a parent job */
+ set_bit(AMDGPU_FENCE_FLAG_EMBED_IN_JOB_BIT, >flags);
+ }
+
amdgpu_ring_emit_fence(ring, ring->fence_drv.gpu_addr,
seq, flags | AMDGPU_FENCE_FLAG_INT);
pm_runtime_get_noresume(adev_to_drm(adev)->dev);
@@ -175,9 +191,9 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct
dma_fence **f,
/* This function can't be called concurrently anyway, otherwise
* emitting the fence would mess up the hardware ring buffer.
*/
Re: Help needed for EVoC/GSoC/Outreachy
Hi everyone! I got some questions from someone that made me realize that there's a couple of things that I forgot to mention here that might be useful for folks to know regarding being a mentor: * "Who decides what project and what student?" It's up to the student to come up with ideas for what they want to work on, although we will occasionally have a list of potential project ideas that students are welcome to use or draw inspiration from. Since X.org participates as a foundation, pretty much any of the projects under the X.org umbrella are allowed to do this if they're willing to come up with mentors. As for who the mentors are, that's really all just up to who's volunteering for it on a given project. As for how we decide what students we accept, that decision is usually made based off the quality of their project proposal along with whether a student seems self-sufficient enough to accomplish said project. Most students who come to us with a project idea already typically fall into this category. The final decision for this is typically made by the student's proposed mentor and/or our volunteer GSoC/Outreachy/EVoC admin. * "I assume this is international?" X.org tries to make our student outreach programs as international as possible. GSoC covers most of the world, but there are definitely some areas it doesn't cover - which is why we've ran EVoC in the past, so that students in areas that wouldn't be eligible for GSoC would still have a chance at participating in a project. Outreachy also helps fill this gap, as I don't believe they have the same kind of international restrictions that GSoC does. * What is the expected result, a grading? Yes. On Wed, 2021-07-14 at 16:32 -0400, Lyude Paul wrote: > Hi! As some of you might already be aware, after helping out X.org > project the previous years with regards to student outreach, Trevor > decided to retire from this position in hopes that someone else will be > able to step up and take on these responsibilities. As such, we're > trying to find people who would be willing to volunteer their time to > help out with getting us involved once again in student outreach > programs. > > In the past, X.org has been active in the GSoC program, occasionally > Outreachy, and our own EVoC program. As of 2021 though, GSoC decided to > shorten the amount of time allocated for a student to work on their > project. This unfortunately posed some problems for > X.org/freedesktop.org as a lot of the potential work that would have > been good for us to have students working on wouldn't really fit within > the new GSoC timeframe. While it's certainly possible that there will be > projects that come up in the future which do fit into this new timeline, > we think it'd be a good idea to step up our involvement again with > Outreachy where the program is a good bit more flexible then GSoC. We've > also had pretty good experience working with the Outreachy candidates > we've had in the past. > > The other main topic of discussion is around the fact that our own > program, EVoC, hasn't really had anyone available to volunteer to help > run it for a while now. For those who aren't aware, EVoC is a program > similar to Google Summer of Code that X.org started running with much > more relaxed requirements then GSoC/Outreachy in order to help fill the > gaps for any exceptional cases with students who would otherwise be left > out by the requirements for GSoC/Outreachy. Typically though, EVoC is > usually considered the last resort after a student has tried getting > into GSoC/Outreachy. > > So, the two biggest things that we need are: > * Admin volunteer(s) > * Mentors, mentors, mentors! We really need these the most. > > So, what responsibilities would being an admin for this entail? > > * Fielding questions from potential GSoC/EVoC/Outreachy participants. > Most of these students are just looking for simple details of how > these programs work and are looking for project ideas. Responding to > these inquiries is mostly just a matter of pointing students to > various pages on our wiki or replying with form/stock replies. Most of > the students at this phase expect to be handed a project and a mentor, > and therefore end up learning that they will need to come up with > their own project and mentor. > * For the small handful of students that make it to the next phase and > figure out a project idea, they then need to find a mentor. Usually > the admin will help out by taking a look at who proposed the project > idea, and/or looking through commit messages and mailing list history > to try to find someone who would be a good fit and willing to mentor > the student. Sometimes this happens quickly, and sometimes it requires > poking a lot of people - and occasionally, there might not always be a > mentor to be found. > * If we have a student, project, and mentor then the next step is having > the student write
Re: [PATCH] drm/amd/pm: Fix a memory leak in an error handling path in 'vangogh_tables_init()'
Applied. Thanks!
Alex
On Thu, Aug 5, 2021 at 2:44 PM Christophe JAILLET
wrote:
>
> 'watermarks_table' must be freed instead 'clocks_table', because
> 'clocks_table' is known to be NULL at this point and 'watermarks_table' is
> never freed if the last kzalloc fails.
>
> Fixes: c98ee89736b8 ("drm/amd/pm: add the fine grain tuning function for
> vangogh")
> Signed-off-by: Christophe JAILLET
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 335b3c70e1a7..06eea917284e 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -256,7 +256,7 @@ static int vangogh_tables_init(struct smu_context *smu)
> return 0;
>
> err3_out:
> - kfree(smu_table->clocks_table);
> + kfree(smu_table->watermarks_table);
> err2_out:
> kfree(smu_table->gpu_metrics_table);
> err1_out:
> --
> 2.30.2
>
Re: [PATCH] DRM: gpu: radeon: Fixed coding style issues
Applied. Thanks!
Alex
On Thu, Aug 5, 2021 at 8:33 AM Christian König
wrote:
>
> Am 04.08.21 um 13:20 schrieb Sergio Miguéns Iglesias:
> > Fixed braces, an unnecessary if statement and added a missing space.
> >
> > Signed-off-by: Sergio Miguéns Iglesias
>
> Normally we see patches which just fixes coding style as unnecessary
> churn, but the "if (rbo) {}" is really ugly here.
>
> So Reviewed-by: Christian König .
>
> Thanks,
> Christian.
>
> > ---
> > drivers/gpu/drm/radeon/radeon_fb.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
> > b/drivers/gpu/drm/radeon/radeon_fb.c
> > index 0b206b052972..6640b7c947fe 100644
> > --- a/drivers/gpu/drm/radeon/radeon_fb.c
> > +++ b/drivers/gpu/drm/radeon/radeon_fb.c
> > @@ -54,6 +54,7 @@ radeonfb_open(struct fb_info *info, int user)
> > struct radeon_fbdev *rfbdev = info->par;
> > struct radeon_device *rdev = rfbdev->rdev;
> > int ret = pm_runtime_get_sync(rdev->ddev->dev);
> > +
> > if (ret < 0 && ret != -EACCES) {
> > pm_runtime_mark_last_busy(rdev->ddev->dev);
> > pm_runtime_put_autosuspend(rdev->ddev->dev);
> > @@ -196,9 +197,8 @@ static int radeonfb_create_pinned_object(struct
> > radeon_fbdev *rfbdev,
> > radeon_bo_check_tiling(rbo, 0, 0);
> > ret = radeon_bo_kmap(rbo, NULL);
> > radeon_bo_unreserve(rbo);
> > - if (ret) {
> > + if (ret)
> > goto out_unref;
> > - }
> >
> > *gobj_p = gobj;
> > return 0;
> > @@ -294,9 +294,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
> > return 0;
> >
> > out:
> > - if (rbo) {
> > -
> > - }
> > if (fb && ret) {
> > drm_gem_object_put(gobj);
> > drm_framebuffer_unregister_private(fb);
>
Re: [PATCH v3] drm/radeon: Update pitch for page flip
On Thu, Aug 5, 2021 at 6:46 AM Zhenneng Li wrote:
>
>
> When primary bo is updated, crtc's pitch may
> have not been updated, this will lead to show
> disorder content when user changes display mode,
> we update crtc's pitch in page flip to avoid
> this bug.
> This refers to amdgpu's pageflip.
>
> v1->v2:
> Update all of the pitch in all of the page_flip functions
> in radeon rather than just the evergreen one.
>
> v2->v3:
> Update pitch set method for r100 according to
> radeon_legacy_crtc.c
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Zhenneng Li
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/evergreen.c | 8 +++-
> drivers/gpu/drm/radeon/r100.c | 9 +
> drivers/gpu/drm/radeon/rs600.c | 8 +++-
> drivers/gpu/drm/radeon/rv770.c | 8 +++-
> 4 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 36a888e1b179..eeb590d2dec2 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -28,6 +28,7 @@
>
> #include
> #include
> +#include
>
> #include "atom.h"
> #include "avivod.h"
> @@ -1414,10 +1415,15 @@ void evergreen_page_flip(struct radeon_device *rdev,
> int crtc_id, u64 crtc_base,
> bool async)
> {
> struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
> + struct drm_framebuffer *fb = radeon_crtc->base.primary->fb;
>
> - /* update the scanout addresses */
> + /* flip at hsync for async, default is vsync */
> WREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset,
>async ? EVERGREEN_GRPH_SURFACE_UPDATE_H_RETRACE_EN : 0);
> + /* update pitch */
> + WREG32(EVERGREEN_GRPH_PITCH + radeon_crtc->crtc_offset,
> + fb->pitches[0] / fb->format->cpp[0]);
> + /* update the scanout addresses */
> WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
> radeon_crtc->crtc_offset,
>upper_32_bits(crtc_base));
> WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS +
> radeon_crtc->crtc_offset,
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index ba724198b72e..2dd85ba1faa2 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -162,6 +162,8 @@ void r100_wait_for_vblank(struct radeon_device *rdev, int
> crtc)
> void r100_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base,
> bool async)
> {
> struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
> + uint32_t crtc_pitch, pitch_pixels;
> + struct drm_framebuffer *fb = radeon_crtc->base.primary->fb;
> u32 tmp = ((u32)crtc_base) | RADEON_CRTC_OFFSET__OFFSET_LOCK;
> int i;
>
> @@ -169,6 +171,13 @@ void r100_page_flip(struct radeon_device *rdev, int
> crtc_id, u64 crtc_base, bool
> /* update the scanout addresses */
> WREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset, tmp);
>
> + /* update pitch */
> + pitch_pixels = fb->pitches[0] / fb->format->cpp[0];
> + crtc_pitch = DIV_ROUND_UP(pitch_pixels * fb->format->cpp[0] * 8,
> + fb->format->cpp[0] * 8 * 8);
> + crtc_pitch |= crtc_pitch << 16;
> + WREG32(RADEON_CRTC_PITCH + radeon_crtc->crtc_offset, crtc_pitch);
> +
> /* Wait for update_pending to go high. */
> for (i = 0; i < rdev->usec_timeout; i++) {
> if (RREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset) &
> RADEON_CRTC_OFFSET__GUI_TRIG_OFFSET)
> diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
> index b2d22e25eee1..b87dd551e939 100644
> --- a/drivers/gpu/drm/radeon/rs600.c
> +++ b/drivers/gpu/drm/radeon/rs600.c
> @@ -41,6 +41,7 @@
>
> #include
> #include
> +#include
>
> #include "atom.h"
> #include "radeon.h"
> @@ -118,6 +119,7 @@ void avivo_wait_for_vblank(struct radeon_device *rdev,
> int crtc)
> void rs600_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base,
> bool async)
> {
> struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
> + struct drm_framebuffer *fb = radeon_crtc->base.primary->fb;
> u32 tmp = RREG32(AVIVO_D1GRPH_UPDATE + radeon_crtc->crtc_offset);
> int i;
>
> @@ -125,9 +127,13 @@ void rs600_page_flip(struct radeon_device *rdev, int
> crtc_id, u64 crtc_base, boo
> tmp |= AVIVO_D1GRPH_UPDATE_LOCK;
> WREG32(AVIVO_D1GRPH_UPDATE + radeon_crtc->crtc_offset, tmp);
>
> - /* update the scanout addresses */
> + /* flip at hsync for async, default is vsync */
> WREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset,
>async ?
[PATCH] drm/amd/pm: Fix a memory leak in an error handling path in 'vangogh_tables_init()'
'watermarks_table' must be freed instead 'clocks_table', because
'clocks_table' is known to be NULL at this point and 'watermarks_table' is
never freed if the last kzalloc fails.
Fixes: c98ee89736b8 ("drm/amd/pm: add the fine grain tuning function for
vangogh")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
index 335b3c70e1a7..06eea917284e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
@@ -256,7 +256,7 @@ static int vangogh_tables_init(struct smu_context *smu)
return 0;
err3_out:
- kfree(smu_table->clocks_table);
+ kfree(smu_table->watermarks_table);
err2_out:
kfree(smu_table->gpu_metrics_table);
err1_out:
--
2.30.2
Re: [git pull] drm fixes for 5.14-rc4
This might possibly have been fixed already by the previous drm pull, but I wanted to report it anyway, just in case. It happened after an uptime of over a week, so it might not be trivial to reproduce. It's a NULL pointer dereference in dc_stream_retain() with the code being lock xadd %eax,0x390(%rdi) <-- trapping instruction and that's just the kref_get(>refcount); with a NULL 'stream' argument. Call Trace: dc_resource_state_copy_construct+0x13f/0x190 [amdgpu] amdgpu_dm_atomic_commit_tail+0xd5/0x1540 [amdgpu] commit_tail+0x97/0x180 [drm_kms_helper] process_one_work+0x1df/0x3a0 the oops is followed by a stream of [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:55:crtc-1] hw_done or flip_done timed out and the machine was not usable afterwards. lspci says this is a 49:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev e7) (prog-if 00 [VGA controller]) Full oops in the attachment, but I think the above is all the really salient details. Linus amd-gpu-ooops Description: Binary data
Re: [git pull] drm fixes for 5.14-rc4
On Thu, Aug 5, 2021 at 2:14 PM Linus Torvalds wrote: > > This might possibly have been fixed already by the previous drm pull, > but I wanted to report it anyway, just in case. > > It happened after an uptime of over a week, so it might not be trivial > to reproduce. > > It's a NULL pointer dereference in dc_stream_retain() with the code being > > lock xadd %eax,0x390(%rdi) <-- trapping instruction > > and that's just the > > kref_get(>refcount); > > with a NULL 'stream' argument. > > Call Trace: >dc_resource_state_copy_construct+0x13f/0x190 [amdgpu] >amdgpu_dm_atomic_commit_tail+0xd5/0x1540 [amdgpu] >commit_tail+0x97/0x180 [drm_kms_helper] >process_one_work+0x1df/0x3a0 > > the oops is followed by a stream of > > [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:55:crtc-1] > hw_done or flip_done timed out > > and the machine was not usable afterwards. > > lspci says this is a > > 49:00.0 VGA compatible controller [0300]: >Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere >[Radeon RX 470/480/570/570X/580/580X/590] >[1002:67df] (rev e7) (prog-if 00 [VGA controller]) > > Full oops in the attachment, but I think the above is all the really > salient details. Thanks for the report. Adding some display folks to take a look. Alex
[PATCH v3] drm/radeon: Update pitch for page flip
When primary bo is updated, crtc's pitch may
have not been updated, this will lead to show
disorder content when user changes display mode,
we update crtc's pitch in page flip to avoid
this bug.
This refers to amdgpu's pageflip.
v1->v2:
Update all of the pitch in all of the page_flip functions
in radeon rather than just the evergreen one.
v2->v3:
Update pitch set method for r100 according to
radeon_legacy_crtc.c
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/radeon/evergreen.c | 8 +++-
drivers/gpu/drm/radeon/r100.c | 9 +
drivers/gpu/drm/radeon/rs600.c | 8 +++-
drivers/gpu/drm/radeon/rv770.c | 8 +++-
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 36a888e1b179..eeb590d2dec2 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include "atom.h"
#include "avivod.h"
@@ -1414,10 +1415,15 @@ void evergreen_page_flip(struct radeon_device *rdev,
int crtc_id, u64 crtc_base,
bool async)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
+ struct drm_framebuffer *fb = radeon_crtc->base.primary->fb;
- /* update the scanout addresses */
+ /* flip at hsync for async, default is vsync */
WREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset,
async ? EVERGREEN_GRPH_SURFACE_UPDATE_H_RETRACE_EN : 0);
+ /* update pitch */
+ WREG32(EVERGREEN_GRPH_PITCH + radeon_crtc->crtc_offset,
+ fb->pitches[0] / fb->format->cpp[0]);
+ /* update the scanout addresses */
WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
radeon_crtc->crtc_offset,
upper_32_bits(crtc_base));
WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS +
radeon_crtc->crtc_offset,
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index ba724198b72e..2dd85ba1faa2 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -162,6 +162,8 @@ void r100_wait_for_vblank(struct radeon_device *rdev, int
crtc)
void r100_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base,
bool async)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
+ uint32_t crtc_pitch, pitch_pixels;
+ struct drm_framebuffer *fb = radeon_crtc->base.primary->fb;
u32 tmp = ((u32)crtc_base) | RADEON_CRTC_OFFSET__OFFSET_LOCK;
int i;
@@ -169,6 +171,13 @@ void r100_page_flip(struct radeon_device *rdev, int
crtc_id, u64 crtc_base, bool
/* update the scanout addresses */
WREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset, tmp);
+ /* update pitch */
+ pitch_pixels = fb->pitches[0] / fb->format->cpp[0];
+ crtc_pitch = DIV_ROUND_UP(pitch_pixels * fb->format->cpp[0] * 8,
+ fb->format->cpp[0] * 8 * 8);
+ crtc_pitch |= crtc_pitch << 16;
+ WREG32(RADEON_CRTC_PITCH + radeon_crtc->crtc_offset, crtc_pitch);
+
/* Wait for update_pending to go high. */
for (i = 0; i < rdev->usec_timeout; i++) {
if (RREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset) &
RADEON_CRTC_OFFSET__GUI_TRIG_OFFSET)
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index b2d22e25eee1..b87dd551e939 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -41,6 +41,7 @@
#include
#include
+#include
#include "atom.h"
#include "radeon.h"
@@ -118,6 +119,7 @@ void avivo_wait_for_vblank(struct radeon_device *rdev, int
crtc)
void rs600_page_flip(struct radeon_device *rdev, int crtc_id, u64 crtc_base,
bool async)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
+ struct drm_framebuffer *fb = radeon_crtc->base.primary->fb;
u32 tmp = RREG32(AVIVO_D1GRPH_UPDATE + radeon_crtc->crtc_offset);
int i;
@@ -125,9 +127,13 @@ void rs600_page_flip(struct radeon_device *rdev, int
crtc_id, u64 crtc_base, boo
tmp |= AVIVO_D1GRPH_UPDATE_LOCK;
WREG32(AVIVO_D1GRPH_UPDATE + radeon_crtc->crtc_offset, tmp);
- /* update the scanout addresses */
+ /* flip at hsync for async, default is vsync */
WREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset,
async ? AVIVO_D1GRPH_SURFACE_UPDATE_H_RETRACE_EN : 0);
+ /* update pitch */
+ WREG32(AVIVO_D1GRPH_PITCH + radeon_crtc->crtc_offset,
+ fb->pitches[0] / fb->format->cpp[0]);
+ /* update the scanout addresses */
WREG32(AVIVO_D1GRPH_SECONDARY_SURFACE_ADDRESS +
radeon_crtc->crtc_offset,
(u32)crtc_base);
Re: [PATCH] drm/amdkfd: Expose GFXIP engine version to sysfs
Am 2021-08-04 um 2:17 p.m. schrieb Graham Sider:
> Add u32 gfx_version field to kfd_node_properties and kfd_device_info.
Update this description with the new property name. With that fixed, the
patch is
Reviewed-by: Felix Kuehling
> Populate _device_info structs accordingly and expose to sysfs.
>
> This allows eliminating device-ID-based lookup tables in user mode for
> future ASICs.
>
> Signed-off-by: Graham Sider
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 29 +++
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 +
> drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 +++
> drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 1 +
> 4 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index b551dd675085..16a57b70cc1a 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -91,6 +91,7 @@ static const struct kfd2kgd_calls *kfd2kgd_funcs[] = {
> static const struct kfd_device_info kaveri_device_info = {
> .asic_family = CHIP_KAVERI,
> .asic_name = "kaveri",
> + .gfx_target_version = 7,
> .max_pasid_bits = 16,
> /* max num of queues for KV.TODO should be a dynamic value */
> .max_no_of_hqd = 24,
> @@ -110,6 +111,7 @@ static const struct kfd_device_info kaveri_device_info = {
> static const struct kfd_device_info carrizo_device_info = {
> .asic_family = CHIP_CARRIZO,
> .asic_name = "carrizo",
> + .gfx_target_version = 80001,
> .max_pasid_bits = 16,
> /* max num of queues for CZ.TODO should be a dynamic value */
> .max_no_of_hqd = 24,
> @@ -130,6 +132,7 @@ static const struct kfd_device_info carrizo_device_info =
> {
> static const struct kfd_device_info raven_device_info = {
> .asic_family = CHIP_RAVEN,
> .asic_name = "raven",
> + .gfx_target_version = 90002,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 8,
> @@ -148,6 +151,7 @@ static const struct kfd_device_info raven_device_info = {
> static const struct kfd_device_info hawaii_device_info = {
> .asic_family = CHIP_HAWAII,
> .asic_name = "hawaii",
> + .gfx_target_version = 70001,
> .max_pasid_bits = 16,
> /* max num of queues for KV.TODO should be a dynamic value */
> .max_no_of_hqd = 24,
> @@ -167,6 +171,7 @@ static const struct kfd_device_info hawaii_device_info = {
> static const struct kfd_device_info tonga_device_info = {
> .asic_family = CHIP_TONGA,
> .asic_name = "tonga",
> + .gfx_target_version = 80002,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 4,
> @@ -185,6 +190,7 @@ static const struct kfd_device_info tonga_device_info = {
> static const struct kfd_device_info fiji_device_info = {
> .asic_family = CHIP_FIJI,
> .asic_name = "fiji",
> + .gfx_target_version = 80003,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 4,
> @@ -203,6 +209,7 @@ static const struct kfd_device_info fiji_device_info = {
> static const struct kfd_device_info fiji_vf_device_info = {
> .asic_family = CHIP_FIJI,
> .asic_name = "fiji",
> + .gfx_target_version = 80003,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 4,
> @@ -222,6 +229,7 @@ static const struct kfd_device_info fiji_vf_device_info =
> {
> static const struct kfd_device_info polaris10_device_info = {
> .asic_family = CHIP_POLARIS10,
> .asic_name = "polaris10",
> + .gfx_target_version = 80003,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 4,
> @@ -240,6 +248,7 @@ static const struct kfd_device_info polaris10_device_info
> = {
> static const struct kfd_device_info polaris10_vf_device_info = {
> .asic_family = CHIP_POLARIS10,
> .asic_name = "polaris10",
> + .gfx_target_version = 80003,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 4,
> @@ -258,6 +267,7 @@ static const struct kfd_device_info
> polaris10_vf_device_info = {
> static const struct kfd_device_info polaris11_device_info = {
> .asic_family = CHIP_POLARIS11,
> .asic_name = "polaris11",
> + .gfx_target_version = 80003,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 4,
> @@ -276,6 +286,7 @@ static const struct kfd_device_info polaris11_device_info
> = {
> static const struct kfd_device_info polaris12_device_info = {
> .asic_family = CHIP_POLARIS12,
> .asic_name = "polaris12",
> + .gfx_target_version = 80003,
> .max_pasid_bits = 16,
> .max_no_of_hqd = 24,
> .doorbell_size = 4,
> @@ -294,6 +305,7 @@ static const struct kfd_device_info polaris12_device_info
> = {
> static const struct kfd_device_info vegam_device_info = {
> .asic_family = CHIP_VEGAM,
>
Re: [PATCH] drm/amdgpu: set default noretry=1 to fix kfd SVM issues for raven
Am 2021-08-05 um 4:51 a.m. schrieb Zhu, Changfeng:
> [AMD Official Use Only]
>
> Hi Felix,
>
> Can we set noretry=1 for dgpu path(ignore_crat=1) which doesn’t to through
> iommuv2 path on raven as below:
There are other possible reasons than ignore_crat for Raven to work in
dGPU mode (broken CRAT, disabled IOMMU). However, those are not known
until later in the initialization.
Regards,
Felix
>> +case CHIP_RAVEN:
>> +/*
>> + * TODO: Raven currently can fix most SVM issues with
>> + * noretry =1. However it has two issues with noretry = 1
>> + * on kfd migrate tests. It still needs to root causes
>> + * with these two migrate fails on raven with noretry = 1.
>> + */
>> if (amdgpu_noretry == -1) {
>> If(ignore_crat)
>> gmc->noretry = 1;
>> else
>> gmc->noretry = 0;
>> }
>> else
>> gmc->noretry = amdgpu_noretry;
>> break;
> BR,
> Changfeng.
>
> -Original Message-
> From: Kuehling, Felix
> Sent: Wednesday, July 28, 2021 10:22 PM
> To: Zhu, Changfeng ; amd-gfx@lists.freedesktop.org;
> Huang, Ray ; Zhang, Yifan
> Subject: Re: [PATCH] drm/amdgpu: set default noretry=1 to fix kfd SVM issues
> for raven
>
> Doesn't this break IOMMUv2? Applications that run using IOMMUv2 for system
> memory access depend on correct retry handling in the SQ.
> Therefore noretry must be 0 on Raven.
>
> I believe the reason that SVM has trouble with retry enabled is, that
> IOMMUv2 is catching the page faults, so the driver never gets to handle the
> page fault interrupts. That breaks page-fault based migration in the SVM
> code. I think the better solution is to disable SVM on APUs where
> IOMMUv2 is enabled.
>
> Alternatively, we could give up on IOMMUv2 entirely and always rely on SVM to
> provide that functionality. But that requires more changes in the amdgpu_vm
> code.
>
> Regards,
> Felix
>
>
> Am 2021-07-28 um 2:36 a.m. schrieb Changfeng:
>> From: changzhu
>>
>> From: Changfeng
>>
>> It can't find any issues with noretry=1 except two SVM migrate issues.
>> Oppositely, it will cause most SVM cases fail with noretry=0.
>> The two SVM migrate issues also happen with noretry=0. So it can set
>> default noretry=1 for raven firstly to fix most SVM fails.
>>
>> Change-Id: Idb5cb3c1a04104013e4ab8aed2ad4751aaec4bbc
>> Signed-off-by: Changfeng
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 15 ---
>> 1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>> index 09edfb64cce0..d7f69dbd48e6 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>> @@ -606,19 +606,20 @@ void amdgpu_gmc_noretry_set(struct amdgpu_device *adev)
>> * noretry = 0 will cause kfd page fault tests fail
>> * for some ASICs, so set default to 1 for these ASICs.
>> */
>> +case CHIP_RAVEN:
>> +/*
>> + * TODO: Raven currently can fix most SVM issues with
>> + * noretry =1. However it has two issues with noretry = 1
>> + * on kfd migrate tests. It still needs to root causes
>> + * with these two migrate fails on raven with noretry = 1.
>> + */
>> if (amdgpu_noretry == -1)
>> gmc->noretry = 1;
>> else
>> gmc->noretry = amdgpu_noretry;
>> break;
>> -case CHIP_RAVEN:
>> default:
>> -/* Raven currently has issues with noretry
>> - * regardless of what we decide for other
>> - * asics, we should leave raven with
>> - * noretry = 0 until we root cause the
>> - * issues.
>> - *
>> +/*
>> * default this to 0 for now, but we may want
>> * to change this in the future for certain
>> * GPUs as it can increase performance in
Re: [PATCH] drm/amd/amdgpu: skip locking delayed work if not initialized.
Am 05.08.21 um 04:37 schrieb YuBiao Wang:
When init failed in early init stage, amdgpu_object has
not been initialized, so hasn't the ttm delayed queue functions.
Signed-off-by: YuBiao Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9e53ff851496..4c33985542ed 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3825,7 +3825,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
{
dev_info(adev->dev, "amdgpu: finishing device.\n");
flush_delayed_work(>delayed_init_work);
- ttm_bo_lock_delayed_workqueue(>mman.bdev);
+ if (adev->mman.initialized)
+ ttm_bo_lock_delayed_workqueue(>mman.bdev);
I'm really wondering why we have that here in the first place.
This just disabled the delayed delete queue which is part of the sw
stack and not related to hardware in any way possible.
I think it would be much cleaner to move this into amdgpu_ttm_fini().
Christian.
adev->shutdown = true;
/* make sure IB test finished before entering exclusive mode
Re: [PATCH] DRM: gpu: radeon: Fixed coding style issues
Am 04.08.21 um 13:20 schrieb Sergio Miguéns Iglesias:
Fixed braces, an unnecessary if statement and added a missing space.
Signed-off-by: Sergio Miguéns Iglesias
Normally we see patches which just fixes coding style as unnecessary
churn, but the "if (rbo) {}" is really ugly here.
So Reviewed-by: Christian König .
Thanks,
Christian.
---
drivers/gpu/drm/radeon/radeon_fb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index 0b206b052972..6640b7c947fe 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -54,6 +54,7 @@ radeonfb_open(struct fb_info *info, int user)
struct radeon_fbdev *rfbdev = info->par;
struct radeon_device *rdev = rfbdev->rdev;
int ret = pm_runtime_get_sync(rdev->ddev->dev);
+
if (ret < 0 && ret != -EACCES) {
pm_runtime_mark_last_busy(rdev->ddev->dev);
pm_runtime_put_autosuspend(rdev->ddev->dev);
@@ -196,9 +197,8 @@ static int radeonfb_create_pinned_object(struct
radeon_fbdev *rfbdev,
radeon_bo_check_tiling(rbo, 0, 0);
ret = radeon_bo_kmap(rbo, NULL);
radeon_bo_unreserve(rbo);
- if (ret) {
+ if (ret)
goto out_unref;
- }
*gobj_p = gobj;
return 0;
@@ -294,9 +294,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
return 0;
out:
- if (rbo) {
-
- }
if (fb && ret) {
drm_gem_object_put(gobj);
drm_framebuffer_unregister_private(fb);
Re: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
Navi12 is swsmu based. Suggest you to check the implementation of below
sys nodes and decide what you want to do. Not able to figure out how it
worked for you, did you really try this on any 1VF system?
+ AMDGPU_DEVICE_ATTR_RO(pp_num_states,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RW(pp_force_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
Thanks,
Lijo
On 8/5/2021 2:48 PM, Gu, JiaWei (Will) wrote:
[AMD Official Use Only]
Hi Lijo,
It's for Navi12 asic as far as I know.
Best regards,
Jiawei
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 5, 2021 5:08 PM
To: Gu, JiaWei (Will) ; amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily ; Deucher,
Alexander
Subject: Re: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
On 8/5/2021 12:01 PM, Gu, JiaWei (Will) wrote:
[AMD Official Use Only]
Ping.
-Original Message-
From: Gu, JiaWei (Will)
Sent: Wednesday, August 4, 2021 4:08 PM
To: Gu, JiaWei (Will) ;
amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily
; Deucher, Alexander
Subject: RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF
mode
[AMD Official Use Only]
Add Alex.
-Original Message-
From: Jiawei Gu
Sent: Wednesday, August 4, 2021 3:50 PM
To: amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily
; Gu, JiaWei (Will)
Subject: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF
mode
Enable pp_num_states, pp_cur_state, pp_force_state, pp_table sysfs under SRIOV
1-VF scenario.
Signed-off-by: Jiawei Gu
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 769f58d5ae1a..04c7d82f8b89 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -2005,10 +2005,10 @@ static int ss_bias_attr_update(struct amdgpu_device
*adev, struct amdgpu_device_ static struct amdgpu_device_attr
amdgpu_device_attrs[] = {
AMDGPU_DEVICE_ATTR_RW(power_dpm_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(power_dpm_force_performance_level,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
- AMDGPU_DEVICE_ATTR_RO(pp_num_states,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RW(pp_force_state,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RW(pp_table,
ATTR_FLAG_BASIC),
+ AMDGPU_DEVICE_ATTR_RO(pp_num_states,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RW(pp_force_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
Which ASIC is this for? As far as I see from the current implementation, power
state is not supported in swsmu projects.
Thanks,
Lijo
+ AMDGPU_DEVICE_ATTR_RW(pp_table,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF) > AMDGPU_DEVICE_ATTR_RW(pp_dpm_sclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(pp_dpm_mclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(pp_dpm_socclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
--
2.17.1
RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
[AMD Official Use Only]
Hi Lijo,
It's for Navi12 asic as far as I know.
Best regards,
Jiawei
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 5, 2021 5:08 PM
To: Gu, JiaWei (Will) ; amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily ;
Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
On 8/5/2021 12:01 PM, Gu, JiaWei (Will) wrote:
> [AMD Official Use Only]
>
> Ping.
>
> -Original Message-
> From: Gu, JiaWei (Will)
> Sent: Wednesday, August 4, 2021 4:08 PM
> To: Gu, JiaWei (Will) ;
> amd-gfx@lists.freedesktop.org
> Cc: Nieto, David M ; Deng, Emily
> ; Deucher, Alexander
> Subject: RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF
> mode
>
> [AMD Official Use Only]
>
> Add Alex.
>
> -Original Message-
> From: Jiawei Gu
> Sent: Wednesday, August 4, 2021 3:50 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Nieto, David M ; Deng, Emily
> ; Gu, JiaWei (Will)
> Subject: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF
> mode
>
> Enable pp_num_states, pp_cur_state, pp_force_state, pp_table sysfs under
> SRIOV 1-VF scenario.
>
> Signed-off-by: Jiawei Gu
> ---
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index 769f58d5ae1a..04c7d82f8b89 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -2005,10 +2005,10 @@ static int ss_bias_attr_update(struct amdgpu_device
> *adev, struct amdgpu_device_ static struct amdgpu_device_attr
> amdgpu_device_attrs[] = {
> AMDGPU_DEVICE_ATTR_RW(power_dpm_state,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> AMDGPU_DEVICE_ATTR_RW(power_dpm_force_performance_level,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> - AMDGPU_DEVICE_ATTR_RO(pp_num_states,
> ATTR_FLAG_BASIC),
> - AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
> ATTR_FLAG_BASIC),
> - AMDGPU_DEVICE_ATTR_RW(pp_force_state,
> ATTR_FLAG_BASIC),
> - AMDGPU_DEVICE_ATTR_RW(pp_table,
> ATTR_FLAG_BASIC),
> + AMDGPU_DEVICE_ATTR_RO(pp_num_states,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> + AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> + AMDGPU_DEVICE_ATTR_RW(pp_force_state,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
Which ASIC is this for? As far as I see from the current implementation, power
state is not supported in swsmu projects.
Thanks,
Lijo
> + AMDGPU_DEVICE_ATTR_RW(pp_table,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF) > AMDGPU_DEVICE_ATTR_RW(pp_dpm_sclk,
>
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> AMDGPU_DEVICE_ATTR_RW(pp_dpm_mclk,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> AMDGPU_DEVICE_ATTR_RW(pp_dpm_socclk,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> --
> 2.17.1
>
Re: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
On 8/5/2021 12:01 PM, Gu, JiaWei (Will) wrote:
[AMD Official Use Only]
Ping.
-Original Message-
From: Gu, JiaWei (Will)
Sent: Wednesday, August 4, 2021 4:08 PM
To: Gu, JiaWei (Will) ; amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily ; Deucher,
Alexander
Subject: RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
[AMD Official Use Only]
Add Alex.
-Original Message-
From: Jiawei Gu
Sent: Wednesday, August 4, 2021 3:50 PM
To: amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily ; Gu,
JiaWei (Will)
Subject: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
Enable pp_num_states, pp_cur_state, pp_force_state, pp_table sysfs under SRIOV
1-VF scenario.
Signed-off-by: Jiawei Gu
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 769f58d5ae1a..04c7d82f8b89 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -2005,10 +2005,10 @@ static int ss_bias_attr_update(struct amdgpu_device
*adev, struct amdgpu_device_ static struct amdgpu_device_attr
amdgpu_device_attrs[] = {
AMDGPU_DEVICE_ATTR_RW(power_dpm_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(power_dpm_force_performance_level,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
- AMDGPU_DEVICE_ATTR_RO(pp_num_states,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RW(pp_force_state,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RW(pp_table,
ATTR_FLAG_BASIC),
+ AMDGPU_DEVICE_ATTR_RO(pp_num_states,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RW(pp_force_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
Which ASIC is this for? As far as I see from the current implementation,
power state is not supported in swsmu projects.
Thanks,
Lijo
+ AMDGPU_DEVICE_ATTR_RW(pp_table, ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF) > AMDGPU_DEVICE_ATTR_RW(pp_dpm_sclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(pp_dpm_mclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(pp_dpm_socclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
--
2.17.1
RE: [PATCH] drm/amdgpu: set default noretry=1 to fix kfd SVM issues for raven
[AMD Official Use Only]
Hi Felix,
Can we set noretry=1 for dgpu path(ignore_crat=1) which doesn’t to through
iommuv2 path on raven as below:
> + case CHIP_RAVEN:
> + /*
> + * TODO: Raven currently can fix most SVM issues with
> + * noretry =1. However it has two issues with noretry = 1
> + * on kfd migrate tests. It still needs to root causes
> + * with these two migrate fails on raven with noretry = 1.
> + */
> if (amdgpu_noretry == -1) {
> If(ignore_crat)
> gmc->noretry = 1;
> else
> gmc->noretry = 0;
> }
> else
> gmc->noretry = amdgpu_noretry;
> break;
BR,
Changfeng.
-Original Message-
From: Kuehling, Felix
Sent: Wednesday, July 28, 2021 10:22 PM
To: Zhu, Changfeng ; amd-gfx@lists.freedesktop.org;
Huang, Ray ; Zhang, Yifan
Subject: Re: [PATCH] drm/amdgpu: set default noretry=1 to fix kfd SVM issues
for raven
Doesn't this break IOMMUv2? Applications that run using IOMMUv2 for system
memory access depend on correct retry handling in the SQ.
Therefore noretry must be 0 on Raven.
I believe the reason that SVM has trouble with retry enabled is, that
IOMMUv2 is catching the page faults, so the driver never gets to handle the
page fault interrupts. That breaks page-fault based migration in the SVM code.
I think the better solution is to disable SVM on APUs where
IOMMUv2 is enabled.
Alternatively, we could give up on IOMMUv2 entirely and always rely on SVM to
provide that functionality. But that requires more changes in the amdgpu_vm
code.
Regards,
Felix
Am 2021-07-28 um 2:36 a.m. schrieb Changfeng:
> From: changzhu
>
> From: Changfeng
>
> It can't find any issues with noretry=1 except two SVM migrate issues.
> Oppositely, it will cause most SVM cases fail with noretry=0.
> The two SVM migrate issues also happen with noretry=0. So it can set
> default noretry=1 for raven firstly to fix most SVM fails.
>
> Change-Id: Idb5cb3c1a04104013e4ab8aed2ad4751aaec4bbc
> Signed-off-by: Changfeng
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 09edfb64cce0..d7f69dbd48e6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -606,19 +606,20 @@ void amdgpu_gmc_noretry_set(struct amdgpu_device *adev)
>* noretry = 0 will cause kfd page fault tests fail
>* for some ASICs, so set default to 1 for these ASICs.
>*/
> + case CHIP_RAVEN:
> + /*
> + * TODO: Raven currently can fix most SVM issues with
> + * noretry =1. However it has two issues with noretry = 1
> + * on kfd migrate tests. It still needs to root causes
> + * with these two migrate fails on raven with noretry = 1.
> + */
> if (amdgpu_noretry == -1)
> gmc->noretry = 1;
> else
> gmc->noretry = amdgpu_noretry;
> break;
> - case CHIP_RAVEN:
> default:
> - /* Raven currently has issues with noretry
> - * regardless of what we decide for other
> - * asics, we should leave raven with
> - * noretry = 0 until we root cause the
> - * issues.
> - *
> + /*
>* default this to 0 for now, but we may want
>* to change this in the future for certain
>* GPUs as it can increase performance in
RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
Acked-by: Emily.Deng
>-Original Message-
>From: Gu, JiaWei (Will)
>Sent: Thursday, August 5, 2021 2:32 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Nieto, David M ; Deng, Emily
>; Deucher, Alexander
>
>Subject: RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF
>mode
>
>[AMD Official Use Only]
>
>Ping.
>
>-Original Message-
>From: Gu, JiaWei (Will)
>Sent: Wednesday, August 4, 2021 4:08 PM
>To: Gu, JiaWei (Will) ; amd-gfx@lists.freedesktop.org
>Cc: Nieto, David M ; Deng, Emily
>; Deucher, Alexander
>
>Subject: RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF
>mode
>
>[AMD Official Use Only]
>
>Add Alex.
>
>-Original Message-
>From: Jiawei Gu
>Sent: Wednesday, August 4, 2021 3:50 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Nieto, David M ; Deng, Emily
>; Gu, JiaWei (Will)
>Subject: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF
>mode
>
>Enable pp_num_states, pp_cur_state, pp_force_state, pp_table sysfs under
>SRIOV 1-VF scenario.
>
>Signed-off-by: Jiawei Gu
>---
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
>b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
>index 769f58d5ae1a..04c7d82f8b89 100644
>--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
>+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
>@@ -2005,10 +2005,10 @@ static int ss_bias_attr_update(struct
>amdgpu_device *adev, struct amdgpu_device_ static struct
>amdgpu_device_attr amdgpu_device_attrs[] = {
> AMDGPU_DEVICE_ATTR_RW(power_dpm_state,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> AMDGPU_DEVICE_ATTR_RW(power_dpm_force_performance_level,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>- AMDGPU_DEVICE_ATTR_RO(pp_num_states,
> ATTR_FLAG_BASIC),
>- AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
> ATTR_FLAG_BASIC),
>- AMDGPU_DEVICE_ATTR_RW(pp_force_state,
> ATTR_FLAG_BASIC),
>- AMDGPU_DEVICE_ATTR_RW(pp_table,
> ATTR_FLAG_BASIC),
>+ AMDGPU_DEVICE_ATTR_RO(pp_num_states,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>+ AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>+ AMDGPU_DEVICE_ATTR_RW(pp_force_state,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>+ AMDGPU_DEVICE_ATTR_RW(pp_table,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> AMDGPU_DEVICE_ATTR_RW(pp_dpm_sclk,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> AMDGPU_DEVICE_ATTR_RW(pp_dpm_mclk,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> AMDGPU_DEVICE_ATTR_RW(pp_dpm_socclk,
> ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>--
>2.17.1
[PATCHv2 2/2] drm/amd/amdgpu: add tdr support for embeded hw_fence
[Why]
After embeded hw_fence to amdgpu_job, we need to add tdr support
for this feature.
[How]
1. Add a resubmit_flag for resubmit jobs.
2. Clear job fence from RCU and force complete vm flush fences in
pre_asic_reset
3. skip dma_fence_get for resubmit jobs and add a dma_fence_put
for guilty jobs.
v2:
use a job_run_counter in amdgpu_job to replace the resubmit_flag in
drm_sched_job. When the job_run_counter >= 1, it means this job is a
resubmit job.
Signed-off-by: Jack Zhang
Signed-off-by: Jingwen Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h| 3 +++
4 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9e53ff851496..ade2fa07a50a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4447,7 +4447,7 @@ int amdgpu_device_mode1_reset(struct amdgpu_device *adev)
int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
struct amdgpu_reset_context *reset_context)
{
- int i, r = 0;
+ int i, j, r = 0;
struct amdgpu_job *job = NULL;
bool need_full_reset =
test_bit(AMDGPU_NEED_FULL_RESET, _context->flags);
@@ -4471,6 +4471,16 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device
*adev,
if (!ring || !ring->sched.thread)
continue;
+ /*clear job fence from fence drv to avoid force_completion
+*leave NULL and vm flush fence in fence drv */
+ for (j = 0; j <= ring->fence_drv.num_fences_mask; j ++) {
+ struct dma_fence *old,**ptr;
+ ptr = >fence_drv.fences[j];
+ old = rcu_dereference_protected(*ptr, 1);
+ if (old && test_bit(AMDGPU_FENCE_FLAG_EMBED_IN_JOB_BIT,
>flags)) {
+ RCU_INIT_POINTER(*ptr, NULL);
+ }
+ }
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 5e29d797a265..c9752cf794fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -159,10 +159,15 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct
dma_fence **f, struct amd
}
seq = ++ring->fence_drv.sync_seq;
- dma_fence_init(fence, _fence_ops,
- >fence_drv.lock,
- adev->fence_context + ring->idx,
- seq);
+ if (job != NULL && job->job_run_counter) {
+ /* reinit seq for resubmitted jobs */
+ fence->seqno = seq;
+ } else {
+ dma_fence_init(fence, _fence_ops,
+ >fence_drv.lock,
+ adev->fence_context + ring->idx,
+ seq);
+ }
if (job != NULL) {
/* mark this fence has a parent job */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 65a395060de2..19b13a65c73b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -254,6 +254,7 @@ static struct dma_fence *amdgpu_job_run(struct
drm_sched_job *sched_job)
dma_fence_set_error(finished, -ECANCELED);/* skip IB as well if
VRAM lost */
if (finished->error < 0) {
+ dma_fence_put(>hw_fence);
DRM_INFO("Skip scheduling IBs!\n");
} else {
r = amdgpu_ib_schedule(ring, job->num_ibs, job->ibs, job,
@@ -262,7 +263,9 @@ static struct dma_fence *amdgpu_job_run(struct
drm_sched_job *sched_job)
DRM_ERROR("Error scheduling IBs (%d)\n", r);
}
- dma_fence_get(fence);
+ if (!job->job_run_counter)
+ dma_fence_get(fence);
+ job->job_run_counter ++;
amdgpu_job_free_resources(job);
fence = r ? ERR_PTR(r) : fence;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
index 92324c978534..1fa667f245e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
@@ -64,6 +64,9 @@ struct amdgpu_job {
/* user fence handling */
uint64_tuf_addr;
uint64_tuf_sequence;
+
+ /* job_run_counter >= 1 means a resubmit job */
+ uint32_tjob_run_counter;
};
int amdgpu_job_alloc(struct amdgpu_device *adev, unsigned num_ibs,
--
2.25.1
[PATCHv2 1/2] drm/amd/amdgpu embed hw_fence into amdgpu_job
From: Jack Zhang
Why: Previously hw fence is alloced separately with job.
It caused historical lifetime issues and corner cases.
The ideal situation is to take fence to manage both job
and fence's lifetime, and simplify the design of gpu-scheduler.
How:
We propose to embed hw_fence into amdgpu_job.
1. We cover the normal job submission by this method.
2. For ib_test, and submit without a parent job keep the
legacy way to create a hw fence separately.
v2:
use AMDGPU_FENCE_FLAG_EMBED_IN_JOB_BIT to show that the fence is
embeded in a job.
Signed-off-by: Jingwen Chen
Signed-off-by: Jack Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 63 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 35
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h| 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
8 files changed, 84 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 7b46ba551cb2..3003ee1c9487 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -714,7 +714,6 @@ int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum
kgd_engine_type engine,
ret = dma_fence_wait(f, false);
err_ib_sched:
- dma_fence_put(f);
amdgpu_job_free(job);
err:
return ret;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 536005bff24a..277128846dd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1414,7 +1414,7 @@ static void amdgpu_ib_preempt_mark_partial_job(struct
amdgpu_ring *ring)
continue;
}
job = to_amdgpu_job(s_job);
- if (preempted && job->fence == fence)
+ if (preempted && (>hw_fence) == fence)
/* mark the job as preempted */
job->preemption_status |= AMDGPU_IB_PREEMPTED;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 7495911516c2..5e29d797a265 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -129,30 +129,46 @@ static u32 amdgpu_fence_read(struct amdgpu_ring *ring)
*
* @ring: ring the fence is associated with
* @f: resulting fence object
+ * @job: job the fence is embeded in
* @flags: flags to pass into the subordinate .emit_fence() call
*
* Emits a fence command on the requested ring (all asics).
* Returns 0 on success, -ENOMEM on failure.
*/
-int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f,
+int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f, struct
amdgpu_job *job,
unsigned flags)
{
struct amdgpu_device *adev = ring->adev;
- struct amdgpu_fence *fence;
+ struct dma_fence *fence;
+ struct amdgpu_fence *am_fence;
struct dma_fence __rcu **ptr;
uint32_t seq;
int r;
- fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL);
- if (fence == NULL)
- return -ENOMEM;
+ if (job == NULL) {
+ /* create a sperate hw fence */
+ am_fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC);
+ if (am_fence == NULL)
+ return -ENOMEM;
+ fence = _fence->base;
+ am_fence->ring = ring;
+ } else {
+ /* take use of job-embedded fence */
+ fence = >hw_fence;
+ job->ring = ring;
+ }
seq = ++ring->fence_drv.sync_seq;
- fence->ring = ring;
- dma_fence_init(>base, _fence_ops,
+ dma_fence_init(fence, _fence_ops,
>fence_drv.lock,
adev->fence_context + ring->idx,
seq);
+
+ if (job != NULL) {
+ /* mark this fence has a parent job */
+ set_bit(AMDGPU_FENCE_FLAG_EMBED_IN_JOB_BIT, >flags);
+ }
+
amdgpu_ring_emit_fence(ring, ring->fence_drv.gpu_addr,
seq, flags | AMDGPU_FENCE_FLAG_INT);
pm_runtime_get_noresume(adev_to_drm(adev)->dev);
@@ -175,9 +191,9 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct
dma_fence **f,
/* This function can't be called concurrently anyway, otherwise
* emitting the fence would mess up the hardware ring buffer.
*/
- rcu_assign_pointer(*ptr, dma_fence_get(>base));
+ rcu_assign_pointer(*ptr, dma_fence_get(fence));
- *f = >base;
+ *f = fence;
return 0;
}
@@ -621,8 +637,16 @@ static const
Re: Linux Mint 20.04 5.11 issue
When launching Chromium from a terminal window, I get the following output: 2606:2626:0804/084411.009101:ERROR:nss_util.cc(286)] After loading Root Certs, loaded==false: NSS error code: -8018mesa: for the --simplifycfg- sink-common option: may only occur zero or one times!mesa: for the -- global-isel-abort option: may only occur zero or one times!mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times!mesa: for the --structurizecfg-skip-uniform-regions option: may only occur zero or one times![2636:2636:0804/084411.912737:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu- process. I got the above after rebooting this morning after another Marco crash (https://termbin.com/xy80). Any insight into whether or not this is software, driver, or hardware issue is appreciated. Thanks,Tim On Fri, 2021-07-30 at 08:08 -0400, Tim Cahill wrote: > Posted the following comment to the Mate-desktop issue: > > Had > another hang with the same configuration as a youtube video played > via a > USB headphone (Jabra40). I was able to recover by killing Firefox, > in > which the video was playing. The video became choppy and garbled and > then stopped. The stderr is below: > > ALSA lib conf.c:5187:(snd_config_expand) Unknown parameters 1ALSA lib > control.c:1379:(snd_ctl_open_noupdate) Invalid CTL sysdefault:1ALSA > lib conf.c:5187:(snd_config_expand) Unknown parameters 2ALSA lib > control.c:1379:(snd_ctl_open_noupdate) Invalid CTL sysdefault:2ALSA > lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slaveALSA lib > pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slaveALSA lib > pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slaveALSA lib > pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slaveALSA lib > pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave > > On re-launch of Firefox from terminal window, the following appeared: > > [GFX1-]: More than 1 GPU from same vendor detected via PCI, cannot > deduce deviceOn Thu, 2021-07-29 at 12:04 -0400, Tim Cahill wrote: > > I apologize if the name callout is disconcerting. I was trying to > > follow instructions for sending bugs and saw your name listed as > > the owner of this code area. > > FYI, I'd done some more troubleshooting and tinkering regarding the > > crashing and Mate seems to be at the center of all the issues. As a > > result, I also opened an Issue with the Mate Desktop team ( > > https://github.com/mate-desktop/mate-panel/issues/1242). Mate also > > has a power management component, which is probably responsible for > > the excess logging and the confusion over Navil10. However, I have > > no way to vouch for now accurately the Mate PM applet gathered data > > for its instantiation. I have no external devices connected that > > I'm aware would use it since I thought that was via HDMI. I *do* > > have a Jabra Evolve2 headset that uses the TypeC USB connector, but > > I assume that's not using the GPU. > > The issue documentation I left with Mate notes that if I launch > > apps from a terminal that is NOT launched from the Mate panel > > (right-click on desktop instead to open terminal), the parent for > > all the apps (Firefox, Evolution, etc.) is separate from Mate (at > > least separate from mate-panel). Everything has worked fine (except > > for the constant logging of the wake-up action) since I've done > > that (and turned off the screensaver and screensaver lock). So, I'm > > not sure what else to do at this point. Please advise if I should > > do anything on the driver side. > > Thanks,Tim > > On Thu, 2021-07-29 at 11:14 -0400, Felix Kuehling wrote: > > > Am 2021-07-28 um 12:10 p.m. schrieb Tim Cahill: > > > > Hi Felix, > > > > > > I'm not sure why you're calling me out by name. I'm not working > > > onanything obviously related to your crashes. > > > Anyway, I took a quick look at the backtraces. They all point at > > > libgdk.Two of them are segfaults, one is an abort. It's not clear > > > how thesewould be related to the GPU driver. That said, when you > > > boot withnomodeset, the GPU driver and all HW acceleration is > > > completelydisabled. If that makes the problem disappear, the GPU > > > driver is clearlyinvolved in the problem in some way. > > > The abort points at a problem while freeing memory. This could be > > > causedby a double-free problem in some unrelated code, possibly > > > related to theGPU driver. This would be a problem in a user mode > > > component (maybeMesa), not the kernel mode driver. > > > I believe the messages you're seeing when you move the mouse are > > > theresult of runtime power management that puts the GPU to sleep > > > when it'sidle and reinitializes it when it's needed. You have 2 > > > GPUs in yourlaptop, an integrated Renoir GPU in the Ryzen CPU, > > > and an externalNavi10 GPU for higher gaming performance. The GPU > > > that goes to sleep andwakes up is the external Navi10 GPU. > > > The OpenGL renderer string
[PATCH] DRM: gpu: radeon: Fixed coding style issues
Fixed braces, an unnecessary if statement and added a missing space.
Signed-off-by: Sergio Miguéns Iglesias
---
drivers/gpu/drm/radeon/radeon_fb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index 0b206b052972..6640b7c947fe 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -54,6 +54,7 @@ radeonfb_open(struct fb_info *info, int user)
struct radeon_fbdev *rfbdev = info->par;
struct radeon_device *rdev = rfbdev->rdev;
int ret = pm_runtime_get_sync(rdev->ddev->dev);
+
if (ret < 0 && ret != -EACCES) {
pm_runtime_mark_last_busy(rdev->ddev->dev);
pm_runtime_put_autosuspend(rdev->ddev->dev);
@@ -196,9 +197,8 @@ static int radeonfb_create_pinned_object(struct
radeon_fbdev *rfbdev,
radeon_bo_check_tiling(rbo, 0, 0);
ret = radeon_bo_kmap(rbo, NULL);
radeon_bo_unreserve(rbo);
- if (ret) {
+ if (ret)
goto out_unref;
- }
*gobj_p = gobj;
return 0;
@@ -294,9 +294,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
return 0;
out:
- if (rbo) {
-
- }
if (fb && ret) {
drm_gem_object_put(gobj);
drm_framebuffer_unregister_private(fb);
--
2.32.0
RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
[AMD Official Use Only]
Ping.
-Original Message-
From: Gu, JiaWei (Will)
Sent: Wednesday, August 4, 2021 4:08 PM
To: Gu, JiaWei (Will) ; amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily ;
Deucher, Alexander
Subject: RE: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
[AMD Official Use Only]
Add Alex.
-Original Message-
From: Jiawei Gu
Sent: Wednesday, August 4, 2021 3:50 PM
To: amd-gfx@lists.freedesktop.org
Cc: Nieto, David M ; Deng, Emily ; Gu,
JiaWei (Will)
Subject: [PATCH] drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode
Enable pp_num_states, pp_cur_state, pp_force_state, pp_table sysfs under SRIOV
1-VF scenario.
Signed-off-by: Jiawei Gu
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 769f58d5ae1a..04c7d82f8b89 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -2005,10 +2005,10 @@ static int ss_bias_attr_update(struct amdgpu_device
*adev, struct amdgpu_device_ static struct amdgpu_device_attr
amdgpu_device_attrs[] = {
AMDGPU_DEVICE_ATTR_RW(power_dpm_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(power_dpm_force_performance_level,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
- AMDGPU_DEVICE_ATTR_RO(pp_num_states,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RW(pp_force_state,
ATTR_FLAG_BASIC),
- AMDGPU_DEVICE_ATTR_RW(pp_table,
ATTR_FLAG_BASIC),
+ AMDGPU_DEVICE_ATTR_RO(pp_num_states,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RO(pp_cur_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RW(pp_force_state,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
+ AMDGPU_DEVICE_ATTR_RW(pp_table,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(pp_dpm_sclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(pp_dpm_mclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
AMDGPU_DEVICE_ATTR_RW(pp_dpm_socclk,
ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
--
2.17.1
