Re: Re: [PATCH 03/14] drm/atmel-hlcdc: Convert to Linux IRQ interfaces
Hi Thomas,
On 7/29/21 12:18 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 28.07.21 um 22:11 schrieb Sam Ravnborg:
>> Hi Dan,
>>
I think I got it - we need to set irq_enabled to true.
The documentation says so:
"
* @irq_enabled:
*
* Indicates that interrupt handling is enabled,
specifically vblank
* handling. Drivers which don't use drm_irq_install()
need to set this
* to true manually.
"
Can you try to add the following line:
+static int atmel_hlcdc_dc_irq_install(struct drm_device *dev,
unsigned int irq)
+{
+ int ret;
+
+ if (irq == IRQ_NOTCONNECTED)
+ return -ENOTCONN;
+
dev->irq_enabled = true; <= THIS LINE
+ atmel_hlcdc_dc_irq_disable(dev);
+
+ ret = request_irq(irq, atmel_hlcdc_dc_irq_handler, 0,
dev->driver->name, dev);
+ if (ret)
+ return ret;
I hope this fixes it.
>>>
>>> It does! With the irq_enabled line added everything is looking good.
>
> Are you sure, you're testing with the latest drm-misc-next or drm-tip?
> Because using irq_enabled is deprecated and the flag was recently
> replaced by commit 1e4cd78ed493 ("drm: Don't test for IRQ support in
> VBLANK ioctls").
>
> Best regards
> Thomas
>
I was testing with 5.14-rc3. I can test with drm-tip or drm-misc-next.
There a preferred branch to test from?
Thanks and regards,
Dan
>>
>> Great, thanks for testing.
>>
>> Thomas - I assume you will do a re-spin and there is likely some fixes
>> for the applied IRQ conversions too.
>>
>> Note - irq_enabled must be cleared if request_irq fails. I did not
>> include this in the testing here.
>>
>> Sam
>>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 03/14] drm/atmel-hlcdc: Convert to Linux IRQ interfaces
Hi Thomas and Sam,
On 7/29/21 12:48 PM, Sam Ravnborg wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Thomas,
>
>>
>> Are you sure, you're testing with the latest drm-misc-next or drm-tip?
>> Because using irq_enabled is deprecated and the flag was recently replaced
>> by commit 1e4cd78ed493 ("drm: Don't test for IRQ support in VBLANK ioctls").
Ok, My fault for testing on the wrong branch. When I test this patch on
drm-misc-next it works great. Sorry for the confusion!
>
> I was looking at drm-misc-fixes which did not have this commit :-(
> Just my silly excuse why I was convinced this was the issue.
>
> Sam
>
Best regards,
Dan
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: fix fdinfo race with process exit
Get process vm root BO ref in case process is exiting and root BO is
freed, to avoid NULL pointer dereference backtrace:
BUG: unable to handle kernel NULL pointer dereference at
Call Trace:
amdgpu_show_fdinfo+0xfe/0x2a0 [amdgpu]
seq_show+0x12c/0x180
seq_read+0x153/0x410
vfs_read+0x91/0x140[ 3427.206183] ksys_read+0x4f/0xb0
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index d94c5419ec25..fba0084bbcbf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -59,6 +59,7 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
uint64_t vram_mem = 0, gtt_mem = 0, cpu_mem = 0;
struct drm_file *file = f->private_data;
struct amdgpu_device *adev = drm_to_adev(file->minor->dev);
+ struct amdgpu_bo *root;
int ret;
ret = amdgpu_file_to_fpriv(f, );
@@ -69,13 +70,19 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
dev = PCI_SLOT(adev->pdev->devfn);
fn = PCI_FUNC(adev->pdev->devfn);
- ret = amdgpu_bo_reserve(fpriv->vm.root.bo, false);
+ root = amdgpu_bo_ref(fpriv->vm.root.base.bo);
+ if (!root)
+ return;
+
+ ret = amdgpu_bo_reserve(root, false);
if (ret) {
DRM_ERROR("Fail to reserve bo\n");
return;
}
amdgpu_vm_get_memory(>vm, _mem, _mem, _mem);
- amdgpu_bo_unreserve(fpriv->vm.root.bo);
+ amdgpu_bo_unreserve(root);
+ amdgpu_bo_unref();
+
seq_printf(m, "pdev:\t%04x:%02x:%02x.%d\npasid:\t%u\n", domain, bus,
dev, fn, fpriv->vm.pasid);
seq_printf(m, "vram mem:\t%llu kB\n", vram_mem/1024UL);
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: Register bad page handler for Aldebaran
[AMD Official Use Only] > -Original Message- > From: Ghannam, Yazen > Sent: Thursday, June 3, 2021 5:13 PM > To: Joshi, Mukul > Cc: Borislav Petkov ; Alex Deucher ; > x86-ml ; Kasiviswanathan, Harish > ; lkml ; > amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: Register bad page handler for Aldebaran > > On Thu, May 27, 2021 at 03:54:27PM -0400, Joshi, Mukul wrote: > ... > > > Is that the same deferred interrupt which calls > > > amd_deferred_error_interrupt() ? > > > > Sorry picking this up after sometime. I thought I had replied to this email. > > Yes it is the same deferred interrupt which calls > amd_deferred_error_interrupt(). > > > > Mukul, > > Do you expect that the driver will need to mark pages with high correctable > error counts as bad? I think the hardware folks may want the GPU memory > errors to be handled more aggressively than CPU memory errors. The specific > threshold may change from product to product, so it may make sense to > hardcode this in the driver. > Sorry I missed this email completely. Just saw it so responding now. At the moment, we don't have a requirement to mark a page "bad" if there is a high correctable error counts. Our previous GPU ASICs which support RAS, also do not have such a feature. But you make a good point. It might be worthwhile to go and ask the hardware folks about it. > We have similar functionality in the Correctable Errors Collector. But > enterprise > users may prefer a direct approach done in the driver (based on the hardware > experts' guidance) instead of configuring the kernel at runtime. > > So I think having a separate priority may make sense if some special > functionality, or combination of behaviors, is needed which don't fall under > any > exisiting things. In this case, "special functionality" could be that the GPU > memory needs to be handled differently than CPU memory. > > Another thing is that this behavior is similar to the NFIT behavior, i.e. > there's a > memory error on an external device that needs to be handled by the device's > driver. So maybe we can rename MCE_PRIO_NFIT to be generic > (MCE_PRIO_EXTERNAL?) and use that? Multiple notifiers with the same priority > is okay, right? > With respect to MCE priority, I was thinking of using the MCE_PRIO_EDAC instead of creating a new priority as the code in the GPU driver is doing error detection and handling the uncorrectable errors. Not sure if that aligns with the definition of EDAC device in the kernel. What do you think? Regards, Mukul > Thanks, > Yazen ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH -next] drm/amdgpu: fix checking pmops when PM_SLEEP is not enabled
'pm_suspend_target_state' is only available when CONFIG_PM_SLEEP
is set/enabled. OTOH, when both SUSPEND and HIBERNATION are not set,
PM_SLEEP is not set, so this variable cannot be used.
../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: In function
‘amdgpu_acpi_is_s0ix_active’:
../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:1046:11: error:
‘pm_suspend_target_state’ undeclared (first use in this function); did you mean
‘__KSYM_pm_suspend_target_state’?
return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
^~~
__KSYM_pm_suspend_target_state
Also use shorter IS_ENABLED(CONFIG_foo) notation for checking the
2 config symbols.
Fixes: 91b03fc6b50c ("drm/amdgpu: Check pmops for desired suspend state")
Signed-off-by: Randy Dunlap
Cc: Alex Deucher
Cc: Christian König
Cc: "Pan, Xinhui"
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-n...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linext-20210729.orig/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ linext-20210729/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -1040,7 +1040,7 @@ void amdgpu_acpi_detect(void)
*/
bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev)
{
-#if defined(CONFIG_AMD_PMC) || defined(CONFIG_AMD_PMC_MODULE)
+#if IS_ENABLED(CONFIG_AMD_PMC) && IS_ENABLED(CONFIG_PM_SLEEP)
if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
if (adev->flags & AMD_IS_APU)
return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/powerplay/smu10: Fix a typo in error message
Applied. Thanks!
On Thu, Jul 29, 2021 at 9:56 AM Masanari Iida wrote:
>
> This patch fixes a spelling typo in error message.
>
> Signed-off-by: Masanari Iida
> ---
> drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> index 43c3f6e755e7..7dd92bdf7ffb 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
> @@ -1580,7 +1580,7 @@ static int smu10_set_fine_grain_clk_vol(struct pp_hwmgr
> *hwmgr,
> }
>
> if (smu10_data->gfx_actual_soft_min_freq >
> smu10_data->gfx_actual_soft_max_freq) {
> - pr_err("The setting minimun sclk (%d) MHz is greater
> than the setting maximum sclk (%d) MHz\n",
> + pr_err("The setting minimum sclk (%d) MHz is greater
> than the setting maximum sclk (%d) MHz\n",
> smu10_data->gfx_actual_soft_min_freq,
> smu10_data->gfx_actual_soft_max_freq);
> return -EINVAL;
> }
> --
> 2.25.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] gpu/drm/radeon: Fix typo in comments
Applied. Thanks! Alex On Thu, Jul 29, 2021 at 4:21 AM Cai Huoqing wrote: > > Remove the repeated word 'the' from comments > > Signed-off-by: Cai Huoqing > --- > drivers/gpu/drm/radeon/atombios.h | 4 ++-- > drivers/gpu/drm/radeon/r300_reg.h | 2 +- > drivers/gpu/drm/radeon/radeon_device.c | 2 +- > drivers/gpu/drm/radeon/radeon_fence.c | 2 +- > drivers/gpu/drm/radeon/radeon_vm.c | 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/atombios.h > b/drivers/gpu/drm/radeon/atombios.h > index 4b86e8b45009..83e8b8547f9b 100644 > --- a/drivers/gpu/drm/radeon/atombios.h > +++ b/drivers/gpu/drm/radeon/atombios.h > @@ -2802,8 +2802,8 @@ ucMaxNBVoltageHigh: Voltage regulator dependent PWM > value. High 8 bits of t > ucMinNBVoltageHigh: Voltage regulator dependent PWM value. High 8 bits > of the value for the min voltage.Set this one to 0x00 if VC without PWM or no > VC at all. > > > -usInterNBVoltageLow:Voltage regulator dependent PWM value. The value > makes the the voltage >=Min NB voltage but <=InterNBVoltageHigh. Set this to > 0x if VC without PWM or no VC at all. > -usInterNBVoltageHigh: Voltage regulator dependent PWM value. The value > makes the the voltage >=InterNBVoltageLow but <=Max NB voltage.Set this to > 0x if VC without PWM or no VC at all. > +usInterNBVoltageLow:Voltage regulator dependent PWM value. The value > makes the voltage >=Min NB voltage but <=InterNBVoltageHigh. Set this to > 0x if VC without PWM or no VC at all. > +usInterNBVoltageHigh: Voltage regulator dependent PWM value. The value > makes the voltage >=InterNBVoltageLow but <=Max NB voltage.Set this to 0x > if VC without PWM or no VC at all. > */ > > > diff --git a/drivers/gpu/drm/radeon/r300_reg.h > b/drivers/gpu/drm/radeon/r300_reg.h > index 00c0d2ba22d3..60d5413bafa1 100644 > --- a/drivers/gpu/drm/radeon/r300_reg.h > +++ b/drivers/gpu/drm/radeon/r300_reg.h > @@ -353,7 +353,7 @@ > # define R300_PVS_CNTL_1_PROGRAM_START_SHIFT 0 > # define R300_PVS_CNTL_1_POS_END_SHIFT 10 > # define R300_PVS_CNTL_1_PROGRAM_END_SHIFT 20 > -/* Addresses are relative the the vertex program parameters area. */ > +/* Addresses are relative the vertex program parameters area. */ > #define R300_VAP_PVS_CNTL_2 0x22D4 > # define R300_PVS_CNTL_2_PARAM_OFFSET_SHIFT 0 > # define R300_PVS_CNTL_2_PARAM_COUNT_SHIFT 16 > diff --git a/drivers/gpu/drm/radeon/radeon_device.c > b/drivers/gpu/drm/radeon/radeon_device.c > index cec03238e14d..ac8c3251b616 100644 > --- a/drivers/gpu/drm/radeon/radeon_device.c > +++ b/drivers/gpu/drm/radeon/radeon_device.c > @@ -406,7 +406,7 @@ void radeon_doorbell_free(struct radeon_device *rdev, u32 > doorbell) > > /* > * radeon_wb_*() > - * Writeback is the the method by which the the GPU updates special pages > + * Writeback is the method by which the GPU updates special pages > * in memory with the status of certain GPU events (fences, ring pointers, > * etc.). > */ > diff --git a/drivers/gpu/drm/radeon/radeon_fence.c > b/drivers/gpu/drm/radeon/radeon_fence.c > index 18f2c2e0dfb3..e9c47ec28ade 100644 > --- a/drivers/gpu/drm/radeon/radeon_fence.c > +++ b/drivers/gpu/drm/radeon/radeon_fence.c > @@ -50,7 +50,7 @@ > * for GPU/CPU synchronization. When the fence is written, > * it is expected that all buffers associated with that fence > * are no longer in use by the associated ring on the GPU and > - * that the the relevant GPU caches have been flushed. Whether > + * that the relevant GPU caches have been flushed. Whether > * we use a scratch register or memory location depends on the asic > * and whether writeback is enabled. > */ > diff --git a/drivers/gpu/drm/radeon/radeon_vm.c > b/drivers/gpu/drm/radeon/radeon_vm.c > index 36a38adaaea9..bb53016f3138 100644 > --- a/drivers/gpu/drm/radeon/radeon_vm.c > +++ b/drivers/gpu/drm/radeon/radeon_vm.c > @@ -41,7 +41,7 @@ > * (uncached system pages). > * Each VM has an ID associated with it and there is a page table > * associated with each VMID. When execting a command buffer, > - * the kernel tells the the ring what VMID to use for that command > + * the kernel tells the ring what VMID to use for that command > * buffer. VMIDs are allocated dynamically as commands are submitted. > * The userspace drivers maintain their own address space and the kernel > * sets up their pages tables accordingly when they submit their > -- > 2.25.1 > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix typo in comments
On Thu, Jul 29, 2021 at 4:18 AM Cai Huoqing wrote: > > Remove the repeated word 'the' from comments > > Signed-off-by: Cai Huoqing Applied. Thanks! > --- > drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +- > .../gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c | 2 +- > .../drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c | 2 +- > .../gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 2 +- > .../gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c | 2 +- > .../gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c | 2 +- > drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c | 4 ++-- > 7 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c > b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c > index 1596f6b7fed7..7f12ca902f7d 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c > @@ -1030,7 +1030,7 @@ bool resource_build_scaling_params(struct pipe_ctx > *pipe_ctx) > > /* Timing borders are part of vactive that we are also supposed to > skip in addition > * to any stream dst offset. Since dm logic assumes dst is in > addressable > -* space we need to add the the left and top borders to dst offsets > temporarily. > +* space we need to add the left and top borders to dst offsets > temporarily. > * TODO: fix in DM, stream dst is supposed to be in vactive > */ > pipe_ctx->stream->dst.x += timing->h_border_left; > diff --git > a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c > index 799bae229e67..2091dd8c252d 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c > @@ -488,7 +488,7 @@ static void get_meta_and_pte_attr(struct display_mode_lib > *mode_lib, > log2_meta_req_bytes = 6; // meta request is 64b and is 8x8byte meta > element > > // each 64b meta request for dcn is 8x8 meta elements and > - // a meta element covers one 256b block of the the data surface. > + // a meta element covers one 256b block of the data surface. > log2_meta_req_height = log2_blk256_height + 3; // meta req is 8x8 > byte, each byte represent 1 blk256 > log2_meta_req_width = log2_meta_req_bytes + 8 - log2_bytes_per_element > - log2_meta_req_height; > diff --git > a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c > index 6a6d5970d1d5..1a0c14e465fa 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c > @@ -488,7 +488,7 @@ static void get_meta_and_pte_attr(struct display_mode_lib > *mode_lib, > log2_meta_req_bytes = 6; // meta request is 64b and is 8x8byte meta > element > > // each 64b meta request for dcn is 8x8 meta elements and > - // a meta element covers one 256b block of the the data surface. > + // a meta element covers one 256b block of the data surface. > log2_meta_req_height = log2_blk256_height + 3; // meta req is 8x8 > byte, each byte represent 1 blk256 > log2_meta_req_width = log2_meta_req_bytes + 8 - log2_bytes_per_element > - log2_meta_req_height; > diff --git > a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c > index dc1c81a6e377..287e31052b30 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c > @@ -482,7 +482,7 @@ static void get_meta_and_pte_attr( > log2_meta_req_bytes = 6; // meta request is 64b and is 8x8byte meta > element > > // each 64b meta request for dcn is 8x8 meta elements and > - // a meta element covers one 256b block of the the data surface. > + // a meta element covers one 256b block of the data surface. > log2_meta_req_height = log2_blk256_height + 3; // meta req is 8x8 > byte, each byte represent 1 blk256 > log2_meta_req_width = log2_meta_req_bytes + 8 - log2_bytes_per_element > - log2_meta_req_height; > diff --git > a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c > b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c > index 04601a767a8f..0d934fae1c3a 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c > @@ -549,7 +549,7 @@ static void get_meta_and_pte_attr(struct display_mode_lib > *mode_lib, >
Re: Linux Mint 20.04 5.11 issue
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 specifies "RENOIR". Therefore I'm > surprisedthat the Navi10 GPU wakes up when you move the mouse. > Ideally itshouldn't be used at all when you're just using the > desktop. > If you suspect that runtime power management is responsible for > yourproblems, you could disable it with amdgpu.runpm=0 on the kernel > commandline. That means the Navi10 GPU won't go into the low power > mode anddrain your battery more quickly. So this is not a permanent > solution.Just an experiment to narrow down the problem. > Regards, Felix > > > I'm not sure how to do this as I haven't had to report a bug > > before.I've looked to a variety of bug reporting sites to see if > > anyone elseis running into the same issues that I'm having (such as > > the Mateproject) and haven't seen anything at all similar to the > > issue I'mhaving. Since I had issues with AMD drivers with my distro > > (infobelow) and some consistent and high volume dmesg content shows > > up,I've decided that I should start here with the AMD kernel team. > > I have a fairly new MSI laptop with the following configuration: > > [code]System:Kernel: 5.11.0-25-generic x86_64 bits: 64 > > compiler: N/ADesktop: MATE 1.24.0 wm: marcodm: LightDM > > Distro: Linux Mint 20.2 Uma base: Ubuntu > > 20.04focal Machine: Type: Laptop System: Micro-Star product: > > Alpha 17 A4DEK v:REV:1.0 serial: Chassis: type: > > 10 serial: Mobo: Micro-Star model: MS-17EK v: > > REV:1.0 serial: UEFI: American Megatrendsv: > > E17EKAMS.101 date: 10/26/2020 Battery: ID-1: BAT1 charge: 66.2 Wh > > condition: 67.0/65.7 Wh (102%)volts: 12.4/10.8model: > > MSI Corp. MS-17EK serial: N/A status: Unknown CPU: Topology: > > 8-Core model: AMD Ryzen 7 4800H with RadeonGraphics bits: 64 type: > > MT MCParch: Zen rev: 1 L2 cache: 4096 > > KiBflags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 > > sse4_2 sse4assse3 svm bogomips: 92630Speed: 4278 MHz > > min/max: 1400/2900 MHz Core speeds (MHz):1: 4280 2: 1865 3: > > 13974: 2188 5: 1489 6: 2265 7: 1907 8: 1906 9: 1729 10: > > 139711: 1397 12: 1397 13: 139714: 1397 15: 1907 16: > > 1740 Graphics: Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT >
Re: [Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open
Remember before enjoying your holiday that the deadline for XDC 2022 proposals is *September 1st, 2021* :-) Feel free to submit your proposal before, so we can give you early feedback on it! Sam On Thu, 2021-07-01 at 18:14 +0200, Samuel Iglesias Gonsálvez wrote: > This is a reminder that the call for proposals for hosting XDC 2022 > period finishes in two months. > > Be sure to prepare your submission before you leave on holiday! > > Sam > > On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote: > > Hello everyone! > > > > The X.org board is soliciting proposals to host XDC in 2022. Since > > XDC 2021 is being held in Europe this year (although virtually), > > we've > > decided to host in North America. However, the board is open to > > other > > locations, especially if there's an interesting co-location with > > another conference. > > > > Of course though, due to the ongoing COVID-19 pandemic it's not yet > > clear whether or not it will be possible to host XDC 2022 in > > person, > > although is seems very likely. Because of this, we would like to > > make it clear that sponsors should prepare for both the possibility > > of an in person conference, and the possibility of a virtual > > conference. We will work with organizers on coming up with a > > deadline for deciding whether or not we'll be going virtual, likely > > sometime around July 2022. > > > > If you're considering hosting XDC, we've assembled a wiki page with > > what's generally expected and needed: > > > > https://www.x.org/wiki/Events/RFP/ > > > > When submitting your proposal, please make sure to include at least > > the > > key information about the potential location in question, possible > > dates along with estimated costs. Proposals can be submitted to > > board > > at foundation.x.org until the deadline of *September 1st, 2021*. > > > > Additionally, an quirk early heads-up to the board if you're > > considering hosting would be appreciated, in case we need to adjust > > the > > schedule a bit. Also, earlier is better since there generally will > > be > > a > > bit of Q with organizers. > > > > And if you just have some questions about what organizing XDC > > entails, > > please feel free to chat with previous organizers, or someone from > > the > > board. > > > > Thanks, > > > > Sam > > > > ___ > > mesa-dev mailing list > > mesa-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 9/9] drm/amd/display: 3.2.147
From: Aric Cyr Acked-by: Aurabindo Pillai Signed-off-by: Aric Cyr --- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dc.h b/drivers/gpu/drm/amd/display/dc/dc.h index 22e917714fe2..62c222d0402f 100644 --- a/drivers/gpu/drm/amd/display/dc/dc.h +++ b/drivers/gpu/drm/amd/display/dc/dc.h @@ -45,7 +45,7 @@ /* forward declaration */ struct aux_payload; -#define DC_VER "3.2.146" +#define DC_VER "3.2.147" #define MAX_SURFACES 3 #define MAX_PLANES 6 -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5/9] drm/amd/display: Fix resetting DCN3.1 HW when resuming from S4
From: Jude Shih
[Why] On S4 resume we also need to fix detection of when to reload DMCUB
firmware because we're currently using the VBIOS version which isn't
compatible with the driver version.
[How] Update the hardware init check for DCN31 since it's the ASIC that
has this issue.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Aurabindo Pillai
Signed-off-by: Jude Shih
---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
index 61446170056e..6820012e3b6e 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
@@ -270,11 +270,13 @@ void dmub_dcn31_set_outbox1_rptr(struct dmub_srv *dmub,
uint32_t rptr_offset)
bool dmub_dcn31_is_hw_init(struct dmub_srv *dmub)
{
- uint32_t is_hw_init;
+ union dmub_fw_boot_status status;
+ uint32_t is_enable;
- REG_GET(DMCUB_CNTL, DMCUB_ENABLE, _hw_init);
+ status.all = REG_READ(DMCUB_SCRATCH0);
+ REG_GET(DMCUB_CNTL, DMCUB_ENABLE, _enable);
- return is_hw_init != 0;
+ return is_enable != 0 && status.bits.dal_fw;
}
bool dmub_dcn31_is_supported(struct dmub_srv *dmub)
--
2.32.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 7/9] drm/amd/display: workaround for hard hang on HPD on native DP
From: Qingqing Zhuo
[Why]
HPD disable and enable sequences are not mutually exclusive
on Linux. For HPDs that spans over 1s (i.e. HPD low = 1s),
part of the disable sequence (specifically, a request to SMU
to lower refclk) could come right before the call to PHY
enable, causing DMUB to access an unresponsive PHY
and thus a hard hang on the system.
[How]
Disable 48mhz refclk off on native DP.
Reviewed-by: Hersen Wu
Acked-by: Aurabindo Pillai
Signed-off-by: Qingqing Zhuo
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index c6f494f0dcea..6185f9475fa2 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -66,9 +66,11 @@ int rn_get_active_display_cnt_wa(
for (i = 0; i < context->stream_count; i++) {
const struct dc_stream_state *stream = context->streams[i];
+ /* Extend the WA to DP for Linux*/
if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A ||
stream->signal == SIGNAL_TYPE_DVI_SINGLE_LINK ||
- stream->signal == SIGNAL_TYPE_DVI_DUAL_LINK)
+ stream->signal == SIGNAL_TYPE_DVI_DUAL_LINK ||
+ stream->signal == SIGNAL_TYPE_DISPLAY_PORT)
tmds_present = true;
}
--
2.32.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/9] drm/amd/display: Assume LTTPR interop for DCN31+
From: Wesley Chalmers
[WHY]
For DCN31 onward, LTTPR is to be enabled and set to Transparent by
VBIOS. Driver is to assume that VBIOS has done this without needing to
check the VBIOS interop bit.
[HOW]
Add LTTPR enable and interop VBIOS bits into dc->caps, and force-set the
interop bit to true for DCN31+.
Reviewed-by: Jun Lei
Acked-by: Aurabindo Pillai
Signed-off-by: Wesley Chalmers
---
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 21 ++-
drivers/gpu/drm/amd/display/dc/dc.h | 2 ++
.../drm/amd/display/dc/dcn30/dcn30_resource.c | 20 ++
.../drm/amd/display/dc/dcn31/dcn31_resource.c | 16 ++
4 files changed, 40 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index f56e061d35bc..cd025c12f17b 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -3595,29 +3595,12 @@ static bool dpcd_read_sink_ext_caps(struct dc_link
*link)
bool dp_retrieve_lttpr_cap(struct dc_link *link)
{
uint8_t lttpr_dpcd_data[6];
- bool vbios_lttpr_enable = false;
- bool vbios_lttpr_interop = false;
- struct dc_bios *bios = link->dc->ctx->dc_bios;
+ bool vbios_lttpr_enable = link->dc->caps.vbios_lttpr_enable;
+ bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
enum dc_status status = DC_ERROR_UNEXPECTED;
bool is_lttpr_present = false;
memset(lttpr_dpcd_data, '\0', sizeof(lttpr_dpcd_data));
- /* Query BIOS to determine if LTTPR functionality is forced on by
system */
- if (bios->funcs->get_lttpr_caps) {
- enum bp_result bp_query_result;
- uint8_t is_vbios_lttpr_enable = 0;
-
- bp_query_result = bios->funcs->get_lttpr_caps(bios,
_vbios_lttpr_enable);
- vbios_lttpr_enable = (bp_query_result == BP_RESULT_OK) &&
!!is_vbios_lttpr_enable;
- }
-
- if (bios->funcs->get_lttpr_interop) {
- enum bp_result bp_query_result;
- uint8_t is_vbios_interop_enabled = 0;
-
- bp_query_result = bios->funcs->get_lttpr_interop(bios,
_vbios_interop_enabled);
- vbios_lttpr_interop = (bp_query_result == BP_RESULT_OK) &&
!!is_vbios_interop_enabled;
- }
/*
* Logic to determine LTTPR mode
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index a948f4f48935..22e917714fe2 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -183,6 +183,8 @@ struct dc_caps {
unsigned int cursor_cache_size;
struct dc_plane_cap planes[MAX_PLANES];
struct dc_color_caps color;
+ bool vbios_lttpr_aware;
+ bool vbios_lttpr_enable;
};
struct dc_bug_wa {
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
index 596c97dce67e..253654d605c2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
@@ -2617,6 +2617,26 @@ static bool dcn30_resource_construct(
dc->caps.color.mpc.ogam_rom_caps.hlg = 0;
dc->caps.color.mpc.ocsc = 1;
+ /* read VBIOS LTTPR caps */
+ {
+ if (ctx->dc_bios->funcs->get_lttpr_caps) {
+ enum bp_result bp_query_result;
+ uint8_t is_vbios_lttpr_enable = 0;
+
+ bp_query_result =
ctx->dc_bios->funcs->get_lttpr_caps(ctx->dc_bios, _vbios_lttpr_enable);
+ dc->caps.vbios_lttpr_enable = (bp_query_result ==
BP_RESULT_OK) && !!is_vbios_lttpr_enable;
+ }
+
+ if (ctx->dc_bios->funcs->get_lttpr_interop) {
+ enum bp_result bp_query_result;
+ uint8_t is_vbios_interop_enabled = 0;
+
+ bp_query_result =
ctx->dc_bios->funcs->get_lttpr_interop(ctx->dc_bios,
+ _vbios_interop_enabled);
+ dc->caps.vbios_lttpr_aware = (bp_query_result ==
BP_RESULT_OK) && !!is_vbios_interop_enabled;
+ }
+ }
+
if (dc->ctx->dce_environment == DCE_ENV_PRODUCTION_DRV)
dc->debug = debug_defaults_drv;
else if (dc->ctx->dce_environment == DCE_ENV_FPGA_MAXIMUS) {
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index f9446ce4fdc5..a7702d3c75cd 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1967,6 +1967,22 @@ static bool dcn31_resource_construct(
dc->caps.color.mpc.ogam_rom_caps.hlg = 0;
dc->caps.color.mpc.ocsc = 1;
+ /* read VBIOS LTTPR caps */
+ {
+ if
[PATCH 0/9] DC patches for Aug 2, 2021
Its a small set of changes this week for DC. In summary, we have: * DC version 3.2.147 * LTTPR, MPO Improvements * General stability and bug fixes -- Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.77 Aric Cyr (1): drm/amd/display: 3.2.147 Bing Guo (2): drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X drm/amd/display: Increase stutter watermark for dcn303 Jaehyun Chung (1): drm/amd/display: Add check for validating unsupported ODM plus MPO case 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 Roman Li (1): drm/amd/display: Remove redundant vblank workqueues in DM Wesley Chalmers (1): drm/amd/display: Assume LTTPR interop for DCN31+ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++- .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++- .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 21 ++- .../gpu/drm/amd/display/dc/core/dc_resource.c | 5 + drivers/gpu/drm/amd/display/dc/dc.h | 4 +++- .../gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- .../drm/amd/display/dc/dcn30/dcn30_resource.c | 20 ++ .../amd/display/dc/dcn303/dcn303_resource.c | 4 ++-- .../drm/amd/display/dc/dcn31/dcn31_resource.c | 16 ++ .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++-- .../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 8 --- 11 files changed, 61 insertions(+), 35 deletions(-) -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 6/9] drm/amd/display: Add check for validating unsupported ODM plus MPO case
From: Jaehyun Chung [Why] We do not currently support ODM plus MPO on only one side of the screen. This unsupported case causes validation calculations to divide by zero due to invalid viewport values. [How] Add stopgap for the validation of ODM plus MPO on one side of screen case. Reviewed-by: Dmytro Laktyushkin Acked-by: Aurabindo Pillai Signed-off-by: Jaehyun Chung --- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c index 1596f6b7fed7..f1b8c1292035 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c @@ -1051,6 +1051,11 @@ bool resource_build_scaling_params(struct pipe_ctx *pipe_ctx) /* depends on scaling ratios and recout, does not calculate offset yet */ calculate_viewport_size(pipe_ctx); + /* Stopgap for validation of ODM + MPO on one side of screen case */ + if (pipe_ctx->plane_res.scl_data.viewport.height < 1 || + pipe_ctx->plane_res.scl_data.viewport.width < 1) + return false; + /* * LB calculations depend on vp size, h/v_active and scaling ratios * Setting line buffer pixel depth to 24bpp yields banding -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4/9] drm/amd/display: Remove redundant vblank workqueues in DM
From: Roman Li
[Why]
Display Manager initializes array of vblank workqueues, but only 1 is used.
[How]
Use single instance init instead of array.
Reviewed-by: Qingqing Zhou
Acked-by: Aurabindo Pillai
Signed-off-by: Roman Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0a1dd25e567d..a05675b84c2c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1066,19 +1066,15 @@ static void event_mall_stutter(struct work_struct *work)
static struct vblank_workqueue *vblank_create_workqueue(struct amdgpu_device
*adev, struct dc *dc)
{
-
- int max_caps = dc->caps.max_links;
struct vblank_workqueue *vblank_work;
- int i = 0;
- vblank_work = kcalloc(max_caps, sizeof(*vblank_work), GFP_KERNEL);
+ vblank_work = kzalloc(sizeof(*vblank_work), GFP_KERNEL);
if (ZERO_OR_NULL_PTR(vblank_work)) {
kfree(vblank_work);
return NULL;
}
- for (i = 0; i < max_caps; i++)
- INIT_WORK(_work[i].mall_work, event_mall_stutter);
+ INIT_WORK(_work->mall_work, event_mall_stutter);
return vblank_work;
}
--
2.32.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/9] drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X
From: Bing Guo Why: In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X by the number of pipes ODM Combined. How: Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the number of pipes ODM Combined. Reviewed-by: Martin Leung Acked-by: Aurabindo Pillai Signed-off-by: Bing Guo --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c index 7fa9fc656b0c..f6e747f25ebe 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c @@ -464,7 +464,7 @@ void optc2_lock_doublebuffer_enable(struct timing_generator *optc) REG_UPDATE_2(OTG_GLOBAL_CONTROL1, MASTER_UPDATE_LOCK_DB_X, - h_blank_start - 200 - 1, + (h_blank_start - 200 - 1) / optc1->opp_count, MASTER_UPDATE_LOCK_DB_Y, v_blank_start - 1); } -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 3/9] drm/amd/display: Increase stutter watermark for dcn303
From: Bing Guo
[Why]
Hardware team suggested to use SRExitTime= 35.5us as w/a to prevent
underflow in certain modes.
Reviewed-by: Martin Leung
Acked-by: Aurabindo Pillai
Signed-off-by: Bing Guo
---
drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
index 833ab13fa834..dc7823d23ba8 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
@@ -146,8 +146,8 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_03_soc = {
.min_dcfclk = 500.0, /* TODO: set this to actual min DCFCLK */
.num_states = 1,
- .sr_exit_time_us = 26.5,
- .sr_enter_plus_exit_time_us = 31,
+ .sr_exit_time_us = 35.5,
+ .sr_enter_plus_exit_time_us = 40,
.urgent_latency_us = 4.0,
.urgent_latency_pixel_data_only_us = 4.0,
.urgent_latency_pixel_mixed_with_vm_data_us = 4.0,
--
2.32.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 8/9] drm/amd/display: [FW Promotion] Release 0.0.77
From: Anthony Koo Acked-by: Aurabindo Pillai Signed-off-by: Anthony Koo --- drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h index 02921ad22310..aa2707e469c1 100644 --- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h +++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h @@ -47,10 +47,10 @@ /* Firmware versioning. */ #ifdef DMUB_EXPOSE_VERSION -#define DMUB_FW_VERSION_GIT_HASH 0xe599e0896 +#define DMUB_FW_VERSION_GIT_HASH 0x6d13d5e2c #define DMUB_FW_VERSION_MAJOR 0 #define DMUB_FW_VERSION_MINOR 0 -#define DMUB_FW_VERSION_REVISION 76 +#define DMUB_FW_VERSION_REVISION 77 #define DMUB_FW_VERSION_TEST 0 #define DMUB_FW_VERSION_VBIOS 0 #define DMUB_FW_VERSION_HOTFIX 0 -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 0/9] DC Patches for Aug 2, 2021
Its a small set of changes this week for DC. In summary, we have: * DC version 3.2.147 * LTTPR, MPO Improvements * General stability and bug fixes -- Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.77 Aric Cyr (1): drm/amd/display: 3.2.147 Guo, Bing (2): drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X drm/amd/display: Increase stutter watermark for dcn303 Jaehyun Chung (1): drm/amd/display: Add check for validating unsupported ODM plus MPO case 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 Roman Li (1): drm/amd/display: Remove redundant vblank workqueues in DM Wesley Chalmers (1): drm/amd/display: Assume LTTPR interop for DCN31+ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++- .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++- .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 21 ++- .../gpu/drm/amd/display/dc/core/dc_resource.c | 5 + drivers/gpu/drm/amd/display/dc/dc.h | 4 +++- .../gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- .../drm/amd/display/dc/dcn30/dcn30_resource.c | 20 ++ .../amd/display/dc/dcn303/dcn303_resource.c | 4 ++-- .../drm/amd/display/dc/dcn31/dcn31_resource.c | 16 ++ .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++-- .../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 8 --- 11 files changed, 61 insertions(+), 35 deletions(-) -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/9] drm/amd/display: Assume LTTPR interop for DCN31+
From: Wesley Chalmers
[WHY]
For DCN31 onward, LTTPR is to be enabled and set to Transparent by
VBIOS. Driver is to assume that VBIOS has done this without needing to
check the VBIOS interop bit.
[HOW]
Add LTTPR enable and interop VBIOS bits into dc->caps, and force-set the
interop bit to true for DCN31+.
Reviewed-by: Jun Lei
Acked-by: Aurabindo Pillai
Signed-off-by: Wesley Chalmers
---
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 21 ++-
drivers/gpu/drm/amd/display/dc/dc.h | 2 ++
.../drm/amd/display/dc/dcn30/dcn30_resource.c | 20 ++
.../drm/amd/display/dc/dcn31/dcn31_resource.c | 16 ++
4 files changed, 40 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index f56e061d35bc..cd025c12f17b 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -3595,29 +3595,12 @@ static bool dpcd_read_sink_ext_caps(struct dc_link
*link)
bool dp_retrieve_lttpr_cap(struct dc_link *link)
{
uint8_t lttpr_dpcd_data[6];
- bool vbios_lttpr_enable = false;
- bool vbios_lttpr_interop = false;
- struct dc_bios *bios = link->dc->ctx->dc_bios;
+ bool vbios_lttpr_enable = link->dc->caps.vbios_lttpr_enable;
+ bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
enum dc_status status = DC_ERROR_UNEXPECTED;
bool is_lttpr_present = false;
memset(lttpr_dpcd_data, '\0', sizeof(lttpr_dpcd_data));
- /* Query BIOS to determine if LTTPR functionality is forced on by
system */
- if (bios->funcs->get_lttpr_caps) {
- enum bp_result bp_query_result;
- uint8_t is_vbios_lttpr_enable = 0;
-
- bp_query_result = bios->funcs->get_lttpr_caps(bios,
_vbios_lttpr_enable);
- vbios_lttpr_enable = (bp_query_result == BP_RESULT_OK) &&
!!is_vbios_lttpr_enable;
- }
-
- if (bios->funcs->get_lttpr_interop) {
- enum bp_result bp_query_result;
- uint8_t is_vbios_interop_enabled = 0;
-
- bp_query_result = bios->funcs->get_lttpr_interop(bios,
_vbios_interop_enabled);
- vbios_lttpr_interop = (bp_query_result == BP_RESULT_OK) &&
!!is_vbios_interop_enabled;
- }
/*
* Logic to determine LTTPR mode
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index a948f4f48935..22e917714fe2 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -183,6 +183,8 @@ struct dc_caps {
unsigned int cursor_cache_size;
struct dc_plane_cap planes[MAX_PLANES];
struct dc_color_caps color;
+ bool vbios_lttpr_aware;
+ bool vbios_lttpr_enable;
};
struct dc_bug_wa {
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
index 596c97dce67e..253654d605c2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
@@ -2617,6 +2617,26 @@ static bool dcn30_resource_construct(
dc->caps.color.mpc.ogam_rom_caps.hlg = 0;
dc->caps.color.mpc.ocsc = 1;
+ /* read VBIOS LTTPR caps */
+ {
+ if (ctx->dc_bios->funcs->get_lttpr_caps) {
+ enum bp_result bp_query_result;
+ uint8_t is_vbios_lttpr_enable = 0;
+
+ bp_query_result =
ctx->dc_bios->funcs->get_lttpr_caps(ctx->dc_bios, _vbios_lttpr_enable);
+ dc->caps.vbios_lttpr_enable = (bp_query_result ==
BP_RESULT_OK) && !!is_vbios_lttpr_enable;
+ }
+
+ if (ctx->dc_bios->funcs->get_lttpr_interop) {
+ enum bp_result bp_query_result;
+ uint8_t is_vbios_interop_enabled = 0;
+
+ bp_query_result =
ctx->dc_bios->funcs->get_lttpr_interop(ctx->dc_bios,
+ _vbios_interop_enabled);
+ dc->caps.vbios_lttpr_aware = (bp_query_result ==
BP_RESULT_OK) && !!is_vbios_interop_enabled;
+ }
+ }
+
if (dc->ctx->dce_environment == DCE_ENV_PRODUCTION_DRV)
dc->debug = debug_defaults_drv;
else if (dc->ctx->dce_environment == DCE_ENV_FPGA_MAXIMUS) {
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index f9446ce4fdc5..a7702d3c75cd 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1967,6 +1967,22 @@ static bool dcn31_resource_construct(
dc->caps.color.mpc.ogam_rom_caps.hlg = 0;
dc->caps.color.mpc.ocsc = 1;
+ /* read VBIOS LTTPR caps */
+ {
+ if
[PATCH] drm/amdkfd: Expose GFXIP engine version to sysfs
Add u32 gfx_version field to kfd_node_properties and kfd_device_info.
Populate _device_info structs accordingly and expose to sysfs.
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..1699f1adff9d 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_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_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_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_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_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_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_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_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_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_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_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,
.asic_name = "vegam",
+ .gfx_version = 80003,
.max_pasid_bits = 16,
.max_no_of_hqd = 24,
.doorbell_size = 4,
@@ -312,6 +324,7 @@ static const struct kfd_device_info vegam_device_info = {
static const struct kfd_device_info vega10_device_info = {
.asic_family = CHIP_VEGA10,
.asic_name = "vega10",
+ .gfx_version = 9,
.max_pasid_bits = 16,
[PATCH 0/9] DC Patches Aug 2, 2021
Its a small set of changes this week for DC. In summary, we have: * DC version 3.2.147 * LTTPR, MPO Improvements * General stability and bug fixes -- Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.77 Aric Cyr (1): drm/amd/display: 3.2.147 Guo, Bing (2): drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X drm/amd/display: Increase stutter watermark for dcn303 Jaehyun Chung (1): drm/amd/display: Add check for validating unsupported ODM plus MPO case 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 Roman Li (1): drm/amd/display: Remove redundant vblank workqueues in DM Wesley Chalmers (1): drm/amd/display: Assume LTTPR interop for DCN31+ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++- .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++- .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 21 ++- .../gpu/drm/amd/display/dc/core/dc_resource.c | 5 + drivers/gpu/drm/amd/display/dc/dc.h | 4 +++- .../gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- .../drm/amd/display/dc/dcn30/dcn30_resource.c | 20 ++ .../amd/display/dc/dcn303/dcn303_resource.c | 4 ++-- .../drm/amd/display/dc/dcn31/dcn31_resource.c | 16 ++ .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++-- .../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 8 --- 11 files changed, 61 insertions(+), 35 deletions(-) -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 0/9] DC Patches for August 2, 2021
This DC patchset brings improvements in multiple areas. In summary, we have: * DC version 3.2.147 * DMUB FW release 0.0.77 * LTTPR, MPO improvements * General bug fixes and stability improvements -- Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.77 Aric Cyr (1): drm/amd/display: 3.2.147 Chung (1): drm/amd/display: Add check for validating unsupported ODM plus MPO case Guo, Bing (2): drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X drm/amd/display: Increase stutter watermark for dcn303 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 Roman Li (1): drm/amd/display: Remove redundant vblank workqueues in DM Wesley Chalmers (1): drm/amd/display: Assume LTTPR interop for DCN31+ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++- .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++- .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 21 ++- .../gpu/drm/amd/display/dc/core/dc_resource.c | 5 + drivers/gpu/drm/amd/display/dc/dc.h | 4 +++- .../gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- .../drm/amd/display/dc/dcn30/dcn30_resource.c | 20 ++ .../amd/display/dc/dcn303/dcn303_resource.c | 4 ++-- .../drm/amd/display/dc/dcn31/dcn31_resource.c | 16 ++ .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++-- .../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 8 --- 11 files changed, 61 insertions(+), 35 deletions(-) -- 2.32.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/display: protect dc_dsc_stream_bandwidth_in_kbps with CONFIG_DRM_AMD_DC_DCN
On 2021-07-28 4:35 p.m., Alex Deucher wrote:
> It's only used and enabled with DCN, so protect it.
>
> Fixes: b6b76b0315ed7b ("drm/amd/display: Fixed EdidUtility build errors")
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 ++
> 1 file changed, 2 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 5be9d6c70ea6..8bd7f42a8053 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -3729,11 +3729,13 @@ uint32_t dc_bandwidth_in_kbps_from_timing(
> uint32_t bits_per_channel = 0;
> uint32_t kbps;
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> if (timing->flags.DSC)
> return dc_dsc_stream_bandwidth_in_kbps(timing,
> timing->dsc_cfg.bits_per_pixel,
> timing->dsc_cfg.num_slices_h,
> timing->dsc_cfg.is_dp);
> +#endif
>
> switch (timing->display_color_depth) {
> case COLOR_DEPTH_666:
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v4] drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Yifan Zhang
Sent: Thursday, July 29, 2021 5:46 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Yifan
Subject: [PATCH v4] drm/amdgpu: fix the doorbell missing when in CGPG issue for
renoir.
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 03acc777adf7..ab79ca770dcd 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1295,6 +1295,16 @@ static bool is_raven_kicker(struct amdgpu_device *adev)
return false;
}
+static bool check_if_enlarge_doorbell_range(struct amdgpu_device *adev)
+{
+ if ((adev->asic_type == CHIP_RENOIR) &&
+ (adev->gfx.me_fw_version >= 0x00a5) &&
+ (adev->gfx.me_feature_version >= 52))
+ return true;
+ else
+ return false;
+}
+
static void gfx_v9_0_check_if_need_gfxoff(struct amdgpu_device *adev)
{
if (gfx_v9_0_should_disable_gfxoff(adev->pdev))
@@ -3675,7 +3685,16 @@ static int gfx_v9_0_kiq_init_register(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
(adev->doorbell_index.kiq * 2) << 2);
- WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ /* If GC has entered CGPG, ringing doorbell > first page
+* doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to
+* workaround this issue. And this change has to align with
firmware
+* update.
+*/
+ if (check_if_enlarge_doorbell_range(adev))
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ (adev->doorbell.size - 4));
+ else
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
(adev->doorbell_index.userqueue_end *
2) << 2);
}
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cc3367e51b7f7457dd02d08d95275c11f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637631487971875543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=SlwGsspm4%2BGSekdb%2F9Tl1rvDhaH%2BJHBDv5%2BgoazxabY%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Fix channel_index table layout for Aldebaran
[AMD Official Use Only]
Reviewed-By: John Clements
From: Joshi, Mukul
Sent: Thursday, July 29, 2021 11:37 PM
To: amd-gfx@lists.freedesktop.org
Cc: Clements, John ; Zhang, Hawking
; Joshi, Mukul
Subject: [PATCH] drm/amdgpu: Fix channel_index table layout for Aldebaran
Fix the channel_index table layout to fetch the correct
channel_index when calculating physical address from
normalized address during page retirement.
Also, fix the number of UMC instances and number of channels
within each UMC instance for Aldebaran.
Signed-off-by: Mukul Joshi
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/umc_v6_7.c | 16
drivers/gpu/drm/amd/amdgpu/umc_v6_7.h | 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 7cf653f9e9a7..097230b5e946 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -1171,8 +1171,8 @@ static void gmc_v9_0_set_umc_funcs(struct amdgpu_device
*adev)
break;
case CHIP_ALDEBARAN:
adev->umc.max_ras_err_cnt_per_query =
UMC_V6_7_TOTAL_CHANNEL_NUM;
- adev->umc.channel_inst_num = UMC_V6_7_UMC_INSTANCE_NUM;
- adev->umc.umc_inst_num = UMC_V6_7_CHANNEL_INSTANCE_NUM;
+ adev->umc.channel_inst_num = UMC_V6_7_CHANNEL_INSTANCE_NUM;
+ adev->umc.umc_inst_num = UMC_V6_7_UMC_INSTANCE_NUM;
adev->umc.channel_offs = UMC_V6_7_PER_CHANNEL_OFFSET;
if (!adev->gmc.xgmi.connected_to_cpu)
adev->umc.ras_funcs = _v6_7_ras_funcs;
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
index 7da12110425c..bb30336b1e8d 100644
--- a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
+++ b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
@@ -30,17 +30,17 @@
const uint32_t
umc_v6_7_channel_idx_tbl_second[UMC_V6_7_UMC_INSTANCE_NUM][UMC_V6_7_CHANNEL_INSTANCE_NUM]
= {
- {28, 12, 6, 22},{19, 3, 9, 25},
- {20, 4, 30, 14},{11, 27, 1, 17},
- {24, 8, 2, 18}, {15, 31, 5, 21},
- {16, 0, 26, 10},{7, 23, 29, 13}
+ {28, 20, 24, 16, 12, 4, 8, 0},
+ {6, 30, 2, 26, 22, 14, 18, 10},
+ {19, 11, 15, 7, 3, 27, 31, 23},
+ {9, 1, 5, 29, 25, 17, 21, 13}
};
const uint32_t
umc_v6_7_channel_idx_tbl_first[UMC_V6_7_UMC_INSTANCE_NUM][UMC_V6_7_CHANNEL_INSTANCE_NUM]
= {
- {19, 3, 9, 25}, {28, 12, 6, 22},
- {11, 27, 1, 17},{20, 4, 30, 14},
- {15, 31, 5, 21},{24, 8, 2, 18},
- {7, 23, 29, 13},{16, 0, 26, 10}
+ {19, 11, 15, 7, 3, 27, 31, 23},
+ {9, 1, 5, 29, 25, 17, 21, 13},
+ {28, 20, 24, 16, 12, 4, 8, 0},
+ {6, 30, 2, 26, 22, 14, 18, 10},
};
static inline uint32_t get_umc_v6_7_reg_offset(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
index 81b8f1844091..57f2557e7aca 100644
--- a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
+++ b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
@@ -36,9 +36,9 @@
#define UMC_V6_7_INST_DIST 0x4
/* number of umc channel instance with memory map register access */
-#define UMC_V6_7_CHANNEL_INSTANCE_NUM 4
+#define UMC_V6_7_UMC_INSTANCE_NUM 4
/* number of umc instance with memory map register access */
-#define UMC_V6_7_UMC_INSTANCE_NUM 8
+#define UMC_V6_7_CHANNEL_INSTANCE_NUM 8
/* total channel instances in one umc block */
#define UMC_V6_7_TOTAL_CHANNEL_NUM (UMC_V6_7_CHANNEL_INSTANCE_NUM *
UMC_V6_7_UMC_INSTANCE_NUM)
/* UMC regiser per channel offset */
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 03/14] drm/atmel-hlcdc: Convert to Linux IRQ interfaces
Hi Thomas,
>
> Are you sure, you're testing with the latest drm-misc-next or drm-tip?
> Because using irq_enabled is deprecated and the flag was recently replaced
> by commit 1e4cd78ed493 ("drm: Don't test for IRQ support in VBLANK ioctls").
I was looking at drm-misc-fixes which did not have this commit :-(
Just my silly excuse why I was convinced this was the issue.
Sam
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: avoid conflicting address mappings
Am 2021-07-19 um 5:18 p.m. schrieb Alex Sierra:
> [Why]
> Avoid conflict with address ranges mapped by SVM
> mechanism that try to be allocated again through
> ioctl_alloc in the same process. And viceversa.
>
> [How]
> For ioctl_alloc_memory_of_gpu allocations
> Check if the address range passed into ioctl memory
> alloc does not exist already in the kfd_process
> svms->objects interval tree.
>
> For SVM allocations
> Look for the address range into the interval tree VA from
> the VM inside of each pdds used in a kfd_process.
>
> Signed-off-by: Alex Sierra
Two nitpicks inline. With that fixed, the patch is
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 13
> drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 79 +++-
> 2 files changed, 75 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 67541c30327a..f39baaa22a62 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -1251,6 +1251,7 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file
> *filep,
> struct kfd_process_device *pdd;
> void *mem;
> struct kfd_dev *dev;
> + struct svm_range_list *svms = >svms;
> int idr_handle;
> long err;
> uint64_t offset = args->mmap_offset;
> @@ -1259,6 +1260,18 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file
> *filep,
> if (args->size == 0)
> return -EINVAL;
>
> +#if IS_ENABLED(CONFIG_HSA_AMD_SVM)
> + mutex_lock(>lock);
> + if (interval_tree_iter_first(>objects,
> + args->va_addr >> PAGE_SHIFT,
> + (args->va_addr + args->size - 1) >>
> PAGE_SHIFT)) {
> + pr_err("Address: 0x%llx already allocated by SVM\n",
> + args->va_addr);
> + mutex_unlock(>lock);
> + return -EADDRINUSE;
> + }
> + mutex_unlock(>lock);
> +#endif
> dev = kfd_device_by_id(args->gpu_id);
> if (!dev)
> return -EINVAL;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> index 31f3f24cef6a..043ee0467916 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> @@ -2581,9 +2581,54 @@ int svm_range_list_init(struct kfd_process *p)
> return 0;
> }
>
> +/**
> + * svm_range_is_vm_bo_mapped - check if virtual address range mapped already
I find the function name a bit confusing. The name suggests something
about a BO, but the description only talks about address ranges. Also,
there is no BO parameter.
Maybe a better name would be svm_range_check_vm.
> + * @p: current kfd_process
> + * @start: range start address, in pages
> + * @last: range last address, in pages
> + *
> + * The purpose is to avoid virtual address ranges already allocated by
> + * kfd_ioctl_alloc_memory_of_gpu ioctl.
> + * It looks for each pdd in the kfd_process.
> + *
> + * Context: Process context
> + *
> + * Return 0 - OK, if the range is not mapped.
> + * Otherwise error code:
> + * -EADDRINUSE - if address is mapped already by
> kfd_ioctl_alloc_memory_of_gpu
> + * -ERESTARTSYS - A wait for the buffer to become unreserved was interrupted
> by
> + * a signal. Release all buffer reservations and return to user-space.
> + */
> +static int
> +svm_range_is_vm_bo_mapped(struct kfd_process *p, uint64_t start, uint64_t
> last)
> +{
> + uint32_t i;
> + int r;
> +
> + for (i = 0; i < p->n_pdds; i++) {
> + struct amdgpu_vm *vm;
> +
> + if (!p->pdds[i]->drm_priv)
> + continue;
> +
> + vm = drm_priv_to_vm(p->pdds[i]->drm_priv);
> + r = amdgpu_bo_reserve(vm->root.bo, false);
> + if (r)
> + return r;
> + if (interval_tree_iter_first(>va, start, last)) {
> + pr_debug("Range [0x%llx 0x%llx] already mapped\n",
> start, last);
> + amdgpu_bo_unreserve(vm->root.bo);
> + return -EADDRINUSE;
> + }
> + amdgpu_bo_unreserve(vm->root.bo);
> + }
> +
> + return 0;
> +}
> +
> /**
> * svm_range_is_valid - check if virtual address range is valid
> - * @mm: current process mm_struct
> + * @mm: current kfd_process
Please fix the variable name here: mm -> p.
Regards,
Felix
> * @start: range start address, in pages
> * @size: range size, in pages
> *
> @@ -2592,28 +2637,27 @@ int svm_range_list_init(struct kfd_process *p)
> * Context: Process context
> *
> * Return:
> - * true - valid svm range
> - * false - invalid svm range
> + * 0 - OK, otherwise error code
> */
> -static bool
> -svm_range_is_valid(struct mm_struct *mm, uint64_t start, uint64_t size)
> +static int
> +svm_range_is_valid(struct kfd_process *p, uint64_t start, uint64_t size)
> {
>
[PATCH] drm/amdgpu: Fix channel_index table layout for Aldebaran
Fix the channel_index table layout to fetch the correct
channel_index when calculating physical address from
normalized address during page retirement.
Also, fix the number of UMC instances and number of channels
within each UMC instance for Aldebaran.
Signed-off-by: Mukul Joshi
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/umc_v6_7.c | 16
drivers/gpu/drm/amd/amdgpu/umc_v6_7.h | 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 7cf653f9e9a7..097230b5e946 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -1171,8 +1171,8 @@ static void gmc_v9_0_set_umc_funcs(struct amdgpu_device
*adev)
break;
case CHIP_ALDEBARAN:
adev->umc.max_ras_err_cnt_per_query =
UMC_V6_7_TOTAL_CHANNEL_NUM;
- adev->umc.channel_inst_num = UMC_V6_7_UMC_INSTANCE_NUM;
- adev->umc.umc_inst_num = UMC_V6_7_CHANNEL_INSTANCE_NUM;
+ adev->umc.channel_inst_num = UMC_V6_7_CHANNEL_INSTANCE_NUM;
+ adev->umc.umc_inst_num = UMC_V6_7_UMC_INSTANCE_NUM;
adev->umc.channel_offs = UMC_V6_7_PER_CHANNEL_OFFSET;
if (!adev->gmc.xgmi.connected_to_cpu)
adev->umc.ras_funcs = _v6_7_ras_funcs;
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
index 7da12110425c..bb30336b1e8d 100644
--- a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
+++ b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
@@ -30,17 +30,17 @@
const uint32_t
umc_v6_7_channel_idx_tbl_second[UMC_V6_7_UMC_INSTANCE_NUM][UMC_V6_7_CHANNEL_INSTANCE_NUM]
= {
- {28, 12, 6, 22},{19, 3, 9, 25},
- {20, 4, 30, 14},{11, 27, 1, 17},
- {24, 8, 2, 18}, {15, 31, 5, 21},
- {16, 0, 26, 10},{7, 23, 29, 13}
+ {28, 20, 24, 16, 12, 4, 8, 0},
+ {6, 30, 2, 26, 22, 14, 18, 10},
+ {19, 11, 15, 7, 3, 27, 31, 23},
+ {9, 1, 5, 29, 25, 17, 21, 13}
};
const uint32_t
umc_v6_7_channel_idx_tbl_first[UMC_V6_7_UMC_INSTANCE_NUM][UMC_V6_7_CHANNEL_INSTANCE_NUM]
= {
- {19, 3, 9, 25}, {28, 12, 6, 22},
- {11, 27, 1, 17},{20, 4, 30, 14},
- {15, 31, 5, 21},{24, 8, 2, 18},
- {7, 23, 29, 13},{16, 0, 26, 10}
+ {19, 11, 15, 7, 3, 27, 31, 23},
+ {9, 1, 5, 29, 25, 17, 21, 13},
+ {28, 20, 24, 16, 12, 4, 8, 0},
+ {6, 30, 2, 26, 22, 14, 18, 10},
};
static inline uint32_t get_umc_v6_7_reg_offset(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
index 81b8f1844091..57f2557e7aca 100644
--- a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
+++ b/drivers/gpu/drm/amd/amdgpu/umc_v6_7.h
@@ -36,9 +36,9 @@
#define UMC_V6_7_INST_DIST 0x4
/* number of umc channel instance with memory map register access */
-#define UMC_V6_7_CHANNEL_INSTANCE_NUM 4
+#define UMC_V6_7_UMC_INSTANCE_NUM 4
/* number of umc instance with memory map register access */
-#define UMC_V6_7_UMC_INSTANCE_NUM 8
+#define UMC_V6_7_CHANNEL_INSTANCE_NUM 8
/* total channel instances in one umc block */
#define UMC_V6_7_TOTAL_CHANNEL_NUM (UMC_V6_7_CHANNEL_INSTANCE_NUM *
UMC_V6_7_UMC_INSTANCE_NUM)
/* UMC regiser per channel offset */
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 03/14] drm/atmel-hlcdc: Convert to Linux IRQ interfaces
Hi
Am 29.07.21 um 21:24 schrieb dan.sned...@microchip.com:
Hi Thomas,
On 7/29/21 12:18 PM, Thomas Zimmermann wrote:
Hi
Am 28.07.21 um 22:11 schrieb Sam Ravnborg:
Hi Dan,
I think I got it - we need to set irq_enabled to true.
The documentation says so:
"
* @irq_enabled:
*
* Indicates that interrupt handling is enabled,
specifically vblank
* handling. Drivers which don't use drm_irq_install()
need to set this
* to true manually.
"
Can you try to add the following line:
+static int atmel_hlcdc_dc_irq_install(struct drm_device *dev,
unsigned int irq)
+{
+ int ret;
+
+ if (irq == IRQ_NOTCONNECTED)
+ return -ENOTCONN;
+
dev->irq_enabled = true; <= THIS LINE
+ atmel_hlcdc_dc_irq_disable(dev);
+
+ ret = request_irq(irq, atmel_hlcdc_dc_irq_handler, 0,
dev->driver->name, dev);
+ if (ret)
+ return ret;
I hope this fixes it.
It does! With the irq_enabled line added everything is looking good.
Are you sure, you're testing with the latest drm-misc-next or drm-tip?
Because using irq_enabled is deprecated and the flag was recently
replaced by commit 1e4cd78ed493 ("drm: Don't test for IRQ support in
VBLANK ioctls").
Best regards
Thomas
I was testing with 5.14-rc3. I can test with drm-tip or drm-misc-next.
There a preferred branch to test from?
I use drm-tip for development, but all the relevant patches go through
drm-misc-next. So either is fine.
Best regards
Thomas
Thanks and regards,
Dan
Great, thanks for testing.
Thomas - I assume you will do a re-spin and there is likely some fixes
for the applied IRQ conversions too.
Note - irq_enabled must be cleared if request_irq fails. I did not
include this in the testing here.
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
OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 03/14] drm/atmel-hlcdc: Convert to Linux IRQ interfaces
Hi
Am 29.07.21 um 21:18 schrieb Thomas Zimmermann:
Hi
Am 28.07.21 um 22:11 schrieb Sam Ravnborg:
Hi Dan,
I think I got it - we need to set irq_enabled to true.
The documentation says so:
"
* @irq_enabled:
*
* Indicates that interrupt handling is enabled,
specifically vblank
* handling. Drivers which don't use drm_irq_install()
need to set this
* to true manually.
"
Can you try to add the following line:
+static int atmel_hlcdc_dc_irq_install(struct drm_device *dev,
unsigned int irq)
+{
+ int ret;
+
+ if (irq == IRQ_NOTCONNECTED)
+ return -ENOTCONN;
+
dev->irq_enabled = true; <= THIS LINE
+ atmel_hlcdc_dc_irq_disable(dev);
+
+ ret = request_irq(irq, atmel_hlcdc_dc_irq_handler, 0,
dev->driver->name, dev);
+ if (ret)
+ return ret;
I hope this fixes it.
It does! With the irq_enabled line added everything is looking good.
Are you sure, you're testing with the latest drm-misc-next or drm-tip?
Because using irq_enabled is deprecated and the flag was recently
replaced by commit 1e4cd78ed493 ("drm: Don't test for IRQ support in
VBLANK ioctls").
For reference, the cover letter lists
base-commit: 2bda1ca4d4acb4892556fec3a7ea1f02afcd40bb
which is a recent drm-tip created on July 25.
Best regards
Thomas
Best regards
Thomas
Great, thanks for testing.
Thomas - I assume you will do a re-spin and there is likely some fixes
for the applied IRQ conversions too.
Note - irq_enabled must be cleared if request_irq fails. I did not
include this in the testing here.
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
OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 03/14] drm/atmel-hlcdc: Convert to Linux IRQ interfaces
Hi
Am 28.07.21 um 22:11 schrieb Sam Ravnborg:
Hi Dan,
I think I got it - we need to set irq_enabled to true.
The documentation says so:
"
* @irq_enabled:
*
* Indicates that interrupt handling is enabled, specifically vblank
* handling. Drivers which don't use drm_irq_install() need to set
this
* to true manually.
"
Can you try to add the following line:
+static int atmel_hlcdc_dc_irq_install(struct drm_device *dev, unsigned int irq)
+{
+ int ret;
+
+ if (irq == IRQ_NOTCONNECTED)
+ return -ENOTCONN;
+
dev->irq_enabled = true;<= THIS LINE
+ atmel_hlcdc_dc_irq_disable(dev);
+
+ ret = request_irq(irq, atmel_hlcdc_dc_irq_handler, 0,
dev->driver->name, dev);
+ if (ret)
+ return ret;
I hope this fixes it.
It does! With the irq_enabled line added everything is looking good.
Are you sure, you're testing with the latest drm-misc-next or drm-tip?
Because using irq_enabled is deprecated and the flag was recently
replaced by commit 1e4cd78ed493 ("drm: Don't test for IRQ support in
VBLANK ioctls").
Best regards
Thomas
Great, thanks for testing.
Thomas - I assume you will do a re-spin and there is likely some fixes
for the applied IRQ conversions too.
Note - irq_enabled must be cleared if request_irq fails. I did not
include this in the testing here.
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
OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: Linux Mint 20.04 5.11 issue
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 on anything 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 these would be related to the GPU driver. That said, when you boot with nomodeset, the GPU driver and all HW acceleration is completely disabled. If that makes the problem disappear, the GPU driver is clearly involved in the problem in some way. The abort points at a problem while freeing memory. This could be caused by a double-free problem in some unrelated code, possibly related to the GPU driver. This would be a problem in a user mode component (maybe Mesa), not the kernel mode driver. I believe the messages you're seeing when you move the mouse are the result of runtime power management that puts the GPU to sleep when it's idle and reinitializes it when it's needed. You have 2 GPUs in your laptop, an integrated Renoir GPU in the Ryzen CPU, and an external Navi10 GPU for higher gaming performance. The GPU that goes to sleep and wakes up is the external Navi10 GPU. The OpenGL renderer string specifies "RENOIR". Therefore I'm surprised that the Navi10 GPU wakes up when you move the mouse. Ideally it shouldn't be used at all when you're just using the desktop. If you suspect that runtime power management is responsible for your problems, you could disable it with amdgpu.runpm=0 on the kernel command line. That means the Navi10 GPU won't go into the low power mode and drain your battery more quickly. So this is not a permanent solution. Just an experiment to narrow down the problem. Regards, Felix > > I'm not sure how to do this as I haven't had to report a bug before. > I've looked to a variety of bug reporting sites to see if anyone else > is running into the same issues that I'm having (such as the Mate > project) and haven't seen anything at all similar to the issue I'm > having. Since I had issues with AMD drivers with my distro (info > below) and some consistent and high volume dmesg content shows up, > I've decided that I should start here with the AMD kernel team. > > I have a fairly new MSI laptop with the following configuration: > > [code] > System:Kernel: 5.11.0-25-generic x86_64 bits: 64 compiler: N/A > Desktop: MATE 1.24.0 wm: marco > dm: LightDM Distro: Linux Mint 20.2 Uma base: Ubuntu 20.04 > focal > Machine: Type: Laptop System: Micro-Star product: Alpha 17 A4DEK v: > REV:1.0 serial: > Chassis: type: 10 serial: > Mobo: Micro-Star model: MS-17EK v: REV:1.0 serial: > UEFI: American Megatrends > v: E17EKAMS.101 date: 10/26/2020 > Battery: ID-1: BAT1 charge: 66.2 Wh condition: 67.0/65.7 Wh (102%) > volts: 12.4/10.8 > model: MSI Corp. MS-17EK serial: N/A status: Unknown > CPU: Topology: 8-Core model: AMD Ryzen 7 4800H with Radeon > Graphics bits: 64 type: MT MCP > arch: Zen rev: 1 L2 cache: 4096 KiB > flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a > ssse3 svm bogomips: 92630 > Speed: 4278 MHz min/max: 1400/2900 MHz Core speeds (MHz): > 1: 4280 2: 1865 3: 1397 > 4: 2188 5: 1489 6: 2265 7: 1907 8: 1906 9: 1729 10: 1397 > 11: 1397 12: 1397 13: 1397 > 14: 1397 15: 1907 16: 1740 > Graphics: Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / > 5700/5700 XT] > vendor: Micro-Star MSI driver: amdgpu v: kernel bus ID: > 03:00.0 chip ID: 1002:731f > Device-2: AMD Renoir vendor: Micro-Star MSI driver: amdgpu > v: kernel bus ID: 08:00.0 > chip ID: 1002:1636 > Display: x11 server: X.Org 1.20.9 driver: amdgpu,ati > unloaded: fbdev,modesetting,radeon,vesa compositor: marco > resolution: 1920x1080~144Hz > OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.11.0-25-generic > LLVM 11.0.0) > v: 4.6 Mesa 20.2.6 direct render: Yes > Audio: Device-1: AMD Navi 10 HDMI Audio vendor: Micro-Star MSI > driver: snd_hda_intel v: kernel > bus ID: 03:00.1 chip ID: 1002:ab38 > Device-2: AMD Raven/Raven2/FireFlight/Renoir Audio > Processor vendor: Micro-Star MSI > driver: N/A bus ID: 08:00.5 chip ID: 1022:15e2 > Device-3: AMD Family 17h HD Audio vendor: Micro-Star MSI > driver: snd_hda_intel > v: kernel bus ID: 08:00.6 chip ID: 1022:15e3 > Sound Server: ALSA v: k5.11.0-25-generic > Network: Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel bus > ID: 04:00.0 > chip ID: 8086:2723 > IF: wlp4s0 state: up mac: > Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit > Ethernet vendor: Micro-Star MSI > driver: r8169 v: kernel port: f000 bus ID: 05:00.0 chip ID: > 10ec:8168 > IF: eno1 state: down mac: > Drives:Local Storage: total: 476.94 GiB
Re: [PATCH 02/11] x86/sev: Add an x86 version of prot_guest_has()
On 7/28/21 8:22 AM, Christoph Hellwig wrote: > On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote: >> Introduce an x86 version of the prot_guest_has() function. This will be >> used in the more generic x86 code to replace vendor specific calls like >> sev_active(), etc. >> >> While the name suggests this is intended mainly for guests, it will >> also be used for host memory encryption checks in place of sme_active(). >> >> The amd_prot_guest_has() function does not use EXPORT_SYMBOL_GPL for the >> same reasons previously stated when changing sme_active(), sev_active and > > None of that applies here as none of the callers get pulled into > random macros. The only case of that is sme_me_mask through > sme_mask, but that's not something this series replaces as far as I can > tell. Ok, let me make sure of that and I'll change to EXPORT_SYMBOL_GPL if that's the case. Thanks, Tom > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test
[Public]
Got you, so the target is to take this chance to make the code logic more clear
instead of making it just workable on top of mixed functionality code.
I will post a more reasonable patch later on to address this. Thank you.
Regards,
Guchun
-Original Message-
From: Christian König
Sent: Thursday, July 29, 2021 8:50 PM
To: Chen, Guchun ; Koenig, Christian
; amd-gfx@lists.freedesktop.org; Gao, Likun
; Zhang, Hawking ; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3
test
Hi Guchun,
see below.
Am 29.07.21 um 14:39 schrieb Chen, Guchun:
> [Public]
>
> Hi Christian,
>
> Thanks for your feedback.
>
> Originally, drm_sched_fini is part of amdgpu_fence_driver_hw_fini, I did not
> move it.
Yeah, not saying that this is your fault, you should just clean that up more
thoughtfully.
> Former patch " cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence "
> has dropped amdgpu_fence_driver_suspend, and called
> amdgpu_fence_driver_hw_fini instead in function amdgpu_device_suspend. I
> checked the code difference between amdgpu_fence_driver_hw_fini and
> amdgpu_device_suspend, they are almost the same except drm_sched_fini part,
> so I think we can leave it as it is, while skipping the execution of
> drm_sched_fini in suspend/resume case.
And exactly that's a bad idea and the reason why I already said during the
review of patch "cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence"
that the callers of those functions need to be adjusted instead.
1. If not already done please rename the functions as Hawking suggested as
well, they should be amdgpu_fence_driver_hw_(init|fini) and
amdgpu_fence_driver_sw_(init|fini).
2. Remove drm_sched_fini() from amdgpu_fence_driver_hw_fini() and add that to
sw_fini instead.
3. Adjust the callers so that we have the same functionality as before.
E.g. by calling both hw_fini and sw_fini at the same time.
Regards,
Christian.
>
> Regards,
> Guchun
>
> -Original Message-
> From: Koenig, Christian
> Sent: Thursday, July 29, 2021 7:11 PM
> To: Chen, Guchun ; amd-gfx@lists.freedesktop.org;
> Gao, Likun ; Zhang, Hawking
> ; Deucher, Alexander
>
> Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver
> fini in s3 test
>
> Am 29.07.21 um 12:49 schrieb Guchun Chen:
>> In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to
>> stop scheduler in s3 test, otherwise, fence errors will occur after resume.
>> So introduce a new parameter to distingiush the case in this API.
> NAK, the problem is rather that drm_sched_fini() is part of the sw shutdown
> and should never be called during hw_fini.
>
> Christian.
>
>> Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
>> Signed-off-by: Guchun Chen
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
>>drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
>>3 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index b1d2dc39e8be..aaff8ebbb7dc 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3844,7 +3844,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
>> else
>> drm_atomic_helper_shutdown(adev_to_drm(adev));
>> }
>> -amdgpu_fence_driver_hw_fini(adev);
>> +amdgpu_fence_driver_hw_fini(adev, false);
>>
>> if (adev->pm_sysfs_en)
>> amdgpu_pm_sysfs_fini(adev);
>> @@ -3941,7 +3941,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
>> fbcon)
>> /* evict vram memory */
>> amdgpu_bo_evict_vram(adev);
>>
>> -amdgpu_fence_driver_hw_fini(adev);
>> +amdgpu_fence_driver_hw_fini(adev, adev->in_suspend);
>>
>> amdgpu_device_ip_suspend_phase2(adev);
>> /* evict remaining vram memory
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> index 49c5c7331c53..7e6a73c2919d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> @@ -515,14 +515,15 @@ int amdgpu_fence_driver_init(struct amdgpu_device
>> *adev)
>>}
>>
>>/**
>> - * amdgpu_fence_driver_fini - tear down the fence driver
>> + * amdgpu_fence_driver_hw_fini - tear down the fence driver
>> * for all possible rings.
>> *
>> * @adev: amdgpu device pointer
>> + * @in_reset: indicator to distingiush device removal case or s3
>> + case
>> *
>> * Tear down the fence driver for all possible rings (all asics).
>> */
>> -void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
>> +void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool
>> +in_reset)
>>{
>> int i, r;
>>
>> @@ -531,8 +532,9 @@ void
RE: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test
[Public]
Hi Christian,
Thanks for your feedback.
Originally, drm_sched_fini is part of amdgpu_fence_driver_hw_fini, I did not
move it.
Former patch " cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence "
has dropped amdgpu_fence_driver_suspend, and called amdgpu_fence_driver_hw_fini
instead in function amdgpu_device_suspend. I checked the code difference
between amdgpu_fence_driver_hw_fini and amdgpu_device_suspend, they are almost
the same except drm_sched_fini part, so I think we can leave it as it is, while
skipping the execution of drm_sched_fini in suspend/resume case.
Regards,
Guchun
-Original Message-
From: Koenig, Christian
Sent: Thursday, July 29, 2021 7:11 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Gao,
Likun ; Zhang, Hawking ; Deucher,
Alexander
Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3
test
Am 29.07.21 um 12:49 schrieb Guchun Chen:
> In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to stop
> scheduler in s3 test, otherwise, fence errors will occur after resume.
> So introduce a new parameter to distingiush the case in this API.
NAK, the problem is rather that drm_sched_fini() is part of the sw shutdown and
should never be called during hw_fini.
Christian.
>
> Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
> Signed-off-by: Guchun Chen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
> 3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index b1d2dc39e8be..aaff8ebbb7dc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3844,7 +3844,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
> else
> drm_atomic_helper_shutdown(adev_to_drm(adev));
> }
> - amdgpu_fence_driver_hw_fini(adev);
> + amdgpu_fence_driver_hw_fini(adev, false);
>
> if (adev->pm_sysfs_en)
> amdgpu_pm_sysfs_fini(adev);
> @@ -3941,7 +3941,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
> fbcon)
> /* evict vram memory */
> amdgpu_bo_evict_vram(adev);
>
> - amdgpu_fence_driver_hw_fini(adev);
> + amdgpu_fence_driver_hw_fini(adev, adev->in_suspend);
>
> amdgpu_device_ip_suspend_phase2(adev);
> /* evict remaining vram memory
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> index 49c5c7331c53..7e6a73c2919d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> @@ -515,14 +515,15 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
> }
>
> /**
> - * amdgpu_fence_driver_fini - tear down the fence driver
> + * amdgpu_fence_driver_hw_fini - tear down the fence driver
>* for all possible rings.
>*
>* @adev: amdgpu device pointer
> + * @in_reset: indicator to distingiush device removal case or s3 case
>*
>* Tear down the fence driver for all possible rings (all asics).
>*/
> -void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
> +void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool
> +in_reset)
> {
> int i, r;
>
> @@ -531,8 +532,9 @@ void amdgpu_fence_driver_hw_fini(struct
> amdgpu_device *adev)
>
> if (!ring || !ring->fence_drv.initialized)
> continue;
> - if (!ring->no_scheduler)
> + if (!ring->no_scheduler && !in_reset)
> drm_sched_fini(>sched);
> +
> /* You can't wait for HW to signal if it's gone */
> if (!drm_dev_is_unplugged(>ddev))
> r = amdgpu_fence_wait_empty(ring); diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 27adffa7658d..42cbecfc26a3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -115,7 +115,7 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
> *ring,
> int amdgpu_fence_driver_start_ring(struct amdgpu_ring *ring,
> struct amdgpu_irq_src *irq_src,
> unsigned irq_type);
> -void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev);
> +void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool
> +in_reset);
> void amdgpu_fence_driver_sw_fini(struct amdgpu_device *adev);
> void amdgpu_fence_driver_hw_init(struct amdgpu_device *adev);
> int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence
> **fence,
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test
Am 29.07.21 um 12:49 schrieb Guchun Chen:
In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to stop
scheduler in s3 test, otherwise, fence errors will occur after resume.
So introduce a new parameter to distingiush the case in this API.
NAK, the problem is rather that drm_sched_fini() is part of the sw
shutdown and should never be called during hw_fini.
Christian.
Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b1d2dc39e8be..aaff8ebbb7dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3844,7 +3844,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
else
drm_atomic_helper_shutdown(adev_to_drm(adev));
}
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, false);
if (adev->pm_sysfs_en)
amdgpu_pm_sysfs_fini(adev);
@@ -3941,7 +3941,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
/* evict vram memory */
amdgpu_bo_evict_vram(adev);
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, adev->in_suspend);
amdgpu_device_ip_suspend_phase2(adev);
/* evict remaining vram memory
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 49c5c7331c53..7e6a73c2919d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -515,14 +515,15 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
}
/**
- * amdgpu_fence_driver_fini - tear down the fence driver
+ * amdgpu_fence_driver_hw_fini - tear down the fence driver
* for all possible rings.
*
* @adev: amdgpu device pointer
+ * @in_reset: indicator to distingiush device removal case or s3 case
*
* Tear down the fence driver for all possible rings (all asics).
*/
-void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
+void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool in_reset)
{
int i, r;
@@ -531,8 +532,9 @@ void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
if (!ring || !ring->fence_drv.initialized)
continue;
- if (!ring->no_scheduler)
+ if (!ring->no_scheduler && !in_reset)
drm_sched_fini(>sched);
+
/* You can't wait for HW to signal if it's gone */
if (!drm_dev_is_unplugged(>ddev))
r = amdgpu_fence_wait_empty(ring);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 27adffa7658d..42cbecfc26a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -115,7 +115,7 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
int amdgpu_fence_driver_start_ring(struct amdgpu_ring *ring,
struct amdgpu_irq_src *irq_src,
unsigned irq_type);
-void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev);
+void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool in_reset);
void amdgpu_fence_driver_sw_fini(struct amdgpu_device *adev);
void amdgpu_fence_driver_hw_init(struct amdgpu_device *adev);
int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **fence,
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test
In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to stop
scheduler in s3 test, otherwise, fence errors will occur after resume.
So introduce a new parameter to distingiush the case in this API.
Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b1d2dc39e8be..aaff8ebbb7dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3844,7 +3844,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
else
drm_atomic_helper_shutdown(adev_to_drm(adev));
}
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, false);
if (adev->pm_sysfs_en)
amdgpu_pm_sysfs_fini(adev);
@@ -3941,7 +3941,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
/* evict vram memory */
amdgpu_bo_evict_vram(adev);
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, adev->in_suspend);
amdgpu_device_ip_suspend_phase2(adev);
/* evict remaining vram memory
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 49c5c7331c53..7e6a73c2919d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -515,14 +515,15 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
}
/**
- * amdgpu_fence_driver_fini - tear down the fence driver
+ * amdgpu_fence_driver_hw_fini - tear down the fence driver
* for all possible rings.
*
* @adev: amdgpu device pointer
+ * @in_reset: indicator to distingiush device removal case or s3 case
*
* Tear down the fence driver for all possible rings (all asics).
*/
-void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
+void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool in_reset)
{
int i, r;
@@ -531,8 +532,9 @@ void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
if (!ring || !ring->fence_drv.initialized)
continue;
- if (!ring->no_scheduler)
+ if (!ring->no_scheduler && !in_reset)
drm_sched_fini(>sched);
+
/* You can't wait for HW to signal if it's gone */
if (!drm_dev_is_unplugged(>ddev))
r = amdgpu_fence_wait_empty(ring);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 27adffa7658d..42cbecfc26a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -115,7 +115,7 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
int amdgpu_fence_driver_start_ring(struct amdgpu_ring *ring,
struct amdgpu_irq_src *irq_src,
unsigned irq_type);
-void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev);
+void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool in_reset);
void amdgpu_fence_driver_sw_fini(struct amdgpu_device *adev);
void amdgpu_fence_driver_hw_init(struct amdgpu_device *adev);
int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **fence,
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/display: Fix typo in comments
Remove the repeated word 'the' from comments Signed-off-by: Cai Huoqing --- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +- .../gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c | 2 +- .../drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c | 2 +- .../gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 2 +- .../gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c | 2 +- .../gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c | 2 +- drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c | 4 ++-- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c index 1596f6b7fed7..7f12ca902f7d 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c @@ -1030,7 +1030,7 @@ bool resource_build_scaling_params(struct pipe_ctx *pipe_ctx) /* Timing borders are part of vactive that we are also supposed to skip in addition * to any stream dst offset. Since dm logic assumes dst is in addressable -* space we need to add the the left and top borders to dst offsets temporarily. +* space we need to add the left and top borders to dst offsets temporarily. * TODO: fix in DM, stream dst is supposed to be in vactive */ pipe_ctx->stream->dst.x += timing->h_border_left; diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c index 799bae229e67..2091dd8c252d 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c @@ -488,7 +488,7 @@ static void get_meta_and_pte_attr(struct display_mode_lib *mode_lib, log2_meta_req_bytes = 6; // meta request is 64b and is 8x8byte meta element // each 64b meta request for dcn is 8x8 meta elements and - // a meta element covers one 256b block of the the data surface. + // a meta element covers one 256b block of the data surface. log2_meta_req_height = log2_blk256_height + 3; // meta req is 8x8 byte, each byte represent 1 blk256 log2_meta_req_width = log2_meta_req_bytes + 8 - log2_bytes_per_element - log2_meta_req_height; diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c index 6a6d5970d1d5..1a0c14e465fa 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c @@ -488,7 +488,7 @@ static void get_meta_and_pte_attr(struct display_mode_lib *mode_lib, log2_meta_req_bytes = 6; // meta request is 64b and is 8x8byte meta element // each 64b meta request for dcn is 8x8 meta elements and - // a meta element covers one 256b block of the the data surface. + // a meta element covers one 256b block of the data surface. log2_meta_req_height = log2_blk256_height + 3; // meta req is 8x8 byte, each byte represent 1 blk256 log2_meta_req_width = log2_meta_req_bytes + 8 - log2_bytes_per_element - log2_meta_req_height; diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c index dc1c81a6e377..287e31052b30 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c @@ -482,7 +482,7 @@ static void get_meta_and_pte_attr( log2_meta_req_bytes = 6; // meta request is 64b and is 8x8byte meta element // each 64b meta request for dcn is 8x8 meta elements and - // a meta element covers one 256b block of the the data surface. + // a meta element covers one 256b block of the data surface. log2_meta_req_height = log2_blk256_height + 3; // meta req is 8x8 byte, each byte represent 1 blk256 log2_meta_req_width = log2_meta_req_bytes + 8 - log2_bytes_per_element - log2_meta_req_height; diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c index 04601a767a8f..0d934fae1c3a 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c @@ -549,7 +549,7 @@ static void get_meta_and_pte_attr(struct display_mode_lib *mode_lib, log2_meta_req_bytes = 6; // meta request is 64b and is 8x8byte meta element // each 64b meta request for dcn is 8x8 meta elements and -// a meta element covers one 256b block of the the data
[PATCH] drm/amdgpu/powerplay/smu10: Fix a typo in error message
This patch fixes a spelling typo in error message.
Signed-off-by: Masanari Iida
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
index 43c3f6e755e7..7dd92bdf7ffb 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
@@ -1580,7 +1580,7 @@ static int smu10_set_fine_grain_clk_vol(struct pp_hwmgr
*hwmgr,
}
if (smu10_data->gfx_actual_soft_min_freq >
smu10_data->gfx_actual_soft_max_freq) {
- pr_err("The setting minimun sclk (%d) MHz is greater
than the setting maximum sclk (%d) MHz\n",
+ pr_err("The setting minimum sclk (%d) MHz is greater
than the setting maximum sclk (%d) MHz\n",
smu10_data->gfx_actual_soft_min_freq,
smu10_data->gfx_actual_soft_max_freq);
return -EINVAL;
}
--
2.25.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] gpu/drm/radeon: Fix typo in comments
Remove the repeated word 'the' from comments Signed-off-by: Cai Huoqing --- drivers/gpu/drm/radeon/atombios.h | 4 ++-- drivers/gpu/drm/radeon/r300_reg.h | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/gpu/drm/radeon/radeon_fence.c | 2 +- drivers/gpu/drm/radeon/radeon_vm.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios.h b/drivers/gpu/drm/radeon/atombios.h index 4b86e8b45009..83e8b8547f9b 100644 --- a/drivers/gpu/drm/radeon/atombios.h +++ b/drivers/gpu/drm/radeon/atombios.h @@ -2802,8 +2802,8 @@ ucMaxNBVoltageHigh: Voltage regulator dependent PWM value. High 8 bits of t ucMinNBVoltageHigh: Voltage regulator dependent PWM value. High 8 bits of the value for the min voltage.Set this one to 0x00 if VC without PWM or no VC at all. -usInterNBVoltageLow:Voltage regulator dependent PWM value. The value makes the the voltage >=Min NB voltage but <=InterNBVoltageHigh. Set this to 0x if VC without PWM or no VC at all. -usInterNBVoltageHigh: Voltage regulator dependent PWM value. The value makes the the voltage >=InterNBVoltageLow but <=Max NB voltage.Set this to 0x if VC without PWM or no VC at all. +usInterNBVoltageLow:Voltage regulator dependent PWM value. The value makes the voltage >=Min NB voltage but <=InterNBVoltageHigh. Set this to 0x if VC without PWM or no VC at all. +usInterNBVoltageHigh: Voltage regulator dependent PWM value. The value makes the voltage >=InterNBVoltageLow but <=Max NB voltage.Set this to 0x if VC without PWM or no VC at all. */ diff --git a/drivers/gpu/drm/radeon/r300_reg.h b/drivers/gpu/drm/radeon/r300_reg.h index 00c0d2ba22d3..60d5413bafa1 100644 --- a/drivers/gpu/drm/radeon/r300_reg.h +++ b/drivers/gpu/drm/radeon/r300_reg.h @@ -353,7 +353,7 @@ # define R300_PVS_CNTL_1_PROGRAM_START_SHIFT 0 # define R300_PVS_CNTL_1_POS_END_SHIFT 10 # define R300_PVS_CNTL_1_PROGRAM_END_SHIFT 20 -/* Addresses are relative the the vertex program parameters area. */ +/* Addresses are relative the vertex program parameters area. */ #define R300_VAP_PVS_CNTL_2 0x22D4 # define R300_PVS_CNTL_2_PARAM_OFFSET_SHIFT 0 # define R300_PVS_CNTL_2_PARAM_COUNT_SHIFT 16 diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index cec03238e14d..ac8c3251b616 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -406,7 +406,7 @@ void radeon_doorbell_free(struct radeon_device *rdev, u32 doorbell) /* * radeon_wb_*() - * Writeback is the the method by which the the GPU updates special pages + * Writeback is the method by which the GPU updates special pages * in memory with the status of certain GPU events (fences, ring pointers, * etc.). */ diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 18f2c2e0dfb3..e9c47ec28ade 100644 --- a/drivers/gpu/drm/radeon/radeon_fence.c +++ b/drivers/gpu/drm/radeon/radeon_fence.c @@ -50,7 +50,7 @@ * for GPU/CPU synchronization. When the fence is written, * it is expected that all buffers associated with that fence * are no longer in use by the associated ring on the GPU and - * that the the relevant GPU caches have been flushed. Whether + * that the relevant GPU caches have been flushed. Whether * we use a scratch register or memory location depends on the asic * and whether writeback is enabled. */ diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c index 36a38adaaea9..bb53016f3138 100644 --- a/drivers/gpu/drm/radeon/radeon_vm.c +++ b/drivers/gpu/drm/radeon/radeon_vm.c @@ -41,7 +41,7 @@ * (uncached system pages). * Each VM has an ID associated with it and there is a page table * associated with each VMID. When execting a command buffer, - * the kernel tells the the ring what VMID to use for that command + * the kernel tells the ring what VMID to use for that command * buffer. VMIDs are allocated dynamically as commands are submitted. * The userspace drivers maintain their own address space and the kernel * sets up their pages tables accordingly when they submit their -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH v4] drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 03acc777adf7..ab79ca770dcd 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1295,6 +1295,16 @@ static bool is_raven_kicker(struct amdgpu_device *adev)
return false;
}
+static bool check_if_enlarge_doorbell_range(struct amdgpu_device *adev)
+{
+ if ((adev->asic_type == CHIP_RENOIR) &&
+ (adev->gfx.me_fw_version >= 0x00a5) &&
+ (adev->gfx.me_feature_version >= 52))
+ return true;
+ else
+ return false;
+}
+
static void gfx_v9_0_check_if_need_gfxoff(struct amdgpu_device *adev)
{
if (gfx_v9_0_should_disable_gfxoff(adev->pdev))
@@ -3675,7 +3685,16 @@ static int gfx_v9_0_kiq_init_register(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
(adev->doorbell_index.kiq * 2) << 2);
- WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ /* If GC has entered CGPG, ringing doorbell > first page
+* doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to
+* workaround this issue. And this change has to align with
firmware
+* update.
+*/
+ if (check_if_enlarge_doorbell_range(adev))
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ (adev->doorbell.size - 4));
+ else
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
(adev->doorbell_index.userqueue_end *
2) << 2);
}
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test
Exactly that yes.
Thanks,
Christian.
Am 29.07.21 um 14:56 schrieb Chen, Guchun:
[Public]
Got you, so the target is to take this chance to make the code logic more clear
instead of making it just workable on top of mixed functionality code.
I will post a more reasonable patch later on to address this. Thank you.
Regards,
Guchun
-Original Message-
From: Christian König
Sent: Thursday, July 29, 2021 8:50 PM
To: Chen, Guchun ; Koenig, Christian ;
amd-gfx@lists.freedesktop.org; Gao, Likun ; Zhang, Hawking
; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3
test
Hi Guchun,
see below.
Am 29.07.21 um 14:39 schrieb Chen, Guchun:
[Public]
Hi Christian,
Thanks for your feedback.
Originally, drm_sched_fini is part of amdgpu_fence_driver_hw_fini, I did not
move it.
Yeah, not saying that this is your fault, you should just clean that up more
thoughtfully.
Former patch " cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence "
has dropped amdgpu_fence_driver_suspend, and called amdgpu_fence_driver_hw_fini instead
in function amdgpu_device_suspend. I checked the code difference between
amdgpu_fence_driver_hw_fini and amdgpu_device_suspend, they are almost the same except
drm_sched_fini part, so I think we can leave it as it is, while skipping the execution of
drm_sched_fini in suspend/resume case.
And exactly that's a bad idea and the reason why I already said during the review of
patch "cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence" that the
callers of those functions need to be adjusted instead.
1. If not already done please rename the functions as Hawking suggested as
well, they should be amdgpu_fence_driver_hw_(init|fini) and
amdgpu_fence_driver_sw_(init|fini).
2. Remove drm_sched_fini() from amdgpu_fence_driver_hw_fini() and add that to
sw_fini instead.
3. Adjust the callers so that we have the same functionality as before.
E.g. by calling both hw_fini and sw_fini at the same time.
Regards,
Christian.
Regards,
Guchun
-Original Message-
From: Koenig, Christian
Sent: Thursday, July 29, 2021 7:11 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org;
Gao, Likun ; Zhang, Hawking
; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver
fini in s3 test
Am 29.07.21 um 12:49 schrieb Guchun Chen:
In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to
stop scheduler in s3 test, otherwise, fence errors will occur after resume.
So introduce a new parameter to distingiush the case in this API.
NAK, the problem is rather that drm_sched_fini() is part of the sw shutdown and
should never be called during hw_fini.
Christian.
Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b1d2dc39e8be..aaff8ebbb7dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3844,7 +3844,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
else
drm_atomic_helper_shutdown(adev_to_drm(adev));
}
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, false);
if (adev->pm_sysfs_en)
amdgpu_pm_sysfs_fini(adev);
@@ -3941,7 +3941,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
/* evict vram memory */
amdgpu_bo_evict_vram(adev);
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, adev->in_suspend);
amdgpu_device_ip_suspend_phase2(adev);
/* evict remaining vram memory
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 49c5c7331c53..7e6a73c2919d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -515,14 +515,15 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
}
/**
- * amdgpu_fence_driver_fini - tear down the fence driver
+ * amdgpu_fence_driver_hw_fini - tear down the fence driver
* for all possible rings.
*
* @adev: amdgpu device pointer
+ * @in_reset: indicator to distingiush device removal case or s3
+ case
*
* Tear down the fence driver for all possible rings (all asics).
*/
-void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
+void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool
+in_reset)
{
int i, r;
@@ -531,8 +532,9 @@ void amdgpu_fence_driver_hw_fini(struct
amdgpu_device *adev)
if (!ring || !ring->fence_drv.initialized)
Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test
Hi Guchun,
see below.
Am 29.07.21 um 14:39 schrieb Chen, Guchun:
[Public]
Hi Christian,
Thanks for your feedback.
Originally, drm_sched_fini is part of amdgpu_fence_driver_hw_fini, I did not
move it.
Yeah, not saying that this is your fault, you should just clean that up
more thoughtfully.
Former patch " cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence "
has dropped amdgpu_fence_driver_suspend, and called amdgpu_fence_driver_hw_fini instead
in function amdgpu_device_suspend. I checked the code difference between
amdgpu_fence_driver_hw_fini and amdgpu_device_suspend, they are almost the same except
drm_sched_fini part, so I think we can leave it as it is, while skipping the execution of
drm_sched_fini in suspend/resume case.
And exactly that's a bad idea and the reason why I already said during
the review of patch "cd87a6dcf6af drm/amdgpu: adjust fence driver enable
sequence" that the callers of those functions need to be adjusted instead.
1. If not already done please rename the functions as Hawking suggested
as well, they should be amdgpu_fence_driver_hw_(init|fini) and
amdgpu_fence_driver_sw_(init|fini).
2. Remove drm_sched_fini() from amdgpu_fence_driver_hw_fini() and add
that to sw_fini instead.
3. Adjust the callers so that we have the same functionality as before.
E.g. by calling both hw_fini and sw_fini at the same time.
Regards,
Christian.
Regards,
Guchun
-Original Message-
From: Koenig, Christian
Sent: Thursday, July 29, 2021 7:11 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Gao, Likun
; Zhang, Hawking ; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3
test
Am 29.07.21 um 12:49 schrieb Guchun Chen:
In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to stop
scheduler in s3 test, otherwise, fence errors will occur after resume.
So introduce a new parameter to distingiush the case in this API.
NAK, the problem is rather that drm_sched_fini() is part of the sw shutdown and
should never be called during hw_fini.
Christian.
Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b1d2dc39e8be..aaff8ebbb7dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3844,7 +3844,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
else
drm_atomic_helper_shutdown(adev_to_drm(adev));
}
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, false);
if (adev->pm_sysfs_en)
amdgpu_pm_sysfs_fini(adev);
@@ -3941,7 +3941,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
/* evict vram memory */
amdgpu_bo_evict_vram(adev);
- amdgpu_fence_driver_hw_fini(adev);
+ amdgpu_fence_driver_hw_fini(adev, adev->in_suspend);
amdgpu_device_ip_suspend_phase2(adev);
/* evict remaining vram memory
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 49c5c7331c53..7e6a73c2919d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -515,14 +515,15 @@ int amdgpu_fence_driver_init(struct amdgpu_device *adev)
}
/**
- * amdgpu_fence_driver_fini - tear down the fence driver
+ * amdgpu_fence_driver_hw_fini - tear down the fence driver
* for all possible rings.
*
* @adev: amdgpu device pointer
+ * @in_reset: indicator to distingiush device removal case or s3 case
*
* Tear down the fence driver for all possible rings (all asics).
*/
-void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
+void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev, bool
+in_reset)
{
int i, r;
@@ -531,8 +532,9 @@ void amdgpu_fence_driver_hw_fini(struct
amdgpu_device *adev)
if (!ring || !ring->fence_drv.initialized)
continue;
- if (!ring->no_scheduler)
+ if (!ring->no_scheduler && !in_reset)
drm_sched_fini(>sched);
+
/* You can't wait for HW to signal if it's gone */
if (!drm_dev_is_unplugged(>ddev))
r = amdgpu_fence_wait_empty(ring); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 27adffa7658d..42cbecfc26a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -115,7 +115,7 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
Re: [PATCH v3] drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.
On 7/29/2021 1:25 PM, Yifan Zhang wrote:
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 03acc777adf7..a35f1d041a85 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3675,7 +3675,18 @@ static int gfx_v9_0_kiq_init_register(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
(adev->doorbell_index.kiq * 2) << 2);
- WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ /* In renoir, if GC has entered CGPG, ringing doorbell > first
page
+* doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to
+* workaround this issue. And this change has to align with
firmware
+* update.
+*/
+ if ((adev->asic_type == CHIP_RENOIR) &&
+ (adev->gfx.me_fw_version >= 0x00a5) &&
+ (adev->gfx.me_feature_version >= 52))
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ (adev->doorbell.size - 4));
For better readability, perhaps
if (extended_doorbell_range(adev))
...
else
...
and move the ASIC and FW version check inside extended_doorbell_range.
Thanks,
Lijo
+ else
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
(adev->doorbell_index.userqueue_end * 2)
<< 2);
}
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH v2] drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.
Agree. Patch updated. Thanks.
-Original Message-
From: Alex Deucher
Sent: Thursday, July 29, 2021 10:24 AM
To: Zhang, Yifan
Cc: amd-gfx list
Subject: Re: [PATCH v2] drm/amdgpu: fix the doorbell missing when in CGPG issue
for renoir.
On Wed, Jul 28, 2021 at 9:33 PM Zhang, Yifan wrote:
>
> Hi Alex,
>
> No, it won't break gfxoff. The "gfxoff broken" issue we saw last time has
> been fixed on CP firmware update for Renoir, and this patch changes doorbell
> range setting specifically for Renoir, not covering the other ASICs. I think
> it is better to change doorbell range setting per ASIC to mitigate possible
> side effects.
>
Thanks. Do we need a firmware version check to determine when to set the range
differently?
Alex
> BRs,
> Yifan
>
> -Original Message-
> From: Alex Deucher
> Sent: Wednesday, July 28, 2021 9:46 PM
> To: Zhang, Yifan
> Cc: amd-gfx list
> Subject: Re: [PATCH v2] drm/amdgpu: fix the doorbell missing when in CGPG
> issue for renoir.
>
> On Wed, Jul 28, 2021 at 2:10 AM Yifan Zhang wrote:
> >
> > If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
> > Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
> >
> > Signed-off-by: Yifan Zhang
>
> I assume this won't break gfxoff? The last time we changed this, it broke a
> bunch of scenarios. Won't this cause just about all doorbells to wake gfx?
>
> Alex
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > index 03acc777adf7..70b64b510743 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > @@ -3675,7 +3675,15 @@ static int gfx_v9_0_kiq_init_register(struct
> > amdgpu_ring *ring)
> > if (ring->use_doorbell) {
> > WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
> > (adev->doorbell_index.kiq * 2) <<
> > 2);
> > - WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
> > + /* In renoir, if GC has entered CGPG, ringing doorbell >
> > first page
> > +* doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to
> > +* workaround this issue.
> > +*/
> > + if (adev->asic_type == CHIP_RENOIR)
> > + WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
> > + (adev->doorbell.size - 4));
> > + else
> > + WREG32_SOC15(GC, 0,
> > + mmCP_MEC_DOORBELL_RANGE_UPPER,
> > (adev->doorbell_index.userqueue_end
> > * 2) << 2);
> > }
> >
> > --
> > 2.25.1
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > st
> > s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7C
> > yi
> > fan1.zhang%40amd.com%7C4a2605541c22483b4a3a08d951ce097c%7C3dd8961fe4
> > 88
> > 4e608e11a82d994e183d%7C0%7C0%7C637630767650055129%7CUnknown%7CTWFpbG
> > Zs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D
> > %7C1000sdata=1TIsNslKHeSNNMDR3MHPaIiP%2BSLVrr5cEfAbCmvZlCw%3D
> > mp
> > ;reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH v3] drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 03acc777adf7..a35f1d041a85 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3675,7 +3675,18 @@ static int gfx_v9_0_kiq_init_register(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
(adev->doorbell_index.kiq * 2) << 2);
- WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ /* In renoir, if GC has entered CGPG, ringing doorbell > first
page
+* doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to
+* workaround this issue. And this change has to align with
firmware
+* update.
+*/
+ if ((adev->asic_type == CHIP_RENOIR) &&
+ (adev->gfx.me_fw_version >= 0x00a5) &&
+ (adev->gfx.me_feature_version >= 52))
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ (adev->doorbell.size - 4));
+ else
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
(adev->doorbell_index.userqueue_end *
2) << 2);
}
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 10/14] drm/tidss: Convert to Linux IRQ interfaces
On 27/07/2021 21:27, Thomas Zimmermann wrote: Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. DRM IRQ callbacks are now being called directly or inlined. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/tidss/tidss_drv.c | 15 +-- drivers/gpu/drm/tidss/tidss_drv.h | 2 ++ drivers/gpu/drm/tidss/tidss_irq.c | 27 --- drivers/gpu/drm/tidss/tidss_irq.h | 4 +--- 4 files changed, 32 insertions(+), 16 deletions(-) Reviewed-by: Tomi Valkeinen Works fine on AM6 EVM. Some cleanups can be done in tidss_irq_install(), but those can be done later. Tomi ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[pull] amdgpu drm-fixes-5.14
Hi Dave, Daniel, Fixes for 5.14. The following changes since commit ff1176468d368232b684f75e82563369208bc371: Linux 5.14-rc3 (2021-07-25 15:35:14 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.14-2021-07-28 for you to fetch changes up to ec30ce41f03820b6289513344b4281ca3a1151f4: maintainers: add bugs and chat URLs for amdgpu (2021-07-27 12:48:59 -0400) amd-drm-fixes-5.14-2021-07-28: amdgpu: - Fix resource leak in an error path - Avoid stack contents exposure in error path - pmops check fix for S0ix vs S3 - DCN 2.1 display fixes - DCN 2.0 display fix - Backlight control fix for laptops with HDR panels - Maintainers updates Alex Deucher (1): drm/amdgpu/display: only enable aux backlight control for OLED panels Dale Zhao (1): drm/amd/display: ensure dentist display clock update finished in DCN20 Jiri Kosina (2): drm/amdgpu: Fix resource leak on probe error path drm/amdgpu: Avoid printing of stack contents on firmware load error Pratik Vishwakarma (1): drm/amdgpu: Check pmops for desired suspend state Simon Ser (1): maintainers: add bugs and chat URLs for amdgpu Victor Lu (2): drm/amd/display: Guard DST_Y_PREFETCH register overflow in DCN21 drm/amd/display: Add missing DCN21 IP parameter MAINTAINERS| 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++-- drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 7 +++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 + drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 3 +++ 8 files changed, 16 insertions(+), 14 deletions(-) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
