Felix that looks a bit fishy to me, can you take a look?
Why are we giving the xcc_mask as parameter here? IIRC the partition a
VM is used with is fixed because the page tables are created
individually for each partition.
Thanks,
Christian.
Am 12.11.23 um 05:45 schrieb Srinivasan Shanmugam:
Hi Lijo,
No real issue here.
Thanks for your explanation. :)
Regards,
Ma Jun
On 11/15/2023 1:27 PM, Lazar, Lijo wrote:
>
>
> On 11/15/2023 10:48 AM, Ma Jun wrote:
>> Set dpm_enabled flag to false only when dpms is
>> successfully disabled.
>>
>
> This a software flag and we block many service
On 11/15/2023 10:48 AM, Ma Jun wrote:
Set dpm_enabled flag to false only when dpms is
successfully disabled.
This a software flag and we block many services based on this flag
status. I think the purpose of setting it early is to block other
service calls which could come in between. Did
Set dpm_enabled flag to false only when dpms is
successfully disabled.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_sm
From: Vitaly Prosyak
[ Upstream commit 4638e0c29a3f2294d5de0d052a4b8c9f33ccb957 ]
When software 'pci unplug' using IGT is executed we got a sysfs directory
entry is NULL for differant ras blocks like hdp, umc, etc.
Before call 'sysfs_remove_file_from_group' and 'sysfs_remove_group'
check that 's
From: Vitaly Prosyak
[ Upstream commit 4638e0c29a3f2294d5de0d052a4b8c9f33ccb957 ]
When software 'pci unplug' using IGT is executed we got a sysfs directory
entry is NULL for differant ras blocks like hdp, umc, etc.
Before call 'sysfs_remove_file_from_group' and 'sysfs_remove_group'
check that 's
From: Vitaly Prosyak
[ Upstream commit 4638e0c29a3f2294d5de0d052a4b8c9f33ccb957 ]
When software 'pci unplug' using IGT is executed we got a sysfs directory
entry is NULL for differant ras blocks like hdp, umc, etc.
Before call 'sysfs_remove_file_from_group' and 'sysfs_remove_group'
check that 's
From: Vitaly Prosyak
[ Upstream commit 4638e0c29a3f2294d5de0d052a4b8c9f33ccb957 ]
When software 'pci unplug' using IGT is executed we got a sysfs directory
entry is NULL for differant ras blocks like hdp, umc, etc.
Before call 'sysfs_remove_file_from_group' and 'sysfs_remove_group'
check that 's
From: Vitaly Prosyak
[ Upstream commit 4638e0c29a3f2294d5de0d052a4b8c9f33ccb957 ]
When software 'pci unplug' using IGT is executed we got a sysfs directory
entry is NULL for differant ras blocks like hdp, umc, etc.
Before call 'sysfs_remove_file_from_group' and 'sysfs_remove_group'
check that 's
[AMD Official Use Only - General]
Reviewed-by: Asad Kamal mailto:asad.ka...@amd.com>>
Thanks & Regards
Asad
From: Wang, Yang(Kevin)
Sent: Wednesday, November 15, 2023 8:42 AM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad ; Ma, Le
Subjec
On 11/15/2023 1:37 AM, Mario Limonciello wrote:
The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
behave as a PCIe Gen1 device. The actual performance of these ports is
controlled by the fabric implement
[AMD Official Use Only - General]
Reviewed-by: Yang Wang
Best Regards,
Kevin
From: Lazar, Lijo
Sent: Wednesday, November 15, 2023 11:04
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad ; Ma, Le
; Wang, Yang(Kevin)
Subje
No need to notify about unload during reset. Also remove the FW version
check.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
b/drivers/gp
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Wang, Yang(Kevin)
Sent: Wednesday, November 15, 2023 07:59
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Wang, Yang(Kevin)
Subject: [PATCH] drm/amdgpu: fix mca ipid socketid
Fix mca ipid socket id decode issue
Fixes: 610259215805 ("drm/amdgpu: correct mca ipid die/socket/addr decode")
Signed-off-by: Yang Wang
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu1
DMABuf imports in compute VMs are not wrapped in a kgd_mem object on the
process_info->kfd_bo_list. There is no explicit KFD API call to validate
them or add eviction fences to them.
This patch automatically validates and fences dymanic DMABuf imports when
they are added to a compute VM. Revalidat
Create a new VM state to track user BOs that are in the system domain.
In the next patch this will be used do conditionally re-validate them in
amdgpu_vm_handle_moved.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +
drivers/gpu/drm/amd/amdgpu/amdg
On 2023-11-09 03:12, Christian König wrote:
Am 08.11.23 um 22:23 schrieb Felix Kuehling:
On 2023-11-08 07:28, Christian König wrote:
Not necessary objections to this patch here, but rather how this new
state is used later on.
The fundamental problem is that re-validating things in
amdgpu_
From: Xiaogang Chen
This patch implements partial migration/mapping for gpu/cpu page faults in SVM
according to migration granularity(default 2MB). A svm range may include pages
from both system ram and vram of one gpu now. These chagnes are expected to
improve migration performance and reduce mm
On 11/14/23 10:27, José Pekkarinen wrote:
The following patch will fix a minor issue where a debug message is
referencing an struct that has just being checked whether is null or
not. This has been noticed by using coccinelle, in the following output:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu
USB4 routers support a feature called "PCIe tunneling". This
allows PCIe traffic to be transmitted over USB4 fabric.
PCIe root ports that are used in this fashion can be discovered
by device specific data that specifies the USB4 router they are
connected to. For the PCI core, the specific connecti
commit 493fb50e958c ("PCI: pciehp: Assume NoCompl+ for Thunderbolt
ports") added a check into pciehp code to explicitly set NoCompl+
for all Intel Thunderbolt controllers, including those that don't
need it.
This overloaded the purpose of the `is_thunderbolt` member of
`struct pci_device` because
The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
behave as a PCIe Gen1 device. The actual performance of these ports is
controlled by the fabric implementation.
Callers for pcie_bandwidth_available() will a
The logic to calculate bandwidth limits may be used at multiple call sites
so split it up into its own static function instead.
No intended functional changes.
Suggested-by: Ilpo Järvinen
Signed-off-by: Mario Limonciello
---
v2->v3:
* Split from previous patch version
---
drivers/pci/pci.c |
All callers have switched to dev_is_removable() for detecting
hotpluggable PCIe devices.
Signed-off-by: Mario Limonciello
---
v2->v3:
* No changes
---
include/linux/pci.h | 22 --
1 file changed, 22 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6
pci_is_thunderbolt_attached() looks at the hierarchy of the PCIe device
to determine if any bridge along the way has the is_thunderbolt bit set.
This bit will only be set when one of the devices in the hierarchy is an
Intel Thunderbolt device.
However PCIe devices can be connected to USB4 hubs and
pci_is_thunderbolt_attached() looks at the hierarchy of the PCIe device
to determine if any bridge along the way has the is_thunderbolt bit set.
This bit will only be set when one of the devices in the hierarchy is an
Intel Thunderbolt device.
However PCIe devices can be connected to USB4 hubs and
The wrong values are reported from pcie_bandwidth_available() which
can cause problems for performance of eGPUs.
This series overhauls Thunderbolt related device detection and uses
the changes to change the behavior of pcie_bandwidth_available().
v2->v3:
* Stop lumping all thunderbolt VSEC and U
From: Alex Deucher
Should be && rather than ||.
Fixes: b2e1cbe6281f ("drm/amdgpu/gmc11: disable AGP on GC 11.5")
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
On 2023-11-13 15:09, Mario Limonciello wrote:
> When ddc_service_construct() is called, it explicitly checks both the
> link type and whether there is something on the link which will
> dictate whether the pin is marked as hw_supported.
>
> If the pin isn't set or the link is not set (such as f
On 11/14/23 01:36, José Pekkarinen wrote:
The following patch will fix a minor issue where a debug message is
referencing an struct that has just being checked whether is null or
not. This has been noticed by using coccinelle, in the following output:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu
Hi,
Yesterday came the 6.7-rc1 kernel.
And surprisingly it turned out it is not working with my LG C3.
I use this OLED TV as my primary monitor.
After login to GNOME I see a horizontal flashing bar with a picture of
the desktop background on white screen.
Demonstration: https://youtu.be/7F76VfRkrVo
On 11/14/2023 2:25 PM, Asad Kamal wrote:
Update pmfw metric table to include pcie
instantaneous bandwidth & pcie error counters
Signed-off-by: Asad Kamal
Reviewed-by: Le Ma
Series is -
Reviewed-by: Lijo Lazar
Thanks,
Lijo
---
.../drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_pmfw
Fill PCIE error counters & instantaneous bandwidth
in gpu metrics v1_4 for smu v_13_0_6
Signed-off-by: Asad Kamal
Reviewed-by: Le Ma
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_
Update pmfw metric table to include pcie
instantaneous bandwidth & pcie error counters
Signed-off-by: Asad Kamal
Reviewed-by: Le Ma
---
.../drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_pmfw.h| 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/sws
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.
Preferably this series
On 13.11.2023 12:37, Heiner Kallweit wrote:
> I2C_CLASS_SPD was used to expose the EEPROM content to user space,
> via the legacy eeprom driver. Now that this driver has been removed,
> we can remove I2C_CLASS_SPD support. at24 driver with explicit
> instantiation should be used instead.
>
> If in
On 13.11.2023 18:49, Wolfram Sang wrote:
>
>> Preferably this series should be applied via the i2c tree.
>
> Are we in a hurry here, i.e. does it block further development of the
> i801 smbus driver? My gut feeling says the patches should rather go via
> drm and fbdev trees, but I may be convince
On 13.11.2023 18:50, Harry Wentland wrote:
> Please just use "drm/amd/display:" as tag in the commit subject.
>
Thanks, noted. Tags have been automatically created by Coccinelle's splitpatch.
> With that fixed, this is
> Acked-by: Harry Wentland
>
> Harry
>
> On 2023-11-13 06:23, Heiner Kallwe
Hi,
When I start X/i3 on a 7900xtx with Linux 6.7-rc1 and Mesa 23.3_rc3, my
log is filled with errors like:
[ 649.788816] amdgpu :03:00.0: amdgpu: [gfxhub] page fault (src_id:0
ring:169 vmid:0 pasid:0, for process pid 0 thread pid 0)
[ 649.788819] amdgpu :03:00.0: amdgpu: in page s
The following patch will fix a minor issue where a debug message is
referencing an struct that has just being checked whether is null or
not. This has been noticed by using coccinelle, in the following output:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c:540:25-29: ERROR:
aconnector
I2C_CLASS_SPD was used to expose the EEPROM content to user space,
via the legacy eeprom driver. Now that this driver has been removed,
we can remove I2C_CLASS_SPD support. at24 driver with explicit
instantiation should be used instead.
If in doubt this patch could be applied via the i2c tree.
Si
44 matches
Mail list logo
