[Why]
On Navi10, and presumably arcterus, updating pp_table via sysfs would
not re-scale the maximum possible power limit one can set. On navi10,
the SMU code ignored the power percentage overdrive setting entirely,
and would not allow you to exceed the default power limit at all.
[How]
Adding a
Acked-by: Alex Deucher
From: amd-gfx on behalf of Bhawanpreet
Lakha
Sent: Friday, November 8, 2019 4:57 PM
To: amd-gfx@lists.freedesktop.org
Cc: Lakha, Bhawanpreet
Subject: [PATCH] drm/amd/display: Load TA firmware for navi10/12/14
load the ta firmware for
load the ta firmware for navi10/12/14.
This is already being done for raven/picasso and
is needed for supporting hdcp on navi
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 25 +
1 file changed, 25 insertions(+)
diff --git
[Why]
Before this patch, navi10 overdrive settings could not be printed via
pp_od_clk_voltage
[How]
Implement printing for the overdrive settings for the following clocks
in navi10's ppt print_clk_levels implementation:
* SMU_OD_SCLK
* SMU_OD_MCLK
* SMU_OD_VDDC_CURVE
---
[Why]
Before this patch, there was no way to set the gfxclk voltage curve in
the overdrive settings for navi10 through pp_od_clk_voltage
[How]
Add the required implementation to navi10's ppt dpm table editing
implementation, similar to the vega20 implementation and interface.
---
[Why]
Before this patch, there was no way to use pp_od_clk_voltage on navi
[How]
Similar to the vega20 implementation, but using the common smc_v11_0
headers, implemented the pp_od_clk_voltage API for navi10's pptable
implementation
---
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +
[Why]
Before this patchset, navi10 users could not utilize the overdrive
functionality. This prevented them from overclocking, overvolting, or
undervolting their cards.
[How]
Similar to the vega20 implementation, add the pp_od_clk_voltage
interface to the navi10 powerplay table.
[Possible
Hi Dave, Daniel,
Fixes for 5.5.
The following changes since commit cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d:
drm/i915: Don't select BROKEN (2019-11-06 05:46:04 +1000)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-11-08
for you to
On Thu, Nov 07, 2019 at 09:00:34PM -0500, Jerome Glisse wrote:
> On Fri, Nov 08, 2019 at 12:32:25AM +, Jason Gunthorpe wrote:
> > On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> > > On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > > > On Wed, Nov 06, 2019
Hey guys,
This patch caused some kind of reversion with smu_reset on Navi10. I'm
no expert since everything I know comes from just reading through the
code, so this could be some kind of intended behavior, but after this
patch, if you write a pptable to the sysfs pp_table interface on navi10,
On 11/8/19 5:54 AM, Deng, Emily wrote:
> Hi Christian,
> Sorry, seems I understand wrong. And from the print, the free job's
> thread is the same as job timeout thread. So seems have some issue in
> function amdgpu_device_gpu_recover.
I don't think it's correct, seems your prints just
On 11/8/19 5:35 AM, Koenig, Christian wrote:
> Hi Emily,
>
> exactly that can't happen. See here:
>
>> /* Don't destroy jobs while the timeout worker is running */
>> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
>> !cancel_delayed_work(>work_tdr))
>>
On Fri, Nov 8, 2019 at 11:29 AM Colin King wrote:
>
> From: Colin Ian King
>
> Variable status is redundant, it is being initialized with a value
> that is over-written later and this is being returned immediately
> after the assignment. Clean up the code by removing status and
> just returning
On 2019-11-08 11:24 a.m., Alex Deucher wrote:
> dm_dcn_crtc_high_irq() is only used when CONFIG_DRM_AMD_DC_DCN is set.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Nicholas Kazlauskas
Thanks!
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
> 1 file changed, 2
From: Colin Ian King
Variable status is redundant, it is being initialized with a value
that is over-written later and this is being returned immediately
after the assignment. Clean up the code by removing status and
just returning the value returned from the call to function
Applied. thanks!
Alex
On Fri, Nov 8, 2019 at 9:42 AM Mikita Lipski wrote:
>
> Thanks!
>
> Reviewed-by: Mikita Lipski
>
> On 08.11.2019 9:38, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently pointer aconnector is being dereferenced by the call to
> > to_dm_connector_state before
On Fri, Nov 8, 2019 at 9:45 AM Colin King wrote:
>
> From: Colin Ian King
>
> Variable grph_obj_type is being assigned twice, one of these is
> redundant so remove it.
>
> Addresses-Coverity: ("Evaluation order violation")
> Signed-off-by: Colin Ian King
Applied. Thanks!
> ---
>
dm_dcn_crtc_high_irq() is only used when CONFIG_DRM_AMD_DC_DCN is set.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
When a custom powerplay table is provided, we need to update
the OD VDDC flag to avoid AVFS being enabled when it shouldn't be.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 +++
1 file changed, 7
On Thu, Nov 07, 2019 at 12:53:56PM -0800, John Hubbard wrote:
> > > > +/**
> > > > + * struct mmu_range_notifier_ops
> > > > + * @invalidate: Upon return the caller must stop using any SPTEs
> > > > within this
> > > > + * range, this function can sleep. Return false if
> > > >
From: Colin Ian King
Currently pointer aconnector is being dereferenced by the call to
to_dm_connector_state before it is being null checked, this could
lead to a null pointer dereference. Fix this by checking that
aconnector is null before dereferencing it.
Addresses-Coverity: ("Dereference
On Thu, Nov 07, 2019 at 05:54:52PM -0500, Boris Ostrovsky wrote:
> On 11/7/19 3:36 PM, Jason Gunthorpe wrote:
> > On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
> >
> >>> So, I suppose it can be relaxed to a null test and a WARN_ON that it
> >>> hasn't changed?
> >> You mean
> >>
From: Colin Ian King
Currently the error check on the call to drm_dp_atomic_find_vcpi_slots
is always false because an unsigned dm_new_connector_state->vcpi_slots
is being checked for a less than zero. Fix this by casting this to
an int on the comparison.
Addresses-Coverity: ("Unsigned compared
On Fri, Nov 08, 2019 at 12:24:42PM +0100, Rafael J. Wysocki wrote:
> On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> > There is no need to cast a typed pointer to a void pointer when calling
> > a function that accepts the latter. Remove it, as the cast prevents
> > further
From: Colin Ian King
Variable grph_obj_type is being assigned twice, one of these is
redundant so remove it.
Addresses-Coverity: ("Evaluation order violation")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 3 +--
1 file changed, 1 insertion(+), 2
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
Greg, have you
In the highly unlikely event that we fail to allocate the "radeon-crtc"
workqueue, we should bail cleanly rather than blindly marching on with a
NULL pointer installed for the 'flip_queue' field of the 'radeon_crtc'
structure.
This was reported previously by Nicolas, but I don't think his fix was
Do we need something similar for vega20?
Alex
From: amd-gfx on behalf of Kenneth Feng
Sent: Friday, November 8, 2019 12:42 AM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH v2] drm/amd/powerplay: dynamically disable ds and ulv for
Thanks!
Reviewed-by: Mikita Lipski
On 08.11.2019 9:38, Colin King wrote:
> From: Colin Ian King
>
> Currently pointer aconnector is being dereferenced by the call to
> to_dm_connector_state before it is being null checked, this could
> lead to a null pointer dereference. Fix this by checking
What about picasso and raven1?
From: amd-gfx on behalf of Zhu,
Changfeng
Sent: Thursday, November 7, 2019 8:54 PM
To: amd-gfx@lists.freedesktop.org ; Zhang,
Hawking ; Huang, Ray
Cc: Zhu, Changfeng
Subject: [PATCH] drm/amdgpu: allow direct upload save restore
On Thu, Nov 07, 2019 at 10:33:02PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> > >
> > > enum mmu_range_notifier_event {
> > > MMU_NOTIFY_RELEASE,
> > > };
> > >
> > > ...assuming that we stay with "mmu_range_notifier" as a core name for
On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> As mentioned by Christian, for drivers which support only primary nodes
> this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
>
> For others, this check in particular will be a noop. So let's remove it
Hi Christian,
Sorry, seems I understand wrong. And from the print, the free job's thread
is the same as job timeout thread. So seems have some issue in function
amdgpu_device_gpu_recover.
Best wishes
Emily Deng
>-Original Message-
>From: Koenig, Christian
>Sent: Friday,
Hi Emily,
exactly that can't happen. See here:
> /* Don't destroy jobs while the timeout worker is running */
> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> !cancel_delayed_work(>work_tdr))
> return NULL;
We never free jobs while the timeout
Hi Christian,
The drm_sched_job_timedout-> amdgpu_job_timedout call
amdgpu_device_gpu_recover. I mean the main scheduler free the jobs while in
amdgpu_device_gpu_recover, and before calling drm_sched_stop.
Best wishes
Emily Deng
>-Original Message-
>From: Koenig, Christian
Am 08.11.19 um 11:23 schrieb Jesse Zhang:
flush/cancel delayed works before doing finalization
to avoid concurrently requests.
Change-Id: I85b7ffbb34875af1c734cb4573a6ecc71d39d652
Signed-off-by: Jesse Zhang
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3
Hi Emily,
well who is calling amdgpu_device_gpu_recover() in this case?
When it's not the scheduler we shouldn't have a guilty job in the first
place.
Regards,
Christian.
Am 08.11.19 um 11:22 schrieb Deng, Emily:
> Hi Chrisitan,
> No, I am with the new branch and also has the patch.
flush/cancel delayed works before doing finalization
to avoid concurrently requests.
Change-Id: I85b7ffbb34875af1c734cb4573a6ecc71d39d652
Signed-off-by: Jesse Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 1 +
Hi Chrisitan,
No, I am with the new branch and also has the patch. Even it are freed by
main scheduler, how we could avoid main scheduler to free jobs while enter to
function amdgpu_device_gpu_recover?
Best wishes
Emily Deng
>-Original Message-
>From: Koenig, Christian
>Sent:
Hi Emily,
in this case you are on an old code branch.
Jobs are freed now by the main scheduler thread and only if no timeout
handler is running.
See this patch here:
> commit 5918045c4ed492fb5813f980dcf89a90fefd0a4e
> Author: Christian König
> Date: Thu Apr 18 11:00:21 2019 -0400
>
>
Hi Christian,
Please refer to follow log, when it enter to amdgpu_device_gpu_recover
function, the bad job 5086879e is freeing in function
amdgpu_job_free_cb at the same time, because of the hardware fence signal. But
amdgpu_device_gpu_recover goes faster, at this case, the
Am 08.11.19 um 10:39 schrieb Deng, Emily:
> Sorry, please take your time.
Have you seen my other response a bit below?
I can't follow how it would be possible for job->s_fence to be NULL
without the job also being freed.
So it looks like this patch is just papering over some bigger issues.
Sorry, please take your time.
Best wishes
Emily Deng
>-Original Message-
>From: Koenig, Christian
>Sent: Friday, November 8, 2019 5:08 PM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu: Fix the null pointer issue for tdr
>
>Am 08.11.19 um 09:52
Am 08.11.19 um 09:52 schrieb Deng, Emily:
> Ping.
You need to give me at least enough time to wake up :)
>
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: amd-gfx On Behalf Of Deng,
>> Emily
>> Sent: Friday, November 8, 2019 10:56 AM
>> To: Koenig, Christian ; amd-
Ping.
Best wishes
Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of Deng,
>Emily
>Sent: Friday, November 8, 2019 10:56 AM
>To: Koenig, Christian ; amd-
>g...@lists.freedesktop.org
>Subject: RE: [PATCH] drm/amdgpu: Fix the null pointer issue for tdr
>
>>-Original
On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > > >
> > > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > >
On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> >
> > enum mmu_range_notifier_event {
> > MMU_NOTIFY_RELEASE,
> > };
> >
> > ...assuming that we stay with "mmu_range_notifier" as a core name for this
> > whole thing.
> >
> > Also, it is best moved down to be next to the
47 matches
Mail list logo
