[AMD Official Use Only - Internal Distribution Only]
Hi David,
What I meant is to ONLY delete the serial[16] from drm_amdgpu_info_vbios, not
the whole struct.
struct drm_amdgpu_info_vbios {
__u8 name[64];
__u32 dbdf;
__u8 vbios_pn[64];
__u32 version;
__u8
The bit 11 of GCEA_ERR_STATUS register is used to clear GCEA error
status.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c
index e943cd2923ac..c63599686708 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c
+++ b/drivers/
I using amd 3400g running with android-x86, this patch is a bad commit when i
use android-x86 on amdgpu.
Revert "Revert "drm/amdgpu: Ensure that the modifier requested is supported by
plane."" is the first bad commit, cause a androidx86 run on amdgpu problem,
look the video,
https://drive.goog
look this video,
https://drive.google.com/file/d/1QklH_H2AlOTu8W1D3yl6_3rtZ7IqbjR_/view?usp=sharing
2021-05-09 23:52 GMT+08:00, Alex Deucher :
> On Sun, May 9, 2021 at 11:42 AM youling257 wrote:
>>
>> I using amd 3400g running with android-x86, this patch is a bad commit
>> when i use android-x86
Revert "Revert "drm/amdgpu: Ensure that the modifier requested is
supported by plane."" is first bad commt.
"drm/amd/display: Fix two cursor duplication when using overlay" is
second bad commit.
they cause same problem, look the video.
i have to revert two patch for my androidx86 run on amdgpu.
20
Hi Alex,
I've just sent a couple of fixes for the recent radeon problems:
https://lore.kernel.org/lkml/20210509224926.GA31035@embeddedor/
https://lore.kernel.org/lkml/20210509225525.GA32045@embeddedor/
So, there is no need to revert the problematic patches for radeon anymore.
Sorry for the inco
On Mon, May 10, 2021 at 6:54 AM Gustavo A. R. Silva
wrote:
>
> Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> and ACPIState.levels are never actually used as flexible arrays. Those
> arrays can be used as simple objects of type
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL, inste
error dmesg
[ 115.977746] [drm:dm_plane_helper_prepare_fb [amdgpu]] No FB bound
[ 115.980406] [drm:dcn10_program_pipe [amdgpu]] Un-gated front end for pipe 0
[ 115.993656] [drm:drm_mode_addfb2 [drm]] [FB:104]
[ 115.993694] [drm:drm_mode_addfb2 [drm]] [FB:105]
[ 115.993722] [drm:drm_mode_addfb
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Dennis Li
Sent: Monday, May 10, 2021 16:17
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Kuehling, Felix ; Zhang,
Hawking ; Koenig, Christian
Cc: Li, Dennis
Subject: [PATCH] drm/amdgpu:
It is stored in dynamically allocated memory, so sysfs_bin_attr_init() must
be called to initialize it. (Note: "initialization" only sets the .attr.key
member in this struct; it does not change the value of any other members.)
Otherwise, when CONFIG_DEBUG_LOCK_ALLOC=y this message appears during b
Fixes: a7c22df2fd07 ("drm/amdgpu: clean up non-DC suspend/resume handling")
Signed-off-by: Leslie Shi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdg
For aldebaran, hardware will not clear error status automatically when
reading error status register, insteadly driver should set clear bit of
the error status register explicitly to clear error status.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mmhub.h
b/drivers/gp
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Dennis Li
Sent: Monday, May 10, 2021 19:14
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Kuehling, Felix ; Zhang,
Hawking ; Koenig, Christian
Cc: Li, D
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Jude Shih
-Original Message-
From: Deucher, Alexander
Sent: Saturday, May 8, 2021 4:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Shih, Jude
Subject: [PATCH 3/3] drm/amdgpu/display: fix build when CO
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Jude Shih
-Original Message-
From: Deucher, Alexander
Sent: Saturday, May 8, 2021 4:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Shih, Jude
Subject: [PATCH 2/3] drm/amdgpu/display: fix warning when
Am 2021-05-07 um 3:07 p.m. schrieb Philip Yang:
> New range is created to recover retry vm fault, set all GPUs have access
> to the range. The new range preferred_loc is default value
> KFD_IOCTL_SVM_LOCATION_UNDEFINED.
>
> Correct one typo.
>
> Signed-off-by: Philip Yang
Would it be better to mo
[AMD Public Use]
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Shi, Leslie
Sent: Monday, May 10, 2021 5:56 PM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Chen, Guchun
Subject: [PATCH] drm/amdgpu: avoid undefined return value
Fixes: a7c22df2fd07 ("drm
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: xinhui pan
From: Christian König
Sent: Wednesday, May 5, 2021 7:01:46 PM
To: Pan, Xinhui ; Deucher, Alexander
; amd-gfx@lists.freedesktop.org
Subject: [PATCH] MAINTAINERS: Add Xinhui Pan as anot
Then the application would need to issue the ioctl and then open a sysfs file
to get all the information it needs. It makes little sense from a programming
perspective to add an incomplete interface in my opinion
From: Gu, JiaWei (Will)
Sent: Monday, May 10, 202
Well we could add both as sysfs file(s).
Question here is rather what is the primary use case of this and if the
application has the necessary access permissions to the sysfs files?
Regards,
Christian.
Am 10.05.21 um 15:42 schrieb Nieto, David M:
Then the application would need to issue the i
Am 2021-05-06 um 11:36 p.m. schrieb Alex Sierra:
> [Why]
> svm ranges can have mixed pages from device or system memory.
> A good example is, after a prange has been allocated in VRAM and a
> copy-on-write is triggered by a fork. This invalidates some pages
> inside the prange. Endding up in mixed
The result of an expression consisting of a single relational operator is
already of the bool type and does not need to be evaluated explicitly.
No functional change.
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn30/d
From: Lee Jones
[ Upstream commit 89adc10178fd6cb68c8ef1905d269070a4d3bd64 ]
Fixes the following W=1 kernel build warning(s):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59:
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:100
Hi,
On Fri, Apr 30, 2021 at 11:44:47AM +0200, Maxime Ripard wrote:
> All the drivers that implement HDR output call pretty much the same
> function to initialise the hdr_output_metadata property, and while the
> creation of that property is in a helper, every driver uses the same
> code to attach
From: Lee Jones
[ Upstream commit 89adc10178fd6cb68c8ef1905d269070a4d3bd64 ]
Fixes the following W=1 kernel build warning(s):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59:
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:100
From: Lee Jones
[ Upstream commit 3e3527f5b765c6f479ba55e5a570ee9538589a74 ]
Fixes the following W=1 kernel build warning(s):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59:
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:100
The result of an expression consisting of a single relational operator is
already of the bool type and does not need to be evaluated explicitly.
No functional change.
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
d
Like the previous time it was reverted, there is a chance it's a user
space bug that's not passing the correct modifier.
Are you able to check what exactly returns false in the code above.
This will give you the greatest hint on what the userspace is missing
and needs to be fixed there.
On Sun, Ma
The other thread about how to manage gpu compute resources reminded me
of this one about gpu memory splitting.
On Thu, Mar 18, 2021 at 8:20 PM Brian Welty wrote:
>
>
> On 3/18/2021 3:16 AM, Daniel Vetter wrote:
> > On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote:
> >>
> >>
> >> On 2/11/2021 7:3
On Fri, May 07, 2021 at 02:00:14PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-05-07 12:24 p.m., Daniel Vetter wrote:
> > On Fri, May 07, 2021 at 11:39:49AM -0400, Andrey Grodzovsky wrote:
> > >
> > >
> > > On 2021-05-07 5:11 a.m., Daniel Vetter wrote:
> > > > On Thu, May 06, 2021 at 12:25:06
Hi,
Mon, 2021-05-10 at 17:36 +0200, Daniel Vetter wrote:
>
...
> > If DRM allows user-space to exhaust all of system memory, this seems
> > to be a gap in enforcement of MEMCG limits for system memory.
> > I tried to look into it when this was discussed in the past
> > My guess is that shmem_
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbolt connection or by emulation through sysfs ->
/sys/bus/pci/devices/device_id/remove)
would cause random crashes in user apps. The random crashes in apps were
mostly due to the app having mapped a device backed
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separate function.
v4:
Map the entire BOs VA space into on demand allocated dummy page
on the first fault for that BO
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 539e0232cb3b..d
Helps to expdite HW related stuff to amdgpu_pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
Some of the stuff in amdgpu_device_fini such as HW interrupts
disable and pending fences finilization must be done right away on
pci_remove while most of the stuff which relates to finilizing and
releasing driver data structures can be kept until
drm_driver.release hook is called, i.e. when the las
Use it to call disply code dependent on device->drv_data
before it's set to NULL on device unplug
v5: Move HW finilization into this callback to prevent MMIO accesses
post cpi remove.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 59 +--
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/
This allows to remove explicit creation and destruction
of those attrs and by this avoids warnings on device
finalizing post physical device extraction.
v5: Use newly added pci_driver.dev_groups directly
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
Protect IB submissions
v6: Switch to !drm_dev_enter instead of scoping entire code
with brackets.
Signed-off-by: A
On device removal reroute all CPU mappings to dummy page
per drm_file instance or imported GEM object.
v4:
Update for modified ttm_bo_vm_dummy_page
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 -
1 file chang
We don't want to rearm the timer if driver hook reports
that the device is gone.
v5: Update drm_gpu_sched_stat values in code.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/
If removing while commands in flight you cannot wait to flush the
HW fences on a ring since the device is gone.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd
This helps converting PCI drivers sysfs attributes to static.
Analogous to b71b283e3d6d ("USB: add support for dev_groups to
struct usb_driver")
Signed-off-by: Andrey Grodzovsky
Suggested-by: Greg Kroah-Hartman
---
drivers/pci/pci-driver.c | 1 +
include/linux/pci.h | 3 +++
2 files chang
Problem: If scheduler is already stopped by the time sched_entity
is released and entity's job_queue not empty I encountred
a hang in drm_sched_entity_flush. This is because drm_sched_entity_is_idle
never becomes false.
Fix: In drm_sched_fini detach all sched_entities from the
scheduler's run queu
Return DRM_TASK_STATUS_ENODEV back to the scheduler when device
is not present so they timeout timer will not be rearmed.
v5: Update to match updated return values in enum drm_gpu_sched_stat
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 19 ---
1
It's already being released by DRM core through devm
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
in
what userspace problem?
05-10 16:23:35.438 1686 1686 I SurfaceFlinger: OpenGL ES
informations: format=0x1
05-10 16:23:35.438 1686 1686 I SurfaceFlinger: vendor: AMD
05-10 16:23:35.438 1686 1686 I SurfaceFlinger: renderer : AMD
Radeon(TM) Vega 11 Graphics (RAVEN, DRM 3.41.0,
5.13.0-rc1-a
In case device remove is just simualted by sysfs then verify
device doesn't keep doing DMA to the released memory after
pci_remove is done.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/a
I use androidx86 nougat on amdgpu, these porting to androidx86 nougat.
https://github.com/youling257/mesa
https://github.com/youling257/llvm
https://github.com/youling257/minigbm
https://github.com/youling257/drm_hwcomposer
2021-05-11 0:32 GMT+08:00, youling 257 :
> what userspace problem?
>
> 05-
A userspace problem was due to the modifier used when you're creating
a buffer but this check renders it as invalid modifier.
Review patch 1 of this series and it will give you a good idea of a
userspace bug that was caught using the check in this patch and fixed
now.
An easy way to figure out what
error dmesg,
05-10 16:59:27.004 0 0 I init: Service 'bootanim' (pid
1912) exited with status 0
05-10 16:59:27.016 1684 1684 E hwc-drm-display-compositor: Commit
test failed for display 0, FIXME
05-10 16:59:27.016 1684 1684 E hwc-drm-two: Failed to apply the
frame composition ret=-2
2021-05-11 0:50 GMT+08:00, Mark Yacoub :
> A userspace problem was due to the modifier used when you're creating
> a buffer but this check renders it as invalid modifier.
> Review patch 1 of this series and it will give you a good idea of a
> userspace bug that was caught using the check in this pa
05-10 17:18:46.509 0 0 I : [drm] amdgpu kernel
modesetting enabled.
05-10 17:18:46.510 0 0 I amdgpu : Topology: Add APU node [0x0:0x0]
05-10 17:18:46.510 0 0 D : checking generic (e000
fa) vs hw (e000 1000)
05-10 17:18:46.510 0 0 I fb
Am 2021-05-10 um 12:36 p.m. schrieb Andrey Grodzovsky:
> It's needed to drop iommu backed pages on device unplug
> before device's IOMMU group is released.
I don't see any calls to ttm_tt_unpopulate in the rest of the series
now. Is that an accident, or can this patch be dropped?
Regards,
Felix
On 2021-05-10 2:27 p.m., Felix Kuehling wrote:
Am 2021-05-10 um 12:36 p.m. schrieb Andrey Grodzovsky:
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
I don't see any calls to ttm_tt_unpopulate in the rest of the series
now. Is that an accident,
One of the primary usecases is to add this information to the renderer string,
I am not sure if there are other cases of UMD drivers accessing sysfs nodes,
but I think if we think permissions, if a client is authenticated and opens the
render device then it can use the IOCTL, it is unclear to me
On Mon, May 10, 2021 at 5:56 AM Leslie Shi wrote:
>
> Fixes: a7c22df2fd07 ("drm/amdgpu: clean up non-DC suspend/resume handling")
>
> Signed-off-by: Leslie Shi
I think this was already fixed in:
commit e64a779ad509391dcdb3d0d4014d81e6db2ac001
Author: Victor Zhao
Date: Tue Apr 27 17:52:56 2021
Free the resources if the fence needs to be ignored
during the ratio calculation
Signed-off-by: David M Nieto
Change-Id: Ibfc55a94c53d4b3a1dba8fff4c53fd893195bb96
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
The proper metric for fence utilization over several
contexts is an harmonic mean, but such calculation is
prohibitive in kernel space, so the code approximates it.
Because the approximation diverges when one context has a
very small ratio compared with the other context, this change
filter out ra
Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
and ACPIState.levels are never actually used as flexible arrays. Those
arrays can be used as simple objects of type
SISLANDS_SMC_HW_PERFORMANCE_LEVEL, instead.
Currently, the code fails because flexible array _levels_ in
stru
Applied. Thanks!
Alex
On Sun, May 9, 2021 at 11:42 AM Rouven Czerwinski wrote:
>
> This function is not used anywhere, remove it. It was added in
> 40dd6bd376a4 ("drm/amd/display: Linux Set/Read link rate and lane count
> through debugfs") and moved in fe798de53a7a ("drm/amd/display: Move link
In subject:
PCI: Add support for dev_groups to struct pci_driver
(not "struct pci_device_driver," which does not exist)
On Mon, May 10, 2021 at 12:36:17PM -0400, Andrey Grodzovsky wrote:
> This helps converting PCI drivers sysfs attributes to static.
>
> Analogous to b71b283e3d6d ("USB: add s
Applied. Thanks!
Alex
On Sun, May 9, 2021 at 12:30 PM Christian König
wrote:
>
> Am 09.05.21 um 16:49 schrieb Dwaipayan Ray:
> > Fix a couple of syntax errors and removed one excess
> > parameter in the function documentations which lead
> > to kernel docs build warning.
> >
> > Signed-off-by:
On Sun, May 9, 2021 at 6:48 PM Gustavo A. R. Silva
wrote:
>
> Create new structure NISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> and ACPIState.levels are never actually used as flexible arrays. Those
> arrays can be used as simple objects of type
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL, instea
Applied. Thanks!
Alex
On Mon, May 10, 2021 at 1:51 AM Kai-Heng Feng
wrote:
>
> On Mon, May 10, 2021 at 6:54 AM Gustavo A. R. Silva
> wrote:
> >
> > Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> > and ACPIState.levels are never actually used as flexible arrays. Thos
On Mon, May 10, 2021 at 4:45 PM Gustavo A. R. Silva
wrote:
>
> Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> and ACPIState.levels are never actually used as flexible arrays. Those
> arrays can be used as simple objects of type
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL, inste
On Mon, May 10, 2021 at 4:26 AM Gustavo A. R. Silva
wrote:
>
> Hi Alex,
>
> I've just sent a couple of fixes for the recent radeon problems:
>
> https://lore.kernel.org/lkml/20210509224926.GA31035@embeddedor/
> https://lore.kernel.org/lkml/20210509225525.GA32045@embeddedor/
>
> So, there is no nee
Applied. Thanks!
Alex
On Mon, May 10, 2021 at 5:31 AM David Ward wrote:
>
> It is stored in dynamically allocated memory, so sysfs_bin_attr_init() must
> be called to initialize it. (Note: "initialization" only sets the .attr.key
> member in this struct; it does not change the value of any othe
Applied. Thanks!
Alex
On Mon, May 10, 2021 at 8:16 AM Zhen Lei wrote:
>
> The result of an expression consisting of a single relational operator is
> already of the bool type and does not need to be evaluated explicitly.
>
> No functional change.
>
> Signed-off-by: Zhen Lei
> ---
> drivers/gp
Applied. Thanks!
Alex
On Mon, May 10, 2021 at 8:24 AM Zhen Lei wrote:
>
> The result of an expression consisting of a single relational operator is
> already of the bool type and does not need to be evaluated explicitly.
>
> No functional change.
>
> Signed-off-by: Zhen Lei
> ---
> drivers/gp
LGTM,
Jay, any comment?
Reviewed-by: Rodrigo Siqueira
On 05/08, Rouven Czerwinski wrote:
> This function is not used anywhere, remove it. It was added in
> 40dd6bd376a4 ("drm/amd/display: Linux Set/Read link rate and lane count
> through debugfs") and moved in fe798de53a7a ("drm/amd/display: Mo
lgtm,
Reviewed-by: Rodrigo Siqueira
On 05/10, Andrey Grodzovsky wrote:
> It's already being released by DRM core through devm
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm
Thanks,
Reviewed-by: Rodrigo Siqueira
On 05/07, Alex Deucher wrote:
> The DCN3 guards were dropped a while ago, this one must have
> snuck in in a merge or something.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
> 1 file changed, 2 deletion
On Fri, May 7, 2021 at 3:27 PM Werner Sembach wrote:
>
> xrandr --prop and other userspace info tools have currently no way of
> telling which color configuration is used on HDMI and DP ports.
>
> The ongoing transsition from HDMI 1.4 to 2.0 and the different bandwidth
> requirements of YCbCr 4:2:
On 05/07, Alex Deucher wrote:
> Ping?
>
> Alex
>
> On Fri, Apr 23, 2021 at 4:49 PM Alex Deucher
> wrote:
> >
> > Add missing structure elements.
> >
> > Fixes: 1ace37b873c2 ("drm/amdgpu/display: Implement functions to let DC
> > allocate GPU memory")
Do we need to add the Fixes tag for this p
Hi Alex,
On 5/10/21 16:17, Alex Deucher wrote:
> On Sun, May 9, 2021 at 6:48 PM Gustavo A. R. Silva
> wrote:
[..]
>>
>> Bug:
>> https://lore.kernel.org/dri-devel/3eedbe78-1fbd-4763-a7f3-ac5665e76...@xenosoft.de/
>> Fixes: 434fb1e7444a ("drm/radeon/nislands_smc.h: Replace one-element array
>> w
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: [PATCH v2 02/10] drm/amdgpu:
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: [PATCH v2 03/10] drm/amdgpu:
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Friday, April 23, 2021 2:23 AM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH v2 04/10
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Monday, April 26, 2021 10:41 PM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH v2 05/1
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Monday, April 26, 2021 10:48 PM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH v2 06/1
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: [PATCH v2 07/10] drm/amdgpu:
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Tuesday, April 27, 2021 10:09 AM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH v2 08/
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: [PATCH v2 09/10] drm/ttm: Don
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Thursday, April 22, 2021 6:20 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH
These patches are the result of deliberations with multiple AMD SW and HW
teams with the goal of improving Aldebaran performance and harmonizing the
Arcturus implementation with it.
Felix Kuehling (2):
drm/amdgpu: Arcturus: MTYPE_NC for coarse-grain remote memory
drm/amdgpu: Albebaran: MTYPE_N
MTYPE UC was used for a specific use case that ended up not being
implemented. Use NC for better performance for coarse-grained memory where
cache coherence during shader execution is not required.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ++-
driver
MTYPE UC was used for a specific use case that ended up not being
implemented. Use NC for better performance for coarse-grained memory where
cache coherence during shader execution is not required.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ++-
driver
On 2021-05-10 5:33 p.m., Rodrigo Siqueira wrote:
LGTM,
Jay, any comment?
None, LGTM, and this applied already.
Reviewed-by: Rodrigo Siqueira
On 05/08, Rouven Czerwinski wrote:
This function is not used anywhere, remove it. It was added in
40dd6bd376a4 ("drm/amd/display: Linux Set/Read
Hi Andrey,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.13-rc1 next-20210510]
[cannot apply to pci/next drm/drm
On 05/10, youling257 wrote:
> I using amd 3400g running with android-x86, this patch is a bad commit when i
> use android-x86 on amdgpu.
>
> Revert "Revert "drm/amdgpu: Ensure that the modifier requested is supported
> by plane."" is the first bad commit, cause a androidx86 run on amdgpu
> prob
This series is Reviewed-by: Oak Zeng
Regards,
Oak
On 2021-05-10, 7:36 PM, "amd-gfx on behalf of Felix Kuehling"
wrote:
These patches are the result of deliberations with multiple AMD SW and HW
teams with the goal of improving Aldebaran performance and harmonizing the
Arcturu
[AMD Official Use Only - Internal Distribution Only]
Got it. Let's keep them both.
Another idea about drm_amdgpu_info_vbios is
Does it make more sense to fill the "serial info" with uint64_t
adev->unique_id, instead of the current char[] in adev->serial?
Sorry about that I was not aware of adev
[AMD Official Use Only - Internal Distribution Only]
I agree that the serial number should be on number form, but I think we are
still missing one field, which is the vbios name, which is located after the
P/N, ASIC, PCI and memory type strings (skiping 0xD 0xA
David
___
[AMD Official Use Only - Internal Distribution Only]
Hi David,
The snippet of code we posted here is truncated.
Here's the complete current struct:
struct drm_amdgpu_info_vbios {
__u8 name[64];
__u32 dbdf;
__u8 vbios_pn[64];
__u32 versi
enable ASPM by default
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/nv.c | 2 +-
drivers/gpu/drm/amd/amdgpu/soc15.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 2 +-
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid
From: Likun GAO
Judgement whether to add an sw ip according to the harvest info.
Signed-off-by: Likun Gao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 15 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 30
From: Likun Gao
Update the method of disabling VCN IP for specific SKU for navi1x ASIC,
it will judge whether should add the related IP at the function of
amdgpu_device_ip_block_add().
Signed-off-by: Likun Gao
---
drivers/gpu/drm/amd/amdgpu/nv.c | 30 --
1 file chan
On Thu, Apr 29, 2021 at 02:08:53PM +0800, Zhu, Changfeng wrote:
> From: changzhu
>
> From: Changfeng
>
> The disable process of CGLS is dependent on CGCG now. Align with windows
> code, seperate the dependency between CGCG and CGLS and it will reduce
> confusion when debug CGCG/CGLS related iss
1 - 100 of 114 matches
Mail list logo
