[Why]
For Vega10, disabling gart of gfxhub could mess up KIQ and PSP
under sriov mode, and lead to DMAR on host side.
[How]
Skip writing GMC registers under sriov.
Signed-off-by: YuBiao Wang
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 26 +---
1 file changed, 14
Properly handle SI DC support when CONFIG_DRM_AMD_DC_SI is not
set.
Fixes: f7f12b25823c0d ("drm/amdgpu: default to true in
amdgpu_device_asic_has_dc_support")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +++-
1 file changed, 11 insertions(+), 1
On 2021-11-03 11:04 a.m., shaoyunl wrote:
When kfd need to be reset, sent command to HWS might cause hang and get
unnecessary timeout.
This change try not to touch HW in pre_reset and keep queues to be in the
evicted state
when the reset is done, so they are not put back on the runlist.
[Why]
For Vega10, disabling gart of gfxhub and mmhub could mess up KIQ and PSP
under sriov mode, and lead to DMAR on host side.
[How]
Skip writing GMC registers under sriov.
Signed-off-by: YuBiao Wang
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 26 +---
1 file changed,
Hi Dave, Daniel,
Fixes for 5.16.
The following changes since commit d9bd054177fbd2c4762546aec40fc3071bfe4cc0:
Merge tag 'amd-drm-next-5.16-2021-10-29' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-11-02 12:40:58
+1000)
are available in the Git repository at:
[AMD Official Use Only]
Yes, I missed such conversions in powerplay. Thanks!
Reviewed-by: Lang Yu
>-Original Message-
>From: Deucher, Alexander
>Sent: Thursday, November 4, 2021 8:59 AM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Yu, Lang
>; Powell, Darren
>Subject:
sysfs_emit and sysfs_emit_at requrie a page boundary
aligned buf address. Make them happy!
v2: fix sysfs_emit -> sysfs_emit_at missed conversions
Cc: Lang Yu
Cc: Darren Powell
Fixes: 6db0c87a0a8e ("amdgpu/pm: Replace hwmgr smu usage of sprintf with
sysfs_emit")
Bug:
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
+ spin_lock(>lock);
+ r = drm_buddy_alloc(mm, (uint64_t)place->fpfn << PAGE_SHIFT,
+
On 25/10/2021 14:00, Arunpravin wrote:
add drm_buddy_free_unused_pages() support on
contiguous allocation
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
On 25/10/2021 14:00, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
Signed-off-by: Arunpravin
Ideally this gets added with some user, so we can see it in action?
Maybe
On 25/10/2021 14:00, Arunpravin wrote:
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver
On 25/10/2021 14:00, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation
On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct
> > drm_connector
On Wed, Nov 3, 2021 at 11:05 AM shaoyunl wrote:
>
> When kfd need to be reset, sent command to HWS might cause hang and get
> unnecessary timeout.
> This change try not to touch HW in pre_reset and keep queues to be in the
> evicted state
> when the reset is done, so they are not put back on
On 10/27/21 12:36 AM, Jim Cromie wrote:
> Use new macro to create a sysfs control bitmap knob to control
> print-to-trace in: /sys/module/drm/parameters/trace
>
> todo: reconsider this api, ie a single macro expecting both debug &
> trace terms (2 each), followed by a single description and
[Public]
It's a conditional case for some kind of early reset. Haven't checked details,
on a quick glance it appeared to call iommu init again.
https://elixir.bootlin.com/linux/v5.15/source/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L5160
Thanks,
Lijo
Acked-by: Nirmoy Das
On 10/28/2021 3:26 PM, Christian König wrote:
Don't touch the exclusive fence manually here, but rather use the
general dma_resv function. We did that for better hw reset handling but
this doesn't necessary work correctly.
Signed-off-by: Christian König
---
On 2021-11-02 11:53 p.m., Lazar, Lijo wrote:
On 11/3/2021 12:53 AM, James Zhu wrote:
From: Yifan Zhang
When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2
init will fail. But this failure should not block amdgpu driver init.
Reported-by: youling
Tested-by: youling
On Tue, Nov 2, 2021 at 9:34 PM James Zhu wrote:
>
> Remove duplicated kfd_resume_iommu which already runs
> in mdgpu_amdkfd_device_init.
>
> Signed-off-by: James Zhu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
> 1 file changed, 4 deletions(-)
>
>
On Wed, Nov 3, 2021 at 10:50 AM Alex Deucher wrote:
>
>
>
> On Wed, Nov 3, 2021 at 10:34 AM Zhu, James wrote:
>>
>> [AMD Official Use Only]
>>
>>
>> Hi Alex,
>>
>> Finally figured out the root cause for this broken,
>>
>> Linux 5.14.15 + afd1818 can fix the issue.
I think this applies to 5.15
When kfd need to be reset, sent command to HWS might cause hang and get
unnecessary timeout.
This change try not to touch HW in pre_reset and keep queues to be in the
evicted state
when the reset is done, so they are not put back on the runlist. These queues
will be destroied
on process
Hello Thomas,
On 11/3/21 14:01, Thomas Zimmermann wrote:
[snip]
>>
>>
>> Javier Martinez Canillas (5):
>>drm/i915: Fix comment about modeset parameters
>>drm: Move nomodeset kernel parameter handler to the DRM subsystem
>>drm: Rename vgacon_text_force() function to
[ Adding dri-devel ]
On 2021-11-01 16:00, Wang, Chao-kai (Stylon) wrote:
>
> The problem with -ERESTARTSYS is the same half-baked atomic state with
> modifications we made in the interrupted atomic check, is reused in the next
> retry and fails the atomic check. What we expect in the next
Hi Harry,
lgtm.
Btw, it looks like that the other patches from this series are already
applied to amd-staging-drm-next.
Reviewed-by: Rodrigo Siqueira
On 2021-10-27 10:26 a.m., Harry Wentland wrote:
There is no reason to allow for partial buffers from
userspace in our debugfs. In this
On 11/3/21 13:57, Thomas Zimmermann wrote:
[snip]
>>
>> -if (vgacon_text_force()) {
>> +if (drm_modeset_disabled()) {
>> DRM_ERROR("amdgpu kernel modesetting disabled.\n");
>
> Please remove all such error messages from drivers.
> drm_modeset_disabled() should print a
Hello Thomas,
On 11/3/21 13:41, Thomas Zimmermann wrote:
> Hi
>
> Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
>> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
>> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>>
>> It makes much
Hello Jani,
On 11/3/21 13:56, Jani Nikula wrote:
[snip]
>>
>> +obj-y += drm_nomodeset.o
>
> This is a subtle functional change. With this, you'll always have
> __setup("nomodeset", text_mode) builtin and the parameter available. And
> using nomodeset will print out the pr_warn() splat from
Hi
Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
[ resend with all relevant people as Cc now, sorry to others for the spam ]
There is a lot of historical baggage on this parameter. It's defined in
the vgacon driver as a "nomodeset" parameter, but it's handler function is
called
Hi
Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
This function is used by some DRM drivers to determine if the "nomodeset"
kernel command line parameter was set and prevent these drivers to probe.
But the function name is quite confusing and does not reflect what really
the drivers
On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>
> It makes much more sense for the parameter logic to be in the subsystem
> of the drivers
[ resend with all relevant people as Cc now, sorry to others for the spam ]
There is a lot of historical baggage on this parameter. It's defined in
the vgacon driver as a "nomodeset" parameter, but it's handler function is
called text_mode() that sets a variable named vgacon_text_mode_force whose
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that are making use of it. Let's move that to DRM.
This function is used by some DRM drivers to determine if the "nomodeset"
kernel command line parameter was set and prevent these drivers to probe.
But the function name is quite confusing and does not reflect what really
the drivers are testing when calling it. Use a better naming now that it
is
Hi
Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers
On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct
> drm_connector *connector,
> u32 max_tmds_clock = hf_vsdb[5] * 5000;
>
On 02/11/2021 15:59, Maxime Ripard wrote:
> A lot of drivers open-code the HDMI 1.4 maximum pixel rate in their
> driver to test whether the resolutions are supported or if the
> scrambling needs to be enabled.
>
> Let's create a common define for everyone to use it.
>
> Cc: Alex Deucher
> Cc:
Ping, Alex do you have a moment for that one here?
Am 28.10.21 um 15:26 schrieb Christian König:
Don't touch the exclusive fence manually here, but rather use the
general dma_resv function. We did that for better hw reset handling but
this doesn't necessary work correctly.
Signed-off-by:
37 matches
Mail list logo
