[PATCH V4 8/8] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index 98a33f8ee209..16c1c04e2034 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -125,6 +125,7 @@ static struct cmn2asic_msg_mapping
smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(ArmD3, PPSMC_MSG_ArmD3,
0),
MSG_MAP(AllowGpo, PPSMC_MSG_SetGpoAllow,
0),
MSG_MAP(GetPptLimit,PPSMC_MSG_GetPptLimit,
0),
+ MSG_MAP(EnableUCLKShadow, PPSMC_MSG_EnableUCLKShadow,
0),
};
static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
@@ -205,6 +206,7 @@ static struct cmn2asic_mapping
smu_v13_0_7_table_map[SMU_TABLE_COUNT] = {
TAB_MAP(DRIVER_SMU_CONFIG),
TAB_MAP(ACTIVITY_MONITOR_COEFF),
[SMU_TABLE_COMBO_PPTABLE] = {1, TABLE_COMBO_PPTABLE},
+ TAB_MAP(WIFIBAND),
};
static struct cmn2asic_mapping smu_v13_0_7_pwr_src_map[SMU_POWER_SOURCE_COUNT]
= {
@@ -487,6 +489,9 @@ static int smu_v13_0_7_tables_init(struct smu_context *smu)
AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_COMBO_PPTABLE,
MP0_MP1_DATA_REGION_SIZE_COMBOPPTABLE,
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
+ SMU_TABLE_INIT(tables, SMU_TABLE_WIFIBAND,
+ sizeof(WifiBandEntryTable_t), PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM);
smu_table->metrics_table = kzalloc(sizeof(SmuMetricsExternal_t),
GFP_KERNEL);
if (!smu_table->metrics_table)
@@ -1721,6 +1726,57 @@ static int smu_v13_0_7_set_df_cstate(struct smu_context
*smu,
NULL);
}
+static bool smu_v13_0_7_wbrf_support_check(struct smu_context *smu)
+{
+ return smu->smc_fw_version > 0x00524600;
+}
+
+static int smu_v13_0_7_set_wbrf_exclusion_ranges(struct smu_context *smu,
+struct exclusion_range
*exclusion_ranges)
+{
+ WifiBandEntryTable_t wifi_bands;
+ int valid_entries = 0;
+ int ret, i;
+
+ memset(_bands, 0, sizeof(wifi_bands));
+ for (i = 0; i < ARRAY_SIZE(wifi_bands.WifiBandEntry); i++) {
+ if (!exclusion_ranges[i].start &&
+ !exclusion_ranges[i].end)
+ break;
+
+ /* PMFW expects the inputs to be in Mhz unit */
+ wifi_bands.WifiBandEntry[valid_entries].LowFreq =
+ DIV_ROUND_DOWN_ULL(exclusion_ranges[i].start,
HZ_IN_MHZ);
+ wifi_bands.WifiBandEntry[valid_entries++].HighFreq =
+ DIV_ROUND_UP_ULL(exclusion_ranges[i].end, HZ_IN_MHZ);
+ }
+ wifi_bands.WifiBandEntryNum = valid_entries;
+
+ /*
+* Per confirm with PMFW team, WifiBandEntryNum = 0 is a valid setting.
+* Considering the scenarios below:
+* - At first the wifi device adds an exclusion range e.g. (2400,2500)
to
+* BIOS and our driver gets notified. We will set WifiBandEntryNum = 1
+* and pass the WifiBandEntry (2400, 2500) to PMFW.
+*
+* - Later the wifi device removes the wifiband list added above and
+* our driver gets notified again. At this time, driver will set
+* WifiBandEntryNum = 0 and pass an empty WifiBandEntry list to PMFW.
+* - PMFW may still need to do some uclk shadow update(e.g. switching
+* from shadow clock back to primary clock) on receiving this.
+*/
+
+ ret = smu_cmn_update_table(smu,
+ SMU_TABLE_WIFIBAND,
+ 0,
+ (void *)(_bands),
+ true);
+ if (ret)
+ dev_err(smu->adev->dev, "Failed to set wifiband!");
+
+ return ret;
+}
+
static const struct pptable_funcs smu_v13_0_7_ppt_funcs = {
.get_allowed_feature_mask = smu_v13_0_7_get_allowed_feature_mask,
.set_default_dpm_table = smu_v13_0_7_set_default_dpm_table,
@@ -1786,6 +1842,9 @@ static const struct pptable_funcs smu_v13_0_7_ppt_funcs =
{
.set_mp1_state = smu_v13_0_7_set_mp1_state,
.set_df_cstate = smu_v13_0_7_set_df_cstate,
.gpo_control = smu_v13_0_gpo_control,
+ .is_asic_wbrf_supported = smu_v13_0_7_wbrf_support_check,
+ .enable_uclk_shadow = smu_v13_0_enable_uclk_shadow,
+ .set_wbrf_exclusion_ranges = smu_v13_0_7_set_wbrf_exclusion_ranges,
};
void smu_v13_0_7_set_ppt_funcs(struct smu_context *smu)
[PATCH V4 7/8] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 +
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 9 +++
.../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 60 +++
5 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
index aa63cc43d41c..a8a4be32cc59 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
@@ -323,6 +323,7 @@ enum smu_table_id
SMU_TABLE_PACE,
SMU_TABLE_ECCINFO,
SMU_TABLE_COMBO_PPTABLE,
+ SMU_TABLE_WIFIBAND,
SMU_TABLE_COUNT,
};
@@ -1496,6 +1497,8 @@ enum smu_baco_seq {
__dst_size); \
})
+#define HZ_IN_MHZ 100U
+
#if !defined(SWSMU_CODE_LAYER_L2) && !defined(SWSMU_CODE_LAYER_L3) &&
!defined(SWSMU_CODE_LAYER_L4)
int smu_get_power_limit(void *handle,
uint32_t *limit,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
index 297b70b9388f..5bbb60289a79 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
@@ -245,7 +245,8 @@
__SMU_DUMMY_MAP(AllowGpo), \
__SMU_DUMMY_MAP(Mode2Reset),\
__SMU_DUMMY_MAP(RequestI2cTransaction), \
- __SMU_DUMMY_MAP(GetMetricsTable),
+ __SMU_DUMMY_MAP(GetMetricsTable), \
+ __SMU_DUMMY_MAP(EnableUCLKShadow),
#undef __SMU_DUMMY_MAP
#define __SMU_DUMMY_MAP(type) SMU_MSG_##type
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
index df3baaab0037..b6fae9b92303 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
@@ -303,5 +303,8 @@ int smu_v13_0_get_pptable_from_firmware(struct smu_context
*smu,
uint32_t *size,
uint32_t pptable_id);
+int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
+bool enablement);
+
#endif
#endif
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index 393c6a7b9609..8c2230d1d862 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -2453,3 +2453,12 @@ int smu_v13_0_mode1_reset(struct smu_context *smu)
return ret;
}
+
+int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
+bool enablement)
+{
+ return smu_cmn_send_smc_msg_with_param(smu,
+ SMU_MSG_EnableUCLKShadow,
+ enablement,
+ NULL);
+}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index 09405ef1e3c8..cf75feaee779 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -155,6 +155,7 @@ static struct cmn2asic_msg_mapping
smu_v13_0_0_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(AllowGpo, PPSMC_MSG_SetGpoAllow,
0),
MSG_MAP(AllowIHHostInterrupt, PPSMC_MSG_AllowIHHostInterrupt,
0),
MSG_MAP(ReenableAcDcInterrupt,
PPSMC_MSG_ReenableAcDcInterrupt, 0),
+ MSG_MAP(EnableUCLKShadow, PPSMC_MSG_EnableUCLKShadow,
0),
};
static struct cmn2asic_mapping smu_v13_0_0_clk_map[SMU_CLK_COUNT] = {
@@ -235,6 +236,7 @@ static struct cmn2asic_mapping
smu_v13_0_0_table_map[SMU_TABLE_COUNT] = {
TAB_MAP(DRIVER_SMU_CONFIG),
TAB_MAP(ACTIVITY_MONITOR_COEFF),
[SMU_TABLE_COMBO_PPTABLE] = {1, TABLE_COMBO_PPTABLE},
+ TAB_MAP(WIFIBAND),
TAB_MAP(I2C_COMMANDS),
TAB_MAP(ECCINFO),
};
@@ -472,6 +474,9 @@ static int smu_v13_0_0_tables_init(struct smu_context *smu)
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_ECCINFO, sizeof(EccInfoTable_t),
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
+ SMU_TABLE_INIT(tables, SMU_TABLE_WIFIBAND,
+ sizeof(WifiBandEntryTable_t), PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM);
smu_table->metrics_table = kzalloc(sizeof(SmuMetricsExternal_t),
GFP_KERNEL);
if (!smu_table->metrics_table)
@@ -2112,6 +2117,58 @@ static ssize_t smu_v13_0_0_get_ecc_info(struct
smu_context *smu,
return ret;
}
+static bool
[PATCH V4 6/8] drm/amd/pm: add flood detection for wbrf events
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 28 ---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index a8efdce4607c..75d6e654b2a6 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1272,6 +1272,22 @@ static void smu_wbrf_event_handler(struct amdgpu_device
*adev)
{
struct smu_context *smu = adev->powerplay.pp_handle;
+ schedule_delayed_work(>wbrf_delayed_work,
+ msecs_to_jiffies(SMU_WBRF_EVENT_HANDLING_PACE));
+}
+
+/**
+ * smu_wbrf_delayed_work_handler - callback on delayed work timer expired
+ *
+ * @work: struct work_struct pointer
+ *
+ * Flood is over and driver will consume the latest exclusion ranges.
+ */
+static void smu_wbrf_delayed_work_handler(struct work_struct *work)
+{
+ struct smu_context *smu =
+ container_of(work, struct smu_context, wbrf_delayed_work.work);
+
smu_wbrf_handle_exclusion_ranges(smu);
}
@@ -1311,6 +1327,9 @@ static int smu_wbrf_init(struct smu_context *smu)
if (!smu->wbrf_supported)
return 0;
+ INIT_DELAYED_WORK(>wbrf_delayed_work,
+ smu_wbrf_delayed_work_handler);
+
ret = amdgpu_acpi_register_wbrf_notify_handler(adev,
smu_wbrf_event_handler);
if (ret)
@@ -1321,11 +1340,10 @@ static int smu_wbrf_init(struct smu_context *smu)
* before our driver loaded. To make sure our driver
* is awared of those exclusion ranges.
*/
- ret = smu_wbrf_handle_exclusion_ranges(smu);
- if (ret)
- dev_err(adev->dev, "Failed to handle wbrf exclusion ranges\n");
+ schedule_delayed_work(>wbrf_delayed_work,
+ msecs_to_jiffies(SMU_WBRF_EVENT_HANDLING_PACE));
- return ret;
+ return 0;
}
/**
@@ -1343,6 +1361,8 @@ static void smu_wbrf_fini(struct smu_context *smu)
return;
amdgpu_acpi_unregister_wbrf_notify_handler(adev);
+
+ cancel_delayed_work_sync(>wbrf_delayed_work);
}
static int smu_smc_hw_setup(struct smu_context *smu)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
index ff0af3da0be2..aa63cc43d41c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
@@ -478,6 +478,12 @@ struct stb_context {
#define WORKLOAD_POLICY_MAX 7
+/*
+ * Configure wbrf event handling pace as there can be only one
+ * event processed every SMU_WBRF_EVENT_HANDLING_PACE ms.
+ */
+#define SMU_WBRF_EVENT_HANDLING_PACE 10
+
struct smu_context
{
struct amdgpu_device*adev;
@@ -576,6 +582,7 @@ struct smu_context
/* data structures for wbrf feature support */
boolwbrf_supported;
+ struct delayed_work wbrf_delayed_work;
};
struct i2c_adapter;
--
2.34.1
[PATCH V4 5/8] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
To make WBRF feature functional, the kernel needs to be configured with
CONFIG_ACPI_WBRF and the platform is equipped with necessary ACPI based
mechanism to get amdgpu driver notified.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
--
v1->v2:
- update the prompt for feature support(Lijo)
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 26 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 63 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 19 ++
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 184 ++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 20 ++
drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 +
6 files changed, 315 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 02b827785e39..2f2ec64ed1b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
@@ -241,6 +242,7 @@ extern int amdgpu_num_kcq;
#define AMDGPU_VCNFW_LOG_SIZE (32 * 1024)
extern int amdgpu_vcnfw_log;
extern int amdgpu_sg_display;
+extern int amdgpu_wbrf;
#define AMDGPU_VM_MAX_NUM_CTX 4096
#define AMDGPU_SG_THRESHOLD(256*1024*1024)
@@ -741,6 +743,9 @@ struct amdgpu_reset_domain;
*/
#define AMDGPU_HAS_VRAM(_adev) ((_adev)->gmc.real_vram_size)
+typedef
+void (*wbrf_notify_handler) (struct amdgpu_device *adev);
+
struct amdgpu_device {
struct device *dev;
struct pci_dev *pdev;
@@ -1050,6 +1055,8 @@ struct amdgpu_device {
booljob_hang;
booldc_enabled;
+
+ wbrf_notify_handler wbrf_event_handler;
};
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
@@ -1381,6 +1388,25 @@ static inline int amdgpu_acpi_smart_shift_update(struct
drm_device *dev,
enum amdgpu_ss ss_state) {
return 0; }
#endif
+#if defined(CONFIG_ACPI_WBRF)
+bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev);
+int amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
+struct wbrf_ranges_out
*exclusions_out);
+int amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
+wbrf_notify_handler handler);
+int amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device *adev);
+#else
+static inline bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev) {
return false; }
+static inline
+int amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
+struct wbrf_ranges_out
*exclusions_out) { return 0; }
+static inline
+int amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
+wbrf_notify_handler handler) {
return 0; }
+static inline
+int amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device *adev) {
return 0; }
+#endif
+
#if defined(CONFIG_ACPI) && defined(CONFIG_SUSPEND)
bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev);
bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index aeeec211861c..efbe6dd91d1a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -1105,3 +1105,66 @@ bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device
*adev)
}
#endif /* CONFIG_SUSPEND */
+
+#ifdef CONFIG_ACPI_WBRF
+bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev)
+{
+ struct acpi_device *acpi_dev = ACPI_COMPANION(adev->dev);
+
+ if (!acpi_dev)
+ return false;
+
+ return wbrf_supported_consumer(acpi_dev);
+}
+
+int amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
+struct wbrf_ranges_out *exclusions_out)
+{
+ struct acpi_device *acpi_dev = ACPI_COMPANION(adev->dev);
+
+ if (!acpi_dev)
+ return -ENODEV;
+
+ return wbrf_retrieve_exclusions(acpi_dev, exclusions_out);
+}
+
+#define CPM_GPU_NOTIFY_COMMAND 0x55
+static void amdgpu_acpi_wbrf_event(acpi_handle handle, u32 event, void *data)
+{
+ struct amdgpu_device *adev = (struct amdgpu_device *)data;
+
+ if (event == CPM_GPU_NOTIFY_COMMAND &&
+ adev->wbrf_event_handler)
+ adev->wbrf_event_handler(adev);
+}
+
+int amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
+
[PATCH V4 4/8] drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
.../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h | 3 ++-
.../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h | 3 ++-
4 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
index b686fb68a6e7..d64188fb5839 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
@@ -388,6 +388,17 @@ typedef struct {
EccInfo_t EccInfo[24];
} EccInfoTable_t;
+typedef struct {
+ uint16_t LowFreq;
+ uint16_t HighFreq;
+} WifiOneBand_t;
+
+typedef struct {
+ uint32_t WifiBandEntryNum;
+ WifiOneBand_tWifiBandEntry[11];
+ uint32_t MmHubPadding[8];
+} WifiBandEntryTable_t;
+
//D3HOT sequences
typedef enum {
BACO_SEQUENCE,
@@ -1592,7 +1603,8 @@ typedef struct {
#define TABLE_I2C_COMMANDS9
#define TABLE_DRIVER_INFO 10
#define TABLE_ECCINFO 11
-#define TABLE_COUNT 12
+#define TABLE_WIFIBAND12
+#define TABLE_COUNT 13
//IH Interupt ID
#define IH_INTERRUPT_ID_TO_DRIVER 0xFE
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
index 4c46a0392451..77483e8485e7 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
@@ -392,6 +392,17 @@ typedef struct {
EccInfo_t EccInfo[24];
} EccInfoTable_t;
+typedef struct {
+ uint16_t LowFreq;
+ uint16_t HighFreq;
+} WifiOneBand_t;
+
+typedef struct {
+ uint32_t WifiBandEntryNum;
+ WifiOneBand_tWifiBandEntry[11];
+ uint32_t MmHubPadding[8];
+} WifiBandEntryTable_t;
+
//D3HOT sequences
typedef enum {
BACO_SEQUENCE,
@@ -1624,7 +1635,8 @@ typedef struct {
#define TABLE_I2C_COMMANDS9
#define TABLE_DRIVER_INFO 10
#define TABLE_ECCINFO 11
-#define TABLE_COUNT 12
+#define TABLE_WIFIBAND12
+#define TABLE_COUNT 13
//IH Interupt ID
#define IH_INTERRUPT_ID_TO_DRIVER 0xFE
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
index 10cff75b44d5..c98cc32d11bd 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
@@ -138,7 +138,8 @@
#define PPSMC_MSG_SetBadMemoryPagesRetiredFlagsPerChannel 0x4A
#define PPSMC_MSG_SetPriorityDeltaGain 0x4B
#define PPSMC_MSG_AllowIHHostInterrupt 0x4C
-#define PPSMC_Message_Count 0x4D
+#define PPSMC_MSG_EnableUCLKShadow 0x51
+#define PPSMC_Message_Count 0x52
//Debug Dump Message
#define DEBUGSMC_MSG_TestMessage0x1
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
index 6aaefca9b595..a6bf9cdd130e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
@@ -134,6 +134,7 @@
#define PPSMC_MSG_SetBadMemoryPagesRetiredFlagsPerChannel 0x4A
#define PPSMC_MSG_SetPriorityDeltaGain 0x4B
#define PPSMC_MSG_AllowIHHostInterrupt 0x4C
-#define PPSMC_Message_Count 0x4D
+#define PPSMC_MSG_EnableUCLKShadow 0x51
+#define PPSMC_Message_Count 0x52
#endif
--
2.34.1
[PATCH V4 3/8] wifi: mac80211: Add support for ACPI WBRF
To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate possible interference.
To make WBRF feature functional, the kernel needs to be configured with
CONFIG_ACPI_WBRF and the platform is equipped with WBRF support(from
BIOS and drivers).
Signed-off-by: Mario Limonciello
Co-developed-by: Evan Quan
Signed-off-by: Evan Quan
--
v1->v2:
- place the new added member(`wbrf_supported`) in
ieee80211_local(Johannes)
- handle chandefs change scenario properly(Johannes)
- some minor fixes around code sharing and possible invalid input
checks(Johannes)
v2->v3:
- drop unnecessary input checks and intermediate APIs(Mario)
- Separate some mac80211 common code(Mario, Johannes)
---
include/linux/ieee80211.h | 1 +
net/mac80211/Makefile | 2 +
net/mac80211/chan.c| 11
net/mac80211/ieee80211_i.h | 19 +++
net/mac80211/main.c| 2 +
net/mac80211/wbrf.c| 111 +
6 files changed, 146 insertions(+)
create mode 100644 net/mac80211/wbrf.c
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index c4cf296e7eaf..0703921547f5 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -4319,6 +4319,7 @@ static inline int ieee80211_get_tdls_action(struct
sk_buff *skb, u32 hdr_size)
/* convert frequencies */
#define MHZ_TO_KHZ(freq) ((freq) * 1000)
#define KHZ_TO_MHZ(freq) ((freq) / 1000)
+#define KHZ_TO_HZ(freq) ((freq) * 1000)
#define PR_KHZ(f) KHZ_TO_MHZ(f), f % 1000
#define KHZ_F "%d.%03d"
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index b8de44da1fb8..709eb678f42a 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -65,4 +65,6 @@ rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += \
mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-y)
+mac80211-$(CONFIG_ACPI_WBRF) += wbrf.o
+
ccflags-y += -DDEBUG
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 77c90ed8f5d7..0c5289a9aa6c 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -506,11 +506,16 @@ static void _ieee80211_change_chanctx(struct
ieee80211_local *local,
WARN_ON(!cfg80211_chandef_compatible(>conf.def, chandef));
+ ieee80211_remove_wbrf(local, >conf.def);
+
ctx->conf.def = *chandef;
/* check if min chanctx also changed */
changed = IEEE80211_CHANCTX_CHANGE_WIDTH |
_ieee80211_recalc_chanctx_min_def(local, ctx, rsvd_for);
+
+ ieee80211_add_wbrf(local, >conf.def);
+
drv_change_chanctx(local, ctx, changed);
if (!local->use_chanctx) {
@@ -668,6 +673,10 @@ static int ieee80211_add_chanctx(struct ieee80211_local
*local,
lockdep_assert_held(>mtx);
lockdep_assert_held(>chanctx_mtx);
+ err = ieee80211_add_wbrf(local, >conf.def);
+ if (err)
+ return err;
+
if (!local->use_chanctx)
local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
@@ -748,6 +757,8 @@ static void ieee80211_del_chanctx(struct ieee80211_local
*local,
}
ieee80211_recalc_idle(local);
+
+ ieee80211_remove_wbrf(local, >conf.def);
}
static void ieee80211_free_chanctx(struct ieee80211_local *local,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index b0372e76f373..f832de16073b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1591,6 +1591,10 @@ struct ieee80211_local {
/* extended capabilities provided by mac80211 */
u8 ext_capa[8];
+
+#ifdef CONFIG_ACPI_WBRF
+ bool wbrf_supported;
+#endif
};
static inline struct ieee80211_sub_if_data *
@@ -2615,4 +2619,19 @@ ieee80211_eht_cap_ie_to_sta_eht_cap(struct
ieee80211_sub_if_data *sdata,
const struct ieee80211_eht_cap_elem
*eht_cap_ie_elem,
u8 eht_cap_len,
struct link_sta_info *link_sta);
+
+#ifdef CONFIG_ACPI_WBRF
+void ieee80211_check_wbrf_support(struct ieee80211_local *local);
+int ieee80211_add_wbrf(struct ieee80211_local *local,
+ struct cfg80211_chan_def *chandef);
+void ieee80211_remove_wbrf(struct ieee80211_local *local,
+ struct cfg80211_chan_def *chandef);
+#else
+static inline void ieee80211_check_wbrf_support(struct ieee80211_local *local)
{ }
+static inline int ieee80211_add_wbrf(struct ieee80211_local *local,
+struct cfg80211_chan_def *chandef) {
return 0; }
+static inline void ieee80211_remove_wbrf(struct ieee80211_local *local,
+struct cfg80211_chan_def *chandef) { }
+#endif /* CONFIG_ACPI_WBRF */
+
#endif /* IEEE80211_I_H */
diff
[PATCH V4 2/8] cfg80211: expose nl80211_chan_width_to_mhz for wide sharing
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9e04f69712b1..c6dc337eafce 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
cfg80211_chandef_compatible(const struct cfg80211_chan_def *chandef1,
const struct cfg80211_chan_def *chandef2);
+/**
+ * nl80211_chan_width_to_mhz - get the channel width in Mhz
+ * @chan_width: the channel width from nl80211_chan_width
+ * Return: channel width in Mhz if the chan_width from nl80211_chan_width
+ * is valid. -1 otherwise.
+ */
+int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width);
+
/**
* cfg80211_chandef_valid - check if a channel definition is valid
* @chandef: the channel definition to check
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 0b7e81db383d..227db04eac42 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -141,7 +141,7 @@ static bool cfg80211_edmg_chandef_valid(const struct
cfg80211_chan_def *chandef)
return true;
}
-static int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
+int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
{
int mhz;
@@ -190,6 +190,7 @@ static int nl80211_chan_width_to_mhz(enum
nl80211_chan_width chan_width)
}
return mhz;
}
+EXPORT_SYMBOL(nl80211_chan_width_to_mhz);
static int cfg80211_chandef_get_width(const struct cfg80211_chan_def *c)
{
--
2.34.1
[PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations
From: Mario Limonciello
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced an ACPI based mechanism that
devices can use to notify active use of particular frequencies so
that devices can make relative internal adjustments as necessary
to avoid this resonance.
In order for a device to support this, the expected flow for device
driver or subsystems:
Drivers/subsystems contributing frequencies:
1) During probe, check `wbrf_supported_producer` to see if WBRF supported
for the device.
2) If adding frequencies, then call `wbrf_add_exclusion` with the
start and end ranges of the frequencies.
3) If removing frequencies, then call `wbrf_remove_exclusion` with
start and end ranges of the frequencies.
Drivers/subsystems responding to frequencies:
1) During probe, check `wbrf_supported_consumer` to see if WBRF is supported
for the device.
2) Call the `wbrf_retrieve_exclusions` to retrieve the current
exclusions on receiving an ACPI notification for a new frequency
change.
Signed-off-by: Mario Limonciello
Co-developed-by: Evan Quan
Signed-off-by: Evan Quan
--
v1->v2:
- move those wlan specific implementations to net/mac80211(Mario)
---
drivers/acpi/Kconfig | 7 ++
drivers/acpi/Makefile| 2 +
drivers/acpi/acpi_wbrf.c | 215 +++
include/linux/wbrf.h | 55 ++
4 files changed, 279 insertions(+)
create mode 100644 drivers/acpi/acpi_wbrf.c
create mode 100644 include/linux/wbrf.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ccbeab9500ec..0276c1487fa2 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -611,3 +611,10 @@ config X86_PM_TIMER
You should nearly always say Y here because many modern
systems require this timer.
+
+config ACPI_WBRF
+ bool "ACPI Wifi band RF mitigation mechanism"
+ help
+ Wifi band RF mitigation mechanism allows multiple drivers from
+ different domains to notify the frequencies in use so that hardware
+ can be reconfigured to avoid harmonic conflicts.
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index feb36c0b9446..14863b0c619f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -131,3 +131,5 @@ obj-y += dptf/
obj-$(CONFIG_ARM64)+= arm64/
obj-$(CONFIG_ACPI_VIOT)+= viot.o
+
+obj-$(CONFIG_ACPI_WBRF)+= acpi_wbrf.o
diff --git a/drivers/acpi/acpi_wbrf.c b/drivers/acpi/acpi_wbrf.c
new file mode 100644
index ..8c275998ac29
--- /dev/null
+++ b/drivers/acpi/acpi_wbrf.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD Wifi Band Exclusion Interface
+ * Copyright (C) 2023 Advanced Micro Devices
+ *
+ */
+
+#include
+
+/* functions */
+#define WBRF_RECORD0x1
+#define WBRF_RETRIEVE 0x2
+
+/* record actions */
+#define WBRF_RECORD_ADD0x0
+#define WBRF_RECORD_REMOVE 0x1
+
+#define WBRF_REVISION 0x1
+
+static const guid_t wifi_acpi_dsm_guid =
+ GUID_INIT(0x7b7656cf, 0xdc3d, 0x4c1c,
+ 0x83, 0xe9, 0x66, 0xe7, 0x21, 0xde, 0x30, 0x70);
+
+static int wbrf_dsm(struct acpi_device *adev, u8 fn,
+ union acpi_object *argv4,
+ union acpi_object **out)
+{
+ union acpi_object *obj;
+ int rc;
+
+ obj = acpi_evaluate_dsm(adev->handle, _acpi_dsm_guid,
+ WBRF_REVISION, fn, argv4);
+ if (!obj)
+ return -ENXIO;
+
+ switch (obj->type) {
+ case ACPI_TYPE_BUFFER:
+ if (!*out) {
+ rc = -EINVAL;
+ break;
+ }
+ *out = obj;
+ return 0;
+
+ case ACPI_TYPE_INTEGER:
+ rc = obj->integer.value ? -EINVAL : 0;
+ break;
+ default:
+ rc = -EOPNOTSUPP;
+ }
+ ACPI_FREE(obj);
+
+ return rc;
+}
+
+static int wbrf_record(struct acpi_device *adev, uint8_t action,
+ struct wbrf_ranges_in *in)
+{
+ union acpi_object *argv4;
+ uint32_t num_of_ranges = 0;
+ uint32_t arg_idx = 0;
+ uint32_t loop_idx;
+ int ret;
+
+ if (!in)
+ return -EINVAL;
+
+ for (loop_idx = 0; loop_idx < ARRAY_SIZE(in->band_list);
+loop_idx++)
+ if (in->band_list[loop_idx].start &&
+ in->band_list[loop_idx].end)
+ num_of_ranges++;
+
+ argv4 = kzalloc(sizeof(*argv4) * (2 * num_of_ranges + 2 + 1),
GFP_KERNEL);
+ if (!argv4)
+ return -ENOMEM;
+
+ argv4[arg_idx].package.type = ACPI_TYPE_PACKAGE;
+ argv4[arg_idx].package.count = 2 +
[PATCH V4 0/8] Support Wifi RFI interference mitigation feature
Due to electrical and mechanical constraints in certain platform designs there may be likely interference of relatively high-powered harmonics of the (G-)DDR memory clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate possible RFI interference producers can advertise the frequencies in use and consumers can use this information to avoid using these frequencies for sensitive features. The whole patch set is based on 6.4-rc3. With some brief introductions as below: Patch1: Core ACPI interfaces needed to support WBRF feature. Patch2 - 3: Enable WBRF support for wifi subsystem. Patch4 - 8: Enable WBRF support for AMD graphics driver. Evan Quan (7): cfg80211: expose nl80211_chan_width_to_mhz for wide sharing wifi: mac80211: Add support for ACPI WBRF drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature drm/amd/pm: setup the framework to support Wifi RFI mitigation feature drm/amd/pm: add flood detection for wbrf events drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0 drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7 Mario Limonciello (1): drivers/acpi: Add support for Wifi band RF mitigations drivers/acpi/Kconfig | 7 + drivers/acpi/Makefile | 2 + drivers/acpi/acpi_wbrf.c | 215 ++ drivers/gpu/drm/amd/amdgpu/amdgpu.h | 26 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 63 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 19 ++ drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 204 + drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 30 +++ .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +- .../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +- .../pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h | 3 +- .../pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h | 3 +- drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 + .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 9 + .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 60 + .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 + drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + include/linux/ieee80211.h | 1 + include/linux/wbrf.h | 55 + include/net/cfg80211.h| 8 + net/mac80211/Makefile | 2 + net/mac80211/chan.c | 11 + net/mac80211/ieee80211_i.h| 19 ++ net/mac80211/main.c | 2 + net/mac80211/wbrf.c | 111 + net/wireless/chan.c | 3 +- 27 files changed, 943 insertions(+), 6 deletions(-) create mode 100644 drivers/acpi/acpi_wbrf.c create mode 100644 include/linux/wbrf.h create mode 100644 net/mac80211/wbrf.c -- 2.34.1
Re: [PATCH v4 5/6] dma-buf: Change locking policy for mmap()
Am 20.06.23 um 17:58 schrieb Dmitry Osipenko: On 5/31/23 22:58, Dmitry Osipenko wrote: On 5/30/23 01:39, Dmitry Osipenko wrote: Change locking policy of mmap() callback, making exporters responsible for handling dma-buf reservation locking. Previous locking policy stated that dma-buf is locked for both importers and exporters by the dma-buf core, which caused a deadlock problem for DRM drivers in a case of self-imported dma-bufs which required to take the lock from the DRM exporter side. Reviewed-by: Emil Velikov Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) Christian, you acked the drm patch of this series sometime ago, perhaps it also implies implicit ack to this patch, but I'd prefer to have the explicit ack. I'll apply this series to drm-misc later this week if you'll approve this dma-buf change. Thanks in advance! I'll merge the patches tomorrow. If there are any additional comments, then please don't hesitate to post them. Sorry for not responding earlier, I have been moving both my office as well as my household and still catching up. I don't have time for an in-deep review, but my ack stands for the whole series. Regards, Christian.
RE: [PATCH] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics
[AMD Official Use Only - General]
Could you add the expected units of voltage/current in 2.4 metrics structure?
Is it mV/mA or mV/A?
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Wenyou Yang
Sent: Thursday, June 1, 2023 7:08 AM
To: Deucher, Alexander ; Limonciello, Mario
; Koenig, Christian ; Pan,
Xinhui ; Quan, Evan
Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Yang, WenYou
; amd-...@lists.freedesktop.org; Yuan, Perry
; Liang, Richard qi
Subject: [PATCH] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire
gpu_metrics
To acquire the voltage and current info from gpu_metrics interface, but
gpu_metrics_v2_3 doesn't contain them, and to be backward compatible, add new
gpu_metrics_v2_4 structure.
Acked-by: Evan Quan
Signed-off-by: Wenyou Yang
---
.../gpu/drm/amd/include/kgd_pp_interface.h| 69 +++
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 109 --
drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c| 3 +
3 files changed, 172 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
index 9f542f6e19ed..0f37dafafcf9 100644
--- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
@@ -892,4 +892,73 @@ struct gpu_metrics_v2_3 {
uint16_taverage_temperature_core[8]; // average
CPU core temperature on APUs
uint16_taverage_temperature_l3[2];
};
+
+struct gpu_metrics_v2_4 {
+ struct metrics_table_header common_header;
+
+ /* Temperature */
+ uint16_ttemperature_gfx;
+ uint16_ttemperature_soc;
+ uint16_ttemperature_core[8];
+ uint16_ttemperature_l3[2];
+
+ /* Utilization */
+ uint16_taverage_gfx_activity;
+ uint16_taverage_mm_activity;
+
+ /* Driver attached timestamp (in ns) */
+ uint64_tsystem_clock_counter;
+
+ /* Power/Energy */
+ uint16_taverage_socket_power;
+ uint16_taverage_cpu_power;
+ uint16_taverage_soc_power;
+ uint16_taverage_gfx_power;
+ uint16_taverage_core_power[8];
+
+ /* Average clocks */
+ uint16_taverage_gfxclk_frequency;
+ uint16_taverage_socclk_frequency;
+ uint16_taverage_uclk_frequency;
+ uint16_taverage_fclk_frequency;
+ uint16_taverage_vclk_frequency;
+ uint16_taverage_dclk_frequency;
+
+ /* Current clocks */
+ uint16_tcurrent_gfxclk;
+ uint16_tcurrent_socclk;
+ uint16_tcurrent_uclk;
+ uint16_tcurrent_fclk;
+ uint16_tcurrent_vclk;
+ uint16_tcurrent_dclk;
+ uint16_tcurrent_coreclk[8];
+ uint16_tcurrent_l3clk[2];
+
+ /* Throttle status (ASIC dependent) */
+ uint32_tthrottle_status;
+
+ /* Fans */
+ uint16_tfan_pwm;
+
+ uint16_tpadding[3];
+
+ /* Throttle status (ASIC independent) */
+ uint64_tindep_throttle_status;
+
+ /* Average Temperature */
+ uint16_taverage_temperature_gfx;
+ uint16_taverage_temperature_soc;
+ uint16_taverage_temperature_core[8];
+ uint16_taverage_temperature_l3[2];
+
+ /* Power/Voltage */
+ uint16_taverage_cpu_voltage;
+ uint16_taverage_soc_voltage;
+ uint16_taverage_gfx_voltage;
+
+ /* Power/Current */
+ uint16_taverage_cpu_current;
+ uint16_taverage_soc_current;
+ uint16_taverage_gfx_current;
+};
#endif
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
index 067b4e0b026c..185d0b50ee8e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
@@ -1854,6 +1854,86 @@ static ssize_t vangogh_get_gpu_metrics_v2_3(struct
smu_context *smu,
return sizeof(struct gpu_metrics_v2_3); }
+static ssize_t vangogh_get_gpu_metrics_v2_4(struct smu_context *smu,
+ void
Re: [PATCH net-next v8 03/11] net: bcmasp: Add support for ASP2.0 Ethernet controller
On Fri, 16 Jun 2023 15:14:16 -0700 Justin Chen wrote:
> Add support for the Broadcom ASP 2.0 Ethernet controller which is first
> introduced with 72165. This controller features two distinct Ethernet
> ports that can be independently operated.
First of all - thanks for splitting the patches up.
This one is still a bit big but much better and good enough.
> + /* Probe each interface (Initialization should continue even if
> + * interfaces are unable to come up)
> + */
> + i = 0;
> + for_each_available_child_of_node(ports_node, intf_node) {
> + priv->intfs[i] = bcmasp_interface_create(priv, intf_node, i);
> + i++;
> + }
> +
> + /* Drop the clock reference count now and let ndo_open()/ndo_close()
> + * manage it for us from now on.
> + */
> + bcmasp_core_clock_set(priv, 0, ASP_CTRL_CLOCK_CTRL_ASP_ALL_DISABLE);
> +
> + clk_disable_unprepare(priv->clk);
> +
> + /* Now do the registration of the network ports which will take care
> + * of managing the clock properly.
> + */
> + for (i = 0; i < priv->intf_count; i++) {
> + intf = priv->intfs[i];
> + if (!intf)
> + continue;
> +
> + ret = register_netdev(intf->ndev);
> + if (ret) {
> + netdev_err(intf->ndev,
> +"failed to register net_device: %d\n", ret);
> + bcmasp_interface_destroy(intf, false);
> + continue;
Did you mean to clear the priv->intfs[i] pointer after destroy?
Otherwise remove will try to free it again.
> + }
> + count++;
> + }
> +
> + dev_info(dev, "Initialized %d port(s)\n", count);
> +
> +of_put_exit:
> + of_node_put(ports_node);
> + return ret;
And in case the last register_netdev() fails .probe will return an
error, meaning that .remove will never get called.
Why are you trying to gracefully handle the case where only some ports
were registered? It's error prone, why not fail probe if any netdev
fails to register?
> +}
> +
> +static int bcmasp_remove(struct platform_device *pdev)
> +{
> + struct bcmasp_priv *priv = dev_get_drvdata(>dev);
> + struct bcmasp_intf *intf;
> + int i;
> +
since .shutdown is defined this callback should probably clear the priv
pointer and check whether priv != NULL before proceeding. It's a bit
unclear whether both .remove and .shutdown may get called for the same
device..
> + for (i = 0; i < priv->intf_count; i++) {
> + intf = priv->intfs[i];
> + if (!intf)
> + continue;
> +
> + bcmasp_interface_destroy(intf, true);
> + }
> +
> + return 0;
> +}
> +MODULE_AUTHOR("Broadcom");
Companies cannot be authors. MODULE_AUTHOR() is not required,
you can drop it if you don't want to put your name there.
> + if (unlikely(skb_headroom(skb) < sizeof(*offload))) {
> + new_skb = skb_realloc_headroom(skb, sizeof(*offload));
That's not right, you can't push to an tx skb just because there's
headroom. Use skb_cow_head().
> + if (tx_spb_ring_full(intf, nr_frags + 1)) {
> + netif_stop_queue(dev);
> + netdev_err(dev, "Tx Ring Full!\n");
rate limit this one, please
> + /* Calculate virt addr by offsetting from physical addr */
> + data = intf->rx_ring_cpu +
> + (DESC_ADDR(desc->buf) - intf->rx_ring_dma);
> +
> + flags = DESC_FLAGS(desc->buf);
> + if (unlikely(flags & (DESC_CRC_ERR | DESC_RX_SYM_ERR))) {
> + netif_err(intf, rx_status, intf->ndev, "flags=0x%llx\n",
> + flags);
ditto
> + u64_stats_update_begin(>syncp);
> + if (flags & DESC_CRC_ERR)
> + u64_stats_inc(>rx_crc_errs);
> + if (flags & DESC_RX_SYM_ERR)
> + u64_stats_inc(>rx_sym_errs);
> + u64_stats_inc(>rx_dropped);
Not right, please see the documentation on struct rtnl_link_stats64
These are errors not drops. Please read that comment and double
check all your stats.
> + u64_stats_update_end(>syncp);
> +
> + goto next;
> + }
> +
> + dma_sync_single_for_cpu(kdev, DESC_ADDR(desc->buf), desc->size,
> + DMA_FROM_DEVICE);
> +
> + len = desc->size;
> +
> + skb = __netdev_alloc_skb(intf->ndev, len,
> + GFP_ATOMIC | __GFP_NOWARN);
maybe napi_alloc_skb()?
> + if (!skb) {
> + u64_stats_update_begin(>syncp);
> + u64_stats_inc(>rx_errors);
> + u64_stats_update_end(>syncp);
> +
> + netif_warn(intf, rx_err, intf->ndev,
> +"SKB alloc
Re: [PATCH drm-next v5 09/14] drm/nouveau: fence: separate fence alloc and emit
Hi Danilo,
kernel test robot noticed the following build errors:
[auto build test ERROR on dcb0775d36de28992f56455ab3967b30d380]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230620-084448
base: dcb0775d36de28992f56455ab3967b30d380
patch link:
https://lore.kernel.org/r/20230620004217.4700-10-dakr%40redhat.com
patch subject: [PATCH drm-next v5 09/14] drm/nouveau: fence: separate fence
alloc and emit
config: arm64-allyesconfig
(https://download.01.org/0day-ci/archive/20230621/202306211017.r9g5nqsc-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 12.3.0
reproduce:
(https://download.01.org/0day-ci/archive/20230621/202306211017.r9g5nqsc-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306211017.r9g5nqsc-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/nouveau/nouveau_dmem.c: In function
'nouveau_dmem_migrate_chunk':
>> drivers/gpu/drm/nouveau/nouveau_dmem.c:681:43: error: 'chunk' undeclared
>> (first use in this function)
681 | nouveau_fence_emit(fence,
chunk->drm->dmem->migrate.chan);
| ^
drivers/gpu/drm/nouveau/nouveau_dmem.c:681:43: note: each undeclared
identifier is reported only once for each function it appears in
vim +/chunk +681 drivers/gpu/drm/nouveau/nouveau_dmem.c
664
665 static void nouveau_dmem_migrate_chunk(struct nouveau_drm *drm,
666 struct nouveau_svmm *svmm, struct migrate_vma *args,
667 dma_addr_t *dma_addrs, u64 *pfns)
668 {
669 struct nouveau_fence *fence;
670 unsigned long addr = args->start, nr_dma = 0, i;
671
672 for (i = 0; addr < args->end; i++) {
673 args->dst[i] = nouveau_dmem_migrate_copy_one(drm, svmm,
674 args->src[i], dma_addrs + nr_dma, pfns
+ i);
675 if (!dma_mapping_error(drm->dev->dev,
dma_addrs[nr_dma]))
676 nr_dma++;
677 addr += PAGE_SIZE;
678 }
679
680 if (!nouveau_fence_new())
> 681 nouveau_fence_emit(fence,
> chunk->drm->dmem->migrate.chan);
682 migrate_vma_pages(args);
683 nouveau_dmem_fence_done();
684 nouveau_pfns_map(svmm, args->vma->vm_mm, args->start, pfns, i);
685
686 while (nr_dma--) {
687 dma_unmap_page(drm->dev->dev, dma_addrs[nr_dma],
PAGE_SIZE,
688 DMA_BIDIRECTIONAL);
689 }
690 migrate_vma_finalize(args);
691 }
692
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
RE: [EXT] Re: [PATCH v6 2/8] dt-bindings: display: bridge: Add Cadence MHDP8501 HDMI and DP
Hi Rob, Thanks for your comments, > -Original Message- > From: Rob Herring > Sent: 2023年6月20日 23:49 > To: Sandor Yu > Cc: andrzej.ha...@intel.com; neil.armstr...@linaro.org; > robert.f...@linaro.org; laurent.pinch...@ideasonboard.com; > jo...@kwiboo.se; jernej.skra...@gmail.com; airl...@gmail.com; > dan...@ffwll.ch; krzysztof.kozlowski...@linaro.org; shawn...@kernel.org; > s.ha...@pengutronix.de; feste...@gmail.com; vk...@kernel.org; > dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; > linux-...@lists.infradead.org; ker...@pengutronix.de; dl-linux-imx > ; Oliver Brown > Subject: [EXT] Re: [PATCH v6 2/8] dt-bindings: display: bridge: Add Cadence > MHDP8501 HDMI and DP > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On Thu, Jun 15, 2023 at 09:38:12AM +0800, Sandor Yu wrote: > > Add bindings for Cadence MHDP8501 DisplayPort and HDMI driver. > > Bindings are for h/w, not a driver. OK, I will change it in the next version. > > > > > Signed-off-by: Sandor Yu > > --- > > .../display/bridge/cdns,mhdp8501.yaml | 105 > ++ > > 1 file changed, 105 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml > > b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml > > new file mode 100644 > > index ..a54756815e6f > > --- /dev/null > > +++ > b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.y > > +++ aml > > @@ -0,0 +1,105 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fdisplay%2Fbridge%2Fcdns%2Cmhdp8501.yaml% > 23 > > > +a=05%7C01%7CSandor.yu%40nxp.com%7C4d4e118d60d744b5dba708db71 > a5de79%7C > > > +686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63822872943965530 > 2%7CUnkno > > > +wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > haWwi > > > +LCJXVCI6Mn0%3D%7C3000%7C%7C%7C=UEsMdkZBmfD7tM1wzJ71 > DHQoi4zVOkpT > > +A9TNE7Rxn%2B8%3D=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23=05%7C01%7CSandor. > yu%40n > > > +xp.com%7C4d4e118d60d744b5dba708db71a5de79%7C686ea1d3bc2b4c6fa > 92cd99c5 > > > +c301635%7C0%7C0%7C638228729439655302%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoi > > > +MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3 > 000%7C% > > > +7C%7C=Zu3v0yG2BXWXvTWV5oLiGvdu3O3PhK%2FrYNJIS2zHwpI%3 > D > > +=0 > > + > > +title: Cadence MHDP8501 Displayport bridge > > + > > +maintainers: > > + - Sandor Yu > > + > > +description: > > + The Cadence MHDP8501 Displayport/HDMI TX interface. > > + > > +properties: > > + compatible: > > +enum: > > + - cdns,mhdp8501-dp > > + - cdns,mhdp8501-hdmi > > + - fsl,imx8mq-mhdp8501-dp > > + - fsl,imx8mq-mhdp8501-hdmi > > Is DP vs. HDMI fixed for a particular SoC implementation or it's a board level > decision. In the latter case, the type of connector should determine the mode, > not compatible. DP or HDMI is bord level decision. Because DP and HDMI have different initialize process and less functions could be reuse, so they have different drivers. Please check it in patch [PATCH v6 3/8] drm: bridge: Cadence: Add MHDP8501 DP driver [PATCH v6 5/8] drm: bridge: Cadence: Add MHDP8501 HDMI driver If use the type of connector to determine the mode, hdmi and DP driver have to combine into one driver. So the compatible may the better choice. > > > + > > + reg: > > +maxItems: 1 > > + > > + clocks: > > +maxItems: 1 > > +description: MHDP8501 DP/HDMI APB clock. > > Seems odd there's no clock tied to the pixel/serdes clock. MHDP8501 for i.MX8MQ use the pixel clock from PHY PLL not from external CCM. The pixel clock will be set in function phy_configure B.R Sandor > > > + > > + phys: > > +maxItems: 1 > > + > > + interrupts: > > +items: > > + - description: Hotplug cable plugin. > > + - description: Hotplug cable plugout. > > + > > + interrupt-names: > > +items: > > + - const: plug_in > > + - const: plug_out > > + > > + ports: > > +$ref: /schemas/graph.yaml#/properties/ports > > + > > +properties: > > + port@0: > > +$ref: /schemas/graph.yaml#/properties/port > > +description: > > + Input port from display controller output. > > + port@1: > > +$ref: /schemas/graph.yaml#/properties/port > > +description: > > + Output port to DP/HDMI connector. > > + > > +required: > > + - port@0 > > + - port@1 > > + > > +required: > > + - compatible > > + - reg >
[PATCH v2] drm/i915/guc/slpc: Apply min softlimit correctly
The scenario being fixed here is depicted in the following sequence-
modprobe i915
echo 1 > /sys/class/drm/card0/gt/gt0/slpc_ignore_eff_freq
echo 300 > /sys/class/drm/card0/gt_min_freq_mhz (RPn)
cat /sys/class/drm/card0/gt_cur_freq_mhz --> cur == RPn as expected
echo 1 > /sys/kernel/debug/dri/0/gt0/reset --> reset
cat /sys/class/drm/card0/gt_min_freq_mhz --> cached freq is RPn
cat /sys/class/drm/card0/gt_cur_freq_mhz --> it's not RPn, but RPe!!
When SLPC reinitializes, it sets SLPC min freq to efficient frequency.
Even if we disable efficient freq post that, we should restore the cached
min freq (via H2G) for it to take effect.
v2: Clarify commit message (Ashutosh)
Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
Reviewed-by: Ashutosh Dixit
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 01b75529311c..ee9f83af7cf6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -606,7 +606,7 @@ static int slpc_set_softlimits(struct intel_guc_slpc *slpc)
if (unlikely(ret))
return ret;
slpc_to_gt(slpc)->defaults.min_freq = slpc->min_freq_softlimit;
- } else if (slpc->min_freq_softlimit != slpc->min_freq) {
+ } else {
return intel_guc_slpc_set_min_freq(slpc,
slpc->min_freq_softlimit);
}
--
2.38.1
RE: [PATCH V3 1/7] drivers/acpi: Add support for Wifi band RF mitigations
[AMD Official Use Only - General]
> -Original Message-
> From: Limonciello, Mario
> Sent: Monday, June 19, 2023 10:04 AM
> To: Quan, Evan
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; raf...@kernel.org; l...@kernel.org; Deucher,
> Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Lazar, Lijo
> Subject: Re: [PATCH V3 1/7] drivers/acpi: Add support for Wifi band RF
> mitigations
>
> On 6/16/23 01:57, Evan Quan wrote:
> > From: Mario Limonciello
> >
> > Due to electrical and mechanical constraints in certain platform
> > designs there may be likely interference of relatively high-powered
> > harmonics of the (G-)DDR memory clocks with local radio module
> > frequency bands used by Wifi 6/6e/7.
> >
> > To mitigate this, AMD has introduced an ACPI based mechanism that
> > devices can use to notify active use of particular frequencies so that
> > devices can make relative internal adjustments as necessary to avoid
> > this resonance.
> >
> > In order for a device to support this, the expected flow for device
> > driver or subsystems:
> >
> > Drivers/subsystems contributing frequencies:
> >
> > 1) During probe, check `wbrf_supported_producer` to see if WBRF
> supported
> > for the device.
> > 2) If adding frequencies, then call `wbrf_add_exclusion` with the
> > start and end ranges of the frequencies.
> > 3) If removing frequencies, then call `wbrf_remove_exclusion` with
> > start and end ranges of the frequencies.
> >
> > Drivers/subsystems responding to frequencies:
> >
> > 1) During probe, check `wbrf_supported_consumer` to see if WBRF is
> supported
> > for the device.
> > 2) Call the `wbrf_retrieve_exclusions` to retrieve the current
> > exclusions on receiving an ACPI notification for a new frequency
> > change.
> >
> > Signed-off-by: Mario Limonciello
> > Co-developed-by: Evan Quan
> > Signed-off-by: Evan Quan
> > --
> > v1->v2:
> >- move those wlan specific implementations to net/mac80211(Mario)
> > ---
> > drivers/acpi/Kconfig | 7 ++
> > drivers/acpi/Makefile| 2 +
> > drivers/acpi/acpi_wbrf.c | 215
> +++
> > include/linux/wbrf.h | 55 ++
> > 4 files changed, 279 insertions(+)
> > create mode 100644 drivers/acpi/acpi_wbrf.c
> > create mode 100644 include/linux/wbrf.h
> >
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index
> > ccbeab9500ec..9ee7c7dcc3e6 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -611,3 +611,10 @@ config X86_PM_TIMER
> >
> > You should nearly always say Y here because many modern
> > systems require this timer.
> > +
> > +config ACPI_WBRF
> > + bool "ACPI Wifi band RF mitigation mechanism"
> > + help
> > + Wifi band RF mitigation mechanism allows multiple drivers from
> > + different domains to notify the frequencies in use so that hardware
> > + can be reconfigured to avoid harmonic conflicts.
> > \ No newline at end of file
>
> There should be a newline at the end of the Kconfig file.
OK, will add that.
Evan
>
> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index
> > feb36c0b9446..be173e76aa62 100644
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -131,3 +131,5 @@ obj-y += dptf/
> > obj-$(CONFIG_ARM64) += arm64/
> >
> > obj-$(CONFIG_ACPI_VIOT) += viot.o
> > +
> > +obj-$(CONFIG_ACPI_WBRF)+= acpi_wbrf.o
> > \ No newline at end of file
> > diff --git a/drivers/acpi/acpi_wbrf.c b/drivers/acpi/acpi_wbrf.c new
> > file mode 100644 index ..8c275998ac29
> > --- /dev/null
> > +++ b/drivers/acpi/acpi_wbrf.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * AMD Wifi Band Exclusion Interface
> > + * Copyright (C) 2023 Advanced Micro Devices
> > + *
> > + */
> > +
> > +#include
> > +
> > +/* functions */
> > +#define WBRF_RECORD0x1
> > +#define WBRF_RETRIEVE 0x2
> > +
> > +/* record actions */
> > +#define WBRF_RECORD_ADD0x0
> > +#define WBRF_RECORD_REMOVE 0x1
> > +
> > +#define WBRF_REVISION 0x1
> > +
> > +static const guid_t wifi_acpi_dsm_guid =
> > + GUID_INIT(0x7b7656cf, 0xdc3d, 0x4c1c,
> > + 0x83, 0xe9, 0x66, 0xe7, 0x21, 0xde, 0x30, 0x70);
> > +
> > +static int wbrf_dsm(struct acpi_device *adev, u8 fn,
> > + union acpi_object *argv4,
> > + union acpi_object **out)
> > +{
> > + union acpi_object *obj;
> > + int rc;
> > +
> > + obj = acpi_evaluate_dsm(adev->handle, _acpi_dsm_guid,
> > +
RE: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF
[AMD Official Use Only - General]
> -Original Message-
> From: Limonciello, Mario
> Sent: Monday, June 19, 2023 10:17 AM
> To: Quan, Evan
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; raf...@kernel.org; l...@kernel.org; Deucher,
> Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Lazar, Lijo
> Subject: Re: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF
>
> On 6/16/23 01:57, Evan Quan wrote:
> > From: Mario Limonciello
> >
> > To support AMD's WBRF interference mitigation mechanism, Wifi adapters
> > utilized in the system must register the frequencies in use(or
> > unregister those frequencies no longer used) via the dedicated APCI
> > calls. So that, other drivers responding to the frequencies can take
> > proper actions to mitigate possible interference.
> >
> > To make WBRF feature functional, the kernel needs to be configured
> > with CONFIG_ACPI_WBRF and the platform is equipped with WBRF
> > support(from BIOS and drivers).
> >
> > Signed-off-by: Mario Limonciello
> > Co-developed-by: Evan Quan
> > Signed-off-by: Evan Quan
> > --
> > v1->v2:
> >- place the new added member(`wbrf_supported`) in
> > ieee80211_local(Johannes)
> >- handle chandefs change scenario properly(Johannes)
> >- some minor fixes around code sharing and possible invalid input
> > checks(Johannes)
> > ---
> > include/net/cfg80211.h | 8 +++
> > net/mac80211/Makefile | 2 +
> > net/mac80211/chan.c| 11 +++
> > net/mac80211/ieee80211_i.h | 19 +
> > net/mac80211/main.c| 2 +
> > net/mac80211/wbrf.c| 137
> +
> > net/wireless/chan.c| 3 +-
> > 7 files changed, 181 insertions(+), 1 deletion(-)
> > create mode 100644 net/mac80211/wbrf.c
> >
> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index
> > 9e04f69712b1..c6dc337eafce 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
> > cfg80211_chandef_compatible(const struct cfg80211_chan_def
> *chandef1,
> > const struct cfg80211_chan_def *chandef2);
> >
> > +/**
> > + * nl80211_chan_width_to_mhz - get the channel width in Mhz
> > + * @chan_width: the channel width from nl80211_chan_width
> > + * Return: channel width in Mhz if the chan_width from
> > +nl80211_chan_width
> > + * is valid. -1 otherwise.
> > + */
> > +int nl80211_chan_width_to_mhz(enum nl80211_chan_width
> chan_width);
> > +
>
> It's up to mac80211 maintainers, but I would think that the changes to change
> nl80211_chan_width_to_mhz from static to exported should be separate
> from the patch to introduced WBRF support in the series.
Will do that.
>
> > /**
> >* cfg80211_chandef_valid - check if a channel definition is valid
> >* @chandef: the channel definition to check diff --git
> > a/net/mac80211/Makefile b/net/mac80211/Makefile index
> > b8de44da1fb8..709eb678f42a 100644
> > --- a/net/mac80211/Makefile
> > +++ b/net/mac80211/Makefile
> > @@ -65,4 +65,6 @@ rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS)
> += \
> >
> > mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-
> y)
> >
> > +mac80211-$(CONFIG_ACPI_WBRF) += wbrf.o
> > +
> > ccflags-y += -DDEBUG
> > diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c index
> > 77c90ed8f5d7..0c5289a9aa6c 100644
> > --- a/net/mac80211/chan.c
> > +++ b/net/mac80211/chan.c
> > @@ -506,11 +506,16 @@ static void _ieee80211_change_chanctx(struct
> > ieee80211_local *local,
> >
> > WARN_ON(!cfg80211_chandef_compatible(>conf.def,
> chandef));
> >
> > + ieee80211_remove_wbrf(local, >conf.def);
> > +
> > ctx->conf.def = *chandef;
> >
> > /* check if min chanctx also changed */
> > changed = IEEE80211_CHANCTX_CHANGE_WIDTH |
> > _ieee80211_recalc_chanctx_min_def(local, ctx, rsvd_for);
> > +
> > + ieee80211_add_wbrf(local, >conf.def);
> > +
> > drv_change_chanctx(local, ctx, changed);
> >
> > if (!local->use_chanctx) {
> > @@ -668,6 +673,10 @@ static int ieee80211_add_chanctx(struct
> ieee80211_local *local,
> > lockdep_assert_held(>mtx);
> > lockdep_assert_held(>chanctx_mtx);
> >
> > + err = ieee80211_add_wbrf(local, >conf.def);
> > + if (err)
> > + return err;
> > +
> > if (!local->use_chanctx)
> > local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
> >
> > @@ -748,6 +757,8 @@ static void ieee80211_del_chanctx(struct
> ieee80211_local *local,
> > }
> >
> > ieee80211_recalc_idle(local);
> > +
> > + ieee80211_remove_wbrf(local, >conf.def);
> > }
> >
> > static
RE: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF
[AMD Official Use Only - General] > -Original Message- > From: Johannes Berg > Sent: Monday, June 19, 2023 4:24 PM > To: Limonciello, Mario ; Quan, Evan > > Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux- > wirel...@vger.kernel.org; raf...@kernel.org; l...@kernel.org; Deucher, > Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name; > lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com; > sean.w...@mediatek.com; matthias@gmail.com; > angelogioacchino.delre...@collabora.com; Lazar, Lijo > Subject: Re: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF > > On Sun, 2023-06-18 at 21:17 -0500, Mario Limonciello wrote: > > > > > --- a/include/net/cfg80211.h > > > +++ b/include/net/cfg80211.h > > > @@ -920,6 +920,14 @@ const struct cfg80211_chan_def * > > > cfg80211_chandef_compatible(const struct cfg80211_chan_def > *chandef1, > > > const struct cfg80211_chan_def *chandef2); > > > > > > +/** > > > + * nl80211_chan_width_to_mhz - get the channel width in Mhz > > > + * @chan_width: the channel width from nl80211_chan_width > > > + * Return: channel width in Mhz if the chan_width from > > > +nl80211_chan_width > > > + * is valid. -1 otherwise. > > > + */ > > > +int nl80211_chan_width_to_mhz(enum nl80211_chan_width > chan_width); > > > + > > > > It's up to mac80211 maintainers, but I would think that the changes to > > change nl80211_chan_width_to_mhz from static to exported should be > > separate from the patch to introduced WBRF support in the series. > > Yeah, that'd be nice :) OK, I will move that into a new patch. > > > > > +#define KHZ_TO_HZ(freq) ((freq) * 1000ULL) > > Together with MHZ_TO_KHZ() for example :) Sure. Evan > > johannes
[RFC PATCH v3 4/4] drm/i915: Implement DRM_IOCTL_GET_RESET
Implement get_reset ioctl for i915.
Signed-off-by: André Almeida
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 18 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h| 2 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 ++
drivers/gpu/drm/i915/i915_driver.c | 2 ++
4 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9a9ff84c90d7..fba8c9bbc7e9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1666,6 +1666,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
ctx->uses_protected_content = true;
}
+ ctx->dev_reset_counter = i915_reset_count(>gpu_error);
+
trace_i915_context_create(ctx);
return ctx;
@@ -2558,6 +2560,22 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
return 0;
}
+int i915_gem_get_reset(struct drm_file *filp, struct drm_device *dev,
+ struct drm_get_reset *reset)
+{
+ struct i915_gem_context *ctx;
+
+ ctx = i915_gem_context_lookup(file->driver_priv, reset->ctx_id);
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
+
+ reset->dev_reset_count = i915_reset_count(>gpu_error) -
ctx->dev_reset_count;
+ reset->ctx_reset_count = ctx->guilty_count;
+
+ i915_gem_context_put(ctx);
+ return 0;
+}
+
/* GEM context-engines iterator: for_each_gem_engine() */
struct intel_context *
i915_gem_engines_iter_next(struct i915_gem_engines_iter *it)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e5b0f66ea1fe..9ee119d8123f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -138,6 +138,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv);
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_gem_get_reset(struct drm_file *file_priv, struct drm_device *dev,
+ struct drm_get_reset *reset);
struct i915_gem_context *
i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index cb78214a7dcd..2e4cf0f0d3dc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -414,6 +414,8 @@ struct i915_gem_context {
/** @engines: list of stale engines */
struct list_head engines;
} stale;
+
+ uint64_t dev_reset_counter;
};
#endif /* __I915_GEM_CONTEXT_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 97244541ec28..640304141ada 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1805,6 +1805,8 @@ static const struct drm_driver i915_drm_driver = {
.postclose = i915_driver_postclose,
.show_fdinfo = i915_drm_client_fdinfo,
+ .get_reset = i915_gem_get_reset,
+
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = i915_gem_prime_import,
--
2.41.0
[RFC PATCH v3 3/4] drm/amdgpu: Implement DRM_IOCTL_GET_RESET
Implement get_reset ioctl for amdgpu
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 35 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 5
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 12 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 2 ++
6 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2eb2c66843a8..0ba26b4b039c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1262,8 +1262,10 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
uint64_t seq;
int r;
- for (i = 0; i < p->gang_size; ++i)
+ for (i = 0; i < p->gang_size; ++i) {
+ p->jobs[i]->ctx = p->ctx;
drm_sched_job_arm(>jobs[i]->base);
+ }
for (i = 0; i < p->gang_size; ++i) {
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index d2139ac12159..d3e292382d4a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -322,6 +322,9 @@ static int amdgpu_ctx_init(struct amdgpu_ctx_mgr *mgr,
int32_t priority,
ctx->init_priority = priority;
ctx->override_priority = AMDGPU_CTX_PRIORITY_UNSET;
+ ctx->global_reset_counter = atomic_read(>adev->gpu_reset_counter);
+ ctx->local_reset_counter = 0;
+
r = amdgpu_ctx_get_stable_pstate(ctx, _stable_pstate);
if (r)
return r;
@@ -963,3 +966,35 @@ void amdgpu_ctx_mgr_usage(struct amdgpu_ctx_mgr *mgr,
}
mutex_unlock(>lock);
}
+
+int amdgpu_get_reset(struct drm_file *filp, struct drm_device *dev,
+struct drm_get_reset *reset)
+{
+ struct amdgpu_device *adev = drm_to_adev(dev);
+ struct amdgpu_ctx *ctx;
+ struct amdgpu_ctx_mgr *mgr;
+ unsigned int id = reset->ctx_id;
+ struct amdgpu_fpriv *fpriv = filp->driver_priv;
+
+ mgr = >ctx_mgr;
+ mutex_lock(>lock);
+ ctx = idr_find(>ctx_handles, id);
+ if (!ctx) {
+ mutex_unlock(>lock);
+ return -EINVAL;
+ }
+
+ reset->dev_reset_count =
+ atomic_read(>gpu_reset_counter) -
ctx->global_reset_counter;
+
+ reset->ctx_reset_count = ctx->local_reset_counter;
+
+ if (amdgpu_in_reset(adev))
+ reset->flags |= DRM_RESET_IN_PROGRESS;
+
+ if (ctx->vram_lost_counter != atomic_read(>vram_lost_counter))
+ reset->flags |= DRM_RESET_VRAM_LOST;
+
+ mutex_unlock(>lock);
+ return 0;
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
index 0fa0e56daf67..0c9815695884 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
@@ -57,6 +57,9 @@ struct amdgpu_ctx {
unsigned long ras_counter_ce;
unsigned long ras_counter_ue;
uint32_tstable_pstate;
+
+ uint64_tglobal_reset_counter;
+ uint64_tlocal_reset_counter;
};
struct amdgpu_ctx_mgr {
@@ -97,4 +100,6 @@ void amdgpu_ctx_mgr_fini(struct amdgpu_ctx_mgr *mgr);
void amdgpu_ctx_mgr_usage(struct amdgpu_ctx_mgr *mgr,
ktime_t usage[AMDGPU_HW_IP_NUM]);
+int amdgpu_get_reset(struct drm_file *file_priv, struct drm_device *dev,
+struct drm_get_reset *reset);
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index c9a41c997c6c..431791b2c3cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2805,6 +2805,7 @@ static const struct drm_driver amdgpu_kms_driver = {
#ifdef CONFIG_PROC_FS
.show_fdinfo = amdgpu_show_fdinfo,
#endif
+ .get_reset = amdgpu_get_reset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index c3d9d75143f4..1553a2633d46 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -35,11 +35,20 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(struct
drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
+ struct drm_sched_entity *entity = job->base.entity;
struct amdgpu_task_info ti;
struct amdgpu_device *adev = ring->adev;
int idx;
int r;
+ memset(, 0, sizeof(struct amdgpu_task_info));
+ amdgpu_vm_get_task_info(ring->adev, job->pasid,
[RFC PATCH v3 2/4] drm: Create DRM_IOCTL_GET_RESET
Create a new DRM ioctl operation to get the numbers of resets for a
given context. The numbers reflect just the resets that happened after
the context was created, and not since the machine was booted.
Create a debugfs interface to make easier to test the API without real
resets.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_debugfs.c | 2 ++
drivers/gpu/drm/drm_ioctl.c | 58 +++
include/drm/drm_device.h | 3 ++
include/drm/drm_drv.h | 3 ++
include/uapi/drm/drm.h| 21 +
include/uapi/drm/drm_mode.h | 15 +
6 files changed, 102 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4855230ba2c6..316dce60434d 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -251,6 +251,8 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
list_del(>list);
}
+ debugfs_create_bool("drm_reset_spoof", 0644, minor->debugfs_root,
>reset_spoof);
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7c9d66ee917d..23c282681ec7 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -528,6 +528,63 @@ int drm_version(struct drm_device *dev, void *data,
return err;
}
+/**
+ * drm_spoof_reset - Spoof a fake reset
+ *
+ * @reset: reset struct to be spoofed
+ *
+ * Create a fake reset report for testing
+ */
+static void drm_spoof_reset(struct drm_get_reset *reset)
+{
+ reset->dev_reset_count = 1;
+ reset->ctx_reset_count = 0;
+ reset->flags = 0;
+ reset->ctx_id = 0;
+
+ DRM_INFO("[Spoofed] Reporting reset.ctx = %llu .dev = %llu\n",
+ reset->ctx_reset_count, reset->dev_reset_count);
+}
+
+/**
+ * drm_getreset - Get reset information from a DRM device
+ *
+ * @dev DRM device
+ * @data user argument, pointing to a drm_get_reset structure
+ * @filp file pointer
+ *
+ * Return zero on success or negative number on failure.
+ *
+ * Fills in the reset information in data arg.
+ */
+int drm_getreset(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_get_reset *reset = data;
+ int ret = 0;
+
+ if (dev->reset_spoof) {
+ drm_spoof_reset(reset);
+ return 0;
+ }
+
+ if (!dev->driver->get_reset)
+ return -ENOSYS;
+
+ if (reset->flags)
+ return -EINVAL;
+
+ ret = dev->driver->get_reset(file_priv, dev, reset);
+
+ if (!ret)
+ DRM_INFO("Reporting reset.ctx = %llu .dev = %llu\n",
+ reset->ctx_reset_count, reset->dev_reset_count);
+ else
+ DRM_WARN("%s failed with %d return\n", __func__, ret);
+
+ return ret;
+}
+
static int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
{
/* ROOT_ONLY is only for CAP_SYS_ADMIN */
@@ -716,6 +773,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, drm_mode_revoke_lease_ioctl,
DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_RESET, drm_getreset, DRM_RENDER_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE(drm_ioctls)
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7cf4afae2e79..fcd7b5d45cde 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -326,6 +326,9 @@ struct drm_device {
*/
struct list_head debugfs_list;
+ /* Spoof device reset for testing */
+ bool reset_spoof;
+
/* Everything below here is for legacy driver, never use! */
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 89e2706cac56..518a9db157fb 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -401,6 +401,9 @@ struct drm_driver {
struct drm_device *dev, uint32_t handle,
uint64_t *offset);
+ int (*get_reset)(struct drm_file *file_priv,
+struct drm_device *dev, struct drm_get_reset *reset);
+
/**
* @show_fdinfo:
*
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index a87ca2d4..a84559aa0d77 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -1169,6 +1169,27 @@ extern "C" {
*/
#define DRM_IOCTL_MODE_GETFB2 DRM_IOWR(0xCE, struct drm_mode_fb_cmd2)
+/**
+ * DRM_IOCTL_GET_RESET - Get information about device resets
+ *
+ * This operation requests from the device information about resets. It should
+ * consider only resets that happens after the context is created, therefore,
+ * the counter should be zero during context creation.
+ *
+ *
[RFC PATCH v3 1/4] drm/doc: Document DRM device reset expectations
Create a section that specifies how to deal with DRM device resets for kernel and userspace drivers. Signed-off-by: André Almeida --- Documentation/gpu/drm-uapi.rst | 65 ++ 1 file changed, 65 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 65fb3036a580..da4f8a694d8d 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -285,6 +285,71 @@ for GPU1 and GPU2 from different vendors, and a third handler for mmapped regular files. Threads cause additional pain with signal handling as well. +Device reset + + +The GPU stack is really complex and is prone to errors, from hardware bugs, +faulty applications and everything in between the many layers. To recover +from this kind of state, sometimes is needed to reset the device. This section +describes what's the expectations for DRM and usermode drivers when a device +resets and how to propagate the reset status. + +Kernel Mode Driver +-- + +The KMD is responsible for checking if the device needs a reset, and to perform +it as needed. Usually a hung is detected when a job gets stuck executing. KMD +then update it's internal reset tracking to be ready when userspace asks the +kernel about reset information. Drivers should implement the DRM_IOCTL_GET_RESET +for that. + +User Mode Driver + + +The UMD should check before submitting new commands to the KMD if the device has +been reset, and this can be checked more often if it requires to. The +DRM_IOCTL_GET_RESET is the default interface for those kind of checks. After +detecting a reset, UMD will then proceed to report it to the application using +the appropriated API error code, as explained in the bellow section about +robustness. + +Robustness +-- + +The only way to try to keep an application working after a reset is if it +complies with the robustness aspects of the graphical API that is using. + +Graphical APIs provide ways to application to deal with device resets. However, +there's no guarantee that the app will be correctly using such features, and UMD +can implement policies to close the app if it's a repeating offender, likely in +a broken loop. This is done to ensure that it doesn't keeps blocking the user +interface to be correctly displayed. + +OpenGL +~~ + +Apps using OpenGL can rely on ``GL_ARB_robustness`` to be robust. This extension +tells if a reset has happened, and if so, all the context state is considered +lost and the app proceeds by creating new ones. If robustness isn't in use, UMD +will terminate the app when a reset is detected, giving that the contexts are +lost and the app won't be able to figure this out and recreate the contexts. + +Vulkan +~~ + +Apps using Vulkan should check for ``VK_ERROR_DEVICE_LOST`` for submissions. +This error code means, among other things, that a device reset has happened and +it needs to recreate the contexts to keep going. + +Reporting resets causes +--- + +Apart from propagating the reset through the stack so apps can recover, it's +really useful for driver developers to learn more about what caused the reset in +first place. DRM devices should make use of devcoredump to store relevant +information about the reset, so this information can be added to user bug +reports. + .. _drm_driver_ioctl: IOCTL Support on Device Nodes -- 2.41.0
[RFC PATCH v3 0/4] drm: Standardize device reset notification
Hi, This is a new version of the documentation for DRM device resets. As I dived more in the subject, I started to believe that part of the problem was the lack of a DRM API to get reset information from the driver. With an API, we can better standardize reset queries, increase common code from both DRM and Mesa, and make easier to write end-to-end tests. So this patchset, along with the documentation, comes with a new IOCTL and two implementations of it for amdgpu and i915 (although just the former was really tested). This IOCTL uses the "context id" to query reset information, but this might be not generic enough to be included in a DRM API. At least for amdgpu, this information is encapsulated by libdrm so one can't just call the ioctl directly from the UMD as I was planning to, but a small refactor can be done to expose the id. Anyway, I'm sharing it as it is to gather feedback if this seems to work. The amdgpu and i915 implementations are provided as a mean of testing and as exemplification, and not as reference code yet, as the goal is more about the interface itself then the driver parts. For the documentation itself, after spending some time reading the reset path in the kernel in Mesa, I decide to rewrite it to better reflect how it works, from bottom to top. You can check the userspace side of the IOCLT here: Mesa: https://gitlab.freedesktop.org/andrealmeid/mesa/-/commit/cd687b22fb32c21b23596c607003e2a495f465 libdrm: https://gitlab.freedesktop.org/andrealmeid/libdrm/-/commit/b31e5404893ee9a85d1aa67e81c2f58c1dac3c46 For testing, I use this vulkan app that has an infinity loop in the shader: https://github.com/andrealmeid/vulkan-triangle-v1 Feedbacks are welcomed! Thanks, André v2: https://lore.kernel.org/all/20230227204000.56787-1-andrealm...@igalia.com/ v1: https://lore.kernel.org/all/20230123202646.356592-1-andrealm...@igalia.com/ André Almeida (4): drm/doc: Document DRM device reset expectations drm: Create DRM_IOCTL_GET_RESET drm/amdgpu: Implement DRM_IOCTL_GET_RESET drm/i915: Implement DRM_IOCTL_GET_RESET Documentation/gpu/drm-uapi.rst| 51 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 35 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 5 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 12 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 2 + drivers/gpu/drm/drm_debugfs.c | 2 + drivers/gpu/drm/drm_ioctl.c | 58 +++ drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 ++ drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 2 + drivers/gpu/drm/i915/i915_driver.c| 2 + include/drm/drm_device.h | 3 + include/drm/drm_drv.h | 3 + include/uapi/drm/drm.h| 21 +++ include/uapi/drm/drm_mode.h | 15 + 17 files changed, 233 insertions(+), 3 deletions(-) -- 2.41.0
Re: [PATCH] drm/mediatek: Fix void-pointer-to-enum-cast warning
Hi Jason-JH.Lin,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.4-rc7 next-20230620]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Jason-JH-Lin/drm-mediatek-Fix-void-pointer-to-enum-cast-warning/20230620-182906
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230620102804.17585-1-jason-jh.lin%40mediatek.com
patch subject: [PATCH] drm/mediatek: Fix void-pointer-to-enum-cast warning
config: arm-allmodconfig
(https://download.01.org/0day-ci/archive/20230621/202306210852.jwlkcawy-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 12.3.0
reproduce:
(https://download.01.org/0day-ci/archive/20230621/202306210852.jwlkcawy-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306210852.jwlkcawy-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c: In function
'ovl_adaptor_comp_init':
>> drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c:429:24: error: incompatible
>> types when assigning to type 'enum mtk_ovl_adaptor_comp_type' from type
>> 'const void *'
429 | type = of_id->data;
|^
--
drivers/gpu/drm/mediatek/mtk_drm_drv.c: In function 'mtk_drm_probe':
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c:831:29: error: incompatible types
>> when assigning to type 'enum mtk_ddp_comp_type' from type 'const void *'
831 | comp_type = of_id->data;
| ^
vim +429 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
405
406 static int ovl_adaptor_comp_init(struct device *dev, struct
component_match **match)
407 {
408 struct mtk_disp_ovl_adaptor *priv = dev_get_drvdata(dev);
409 struct device_node *node, *parent;
410 struct platform_device *comp_pdev;
411
412 parent = dev->parent->parent->of_node->parent;
413
414 for_each_child_of_node(parent, node) {
415 const struct of_device_id *of_id;
416 enum mtk_ovl_adaptor_comp_type type;
417 int id;
418
419 of_id = of_match_node(mtk_ovl_adaptor_comp_dt_ids,
node);
420 if (!of_id)
421 continue;
422
423 if (!of_device_is_available(node)) {
424 dev_dbg(dev, "Skipping disabled component
%pOF\n",
425 node);
426 continue;
427 }
428
> 429 type = of_id->data;
430 id = ovl_adaptor_comp_get_id(dev, node, type);
431 if (id < 0) {
432 dev_warn(dev, "Skipping unknown component
%pOF\n",
433 node);
434 continue;
435 }
436
437 comp_pdev = of_find_device_by_node(node);
438 if (!comp_pdev)
439 return -EPROBE_DEFER;
440
441 priv->ovl_adaptor_comp[id] = _pdev->dev;
442
443 drm_of_component_match_add(dev, match, compare_of,
node);
444 dev_dbg(dev, "Adding component match for %pOF\n", node);
445 }
446
447 if (!*match) {
448 dev_err(dev, "No match device for ovl_adaptor\n");
449 return -ENODEV;
450 }
451
452 return 0;
453 }
454
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH] drm/amd/amdgpu: Properly tune the size of struct
Hi Su, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.4-rc7 next-20230620] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Su-Hui/drm-amd-amdgpu-Properly-tune-the-size-of-struct/20230620-130013 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230620045919.492128-1-suhui%40nfschina.com patch subject: [PATCH] drm/amd/amdgpu: Properly tune the size of struct config: csky-randconfig-s041-20230620 (https://download.01.org/0day-ci/archive/20230621/202306210814.ejjpl8qs-...@intel.com/config) compiler: csky-linux-gcc (GCC) 12.3.0 reproduce: (https://download.01.org/0day-ci/archive/20230621/202306210814.ejjpl8qs-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202306210814.ejjpl8qs-...@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression >> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: incorrect >> type in initializer (different address spaces) @@ expected void >> [noderef] __user *__p @@ got unsigned int [usertype] * @@ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: expected void [noderef] __user *__p drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: got unsigned int [usertype] * drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected void [noderef] __user *__p @@ got unsigned int [usertype] * @@ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: expected void [noderef] __user *__p drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: got unsigned int [usertype] * drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected void [noderef] __user *__p @@ got unsigned int [usertype] * @@ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: expected void [noderef] __user *__p drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: got unsigned int [usertype] * drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:
RE: [PATCH V3 4/7] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature
[AMD Official Use Only - General]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, June 19, 2023 10:55 PM
> To: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Limonciello, Mario
>
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org
> Subject: Re: [PATCH V3 4/7] drm/amd/pm: setup the framework to support
> Wifi RFI mitigation feature
>
>
>
> On 6/16/2023 12:27 PM, Evan Quan wrote:
> > With WBRF feature supported, as a driver responding to the
> > frequencies, amdgpu driver is able to do shadow pstate switching to
> > mitigate possible interference(between its (G-)DDR memory clocks and
> > local radio module frequency bands used by Wifi 6/6e/7).
> >
> > To make WBRF feature functional, the kernel needs to be configured
> > with CONFIG_ACPI_WBRF and the platform is equipped with necessary ACPI
> > based mechanism to get amdgpu driver notified.
> >
> > Signed-off-by: Evan Quan
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 26 +++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 63 ++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 19 ++
> > drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 184
> ++
> > drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 20 ++
> > drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 +
> > 6 files changed, 315 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 02b827785e39..2f2ec64ed1b2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -50,6 +50,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -241,6 +242,7 @@ extern int amdgpu_num_kcq;
> > #define AMDGPU_VCNFW_LOG_SIZE (32 * 1024)
> > extern int amdgpu_vcnfw_log;
> > extern int amdgpu_sg_display;
> > +extern int amdgpu_wbrf;
> >
> > #define AMDGPU_VM_MAX_NUM_CTX 4096
> > #define AMDGPU_SG_THRESHOLD (256*1024*1024)
> > @@ -741,6 +743,9 @@ struct amdgpu_reset_domain;
> >*/
> > #define AMDGPU_HAS_VRAM(_adev) ((_adev)->gmc.real_vram_size)
> >
> > +typedef
> > +void (*wbrf_notify_handler) (struct amdgpu_device *adev);
> > +
> > struct amdgpu_device {
> > struct device *dev;
> > struct pci_dev *pdev;
> > @@ -1050,6 +1055,8 @@ struct amdgpu_device {
> >
> > booljob_hang;
> > booldc_enabled;
> > +
> > + wbrf_notify_handler wbrf_event_handler;
> > };
> >
> > static inline struct amdgpu_device *drm_to_adev(struct drm_device
> > *ddev) @@ -1381,6 +1388,25 @@ static inline int
> amdgpu_acpi_smart_shift_update(struct drm_device *dev,
> > enum amdgpu_ss ss_state)
> { return 0; }
> > #endif
> >
> > +#if defined(CONFIG_ACPI_WBRF)
> > +bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev); int
> > +amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
> > +struct wbrf_ranges_out
> *exclusions_out); int
> > +amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
> > +wbrf_notify_handler handler); int
> > +amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device
> > +*adev); #else static inline bool amdgpu_acpi_is_wbrf_supported(struct
> > +amdgpu_device *adev) { return false; } static inline int
> > +amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
> > +struct wbrf_ranges_out
> *exclusions_out) { return 0; } static
> > +inline int amdgpu_acpi_register_wbrf_notify_handler(struct
> > +amdgpu_device *adev,
> > +wbrf_notify_handler handler)
> { return 0; } static inline
> > +int amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device
> > +*adev) { return 0; } #endif
> > +
> > #if defined(CONFIG_ACPI) && defined(CONFIG_SUSPEND)
> > bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev);
> > bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev); diff
> > --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > index aeeec211861c..efbe6dd91d1a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -1105,3 +1105,66 @@ bool amdgpu_acpi_is_s0ix_active(struct
> amdgpu_device *adev)
> > }
> >
> > #endif /* CONFIG_SUSPEND */
> > +
> >
Re: [Freedreno] [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 6/20/2023 3:11 PM, Dmitry Baryshkov wrote: On Wed, 21 Jun 2023 at 00:37, Jessica Zhang wrote: On 6/16/2023 5:37 PM, Dmitry Baryshkov wrote: On 17/06/2023 00:10, Abhinav Kumar wrote: On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote: On 14/06/2023 23:39, Abhinav Kumar wrote: On 6/14/2023 12:54 PM, Abhinav Kumar wrote: On 6/14/2023 12:35 PM, Abhinav Kumar wrote: On 6/14/2023 5:23 AM, Marijn Suijten wrote: On 2023-06-14 15:01:59, Dmitry Baryshkov wrote: On 14/06/2023 14:42, Marijn Suijten wrote: On 2023-06-13 18:57:11, Jessica Zhang wrote: DPU 5.x+ supports a databus widen mode that allows more data to be sent per pclk. Enable this feature flag on all relevant chipsets. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c index 36ba3f58dcdf..0be7bf0bfc41 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -103,7 +103,8 @@ (BIT(DPU_INTF_INPUT_CTRL) | \ BIT(DPU_INTF_TE) | \ BIT(DPU_INTF_STATUS_SUPPORTED) | \ - BIT(DPU_DATA_HCTL_EN)) + BIT(DPU_DATA_HCTL_EN) | \ + BIT(DPU_INTF_DATABUS_WIDEN)) This doesn't work. DPU 5.0.0 is SM8150, which has DSI 6G 2.3. In the last patch for DSI you state and enable widebus for DSI 6G 2.5+ only, meaning DPU and DSI are now desynced, and the output is completely corrupted. I looked at the internal docs and also this change. This change is incorrect because this will try to enable widebus for DPU >= 5.0 and DSI >= 2.5 That was not the intended right condition as thats not what the docs say. We should enable for DPU >= 7.0 and DSI >= 2.5 Is there any combination where this compatibility is broken? That would be the strange thing for me ( not DPU 5.0 and DSI 2.5 as that was incorrect) Part of this confusion is because of catalog macro re-use again. This series is a good candidate and infact I think we should only do core_revision based check on DPU and DSI to avoid bringing the catalog mess into this. I have just a single request here: can we please have the same approach for both DSI and DP? I don't mind changing DP code if it makes it better. If you don't have better reasons, I like the idea of DSI/DP dictating whether wide bus should be used on the particular interface. It allows us to handle possible errata or corner cases there. Another option would be to make DPU tell DSI / DP whether the wide bus is enabled or not, but I'd say, this is slightly worse solution. Today, DP's widebus does not check if DPU supports that or not. DPU encoder queries the DP whether widebus is available and enables it. We can also do the same thing for DSI. So for intf_type of DSI, DPU encoder will query DSI if it supports widebus. Not if it supports wide bus. But the check is whether enabling wide bus is requested by the output driver (DSI/DP). Hi Dmitry, Can you explain what you mean by "requested by output driver"? FWIW, if the DSI version supports wide bus && if DSC is enabled, then wide bus will be enabled in DSI. Like for DP, let DSI select whether a wide bus should be enabled or not, then let DPU get this flag from DSI. Got it -- so basically have DSI do the version check *and* the DSC check in some `msm_dsi_is_widebus_enabled()` helper and have DPU use that helper to check if widebus is enabled. I think that should be fine. Thanks, Jessica Zhang Thanks, Jessica Zhang Then DSI will do its version checks and for DSC it will say yes. This way, we will never check for the DPU's core revision for DSI and purely rely of DP/DSI's hw revisions. Thats fine with me because that way we again just rely on the hw revision to enable the feature. But as a result I am still going to drop this patch which adds widebus to the catalog as a dpu cap which I always wanted to do anyway as we will just rely on the DSI and DP hw revisions. Yep. Tested this on SM8350 which actually has DSI 2.5, and it is also corrupted with this series so something else on this series might be broken. Missed this response. That seems strange. This series was tested on SM8350 HDK with a command mode panel. We will fix the DPU-DSI handshake and post a v2 but your issue needs investigation in parallel. So another bug to track that would be great. Is the bound in dsi_host wrong, or do DPU and DSI need to communicate when widebus will be enabled, based on DPU && DSI supporting it? I'd prefer to follow the second approach, as we did for DP. DPU asks the actual video output driver if widebus is to be enabled. I was afraid of this. This series was made on an assumption that the DPU version of widebus and DSI version of widebus would be compatible but looks like already SM8150 is an outlier.
[PATCH v3] drm/msm/a2xx: Call adreno_gpu_init() earlier
From: Fabio Estevam
The adreno_is_a20x() and adreno_is_a225() functions rely on the
GPU revision, but such information is retrieved inside adreno_gpu_init(),
which is called afterwards.
Fix this problem by caling adreno_gpu_init() earlier, so that
the GPU information revision is available when adreno_is_a20x()
and adreno_is_a225() run.
Tested on a imx53-qsb board.
Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx")
Signed-off-by: Fabio Estevam
---
Hi,
This error has been exposed by a recent commit in linux-next:
cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before being set")
, but the error has been present since the very first a2xx commit.
Changes since v2:
- Call adreno_gpu_init() earlier.
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index c67089a7ebc1..ad4570d60abf 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -540,6 +540,10 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+ ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
+ if (ret)
+ goto fail;
+
if (adreno_is_a20x(adreno_gpu))
adreno_gpu->registers = a200_registers;
else if (adreno_is_a225(adreno_gpu))
@@ -547,10 +551,6 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
else
adreno_gpu->registers = a220_registers;
- ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
- if (ret)
- goto fail;
-
if (!gpu->aspace) {
dev_err(dev->dev, "No memory protection without MMU\n");
if (!allow_vram_carveout) {
--
2.34.1
Re: [PATCH] drm/gma500: Replace kmap{,_atomic}() with page_address()
On martedì 20 giugno 2023 20:01:48 CEST Sumitra Sharma wrote:
> Remove unnecessary calls to kmap{,_atomic}() when acquiring
> pages using GFP_DMA32.
>
> The GFP_DMA32 uses the DMA32 zone to satisfy the allocation
> requests. Therefore, pages allocated with GFP_DMA32 cannot
> come from Highmem.
>
> Avoid using calls to kmap_local_page() / kunmap_local() and
> kmap() / kunmap() in the psb_mmu_alloc_pd function. Instead,
> utilize page_address().
>
> Remove the usage of kmap_atomic() / kunmap_atomic() in the
> psb_mmu_alloc_pt function. Use page_address() instead.
>
> Substitute kmap_atomic(pt->p) / kunmap_atomic(pt->v) calls
> in the psb_mmu_pt_alloc_map_lock() and psb_mmu_pt_unmap_unlock()
> functions with page_address(pt->p). This is possible as
> pt = psb_mmu_alloc_pt(pd) allocates a page using
> pt->p = alloc_page(GFP_DMA32).
Sumitra,
I'm sorry because this patch cannot acked with this commit message.
This commit message is missing two _really_ important information. Therefore,
it is not acked. Please check again what I write below and either add the
missing information or change the code accordingly...
You should assure everybody that the code between the old kmap_atomic() /
kunmap_atomic() doesn't depend either on implicit pagefault_disable() or
preempt_disable() calls or both.
Please read again the section of the Highmem's documentation regarding
kmap_atomic() at https://docs.kernel.org/mm/highmem.html
In particular take care to read and understand what "[] the code between calls
to kmap_atomic() and kunmap_atomic() may implicitly depend on the side effects
of atomic mappings, i.e. disabling page faults or preemption, or both. In that
case, explicit calls to pagefault_disable() or preempt_disable() or both must
be made in conjunction with the use of kmap_local_page().".
Please study carefully also the following patch from Zhao, suggested by Ira
and reviewed by Ira and I: "[PATCH v2 3/9] drm/i915: Use kmap_local_page() in
gem/i915_gem_shmem.c". It's not yet reached upstream so you need to find it in
lore.kernel.org at
https://lore.kernel.org/lkml/20230329073220.3982460-4-zhao1@linux.intel.com/
Please note that, in turn, that patch also contains a link to a patch from Ira
who too had to disable faults (https://lore.kernel.org/all/
20220813220034.806698-1-ira.we...@intel.com)
I haven't yet looked at your code. If any sections do depend on those implicit
disables, you should act accordingly and add one or both of the above-
mentioned calls, even in cases where you get rid of local mappings.
Instead if the sections don't depend on the mentioned side effects, you should
write something like what I wrote in "[PATCH] NFS: Convert kmap_atomic() to
kmap_local_folio()" that you can find at https://lore.kernel.org/lkml/
20230503172411.3356-1-fmdefrance...@gmail.com/ or, by by using "git show
4b71e2416ec4".
Thanks for working on this,
Fabio
>
> Suggested-by: Ira Weiny
> Signed-off-by: Sumitra Sharma
> ---
> drivers/gpu/drm/gma500/mmu.c | 17 +
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
> index a70b01ccdf70..59aa5661e56a 100644
> --- a/drivers/gpu/drm/gma500/mmu.c
> +++ b/drivers/gpu/drm/gma500/mmu.c
> @@ -184,20 +184,15 @@ struct psb_mmu_pd *psb_mmu_alloc_pd(struct
> psb_mmu_driver *driver, pd->invalid_pte = 0;
> }
>
> - v = kmap_local_page(pd->dummy_pt);
> + v = page_address(pd->dummy_pt);
> for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> v[i] = pd->invalid_pte;
>
> - kunmap_local(v);
> -
> - v = kmap_local_page(pd->p);
> + v = page_address(pd->p);
> for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> v[i] = pd->invalid_pde;
>
> - kunmap_local(v);
> -
> - clear_page(kmap(pd->dummy_page));
> - kunmap(pd->dummy_page);
> + clear_page(page_address(pd->dummy_page));
>
> pd->tables = vmalloc_user(sizeof(struct psb_mmu_pt *) * 1024);
> if (!pd->tables)
> @@ -279,7 +274,7 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
> psb_mmu_pd *pd)
>
> spin_lock(lock);
>
> - v = kmap_atomic(pt->p);
> + v = page_address(pt->p);
> clf = (uint8_t *) v;
> ptes = (uint32_t *) v;
> for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> @@ -293,7 +288,6 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
> psb_mmu_pd *pd) }
> mb();
> }
> - kunmap_atomic(v);
> spin_unlock(lock);
>
> pt->count = 0;
> @@ -339,7 +333,7 @@ static struct psb_mmu_pt
*psb_mmu_pt_alloc_map_lock(struct
> psb_mmu_pd *pd, atomic_set(>driver->needs_tlbflush, 1);
> }
> }
> - pt->v = kmap_atomic(pt->p);
> + pt->v = page_address(pt->p);
> return pt;
> }
>
> @@ -365,7 +359,6 @@ static void psb_mmu_pt_unmap_unlock(struct psb_mmu_pt
*pt)
> struct psb_mmu_pd *pd = pt->pd;
> uint32_t *v;
>
> -
Re: [Freedreno] [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On Wed, 21 Jun 2023 at 00:37, Jessica Zhang wrote: > > > > On 6/16/2023 5:37 PM, Dmitry Baryshkov wrote: > > On 17/06/2023 00:10, Abhinav Kumar wrote: > >> > >> > >> On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote: > >>> On 14/06/2023 23:39, Abhinav Kumar wrote: > > > On 6/14/2023 12:54 PM, Abhinav Kumar wrote: > > > > > > On 6/14/2023 12:35 PM, Abhinav Kumar wrote: > >> > >> > >> On 6/14/2023 5:23 AM, Marijn Suijten wrote: > >>> On 2023-06-14 15:01:59, Dmitry Baryshkov wrote: > On 14/06/2023 14:42, Marijn Suijten wrote: > > On 2023-06-13 18:57:11, Jessica Zhang wrote: > >> DPU 5.x+ supports a databus widen mode that allows more data > >> to be sent > >> per pclk. Enable this feature flag on all relevant chipsets. > >> > >> Signed-off-by: Jessica Zhang > >> --- > >>drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 ++- > >>drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ > >>2 files changed, 4 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >> index 36ba3f58dcdf..0be7bf0bfc41 100644 > >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >> @@ -103,7 +103,8 @@ > >>(BIT(DPU_INTF_INPUT_CTRL) | \ > >> BIT(DPU_INTF_TE) | \ > >> BIT(DPU_INTF_STATUS_SUPPORTED) | \ > >> - BIT(DPU_DATA_HCTL_EN)) > >> + BIT(DPU_DATA_HCTL_EN) | \ > >> + BIT(DPU_INTF_DATABUS_WIDEN)) > > > > This doesn't work. DPU 5.0.0 is SM8150, which has DSI 6G 2.3. > > In the > > last patch for DSI you state and enable widebus for DSI 6G 2.5+ > > only, > > meaning DPU and DSI are now desynced, and the output is completely > > corrupted. > >>> > > I looked at the internal docs and also this change. This change is > incorrect because this will try to enable widebus for DPU >= 5.0 and > DSI >= 2.5 > > That was not the intended right condition as thats not what the docs > say. > > We should enable for DPU >= 7.0 and DSI >= 2.5 > > Is there any combination where this compatibility is broken? That > would be the strange thing for me ( not DPU 5.0 and DSI 2.5 as that > was incorrect) > > Part of this confusion is because of catalog macro re-use again. > > This series is a good candidate and infact I think we should only do > core_revision based check on DPU and DSI to avoid bringing the > catalog mess into this. > >>> > >>> I have just a single request here: can we please have the same > >>> approach for both DSI and DP? I don't mind changing DP code if it > >>> makes it better. If you don't have better reasons, I like the idea of > >>> DSI/DP dictating whether wide bus should be used on the particular > >>> interface. It allows us to handle possible errata or corner cases > >>> there. Another option would be to make DPU tell DSI / DP whether the > >>> wide bus is enabled or not, but I'd say, this is slightly worse > >>> solution. > >>> > >> > >> Today, DP's widebus does not check if DPU supports that or not. > >> > >> DPU encoder queries the DP whether widebus is available and enables it. > >> > >> We can also do the same thing for DSI. > >> > >> So for intf_type of DSI, DPU encoder will query DSI if it supports > >> widebus. > > > > Not if it supports wide bus. But the check is whether enabling wide bus > > is requested by the output driver (DSI/DP). > > Hi Dmitry, > > Can you explain what you mean by "requested by output driver"? FWIW, if > the DSI version supports wide bus && if DSC is enabled, then wide bus > will be enabled in DSI. Like for DP, let DSI select whether a wide bus should be enabled or not, then let DPU get this flag from DSI. > > Thanks, > > Jessica Zhang > > > > >> > >> Then DSI will do its version checks and for DSC it will say yes. > >> > >> This way, we will never check for the DPU's core revision for DSI and > >> purely rely of DP/DSI's hw revisions. > >> > >> Thats fine with me because that way we again just rely on the hw > >> revision to enable the feature. > >> > >> But as a result I am still going to drop this patch which adds widebus > >> to the catalog as a dpu cap which I always wanted to do anyway as we > >> will just rely on the DSI and DP hw revisions. > > > > Yep. > > > >> > > >>> Tested this on SM8350 which actually has DSI 2.5, and it is also > >>> corrupted with this series so something else on this series might be > >>> broken. > >>> > > > > Missed this response. That seems strange. > > > > This series was tested on SM8350 HDK with a command mode panel. > > > > We
Re: [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders
On Wed, 21 Jun 2023 at 00:38, Jessica Zhang wrote: > > > > On 6/16/2023 5:35 PM, Dmitry Baryshkov wrote: > > On 17/06/2023 00:54, Marijn Suijten wrote: > >> On 2023-06-16 14:18:39, Abhinav Kumar wrote: > >>> > >>> > >>> On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote: > On 14/06/2023 04:57, Jessica Zhang wrote: > > Add a DPU INTF op to set the DATABUS_WIDEN register to enable the > > databus-widen mode datapath. > > > > Signed-off-by: Jessica Zhang > > --- > >drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ > >drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 > > > >drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 3 +++ > >3 files changed, 18 insertions(+) > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > > index b856c6286c85..124ba96bebda 100644 > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > > @@ -70,6 +70,9 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg( > >if (intf_cfg.dsc != 0 && > > phys_enc->hw_intf->ops.enable_compression) > > > > phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf); > > + > > +if (phys_enc->hw_intf->ops.enable_widebus) > > +phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf); > > No. Please provide a single function which takes necessary > configuration, including compression and wide_bus_enable. > > >>> > >>> There are two ways to look at this. Your point is coming from the > >>> perspective that its programming the same register but just a different > >>> bit. But that will also make it a bit confusing. > > > > My point is to have a high-level function that configures the INTF for > > the CMD mode. This way it can take a structure with necessary > > configuration bits. > > Hi Dmitry, > > After discussing this approach with Abhinav, we still have a few > questions about it: > > Currently, only 3 of the 32 bits for INTF_CONFIG2 are being used (the > rest are reserved with no plans of being programmed in the future). Does > this still justify the use of a struct to pass in the necessary > configuration? Yes. > > In addition, it seems that video mode does all its INTF_CONFIG2 > configuration separately in dpu_hw_intf_setup_timing_engine(). If we > have a generic set_intf_config2() op, it might be good to have it as > part of a larger cleanup where we have both video and command mode use > the generic op. What are your thoughts on this? No. If I get your idea right, this would mean moving INTF_CONFIG2 knowledge to the caller, which, I think, is a bad idea. > > Thanks, > > Jessica Zhang > > > > >>> > >>> So lets say the function is called intf_cfg2_xxx(..., bool widebus, bool > >>> data_compress) > >>> > >>> Now for the caller who wants to just enable widebus this will be > >>> > >>> intf_cfg2_xxx(., true, false) > >>> > >>> if we want to do both > >>> > >>> intf_cfg2_xxx(, true, true) > >>> > >>> the last one where we want to do just data_compress(highly unlikely and > >>> not recommended) > >>> > >>> intf_cfg2_xxx(, false, true) > >>> > >>> Now someone looking at the code will have to go and find out what each > >>> bool is. > >>> > >>> Whereas with separate ops, its kind of implicit. > >> > >> That's why you never pass bools as function argument (edge-case if it is > >> the only argument, and its meaning becomes clear from the function > >> name). Use enumerations anywhere else. > >> > >> - Marijn > >> > >>> > >>> For that reason, I dont think this patch is bad at all. > > > > -- > > With best wishes > > Dmitry > > -- With best wishes Dmitry
Re: [PATCH 1/3] drm/msm/a3xx: Pass the revision information
On Tue, 20 Jun 2023 at 21:14, Fabio Estevam wrote:
>
> On 20/06/2023 14:40, Dmitry Baryshkov wrote:
>
> > This looks like a boilerplate being added to all aYxx drivers (and
> > then these fields are also set in adreno_gpu_init()). Can we remove
> > duplication somehow?
>
> Sorry, I missed this comment prior to sending v2.
>
> Maybe a simpler fix for a2xx_gpu would be:
>
> --- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
> @@ -540,6 +540,10 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device
> *dev)
> gpu->perfcntrs = perfcntrs;
> gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
>
> + ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
> + if (ret)
> + goto fail;
> +
> if (adreno_is_a20x(adreno_gpu))
> adreno_gpu->registers = a200_registers;
> else if (adreno_is_a225(adreno_gpu))
> @@ -547,10 +551,6 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device
> *dev)
> else
> adreno_gpu->registers = a220_registers;
>
> - ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
> - if (ret)
> - goto fail;
> -
> if (!gpu->aspace) {
> dev_err(dev->dev, "No memory protection without MMU\n");
> if (!allow_vram_carveout) {
>
> What do you think?
>
> a3xx and a4xx call adreno_gpu_init() prior to adreno_is_xxx() so they
> don't have issues.
Yes, this seems like a perfect solution. Please send it with the
proper commit message. Also please add:
Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx")
--
With best wishes
Dmitry
Re: [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders
On 6/16/2023 5:35 PM, Dmitry Baryshkov wrote: On 17/06/2023 00:54, Marijn Suijten wrote: On 2023-06-16 14:18:39, Abhinav Kumar wrote: On 6/14/2023 12:56 AM, Dmitry Baryshkov wrote: On 14/06/2023 04:57, Jessica Zhang wrote: Add a DPU INTF op to set the DATABUS_WIDEN register to enable the databus-widen mode datapath. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 3 +++ 3 files changed, 18 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index b856c6286c85..124ba96bebda 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -70,6 +70,9 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg( if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression) phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf); + + if (phys_enc->hw_intf->ops.enable_widebus) + phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf); No. Please provide a single function which takes necessary configuration, including compression and wide_bus_enable. There are two ways to look at this. Your point is coming from the perspective that its programming the same register but just a different bit. But that will also make it a bit confusing. My point is to have a high-level function that configures the INTF for the CMD mode. This way it can take a structure with necessary configuration bits. Hi Dmitry, After discussing this approach with Abhinav, we still have a few questions about it: Currently, only 3 of the 32 bits for INTF_CONFIG2 are being used (the rest are reserved with no plans of being programmed in the future). Does this still justify the use of a struct to pass in the necessary configuration? In addition, it seems that video mode does all its INTF_CONFIG2 configuration separately in dpu_hw_intf_setup_timing_engine(). If we have a generic set_intf_config2() op, it might be good to have it as part of a larger cleanup where we have both video and command mode use the generic op. What are your thoughts on this? Thanks, Jessica Zhang So lets say the function is called intf_cfg2_xxx(..., bool widebus, bool data_compress) Now for the caller who wants to just enable widebus this will be intf_cfg2_xxx(., true, false) if we want to do both intf_cfg2_xxx(, true, true) the last one where we want to do just data_compress(highly unlikely and not recommended) intf_cfg2_xxx(, false, true) Now someone looking at the code will have to go and find out what each bool is. Whereas with separate ops, its kind of implicit. That's why you never pass bools as function argument (edge-case if it is the only argument, and its meaning becomes clear from the function name). Use enumerations anywhere else. - Marijn For that reason, I dont think this patch is bad at all. -- With best wishes Dmitry
Re: [Freedreno] [PATCH 1/3] drm/msm/dpu: Add DPU_INTF_DATABUS_WIDEN feature flag for DPU >= 5.0
On 6/16/2023 5:37 PM, Dmitry Baryshkov wrote: On 17/06/2023 00:10, Abhinav Kumar wrote: On 6/14/2023 1:43 PM, Dmitry Baryshkov wrote: On 14/06/2023 23:39, Abhinav Kumar wrote: On 6/14/2023 12:54 PM, Abhinav Kumar wrote: On 6/14/2023 12:35 PM, Abhinav Kumar wrote: On 6/14/2023 5:23 AM, Marijn Suijten wrote: On 2023-06-14 15:01:59, Dmitry Baryshkov wrote: On 14/06/2023 14:42, Marijn Suijten wrote: On 2023-06-13 18:57:11, Jessica Zhang wrote: DPU 5.x+ supports a databus widen mode that allows more data to be sent per pclk. Enable this feature flag on all relevant chipsets. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c index 36ba3f58dcdf..0be7bf0bfc41 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -103,7 +103,8 @@ (BIT(DPU_INTF_INPUT_CTRL) | \ BIT(DPU_INTF_TE) | \ BIT(DPU_INTF_STATUS_SUPPORTED) | \ - BIT(DPU_DATA_HCTL_EN)) + BIT(DPU_DATA_HCTL_EN) | \ + BIT(DPU_INTF_DATABUS_WIDEN)) This doesn't work. DPU 5.0.0 is SM8150, which has DSI 6G 2.3. In the last patch for DSI you state and enable widebus for DSI 6G 2.5+ only, meaning DPU and DSI are now desynced, and the output is completely corrupted. I looked at the internal docs and also this change. This change is incorrect because this will try to enable widebus for DPU >= 5.0 and DSI >= 2.5 That was not the intended right condition as thats not what the docs say. We should enable for DPU >= 7.0 and DSI >= 2.5 Is there any combination where this compatibility is broken? That would be the strange thing for me ( not DPU 5.0 and DSI 2.5 as that was incorrect) Part of this confusion is because of catalog macro re-use again. This series is a good candidate and infact I think we should only do core_revision based check on DPU and DSI to avoid bringing the catalog mess into this. I have just a single request here: can we please have the same approach for both DSI and DP? I don't mind changing DP code if it makes it better. If you don't have better reasons, I like the idea of DSI/DP dictating whether wide bus should be used on the particular interface. It allows us to handle possible errata or corner cases there. Another option would be to make DPU tell DSI / DP whether the wide bus is enabled or not, but I'd say, this is slightly worse solution. Today, DP's widebus does not check if DPU supports that or not. DPU encoder queries the DP whether widebus is available and enables it. We can also do the same thing for DSI. So for intf_type of DSI, DPU encoder will query DSI if it supports widebus. Not if it supports wide bus. But the check is whether enabling wide bus is requested by the output driver (DSI/DP). Hi Dmitry, Can you explain what you mean by "requested by output driver"? FWIW, if the DSI version supports wide bus && if DSC is enabled, then wide bus will be enabled in DSI. Thanks, Jessica Zhang Then DSI will do its version checks and for DSC it will say yes. This way, we will never check for the DPU's core revision for DSI and purely rely of DP/DSI's hw revisions. Thats fine with me because that way we again just rely on the hw revision to enable the feature. But as a result I am still going to drop this patch which adds widebus to the catalog as a dpu cap which I always wanted to do anyway as we will just rely on the DSI and DP hw revisions. Yep. Tested this on SM8350 which actually has DSI 2.5, and it is also corrupted with this series so something else on this series might be broken. Missed this response. That seems strange. This series was tested on SM8350 HDK with a command mode panel. We will fix the DPU-DSI handshake and post a v2 but your issue needs investigation in parallel. So another bug to track that would be great. Is the bound in dsi_host wrong, or do DPU and DSI need to communicate when widebus will be enabled, based on DPU && DSI supporting it? I'd prefer to follow the second approach, as we did for DP. DPU asks the actual video output driver if widebus is to be enabled. I was afraid of this. This series was made on an assumption that the DPU version of widebus and DSI version of widebus would be compatible but looks like already SM8150 is an outlier. Yes, I think we have to go with second approach. DPU queries DSI if it supports widebus and enables it. Thanks for your responses. We will post a v2. Doesn't it seem very strange that DPU 5.x+ comes with a widebus feature, but the DSI does not until two revisions later? Or is this available on every interface, but only for a different (probably DP) encoder block? Yes its strange. I have clarified this
Re: [Intel-xe] [RFC PATCH 1/1] drm/xe: Introduce function pointers for MMIO functions
On Sun, Jun 18, 2023 at 11:28:20AM +0300, Oded Gabbay wrote:
On Thu, Jun 15, 2023 at 7:34 PM Matt Roper wrote:
On Thu, Jun 15, 2023 at 04:04:18PM +0300, Oded Gabbay wrote:
> On Thu, Jun 15, 2023 at 3:01 AM Matt Roper wrote:
> >
> > On Mon, Jun 12, 2023 at 06:31:57PM +0200, Francois Dugast wrote:
> > > On Thu, Jun 08, 2023 at 10:35:29AM -0700, Lucas De Marchi wrote:
> > > > On Fri, Jun 02, 2023 at 02:25:01PM +, Francois Dugast wrote:
> > > > > A local structure of function pointers is used as a minimal hardware
> > > > > abstraction layer to prepare for platform independent MMIO calls.
> > > > >
> > > > > Cc: Oded Gabbay
> > > > > Cc: Ofir Bitton
> > > > > Cc: Ohad Sharabi
> > > > > Signed-off-by: Francois Dugast
> > > > > ---
> > > > > drivers/gpu/drm/xe/xe_device_types.h | 3 ++
> > > > > drivers/gpu/drm/xe/xe_mmio.c | 81
> > > > > drivers/gpu/drm/xe/xe_mmio.h | 35 ++--
> > > > > 3 files changed, 99 insertions(+), 20 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
> > > > > index 17b6b1cc5adb..3f8fd0d8129b 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_device_types.h
> > > > > +++ b/drivers/gpu/drm/xe/xe_device_types.h
> > > > > @@ -378,6 +378,9 @@ struct xe_device {
> > > > > /** @d3cold_allowed: Indicates if d3cold is a valid device state */
> > > > > bool d3cold_allowed;
> > > > >
> > > > > + /** @mmio_funcs: function pointers for MMIO related functions */
> > > > > + const struct xe_mmio_funcs *mmio_funcs;
> > > > > +
> > > > > /* private: */
> > > > >
> > > > > #if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
> > > > > diff --git a/drivers/gpu/drm/xe/xe_mmio.c
b/drivers/gpu/drm/xe/xe_mmio.c
> > > > > index 475b14fe4356..f3d08676a77a 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_mmio.c
> > > > > +++ b/drivers/gpu/drm/xe/xe_mmio.c
> > > > > @@ -25,6 +25,62 @@
> > > > >
> > > > > #define BAR_SIZE_SHIFT 20
> > > > >
> > > > > +static void xe_mmio_write32_device(struct xe_gt *gt,
> > > > > +struct xe_reg reg, u32 val);
> > > > > +static u32 xe_mmio_read32_device(struct xe_gt *gt, struct xe_reg
reg);
> > > > > +static void xe_mmio_write64_device(struct xe_gt *gt,
> > > > > +struct xe_reg reg, u64 val);
> > > > > +static u64 xe_mmio_read64_device(struct xe_gt *gt, struct xe_reg
reg);
> > > > > +
> > > > > +static const struct xe_mmio_funcs xe_mmio_funcs_device = {
> > > > > + .write32 = xe_mmio_write32_device,
> > > > > + .read32 = xe_mmio_read32_device,
> > > > > + .write64 = xe_mmio_write64_device,
> > > > > + .read64 = xe_mmio_read64_device,
> > > > > +};
> > > > > +
> > > > > +static inline void xe_mmio_write32_device(struct xe_gt *gt,
> > > > > +struct xe_reg reg, u32 val)
> > > > > +{
> > > > > + struct xe_tile *tile = gt_to_tile(gt);
> > > > > +
> > > > > + if (reg.addr < gt->mmio.adj_limit)
> > > > > + reg.addr += gt->mmio.adj_offset;
> > > > > +
> > > > > + writel(val, tile->mmio.regs + reg.addr);
> > > > > +}
> > > > > +
> > > > > +static inline u32 xe_mmio_read32_device(struct xe_gt *gt, struct
xe_reg reg)
> > > > > +{
> > > > > + struct xe_tile *tile = gt_to_tile(gt);
> > > > > +
> > > > > + if (reg.addr < gt->mmio.adj_limit)
> > > > > + reg.addr += gt->mmio.adj_offset;
> > > > > +
> > > > > + return readl(tile->mmio.regs + reg.addr);
> > > > > +}
> > > > > +
> > > > > +static inline void xe_mmio_write64_device(struct xe_gt *gt,
> > > > > +struct xe_reg reg, u64 val)
> > > > > +{
> > > > > + struct xe_tile *tile = gt_to_tile(gt);
> > > > > +
> > > > > + if (reg.addr < gt->mmio.adj_limit)
> > > > > + reg.addr += gt->mmio.adj_offset;
> > > > > +
> > > > > + writeq(val, tile->mmio.regs + reg.addr);
> > > > > +}
> > > > > +
> > > > > +static inline u64 xe_mmio_read64_device(struct xe_gt *gt, struct
xe_reg reg)
> > > > > +{
> > > > > + struct xe_tile *tile = gt_to_tile(gt);
> > > > > +
> > > > > + if (reg.addr < gt->mmio.adj_limit)
> > > > > + reg.addr += gt->mmio.adj_offset;
> > > > > +
> > > > > + return readq(tile->mmio.regs + reg.addr);
> > > > > +}
> > > > > +
> > > > > static int xe_set_dma_info(struct xe_device *xe)
> > > > > {
> > > > > unsigned int mask_size = xe->info.dma_mask_size;
> > > > > @@ -377,6 +433,29 @@ static void mmio_fini(struct drm_device *drm,
void *arg)
> > > > > iounmap(xe->mem.vram.mapping);
> > > > > }
> > > > >
> > > > > +static void xe_mmio_set_funcs(struct xe_device *xe)
> > > > > +{
> > > > > + /* For now all platforms use the set of MMIO functions for a
> > > > > + * physical device.
> > > > > + */
> > > >
> > > >
> > > > what is "device" in this context? that seems confusing as we always ever
> > > > just support reading/writing to a real device (physical here may also
> > > > add to the confusion when thinking about SR-IOV and VFs).
> > > > We shouldn't add abstractions
Re: [PATCH v2] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2
Also since I forgot, so patchwork picks this up:
Reviewed-by: Lyude Paul
On Tue, 2023-06-20 at 15:50 -0400, Lyude Paul wrote:
> Eek - this might have been a situation where everyone involved assumed someone
> else would push it, whoops. I'll make sure this is pushed upstream :).
>
> FWIW: You could definitely send an MR to the fedora kernel's gitlab to get
> this included earlier. If you don't get to it before me I'll try to do that
> today
>
> On Tue, 2023-06-20 at 07:18 -0400, Jeff Layton wrote:
> > I've noticed that this patch is not included in linux-next currently.
> >
> > Can I get some confirmation that this is going to be included in v6.5?
> > Currently, I've been having to rebuild Fedora kernels to avoid this
> > panic, and I'd like to know there is a light at the end of that tunnel.
> >
> > Thanks,
> > Jeff
> >
> > On Wed, 2023-04-19 at 16:54 -0400, Lyude Paul wrote:
> > > Reviewed-by: Lyude Paul
> > >
> > > Thanks!
> > >
> > > On Wed, 2023-04-19 at 07:24 -0400, Jeff Layton wrote:
> > > > I've been experiencing some intermittent crashes down in the display
> > > > driver code. The symptoms are ususally a line like this in dmesg:
> > > >
> > > > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > > > 6d3a3885: -5
> > > >
> > > > ...followed by an Oops due to a NULL pointer dereference.
> > > >
> > > > Switch to using mgr->dev instead of state->dev since "state" can be
> > > > NULL in some cases.
> > > >
> > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > > > Suggested-by: Jani Nikula
> > > > Signed-off-by: Jeff Layton
> > > > ---
> > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > I've been running this patch for a couple of days, but the problem
> > > > hasn't occurred again as of yet. It seems sane though as long as we can
> > > > assume that mgr->dev will be valid even when "state" is a NULL pointer.
> > > >
> > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > index 38dab76ae69e..e2e21ce79510 100644
> > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > @@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct
> > > > drm_dp_mst_topology_mgr *mgr,
> > > >
> > > > /* Skip failed payloads */
> > > > if (payload->vc_start_slot == -1) {
> > > > - drm_dbg_kms(state->dev, "Part 1 of payload creation for
> > > > %s failed, skipping part 2\n",
> > > > + drm_dbg_kms(mgr->dev, "Part 1 of payload creation for
> > > > %s failed, skipping part 2\n",
> > > > payload->port->connector->name);
> > > > return -EIO;
> > > > }
> > >
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v2] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2
Eek - this might have been a situation where everyone involved assumed someone
else would push it, whoops. I'll make sure this is pushed upstream :).
FWIW: You could definitely send an MR to the fedora kernel's gitlab to get
this included earlier. If you don't get to it before me I'll try to do that
today
On Tue, 2023-06-20 at 07:18 -0400, Jeff Layton wrote:
> I've noticed that this patch is not included in linux-next currently.
>
> Can I get some confirmation that this is going to be included in v6.5?
> Currently, I've been having to rebuild Fedora kernels to avoid this
> panic, and I'd like to know there is a light at the end of that tunnel.
>
> Thanks,
> Jeff
>
> On Wed, 2023-04-19 at 16:54 -0400, Lyude Paul wrote:
> > Reviewed-by: Lyude Paul
> >
> > Thanks!
> >
> > On Wed, 2023-04-19 at 07:24 -0400, Jeff Layton wrote:
> > > I've been experiencing some intermittent crashes down in the display
> > > driver code. The symptoms are ususally a line like this in dmesg:
> > >
> > > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > > 6d3a3885: -5
> > >
> > > ...followed by an Oops due to a NULL pointer dereference.
> > >
> > > Switch to using mgr->dev instead of state->dev since "state" can be
> > > NULL in some cases.
> > >
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > > Suggested-by: Jani Nikula
> > > Signed-off-by: Jeff Layton
> > > ---
> > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > I've been running this patch for a couple of days, but the problem
> > > hasn't occurred again as of yet. It seems sane though as long as we can
> > > assume that mgr->dev will be valid even when "state" is a NULL pointer.
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index 38dab76ae69e..e2e21ce79510 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > >
> > > /* Skip failed payloads */
> > > if (payload->vc_start_slot == -1) {
> > > - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> > > failed, skipping part 2\n",
> > > + drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s
> > > failed, skipping part 2\n",
> > > payload->port->connector->name);
> > > return -EIO;
> > > }
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/display/dp_mst: Fix missing check for return value of drm_atomic_get_mst_payload_state()
Hm, I suppose it's not -impossible- for this to return NULL, but if it does return NULL that absolutely means something broke well before this point in the code. More comments below: On Wed, 2023-06-14 at 09:09 -0700, Chenyuan Mi wrote: > The drm_atomic_get_mst_payload_state() function may > return NULL, which may cause null pointer deference, > and most other callsites of drm_atomic_get_mst_payload_state() > do Null check. Add Null check for return value of > drm_atomic_get_mst_payload_state(). > > Found by our static analysis tool. > > Signed-off-by: Chenyuan Mi > --- > drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c > b/drivers/gpu/drm/display/drm_dp_mst_topology.c > index 38dab76ae69e..27f4bcf409ea 100644 > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c > @@ -4434,6 +4434,8 @@ void drm_dp_mst_atomic_wait_for_dependencies(struct > drm_atomic_state *state) > > new_payload = > drm_atomic_get_mst_payload_state(new_mst_state, > > old_payload->port); > + if (!new_payload) > + continue; Could you change this check to: if (drm_WARN_ON(state->dev, !new_payload)) > new_payload->vc_start_slot = old_payload->vc_start_slot; > } > } -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH] drm/bridge_connector: use drm_kms_helper_connector_hotplug_event()
Hi Simon, On Tue, Jun 20, 2023 at 07:01:59PM +, Simon Ser wrote: > On Tuesday, June 20th, 2023 at 20:58, Sam Ravnborg wrote: > > > On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote: > > > > > This adds more information to the hotplug uevent and lets user-space > > > know that it's about a particular connector only. > > > > Will this change have impact on user space? > > They will start to see CONNECTOR=n where they did not occur before. > > Asking as I have not really worked with the hotplug stuff. > > Yes. CONNECTOR is an optional udev event property indicating that only > the specified connector has changed. User-space unaware of this > property will just ignore it. User-space aware of this property will > only refresh information about the connector instead of the whole > device. > > A few months back, we've converted calls to > drm_kms_helper_connector_hotplug_event() in amdgpu and the DRM DP > helper. Thanks for the explanation - all is good. Sam
Re: [PATCH] drm/bridge_connector: use drm_kms_helper_connector_hotplug_event()
On Tuesday, June 20th, 2023 at 20:58, Sam Ravnborg wrote: > On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote: > > > This adds more information to the hotplug uevent and lets user-space > > know that it's about a particular connector only. > > Will this change have impact on user space? > They will start to see CONNECTOR=n where they did not occur before. > Asking as I have not really worked with the hotplug stuff. Yes. CONNECTOR is an optional udev event property indicating that only the specified connector has changed. User-space unaware of this property will just ignore it. User-space aware of this property will only refresh information about the connector instead of the whole device. A few months back, we've converted calls to drm_kms_helper_connector_hotplug_event() in amdgpu and the DRM DP helper.
Re: [PATCH] drm/bridge_connector: use drm_kms_helper_connector_hotplug_event()
Hi Simon, On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote: > This adds more information to the hotplug uevent and lets user-space > know that it's about a particular connector only. Will this change have impact on user space? They will start to see CONNECTOR=n where they did not occur before. Asking as I have not really worked with the hotplug stuff. The code change looks fine - no comment there. And if there are no user space worries then: Reviewed-by: Sam Ravnborg Sam > > Signed-off-by: Simon Ser > Cc: Dmitry Baryshkov > Cc: Paul Cercueil > Cc: Laurent Pinchart > Cc: Sam Ravnborg > --- > drivers/gpu/drm/drm_bridge_connector.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c > b/drivers/gpu/drm/drm_bridge_connector.c > index 19ae4a177ac3..fc6f16e14f36 100644 > --- a/drivers/gpu/drm/drm_bridge_connector.c > +++ b/drivers/gpu/drm/drm_bridge_connector.c > @@ -125,7 +125,7 @@ static void drm_bridge_connector_hpd_cb(void *cb_data, > > drm_bridge_connector_hpd_notify(connector, status); > > - drm_kms_helper_hotplug_event(dev); > + drm_kms_helper_connector_hotplug_event(connector); > } > > static void drm_bridge_connector_enable_hpd(struct drm_connector *connector) > -- > 2.41.0 >
RE: [PATCH] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics
[Public]
You've got an A-b from Evan already on this. It looks fine to me too.
Reviewed-by: Mario Limonciello
> -Original Message-
> From: Yang, WenYou
> Sent: Sunday, June 11, 2023 12:53 AM
> To: Yang, WenYou ; Deucher, Alexander
> ; Limonciello, Mario
> ; Koenig, Christian
> ; Pan, Xinhui ; Quan,
> Evan
> Cc: Yuan, Perry ; Liang, Richard qi
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: RE: [PATCH] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to
> acquire gpu_metrics
>
> [AMD Official Use Only - General]
>
> Any comments?
>
> > -Original Message-
> > From: Wenyou Yang
> > Sent: Thursday, June 1, 2023 9:38 AM
> > To: Deucher, Alexander ; Limonciello, Mario
> > ; Koenig, Christian
> ;
> > Pan, Xinhui ; Quan, Evan
> > Cc: Yuan, Perry ; Liang, Richard qi
> > ; amd-...@lists.freedesktop.org; dri-
> > de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Yang, WenYou
> >
> > Subject: [PATCH] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to
> acquire
> > gpu_metrics
> >
> > To acquire the voltage and current info from gpu_metrics interface, but
> > gpu_metrics_v2_3 doesn't contain them, and to be backward compatible,
> add
> > new gpu_metrics_v2_4 structure.
> >
> > Acked-by: Evan Quan
> > Signed-off-by: Wenyou Yang
> > ---
> > .../gpu/drm/amd/include/kgd_pp_interface.h| 69 +++
> > .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 109
> -
> > -
> > drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c| 3 +
> > 3 files changed, 172 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > index 9f542f6e19ed..0f37dafafcf9 100644
> > --- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > +++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > @@ -892,4 +892,73 @@ struct gpu_metrics_v2_3 {
> > uint16_taverage_temperature_core[8]; //
> > average CPU core temperature on APUs
> > uint16_taverage_temperature_l3[2];
> > };
> > +
> > +struct gpu_metrics_v2_4 {
> > + struct metrics_table_header common_header;
> > +
> > + /* Temperature */
> > + uint16_ttemperature_gfx;
> > + uint16_ttemperature_soc;
> > + uint16_ttemperature_core[8];
> > + uint16_ttemperature_l3[2];
> > +
> > + /* Utilization */
> > + uint16_taverage_gfx_activity;
> > + uint16_taverage_mm_activity;
> > +
> > + /* Driver attached timestamp (in ns) */
> > + uint64_tsystem_clock_counter;
> > +
> > + /* Power/Energy */
> > + uint16_taverage_socket_power;
> > + uint16_taverage_cpu_power;
> > + uint16_taverage_soc_power;
> > + uint16_taverage_gfx_power;
> > + uint16_taverage_core_power[8];
> > +
> > + /* Average clocks */
> > + uint16_taverage_gfxclk_frequency;
> > + uint16_taverage_socclk_frequency;
> > + uint16_taverage_uclk_frequency;
> > + uint16_taverage_fclk_frequency;
> > + uint16_taverage_vclk_frequency;
> > + uint16_taverage_dclk_frequency;
> > +
> > + /* Current clocks */
> > + uint16_tcurrent_gfxclk;
> > + uint16_tcurrent_socclk;
> > + uint16_tcurrent_uclk;
> > + uint16_tcurrent_fclk;
> > + uint16_tcurrent_vclk;
> > + uint16_tcurrent_dclk;
> > + uint16_tcurrent_coreclk[8];
> > + uint16_tcurrent_l3clk[2];
> > +
> > + /* Throttle status (ASIC dependent) */
> > + uint32_tthrottle_status;
> > +
> > + /* Fans */
> > + uint16_tfan_pwm;
> > +
> > + uint16_tpadding[3];
> > +
> > + /* Throttle status (ASIC independent) */
> > + uint64_tindep_throttle_status;
> > +
> > + /* Average Temperature */
> > + uint16_taverage_temperature_gfx;
> > + uint16_taverage_temperature_soc;
> > + uint16_taverage_temperature_core[8];
> > + uint16_taverage_temperature_l3[2];
> > +
> > + /* Power/Voltage */
> > + uint16_taverage_cpu_voltage;
> > + uint16_taverage_soc_voltage;
> > + uint16_taverage_gfx_voltage;
> > +
> > + /*
[PATCH] accel: make accel_class a static const structure
From: Ivan Orlov
Now that the driver core allows for struct class to be in read-only
memory, move the accel_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Oded Gabbay
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Ivan Orlov
Signed-off-by: Greg Kroah-Hartman
---
drivers/accel/drm_accel.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
index 4a9baf02439e..2dc187e1ee41 100644
--- a/drivers/accel/drm_accel.c
+++ b/drivers/accel/drm_accel.c
@@ -21,7 +21,6 @@ static DEFINE_SPINLOCK(accel_minor_lock);
static struct idr accel_minors_idr;
static struct dentry *accel_debugfs_root;
-static struct class *accel_class;
static struct device_type accel_sysfs_device_minor = {
.name = "accel_minor"
@@ -32,23 +31,19 @@ static char *accel_devnode(const struct device *dev,
umode_t *mode)
return kasprintf(GFP_KERNEL, "accel/%s", dev_name(dev));
}
+static const struct class accel_class = {
+ .name = "accel",
+ .devnode = accel_devnode,
+};
+
static int accel_sysfs_init(void)
{
- accel_class = class_create("accel");
- if (IS_ERR(accel_class))
- return PTR_ERR(accel_class);
-
- accel_class->devnode = accel_devnode;
-
- return 0;
+ return class_register(_class);
}
static void accel_sysfs_destroy(void)
{
- if (IS_ERR_OR_NULL(accel_class))
- return;
- class_destroy(accel_class);
- accel_class = NULL;
+ class_unregister(_class);
}
static int accel_name_info(struct seq_file *m, void *data)
@@ -116,7 +111,7 @@ void accel_debugfs_init(struct drm_minor *minor, int
minor_id)
void accel_set_device_instance_params(struct device *kdev, int index)
{
kdev->devt = MKDEV(ACCEL_MAJOR, index);
- kdev->class = accel_class;
+ kdev->class = _class;
kdev->type = _sysfs_device_minor;
}
--
2.41.0
Re: [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
On Tue, 20 Jun 2023, Andy Shevchenko wrote: > So, what does prevent you from using GENMASK_ULL()? > > Another point, you may teach GENMASK() to issue a warning if hi and/or lo > bigger than BITS_PER_LONG. What good does that do if you want the warning for a fixed size different from unsigned long or long long? Worse, sizeof(long) depends on arch, while the GENMASK you want depends on the use case. > I still don't see the usefulness of that churn. This thread is turning into a prime example of why drivers and subsystems reinvent their own wheels instead of trying to get generally useful stuff merged in kernel headers. :p BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 1/3] drm/msm/a3xx: Pass the revision information
On 20/06/2023 14:40, Dmitry Baryshkov wrote:
This looks like a boilerplate being added to all aYxx drivers (and
then these fields are also set in adreno_gpu_init()). Can we remove
duplication somehow?
Sorry, I missed this comment prior to sending v2.
Maybe a simpler fix for a2xx_gpu would be:
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -540,6 +540,10 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device
*dev)
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+ ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
+ if (ret)
+ goto fail;
+
if (adreno_is_a20x(adreno_gpu))
adreno_gpu->registers = a200_registers;
else if (adreno_is_a225(adreno_gpu))
@@ -547,10 +551,6 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device
*dev)
else
adreno_gpu->registers = a220_registers;
- ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
- if (ret)
- goto fail;
-
if (!gpu->aspace) {
dev_err(dev->dev, "No memory protection without MMU\n");
if (!allow_vram_carveout) {
What do you think?
a3xx and a4xx call adreno_gpu_init() prior to adreno_is_xxx() so they
don't have issues.
Re: [PATCH] drm/bridge_connector: use drm_kms_helper_connector_hotplug_event()
Hi Simon, Thank you for the patch. On Tue, Jun 20, 2023 at 05:55:09PM +, Simon Ser wrote: > This adds more information to the hotplug uevent and lets user-space > know that it's about a particular connector only. > > Signed-off-by: Simon Ser > Cc: Dmitry Baryshkov > Cc: Paul Cercueil > Cc: Laurent Pinchart > Cc: Sam Ravnborg Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_bridge_connector.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c > b/drivers/gpu/drm/drm_bridge_connector.c > index 19ae4a177ac3..fc6f16e14f36 100644 > --- a/drivers/gpu/drm/drm_bridge_connector.c > +++ b/drivers/gpu/drm/drm_bridge_connector.c > @@ -125,7 +125,7 @@ static void drm_bridge_connector_hpd_cb(void *cb_data, > > drm_bridge_connector_hpd_notify(connector, status); > > - drm_kms_helper_hotplug_event(dev); > + drm_kms_helper_connector_hotplug_event(connector); > } > > static void drm_bridge_connector_enable_hpd(struct drm_connector *connector) -- Regards, Laurent Pinchart
Re: [PATCH v2] drm/i915: Replace kmap() with kmap_local_page()
On Tue, Jun 20, 2023 at 06:23:38AM -0700, Ira Weiny wrote: > Sumitra Sharma wrote: > > On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote: > > > Sumitra Sharma wrote: > > > > kmap() has been deprecated in favor of the kmap_local_page() > > > > due to high cost, restricted mapping space, the overhead of a > > > > global lock for synchronization, and making the process sleep > > > > in the absence of free slots. > > > > > > > > kmap_local_page() is faster than kmap() and offers thread-local > > > > and CPU-local mappings, take pagefaults in a local kmap region > > > > and preserves preemption by saving the mappings of outgoing tasks > > > > and restoring those of the incoming one during a context switch. > > > > > > > > The mapping is kept thread local in the function > > > > “i915_vma_coredump_create” in i915_gpu_error.c > > > > > > > > Therefore, replace kmap() with kmap_local_page(). > > > > > > > > Suggested-by: Ira Weiny > > > > > > > > > > NIT: No need for the line break between Suggested-by and your signed off > > > line. > > > > > > > Hi Ira, > > > > What does NIT stand for? > > Shorthand for 'nitpicking'. > > "giving too much attention to details that are not important, especially > as a way of criticizing: " > > - https://dictionary.cambridge.org/dictionary/english/nitpicking > > Via email this is a way for authors of an email to indicate something is > technically wrong but while nicely acknowledging that it is not very > significant and could be seen as overly critical. > > For this particular comment I'm showing something to pay attention to next > time but that was not a big deal this time around. > Hi Ira, Thank for your explanation on NIT. > > > > Thank you. I will take care about the line breaks. > > > > > > Signed-off-by: Sumitra Sharma > > > > --- > > > > > > > > Changes in v2: > > > > - Replace kmap() with kmap_local_page(). > > > > > > Generally it is customary to attribute a change like this to those who > > > suggested it in a V1 review. > > > > > > For example: > > > > > > - Tvrtko/Thomas: Use kmap_local_page() instead of page_address() > > > > > > Also I don't see Thomas on the new email list. Since he took the time to > > > review V1 he might want to check this version out. I've added him to the > > > 'To:' list. > > > > > > Also a link to V1 is nice. B4 formats it like this: > > > > > > - Link to v1: > > > https://lore.kernel.org/all/20230614123556.ga381...@sumitra.com/ > > > > > > All that said the code looks good to me. So with the above changes. > > > > > > Reviewed-by: Ira Weiny > > > > > > > I have noted down the points mentioned above. Thank you again. > > > > I am not supposed to create another version of this patch for > > adding the above mentions, as you and Thomas both gave this patch > > a reviewed-by tag. Right? > > > > Based on this response[*] from Tvrtko I think this version can move > through without a v3. Okay! Thanks & regards Sumitra > > Thanks! > Ira > > [*] > https://lore.kernel.org/all/bcb0a1d2-cd4d-a56f-1ee6-7ccfdd2f7...@linux.intel.com/ > > > Thanks all! I'll just re-send the patch for our CI, since it didn't get > picked up automatically (stuck in moderation perhaps), with all r-b tags > added and extra line space removed and merge it if results will be green. > > Regards, > > Tvrtko > > > > > > > Thanks & regards > > Sumitra > > > > PS: I am new to the open source vocabulary terms. > > > > > > - Change commit subject and message. > > > > > > > > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > > > > b/drivers/gpu/drm/i915/i915_gpu_error.c > > > > index f020c0086fbc..bc41500eedf5 100644 > > > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > > > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > > > > @@ -1164,9 +1164,9 @@ i915_vma_coredump_create(const struct intel_gt > > > > *gt, > > > > > > > > drm_clflush_pages(, 1); > > > > > > > > - s = kmap(page); > > > > + s = kmap_local_page(page); > > > > ret = compress_page(compress, s, dst, false); > > > > - kunmap(page); > > > > + kunmap_local(s); > > > > > > > > drm_clflush_pages(, 1); > > > > > > > > -- > > > > 2.25.1 > > > > > > > > > > > >
Re: [PATCH v1] drm/i915/gsc: Fix intel_gsc_uc_fw_proxy_init_done with directed wakerefs
On 6/16/2023 8:54 AM, Ceraolo Spurio, Daniele wrote:
On 6/15/2023 2:19 PM, Alan Previn wrote:
intel_gsc_uc_fw_proxy_init_done is used by a few code paths
and usages. However, certain paths need a wakeref while others
can't take a wakeref such as from the runtime_pm_resume callstack.
Add a param into this helper to allow callers to direct whether
to take the wakeref or not. This resolves the following bug:
INFO: task sh:2607 blocked for more than 61 seconds.
Not tainted 6.3.0-pxp-gsc-final-jun14+ #297
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
task:sh state:D stack:13016 pid:2607 ppid:2602
flags:0x4000
Call Trace:
__schedule+0x47b/0xe10
schedule+0x58/0xd0
rpm_resume+0x1cc/0x800
? __pfx_autoremove_wake_function+0x10/0x10
__pm_runtime_resume+0x42/0x80
__intel_runtime_pm_get+0x19/0x80 [i915]
gsc_uc_get_fw_status+0x10/0x50 [i915]
intel_gsc_uc_fw_init_done+0x9/0x20 [i915]
intel_gsc_uc_load_start+0x5b/0x130 [i915]
__uc_resume+0xa5/0x280 [i915]
intel_runtime_resume+0xd4/0x250 [i915]
? __pfx_pci_pm_runtime_resume+0x10/0x10
__rpm_callback+0x3c/0x160
Fixes: 8c33c3755b75 ("drm/i915/gsc: take a wakeref for the
proxy-init-completion check")
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
I'm going to send a trybot of this patch with the FW definition patch,
just to make sure there aren't any other issues that kick in once the
FW is defined and the code starts being executed, and merge if the
results are ok.
Trybot came back green
(https://patchwork.freedesktop.org/series/119471/), so pushed.
Daniele
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 17 +++--
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 856de9af1e3a..ab1a456f833d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -22,27 +22,32 @@ static bool gsc_is_in_reset(struct intel_uncore
*uncore)
HECI1_FWSTS1_CURRENT_STATE_RESET;
}
-static u32 gsc_uc_get_fw_status(struct intel_uncore *uncore)
+static u32 gsc_uc_get_fw_status(struct intel_uncore *uncore, bool
needs_wakeref)
{
intel_wakeref_t wakeref;
u32 fw_status = 0;
- with_intel_runtime_pm(uncore->rpm, wakeref)
- fw_status = intel_uncore_read(uncore,
HECI_FWSTS(MTL_GSC_HECI1_BASE, 1));
+ if (needs_wakeref)
+ wakeref = intel_runtime_pm_get(uncore->rpm);
+ fw_status = intel_uncore_read(uncore,
HECI_FWSTS(MTL_GSC_HECI1_BASE, 1));
+
+ if (needs_wakeref)
+ intel_runtime_pm_put(uncore->rpm, wakeref);
return fw_status;
}
-bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc)
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc, bool
needs_wakeref)
{
return REG_FIELD_GET(HECI1_FWSTS1_CURRENT_STATE,
- gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore)) ==
+ gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore,
+ needs_wakeref)) ==
HECI1_FWSTS1_PROXY_STATE_NORMAL;
}
bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
{
- return gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore) &
+ return gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore, false) &
HECI1_FWSTS1_INIT_COMPLETE;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index 8d7b9e4f1ffc..ad2167ce9137 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -15,6 +15,6 @@ struct intel_uncore;
int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, const
void *data, size_t size);
int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
-bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc);
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc, bool
needs_wakeref);
#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 85d90f0a15e3..75a3a0790ef3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -72,7 +72,7 @@ static void gsc_work(struct work_struct *work)
* complete the request handling cleanly, so we need to
check the
* status register to check if the proxy init was
actually successful
*/
- if (intel_gsc_uc_fw_proxy_init_done(gsc)) {
+ if (intel_gsc_uc_fw_proxy_init_done(gsc, false)) {
drm_dbg(>i915->drm, "GSC Proxy initialized\n");
Re: [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
On Tue, Jun 20, 2023 at 08:41:10PM +0300, Andy Shevchenko wrote:
On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > On Thu, 15 Jun 2023, Andy Shevchenko
wrote:
> > > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> > >> On Fri, 12 May 2023, Andy Shevchenko
wrote:
> > >> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> > >> >> On Fri, 12 May 2023, Andy Shevchenko
wrote:
> > >> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> > >> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create
> > >> >> >> masks for fixed-width types and also the corresponding BIT_U32(),
> > >> >> >> BIT_U16() and BIT_U8().
> > >> >> > Why?
> > >> >>
> > >> >> The main reason is that GENMASK() and BIT() size varies for 32/64 bit
> > >> >> builds.
> > >> >
> > >> > When needed GENMASK_ULL() can be used (with respective castings
perhaps)
> > >> > and BIT_ULL(), no?
> > >>
> > >> How does that help with making them the same 32-bit size on both 32 and
> > >> 64 bit builds?
> > >
> > > u32 x = GENMASK();
> > > u64 y = GENMASK_ULL();
> > >
> > > No? Then use in your code either x or y. Note that I assume that the
parameters
> > > to GENMASK*() are built-time constants. Is it the case for you?
> >
> > What's wrong with wanting to define macros with specific size, depending
> > on e.g. hardware registers instead of build size?
>
> Nothing, but I think the problem is smaller than it's presented.
not sure about big/small problem you are talking about. It's a problem
for when the *device* register is a 32b fixed width, which is
independent from the CPU you are running on. We also have registers that
are u16 and u64. Having fixed-width GENMASK and BIT helps avoiding
mistakes like below. Just to use one example, the diff below builds
fine on my 64b machine, yet it's obviously wrong:
$ git diff diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 0b414eae1683..692a0ad9a768 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -261,8 +261,8 @@ static u32 rw_with_mcr_steering_fw(struct intel_gt
*gt,
* No need to save old steering reg value.
*/
intel_uncore_write_fw(uncore, MTL_MCR_SELECTOR,
- REG_FIELD_PREP(MTL_MCR_GROUPID,
group) |
-
REG_FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
+ FIELD_PREP(MTL_MCR_GROUPID,
group) |
+ FIELD_PREP(MTL_MCR_INSTANCEID,
instance) |
(rw_flag == FW_REG_READ ?
GEN11_MCR_MULTICAST : 0));
} else if (GRAPHICS_VER(uncore->i915) >= 11) {
mcr_mask = GEN11_MCR_SLICE_MASK |
GEN11_MCR_SUBSLICE_MASK;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 718cb2c80f79..c42bc2900c6a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -80,8 +80,8 @@
#define GEN11_MCR_SLICE_MASK GEN11_MCR_SLICE(0xf)
#define GEN11_MCR_SUBSLICE(subslice) (((subslice) & 0x7) <<
24)
#define GEN11_MCR_SUBSLICE_MASK GEN11_MCR_SUBSLICE(0x7)
-#define MTL_MCR_GROUPID REG_GENMASK(11, 8)
-#define MTL_MCR_INSTANCEID REG_GENMASK(3, 0)
+#define MTL_MCR_GROUPID GENMASK(32, 8)
+#define MTL_MCR_INSTANCEID GENMASK(3, 0)
#define IPEIR_I965 _MMIO(0x2064)
#define IPEHR_I965 _MMIO(0x2068)
If the driver didn't support 32b CPUs, this would even go unnoticed.
So, what does prevent you from using GENMASK_ULL()?
nothing is preventing me to write the wrong code, which is what we are
trying to solve. GENMASK_ULL() would generate the wrong code as that
particular register is 32b, not 64b, on the GPU.
Another point, you may teach GENMASK() to issue a warning if hi and/or lo
bigger than BITS_PER_LONG.
Which varies depending on the CPU you are building for, so it misses the
point. GENMASK_U32/GENMASK_U16/GENMASK_U8 and BIT counterparts would
emit a warning if hi is bigger than _exactly_ 32, 16 or 8, regardless
of the CPU you built the code for.
Lucas De Marchi
I still don't see the usefulness of that churn.
Lucas De Marchi
> And there are already header for bitfields with a lot of helpers
> for (similar) cases if not yours.
>
> > What would you use for printk
[PATCH] drm/gma500: Replace kmap{,_atomic}() with page_address()
Remove unnecessary calls to kmap{,_atomic}() when acquiring
pages using GFP_DMA32.
The GFP_DMA32 uses the DMA32 zone to satisfy the allocation
requests. Therefore, pages allocated with GFP_DMA32 cannot
come from Highmem.
Avoid using calls to kmap_local_page() / kunmap_local() and
kmap() / kunmap() in the psb_mmu_alloc_pd function. Instead,
utilize page_address().
Remove the usage of kmap_atomic() / kunmap_atomic() in the
psb_mmu_alloc_pt function. Use page_address() instead.
Substitute kmap_atomic(pt->p) / kunmap_atomic(pt->v) calls
in the psb_mmu_pt_alloc_map_lock() and psb_mmu_pt_unmap_unlock()
functions with page_address(pt->p). This is possible as
pt = psb_mmu_alloc_pt(pd) allocates a page using
pt->p = alloc_page(GFP_DMA32).
Suggested-by: Ira Weiny
Signed-off-by: Sumitra Sharma
---
drivers/gpu/drm/gma500/mmu.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
index a70b01ccdf70..59aa5661e56a 100644
--- a/drivers/gpu/drm/gma500/mmu.c
+++ b/drivers/gpu/drm/gma500/mmu.c
@@ -184,20 +184,15 @@ struct psb_mmu_pd *psb_mmu_alloc_pd(struct psb_mmu_driver
*driver,
pd->invalid_pte = 0;
}
- v = kmap_local_page(pd->dummy_pt);
+ v = page_address(pd->dummy_pt);
for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
v[i] = pd->invalid_pte;
- kunmap_local(v);
-
- v = kmap_local_page(pd->p);
+ v = page_address(pd->p);
for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
v[i] = pd->invalid_pde;
- kunmap_local(v);
-
- clear_page(kmap(pd->dummy_page));
- kunmap(pd->dummy_page);
+ clear_page(page_address(pd->dummy_page));
pd->tables = vmalloc_user(sizeof(struct psb_mmu_pt *) * 1024);
if (!pd->tables)
@@ -279,7 +274,7 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
psb_mmu_pd *pd)
spin_lock(lock);
- v = kmap_atomic(pt->p);
+ v = page_address(pt->p);
clf = (uint8_t *) v;
ptes = (uint32_t *) v;
for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
@@ -293,7 +288,6 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
psb_mmu_pd *pd)
}
mb();
}
- kunmap_atomic(v);
spin_unlock(lock);
pt->count = 0;
@@ -339,7 +333,7 @@ static struct psb_mmu_pt *psb_mmu_pt_alloc_map_lock(struct
psb_mmu_pd *pd,
atomic_set(>driver->needs_tlbflush, 1);
}
}
- pt->v = kmap_atomic(pt->p);
+ pt->v = page_address(pt->p);
return pt;
}
@@ -365,7 +359,6 @@ static void psb_mmu_pt_unmap_unlock(struct psb_mmu_pt *pt)
struct psb_mmu_pd *pd = pt->pd;
uint32_t *v;
- kunmap_atomic(pt->v);
if (pt->count == 0) {
v = kmap_atomic(pd->p);
v[pt->index] = pd->invalid_pde;
--
2.25.1
Re: [PATCH] drm/amd/amdgpu: Use “__packed“ instead of "pragma pack()"
Hi Su, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.4-rc7 next-20230620] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Su-Hui/drm-amd-amdgpu-Use-__packed-instead-of-pragma-pack/20230620-165739 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230620085543.576733-1-suhui%40nfschina.com patch subject: [PATCH] drm/amd/amdgpu: Use “__packed“ instead of "pragma pack()" config: openrisc-randconfig-s051-20230620 (https://download.01.org/0day-ci/archive/20230621/202306210140.tawpw0sg-...@intel.com/config) compiler: or1k-linux-gcc (GCC) 12.3.0 reproduce: (https://download.01.org/0day-ci/archive/20230621/202306210140.tawpw0sg-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202306210140.tawpw0sg-...@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression >> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: incorrect >> type in initializer (different address spaces) @@ expected unsigned int >> [noderef] __user *__pu_addr @@ got unsigned int [usertype] * @@ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: expected unsigned int [noderef] __user *__pu_addr drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: got unsigned int [usertype] * drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:485:29: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned int [noderef] __user *__pu_addr @@ got unsigned int [usertype] * @@ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: expected unsigned int [noderef] __user *__pu_addr drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: got unsigned int [usertype] * drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:500:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned int [noderef] __user *__pu_addr @@ got unsigned int [usertype] * @@ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: expected unsigned int [noderef] __user *__pu_addr drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: got unsigned int [usertype] * drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: sparse: cast removes address space '__user' of expression drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:546:21: sparse: s
[PATCH] drm/bridge_connector: use drm_kms_helper_connector_hotplug_event()
This adds more information to the hotplug uevent and lets user-space know that it's about a particular connector only. Signed-off-by: Simon Ser Cc: Dmitry Baryshkov Cc: Paul Cercueil Cc: Laurent Pinchart Cc: Sam Ravnborg --- drivers/gpu/drm/drm_bridge_connector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c index 19ae4a177ac3..fc6f16e14f36 100644 --- a/drivers/gpu/drm/drm_bridge_connector.c +++ b/drivers/gpu/drm/drm_bridge_connector.c @@ -125,7 +125,7 @@ static void drm_bridge_connector_hpd_cb(void *cb_data, drm_bridge_connector_hpd_notify(connector, status); - drm_kms_helper_hotplug_event(dev); + drm_kms_helper_connector_hotplug_event(connector); } static void drm_bridge_connector_enable_hpd(struct drm_connector *connector) -- 2.41.0
[PATCH v2 4/4] drm/msm/a5xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
Changes since v1:
- None
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a99310b68793..b4c1720ba89c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1744,6 +1744,7 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct a5xx_gpu *a5xx_gpu = NULL;
struct adreno_gpu *adreno_gpu;
struct msm_gpu *gpu;
@@ -1770,6 +1771,23 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
nr_rings = 4;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
if (adreno_cmp_rev(ADRENO_REV(5, 1, 0, ANY_ID), config->rev))
nr_rings = 1;
--
2.34.1
[PATCH v2 2/4] drm/msm/a3xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
Changes since v1:
- None
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c86b377f6f0d..fc23810d7684 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -530,6 +530,8 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -558,6 +560,25 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
--
2.34.1
[PATCH v2 3/4] drm/msm/a4xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
Changes since v1:
- None
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 715436cb3996..2ae072b4e79d 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -658,6 +658,8 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -684,6 +686,25 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
adreno_gpu->registers = adreno_is_a405(adreno_gpu) ? a405_registers :
a4xx_registers;
--
2.34.1
[PATCH v2 1/4] drm/msm/a2xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions:
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/msm/adreno/adreno_gpu.h:171
a2xx_gpu_init+0x138/0x184
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-rc7-next-20230620 #993
Pass the GPU revision information to avoid run-time warning.
Tested on a imx53-qsb board.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Make it part of a single patch series.
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index c67089a7ebc1..4e1218462a23 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -520,6 +520,8 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
int ret;
if (!pdev) {
@@ -540,6 +542,23 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
if (adreno_is_a20x(adreno_gpu))
adreno_gpu->registers = a200_registers;
else if (adreno_is_a225(adreno_gpu))
--
2.34.1
Re: [PATCH] drm/sysfs: rename drm_sysfs_connector_status_event()
Hi Simon. On Tue, Jun 20, 2023 at 05:42:42PM +, Simon Ser wrote: > Rename drm_sysfs_connector_status_event() to > drm_sysfs_connector_property_event(). Indeed, "status" is a bit > vague: it can easily be confused with the connected/disconnected > status of the connector. This function has nothing to do with > connected/disconnected: it merely sends a notification that a > connector's property has changed (e.g. HDCP, privacy screen, etc). > > Signed-off-by: Simon Ser > Cc: Manasi Navare > Cc: Sam Ravnborg > Cc: Harry Wentland > Cc: Daniel Vetter Makes sense to me. Reviewed-by: Sam Ravnborg
[PATCH] drm/sysfs: rename drm_sysfs_connector_status_event()
Rename drm_sysfs_connector_status_event() to
drm_sysfs_connector_property_event(). Indeed, "status" is a bit
vague: it can easily be confused with the connected/disconnected
status of the connector. This function has nothing to do with
connected/disconnected: it merely sends a notification that a
connector's property has changed (e.g. HDCP, privacy screen, etc).
Signed-off-by: Simon Ser
Cc: Manasi Navare
Cc: Sam Ravnborg
Cc: Harry Wentland
Cc: Daniel Vetter
---
drivers/gpu/drm/display/drm_hdcp_helper.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 8
drivers/gpu/drm/drm_sysfs.c | 23 +--
include/drm/drm_sysfs.h | 4 ++--
4 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index e78999c72bd7..a3f0e6d96105 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -415,7 +415,7 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
return;
state->content_protection = val;
- drm_sysfs_connector_status_event(connector,
-dev->mode_config.content_protection_property);
+ drm_sysfs_connector_property_event(connector,
+
dev->mode_config.content_protection_property);
}
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3ed4cfcb350c..bf8371dc2a61 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2730,10 +2730,10 @@ static int drm_connector_privacy_screen_notifier(
drm_connector_update_privacy_screen_properties(connector, true);
drm_modeset_unlock(>mode_config.connection_mutex);
- drm_sysfs_connector_status_event(connector,
- connector->privacy_screen_sw_state_property);
- drm_sysfs_connector_status_event(connector,
- connector->privacy_screen_hw_state_property);
+ drm_sysfs_connector_property_event(connector,
+
connector->privacy_screen_sw_state_property);
+ drm_sysfs_connector_property_event(connector,
+
connector->privacy_screen_hw_state_property);
return NOTIFY_DONE;
}
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index f62767ff34b2..b169b3e44a92 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -487,17 +487,17 @@ void drm_sysfs_connector_hotplug_event(struct
drm_connector *connector)
EXPORT_SYMBOL(drm_sysfs_connector_hotplug_event);
/**
- * drm_sysfs_connector_status_event - generate a DRM uevent for connector
- * property status change
- * @connector: connector on which property status changed
- * @property: connector property whose status changed.
+ * drm_sysfs_connector_property_event - generate a DRM uevent for connector
+ * property change
+ * @connector: connector on which property changed
+ * @property: connector property which has changed.
*
- * Send a uevent for the DRM device specified by @dev. Currently we
+ * Send a uevent for the specified DRM connector and property. Currently we
* set HOTPLUG=1 and connector id along with the attached property id
- * related to the status change.
+ * related to the change.
*/
-void drm_sysfs_connector_status_event(struct drm_connector *connector,
- struct drm_property *property)
+void drm_sysfs_connector_property_event(struct drm_connector *connector,
+ struct drm_property *property)
{
struct drm_device *dev = connector->dev;
char hotplug_str[] = "HOTPLUG=1", conn_id[21], prop_id[21];
@@ -511,11 +511,14 @@ void drm_sysfs_connector_status_event(struct
drm_connector *connector,
snprintf(prop_id, ARRAY_SIZE(prop_id),
"PROPERTY=%u", property->base.id);
- DRM_DEBUG("generating connector status event\n");
+ drm_dbg_kms(connector->dev,
+ "[CONNECTOR:%d:%s] generating connector property event for
[PROP:%d:%s]\n",
+ connector->base.id, connector->name,
+ property->base.id, property->name);
kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
}
-EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+EXPORT_SYMBOL(drm_sysfs_connector_property_event);
struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
{
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 6273cac44e47..96a5d858404b 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -12,6 +12,6 @@ void drm_class_device_unregister(struct device *dev);
void drm_sysfs_hotplug_event(struct drm_device *dev);
void
Re: [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > > On Thu, 15 Jun 2023, Andy Shevchenko
> > > wrote:
> > > > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> > > >> On Fri, 12 May 2023, Andy Shevchenko
> > > >> wrote:
> > > >> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> > > >> >> On Fri, 12 May 2023, Andy Shevchenko
> > > >> >> wrote:
> > > >> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> > > >> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to
> > > >> >> >> create
> > > >> >> >> masks for fixed-width types and also the corresponding BIT_U32(),
> > > >> >> >> BIT_U16() and BIT_U8().
> > > >> >> > Why?
> > > >> >>
> > > >> >> The main reason is that GENMASK() and BIT() size varies for 32/64
> > > >> >> bit
> > > >> >> builds.
> > > >> >
> > > >> > When needed GENMASK_ULL() can be used (with respective castings
> > > >> > perhaps)
> > > >> > and BIT_ULL(), no?
> > > >>
> > > >> How does that help with making them the same 32-bit size on both 32 and
> > > >> 64 bit builds?
> > > >
> > > > u32 x = GENMASK();
> > > > u64 y = GENMASK_ULL();
> > > >
> > > > No? Then use in your code either x or y. Note that I assume that the
> > > > parameters
> > > > to GENMASK*() are built-time constants. Is it the case for you?
> > >
> > > What's wrong with wanting to define macros with specific size, depending
> > > on e.g. hardware registers instead of build size?
> >
> > Nothing, but I think the problem is smaller than it's presented.
>
> not sure about big/small problem you are talking about. It's a problem
> for when the *device* register is a 32b fixed width, which is
> independent from the CPU you are running on. We also have registers that
> are u16 and u64. Having fixed-width GENMASK and BIT helps avoiding
> mistakes like below. Just to use one example, the diff below builds
> fine on my 64b machine, yet it's obviously wrong:
>
> $ git diff diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index 0b414eae1683..692a0ad9a768 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -261,8 +261,8 @@ static u32 rw_with_mcr_steering_fw(struct intel_gt
> *gt,
>* No need to save old steering reg value.
>*/
> intel_uncore_write_fw(uncore, MTL_MCR_SELECTOR,
> - REG_FIELD_PREP(MTL_MCR_GROUPID,
> group) |
> -
> REG_FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
> + FIELD_PREP(MTL_MCR_GROUPID,
> group) |
> + FIELD_PREP(MTL_MCR_INSTANCEID,
> instance) |
> (rw_flag == FW_REG_READ ?
> GEN11_MCR_MULTICAST : 0));
> } else if (GRAPHICS_VER(uncore->i915) >= 11) {
> mcr_mask = GEN11_MCR_SLICE_MASK |
> GEN11_MCR_SUBSLICE_MASK;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 718cb2c80f79..c42bc2900c6a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -80,8 +80,8 @@
>#define GEN11_MCR_SLICE_MASK GEN11_MCR_SLICE(0xf)
>#define GEN11_MCR_SUBSLICE(subslice) (((subslice) & 0x7) <<
> 24)
>#define GEN11_MCR_SUBSLICE_MASK GEN11_MCR_SUBSLICE(0x7)
> -#define MTL_MCR_GROUPID REG_GENMASK(11, 8)
> -#define MTL_MCR_INSTANCEID REG_GENMASK(3, 0)
> +#define MTL_MCR_GROUPID GENMASK(32, 8)
> +#define MTL_MCR_INSTANCEID GENMASK(3, 0)
>#define IPEIR_I965 _MMIO(0x2064)
>#define IPEHR_I965 _MMIO(0x2068)
>
> If the driver didn't support 32b CPUs, this would even go unnoticed.
So, what does prevent you from using GENMASK_ULL()?
Another point, you may teach GENMASK() to issue a warning if hi and/or lo
bigger than BITS_PER_LONG.
I still don't see the usefulness of that churn.
> Lucas De Marchi
>
> > And there are already header for bitfields with a lot of helpers
> > for (similar) cases if not yours.
> >
> > > What would you use for printk format if you wanted to to print
> > > GENMASK()?
> >
> > %lu, no?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 1/3] drm/msm/a3xx: Pass the revision information
On 20/06/2023 20:33, Fabio Estevam wrote:
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
I'll take a glance later. Generic comment, you missed freedreno@, so
these patches will not pop up in our patch tracker. Also could you
please use git send-email passing all patches to the command, so that
they are threaded?
---
Build-tested only.
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c86b377f6f0d..fc23810d7684 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -530,6 +530,8 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -558,6 +560,25 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
This looks like a boilerplate being added to all aYxx drivers (and then
these fields are also set in adreno_gpu_init()). Can we remove
duplication somehow?
+
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
--
With best wishes
Dmitry
[PATCH 3/3] drm/msm/a5xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a99310b68793..b4c1720ba89c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1744,6 +1744,7 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct a5xx_gpu *a5xx_gpu = NULL;
struct adreno_gpu *adreno_gpu;
struct msm_gpu *gpu;
@@ -1770,6 +1771,23 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
nr_rings = 4;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
if (adreno_cmp_rev(ADRENO_REV(5, 1, 0, ANY_ID), config->rev))
nr_rings = 1;
--
2.34.1
[PATCH 2/3] drm/msm/43xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 715436cb3996..2ae072b4e79d 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -658,6 +658,8 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -684,6 +686,25 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
adreno_gpu->registers = adreno_is_a405(adreno_gpu) ? a405_registers :
a4xx_registers;
--
2.34.1
[PATCH 1/3] drm/msm/a3xx: Pass the revision information
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fabio Estevam
---
Build-tested only.
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c86b377f6f0d..fc23810d7684 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -530,6 +530,8 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
struct icc_path *ocmem_icc_path;
struct icc_path *icc_path;
int ret;
@@ -558,6 +560,25 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
if (ret)
goto fail;
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
--
2.34.1
Re: [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
On Thu, 15 Jun 2023, Andy Shevchenko wrote:
> On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
>> On Fri, 12 May 2023, Andy Shevchenko
wrote:
>> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
>> >> On Fri, 12 May 2023, Andy Shevchenko
wrote:
>> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
>> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create
>> >> >> masks for fixed-width types and also the corresponding BIT_U32(),
>> >> >> BIT_U16() and BIT_U8().
>> >> >
>> >> > Why?
>> >>
>> >> The main reason is that GENMASK() and BIT() size varies for 32/64 bit
>> >> builds.
>> >
>> > When needed GENMASK_ULL() can be used (with respective castings perhaps)
>> > and BIT_ULL(), no?
>>
>> How does that help with making them the same 32-bit size on both 32 and
>> 64 bit builds?
>
>u32 x = GENMASK();
>u64 y = GENMASK_ULL();
>
> No? Then use in your code either x or y. Note that I assume that the
parameters
> to GENMASK*() are built-time constants. Is it the case for you?
What's wrong with wanting to define macros with specific size, depending
on e.g. hardware registers instead of build size?
Nothing, but I think the problem is smaller than it's presented.
not sure about big/small problem you are talking about. It's a problem
for when the *device* register is a 32b fixed width, which is
independent from the CPU you are running on. We also have registers that
are u16 and u64. Having fixed-width GENMASK and BIT helps avoiding
mistakes like below. Just to use one example, the diff below builds
fine on my 64b machine, yet it's obviously wrong:
$ git diff
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 0b414eae1683..692a0ad9a768 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -261,8 +261,8 @@ static u32 rw_with_mcr_steering_fw(struct intel_gt
*gt,
* No need to save old steering reg value.
*/
intel_uncore_write_fw(uncore, MTL_MCR_SELECTOR,
- REG_FIELD_PREP(MTL_MCR_GROUPID,
group) |
-
REG_FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
+ FIELD_PREP(MTL_MCR_GROUPID,
group) |
+ FIELD_PREP(MTL_MCR_INSTANCEID,
instance) |
(rw_flag == FW_REG_READ ?
GEN11_MCR_MULTICAST : 0));
} else if (GRAPHICS_VER(uncore->i915) >= 11) {
mcr_mask = GEN11_MCR_SLICE_MASK |
GEN11_MCR_SUBSLICE_MASK;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 718cb2c80f79..c42bc2900c6a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -80,8 +80,8 @@
#define GEN11_MCR_SLICE_MASK GEN11_MCR_SLICE(0xf)
#define GEN11_MCR_SUBSLICE(subslice) (((subslice) & 0x7) <<
24)
#define GEN11_MCR_SUBSLICE_MASK GEN11_MCR_SUBSLICE(0x7)
-#define MTL_MCR_GROUPID REG_GENMASK(11, 8)
-#define MTL_MCR_INSTANCEID REG_GENMASK(3, 0)
+#define MTL_MCR_GROUPID GENMASK(32, 8)
+#define MTL_MCR_INSTANCEID GENMASK(3, 0)
#define IPEIR_I965 _MMIO(0x2064)
#define IPEHR_I965 _MMIO(0x2068)
If the driver didn't support 32b CPUs, this would even go unnoticed.
Lucas De Marchi
And there are already header for bitfields with a lot of helpers
for (similar) cases if not yours.
What would you use for printk format if you wanted to to print
GENMASK()?
%lu, no?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 3/3] drm/gem-dma: Unexport drm_gem_dma_vm_ops
Hi Thomas,
Thank you for the patch.
On Tue, Jun 20, 2023 at 02:03:23PM +0200, Thomas Zimmermann wrote:
> There are no external users of drm_gem_dma_vm_ops. Unexport the symbol.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_gem_dma_helper.c | 11 +--
> include/drm/drm_gem_dma_helper.h | 2 --
> 2 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
> b/drivers/gpu/drm/drm_gem_dma_helper.c
> index e9aa3ac140654..d8a415c3d156c 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -45,6 +45,11 @@
> * drm_gem_dma_vmap()). These helpers perform the necessary type conversion.
> */
>
> +static const struct vm_operations_struct drm_gem_dma_vm_ops = {
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> +};
> +
> static const struct drm_gem_object_funcs drm_gem_dma_default_funcs = {
> .free = drm_gem_dma_object_free,
> .print_info = drm_gem_dma_object_print_info,
> @@ -315,12 +320,6 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
> }
> EXPORT_SYMBOL_GPL(drm_gem_dma_dumb_create);
>
> -const struct vm_operations_struct drm_gem_dma_vm_ops = {
> - .open = drm_gem_vm_open,
> - .close = drm_gem_vm_close,
> -};
> -EXPORT_SYMBOL_GPL(drm_gem_dma_vm_ops);
> -
> #ifndef CONFIG_MMU
> /**
> * drm_gem_dma_get_unmapped_area - propose address for mapping in noMMU cases
> diff --git a/include/drm/drm_gem_dma_helper.h
> b/include/drm/drm_gem_dma_helper.h
> index 3877cbf0e927c..88a810f954fce 100644
> --- a/include/drm/drm_gem_dma_helper.h
> +++ b/include/drm/drm_gem_dma_helper.h
> @@ -45,8 +45,6 @@ int drm_gem_dma_vmap(struct drm_gem_dma_object *dma_obj,
>struct iosys_map *map);
> int drm_gem_dma_mmap(struct drm_gem_dma_object *dma_obj, struct
> vm_area_struct *vma);
>
> -extern const struct vm_operations_struct drm_gem_dma_vm_ops;
> -
> /*
> * GEM object functions
> */
--
Regards,
Laurent Pinchart
Re: [PATCH 1/3] drm/rcar-du: Import buffers with GEM DMA's helpers
Hi Thomas,
Thank you for the patch.
On Tue, Jun 20, 2023 at 02:03:21PM +0200, Thomas Zimmermann wrote:
> Call __drm_gem_dma_create() to create an object for imported buffers,
> instead of reimplementing the function within the driver. Reduces
> code duplication and will later allow to un-export a number of symbols
> from the GEM DMA helpers.
>
> Signed-off-by: Thomas Zimmermann
Nice simplification.
Reviewed-by: Laurent Pinchart
I assume you'll merge the whole series through drm-misc, please let me
know if that's not correct.
> ---
> drivers/gpu/drm/drm_gem_dma_helper.c | 5 +--
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 33 +++
> include/drm/drm_gem_dma_helper.h | 3 ++
> 3 files changed, 10 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
> b/drivers/gpu/drm/drm_gem_dma_helper.c
> index 870b90b78bc4e..e9aa3ac140654 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -67,8 +67,8 @@ static const struct drm_gem_object_funcs
> drm_gem_dma_default_funcs = {
> * A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
> * error code on failure.
> */
> -static struct drm_gem_dma_object *
> -__drm_gem_dma_create(struct drm_device *drm, size_t size, bool private)
> +struct drm_gem_dma_object *__drm_gem_dma_create(struct drm_device *drm,
> + size_t size, bool private)
> {
> struct drm_gem_dma_object *dma_obj;
> struct drm_gem_object *gem_obj;
> @@ -112,6 +112,7 @@ __drm_gem_dma_create(struct drm_device *drm, size_t size,
> bool private)
> kfree(dma_obj);
> return ERR_PTR(ret);
> }
> +EXPORT_SYMBOL_GPL(__drm_gem_dma_create);
>
> /**
> * drm_gem_dma_create - allocate an object with the given size
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index adfb36b0e8154..ea7487e270f13 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -356,49 +356,24 @@ const struct rcar_du_format_info
> *rcar_du_format_info(u32 fourcc)
> * Frame buffer
> */
>
> -static const struct drm_gem_object_funcs rcar_du_gem_funcs = {
> - .free = drm_gem_dma_object_free,
> - .print_info = drm_gem_dma_object_print_info,
> - .get_sg_table = drm_gem_dma_object_get_sg_table,
> - .vmap = drm_gem_dma_object_vmap,
> - .mmap = drm_gem_dma_object_mmap,
> - .vm_ops = _gem_dma_vm_ops,
> -};
> -
> struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
> *dev,
> struct dma_buf_attachment *attach,
> struct sg_table *sgt)
> {
> struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> struct drm_gem_dma_object *dma_obj;
> - struct drm_gem_object *gem_obj;
> - int ret;
>
> if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
> return drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
>
> - /* Create a DMA GEM buffer. */
> - dma_obj = kzalloc(sizeof(*dma_obj), GFP_KERNEL);
> - if (!dma_obj)
> - return ERR_PTR(-ENOMEM);
> -
> - gem_obj = _obj->base;
> - gem_obj->funcs = _du_gem_funcs;
> -
> - drm_gem_private_object_init(dev, gem_obj, attach->dmabuf->size);
> - dma_obj->map_noncoherent = false;
> -
> - ret = drm_gem_create_mmap_offset(gem_obj);
> - if (ret) {
> - drm_gem_object_release(gem_obj);
> - kfree(dma_obj);
> - return ERR_PTR(ret);
> - }
> + dma_obj = __drm_gem_dma_create(dev, attach->dmabuf->size, true);
> + if (IS_ERR(dma_obj))
> + return ERR_CAST(dma_obj);
>
> dma_obj->dma_addr = 0;
> dma_obj->sgt = sgt;
>
> - return gem_obj;
> + return _obj->base;
> }
>
> int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
> diff --git a/include/drm/drm_gem_dma_helper.h
> b/include/drm/drm_gem_dma_helper.h
> index 61da596780b64..3877cbf0e927c 100644
> --- a/include/drm/drm_gem_dma_helper.h
> +++ b/include/drm/drm_gem_dma_helper.h
> @@ -32,6 +32,9 @@ struct drm_gem_dma_object {
> #define to_drm_gem_dma_obj(gem_obj) \
> container_of(gem_obj, struct drm_gem_dma_object, base)
>
> +struct drm_gem_dma_object *__drm_gem_dma_create(struct drm_device *drm,
> + size_t size, bool private);
> +
> struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> size_t size);
> void drm_gem_dma_free(struct drm_gem_dma_object *dma_obj);
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/drm_gem.c: remove surplus else after return clause
Hi
Am 20.06.23 um 18:06 schrieb Sui Jingfeng:
Hi,
On 2023/6/20 22:43, Thomas Zimmermann wrote:
Hi
Am 20.06.23 um 06:08 schrieb Sui Jingfeng:
ping ?
On 2023/3/14 20:53, Sui Jingfeng wrote:
else is not generally useful after return
No indention please.
OK, will be fixed at the next version.
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
drivers/gpu/drm/drm_gem.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a6208e2c089b..364e3733af98 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1150,8 +1150,8 @@ int drm_gem_pin(struct drm_gem_object *obj)
{
if (obj->funcs->pin)
return obj->funcs->pin(obj);
- else
- return 0;
+
+ return 0;
This change is ok.
}
void drm_gem_unpin(struct drm_gem_object *obj)
@@ -1172,7 +1172,8 @@ int drm_gem_vmap(struct drm_gem_object *obj,
struct iosys_map *map)
ret = obj->funcs->vmap(obj, map);
if (ret)
return ret;
- else if (iosys_map_is_null(map))
+
+ if (iosys_map_is_null(map))
return -ENOMEM;
This is not correct. Calling iosys_map_is_null() is part of handling
the return value from vmap, so the else is fine.
Are you serious ?
1. Before apply this patch:
If the 'ret' is 0, it stand for obj->funcs->vmap() is successful, then
if (iosys_map_is_null(map)) will be run.
If the 'ret' is NOT 0, then it return immediately.
2. After apply this patch:
If the 'ret' is NOT 0, it stand for obj->funcs->vmap() failed, then it
return immediately.
If the 'ret' is 0, it stand for obj->funcs->vmap() is successful, then
the check if (iosys_map_is_null(map))
will be run!
I feel strange about the core here, I think the check ' if
(iosys_map_is_null(map))' is not needed,
the implement should responsible to handle all of possible errors.
The ->vmap() callback can succeed with ret=0, but we still have no
memory. Then we return -ENOMEM. The call to _is_null(map) is part of the
error handling for ->vmap(). That is a bit strange, but it as always
worked like that. Keeping all error handling in the same if-else block
make all this more obvious.
Best regards
Thomas
But both case (1. and 2.) are same in the semantic, right?
Best regards
Thomas
return 0;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] drm/drm_gem.c: remove surplus else after return clause
Hi,
On 2023/6/20 22:43, Thomas Zimmermann wrote:
Hi
Am 20.06.23 um 06:08 schrieb Sui Jingfeng:
ping ?
On 2023/3/14 20:53, Sui Jingfeng wrote:
else is not generally useful after return
No indention please.
OK, will be fixed at the next version.
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
drivers/gpu/drm/drm_gem.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a6208e2c089b..364e3733af98 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1150,8 +1150,8 @@ int drm_gem_pin(struct drm_gem_object *obj)
{
if (obj->funcs->pin)
return obj->funcs->pin(obj);
- else
- return 0;
+
+ return 0;
This change is ok.
}
void drm_gem_unpin(struct drm_gem_object *obj)
@@ -1172,7 +1172,8 @@ int drm_gem_vmap(struct drm_gem_object *obj,
struct iosys_map *map)
ret = obj->funcs->vmap(obj, map);
if (ret)
return ret;
- else if (iosys_map_is_null(map))
+
+ if (iosys_map_is_null(map))
return -ENOMEM;
This is not correct. Calling iosys_map_is_null() is part of handling
the return value from vmap, so the else is fine.
Are you serious ?
1. Before apply this patch:
If the 'ret' is 0, it stand for obj->funcs->vmap() is successful, then
if (iosys_map_is_null(map)) will be run.
If the 'ret' is NOT 0, then it return immediately.
2. After apply this patch:
If the 'ret' is NOT 0, it stand for obj->funcs->vmap() failed, then it
return immediately.
If the 'ret' is 0, it stand for obj->funcs->vmap() is successful, then
the check if (iosys_map_is_null(map))
will be run!
I feel strange about the core here, I think the check ' if
(iosys_map_is_null(map))' is not needed,
the implement should responsible to handle all of possible errors.
But both case (1. and 2.) are same in the semantic, right?
Best regards
Thomas
return 0;
--
Jingfeng
Re: [PATCH v4 5/6] dma-buf: Change locking policy for mmap()
On 5/31/23 22:58, Dmitry Osipenko wrote: > On 5/30/23 01:39, Dmitry Osipenko wrote: >> Change locking policy of mmap() callback, making exporters responsible >> for handling dma-buf reservation locking. Previous locking policy stated >> that dma-buf is locked for both importers and exporters by the dma-buf >> core, which caused a deadlock problem for DRM drivers in a case of >> self-imported dma-bufs which required to take the lock from the DRM >> exporter side. >> >> Reviewed-by: Emil Velikov >> Signed-off-by: Dmitry Osipenko >> --- >> drivers/dma-buf/dma-buf.c | 17 +++-- >> 1 file changed, 3 insertions(+), 14 deletions(-) > > Christian, you acked the drm patch of this series sometime ago, perhaps > it also implies implicit ack to this patch, but I'd prefer to have the > explicit ack. I'll apply this series to drm-misc later this week if > you'll approve this dma-buf change. Thanks in advance! I'll merge the patches tomorrow. If there are any additional comments, then please don't hesitate to post them. -- Best regards, Dmitry
Re: [PATCH v2 3/3] drm/prime: Unexport helpers for fd/handle conversion
On 6/20/2023 1:59 AM, Thomas Zimmermann wrote: Unexport drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). Both are only used internally within the PRIME code. v2: * reword docs as functions are now unexported (Simon) Signed-off-by: Thomas Zimmermann Reviewed-by: Simon Ser Acked-by: Alex Deucher Reviewed-by: Jeffrey Hugo
Re: [PATCH v2 1/3] drm: Enable PRIME import/export for all drivers
On 6/20/2023 1:59 AM, Thomas Zimmermann wrote: Call drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() by default if no PRIME import/export helpers have been set. Both functions are the default for almost all drivers. DRM drivers implement struct drm_driver.gem_prime_import_sg_table to import dma-buf objects from other drivers. Having the function drm_gem_prime_fd_to_handle() functions set by default allows each driver to import dma-buf objects to itself, even without support for other drivers. For drm_gem_prime_handle_to_fd() it is similar: using it by default allows each driver to export to itself, even without support for other drivers. This functionality enables userspace to share per-driver buffers across process boundaries via PRIME (e.g., wlroots requires this functionality). The patch generalizes a pattern that has previously been implemented by GEM VRAM helpers [1] to work with any driver. For example, gma500 can now run the wlroots-based sway compositor. v2: * clean up docs and TODO comments (Simon, Zack) * clean up style in drm_getcap() Signed-off-by: Thomas Zimmermann Link: https://lore.kernel.org/dri-devel/20230302143502.500661-1-cont...@emersion.fr/ # 1 Reviewed-by: Simon Ser Acked-by: Alex Deucher Reviewed-by: Jeffrey Hugo
Re: [PATCH v6 2/8] dt-bindings: display: bridge: Add Cadence MHDP8501 HDMI and DP
On Thu, Jun 15, 2023 at 09:38:12AM +0800, Sandor Yu wrote:
> Add bindings for Cadence MHDP8501 DisplayPort and HDMI driver.
Bindings are for h/w, not a driver.
>
> Signed-off-by: Sandor Yu
> ---
> .../display/bridge/cdns,mhdp8501.yaml | 105 ++
> 1 file changed, 105 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> new file mode 100644
> index ..a54756815e6f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence MHDP8501 Displayport bridge
> +
> +maintainers:
> + - Sandor Yu
> +
> +description:
> + The Cadence MHDP8501 Displayport/HDMI TX interface.
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,mhdp8501-dp
> + - cdns,mhdp8501-hdmi
> + - fsl,imx8mq-mhdp8501-dp
> + - fsl,imx8mq-mhdp8501-hdmi
Is DP vs. HDMI fixed for a particular SoC implementation or it's a board
level decision. In the latter case, the type of connector should
determine the mode, not compatible.
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +description: MHDP8501 DP/HDMI APB clock.
Seems odd there's no clock tied to the pixel/serdes clock.
> +
> + phys:
> +maxItems: 1
> +
> + interrupts:
> +items:
> + - description: Hotplug cable plugin.
> + - description: Hotplug cable plugout.
> +
> + interrupt-names:
> +items:
> + - const: plug_in
> + - const: plug_out
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Input port from display controller output.
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Output port to DP/HDMI connector.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - interrupt-names
> + - phys
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +mhdp_dp: dp-bridge@32c0 {
> +compatible = "fsl,imx8mq-mhdp8501-dp";
> +reg = <0x32c0 0x10>;
> +interrupts = ,
> + ;
> +interrupt-names = "plug_in", "plug_out";
> +clocks = < IMX8MQ_CLK_DISP_APB_ROOT>;
> +phys = <_phy>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +
> +mhdp_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +
> +mhdp_out: endpoint {
> +remote-endpoint = <_con>;
> +};
> +};
> +};
> +};
> --
> 2.34.1
>
Re: [PATCH v6 2/8] dt-bindings: display: bridge: Add Cadence MHDP8501 HDMI and DP
On Fri, Jun 16, 2023 at 11:31:43AM +0200, Alexander Stein wrote: > Hi Sandor, > > Am Donnerstag, 15. Juni 2023, 03:38:12 CEST schrieb Sandor Yu: > > Add bindings for Cadence MHDP8501 DisplayPort and HDMI driver. > > > > Signed-off-by: Sandor Yu > > --- > > .../display/bridge/cdns,mhdp8501.yaml | 105 ++ > > 1 file changed, 105 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml > > b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml new > > file mode 100644 > > index ..a54756815e6f > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml > > @@ -0,0 +1,105 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Cadence MHDP8501 Displayport bridge > > + > > +maintainers: > > + - Sandor Yu > > + > > +description: > > + The Cadence MHDP8501 Displayport/HDMI TX interface. > > + > > +properties: > > + compatible: > > +enum: > > + - cdns,mhdp8501-dp > > + - cdns,mhdp8501-hdmi > > + - fsl,imx8mq-mhdp8501-dp > > + - fsl,imx8mq-mhdp8501-hdmi > > + > > + reg: > > +maxItems: 1 > > + > > + clocks: > > +maxItems: 1 > > +description: MHDP8501 DP/HDMI APB clock. > > + > > + phys: > > +maxItems: 1 > > + > > + interrupts: > > +items: > > + - description: Hotplug cable plugin. > > + - description: Hotplug cable plugout. > > + > > + interrupt-names: > > +items: > > + - const: plug_in > > + - const: plug_out > > + > > + ports: > > +$ref: /schemas/graph.yaml#/properties/ports > > + > > +properties: > > + port@0: > > +$ref: /schemas/graph.yaml#/properties/port > > +description: > > + Input port from display controller output. > > + port@1: > > +$ref: /schemas/graph.yaml#/properties/port > > +description: > > + Output port to DP/HDMI connector. > > + > > +required: > > + - port@0 > > + - port@1 > > You mark these ports as required, but apparently the drivers do not use them, > AFAICT. E.g. missing port@1 is not resulting in an error, at lease for HDMI > one. A connector node should be required whether a particular OS requires it or not. The bindings without predate defining a connector node. Rob
[PATCH] drm/msm/a2xx: Pass the revision information
From: Fabio Estevam
Since commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") the following run-time warning is observed:
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/msm/adreno/adreno_gpu.h:171
a2xx_gpu_init+0x138/0x184
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-rc7-next-20230620 #993
Fix the problem by assigning the GPU revision fields like it is
done in a6xx_gpu.
Fixes: cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before
being set")
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index c67089a7ebc1..4e1218462a23 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -520,6 +520,8 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+ struct adreno_platform_config *config = pdev->dev.platform_data;
+ const struct adreno_info *info;
int ret;
if (!pdev) {
@@ -540,6 +542,23 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+ /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+ info = adreno_info(config->rev);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ /* Assign these early so that we can use the is_aXYZ helpers */
+ /* Numeric revision IDs (e.g. 630) */
+ adreno_gpu->revn = info->revn;
+ /* New-style ADRENO_REV()-only */
+ adreno_gpu->rev = info->rev;
+ /* Quirk data */
+ adreno_gpu->info = info;
+
if (adreno_is_a20x(adreno_gpu))
adreno_gpu->registers = a200_registers;
else if (adreno_is_a225(adreno_gpu))
--
2.34.1
Re: [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote: > On Thu, 15 Jun 2023, Andy Shevchenko > wrote: > > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote: > >> On Fri, 12 May 2023, Andy Shevchenko > >> wrote: > >> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote: > >> >> On Fri, 12 May 2023, Andy Shevchenko > >> >> wrote: > >> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote: > >> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create > >> >> >> masks for fixed-width types and also the corresponding BIT_U32(), > >> >> >> BIT_U16() and BIT_U8(). > >> >> > > >> >> > Why? > >> >> > >> >> The main reason is that GENMASK() and BIT() size varies for 32/64 bit > >> >> builds. > >> > > >> > When needed GENMASK_ULL() can be used (with respective castings perhaps) > >> > and BIT_ULL(), no? > >> > >> How does that help with making them the same 32-bit size on both 32 and > >> 64 bit builds? > > > > u32 x = GENMASK(); > > u64 y = GENMASK_ULL(); > > > > No? Then use in your code either x or y. Note that I assume that the > > parameters > > to GENMASK*() are built-time constants. Is it the case for you? > > What's wrong with wanting to define macros with specific size, depending > on e.g. hardware registers instead of build size? Nothing, but I think the problem is smaller than it's presented. And there are already header for bitfields with a lot of helpers for (similar) cases if not yours. > What would you use for printk format if you wanted to to print > GENMASK()? %lu, no? -- With Best Regards, Andy Shevchenko
Re: [PATCH] dt-bindings: gpu: drop unneeded quotes
On Fri, 09 Jun 2023 16:07:38 +0200, Krzysztof Kozlowski wrote: > Cleanup bindings dropping unneeded quotes. Once all these are fixed, > checking for this can be enabled in yamllint. > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 2 +- > Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Applied, thanks!
Re: [RFC 02/10] drm: Update file owner during use
Hi Tvrtko Sorry for the delay, real life and other obligations got in the way. On Thu, 8 Jun 2023 at 15:26, Tvrtko Ursulin wrote: > On 21/04/2023 13:13, Emil Velikov wrote: > Are you okay if I just paste your very fine explanation verbatim, with > credits? > Yes, feel free to use as much of if as you see reasonable. > > I also had a brief look at 01/10, although I cannot find many > > references for the pid <> tguid mappings. Be that on the kernel side > > or userspace - do you have any links that I can educate myself? > > TGID or thread group leader. For single threaded userspace TGID equals > to PID, while for multi-threaded first thread TGID equals PID/TID, while > additional threads PID/TID does not equal TGID. Clear, as mud? :) My > POSIX book is misplaced somewhere having not consulted it years... :) > Ack. /me looks into actually buying one, perhaps Thanks Emil
Re: [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
On Thu, 15 Jun 2023, Andy Shevchenko wrote: > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote: >> On Fri, 12 May 2023, Andy Shevchenko >> wrote: >> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote: >> >> On Fri, 12 May 2023, Andy Shevchenko >> >> wrote: >> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote: >> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create >> >> >> masks for fixed-width types and also the corresponding BIT_U32(), >> >> >> BIT_U16() and BIT_U8(). >> >> > >> >> > Why? >> >> >> >> The main reason is that GENMASK() and BIT() size varies for 32/64 bit >> >> builds. >> > >> > When needed GENMASK_ULL() can be used (with respective castings perhaps) >> > and BIT_ULL(), no? >> >> How does that help with making them the same 32-bit size on both 32 and >> 64 bit builds? > > u32 x = GENMASK(); > u64 y = GENMASK_ULL(); > > No? Then use in your code either x or y. Note that I assume that the > parameters > to GENMASK*() are built-time constants. Is it the case for you? What's wrong with wanting to define macros with specific size, depending on e.g. hardware registers instead of build size? What would you use for printk format if you wanted to to print GENMASK()? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm/drm_gem.c: remove surplus else after return clause
Hi
Am 20.06.23 um 06:08 schrieb Sui Jingfeng:
ping ?
On 2023/3/14 20:53, Sui Jingfeng wrote:
else is not generally useful after return
No indention please.
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
drivers/gpu/drm/drm_gem.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a6208e2c089b..364e3733af98 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1150,8 +1150,8 @@ int drm_gem_pin(struct drm_gem_object *obj)
{
if (obj->funcs->pin)
return obj->funcs->pin(obj);
- else
- return 0;
+
+ return 0;
This change is ok.
}
void drm_gem_unpin(struct drm_gem_object *obj)
@@ -1172,7 +1172,8 @@ int drm_gem_vmap(struct drm_gem_object *obj,
struct iosys_map *map)
ret = obj->funcs->vmap(obj, map);
if (ret)
return ret;
- else if (iosys_map_is_null(map))
+
+ if (iosys_map_is_null(map))
return -ENOMEM;
This is not correct. Calling iosys_map_is_null() is part of handling the
return value from vmap, so the else is fine.
Best regards
Thomas
return 0;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/3] drm/rockchip: Resolve dependency in GEM DMA helpers
Hi Am 20.06.23 um 15:56 schrieb Jonas Karlman: Hi Thomas, On 2023-06-20 14:03, Thomas Zimmermann wrote: Remove the dependency on the GEM DMA helper library. Rockchip comes with its own implementation of the GEM interface. It only uses the VM callbacks in drm_gem_dma_vm_ops from the GEM DMA helpers. These are not DMA specific. Duplicate drm_gem_dma_vm_ops in rockchip and remove all dependencies on the GEM DMA helper library. I have intentions to remove the entire custom implementation of the GEM interface and replace it with use of GEM DMA helpers in a future series. Current custom implementation break import of video framebuffers located in memory beyond 4GB. Switching to use pure GEM DMA helpers solved that issue but requires reworking IOMMU integration for full support of multiple VOPs on e.g., RK3288 and RK3399. I have no ETA on when such series can be ready so this is more of a heads up that I will revert this removal of dependency on GEM DMA helper library in a future series. No problem. I'm only interested in cleaning up the current interfaces. Rockchip can easily switch to real GEM DMA code. Best regards Thomas Regards, Jonas Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/rockchip/Kconfig| 1 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 ++-- 3 files changed, 7 insertions(+), 4 deletions(-) [snip] -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS
On 6/1/2023 12:45 PM, Alan Previn wrote:
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
This patch adds this additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we catch it so that we can change the returned PXP_STATUS
from "2" (i.e. 'PXP is supported but not yet ready')
to "-ENODEV". This typically should not happen and if it
does, we have a platform configuration.
- If a PXP arbitration session creation event failed
due to incorrect firmware version or blocking SOC fusing
or blocking BIOS configuration (platform reasons that won't
change if we retry), then reflect that blockage by also
returning -ENODEV in the GET_PARAM-PXP_STATUS.
- GET_PARAM:PXP_STATUS should not wait at all if PXP is
supported but non-i915 dependencies (component-driver /
firmware) we are still pending to complete the init flows.
In this case, just return "2" immediately (i.e. 'PXP is
supported but not yet ready').
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 11 +-
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 25 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 7 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 9
7 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fb0984f875f9..4dd744c96a37 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -42,8 +42,17 @@ static void gsc_work(struct work_struct *work)
}
ret = intel_gsc_proxy_request_handler(gsc);
- if (ret)
+ if (ret) {
+ if (actions & GSC_ACTION_FW_LOAD) {
+ /*
+* a proxy request failure that came together
with the
+* firmware load action means the last part of
init has
+* failed so GSC fw won't be usable after this
+*/
+ intel_uc_fw_change_status(>fw,
INTEL_UC_FIRMWARE_LOAD_FAIL);
+ }
goto out_put;
+ }
/* mark the GSC FW init as done the first time we run this */
if (actions & GSC_ACTION_FW_LOAD) {
On the huc authentication comment block above this snippet, the last
statement: "Note that we can only do the GSC auth if the GuC auth was"
is confusing as the code below is only dealing with HuC Authentication.
This function seems to have a section to deal with FW load action and
another to deal with SW Proxy requests, but we seem to be mixing both
actions in the SW proxy section. instead, can we move this call to
intel_gsc_proxy_request_handler to the FW load section itself instead of
handling it as an additional check in the SW_proxy section? In the same
vein, we should also move the intel_uc_fw_change_status() call into the
above FW Load action section. i think that way the code reads better.
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 6f11d7eaa91a..1b2ee98a158a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -105,7 +105,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
return value;
break;
case I915_PARAM_PXP_STATUS:
- value = intel_pxp_get_readiness_status(i915->pxp);
+ value = intel_pxp_get_readiness_status(i915->pxp, 1);
if (value < 0)
return value;
break;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index bb2e15329f34..1478bb9b4e26 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -359,21 +359,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
intel_runtime_pm_put(>runtime_pm, wakeref);
}
+static bool pxp_required_fw_failed(struct intel_pxp *pxp)
+{
+ if (__intel_uc_fw_status(>ctrl_gt->uc.huc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0) &&
+ __intel_uc_fw_status(>ctrl_gt->uc.gsc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+
+ return false;
+}
+
/*
* this helper is used by both intel_pxp_start and by
* the GET_PARAM IOCTL that user space calls. Thus, the
* return values here should match the UAPI spec.
*/
-int intel_pxp_get_readiness_status(struct
Re: [PATCH v2] drm/msm/dsi: Document DSC related pclk_rate and hdisplay calculations
On 20/06/2023 15:05, Marijn Suijten wrote:
On 2023-06-20 00:06:47, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
- Converted dsi_adjust_pclk_for_compression() into kerneldoc (Marijn)
- Added a pointer from dsi_timing_setup() docs to
dsi_adjust_pclk_for_compression() (Marijn)
- Fixed two typo (Marijn)
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 40 --
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 3f6dfb4f9d5a..a8a31c3dd168 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -528,6 +528,25 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
+/**
+ * dsi_adjust_pclk_for_compression() - Adjust the pclk rate for compression
case
+ * @mode: the selected mode for the DSI output
The
+ * @dsc: DRM DSC configuration for this DSI output
+ *
+ * Adjust the pclk rate by calculating a new hdisplay proportional to
+ * the compression ratio such that:
+ * new_hdisplay = old_hdisplay * compressed_bpp / uncompressed_bpp
And in v1 you explained that it is _not_ about bpp...
Hmm, this bit stayed intact, so I'm slightly confused here.
This function is about BPP and compressed rate. dsi_timing_setup() is
about bytes.
+ *
+ * Porches do not need to be adjusted:
+ * - For the VIDEO mode they are not compressed by DSC and are passed as is.
+ * - For the CMD mode there are no actual porches. Instead these fields
I feel like "For VIDEO mode" and "For CMD mode" reads more naturally, no
need for "the", but I don't know the grammar rule that states so.
Ack
+ * currently represent the overhead to the image data transfer. As such, they
+ * are calculated for the final mode parameters (after the compression) and
+ * are not to be adjusted too.
+ *
+ * FIXME: Reconsider this if/when CMD mode handling is rewritten to use
+ * refresh rate and data overhead as a starting point of the calculations.
Nit: well, refresh rate is already part of this calculation (that's how
drm_display_mode's clock member comes to be, and how drm_mode_vrefresh()
figures out fps after the fact). It's all about the per-CMD transfer
overhead in bytes that is currently not part of the calculation.
Please correct me if I'm wrong, we start from mode->clock. Refresh rate
isn't even a part of struct drm_display_mode.
+ */
static unsigned long dsi_adjust_pclk_for_compression(const struct
drm_display_mode *mode,
const struct drm_dsc_config *dsc)
{
@@ -926,8 +945,25 @@ static void dsi_timing_setup(struct msm_dsi_host
*msm_host, bool is_bonded_dsi)
if (ret)
return;
- /* Divide the display by 3 but keep back/font porch and
-* pulse width same
+ /*
+* DPU sends 3 bytes per pclk cycle to DSI. If compression is
Should this be pixels (1 pixel), not bytes, just like in the compressed
scenario?
No.
+* not used, a single pixel is transferred at each pulse, no
+* matter what bpp or pixel format is used. In case of DSC
+* compression this results (due to data alignment
+* requirements) in a transfer of 3 compressed pixel per pclk
+* cycle.
+*
+* If widebus is enabled, bus width is extended to 6 bytes.
+* This way the DPU can transfer 6 compressed pixels with bpp
+* less or equal to 8 or 3 compressed pixels in case bpp is
+* greater than 8.
Okay, so one can not send more than 6 pixels even if the bpp is less
than 8, is what this comes down to.
Yes.
+*
+* The back/font porch and pulse width are kept intact. They
+* represent timing parameters rather than actual data
+* transfer. See the documentation of
+* dsi_adjust_pclk_for_compression().
Nit: note that this is only for VIDEO mode, h_total and ha_end are
accurately unused in the CMDmode path below.
- Marijn
+*
+* XXX: widebus is not supported by the driver (yet).
*/
h_total -= hdisplay;
hdisplay =
DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc), 3);
--
2.39.2
--
With best wishes
Dmitry
Re: [PATCH drm-next v5 00/14] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI
Hi Boris, On 6/20/23 11:25, Boris Brezillon wrote: Hi Danilo, On Tue, 20 Jun 2023 02:42:03 +0200 Danilo Krummrich wrote: This patch series provides a new UAPI for the Nouveau driver in order to support Vulkan features, such as sparse bindings and sparse residency. Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to keep track of GPU virtual address (VA) mappings in a more generic way. The DRM GPUVA manager is indented to help drivers implement userspace-manageable GPU VA spaces in reference to the Vulkan API. In order to achieve this goal it serves the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, making use of the maple_tree. 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager, itself providing the following new interfaces. 1) Initialize a GPU VA space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA space managed by the kernel and userspace, respectively. 2) Allocate and free a VA space region as well as bind and unbind memory to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, make use of the DRM scheduler to queue jobs and support asynchronous processing with DRM syncobjs as synchronization mechanism. By default DRM_IOCTL_NOUVEAU_VM_BIND does synchronous processing, DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only. The new VM_BIND UAPI for Nouveau makes also use of drm_exec (execution context for GEM buffers) by Christian König. Since the patch implementing drm_exec was not yet merged into drm-next it is part of this series, as well as a small fix for this patch, which was found while testing this series. This patch series is also available at [1]. There is a Mesa NVK merge request by Dave Airlie [2] implementing the corresponding userspace parts for this series. The Vulkan CTS test suite passes the sparse binding and sparse residency test cases for the new UAPI together with Dave's Mesa work. There are also some test cases in the igt-gpu-tools project [3] for the new UAPI and hence the DRM GPU VA manager. However, most of them are testing the DRM GPU VA manager's logic through Nouveau's new UAPI and should be considered just as helper for implementation. However, I absolutely intend to change those test cases to proper kunit test cases for the DRM GPUVA manager, once and if we agree on it's usefulness and design. [1] https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next / https://gitlab.freedesktop.org/nouvelles/kernel/-/merge_requests/1 [2] https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/150/ [3] https://gitlab.freedesktop.org/dakr/igt-gpu-tools/-/tree/wip_nouveau_vm_bind Changes in V2: == Nouveau: - Reworked the Nouveau VM_BIND UAPI to avoid memory allocations in fence signalling critical sections. Updates to the VA space are split up in three separate stages, where only the 2. stage executes in a fence signalling critical section: 1. update the VA space, allocate new structures and page tables 2. (un-)map the requested memory bindings 3. free structures and page tables - Separated generic job scheduler code from specific job implementations. - Separated the EXEC and VM_BIND implementation of the UAPI. - Reworked the locking parts of the nvkm/vmm RAW interface, such that (un-)map operations can be executed in fence signalling critical sections. GPUVA Manager: - made drm_gpuva_regions optional for users of the GPUVA manager - allow NULL GEMs for drm_gpuva entries - swichted from drm_mm to maple_tree for track drm_gpuva / drm_gpuva_region entries - provide callbacks for users to allocate custom drm_gpuva_op structures to allow inheritance - added user bits to drm_gpuva_flags - added a prefetch operation type in order to support generating prefetch operations in the same way other operations generated - hand the responsibility for mutual exclusion for a GEM's drm_gpuva list to the user; simplified corresponding (un-)link functions Maple Tree: - I added two maple tree patches to the series, one to support custom tree walk macros and one to hand the locking responsibility to the user of the GPUVA manager without pre-defined lockdep checks. Changes in V3: ==
Re: [PATCH] accel/qaic: Call DRM helper function to destroy prime GEM
On 6/14/2023 10:15 AM, Jeffrey Hugo wrote:
From: Pranjal Ramajor Asha Kanojiya
smatch warning:
drivers/accel/qaic/qaic_data.c:620 qaic_free_object() error:
dereferencing freed memory 'obj->import_attach'
obj->import_attach is detached and freed using dma_buf_detach().
But used after free to decrease the dmabuf ref count using
dma_buf_put().
drm_prime_gem_destroy() handles this issue and performs the proper clean
up instead of open coding it in the driver.
Fixes: ff13be830333 ("accel/qaic: Add datapath")
Reported-by: Sukrut Bellary
Closes:
https://lore.kernel.org/all/20230610021200.377452-1-sukrut.bell...@linux.com/
Suggested-by: Christian König
Signed-off-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Carl Vanderlip
Reviewed-by: Jeffrey Hugo
Signed-off-by: Jeffrey Hugo
Pushed to drm-misc-fixes
-Jeff
Re: [PATCH drm-next v5 03/14] drm: manager to keep track of GPUs VA mappings
Hi Christian,
On 6/20/23 08:45, Christian König wrote:
Hi Danilo,
sorry for the delayed reply. I've trying to dig myself out of a hole at
the moment.
No worries, thank you for taking a look anyway!
Am 20.06.23 um 02:42 schrieb Danilo Krummrich:
[SNIP]
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bbc721870c13..5ec8148a30ee 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -36,6 +36,8 @@
#include
#include
+#include
+#include
#include
@@ -379,6 +381,18 @@ struct drm_gem_object {
*/
struct dma_resv _resv;
+ /**
+ * @gpuva:
+ *
+ * Provides the list of GPU VAs attached to this GEM object.
+ *
+ * Drivers should lock list accesses with the GEMs _resv lock
+ * (_gem_object.resv).
+ */
+ struct {
+ struct list_head list;
+ } gpuva;
+
/**
* @funcs:
*
I'm pretty sure that it's not a good idea to attach this directly to the
GEM object.
Why do you think so? IMHO having a common way to connect mappings to
their backing buffers is a good thing, since every driver needs this
connection anyway.
E.g. when a BO gets evicted, drivers can just iterate the list of
mappings and, as the circumstances require, invalidate the corresponding
mappings or to unmap all existing mappings of a given buffer.
What would be the advantage to let every driver implement a driver
specific way of keeping this connection? Do you see cases where this
kind of connection between mappings and backing buffers wouldn't be good
enough? If so, which cases do you have in mind? Maybe we can cover them
in a common way as well?
As you wrote in the commit message it's highly driver specific what to
map and where to map it.
In the end the common case should be that in a VA space at least every
mapping being backed by a BO is represented by a struct drm_gpuva.
Instead I suggest to have a separate structure for mappings in a VA
space which driver can then add to their GEM objects or whatever they
want to map into their VMs.
Which kind of separate structure for mappings? Another one analogous to
struct drm_gpuva?
- Danilo
Regards,
Christian.
Re: [PATCH 2/3] drm/rockchip: Resolve dependency in GEM DMA helpers
Hi Thomas, On 2023-06-20 14:03, Thomas Zimmermann wrote: > Remove the dependency on the GEM DMA helper library. Rockchip comes > with its own implementation of the GEM interface. It only uses the VM > callbacks in drm_gem_dma_vm_ops from the GEM DMA helpers. These are > not DMA specific. > > Duplicate drm_gem_dma_vm_ops in rockchip and remove all dependencies on > the GEM DMA helper library. I have intentions to remove the entire custom implementation of the GEM interface and replace it with use of GEM DMA helpers in a future series. Current custom implementation break import of video framebuffers located in memory beyond 4GB. Switching to use pure GEM DMA helpers solved that issue but requires reworking IOMMU integration for full support of multiple VOPs on e.g., RK3288 and RK3399. I have no ETA on when such series can be ready so this is more of a heads up that I will revert this removal of dependency on GEM DMA helper library in a future series. Regards, Jonas > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/rockchip/Kconfig| 1 - > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 ++-- > 3 files changed, 7 insertions(+), 4 deletions(-) > [snip]
Re: [PATCH 00/14] drm/ast: Refactor the device-detection code
On 16/06/2023 15:52, Thomas Zimmermann wrote: Ast's code for detecting the device type and features is convoluted. It mixes up several state fields, chip types and sub-models. Rework the driver into somehting more understandable. Patches 1 fixes a long-standing bug. The affected code has never worked correctly. Patches 2 to 8 make various changes to the init code, or remove dead and duplicated code paths. Patch 9 introduces chip generations. Until now, ast used the value of enum ast_chip to represent a certain set of related modes, and also used the enum to represent individal models. This makes the driver code hard to understand in certain places. The patch encodes a chip generation in each model enum and converts the driver to use it. That's a very good thing, the handling of different AST revisions was a bit messy, and there was bugs when a new one was introduced. Patches 10 to 12 replace duplicated model checks with the correct enum value. Detection of wide-screen functionality and the transmitter chip can then be moved into individual functions in patch 13. Patch 14 merges the detection of the silicon revision and the chip model into s single function. Both need to be done in the same place and affect each other. Tested on AST1100 and AST2300. I've also tested (remotely) on AST2600 For the whole series: Reviewed-by: Jocelyn Falempe Tested-by: Jocelyn Falempe Thomas Zimmermann (14): drm/ast: Fix DRAM init on AST2200 drm/ast: Remove vga2_clone field drm/ast: Implement register helpers in ast_drv.h drm/ast: Remove dead else branch in POST code drm/ast: Remove device POSTing and config from chip detection drm/ast: Set PCI config before accessing I/O registers drm/ast: Enable and unlock device access early during init drm/ast: Set up release action right after enabling MMIO drm/ast: Distinguish among chip generations drm/ast: Detect AST 1300 model drm/ast: Detect AST 1400 model drm/ast: Detect AST 2510 model drm/ast: Move widescreen- and tx-chip detection into separate helpers drm/ast: Merge config and chip detection drivers/gpu/drm/ast/ast_dp501.c | 6 +- drivers/gpu/drm/ast/ast_drv.h | 97 +++--- drivers/gpu/drm/ast/ast_main.c | 320 +++- drivers/gpu/drm/ast/ast_mm.c| 2 - drivers/gpu/drm/ast/ast_mode.c | 35 ++-- drivers/gpu/drm/ast/ast_post.c | 74 ++-- 6 files changed, 294 insertions(+), 240 deletions(-)
Re: [PATCH v2] drm/i915: Replace kmap() with kmap_local_page()
Sumitra Sharma wrote: > On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote: > > Sumitra Sharma wrote: > > > kmap() has been deprecated in favor of the kmap_local_page() > > > due to high cost, restricted mapping space, the overhead of a > > > global lock for synchronization, and making the process sleep > > > in the absence of free slots. > > > > > > kmap_local_page() is faster than kmap() and offers thread-local > > > and CPU-local mappings, take pagefaults in a local kmap region > > > and preserves preemption by saving the mappings of outgoing tasks > > > and restoring those of the incoming one during a context switch. > > > > > > The mapping is kept thread local in the function > > > “i915_vma_coredump_create” in i915_gpu_error.c > > > > > > Therefore, replace kmap() with kmap_local_page(). > > > > > > Suggested-by: Ira Weiny > > > > > > > NIT: No need for the line break between Suggested-by and your signed off > > line. > > > > Hi Ira, > > What does NIT stand for? Shorthand for 'nitpicking'. "giving too much attention to details that are not important, especially as a way of criticizing: " - https://dictionary.cambridge.org/dictionary/english/nitpicking Via email this is a way for authors of an email to indicate something is technically wrong but while nicely acknowledging that it is not very significant and could be seen as overly critical. For this particular comment I'm showing something to pay attention to next time but that was not a big deal this time around. > > Thank you. I will take care about the line breaks. > > > > Signed-off-by: Sumitra Sharma > > > --- > > > > > > Changes in v2: > > > - Replace kmap() with kmap_local_page(). > > > > Generally it is customary to attribute a change like this to those who > > suggested it in a V1 review. > > > > For example: > > > > - Tvrtko/Thomas: Use kmap_local_page() instead of page_address() > > > > Also I don't see Thomas on the new email list. Since he took the time to > > review V1 he might want to check this version out. I've added him to the > > 'To:' list. > > > > Also a link to V1 is nice. B4 formats it like this: > > > > - Link to v1: > > https://lore.kernel.org/all/20230614123556.ga381...@sumitra.com/ > > > > All that said the code looks good to me. So with the above changes. > > > > Reviewed-by: Ira Weiny > > > > I have noted down the points mentioned above. Thank you again. > > I am not supposed to create another version of this patch for > adding the above mentions, as you and Thomas both gave this patch > a reviewed-by tag. Right? > Based on this response[*] from Tvrtko I think this version can move through without a v3. Thanks! Ira [*] https://lore.kernel.org/all/bcb0a1d2-cd4d-a56f-1ee6-7ccfdd2f7...@linux.intel.com/ Thanks all! I'll just re-send the patch for our CI, since it didn't get picked up automatically (stuck in moderation perhaps), with all r-b tags added and extra line space removed and merge it if results will be green. Regards, Tvrtko > > Thanks & regards > Sumitra > > PS: I am new to the open source vocabulary terms. > > > > - Change commit subject and message. > > > > > > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > > > b/drivers/gpu/drm/i915/i915_gpu_error.c > > > index f020c0086fbc..bc41500eedf5 100644 > > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > > > @@ -1164,9 +1164,9 @@ i915_vma_coredump_create(const struct intel_gt *gt, > > > > > > drm_clflush_pages(, 1); > > > > > > - s = kmap(page); > > > + s = kmap_local_page(page); > > > ret = compress_page(compress, s, dst, false); > > > - kunmap(page); > > > + kunmap_local(s); > > > > > > drm_clflush_pages(, 1); > > > > > > -- > > > 2.25.1 > > > > > > >
Re: [PATCH] gpu: drm: Optimize the unused variable ret
On 19/06/2023 13:31, Li Dong wrote:
> Use zero as the return value instead of the unused variable ret
>
> Signed-off-by: Li Dong
> ---
> drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
> b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
> index 102e1fc7ee38..fec0d014fd0e 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
> @@ -66,7 +66,6 @@ static void s6d7aa0_reset(struct s6d7aa0 *ctx)
> static int s6d7aa0_lock(struct s6d7aa0 *ctx, bool lock)
> {
> struct mipi_dsi_device *dsi = ctx->dsi;
> - int ret = 0;
>
> if (lock) {
> mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0xa5, 0xa5);
> @@ -80,7 +79,7 @@ static int s6d7aa0_lock(struct s6d7aa0 *ctx, bool lock)
> mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD3, 0xa5, 0xa5);
> }
>
> - return ret;
> + return 0;
> }
>
> static int s6d7aa0_on(struct s6d7aa0 *ctx)
Commit "drm/panel: s6d7aa0: remove the unneeded variable in
s6d7aa0_lock"[1] already does this.
Best regards
Artur
[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c?id=c5dacfe2e6c1251276e29b4cdac771f504593523
[PATCH v4 2/2] phy: mtk-mipi-csi: add driver for CSI phy
From: Phi-bang Nguyen This is a new driver that supports the MIPI CSI CD-PHY version 0.5 The number of PHYs depend on the SoC. Each PHY can support D-PHY only or CD-PHY configuration. The driver supports only D-PHY mode, so CD-PHY compatible PHY are configured in D-PHY mode. Signed-off-by: Louis Kuo Signed-off-by: Phi-bang Nguyen [Julien Stephan: refactor code] [Julien Stephan: simplify driver model: one instance per phy vs one instance for all phys] Co-developed-by: Julien Stephan Signed-off-by: Julien Stephan --- MAINTAINERS | 1 + drivers/phy/mediatek/Kconfig | 12 + drivers/phy/mediatek/Makefile | 2 + .../mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h| 62 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c | 343 ++ 5 files changed, 420 insertions(+) create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c diff --git a/MAINTAINERS b/MAINTAINERS index 024d67eb7a94..4d9b6c9f6662 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13189,6 +13189,7 @@ M: Julien Stephan M: Andy Hsieh S: Supported F: Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml +F: drivers/phy/mediatek/phy-mtk-mipi-csi-0-5* MEDIATEK MMC/SD/SDIO DRIVER M: Chaotian Jing diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig index 3125ecb5d119..7088382ebc9e 100644 --- a/drivers/phy/mediatek/Kconfig +++ b/drivers/phy/mediatek/Kconfig @@ -74,3 +74,15 @@ config PHY_MTK_DP select GENERIC_PHY help Support DisplayPort PHY for MediaTek SoCs. + +config PHY_MTK_MIPI_CSI_0_5 + tristate "MediaTek MIPI CSI CD-PHY v0.5 Driver" + depends on ARCH_MEDIATEK || COMPILE_TEST + depends on OF + select GENERIC_PHY + help + Enable this to support the MIPI CSI CD-PHY receiver version 0.5. + The driver supports multiple CSI cdphy ports simultaneously. + + To compile this driver as a module, choose M here: the + module will be called phy-mtk-mipi-csi-0-5. diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile index c9a50395533e..63f2fa3ec7e5 100644 --- a/drivers/phy/mediatek/Makefile +++ b/drivers/phy/mediatek/Makefile @@ -19,3 +19,5 @@ phy-mtk-mipi-dsi-drv-y:= phy-mtk-mipi-dsi.o phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o + +obj-$(CONFIG_PHY_MTK_MIPI_CSI_0_5) += phy-mtk-mipi-csi-0-5.o diff --git a/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h new file mode 100644 index ..97b4c27a1699 --- /dev/null +++ b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h @@ -0,0 +1,62 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2023, MediaTek Inc. + * Copyright (c) 2023, BayLibre Inc. + */ + +#ifndef __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__ +#define __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__ + +/* + * CSI1 and CSI2 are identical, and similar to CSI0. All CSIX macros are + * applicable to the three PHYs. Where differences exist, they are denoted by + * macro names using CSI0 and CSI1, the latter being applicable to CSI1 and + * CSI2 alike. + */ + +#define MIPI_RX_ANA00_CSIXA0x +#define RG_CSI0A_CPHY_EN BIT(0) +#define RG_CSIXA_EQ_PROTECT_EN BIT(1) +#define RG_CSIXA_BG_LPF_EN BIT(2) +#define RG_CSIXA_BG_CORE_ENBIT(3) +#define RG_CSIXA_DPHY_L0_CKMODE_EN BIT(5) +#define RG_CSIXA_DPHY_L0_CKSEL BIT(6) +#define RG_CSIXA_DPHY_L1_CKMODE_EN BIT(8) +#define RG_CSIXA_DPHY_L1_CKSEL BIT(9) +#define RG_CSIXA_DPHY_L2_CKMODE_EN BIT(11) +#define RG_CSIXA_DPHY_L2_CKSEL BIT(12) + +#define MIPI_RX_ANA18_CSIXA0x0018 +#define RG_CSI0A_L0_T0AB_EQ_IS GENMASK(5, 4) +#define RG_CSI0A_L0_T0AB_EQ_BW GENMASK(7, 6) +#define RG_CSI0A_L1_T1AB_EQ_IS GENMASK(21, 20) +#define RG_CSI0A_L1_T1AB_EQ_BW GENMASK(23, 22) +#define RG_CSI0A_L2_T1BC_EQ_IS GENMASK(21, 20) +#define RG_CSI0A_L2_T1BC_EQ_BW GENMASK(23, 22) +#define RG_CSI1A_L0_EQ_IS GENMASK(5, 4) +#define RG_CSI1A_L0_EQ_BW GENMASK(7, 6) +#define RG_CSI1A_L1_EQ_IS GENMASK(21, 20) +#define RG_CSI1A_L1_EQ_BW GENMASK(23, 22) +#define RG_CSI1A_L2_EQ_IS GENMASK(5, 4) +#define RG_CSI1A_L2_EQ_BW GENMASK(7, 6) + +#define MIPI_RX_ANA1C_CSIXA0x001c +#define MIPI_RX_ANA20_CSI0A0x0020 + +#define MIPI_RX_ANA24_CSIXA
[PATCH v4 1/2] dt-bindings: phy: add mediatek MIPI CD-PHY module v0.5
From: Florian Sylvestre
This adds the bindings, for the MIPI CD-PHY module v0.5 embedded in
some Mediatek soc, such as the mt8365
Signed-off-by: Florian Sylvestre
Signed-off-by: Julien Stephan
---
.../bindings/phy/mediatek,mt8365-csi-rx.yaml | 79 +++
MAINTAINERS | 6 ++
2 files changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
new file mode 100644
index ..2127a5732f73
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 MediaTek, BayLibre
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,mt8365-csi-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Sensor Interface MIPI CSI CD-PHY
+
+maintainers:
+ - Julien Stephan
+ - Andy Hsieh
+
+description:
+ The SENINF CD-PHY is a set of CD-PHY connected to the SENINF CSI-2
+ receivers. The number of PHYs depends on the SoC model.
+ Depending on the SoC model, each PHYs can be either CD-PHY or D-PHY only
+ capable.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8365-csi-rx
+
+ reg:
+maxItems: 1
+
+ num-lanes:
+enum: [2, 3, 4]
+
+ '#phy-cells':
+enum: [0, 1]
+description: |
+ If the PHY doesn't support mode selection then #phy-cells must be 0 and
+ PHY mode is described using phy-type property.
+ If the PHY supports mode selection, then #phy-cells must be 1 and mode
+ is set in the PHY cells. Supported modes are:
+- PHY_TYPE_DPHY
+- PHY_TYPE_CPHY
+ See include/dt-bindings/phy/phy.h for constants.
+
+ phy-type:
+description:
+ If the PHY doesn't support mode selection then this set the operating
mode.
+ See include/dt-bindings/phy/phy.h for constants.
+const: 10
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - num-lanes
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ csi0_rx: phy@11c1 {
+compatible = "mediatek,mt8365-csi-rx";
+reg = <0 0x11c1 0 0x2000>;
+num-lanes = <2>;
+#phy-cells = <1>;
+ };
+
+ csi1_rx: phy@11c12000 {
+compatible = "mediatek,mt8365-csi-rx";
+reg = <0 0x11c12000 0 0x2000>;
+phy-type = ;
+num-lanes = <2>;
+#phy-cells = <0>;
+ };
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 45fc831f1654..024d67eb7a94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13184,6 +13184,12 @@ F:
Documentation/devicetree/bindings/media/mediatek-vpu.txt
F: drivers/media/platform/mediatek/vcodec/
F: drivers/media/platform/mediatek/vpu/
+MEDIATEK MIPI-CSI CDPHY DRIVER
+M: Julien Stephan
+M: Andy Hsieh
+S: Supported
+F: Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
+
MEDIATEK MMC/SD/SDIO DRIVER
M: Chaotian Jing
S: Maintained
--
2.41.0
[PATCH v4 0/3] phy: mtk-mipi-csi: add driver for CSI phy
Adding a new driver for the MIPI CSI CD-PHY module v 0.5 embedded in some Mediatek soc, such as the MT8365 This driver was adapted from https://patchwork.kernel.org/project/linux-mediatek/cover/20200708104023.3225-1-louis@mediatek.com/ v1 can be found here: https://lore.kernel.org/all/20230403071929.360911-1-jstep...@baylibre.com/ v2 can be found here: https://lore.kernel.org/all/20230515090551.1251389-1-jstep...@baylibre.com/ v3 can be found here: https://lore.kernel.org/all/20230524083033.486490-1-jstep...@baylibre.com/ Changelog Changes in v4: include/dt-bindings/phy/phy.h: - remove commit adding PHY_TYPE_CDPHY definition Binding file: - use the standard phy-type property instead of a custom one so rename mediatek,phy-type -> phy-type - phy-type property is made optional: when present, describes the phy type and the operating mode - phy-cell is modified to accept a phy argument representing the phy operating mode if phy-type is not specified - adding new property num-lanes Driver: - add a custom xlate function to handle phy cells - update probe function to retrieve the new value phy-type instead of the mediatek,phy-type - remove useless struct define `struct mtk_mipi_dphy;` - rename some functin/variable from `xx_dphy_xx` to `xx_cdphy_xx` - update probe function to read num-lanes property Changes in v3: Binding file: - rename compatible string mediatek,phy-mipi-csi-0-5 -> mediatek,mt8365-csi-rx - rename binding file to be as compatible string - change property mediatek,is_cdphy -> mediatek,phy-type using an enum value instead of boolean for scalability - remove status property from example nodes - rename example node name 'mipi_rx_csi0: mipi_rx_csi0@11c1' -> 'csi0_rx: phy@11c1' - put reg address in lower case include/dt-bindings/phy/phy.h: - add PHY_TYPE_CDPHY definition Driver: - rename compatible string - rename property mediatek,is_cdphy -> mediatek,phy-type - rename CSIx* macro to CSIX* (x -> X) - fix style issue on the driver data structure - update MODULE_DESCRIPTION as suggested by Angelo and update the kconfig module description to match it - add dphy /cdphy eq tuning function to factor the code and increase readability - fix typo __PHY_MTK__MIPI_CSI__C_0_5_RX_REG_H_ --> __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H_ - reword commit message to update my contributions - added missing copyright - added module name in Kconfig Changes in v2: - fix all comments on bindings - move the binding chunk from driver to binding commit - fix dt_binding_check error (reported by DT_CHECKER_FLAGS) - use a more generic compatible string - add a new dt properties to simplify the driver "mediatek,is_cdphy" - rename the driver and the corresponding file to include version - drop of_match_ptr() - use devm_platform_ioremap_resource - use phy-mtk-io.h api instead of regmap - rework the driver to use dt nodes to declare PHY instead of an array in the driver - remove useless define for unused registers - remove support for CSI0A/B because it cannot be tested, and it simplifies the driver for a first review - edit commit message and bindings to be more descriptive about the hardware Florian Sylvestre (1): dt-bindings: phy: add mediatek MIPI CD-PHY module v0.5 Julien Stephan (1): phy use phy-type Phi-bang Nguyen (1): phy: mtk-mipi-csi: add driver for CSI phy .../bindings/phy/mediatek,mt8365-csi-rx.yaml | 73 MAINTAINERS | 7 + drivers/phy/mediatek/Kconfig | 12 + drivers/phy/mediatek/Makefile | 2 + .../mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h| 62 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c | 331 ++ 6 files changed, 487 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c -- 2.41.0
[PATCH 3/3] drm/gem-dma: Unexport drm_gem_dma_vm_ops
There are no external users of drm_gem_dma_vm_ops. Unexport the symbol.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_dma_helper.c | 11 +--
include/drm/drm_gem_dma_helper.h | 2 --
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index e9aa3ac140654..d8a415c3d156c 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -45,6 +45,11 @@
* drm_gem_dma_vmap()). These helpers perform the necessary type conversion.
*/
+static const struct vm_operations_struct drm_gem_dma_vm_ops = {
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
static const struct drm_gem_object_funcs drm_gem_dma_default_funcs = {
.free = drm_gem_dma_object_free,
.print_info = drm_gem_dma_object_print_info,
@@ -315,12 +320,6 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
}
EXPORT_SYMBOL_GPL(drm_gem_dma_dumb_create);
-const struct vm_operations_struct drm_gem_dma_vm_ops = {
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-EXPORT_SYMBOL_GPL(drm_gem_dma_vm_ops);
-
#ifndef CONFIG_MMU
/**
* drm_gem_dma_get_unmapped_area - propose address for mapping in noMMU cases
diff --git a/include/drm/drm_gem_dma_helper.h b/include/drm/drm_gem_dma_helper.h
index 3877cbf0e927c..88a810f954fce 100644
--- a/include/drm/drm_gem_dma_helper.h
+++ b/include/drm/drm_gem_dma_helper.h
@@ -45,8 +45,6 @@ int drm_gem_dma_vmap(struct drm_gem_dma_object *dma_obj,
struct iosys_map *map);
int drm_gem_dma_mmap(struct drm_gem_dma_object *dma_obj, struct vm_area_struct
*vma);
-extern const struct vm_operations_struct drm_gem_dma_vm_ops;
-
/*
* GEM object functions
*/
--
2.41.0
[PATCH 1/3] drm/rcar-du: Import buffers with GEM DMA's helpers
Call __drm_gem_dma_create() to create an object for imported buffers,
instead of reimplementing the function within the driver. Reduces
code duplication and will later allow to un-export a number of symbols
from the GEM DMA helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_dma_helper.c | 5 +--
drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 33 +++
include/drm/drm_gem_dma_helper.h | 3 ++
3 files changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index 870b90b78bc4e..e9aa3ac140654 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -67,8 +67,8 @@ static const struct drm_gem_object_funcs
drm_gem_dma_default_funcs = {
* A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
* error code on failure.
*/
-static struct drm_gem_dma_object *
-__drm_gem_dma_create(struct drm_device *drm, size_t size, bool private)
+struct drm_gem_dma_object *__drm_gem_dma_create(struct drm_device *drm,
+ size_t size, bool private)
{
struct drm_gem_dma_object *dma_obj;
struct drm_gem_object *gem_obj;
@@ -112,6 +112,7 @@ __drm_gem_dma_create(struct drm_device *drm, size_t size,
bool private)
kfree(dma_obj);
return ERR_PTR(ret);
}
+EXPORT_SYMBOL_GPL(__drm_gem_dma_create);
/**
* drm_gem_dma_create - allocate an object with the given size
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
index adfb36b0e8154..ea7487e270f13 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
@@ -356,49 +356,24 @@ const struct rcar_du_format_info *rcar_du_format_info(u32
fourcc)
* Frame buffer
*/
-static const struct drm_gem_object_funcs rcar_du_gem_funcs = {
- .free = drm_gem_dma_object_free,
- .print_info = drm_gem_dma_object_print_info,
- .get_sg_table = drm_gem_dma_object_get_sg_table,
- .vmap = drm_gem_dma_object_vmap,
- .mmap = drm_gem_dma_object_mmap,
- .vm_ops = _gem_dma_vm_ops,
-};
-
struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt)
{
struct rcar_du_device *rcdu = to_rcar_du_device(dev);
struct drm_gem_dma_object *dma_obj;
- struct drm_gem_object *gem_obj;
- int ret;
if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
return drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
- /* Create a DMA GEM buffer. */
- dma_obj = kzalloc(sizeof(*dma_obj), GFP_KERNEL);
- if (!dma_obj)
- return ERR_PTR(-ENOMEM);
-
- gem_obj = _obj->base;
- gem_obj->funcs = _du_gem_funcs;
-
- drm_gem_private_object_init(dev, gem_obj, attach->dmabuf->size);
- dma_obj->map_noncoherent = false;
-
- ret = drm_gem_create_mmap_offset(gem_obj);
- if (ret) {
- drm_gem_object_release(gem_obj);
- kfree(dma_obj);
- return ERR_PTR(ret);
- }
+ dma_obj = __drm_gem_dma_create(dev, attach->dmabuf->size, true);
+ if (IS_ERR(dma_obj))
+ return ERR_CAST(dma_obj);
dma_obj->dma_addr = 0;
dma_obj->sgt = sgt;
- return gem_obj;
+ return _obj->base;
}
int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
diff --git a/include/drm/drm_gem_dma_helper.h b/include/drm/drm_gem_dma_helper.h
index 61da596780b64..3877cbf0e927c 100644
--- a/include/drm/drm_gem_dma_helper.h
+++ b/include/drm/drm_gem_dma_helper.h
@@ -32,6 +32,9 @@ struct drm_gem_dma_object {
#define to_drm_gem_dma_obj(gem_obj) \
container_of(gem_obj, struct drm_gem_dma_object, base)
+struct drm_gem_dma_object *__drm_gem_dma_create(struct drm_device *drm,
+ size_t size, bool private);
+
struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
size_t size);
void drm_gem_dma_free(struct drm_gem_dma_object *dma_obj);
--
2.41.0
[PATCH 2/3] drm/rockchip: Resolve dependency in GEM DMA helpers
Remove the dependency on the GEM DMA helper library. Rockchip comes
with its own implementation of the GEM interface. It only uses the VM
callbacks in drm_gem_dma_vm_ops from the GEM DMA helpers. These are
not DMA specific.
Duplicate drm_gem_dma_vm_ops in rockchip and remove all dependencies on
the GEM DMA helper library.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/rockchip/Kconfig| 1 -
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 ++--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 1bf3e2829cd07..5f49cd0210e6b 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -2,7 +2,6 @@
config DRM_ROCKCHIP
tristate "DRM Support for Rockchip"
depends on DRM && ROCKCHIP_IOMMU
- select DRM_GEM_DMA_HELPER
select DRM_KMS_HELPER
select DRM_PANEL
select VIDEOMODE_HELPERS
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index b8cf89f0cc566..b090b8abb6637 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -18,7 +18,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b8f8b45ebf594..acb6f122a2dca 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -11,13 +11,17 @@
#include
#include
#include
-#include
#include
#include
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
+static const struct vm_operations_struct rockchip_gem_vm_ops = {
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
{
struct drm_device *drm = rk_obj->base.dev;
@@ -276,7 +280,7 @@ static const struct drm_gem_object_funcs
rockchip_gem_object_funcs = {
.vmap = rockchip_gem_prime_vmap,
.vunmap = rockchip_gem_prime_vunmap,
.mmap = rockchip_drm_gem_object_mmap,
- .vm_ops = _gem_dma_vm_ops,
+ .vm_ops = _gem_vm_ops,
};
static struct rockchip_gem_object *
--
2.41.0
[PATCH 0/3] drm/gem-dma: Remove unnecessary calls
Remove rockchip's dependency on GEM DMA helpers. Rework the GEM DMA interface to fit the needs of rcar-du. This intends to be a cleanup with no functional changes. With the patches merged, a later patchset can attempt to generate some of the boiler-plate code for struct drm_gem_object_funcs automatically. Thomas Zimmermann (3): drm/rcar-du: Import buffers with GEM DMA's helpers drm/rockchip: Resolve dependency in GEM DMA helpers drm/gem-dma: Unexport drm_gem_dma_vm_ops drivers/gpu/drm/drm_gem_dma_helper.c | 16 - drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 33 +++ drivers/gpu/drm/rockchip/Kconfig | 1 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 +++-- include/drm/drm_gem_dma_helper.h | 5 +-- 6 files changed, 22 insertions(+), 43 deletions(-) base-commit: 32e260cd0d16cee6f33e747679f168d63ea54bf6 -- 2.41.0
Re: [PATCH v2] drm/msm/dsi: Document DSC related pclk_rate and hdisplay calculations
On 2023-06-20 00:06:47, Dmitry Baryshkov wrote:
> Provide actual documentation for the pclk and hdisplay calculations in
> the case of DSC compression being used.
>
> Signed-off-by: Dmitry Baryshkov
> ---
>
> Changes since v1:
> - Converted dsi_adjust_pclk_for_compression() into kerneldoc (Marijn)
> - Added a pointer from dsi_timing_setup() docs to
> dsi_adjust_pclk_for_compression() (Marijn)
> - Fixed two typo (Marijn)
>
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 40 --
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 3f6dfb4f9d5a..a8a31c3dd168 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -528,6 +528,25 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host
> *msm_host)
> clk_disable_unprepare(msm_host->byte_clk);
> }
>
> +/**
> + * dsi_adjust_pclk_for_compression() - Adjust the pclk rate for compression
> case
> + * @mode: the selected mode for the DSI output
The
> + * @dsc: DRM DSC configuration for this DSI output
> + *
> + * Adjust the pclk rate by calculating a new hdisplay proportional to
> + * the compression ratio such that:
> + * new_hdisplay = old_hdisplay * compressed_bpp / uncompressed_bpp
And in v1 you explained that it is _not_ about bpp...
> + *
> + * Porches do not need to be adjusted:
> + * - For the VIDEO mode they are not compressed by DSC and are passed as is.
> + * - For the CMD mode there are no actual porches. Instead these fields
I feel like "For VIDEO mode" and "For CMD mode" reads more naturally, no
need for "the", but I don't know the grammar rule that states so.
> + * currently represent the overhead to the image data transfer. As such,
> they
> + * are calculated for the final mode parameters (after the compression) and
> + * are not to be adjusted too.
> + *
> + * FIXME: Reconsider this if/when CMD mode handling is rewritten to use
> + * refresh rate and data overhead as a starting point of the calculations.
Nit: well, refresh rate is already part of this calculation (that's how
drm_display_mode's clock member comes to be, and how drm_mode_vrefresh()
figures out fps after the fact). It's all about the per-CMD transfer
overhead in bytes that is currently not part of the calculation.
> + */
> static unsigned long dsi_adjust_pclk_for_compression(const struct
> drm_display_mode *mode,
> const struct drm_dsc_config *dsc)
> {
> @@ -926,8 +945,25 @@ static void dsi_timing_setup(struct msm_dsi_host
> *msm_host, bool is_bonded_dsi)
> if (ret)
> return;
>
> - /* Divide the display by 3 but keep back/font porch and
> - * pulse width same
> + /*
> + * DPU sends 3 bytes per pclk cycle to DSI. If compression is
Should this be pixels (1 pixel), not bytes, just like in the compressed
scenario?
> + * not used, a single pixel is transferred at each pulse, no
> + * matter what bpp or pixel format is used. In case of DSC
> + * compression this results (due to data alignment
> + * requirements) in a transfer of 3 compressed pixel per pclk
> + * cycle.
> + *
> + * If widebus is enabled, bus width is extended to 6 bytes.
> + * This way the DPU can transfer 6 compressed pixels with bpp
> + * less or equal to 8 or 3 compressed pixels in case bpp is
> + * greater than 8.
Okay, so one can not send more than 6 pixels even if the bpp is less
than 8, is what this comes down to.
> + *
> + * The back/font porch and pulse width are kept intact. They
> + * represent timing parameters rather than actual data
> + * transfer. See the documentation of
> + * dsi_adjust_pclk_for_compression().
Nit: note that this is only for VIDEO mode, h_total and ha_end are
accurately unused in the CMDmode path below.
- Marijn
> + *
> + * XXX: widebus is not supported by the driver (yet).
>*/
> h_total -= hdisplay;
> hdisplay =
> DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->dsc), 3);
> --
> 2.39.2
>
Re: [PATCH v2] PCI: Add dummy implement for pci_clear_master() function
On Tue, Jun 20, 2023 at 06:06:00AM -0500, Bjorn Helgaas wrote: > On Tue, Jun 20, 2023 at 12:04:40PM +0800, Sui Jingfeng wrote: > > Where is the formal(unstream) PCI git branch where we could see the latest > > patch ? > > Here's the "misc" branch: > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=misc > > And here's the "next" branch that will be merged for v6.5, which > includes "misc" and other things: > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=next I forgot to mention: in case you need to find other git branches, most subsystems list this in the MAINTAINERS file, e.g., PCI SUBSYSTEM ... T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
[PATCH v2 2/2] drm/msm/dsi: Enable runtime PM
Some devices power the DSI PHY/PLL through a power rail that we model as a GENPD. Enable runtime PM to make it suspendable. Signed-off-by: Konrad Dybcio --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c index 2f319e0eb74f..22431e106529 100644 --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -689,6 +689,10 @@ static int dsi_phy_driver_probe(struct platform_device *pdev) return dev_err_probe(dev, PTR_ERR(phy->ahb_clk), "Unable to get ahb clk\n"); + ret = devm_pm_runtime_enable(>dev); + if (ret) + return ret; + /* PLL init will call into clk_register which requires * register access, so we need to enable power and ahb clock. */ -- 2.41.0
[PATCH v2 1/2] drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks
This helper has been introduced to avoid programmer errors (missing
_put calls leading to dangling refcnt) when using pm_runtime_get, use it.
While at it, start checking the return value.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 9d5795c58a98..2f319e0eb74f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -516,7 +516,9 @@ static int dsi_phy_enable_resource(struct msm_dsi_phy *phy)
struct device *dev = >pdev->dev;
int ret;
- pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret)
+ return ret;
ret = clk_prepare_enable(phy->ahb_clk);
if (ret) {
--
2.41.0
