date:20230529


Hi,

On 2023/5/30 03:36, Sam Ravnborg wrote:

Hi Thomas,

On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:

Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.

i915's fbdev emulation is still incomplete as it doesn't implement
deferred I/O and damage handling for mmaped pages.

v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_IO_HELPERS options

Signed-off-by: Thomas Zimmermann 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: "Ville Syrjälä" 
---
  drivers/gpu/drm/Kconfig|   3 -
  drivers/gpu/drm/drm_fb_helper.c| 107 -
  drivers/gpu/drm/i915/Kconfig   |   1 +
  drivers/gpu/drm/i915/display/intel_fbdev.c |  14 +--
  include/drm/drm_fb_helper.h|  39 
  5 files changed, 9 insertions(+), 155 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 92a782827b7b..bb2e48cc6cd6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -133,9 +133,6 @@ config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPER
depends on FB=y || FB=DRM_KMS_HELPER
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bab6b252f02a..9978147bbc8a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
struct list_head *pagerefli
  }
  EXPORT_SYMBOL(drm_fb_helper_deferred_io);
  
-/**

- * drm_fb_helper_cfb_read - Implements struct _ops.fb_read for I/O memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_cfb_read(struct fb_info *info, char __user *buf,
-  size_t count, loff_t *ppos)
-{
-   return fb_io_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_cfb_read);
-
-/**
- * drm_fb_helper_cfb_write - Implements struct _ops.fb_write for I/O memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_cfb_write(struct fb_info *info, const char __user *buf,
-   size_t count, loff_t *ppos)
-{
-   struct drm_fb_helper *helper = info->par;
-   loff_t pos = *ppos;
-   ssize_t ret;
-   struct drm_rect damage_area;
-
-   ret = fb_io_write(info, buf, count, ppos);
-   if (ret <= 0)
-   return ret;
-
-   if (helper->funcs->fb_dirty) {
-   drm_fb_helper_memory_range_to_clip(info, pos, ret, 
_area);
-   drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
-drm_rect_width(_area),
-drm_rect_height(_area));
-   }

The generated helpers do not have the if (helper->funcs->fb_dirty)
check.


Nice catch!

If I understand this correctly, fb_io_write() will write directly to the 
ultimate


destination. There no need to check if (helper->funcs->fb_dirty) anymore.

code inside the curly brace of  `if (helper->funcs->fb_dirty) { }`  can 
be delete safely .



This could turn out to be an optimization. This is a benefit of 
untangled implement.


previously this is a generic (tangled) implement, which intended to be 
used by both


the UMA device driver and non-UMA device(with dedicate VRAM) driver.


drm_fbdev_generic always has a shadow screen buffer allocated in system RAM,

 it always has the fb_dirty hooked, so this could be an optimization 
for fbdev_generic


by eliminate if (helper->funcs->fb_dirty) check.


while dma helper based driver could switch to drm_fbdev_dma, they writing

to gem buffer directly, no shadow buffer is needed.


With those patch, device driver with dedicated video memory can also 
choose FB_CFB_*


to update (iomem)framebuffer directly, despite slower.



Is this implemented somewhere else that I missed?

Sam


drm_fb_helper_fb_dirty() function has a check:

```

    if (drm_WARN_ON_ONCE(dev, !helper->funcs->fb_dirty))

[PATCH 9/9] 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 
--
v1->v2:
  - check wbrf support using pmfw version(Lijo)
v2->v3:
  - some minor fixes(Mario)
---
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  | 61 +++
 1 file changed, 61 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..d885f20e33d7 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,59 @@ 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;
+   uint64_t start_rounddown;
+   uint64_t end_roundup;
+   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;
+
+   start_rounddown = rounddown(exclusion_ranges[i].start, 
HZ_IN_MHZ);
+   end_roundup = roundup(exclusion_ranges[i].end, HZ_IN_MHZ);
+   /* PMFW expects the inputs to be in Mhz unit */
+   wifi_bands.WifiBandEntry[valid_entries].LowFreq = 
HZ_TO_MHZ(start_rounddown);
+   wifi_bands.WifiBandEntry[valid_entries++].HighFreq = 
HZ_TO_MHZ(end_roundup);
+   }
+   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 +1844,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,
+

[PATCH 8/9] 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 
--
v1->v2:
  - check the wbrf support using pmfw version(Lijo)
v2->v3:
  - some minor fixes(Mario)
---
 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  4 ++
 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  | 62 +++
 5 files changed, 80 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..b71df196d047 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,9 @@ enum smu_baco_seq {
 __dst_size);  \
 })
 
+#define HZ_IN_MHZ  100UL
+#define HZ_TO_MHZ(freq)((freq) / HZ_IN_MHZ)
+
 #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..c617046cb893 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

[PATCH 7/9] drm/amd/pm: add flood detection for wbrf events

To protect PMFW from being overloaded.

Signed-off-by: Evan Quan 
--
v1->v2:
  - utilize the delayed work(Lijo, Christian)
  - split the new module parameter changes out(Christian, Alex)
v2->v3:
  - simplify the flood detection further per latest design
v3->v4:
  - drop unneeded wbrf_mutex(Lijo, Christian)
  - use schedule_delayed_work() to avoid possible concurrent
access(Chrisitan)
---
 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 89f876cc60e6..2619e310ef54 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 6/9] 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 
--
v1->v2:
  - move the implementations to swsmu(Lijo)
  - support runpm suspend/resume scenario(Lijo)
  - add missing mutex_destory(Mario)
v2->v3:
  - Per the latest designs, get those ACPI interfaces
needed by consumer(VGA) implemented in amdgpu_smu.c
v3->v4:
  - update the descriptions for parameter 'wbrf'(Alex)
v4->v5:
  - support CONFIG_ACPI_WBRF disabled scenario
  - correct the default setting for parameter `wbrf` as -1 (auto)(Alex)
v5->v6:
  - separate those ACPI related code into amdgpu_acpi.c
and acpi_wbrf.c
v6->v7:
  - wrap the document and modinfo for `wbrf` under
CONFIG_ACPI_WBRF(Mario)
v7->v8:
  - some minor fixes around error/information prompts(Mario)
---
 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 =

[PATCH 5/9] 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 
--
v1->v2:
  - update smu_v13_0_7_ppsmc.h to fit latest messages definitions
---
 .../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 4/9] wifi: ath12k: Add support to the Qualcomm ath12k for ACPI WBRF

Qualcomm wifi adapters are utilized in systems that support AMD's WBRF
interference mitigation mechanism. For this mechanism to work frequencies
utilized use must be notified to an ACPI device.

If the kernel is configured with CONFIG_ACPI_WBRF then notify this ACPI
device accordingly.

Change based on code review, not tested due to lack of hardware.

Signed-off-by: Evan Quan 
---
v1->v2:
  - drop unnecessary EXPORT_SYMBOL_GPL(Mario)
---
 drivers/net/wireless/ath/ath12k/core.c | 21 +
 drivers/net/wireless/ath/ath12k/core.h | 14 ++
 drivers/net/wireless/ath/ath12k/mac.c  |  4 
 drivers/net/wireless/ath/ath12k/pci.c  |  3 +++
 4 files changed, 42 insertions(+)

diff --git a/drivers/net/wireless/ath/ath12k/core.c 
b/drivers/net/wireless/ath/ath12k/core.c
index a89e66653f04..fde811524756 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -14,6 +14,7 @@
 #include "dp_rx.h"
 #include "debug.h"
 #include "hif.h"
+#include "../ath.h"
 
 unsigned int ath12k_debug_mask;
 module_param_named(debug_mask, ath12k_debug_mask, uint, 0644);
@@ -935,5 +936,25 @@ struct ath12k_base *ath12k_core_alloc(struct device *dev, 
size_t priv_size,
return NULL;
 }
 
+#if defined(CONFIG_ACPI_WBRF)
+int ath12k_add_wbrf(struct ath12k_base *ab,
+   struct cfg80211_chan_def *chandef)
+{
+   if (!ab->wbrf)
+   return 0;
+
+   return ath_add_wbrf(ab->dev, chandef);
+}
+
+int ath12k_remove_wbrf(struct ath12k_base *ab,
+  struct cfg80211_chan_def *chandef)
+{
+   if (!ab->wbrf)
+   return 0;
+
+   return ath_remove_wbrf(ab->dev, chandef);
+}
+#endif
+
 MODULE_DESCRIPTION("Core module for Qualcomm Atheros 802.11be wireless LAN 
cards.");
 MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/wireless/ath/ath12k/core.h 
b/drivers/net/wireless/ath/ath12k/core.h
index 9439052a652e..53ffb679b5c1 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -736,6 +736,8 @@ struct ath12k_base {
u64 fw_soc_drop_count;
bool static_window_map;
 
+   bool wbrf;
+
/* must be last */
u8 drv_priv[] __aligned(sizeof(void *));
 };
@@ -820,4 +822,16 @@ static inline const char *ath12k_bus_str(enum ath12k_bus 
bus)
return "unknown";
 }
 
+#ifdef CONFIG_ACPI_WBRF
+int ath12k_add_wbrf(struct ath12k_base *ab, struct cfg80211_chan_def *chandef);
+int ath12k_remove_wbrf(struct ath12k_base *ab, struct cfg80211_chan_def 
*chandef);
+#else
+static inline
+int ath12k_add_wbrf(struct ath12k_base *ab,
+   struct cfg80211_chan_def *chandef) { return 0; }
+static inline
+int ath12k_remove_wbrf(struct ath12k_base *ab0,
+  struct cfg80211_chan_def *chandef) { return 0; }
+#endif /* CONFIG_ACPI_WBRF */
+
 #endif /* _CORE_H_ */
diff --git a/drivers/net/wireless/ath/ath12k/mac.c 
b/drivers/net/wireless/ath/ath12k/mac.c
index ee792822b411..999354d60228 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -5396,6 +5396,8 @@ static int ath12k_mac_op_add_chanctx(struct ieee80211_hw 
*hw,
 
mutex_lock(>conf_mutex);
 
+   ath12k_add_wbrf(ab, >def);
+
spin_lock_bh(>data_lock);
/* TODO: In case of multiple channel context, populate rx_channel from
 * Rx PPDU desc information.
@@ -5420,6 +5422,8 @@ static void ath12k_mac_op_remove_chanctx(struct 
ieee80211_hw *hw,
 
mutex_lock(>conf_mutex);
 
+   ath12k_remove_wbrf(ab, >def);
+
spin_lock_bh(>data_lock);
/* TODO: In case of there is one more channel context left, populate
 * rx_channel with the channel of that remaining channel context.
diff --git a/drivers/net/wireless/ath/ath12k/pci.c 
b/drivers/net/wireless/ath/ath12k/pci.c
index 9f174daf324c..544d93d66d69 100644
--- a/drivers/net/wireless/ath/ath12k/pci.c
+++ b/drivers/net/wireless/ath/ath12k/pci.c
@@ -13,6 +13,7 @@
 #include "hif.h"
 #include "mhi.h"
 #include "debug.h"
+#include "../ath.h"
 
 #define ATH12K_PCI_BAR_NUM 0
 #define ATH12K_PCI_DMA_MASK32
@@ -1272,6 +1273,8 @@ static int ath12k_pci_probe(struct pci_dev *pdev,
goto err_ce_free;
}
 
+   ab->wbrf = ath_check_wbrf_support(ab->dev);
+
ret = ath12k_core_init(ab);
if (ret) {
ath12k_err(ab, "failed to init core: %d\n", ret);
-- 
2.34.1

[PATCH 3/9] wifi: ath11k: Add support to the Qualcomm ath11k for ACPI WBRF

From: Anson Tsao 

Qualcomm wifi adapters are utilized in systems that support AMD's WBRF
interference mitigation mechanism. For this mechanism to work frequencies
utilized use must be notified to an ACPI device.

If the kernel is configured with CONFIG_ACPI_WBRF then notify this ACPI
device accordingly.

Tested-on: WCN6855 hw2.0 PCI 
WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23

Signed-off-by: Anson Tsao 
Signed-off-by: Evan Quan 
Co-developed-by: Evan Quan 
--
v1->v2:
  - Fix possible NULL pointer dereference caused by ar->hw->conf.chandef.chan
v2->v3:
  - correct the timing for `ath11k_add_wbrf` and `ath11k_remove_wbrf`
calling
---
 drivers/net/wireless/ath/Makefile  |  1 +
 drivers/net/wireless/ath/acpi_wbrf.c   | 45 ++
 drivers/net/wireless/ath/ath.h | 15 +
 drivers/net/wireless/ath/ath11k/core.c | 23 +
 drivers/net/wireless/ath/ath11k/core.h | 14 
 drivers/net/wireless/ath/ath11k/mac.c  |  4 +++
 drivers/net/wireless/ath/ath11k/pci.c  |  3 ++
 7 files changed, 105 insertions(+)
 create mode 100644 drivers/net/wireless/ath/acpi_wbrf.c

diff --git a/drivers/net/wireless/ath/Makefile 
b/drivers/net/wireless/ath/Makefile
index 8d6e6e218d24..234e904bdfa9 100644
--- a/drivers/net/wireless/ath/Makefile
+++ b/drivers/net/wireless/ath/Makefile
@@ -21,5 +21,6 @@ ath-objs :=   main.o \
 
 ath-$(CONFIG_ATH_DEBUG) += debug.o
 ath-$(CONFIG_ATH_TRACEPOINTS) += trace.o
+ath-$(CONFIG_ACPI_WBRF) += acpi_wbrf.o
 
 CFLAGS_trace.o := -I$(src)
diff --git a/drivers/net/wireless/ath/acpi_wbrf.c 
b/drivers/net/wireless/ath/acpi_wbrf.c
new file mode 100644
index ..98b3416eca4d
--- /dev/null
+++ b/drivers/net/wireless/ath/acpi_wbrf.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: ISC
+/* Copyright (C) 2023 Advanced Micro Devices */
+
+#include 
+#include "ath.h"
+
+bool ath_check_wbrf_support(struct device *dev)
+{
+   struct acpi_device *acpi_dev = ACPI_COMPANION(dev);
+   bool wbrf_supported;
+
+   if (!acpi_dev) {
+   dev_dbg(dev, "ACPI companion not found\n");
+   return false;
+   }
+
+   wbrf_supported = wbrf_supported_producer(acpi_dev);
+   dev_dbg(dev, "WBRF is %s supported\n",
+   wbrf_supported ? "" : "not");
+
+   return wbrf_supported;
+}
+EXPORT_SYMBOL_GPL(ath_check_wbrf_support);
+
+int ath_add_wbrf(struct device *dev, struct cfg80211_chan_def *chandef)
+{
+   struct acpi_device *acpi_dev = ACPI_COMPANION(dev);
+
+   if (!acpi_dev)
+   return -ENODEV;
+
+   return wbrf_add_exclusion_wlan(acpi_dev, chandef);
+}
+EXPORT_SYMBOL_GPL(ath_add_wbrf);
+
+int ath_remove_wbrf(struct device *dev, struct cfg80211_chan_def *chandef)
+{
+   struct acpi_device *acpi_dev = ACPI_COMPANION(dev);
+
+   if (!acpi_dev)
+   return -ENODEV;
+
+   return wbrf_remove_exclusion_wlan(acpi_dev, chandef);
+}
+EXPORT_SYMBOL_GPL(ath_remove_wbrf);
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index f02a308a9ffc..c9f5c9a67c0a 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -334,4 +334,19 @@ static inline const char *ath_bus_type_to_string(enum 
ath_bus_type bustype)
return ath_bus_type_strings[bustype];
 }
 
+#ifdef CONFIG_ACPI_WBRF
+bool ath_check_wbrf_support(struct device *dev);
+int ath_add_wbrf(struct device *dev, struct cfg80211_chan_def *chandef);
+int ath_remove_wbrf(struct device *dev, struct cfg80211_chan_def *chandef);
+#else
+static inline
+bool ath_check_wbrf_support(struct device *dev) { return false; }
+static inline
+int ath_add_wbrf(struct device *dev,
+struct cfg80211_chan_def *chandef) { return 0; }
+static inline
+int ath_remove_wbrf(struct device *dev,
+   struct cfg80211_chan_def *chandef) { return 0; }
+#endif
+
 #endif /* ATH_H */
diff --git a/drivers/net/wireless/ath/ath11k/core.c 
b/drivers/net/wireless/ath/ath11k/core.c
index b1b90bd34d67..1f1eed9c8ae7 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -16,6 +16,7 @@
 #include "debug.h"
 #include "hif.h"
 #include "wow.h"
+#include "../ath.h"
 
 unsigned int ath11k_debug_mask;
 EXPORT_SYMBOL(ath11k_debug_mask);
@@ -2035,5 +2036,27 @@ struct ath11k_base *ath11k_core_alloc(struct device 
*dev, size_t priv_size,
 }
 EXPORT_SYMBOL(ath11k_core_alloc);
 
+#if defined(CONFIG_ACPI_WBRF)
+int ath11k_add_wbrf(struct ath11k_base *ab,
+   struct cfg80211_chan_def *chandef)
+{
+   if (!ab->wbrf)
+   return 0;
+
+   return ath_add_wbrf(ab->dev, chandef);
+}
+EXPORT_SYMBOL_GPL(ath11k_add_wbrf);
+
+int ath11k_remove_wbrf(struct ath11k_base *ab,
+  struct cfg80211_chan_def *chandef)
+{
+   if (!ab->wbrf)
+   return 0;
+
+   return ath_remove_wbrf(ab->dev, chandef);
+}
+EXPORT_SYMBOL_GPL(ath11k_remove_wbrf);
+#endif
+
 MODULE_DESCRIPTION("Core module for

[PATCH 2/9] mt76: Add support to the Mediatek MT7921 for ACPI WBRF

From: Mario Limonciello 

Mediatek wifi adapters are utilized in systems that support AMD's WBRF
interference mitigation mechanism. For this mechanism to work frequencies
utilized use must be notified to an ACPI device.

If the kernel is configured with CONFIG_ACPI_WBRF then notify this ACPI
device accordingly.

Signed-off-by: Mario Limonciello 
Signed-off-by: Anson Taso 
Co-developed-by: Anson Taso 
--
v1->v2:
  - Fix build errors below for mt76 w/ WBRF enabled
ERROR: modpost: "mt76_add_wbrf" 
[drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2e.ko] undefined!
ERROR: modpost: "mt76_remove_wbrf" 
[drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2e.ko] undefined!
ERROR: modpost: "mt76_init_acpi_wbrf" 
[drivers/net/wireless/mediatek/mt76/mt7921/mt7921-common.ko] undefined!
v2->v3:
  - add support to the real driver(mt7921/main.c) which supports
Mediatek MT7921
---
 drivers/net/wireless/mediatek/mt76/Makefile   |  1 +
 .../net/wireless/mediatek/mt76/acpi_wbrf.c| 36 +++
 drivers/net/wireless/mediatek/mt76/mt76.h | 19 ++
 .../net/wireless/mediatek/mt76/mt7921/init.c  |  2 ++
 .../net/wireless/mediatek/mt76/mt7921/main.c  |  3 ++
 5 files changed, 61 insertions(+)
 create mode 100644 drivers/net/wireless/mediatek/mt76/acpi_wbrf.c

diff --git a/drivers/net/wireless/mediatek/mt76/Makefile 
b/drivers/net/wireless/mediatek/mt76/Makefile
index 84c99b7e57f9..c016c71f23bd 100644
--- a/drivers/net/wireless/mediatek/mt76/Makefile
+++ b/drivers/net/wireless/mediatek/mt76/Makefile
@@ -12,6 +12,7 @@ mt76-y := \
 
 mt76-$(CONFIG_PCI) += pci.o
 mt76-$(CONFIG_NL80211_TESTMODE) += testmode.o
+mt76-$(CONFIG_ACPI_WBRF) += acpi_wbrf.o
 
 mt76-usb-y := usb.o usb_trace.o
 mt76-sdio-y := sdio.o sdio_txrx.o
diff --git a/drivers/net/wireless/mediatek/mt76/acpi_wbrf.c 
b/drivers/net/wireless/mediatek/mt76/acpi_wbrf.c
new file mode 100644
index ..ceef57bddc6f
--- /dev/null
+++ b/drivers/net/wireless/mediatek/mt76/acpi_wbrf.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: ISC
+/* Copyright (C) 2023 Advanced Micro Devices */
+
+#include 
+#include "mt76.h"
+
+#if defined(CONFIG_ACPI_WBRF)
+void mt76_init_acpi_wbrf(struct mt76_dev *dev)
+{
+   struct acpi_device *acpi_dev = ACPI_COMPANION(dev->dev);
+
+   if (!acpi_dev) {
+   dev_dbg(dev->dev, "ACPI companion not found\n");
+   return;
+   }
+
+   dev->phy.wbrf = wbrf_supported_producer(acpi_dev);
+   dev_dbg(dev->dev, "WBRF is %s supported\n",
+   dev->phy.wbrf ? "" : "not");
+}
+EXPORT_SYMBOL_GPL(mt76_init_acpi_wbrf);
+int mt76_add_wbrf(struct mt76_dev *dev, struct cfg80211_chan_def *chandef)
+{
+   if (!dev->phy.wbrf)
+   return 0;
+   return wbrf_add_exclusion_wlan(ACPI_COMPANION(dev->dev), chandef);
+}
+EXPORT_SYMBOL_GPL(mt76_add_wbrf);
+int mt76_remove_wbrf(struct mt76_dev *dev, struct cfg80211_chan_def *chandef)
+{
+   if (!dev->phy.wbrf)
+   return 0;
+   return wbrf_remove_exclusion_wlan(ACPI_COMPANION(dev->dev), chandef);
+}
+EXPORT_SYMBOL_GPL(mt76_remove_wbrf);
+#endif
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h 
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 6b07b8fafec2..fd33a553ba2e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -733,6 +733,7 @@ struct mt76_phy {
int txpower_cur;
u8 antenna_mask;
u16 chainmask;
+   bool wbrf;
 
 #ifdef CONFIG_NL80211_TESTMODE
struct mt76_testmode_data test;
@@ -1511,4 +1512,22 @@ mt76_packet_id_flush(struct mt76_dev *dev, struct 
mt76_wcid *wcid)
idr_destroy(>pktid);
 }
 
+#ifdef CONFIG_ACPI_WBRF
+void mt76_init_acpi_wbrf(struct mt76_dev *dev);
+int mt76_add_wbrf(struct mt76_dev *dev, struct cfg80211_chan_def *chandef);
+int mt76_remove_wbrf(struct mt76_dev *dev, struct cfg80211_chan_def *chandef);
+#else
+static inline void mt76_init_acpi_wbrf(struct mt76_dev *dev) { };
+static inline int
+mt76_add_wbrf(struct mt76_dev *dev, struct cfg80211_chan_def *chandef)
+{
+   return 0;
+}
+static inline int
+mt76_remove_wbrf(struct mt76_dev *dev, struct cfg80211_chan_def *chandef)
+{
+   return 0;
+}
+#endif /* CONFIG_ACPI_WBRF */
+
 #endif
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/init.c 
b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
index bf1da9fddfab..91396139a177 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
@@ -420,6 +420,8 @@ int mt7921_register_device(struct mt7921_dev *dev)
 
mt7921_init_acpi_sar(dev);
 
+   mt76_init_acpi_wbrf(>mt76);
+
ret = mt7921_init_wcid(dev);
if (ret)
return ret;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/main.c 
b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
index 3b6adb29cbef..241d5b1729dd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
+++

[PATCH 1/9] 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. For net/wireless subsystem
   specifically, `wbrf_add_exclusion_wlan` can be used instead.
3) If removing frequencies, then call `wbrf_remove_exclusion` with
   start and end ranges of the frequencies. For net/wireless subsystem
   specifically, `wbrf_remove_exclusion_wlan` can be used instead.

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:
  - update wifi_acpi_dsm_guid and wbrf_record to fit latest designs
  - the frequency range fed to BIOS is expected to be in HZ unit
v2->v3:
  - correct the algorithm for frequency range start and end point
calculation
  - drop unneeded notifier register/unregister APIs
v3->v4:
  - concentrate all wbrf ACPI related code in acpi_wbrf.c
v4->v5:
  - typo and some other minor fixes(Mario)
v5->v6:
  - correct the calculations around start/end frequency points
v6->v7:
  - correct the data type for arg3 to fit ACPI spce
---
 drivers/acpi/Kconfig |   7 +
 drivers/acpi/Makefile|   2 +
 drivers/acpi/acpi_wbrf.c | 343 +++
 include/linux/wbrf.h |  70 
 4 files changed, 422 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
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 ..bf8e0ed73072
--- /dev/null
+++ b/drivers/acpi/acpi_wbrf.c
@@ -0,0 +1,343 @@
+// 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
+
+#define KHZ_TO_HZ(freq)((freq) * 1000ULL)
+
+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

[PATCH 0/9] 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 - 4: Enable WBRF support for some Mediatek and Qualcomm wifi drivers.
Patch5 - 9: Enable WBRF support for AMD graphics driver.

Anson Tsao (1):
  wifi: ath11k: Add support to the Qualcomm ath11k for ACPI WBRF

Evan Quan (6):
  wifi: ath12k: Add support to the Qualcomm ath12k 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 (2):
  drivers/acpi: Add support for Wifi band RF mitigations
  mt76: Add support to the Mediatek MT7921 for ACPI WBRF

 drivers/acpi/Kconfig  |   7 +
 drivers/acpi/Makefile |   2 +
 drivers/acpi/acpi_wbrf.c  | 343 ++
 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 |  31 ++
 .../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  |  62 
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  |  61 
 drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |   3 +
 drivers/net/wireless/ath/Makefile |   1 +
 drivers/net/wireless/ath/acpi_wbrf.c  |  45 +++
 drivers/net/wireless/ath/ath.h|  15 +
 drivers/net/wireless/ath/ath11k/core.c|  23 ++
 drivers/net/wireless/ath/ath11k/core.h|  14 +
 drivers/net/wireless/ath/ath11k/mac.c |   4 +
 drivers/net/wireless/ath/ath11k/pci.c |   3 +
 drivers/net/wireless/ath/ath12k/core.c|  21 ++
 drivers/net/wireless/ath/ath12k/core.h|  14 +
 drivers/net/wireless/ath/ath12k/mac.c |   4 +
 drivers/net/wireless/ath/ath12k/pci.c |   3 +
 drivers/net/wireless/mediatek/mt76/Makefile   |   1 +
 .../net/wireless/mediatek/mt76/acpi_wbrf.c|  36 ++
 drivers/net/wireless/mediatek/mt76/mt76.h |  19 +
 .../net/wireless/mediatek/mt76/mt7921/init.c  |   2 +
 .../net/wireless/mediatek/mt76/mt7921/main.c  |   3 +
 include/linux/wbrf.h  |  70 
 35 files changed, 1143 insertions(+), 5 deletions(-)
 create mode 100644 drivers/acpi/acpi_wbrf.c
 create mode 100644 drivers/net/wireless/ath/acpi_wbrf.c
 create mode 100644 drivers/net/wireless/mediatek/mt76/acpi_wbrf.c
 create mode 100644 include/linux/wbrf.h

-- 
2.34.1

Re: linux-next: manual merge of the drm-intel tree with the drm tree

2023-05-29 Thread Stephen Rothwell

Hi all,

On Tue, 30 May 2023 11:57:52 +1000 Stephen Rothwell  
wrote:
>
> @@@ -920,33 -587,8 +640,9 @@@ static const struct intel_device_info j
>   #define GEN12_FEATURES \
>   GEN11_FEATURES, \
>   GEN(12), \
> - .display.abox_mask = GENMASK(2, 1), \
> - .__runtime.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | 
> BIT(PIPE_D), \
> - .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) 
> | \
> - BIT(TRANSCODER_C) | BIT(TRANSCODER_D) | \
> - BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1), \
> - .display.pipe_offsets = { \
> - [TRANSCODER_A] = PIPE_A_OFFSET, \
> - [TRANSCODER_B] = PIPE_B_OFFSET, \
> - [TRANSCODER_C] = PIPE_C_OFFSET, \
> - [TRANSCODER_D] = PIPE_D_OFFSET, \
> - [TRANSCODER_DSI_0] = PIPE_DSI0_OFFSET, \
> - [TRANSCODER_DSI_1] = PIPE_DSI1_OFFSET, \
> - }, \
> - .display.trans_offsets = { \
> - [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> - [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> - [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
> - [TRANSCODER_D] = TRANSCODER_D_OFFSET, \
> - [TRANSCODER_DSI_0] = TRANSCODER_DSI0_OFFSET, \
> - [TRANSCODER_DSI_1] = TRANSCODER_DSI1_OFFSET, \
> - }, \
> - TGL_CURSOR_OFFSETS, \
> - TGL_CACHELEVEL, \
> ++.max_pat_index = 3 \

I fixed the above up to have a ',' after the '3'

>   .has_global_mocs = 1, \
> - .has_pxp = 1, \
> - .display.has_dsb = 1, \
> - .max_pat_index = 3
> + .has_pxp = 1
-- 
Cheers,
Stephen Rothwell


pgpLmxwloXSk7.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the drm-intel tree with the drm tree

2023-05-29 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  66ca1d8f222b ("drm/i915/i915_drv: Use i915 instead of dev_priv insied the 
file_priv structure")

from the drm tree and commits:

  5af5169d7582 ("drm/i915: Convert INTEL_INFO()->display to a pointer")
  18e0deeed8c8 ("drm/i915/display: Move display runtime info to display 
structure")
  95c08508e237 ("drm/i915/display: Move feature test macros to 
intel_display_device.h")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This is
now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_drv.h
index f23b030aaf09,e9c403def9c9..
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -407,11 -408,13 +408,13 @@@ static inline struct intel_gt *to_gt(st
 (engine__) && (engine__)->uabi_class == (class__); \
 (engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node)))
  
 -#define INTEL_INFO(dev_priv)  (&(dev_priv)->__info)
 +#define INTEL_INFO(i915)  (&(i915)->__info)
+ #define DISPLAY_INFO(i915)(INTEL_INFO(i915)->display)
 -#define RUNTIME_INFO(dev_priv)(&(dev_priv)->__runtime)
 +#define RUNTIME_INFO(i915)(&(i915)->__runtime)
+ #define DISPLAY_RUNTIME_INFO(i915)(&(i915)->__display_runtime)
 -#define DRIVER_CAPS(dev_priv) (&(dev_priv)->caps)
 +#define DRIVER_CAPS(i915) (&(i915)->caps)
  
 -#define INTEL_DEVID(dev_priv) (RUNTIME_INFO(dev_priv)->device_id)
 +#define INTEL_DEVID(i915) (RUNTIME_INFO(i915)->device_id)
  
  #define IP_VER(ver, rel)  ((ver) << 8 | (rel))
  
@@@ -753,125 -756,82 +756,82 @@@ IS_SUBPLATFORM(const struct drm_i915_pr
   * The Gen7 cmdparser copies the scanned buffer to the ggtt for execution
   * All later gens can run the final buffer from the ppgtt
   */
 -#define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7)
 +#define CMDPARSER_USES_GGTT(i915) (GRAPHICS_VER(i915) == 7)
  
 -#define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc)
 -#define HAS_4TILE(dev_priv)   (INTEL_INFO(dev_priv)->has_4tile)
 -#define HAS_SNOOP(dev_priv)   (INTEL_INFO(dev_priv)->has_snoop)
 -#define HAS_EDRAM(dev_priv)   ((dev_priv)->edram_size_mb)
 -#define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6)
 -#define HAS_WT(dev_priv)  HAS_EDRAM(dev_priv)
 +#define HAS_LLC(i915) (INTEL_INFO(i915)->has_llc)
 +#define HAS_4TILE(i915)   (INTEL_INFO(i915)->has_4tile)
 +#define HAS_SNOOP(i915)   (INTEL_INFO(i915)->has_snoop)
 +#define HAS_EDRAM(i915)   ((i915)->edram_size_mb)
 +#define HAS_SECURE_BATCHES(i915) (GRAPHICS_VER(i915) < 6)
 +#define HAS_WT(i915)  HAS_EDRAM(i915)
  
 -#define HWS_NEEDS_PHYSICAL(dev_priv)  
(INTEL_INFO(dev_priv)->hws_needs_physical)
 +#define HWS_NEEDS_PHYSICAL(i915)  (INTEL_INFO(i915)->hws_needs_physical)
  
 -#define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
 -  (INTEL_INFO(dev_priv)->has_logical_ring_contexts)
 -#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
 -  (INTEL_INFO(dev_priv)->has_logical_ring_elsq)
 +#define HAS_LOGICAL_RING_CONTEXTS(i915) \
 +  (INTEL_INFO(i915)->has_logical_ring_contexts)
 +#define HAS_LOGICAL_RING_ELSQ(i915) \
 +  (INTEL_INFO(i915)->has_logical_ring_elsq)
  
 -#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
 +#define HAS_EXECLISTS(i915) HAS_LOGICAL_RING_CONTEXTS(i915)
  
 -#define INTEL_PPGTT(dev_priv) (RUNTIME_INFO(dev_priv)->ppgtt_type)
 -#define HAS_PPGTT(dev_priv) \
 -  (INTEL_PPGTT(dev_priv) != INTEL_PPGTT_NONE)
 -#define HAS_FULL_PPGTT(dev_priv) \
 -  (INTEL_PPGTT(dev_priv) >= INTEL_PPGTT_FULL)
 +#define INTEL_PPGTT(i915) (RUNTIME_INFO(i915)->ppgtt_type)
 +#define HAS_PPGTT(i915) \
 +  (INTEL_PPGTT(i915) != INTEL_PPGTT_NONE)
 +#define HAS_FULL_PPGTT(i915) \
 +  (INTEL_PPGTT(i915) >= INTEL_PPGTT_FULL)
  
 -#define HAS_PAGE_SIZES(dev_priv, sizes) ({ \
 +#define HAS_PAGE_SIZES(i915, sizes) ({ \
GEM_BUG_ON((sizes) == 0); \
 -  ((sizes) & ~RUNTIME_INFO(dev_priv)->page_sizes) == 0; \
 +  ((sizes) & ~RUNTIME_INFO(i915)->page_sizes) == 0; \
  })
  
- #define HAS_OVERLAY(i915)  (INTEL_INFO(i915)->display.has_overlay)
- #define OVERLAY_NEEDS_PHYSICAL(i915) \
-   (INTEL_INFO(i915)->display.overlay_needs_physical)
- 
  /* Early gen2 have a totally busted CS tlb and require pinned batches. */
 -#define HAS_BROKEN_CS_TLB(dev_priv)   (IS_I830(dev_priv) || 
IS_I845G(dev_priv))
 +#define HAS_BROKEN_CS_TLB(i915)   (IS_I830(i915) || IS_I845G(i915))
  
 -#define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv) \
 -  (IS_BROADWELL(dev_priv) ||

linux-next: manual merge of the drm-intel tree with the drm tree

2023-05-29 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_pci.c

between commit:

  5e352e32aec2 ("drm/i915: preparation for using PAT index")

from the drm tree and commits:

  5af5169d7582 ("drm/i915: Convert INTEL_INFO()->display to a pointer")
  18e0deeed8c8 ("drm/i915/display: Move display runtime info to display 
structure")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_pci.c
index 75cbccd1a441,34bc732a6375..
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@@ -27,9 -27,9 +27,10 @@@
  #include 
  
  #include "display/intel_display.h"
+ #include "display/intel_display_driver.h"
  #include "gt/intel_gt_regs.h"
  #include "gt/intel_sa_media.h"
 +#include "gem/i915_gem_object_types.h"
  
  #include "i915_driver.h"
  #include "i915_drv.h"
@@@ -40,162 -40,8 +41,40 @@@
  #define PLATFORM(x) .platform = (x)
  #define GEN(x) \
.__runtime.graphics.ip.ver = (x), \
-   .__runtime.media.ip.ver = (x), \
-   .__runtime.display.ip.ver = (x)
- 
- #define NO_DISPLAY .__runtime.pipe_mask = 0
- 
- #define I845_PIPE_OFFSETS \
-   .display.pipe_offsets = { \
-   [TRANSCODER_A] = PIPE_A_OFFSET, \
-   }, \
-   .display.trans_offsets = { \
-   [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
-   }
- 
- #define I9XX_PIPE_OFFSETS \
-   .display.pipe_offsets = { \
-   [TRANSCODER_A] = PIPE_A_OFFSET, \
-   [TRANSCODER_B] = PIPE_B_OFFSET, \
-   }, \
-   .display.trans_offsets = { \
-   [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
-   [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
-   }
- 
- #define IVB_PIPE_OFFSETS \
-   .display.pipe_offsets = { \
-   [TRANSCODER_A] = PIPE_A_OFFSET, \
-   [TRANSCODER_B] = PIPE_B_OFFSET, \
-   [TRANSCODER_C] = PIPE_C_OFFSET, \
-   }, \
-   .display.trans_offsets = { \
-   [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
-   [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
-   [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
-   }
- 
- #define HSW_PIPE_OFFSETS \
-   .display.pipe_offsets = { \
-   [TRANSCODER_A] = PIPE_A_OFFSET, \
-   [TRANSCODER_B] = PIPE_B_OFFSET, \
-   [TRANSCODER_C] = PIPE_C_OFFSET, \
-   [TRANSCODER_EDP] = PIPE_EDP_OFFSET, \
-   }, \
-   .display.trans_offsets = { \
-   [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
-   [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
-   [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
-   [TRANSCODER_EDP] = TRANSCODER_EDP_OFFSET, \
-   }
- 
- #define CHV_PIPE_OFFSETS \
-   .display.pipe_offsets = { \
-   [TRANSCODER_A] = PIPE_A_OFFSET, \
-   [TRANSCODER_B] = PIPE_B_OFFSET, \
-   [TRANSCODER_C] = CHV_PIPE_C_OFFSET, \
-   }, \
-   .display.trans_offsets = { \
-   [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
-   [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
-   [TRANSCODER_C] = CHV_TRANSCODER_C_OFFSET, \
-   }
- 
- #define I845_CURSOR_OFFSETS \
-   .display.cursor_offsets = { \
-   [PIPE_A] = CURSOR_A_OFFSET, \
-   }
- 
- #define I9XX_CURSOR_OFFSETS \
-   .display.cursor_offsets = { \
-   [PIPE_A] = CURSOR_A_OFFSET, \
-   [PIPE_B] = CURSOR_B_OFFSET, \
-   }
- 
- #define CHV_CURSOR_OFFSETS \
-   .display.cursor_offsets = { \
-   [PIPE_A] = CURSOR_A_OFFSET, \
-   [PIPE_B] = CURSOR_B_OFFSET, \
-   [PIPE_C] = CHV_CURSOR_C_OFFSET, \
-   }
- 
- #define IVB_CURSOR_OFFSETS \
-   .display.cursor_offsets = { \
-   [PIPE_A] = CURSOR_A_OFFSET, \
-   [PIPE_B] = IVB_CURSOR_B_OFFSET, \
-   [PIPE_C] = IVB_CURSOR_C_OFFSET, \
-   }
- 
- #define TGL_CURSOR_OFFSETS \
-   .display.cursor_offsets = { \
-   [PIPE_A] = CURSOR_A_OFFSET, \
-   [PIPE_B] = IVB_CURSOR_B_OFFSET, \
-   [PIPE_C] = IVB_CURSOR_C_OFFSET, \
-   [PIPE_D] = TGL_CURSOR_D_OFFSET, \
-   }
- 
- #define I845_COLORS \
-   .display.color = { .gamma_lut_size = 256 }
- #define I9XX_COLORS \
-   .display.color = { .gamma_lut_size = 129, \
-  .gamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING, \
-   }
- #define ILK_COLORS \
-   .display.color = { .gamma_lut_size = 1024 }
- #define IVB_COLORS \
-   .display.color = { .degamma_lut_size = 1024, .gamma_lut_size = 1024 }
-

[Bug 217499] NVIDIA drivers fail to install on 6.4.0-rc3-1-mainline kernel

2023-05-29 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=217499

Wessel (wessel.working+ker...@gmail.com) changed:

   What|Removed |Added

 Resolution|MOVED   |ANSWERED

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH 00/36] drm/amd/display: add AMD driver-specific properties for color mgmt


On 24/05/2023 01:14, Melissa Wen wrote:

This series is a refined version of our RFC [1] for AMD driver-specific
color management properties. It is a collection of contributions from
Joshua, Harry and I to enhance AMD KMS color pipeline for Steam
Deck/SteamOS by exposing the large set of color caps available in AMD
display HW.

Considering RFC feedback, this patchset differs from the previous one by
removing the KConfig option and just guarding driver-specific properties
with `AMD_PRIVATE_COLOR` - but we also removed the guards from internal
elements and operations. We stopped to advertise CRTC shaper and 3D LUTs
properties since they aren't in use in the Steam Deck color pipeline[2].
On the other hand, we keep mapping CRTC shaper and 3D LUTs (DM) to DC
MPC setup. We also improved curve calculations to take into account HW
color caps.

In short, for pre-blending, we added the following properties:
- plane degamma LUT and predefined transfer function;
- plane HDR multiplier
- plane shaper LUT/transfer function;
- plane 3D LUT; and finally,
- plane blend LUT/transfer function, just before blending.


This set of properties sounds interesting and not fully AMD-specific. 
Could you please consider moving them to the more generic location?


For the reference, MSM (Qualcomm) display hardware supports 
degamma/gamma LUTs for planes too. One of the suggested usecases for 
these degamma/gamma units is to support colorspace transfer functions.


Thus, at least some of these properties can be implemented in drm/msm 
driver too.



After blending, we already have DRM CRTC degamma/gamma LUTs and CTM,
therefore, we extend post-blending color pipeline with CRTC gamma
transfer function.

The first three patches are on DRM KMS side. We expose DRM property
helper for blob lookup and replacement so that we can use it for
managing driver-specific properties. We add a tracked for plane color
mgmt changes and increase the maximum number of properties to
accommodate this expansion.

The userspace case here is Gamescope which is the compositor for
SteamOS. It's already using all of this functionality to implement its
color management pipeline right now [3].

Current IGT tests kms_color and amdgpu/amd_color on DCN301 and DCN21 HW
preserve the same results with and without the guard.

Finally, I may have missed something, please let me know if that's the
case.

Best Regards,

Melissa Wen

[1] https://lore.kernel.org/dri-devel/20230423141051.702990-1-m...@igalia.com
[2] 
https://github.com/ValveSoftware/gamescope/blob/master/src/docs/Steam%20Deck%20Display%20Pipeline.png
[3] https://github.com/ValveSoftware/gamescope


Harry Wentland (2):
   drm/amd/display: fix segment distribution for linear LUTs
   drm/amd/display: fix the delta clamping for shaper LUT

Joshua Ashton (13):
   drm/amd/display: add plane degamma TF driver-specific property
   drm/amd/display: add plane HDR multiplier driver-specific property
   drm/amd/display: add plane blend LUT and TF driver-specific properties
   drm/amd/display: copy 3D LUT settings from crtc state to stream_update
   drm/amd/display: dynamically acquire 3DLUT resources for color changes
   drm/amd/display: add CRTC regamma TF support
   drm/amd/display: set sdr_ref_white_level to 80 for out_transfer_func
   drm/amd/display: add support for plane degamma TF and LUT properties
   drm/amd/display: add dc_fixpt_from_s3132 helper
   drm/adm/display: add HDR multiplier support
   drm/amd/display: handle empty LUTs in __set_input_tf
   drm/amd/display: add DRM plane blend LUT and TF support
   drm/amd/display: allow newer DC hardware to use degamma ROM for PQ/HLG

Melissa Wen (21):
   drm/drm_mode_object: increase max objects to accommodate new color
 props
   drm/drm_property: make replace_property_blob_from_id a DRM helper
   drm/drm_plane: track color mgmt changes per plane
   drm/amd/display: add CRTC driver-specific property for gamma TF
   drm/amd/display: add plane driver-specific properties for degamma LUT
   drm/amd/display: add plane 3D LUT driver-specific properties
   drm/amd/display: add plane shaper LUT driver-specific properties
   drm/amd/display: add plane shaper TF driver-private property
   drm/amd/display: add comments to describe DM crtc color mgmt behavior
   drm/amd/display: encapsulate atomic regamma operation
   drm/amd/display: update lut3d and shaper lut to stream
   drm/amd/display: allow BYPASS 3D LUT but keep shaper LUT settings
   drm/amd/display: handle MPC 3D LUT resources for a given context
   drm/amd/display: add CRTC 3D LUT support
   drm/amd/display: add CRTC shaper LUT support
   drm/amd/display: add CRTC shaper TF support
   drm/amd/display: mark plane as needing reset if plane color mgmt
 changes
   drm/amd/display: decouple steps for mapping CRTC degamma to DC plane
   drm/amd/display: reject atomic commit if setting both plane and CRTC
 degamma
   drm/amd/display: program DPP shaper and 3D LUT if updated
   drm/amd/display: add plane

[PATCH v4 6/6] drm/shmem-helper: Switch to reservation lock

Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.

Suggested-by: Daniel Vetter 
Acked-by: Thomas Zimmermann 
Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c| 210 --
 drivers/gpu/drm/lima/lima_gem.c   |   8 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c   |   7 +-
 .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   6 +-
 drivers/gpu/drm/panfrost/panfrost_mmu.c   |  19 +-
 include/drm/drm_gem_shmem_helper.h|  14 +-
 6 files changed, 116 insertions(+), 148 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4ea6507a77e5..a783d2245599 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -88,8 +88,6 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size, 
bool private)
if (ret)
goto err_release;
 
-   mutex_init(>pages_lock);
-   mutex_init(>vmap_lock);
INIT_LIST_HEAD(>madv_list);
 
if (!private) {
@@ -141,11 +139,13 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object 
*shmem)
 {
struct drm_gem_object *obj = >base;
 
-   drm_WARN_ON(obj->dev, shmem->vmap_use_count);
-
if (obj->import_attach) {
drm_prime_gem_destroy(obj, shmem->sgt);
} else {
+   dma_resv_lock(shmem->base.resv, NULL);
+
+   drm_WARN_ON(obj->dev, shmem->vmap_use_count);
+
if (shmem->sgt) {
dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
  DMA_BIDIRECTIONAL, 0);
@@ -154,22 +154,24 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object 
*shmem)
}
if (shmem->pages)
drm_gem_shmem_put_pages(shmem);
-   }
 
-   drm_WARN_ON(obj->dev, shmem->pages_use_count);
+   drm_WARN_ON(obj->dev, shmem->pages_use_count);
+
+   dma_resv_unlock(shmem->base.resv);
+   }
 
drm_gem_object_release(obj);
-   mutex_destroy(>pages_lock);
-   mutex_destroy(>vmap_lock);
kfree(shmem);
 }
 EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
 
-static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
+static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
 {
struct drm_gem_object *obj = >base;
struct page **pages;
 
+   dma_resv_assert_held(shmem->base.resv);
+
if (shmem->pages_use_count++ > 0)
return 0;
 
@@ -197,35 +199,16 @@ static int drm_gem_shmem_get_pages_locked(struct 
drm_gem_shmem_object *shmem)
 }
 
 /*
- * drm_gem_shmem_get_pages - Allocate backing pages for a shmem GEM object
+ * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a 
shmem GEM object
  * @shmem: shmem GEM object
  *
- * This function makes sure that backing pages exists for the shmem GEM object
- * and increases the use count.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
+ * This function decreases the use count and puts the backing pages when use 
drops to zero.
  */
-int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
+void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
 {
struct drm_gem_object *obj = >base;
-   int ret;
 
-   drm_WARN_ON(obj->dev, obj->import_attach);
-
-   ret = mutex_lock_interruptible(>pages_lock);
-   if (ret)
-   return ret;
-   ret = drm_gem_shmem_get_pages_locked(shmem);
-   mutex_unlock(>pages_lock);
-
-   return ret;
-}
-EXPORT_SYMBOL(drm_gem_shmem_get_pages);
-
-static void drm_gem_shmem_put_pages_locked(struct drm_gem_shmem_object *shmem)
-{
-   struct drm_gem_object *obj = >base;
+   dma_resv_assert_held(shmem->base.resv);
 
if (drm_WARN_ON_ONCE(obj->dev, !shmem->pages_use_count))
return;
@@ -243,20 +226,25 @@ static void drm_gem_shmem_put_pages_locked(struct 
drm_gem_shmem_object *shmem)
  shmem->pages_mark_accessed_on_put);
shmem->pages = NULL;
 }
+EXPORT_SYMBOL(drm_gem_shmem_put_pages);
 
-/*
- * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a 
shmem GEM object
- * @shmem: shmem GEM object
- *
- * This function decreases the use count and puts the backing pages when use 
drops to zero.
- */
-void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
+static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem)
 {
-   mutex_lock(>pages_lock);
-   drm_gem_shmem_put_pages_locked(shmem);
-   mutex_unlock(>pages_lock);
+   int ret;
+
+   dma_resv_assert_held(shmem->base.resv);
+
+   ret =

[PATCH v4 4/6] drm: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares DRM
drivers for the locking policy update.

Reviewed-by: Emil Velikov 
Acked-by: Christian König 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/drm_prime.c| 2 --
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  | 2 --
 drivers/gpu/drm/tegra/gem.c| 2 --
 4 files changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 149cd4ff6a3b..cea85e84666f 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -781,8 +781,6 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct 
vm_area_struct *vma)
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
 
-   dma_resv_assert_held(dma_buf->resv);
-
if (!dev->driver->gem_prime_mmap)
return -ENOSYS;
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index fd556a076d05..1df74f7aa3dc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -97,8 +97,6 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, 
struct vm_area_struct *
struct drm_i915_private *i915 = to_i915(obj->base.dev);
int ret;
 
-   dma_resv_assert_held(dma_buf->resv);
-
if (obj->base.size < vma->vm_end - vma->vm_start)
return -EINVAL;
 
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 3abc47521b2c..8e194dbc9506 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -66,8 +66,6 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct drm_gem_object *obj = buffer->priv;
int ret = 0;
 
-   dma_resv_assert_held(buffer->resv);
-
ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bce991a2ccc0..871ef5d26523 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -693,8 +693,6 @@ static int tegra_gem_prime_mmap(struct dma_buf *buf, struct 
vm_area_struct *vma)
struct drm_gem_object *gem = buf->priv;
int err;
 
-   dma_resv_assert_held(buf->resv);
-
err = drm_gem_mmap_obj(gem, gem->size, vma);
if (err < 0)
return err;
-- 
2.40.1

[PATCH v4 5/6] dma-buf: Change locking policy for mmap()

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(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index aa4ea8530cb3..21916bba77d5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -131,7 +131,6 @@ static struct file_system_type dma_buf_fs_type = {
 static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
 {
struct dma_buf *dmabuf;
-   int ret;
 
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -147,11 +146,7 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
 
-   dma_resv_lock(dmabuf->resv, NULL);
-   ret = dmabuf->ops->mmap(dmabuf, vma);
-   dma_resv_unlock(dmabuf->resv);
-
-   return ret;
+   return dmabuf->ops->mmap(dmabuf, vma);
 }
 
 static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -850,6 +845,7 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
  * - _buf_ops.release()
  * - _buf_ops.begin_cpu_access()
  * - _buf_ops.end_cpu_access()
+ * - _buf_ops.mmap()
  *
  * 2. These _buf_ops callbacks are invoked with locked dma-buf
  *reservation and exporter can't take the lock:
@@ -858,7 +854,6 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
  * - _buf_ops.unpin()
  * - _buf_ops.map_dma_buf()
  * - _buf_ops.unmap_dma_buf()
- * - _buf_ops.mmap()
  * - _buf_ops.vmap()
  * - _buf_ops.vunmap()
  *
@@ -1463,8 +1458,6 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
 int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
 unsigned long pgoff)
 {
-   int ret;
-
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
 
@@ -1485,11 +1478,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
 
-   dma_resv_lock(dmabuf->resv, NULL);
-   ret = dmabuf->ops->mmap(dmabuf, vma);
-   dma_resv_unlock(dmabuf->resv);
-
-   return ret;
+   return dmabuf->ops->mmap(dmabuf, vma);
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
 
-- 
2.40.1

[PATCH v4 2/6] dma-buf/heaps: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem
solved by moving the lock down to exporters. This patch prepares dma-buf
heaps for the locking policy update.

Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/heaps/cma_heap.c| 3 ---
 drivers/dma-buf/heaps/system_heap.c | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 1131fb943992..28fb04eccdd0 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -183,8 +182,6 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
 {
struct cma_heap_buffer *buffer = dmabuf->priv;
 
-   dma_resv_assert_held(dmabuf->resv);
-
if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
return -EINVAL;
 
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index e8bd10e60998..fcf836ba9c1f 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -202,8 +201,6 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
struct sg_page_iter piter;
int ret;
 
-   dma_resv_assert_held(dmabuf->resv);
-
for_each_sgtable_page(table, , vma->vm_pgoff) {
struct page *page = sg_page_iter_page();
 
-- 
2.40.1

[PATCH v4 3/6] udmabuf: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares udmabuf
for the locking policy update.

Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/udmabuf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 740d6e426ee9..277f1afa9552 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -52,8 +52,6 @@ static int mmap_udmabuf(struct dma_buf *buf, struct 
vm_area_struct *vma)
 {
struct udmabuf *ubuf = buf->priv;
 
-   dma_resv_assert_held(buf->resv);
-
if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
return -EINVAL;
 
-- 
2.40.1

[PATCH v4 0/6] Move dma-buf mmap() reservation locking down to exporters

This patchset makes dma-buf exporters responisble for taking care of
the reservation lock. I also included patch that moves drm-shmem to use
reservation lock, to let CI test the whole set. I'm going to take all
the patches via the drm-misc tree, please give an ack.

Previous policy stated that dma-buf core takes the lock around mmap()
callback. Which meant that both importers and exporters shouldn't touch
the reservation lock in the mmap() code path. This worked well until
Intel-CI found a deadlock problem in a case of self-imported dma-buf [1].

The problem happens when userpace mmaps a self-imported dma-buf, i.e.
mmaps the dma-buf FD. DRM core treats self-imported dma-bufs as own GEMs
[2]. There is no way to differentiate a prime GEM from a normal GEM for
drm-shmem in drm_gem_shmem_mmap(), which resulted in a deadlock problem
for drm-shmem mmap() code path once it's switched to use reservation lock.

It was difficult to fix the drm-shmem problem without adjusting dma-buf
locking policy. In parctice not much changed from importers perspective
because previosly dma-buf was taking the lock in between of importers
and exporters. Now this lock is shifted down to exporters.

[1]
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt@prime_vgem@s...@rcs0.html
[2]
https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/drm_prime.c#L924

Changelog:

v4: - Added dma_resv_assert_held() to drm_gem_shmem_get_pages(), making
assert consistent with the put() variant. Suggested by Emil Velikov.

v3: - Added r-b from Hans Verkuil to the videobuf2 patch.

- The v2 fastrpc patch was already applied, not including it anymore.
Though, the cover-letter says that I'd want to apply all the patches
via the drm-misc tree to keep the proper ordering of the changes.

- Previously Intel's CI gave a flake failure to v2, want to re-test
it again.

v2: - Added ack from Christian König to the DRM patch.

- Dropped "fixes" tag from the patches, like was requested by
Christian König. The patches don't actually need a backport
and merely improve the locking policy.

- Dropped "reverts" from the patch titles to prevent them from
auto-backporting by the stable bot based on the title.

- Added r-b from Emil Velikov and placed the drm_WARN in the
drm-shmem patch like he suggested in a comment to v1.

- Corrected drm-shmem patch dma_resv_lock(obj->resv) inconsistently
used with dma_resv_unlock(shmem->base.resv). Now shmem->base.resv
variant is used for all locks/unlocks.

Dmitry Osipenko (6):
media: videobuf2: Don't assert held reservation lock for dma-buf
mmapping
dma-buf/heaps: Don't assert held reservation lock for dma-buf mmapping
udmabuf: Don't assert held reservation lock for dma-buf mmapping
drm: Don't assert held reservation lock for dma-buf mmapping
dma-buf: Change locking policy for mmap()
drm/shmem-helper: Switch to reservation lock

drivers/dma-buf/dma-buf.c | 17 +-
drivers/dma-buf/heaps/cma_heap.c | 3 -
drivers/dma-buf/heaps/system_heap.c | 3 -
drivers/dma-buf/udmabuf.c | 2 -
drivers/gpu/drm/drm_gem_shmem_helper.c| 210 --
drivers/gpu/drm/drm_prime.c | 2 -
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 -
drivers/gpu/drm/lima/lima_gem.c | 8 +-
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 -
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-
.../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +-
drivers/gpu/drm/tegra/gem.c | 2 -
.../common/videobuf2/videobuf2-dma-contig.c | 3 -
.../media/common/videobuf2/videobuf2-dma-sg.c | 3 -
.../common/videobuf2/videobuf2-vmalloc.c | 3 -
include/drm/drm_gem_shmem_helper.h| 14 +-
17 files changed, 119 insertions(+), 187 deletions(-)

--
2.40.1

[PATCH v4 1/6] media: videobuf2: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares videobuf2
for the locking policy update.

Reviewed-by: Emil Velikov 
Reviewed-by: Hans Verkuil 
Signed-off-by: Dmitry Osipenko 
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 ---
 drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 ---
 drivers/media/common/videobuf2/videobuf2-vmalloc.c| 3 ---
 3 files changed, 9 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 205d3cac425c..2fa455d4a048 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -11,7 +11,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -456,8 +455,6 @@ static int vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf, 
struct iosys_map *map)
 static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
 {
-   dma_resv_assert_held(dbuf->resv);
-
return vb2_dc_mmap(dbuf->priv, vma);
 }
 
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 183037fb1273..28f3fdfe23a2 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -10,7 +10,6 @@
  * the Free Software Foundation.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -498,8 +497,6 @@ static int vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf,
 static int vb2_dma_sg_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
 {
-   dma_resv_assert_held(dbuf->resv);
-
return vb2_dma_sg_mmap(dbuf->priv, vma);
 }
 
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c 
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index a6c6d2fcaaa4..7c635e292106 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -10,7 +10,6 @@
  * the Free Software Foundation.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -319,8 +318,6 @@ static int vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf,
 static int vb2_vmalloc_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
 {
-   dma_resv_assert_held(dbuf->resv);
-
return vb2_vmalloc_mmap(dbuf->priv, vma);
 }
 
-- 
2.40.1

Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3


On 30/05/2023 01:37, Marijn Suijten wrote:

On 2023-05-30 01:18:40, Dmitry Baryshkov wrote:


+ret = mipi_dsi_dcs_set_display_on(dsi);
+if (ret < 0) {
+dev_err(dev, "Failed to turn display on: %d\n", ret);
+return ret;
+}


My usual question: should the mipi_dsi_dcs_exit_sleep_mode() / 
mipi_dsi_dcs_set_display_on() be moved from prepare() to enable() part?



No, prepare is called before the video stream is started and when display is 
still in LPM mode and the mode hasn't been set.



Yes, that's my point. Shouldn't we enable the panel _after_ starting the stream?


I have never investigated what it takes to split these functions, but
some of these panels do show some corruption at startup which may be
circumvented by powering the panel on after starting the video stream?

I'm just not sure where to make the split: downstream does describe a
qcom,mdss-dsi-on-command and qcom,mdss-dsi-post-panel-on-command, where
the latter only contains set_display_on() (not exit_sleep_mode()).
It is documented like:

  same as "qcom,mdss-dsi-on-command" except commands are sent after
  displaying an image."

So this seems like the right way to split them up, I'll test this out on
all submitted panel drivers.


Interesting enough, Neil suggested that sending all the commands during
pre_enable() is the correct sequence (especially for VIDEO mode panels),
since not all DSI hosts can send commands after switching to the VIDEO mode.


Note that all these panels and Driver-ICs are command-mode, and/or
programmed to run in command-mode, so there shouldn't be any notion of a
VIDEO stream (any command-mode frame is just an "arbitrary command" as
far as I understood).


Yes, from the data stream point of view. I was talking about the DSI 
host being able to send arbitrary commands or not after enabling the 
video/cmd stream.




- Marijn


--
With best wishes
Dmitry

Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3

On 2023-05-30 01:18:40, Dmitry Baryshkov wrote:

> > +ret = mipi_dsi_dcs_set_display_on(dsi);
> > +if (ret < 0) {
> > +dev_err(dev, "Failed to turn display on: %d\n", ret);
> > +return ret;
> > +}
> 
>  My usual question: should the mipi_dsi_dcs_exit_sleep_mode() / 
>  mipi_dsi_dcs_set_display_on() be moved from prepare() to enable() part?
> >>>
> >>>
> >>> No, prepare is called before the video stream is started and when display 
> >>> is still in LPM mode and the mode hasn't been set.
> >>>
> >>
> >> Yes, that's my point. Shouldn't we enable the panel _after_ starting the 
> >> stream?
> > 
> > I have never investigated what it takes to split these functions, but
> > some of these panels do show some corruption at startup which may be
> > circumvented by powering the panel on after starting the video stream?
> > 
> > I'm just not sure where to make the split: downstream does describe a
> > qcom,mdss-dsi-on-command and qcom,mdss-dsi-post-panel-on-command, where
> > the latter only contains set_display_on() (not exit_sleep_mode()).
> > It is documented like:
> > 
> >  same as "qcom,mdss-dsi-on-command" except commands are sent after
> >  displaying an image."
> > 
> > So this seems like the right way to split them up, I'll test this out on
> > all submitted panel drivers.
> 
> Interesting enough, Neil suggested that sending all the commands during 
> pre_enable() is the correct sequence (especially for VIDEO mode panels), 
> since not all DSI hosts can send commands after switching to the VIDEO mode.

Note that all these panels and Driver-ICs are command-mode, and/or
programmed to run in command-mode, so there shouldn't be any notion of a
VIDEO stream (any command-mode frame is just an "arbitrary command" as
far as I understood).

- Marijn

Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3


On 30/05/2023 00:11, Marijn Suijten wrote:

On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:


+   if (ctx->dsi->dsc) {


dsi->dsc is always set, thus this condition can be dropped.


I want to leave room for possibly running the panel without DSC (at a
lower resolution/refresh rate, or at higher power consumption if there
is enough BW) by not assigning the pointer, if we get access to panel
documentation: probably one of the magic commands sent in this driver
controls it but we don't know which.


This sounds like 'a possible room for expansion' which might never be 
actually used. I think, if we ever get such information or when the 
panel's DSC config gets variadic following the mode, we can reintroduce 
this check.





+   drm_dsc_pps_payload_pack(, ctx->dsi->dsc);
+
+   ret = mipi_dsi_picture_parameter_set(ctx->dsi, );
+   if (ret < 0) {
+   dev_err(panel->dev, "failed to transmit PPS: %d\n", 
ret);
+   goto fail;
+   }
+   ret = mipi_dsi_compression_mode(ctx->dsi, true);
+   if (ret < 0) {
+   dev_err(dev, "failed to enable compression mode: %d\n", 
ret);
+   goto fail;
+   }
+
+   msleep(28);
+   }
+
+   ctx->prepared = true;
+   return 0;
+
+fail:
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   regulator_disable(ctx->vddio);
+   return ret;
+}



+   /* This panel only supports DSC; unconditionally enable it */


--
With best wishes
Dmitry

Re: [PATCH RFC 06/10] drm/panel/samsung-sofef01: Add panel driver for Sony Xperia 5 / 10 II

On 2023-05-30 01:20:17, Dmitry Baryshkov wrote:
> On 29/05/2023 23:58, Marijn Suijten wrote:
> > On 2023-05-23 01:56:46, Dmitry Baryshkov wrote:
> >> On Tue, 23 May 2023 at 01:32, Marijn Suijten
> >>  wrote:
> >>>
> >>> On 2023-05-22 04:19:45, Dmitry Baryshkov wrote:
>  On 22/05/2023 00:23, Marijn Suijten wrote:
> > This SOFEF01-M Display-IC driver supports two modes with different
> > compatibles to differentiate between slightly different physical sizes
> > (panels) found on the Xperia 5 (6.1") and 10 II (6.0").
> >
> > It is currently also used to hardcode significantly higher fake porches
> > for the Xperia 5, which are unused in transfers due to this being a
> > command-mode panel but do have an effect on the clock rates set by
> > dsi_host.c.  Without higher clock rates this panel fails to achieve
> > 60fps and has significant tearing artifacts, while the same calculated
> > clock rate works perfectly fine on the Xperia 10 II.
> >>>
> >>> 
> >>>
> > +/* Sony Xperia 5 (kumano bahamut) */
> > +static const struct drm_display_mode samsung_sofef01_m_bahamut_mode = {
> > +   /*
> > +* WARNING: These massive porches are wrong/useless for CMDmode
> > +* (and not defined in downstream DTS) but necessary to bump dsi
> > +* clocks higher, so that we can achieve proper 60fps without 
> > tearing.
> > +*/
> > +   .clock = (1080 + 156 + 8 + 8) * (2520 + 2393 + 8 + 8) * 60 / 1000,
> > +   .hdisplay = 1080,
> > +   .hsync_start = 1080 + 156,
> > +   .hsync_end = 1080 + 156 + 8,
> > +   .htotal = 1080 + 156 + 8 + 8,
> > +   .vdisplay = 2520,
> > +   .vsync_start = 2520 + 2393,
> > +   .vsync_end = 2520 + 2393 + 8,
> > +   .vtotal = 2520 + 2393 + 8 + 8,
> > +   .width_mm = 61,
> > +   .height_mm = 142,
> > +};
> > +
> > +/* Sony Xperia 10 II (seine pdx201) */
> > +static const struct drm_display_mode samsung_sofef01_m_pdx201_mode = {
> > +   .clock = (1080 + 8 + 8 + 8) * (2520 + 8 + 8 + 8) * 60 / 1000,
> > +   .hdisplay = 1080,
> > +   .hsync_start = 1080 + 8,
> > +   .hsync_end = 1080 + 8 + 8,
> > +   .htotal = 1080 + 8 + 8 + 8,
> > +   .vdisplay = 2520,
> > +   .vsync_start = 2520 + 8,
> > +   .vsync_end = 2520 + 8 + 8,
> > +   .vtotal = 2520 + 8 + 8 + 8,
> > +   .width_mm = 60,
> > +   .height_mm = 139,
> > +};
> > +
> > +static const struct of_device_id samsung_sofef01_m_of_match[] = {
> > +   { .compatible = "samsung,sofef01-m-bahamut", .data = 
> > _sofef01_m_bahamut_mode },
> > +   { .compatible = "samsung,sofef01-m-pdx201", .data = 
> > _sofef01_m_pdx201_mode },
> 
>  Are there really two panels? Can we use one mode for both usecases?
> >>>
> >>> See the commit description where I explained exactly this: the panels
> >>> have different dimensions (6.1" vs 6.0", hence different DPI) and I also
> >>> abuse this to hack in higher clock rates via fake porches.
> >>>
> >>> I just ended up on a scary website that supposedly contains the panel
> >>> names:
> >>>
> >>> - Xperia 5 (bahamut, 6.1"): AMB609TC01
> >>> - Xperia 10 II (pdx201, 6.0"): AMS597UT01
> >>
> >> Great! From the patch description it was not obvious if those are two
> >> different panels or a single panel with slight difference in the glass
> >> cover. With these names in place (well, with two distinct names in
> >> place) it makes sense.
> > 
> > For completeness: keep the current single file but embed these panel
> > names as suffix (eg. `samsung,sofef-01-m-am[bs]...`) to the compatible
> > (and document these more explicitly elsewhere)?
> 
> Where do the sofef parts of the name come from? Glancing at other 
> panels, I'd expect something simpler. Maybe:

That is the Driver-IC.  Sorry, I meant sofef01-m without the first dash,
matching the original compatibles.  But can also drop the dash in 01-m
if desired.

> samsung,sofef01m-amb60...

- Marijn

Re: [PATCH RFC 08/10] drm/panel/samsung-sofef03: Add panel driver for Sony Xperia 5 II

On 2023-05-30 01:22:54, Dmitry Baryshkov wrote:
> On 30/05/2023 00:29, Konrad Dybcio wrote:
> > 
> > 
> > On 29.05.2023 23:21, Marijn Suijten wrote:
> >> On 2023-05-22 11:08:12, Neil Armstrong wrote:
> >>> On 22/05/2023 03:23, Dmitry Baryshkov wrote:
>  On 22/05/2023 00:23, Marijn Suijten wrote:
> > The SOFEF03-M Display-IC paired with an unknown panel in the Sony Xperia
> > 5 II always uses Display Stream Compression 1.1 and features a 60hz and
> > 120hz refresh-rate mode.
> >
> > Co-developed-by: Konrad Dybcio 
> 
>  Konrad's S-o-b is also required then
> >>
> >> I am unsure what to include here, since Konrad originally "authored" the
> >> commit but I believe it was nothing more than a completely broken and
> >> unusable driver spit out by "The mdss panel generator".  This needed
> >> enough rewriting that I don't feel like giving it much credit ;)
> > Might have been. I won't be mad if you drop this!
> 
> I'd say, either add S-o-B, or drop C-D-B. The Co-developed-by should 
> always come with the Signed-of-by, otherwise one can not be sure that 
> the co-developer didn't copy-paste some super-proprietary stolen code.

That is effectively what the downstream command sequences are, with
their meaning removed :P

I'll drop it then, that makes most sense I think.

- Marijn

Re: [PATCH RFC 08/10] drm/panel/samsung-sofef03: Add panel driver for Sony Xperia 5 II


On 30/05/2023 00:29, Konrad Dybcio wrote:



On 29.05.2023 23:21, Marijn Suijten wrote:

On 2023-05-22 11:08:12, Neil Armstrong wrote:

On 22/05/2023 03:23, Dmitry Baryshkov wrote:

On 22/05/2023 00:23, Marijn Suijten wrote:

The SOFEF03-M Display-IC paired with an unknown panel in the Sony Xperia
5 II always uses Display Stream Compression 1.1 and features a 60hz and
120hz refresh-rate mode.

Co-developed-by: Konrad Dybcio 


Konrad's S-o-b is also required then


I am unsure what to include here, since Konrad originally "authored" the
commit but I believe it was nothing more than a completely broken and
unusable driver spit out by "The mdss panel generator".  This needed
enough rewriting that I don't feel like giving it much credit ;)

Might have been. I won't be mad if you drop this!


I'd say, either add S-o-B, or drop C-D-B. The Co-developed-by should 
always come with the Signed-of-by, otherwise one can not be sure that 
the co-developer didn't copy-paste some super-proprietary stolen code.




Konrad





Signed-off-by: Marijn Suijten 



--
With best wishes
Dmitry

Re: [PATCH RFC 06/10] drm/panel/samsung-sofef01: Add panel driver for Sony Xperia 5 / 10 II


On 29/05/2023 23:58, Marijn Suijten wrote:

On 2023-05-23 01:56:46, Dmitry Baryshkov wrote:

On Tue, 23 May 2023 at 01:32, Marijn Suijten
 wrote:


On 2023-05-22 04:19:45, Dmitry Baryshkov wrote:

On 22/05/2023 00:23, Marijn Suijten wrote:

This SOFEF01-M Display-IC driver supports two modes with different
compatibles to differentiate between slightly different physical sizes
(panels) found on the Xperia 5 (6.1") and 10 II (6.0").

It is currently also used to hardcode significantly higher fake porches
for the Xperia 5, which are unused in transfers due to this being a
command-mode panel but do have an effect on the clock rates set by
dsi_host.c.  Without higher clock rates this panel fails to achieve
60fps and has significant tearing artifacts, while the same calculated
clock rate works perfectly fine on the Xperia 10 II.





+/* Sony Xperia 5 (kumano bahamut) */
+static const struct drm_display_mode samsung_sofef01_m_bahamut_mode = {
+   /*
+* WARNING: These massive porches are wrong/useless for CMDmode
+* (and not defined in downstream DTS) but necessary to bump dsi
+* clocks higher, so that we can achieve proper 60fps without tearing.
+*/
+   .clock = (1080 + 156 + 8 + 8) * (2520 + 2393 + 8 + 8) * 60 / 1000,
+   .hdisplay = 1080,
+   .hsync_start = 1080 + 156,
+   .hsync_end = 1080 + 156 + 8,
+   .htotal = 1080 + 156 + 8 + 8,
+   .vdisplay = 2520,
+   .vsync_start = 2520 + 2393,
+   .vsync_end = 2520 + 2393 + 8,
+   .vtotal = 2520 + 2393 + 8 + 8,
+   .width_mm = 61,
+   .height_mm = 142,
+};
+
+/* Sony Xperia 10 II (seine pdx201) */
+static const struct drm_display_mode samsung_sofef01_m_pdx201_mode = {
+   .clock = (1080 + 8 + 8 + 8) * (2520 + 8 + 8 + 8) * 60 / 1000,
+   .hdisplay = 1080,
+   .hsync_start = 1080 + 8,
+   .hsync_end = 1080 + 8 + 8,
+   .htotal = 1080 + 8 + 8 + 8,
+   .vdisplay = 2520,
+   .vsync_start = 2520 + 8,
+   .vsync_end = 2520 + 8 + 8,
+   .vtotal = 2520 + 8 + 8 + 8,
+   .width_mm = 60,
+   .height_mm = 139,
+};
+
+static const struct of_device_id samsung_sofef01_m_of_match[] = {
+   { .compatible = "samsung,sofef01-m-bahamut", .data = 
_sofef01_m_bahamut_mode },
+   { .compatible = "samsung,sofef01-m-pdx201", .data = 
_sofef01_m_pdx201_mode },


Are there really two panels? Can we use one mode for both usecases?


See the commit description where I explained exactly this: the panels
have different dimensions (6.1" vs 6.0", hence different DPI) and I also
abuse this to hack in higher clock rates via fake porches.

I just ended up on a scary website that supposedly contains the panel
names:

- Xperia 5 (bahamut, 6.1"): AMB609TC01
- Xperia 10 II (pdx201, 6.0"): AMS597UT01


Great! From the patch description it was not obvious if those are two
different panels or a single panel with slight difference in the glass
cover. With these names in place (well, with two distinct names in
place) it makes sense.


For completeness: keep the current single file but embed these panel
names as suffix (eg. `samsung,sofef-01-m-am[bs]...`) to the compatible
(and document these more explicitly elsewhere)?


Where do the sofef parts of the name come from? Glancing at other 
panels, I'd expect something simpler. Maybe:


samsung,sofef01m-amb60...



- Marijn



--
With best wishes
Dmitry


--
With best wishes
Dmitry

Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3


On 30/05/2023 00:07, Marijn Suijten wrote:

On 2023-05-22 15:58:56, Dmitry Baryshkov wrote:

On Mon, 22 May 2023 at 12:04, Neil Armstrong  wrote:


On 22/05/2023 03:16, Dmitry Baryshkov wrote:

On 22/05/2023 00:23, Marijn Suijten wrote:

Sony provides an unlabeled LGD + Atmel maXTouch assembly in its Xperia
XZ3 (tama akatsuki) phone, with custom DCS commands to match.

This panel features Display Stream Compression 1.1.

Signed-off-by: Marijn Suijten 
---
   drivers/gpu/drm/panel/Kconfig   |  11 +
   drivers/gpu/drm/panel/Makefile  |   1 +
   drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c | 362 

   3 files changed, 374 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 67ef898d133f2..18bd116e78a71 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -706,6 +706,17 @@ config DRM_PANEL_SONY_ACX565AKM
 Say Y here if you want to enable support for the Sony ACX565AKM
 800x600 3.5" panel (found on the Nokia N900).
+config DRM_PANEL_SONY_AKATSUKI_LGD
+tristate "Sony Xperia XZ3 LGD panel"
+depends on GPIOLIB && OF
+depends on DRM_MIPI_DSI
+depends on BACKLIGHT_CLASS_DEVICE
+help
+  Say Y here if you want to enable support for the Sony Xperia XZ3
+  1440x2880@60 6.0" OLED DSI cmd mode panel produced by LG Display.
+
+  This panel uses Display Stream Compression 1.1.
+
   config DRM_PANEL_SONY_TD4353_JDI
   tristate "Sony TD4353 JDI panel"
   depends on GPIOLIB && OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index ff169781e82d7..85133f73558f3 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += 
panel-sitronix-st7701.o
   obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
   obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
   obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_SONY_AKATSUKI_LGD) += panel-sony-akatsuki-lgd.o
   obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
   obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) += 
panel-sony-tulip-truly-nt35521.o
   obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
diff --git a/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c 
b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
new file mode 100644
index 0..f55788f963dab
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Marijn Suijten 
+ *
+ * Based on Sony Downstream's "Atmel LGD ID5" Akatsuki panel dtsi.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sony_akatsuki_lgd {
+struct drm_panel panel;
+struct mipi_dsi_device *dsi;
+struct regulator *vddio;
+struct gpio_desc *reset_gpio;
+bool prepared;
+};
+
+static inline struct sony_akatsuki_lgd *to_sony_akatsuki_lgd(struct drm_panel 
*panel)
+{
+return container_of(panel, struct sony_akatsuki_lgd, panel);
+}
+
+static int sony_akatsuki_lgd_on(struct sony_akatsuki_lgd *ctx)
+{
+struct mipi_dsi_device *dsi = ctx->dsi;
+struct device *dev = >dev;
+int ret;
+
+dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0x02, 0x01);
+mipi_dsi_dcs_write_seq(dsi, 0x59, 0x01);
+/* Enable backlight control */
+mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, BIT(5));
+mipi_dsi_dcs_write_seq(dsi, 0x57, 0x20, 0x80, 0xde, 0x60, 0x00);
+
+ret = mipi_dsi_dcs_set_column_address(dsi, 0, 1440 - 1);
+if (ret < 0) {
+dev_err(dev, "Failed to set column address: %d\n", ret);
+return ret;
+}
+
+ret = mipi_dsi_dcs_set_page_address(dsi, 0, 2880 - 1);
+if (ret < 0) {
+dev_err(dev, "Failed to set page address: %d\n", ret);
+return ret;
+}
+
+mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_POWER_SAVE, 0x00);
+
+ret = mipi_dsi_dcs_set_tear_on(dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+if (ret < 0) {
+dev_err(dev, "Failed to set tear on: %d\n", ret);
+return ret;
+}
+
+mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
+mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x03);
+mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x04);
+mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x05);
+mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x01, 0x7f, 0x00);
+
+ret =

Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3


On 30/05/2023 00:11, Marijn Suijten wrote:

On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:


+   if (ctx->dsi->dsc) {


dsi->dsc is always set, thus this condition can be dropped.


I want to leave room for possibly running the panel without DSC (at a
lower resolution/refresh rate, or at higher power consumption if there
is enough BW) by not assigning the pointer, if we get access to panel
documentation: probably one of the magic commands sent in this driver
controls it but we don't know which.


+   drm_dsc_pps_payload_pack(, ctx->dsi->dsc);
+
+   ret = mipi_dsi_picture_parameter_set(ctx->dsi, );
+   if (ret < 0) {
+   dev_err(panel->dev, "failed to transmit PPS: %d\n", 
ret);
+   goto fail;
+   }
+   ret = mipi_dsi_compression_mode(ctx->dsi, true);
+   if (ret < 0) {
+   dev_err(dev, "failed to enable compression mode: %d\n", 
ret);
+   goto fail;
+   }
+
+   msleep(28);
+   }
+
+   ctx->prepared = true;
+   return 0;
+
+fail:
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   regulator_disable(ctx->vddio);
+   return ret;
+}



+   /* This panel only supports DSC; unconditionally enable it */


On that note I should perhaps reword this.


+   dsi->dsc = dsc = devm_kzalloc(>dev, sizeof(*dsc), GFP_KERNEL);


I think double assignments are frowned upon.


Ack.




+   if (!dsc)
+   return -ENOMEM;
+
+   dsc->dsc_version_major = 1;
+   dsc->dsc_version_minor = 1;
+
+   dsc->slice_height = 32;
+   dsc->slice_count = 2;
+   // TODO: Get hdisplay from the mode


Would you like to fix the TODO?


I can't unless either migrating to drm_bridge (is that doable?) or
expand drm_panel.  That's a larger task, but I don't think this driver
is the right place to track that desire.  Should I drop the comment
entirely or reword it?


I'd say, reword it, so that it becomes more obvious why this TODO can 
not be fixed at this moment.





+   WARN_ON(1440 % dsc->slice_count);
+   dsc->slice_width = 1440 / dsc->slice_count;




- Marijn


--
With best wishes
Dmitry

Re: [PATCH] drm/msm/dpu: use PINGPONG_NONE to unbind INTF from PP

On Tue, 30 May 2023 at 00:46, Marijn Suijten
 wrote:
>
> On 2023-05-26 12:09:45, Dmitry Baryshkov wrote:
> > Currently the driver passes the PINGPONG index to
> > dpu_hw_intf_ops::bind_pingpong_blk() callback and uses separate boolean
> > flag to tell whether INTF should be bound or unbound. Simplify this by
> > passing PINGPONG_NONE in case of unbinding and drop the flag completely.
>
> Perhaps worth mentioning that this flag was only recently introduced
> (and link to it as a dependency under the cut),

The patch is already a part of linux-next. This is the usual boundary
of skipping the dependencies.

>  as well as explain that
> the passed `enum dpu_pingpong` value is bogus when enable=false because
> it is not part of the value written to the register for the
> "unbind/disable" case?

Good suggestion.

>  See for example the wording I suggested on the
> patch that introduces and uses PINGPONG_NONE.
>
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 4 ++--
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 +---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 1 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  | 3 +--
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 1 -
>
> How about appending/sending another patch that drops this from
> dpu_hw_wb.c as well?

Ack, nice catch.

>
> >  5 files changed, 4 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index ebe34eda6e50..7fd3a13ac226 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -2102,8 +2102,8 @@ void dpu_encoder_helper_phys_cleanup(struct 
> > dpu_encoder_phys *phys_enc)
> >   for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> >   if (dpu_enc->phys_encs[i] && 
> > phys_enc->hw_intf->ops.bind_pingpong_blk)
> >   phys_enc->hw_intf->ops.bind_pingpong_blk(
> > - 
> > dpu_enc->phys_encs[i]->hw_intf, false,
> > - 
> > dpu_enc->phys_encs[i]->hw_pp->idx);
> > + 
> > dpu_enc->phys_encs[i]->hw_intf,
> > + PINGPONG_NONE);
> >
> >   /* mark INTF flush as pending */
> >   if (phys_enc->hw_ctl->ops.update_pending_flush_intf)
> > 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 1a4c20f02312..3130c86a32cc 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
> > @@ -66,7 +66,6 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
> >   if (test_bit(DPU_CTL_ACTIVE_CFG, >caps->features) && 
> > phys_enc->hw_intf->ops.bind_pingpong_blk)
> >   phys_enc->hw_intf->ops.bind_pingpong_blk(
> >   phys_enc->hw_intf,
> > - true,
> >   phys_enc->hw_pp->idx);
> >
> >   if (phys_enc->hw_intf->ops.enable_compression)
> > @@ -556,8 +555,7 @@ static void dpu_encoder_phys_cmd_disable(struct 
> > dpu_encoder_phys *phys_enc)
> >   if (phys_enc->hw_intf->ops.bind_pingpong_blk) {
> >   phys_enc->hw_intf->ops.bind_pingpong_blk(
> >   phys_enc->hw_intf,
> > - false,
> > - phys_enc->hw_pp->idx);
> > + PINGPONG_NONE);
>
> Is there also a cleanup state where hw_pp is assigned back to NULL?

No. None of the encoder resources are reassigned to NULL. I will tend
this topic during vN of resource allocation rework.

>
> >   ctl = phys_enc->hw_ctl;
> >   ctl->ops.update_pending_flush_intf(ctl, phys_enc->intf_idx);
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> > index 3a374292f311..220020273304 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> > @@ -287,7 +287,6 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
> >   if (phys_enc->hw_intf->ops.bind_pingpong_blk)
> >   phys_enc->hw_intf->ops.bind_pingpong_blk(
> >   phys_enc->hw_intf,
> > - true,
> >   phys_enc->hw_pp->idx);
> >
> >   if (phys_enc->hw_pp->merge_3d)
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > index a2486f99d3c2..918d154848b9 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > +++

Re: [PATCH v3 6/6] drm/shmem-helper: Switch to reservation lock

On 5/22/23 16:02, Emil Velikov wrote:
>> -void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
>> +static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem)
>> +{
>> +   int ret;
>> +
>> +   dma_resv_assert_held(shmem->base.resv);
>> +
>> +   ret = drm_gem_shmem_get_pages(shmem);
>> +
>> +   return ret;
> With the assert_held in the getter, it would be less confusing to
> inline this and the unpin_locked functions.

Sorry, missed this comment earlier. The reason why it's a separate
function is because there will be another caller once we'll add the
drm-shrinker.

-- 
Best regards,
Dmitry

Re: [PATCH] drm/msm/dpu: use PINGPONG_NONE to unbind INTF from PP

On 2023-05-26 12:09:45, Dmitry Baryshkov wrote:
> Currently the driver passes the PINGPONG index to
> dpu_hw_intf_ops::bind_pingpong_blk() callback and uses separate boolean
> flag to tell whether INTF should be bound or unbound. Simplify this by
> passing PINGPONG_NONE in case of unbinding and drop the flag completely.

Perhaps worth mentioning that this flag was only recently introduced
(and link to it as a dependency under the cut), as well as explain that
the passed `enum dpu_pingpong` value is bogus when enable=false because
it is not part of the value written to the register for the
"unbind/disable" case?  See for example the wording I suggested on the
patch that introduces and uses PINGPONG_NONE.

> Signed-off-by: Dmitry Baryshkov 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 4 ++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 +---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  | 3 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 1 -

How about appending/sending another patch that drops this from
dpu_hw_wb.c as well?

>  5 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index ebe34eda6e50..7fd3a13ac226 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2102,8 +2102,8 @@ void dpu_encoder_helper_phys_cleanup(struct 
> dpu_encoder_phys *phys_enc)
>   for (i = 0; i < dpu_enc->num_phys_encs; i++) {
>   if (dpu_enc->phys_encs[i] && 
> phys_enc->hw_intf->ops.bind_pingpong_blk)
>   phys_enc->hw_intf->ops.bind_pingpong_blk(
> - dpu_enc->phys_encs[i]->hw_intf, 
> false,
> - 
> dpu_enc->phys_encs[i]->hw_pp->idx);
> + dpu_enc->phys_encs[i]->hw_intf,
> + PINGPONG_NONE);
>  
>   /* mark INTF flush as pending */
>   if (phys_enc->hw_ctl->ops.update_pending_flush_intf)
> 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 1a4c20f02312..3130c86a32cc 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
> @@ -66,7 +66,6 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
>   if (test_bit(DPU_CTL_ACTIVE_CFG, >caps->features) && 
> phys_enc->hw_intf->ops.bind_pingpong_blk)
>   phys_enc->hw_intf->ops.bind_pingpong_blk(
>   phys_enc->hw_intf,
> - true,
>   phys_enc->hw_pp->idx);
>  
>   if (phys_enc->hw_intf->ops.enable_compression)
> @@ -556,8 +555,7 @@ static void dpu_encoder_phys_cmd_disable(struct 
> dpu_encoder_phys *phys_enc)
>   if (phys_enc->hw_intf->ops.bind_pingpong_blk) {
>   phys_enc->hw_intf->ops.bind_pingpong_blk(
>   phys_enc->hw_intf,
> - false,
> - phys_enc->hw_pp->idx);
> + PINGPONG_NONE);

Is there also a cleanup state where hw_pp is assigned back to NULL?

>   ctl = phys_enc->hw_ctl;
>   ctl->ops.update_pending_flush_intf(ctl, phys_enc->intf_idx);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> index 3a374292f311..220020273304 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> @@ -287,7 +287,6 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
>   if (phys_enc->hw_intf->ops.bind_pingpong_blk)
>   phys_enc->hw_intf->ops.bind_pingpong_blk(
>   phys_enc->hw_intf,
> - true,
>   phys_enc->hw_pp->idx);
>  
>   if (phys_enc->hw_pp->merge_3d)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index a2486f99d3c2..918d154848b9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> @@ -268,7 +268,6 @@ static void dpu_hw_intf_setup_prg_fetch(
>  
>  static void dpu_hw_intf_bind_pingpong_blk(
>   struct dpu_hw_intf *intf,
> - bool enable,
>   const enum dpu_pingpong pp)
>  {
>   struct dpu_hw_blk_reg_map *c = >hw;
> @@ -277,7 +276,7 @@ static void dpu_hw_intf_bind_pingpong_blk(
>   mux_cfg = DPU_REG_READ(c, INTF_MUX);
>   mux_cfg &= ~0xf;
>  
> - if (enable)
> + if (pp != PINGPONG_NONE)

Kuogee just used `if

Re: [PATCH 1/2] drm/msm/dpu: drop SSPP register dumpers

On 2023-05-24 12:18:09, Abhinav Kumar wrote:
> 
> 
> On 5/24/2023 2:48 AM, Marijn Suijten wrote:
> > On 2023-05-23 13:01:13, Abhinav Kumar wrote:
> >>
> >>
> >> On 5/21/2023 10:21 AM, Dmitry Baryshkov wrote:
> >>> Drop SSPP-specifig debugfs register dumps in favour of using
> >>> debugfs/dri/0/kms or devcoredump.
> >>>
> >>
> >> I did see another series which removes src_blk from the catalog (I am
> >> yet to review that one) . Lets assume that one is fine and this change
> >> will be going on top of that one right?
> > 
> > It replaces src_blk with directly accessing the blk (non-sub-block)
> > directly, because they were overlapping anyway.
> > 
> >> The concern I have with this change is that although I do agree that we
> >> should be in favor of using debugfs/dri/0/kms ( i have used it a few
> >> times and it works pretty well ), devcoredump does not have the support
> >> to dump sub-blocks . Something which we should add with priority because
> >> even with DSC blocks with the separation of enc/ctl blocks we need that
> >> like I wrote in one of the responses.
> >>
> >> So the "len" of the blocks having sub-blocks will be ignored in favor of
> >> the len of the sub-blocks.
> > 
> > The sub-blocks are not always contiguous with their parent block, are
> > they?  It's probably better to print the sub-blocks separately with
> 
> Yes, not contiguous otherwise we could have just had them in one big range.
> 
> > clear headers anyway rather than dumping the range parent_blk_base to
> > max(parent_blk_base+len, parent_blk_base+sblk_base+sblk_len...).
> > 
> > - Marijn
> 
> When I meant sub-block support to devcoredump, this is how I visualize 
> them to be printed
> 
> =SSPP xxx ===
> =SSPP_CSC ===(for SSPP_xxx)
> =SSPP_QSEED =(for SSPP_xxx)

Yeah something along those lines, though I don't really like the `(for
SSPP_xxx)` suffix which we should either drop entirely and make the
"heading" less of a "heading"

= SSPP xxx ===
...
- SSPP_CSC ---
...
- SSPP_QSEED -
...

And/or inline the numbers:

= SSPP xxx ===
...
--- SSPP_xxx_CSC -
...
-- SSPP_xxx_QSEED 
...

Either works, or any other pattern in the title (e.g `SSPP xxx: CSC`)
that clearly tells the blocks and sub-blocks apart.

- Marijn

Re: [PATCH RFC 08/10] drm/panel/samsung-sofef03: Add panel driver for Sony Xperia 5 II




On 29.05.2023 23:21, Marijn Suijten wrote:
> On 2023-05-22 11:08:12, Neil Armstrong wrote:
>> On 22/05/2023 03:23, Dmitry Baryshkov wrote:
>>> On 22/05/2023 00:23, Marijn Suijten wrote:
 The SOFEF03-M Display-IC paired with an unknown panel in the Sony Xperia
 5 II always uses Display Stream Compression 1.1 and features a 60hz and
 120hz refresh-rate mode.

 Co-developed-by: Konrad Dybcio 
>>>
>>> Konrad's S-o-b is also required then
> 
> I am unsure what to include here, since Konrad originally "authored" the
> commit but I believe it was nothing more than a completely broken and
> unusable driver spit out by "The mdss panel generator".  This needed
> enough rewriting that I don't feel like giving it much credit ;)
Might have been. I won't be mad if you drop this!

Konrad
> 
>>>
 Signed-off-by: Marijn Suijten 
 ---
   drivers/gpu/drm/panel/Kconfig |  14 +
   drivers/gpu/drm/panel/Makefile    |   1 +
   drivers/gpu/drm/panel/panel-samsung-sofef03.c | 423 
 ++
   3 files changed, 438 insertions(+)

 diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
 index 3f11e9906f2cb..8e2668153bce2 100644
 --- a/drivers/gpu/drm/panel/Kconfig
 +++ b/drivers/gpu/drm/panel/Kconfig
 @@ -630,6 +630,20 @@ config DRM_PANEL_SAMSUNG_SOFEF01
     This panel features a fixed mode of 1080x2520@60.
 +config DRM_PANEL_SAMSUNG_SOFEF03
 +    tristate "Samsung sofef03 Sony Xperia 5 II DSI cmd mode panel"
 +    depends on GPIOLIB
 +    depends on OF
 +    depends on DRM_MIPI_DSI
 +    depends on BACKLIGHT_CLASS_DEVICE
 +    help
 +  Say Y or M here if you want to enable support for the Samsung AMOLED
 +  command mode panel found in the Sony Xperia 5 II smartphone.
 +
 +  This panel uses Display Stream Compression 1.1.
 +
 +  The panel features a 1080x2520@60 and 1080x2520@120 mode.
 +
   config DRM_PANEL_SEIKO_43WVF1G
   tristate "Seiko 43WVF1G panel"
   depends on OF
 diff --git a/drivers/gpu/drm/panel/Makefile 
 b/drivers/gpu/drm/panel/Makefile
 index a4039d0fc9cfb..52dcd82e33120 100644
 --- a/drivers/gpu/drm/panel/Makefile
 +++ b/drivers/gpu/drm/panel/Makefile
 @@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01) += 
 panel-samsung-s6e88a0-ams4
   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
   obj-$(CONFIG_DRM_PANEL_SAMSUNG_SOFEF00) += panel-samsung-sofef00.o
   obj-$(CONFIG_DRM_PANEL_SAMSUNG_SOFEF01) += panel-samsung-sofef01.o
 +obj-$(CONFIG_DRM_PANEL_SAMSUNG_SOFEF03) += panel-samsung-sofef03.o
   obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
   obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
 diff --git a/drivers/gpu/drm/panel/panel-samsung-sofef03.c 
 b/drivers/gpu/drm/panel/panel-samsung-sofef03.c
 new file mode 100644
 index 0..2763e1c56b37b
 --- /dev/null
 +++ b/drivers/gpu/drm/panel/panel-samsung-sofef03.c
 @@ -0,0 +1,423 @@
 +// SPDX-License-Identifier: GPL-2.0-only
 +/*
 + * Copyright (c) 2022 Konrad Dybcio 
 + * Copyright (c) 2023 Marijn Suijten 
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +static const bool enable_120hz = true;
>>
>> Maybe this can be a module parameter ? Can you explain why this can't be 
>> dynamically changed by a modeset ?
>>
 +
 +struct samsung_sofef03_m {
 +    struct drm_panel panel;
 +    struct mipi_dsi_device *dsi;
 +    struct regulator *vddio, *vci;
 +    struct gpio_desc *reset_gpio;
 +    bool prepared;
 +};
 +
 +static inline struct samsung_sofef03_m *to_samsung_sofef03_m(struct 
 drm_panel *panel)
 +{
 +    return container_of(panel, struct samsung_sofef03_m, panel);
 +}
 +
 +static void samsung_sofef03_m_reset(struct samsung_sofef03_m *ctx)
 +{
 +    gpiod_set_value_cansleep(ctx->reset_gpio, 0);
 +    usleep_range(1, 11000);
 +}
 +
 +static int samsung_sofef03_m_on(struct samsung_sofef03_m *ctx)
 +{
 +    struct mipi_dsi_device *dsi = ctx->dsi;
 +    struct device *dev = >dev;
 +    int ret;
 +
 +    dsi->mode_flags |= MIPI_DSI_MODE_LPM;
 +
 +    mipi_dsi_dcs_write_seq(dsi, 0x9d, 0x01);
 +
 +    ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
 +    if (ret < 0) {
 +    dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
 +    return ret;
 +    }
 +    usleep_range(1, 11000);
 +
 +    mipi_dsi_dcs_write_seq(dsi, 0xf0,

Re: [PATCH RFC 08/10] drm/panel/samsung-sofef03: Add panel driver for Sony Xperia 5 II

On 2023-05-22 11:08:12, Neil Armstrong wrote:
> On 22/05/2023 03:23, Dmitry Baryshkov wrote:
> > On 22/05/2023 00:23, Marijn Suijten wrote:
> >> The SOFEF03-M Display-IC paired with an unknown panel in the Sony Xperia
> >> 5 II always uses Display Stream Compression 1.1 and features a 60hz and
> >> 120hz refresh-rate mode.
> >>
> >> Co-developed-by: Konrad Dybcio 
> > 
> > Konrad's S-o-b is also required then

I am unsure what to include here, since Konrad originally "authored" the
commit but I believe it was nothing more than a completely broken and
unusable driver spit out by "The mdss panel generator".  This needed
enough rewriting that I don't feel like giving it much credit ;)

> > 
> >> Signed-off-by: Marijn Suijten 
> >> ---
> >>   drivers/gpu/drm/panel/Kconfig |  14 +
> >>   drivers/gpu/drm/panel/Makefile    |   1 +
> >>   drivers/gpu/drm/panel/panel-samsung-sofef03.c | 423 
> >> ++
> >>   3 files changed, 438 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> >> index 3f11e9906f2cb..8e2668153bce2 100644
> >> --- a/drivers/gpu/drm/panel/Kconfig
> >> +++ b/drivers/gpu/drm/panel/Kconfig
> >> @@ -630,6 +630,20 @@ config DRM_PANEL_SAMSUNG_SOFEF01
> >>     This panel features a fixed mode of 1080x2520@60.
> >> +config DRM_PANEL_SAMSUNG_SOFEF03
> >> +    tristate "Samsung sofef03 Sony Xperia 5 II DSI cmd mode panel"
> >> +    depends on GPIOLIB
> >> +    depends on OF
> >> +    depends on DRM_MIPI_DSI
> >> +    depends on BACKLIGHT_CLASS_DEVICE
> >> +    help
> >> +  Say Y or M here if you want to enable support for the Samsung AMOLED
> >> +  command mode panel found in the Sony Xperia 5 II smartphone.
> >> +
> >> +  This panel uses Display Stream Compression 1.1.
> >> +
> >> +  The panel features a 1080x2520@60 and 1080x2520@120 mode.
> >> +
> >>   config DRM_PANEL_SEIKO_43WVF1G
> >>   tristate "Seiko 43WVF1G panel"
> >>   depends on OF
> >> diff --git a/drivers/gpu/drm/panel/Makefile 
> >> b/drivers/gpu/drm/panel/Makefile
> >> index a4039d0fc9cfb..52dcd82e33120 100644
> >> --- a/drivers/gpu/drm/panel/Makefile
> >> +++ b/drivers/gpu/drm/panel/Makefile
> >> @@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01) += 
> >> panel-samsung-s6e88a0-ams4
> >>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
> >>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_SOFEF00) += panel-samsung-sofef00.o
> >>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_SOFEF01) += panel-samsung-sofef01.o
> >> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_SOFEF03) += panel-samsung-sofef03.o
> >>   obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
> >>   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> >>   obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> >> diff --git a/drivers/gpu/drm/panel/panel-samsung-sofef03.c 
> >> b/drivers/gpu/drm/panel/panel-samsung-sofef03.c
> >> new file mode 100644
> >> index 0..2763e1c56b37b
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/panel/panel-samsung-sofef03.c
> >> @@ -0,0 +1,423 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * Copyright (c) 2022 Konrad Dybcio 
> >> + * Copyright (c) 2023 Marijn Suijten 
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +static const bool enable_120hz = true;
> 
> Maybe this can be a module parameter ? Can you explain why this can't be 
> dynamically changed by a modeset ?
> 
> >> +
> >> +struct samsung_sofef03_m {
> >> +    struct drm_panel panel;
> >> +    struct mipi_dsi_device *dsi;
> >> +    struct regulator *vddio, *vci;
> >> +    struct gpio_desc *reset_gpio;
> >> +    bool prepared;
> >> +};
> >> +
> >> +static inline struct samsung_sofef03_m *to_samsung_sofef03_m(struct 
> >> drm_panel *panel)
> >> +{
> >> +    return container_of(panel, struct samsung_sofef03_m, panel);
> >> +}
> >> +
> >> +static void samsung_sofef03_m_reset(struct samsung_sofef03_m *ctx)
> >> +{
> >> +    gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> >> +    usleep_range(1, 11000);
> >> +}
> >> +
> >> +static int samsung_sofef03_m_on(struct samsung_sofef03_m *ctx)
> >> +{
> >> +    struct mipi_dsi_device *dsi = ctx->dsi;
> >> +    struct device *dev = >dev;
> >> +    int ret;
> >> +
> >> +    dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> >> +
> >> +    mipi_dsi_dcs_write_seq(dsi, 0x9d, 0x01);
> >> +
> >> +    ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> >> +    if (ret < 0) {
> >> +    dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> >> +    return ret;
> >> +    }
> >> +    usleep_range(1, 11000);
> >> +
> >> +    mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
> >> +    mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x09);
> >> +    mipi_dsi_dcs_write_seq(dsi, 0xd5, 0x00, 0x00,

Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3

On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:

> > +   if (ctx->dsi->dsc) {
> 
> dsi->dsc is always set, thus this condition can be dropped.

I want to leave room for possibly running the panel without DSC (at a
lower resolution/refresh rate, or at higher power consumption if there
is enough BW) by not assigning the pointer, if we get access to panel
documentation: probably one of the magic commands sent in this driver
controls it but we don't know which.

> > +   drm_dsc_pps_payload_pack(, ctx->dsi->dsc);
> > +
> > +   ret = mipi_dsi_picture_parameter_set(ctx->dsi, );
> > +   if (ret < 0) {
> > +   dev_err(panel->dev, "failed to transmit PPS: %d\n", 
> > ret);
> > +   goto fail;
> > +   }
> > +   ret = mipi_dsi_compression_mode(ctx->dsi, true);
> > +   if (ret < 0) {
> > +   dev_err(dev, "failed to enable compression mode: %d\n", 
> > ret);
> > +   goto fail;
> > +   }
> > +
> > +   msleep(28);
> > +   }
> > +
> > +   ctx->prepared = true;
> > +   return 0;
> > +
> > +fail:
> > +   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> > +   regulator_disable(ctx->vddio);
> > +   return ret;
> > +}

> > +   /* This panel only supports DSC; unconditionally enable it */

On that note I should perhaps reword this.

> > +   dsi->dsc = dsc = devm_kzalloc(>dev, sizeof(*dsc), GFP_KERNEL);
> 
> I think double assignments are frowned upon.

Ack.

> 
> > +   if (!dsc)
> > +   return -ENOMEM;
> > +
> > +   dsc->dsc_version_major = 1;
> > +   dsc->dsc_version_minor = 1;
> > +
> > +   dsc->slice_height = 32;
> > +   dsc->slice_count = 2;
> > +   // TODO: Get hdisplay from the mode
> 
> Would you like to fix the TODO?

I can't unless either migrating to drm_bridge (is that doable?) or
expand drm_panel.  That's a larger task, but I don't think this driver
is the right place to track that desire.  Should I drop the comment
entirely or reword it?

> > +   WARN_ON(1440 % dsc->slice_count);
> > +   dsc->slice_width = 1440 / dsc->slice_count;

- Marijn

Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3

On 2023-05-22 15:58:56, Dmitry Baryshkov wrote:
> On Mon, 22 May 2023 at 12:04, Neil Armstrong  
> wrote:
> >
> > On 22/05/2023 03:16, Dmitry Baryshkov wrote:
> > > On 22/05/2023 00:23, Marijn Suijten wrote:
> > >> Sony provides an unlabeled LGD + Atmel maXTouch assembly in its Xperia
> > >> XZ3 (tama akatsuki) phone, with custom DCS commands to match.
> > >>
> > >> This panel features Display Stream Compression 1.1.
> > >>
> > >> Signed-off-by: Marijn Suijten 
> > >> ---
> > >>   drivers/gpu/drm/panel/Kconfig   |  11 +
> > >>   drivers/gpu/drm/panel/Makefile  |   1 +
> > >>   drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c | 362 
> > >> 
> > >>   3 files changed, 374 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/panel/Kconfig 
> > >> b/drivers/gpu/drm/panel/Kconfig
> > >> index 67ef898d133f2..18bd116e78a71 100644
> > >> --- a/drivers/gpu/drm/panel/Kconfig
> > >> +++ b/drivers/gpu/drm/panel/Kconfig
> > >> @@ -706,6 +706,17 @@ config DRM_PANEL_SONY_ACX565AKM
> > >> Say Y here if you want to enable support for the Sony ACX565AKM
> > >> 800x600 3.5" panel (found on the Nokia N900).
> > >> +config DRM_PANEL_SONY_AKATSUKI_LGD
> > >> +tristate "Sony Xperia XZ3 LGD panel"
> > >> +depends on GPIOLIB && OF
> > >> +depends on DRM_MIPI_DSI
> > >> +depends on BACKLIGHT_CLASS_DEVICE
> > >> +help
> > >> +  Say Y here if you want to enable support for the Sony Xperia XZ3
> > >> +  1440x2880@60 6.0" OLED DSI cmd mode panel produced by LG Display.
> > >> +
> > >> +  This panel uses Display Stream Compression 1.1.
> > >> +
> > >>   config DRM_PANEL_SONY_TD4353_JDI
> > >>   tristate "Sony TD4353 JDI panel"
> > >>   depends on GPIOLIB && OF
> > >> diff --git a/drivers/gpu/drm/panel/Makefile 
> > >> b/drivers/gpu/drm/panel/Makefile
> > >> index ff169781e82d7..85133f73558f3 100644
> > >> --- a/drivers/gpu/drm/panel/Makefile
> > >> +++ b/drivers/gpu/drm/panel/Makefile
> > >> @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += 
> > >> panel-sitronix-st7701.o
> > >>   obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
> > >>   obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> > >>   obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> > >> +obj-$(CONFIG_DRM_PANEL_SONY_AKATSUKI_LGD) += panel-sony-akatsuki-lgd.o
> > >>   obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
> > >>   obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) += 
> > >> panel-sony-tulip-truly-nt35521.o
> > >>   obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
> > >> diff --git a/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c 
> > >> b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
> > >> new file mode 100644
> > >> index 0..f55788f963dab
> > >> --- /dev/null
> > >> +++ b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
> > >> @@ -0,0 +1,362 @@
> > >> +// SPDX-License-Identifier: GPL-2.0-only
> > >> +/*
> > >> + * Copyright (c) 2023 Marijn Suijten 
> > >> + *
> > >> + * Based on Sony Downstream's "Atmel LGD ID5" Akatsuki panel dtsi.
> > >> + */
> > >> +
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +
> > >> +#include 
> > >> +
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +
> > >> +struct sony_akatsuki_lgd {
> > >> +struct drm_panel panel;
> > >> +struct mipi_dsi_device *dsi;
> > >> +struct regulator *vddio;
> > >> +struct gpio_desc *reset_gpio;
> > >> +bool prepared;
> > >> +};
> > >> +
> > >> +static inline struct sony_akatsuki_lgd *to_sony_akatsuki_lgd(struct 
> > >> drm_panel *panel)
> > >> +{
> > >> +return container_of(panel, struct sony_akatsuki_lgd, panel);
> > >> +}
> > >> +
> > >> +static int sony_akatsuki_lgd_on(struct sony_akatsuki_lgd *ctx)
> > >> +{
> > >> +struct mipi_dsi_device *dsi = ctx->dsi;
> > >> +struct device *dev = >dev;
> > >> +int ret;
> > >> +
> > >> +dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> > >> +
> > >> +mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
> > >> +mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
> > >> +mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
> > >> +mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
> > >> +mipi_dsi_dcs_write_seq(dsi, 0x02, 0x01);
> > >> +mipi_dsi_dcs_write_seq(dsi, 0x59, 0x01);
> > >> +/* Enable backlight control */
> > >> +mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, BIT(5));
> > >> +mipi_dsi_dcs_write_seq(dsi, 0x57, 0x20, 0x80, 0xde, 0x60, 0x00);
> > >> +
> > >> +ret = mipi_dsi_dcs_set_column_address(dsi, 0, 1440 - 1);
> > >> +if (ret < 0) {
> > >> +dev_err(dev, "Failed to set column address: %d\n", ret);
> > >> +return ret;
> > >> +}
> > >> +
> > >> +ret = mipi_dsi_dcs_set_page_address(dsi, 0, 2880 - 1);
>

Re: [PATCH RFC 06/10] drm/panel/samsung-sofef01: Add panel driver for Sony Xperia 5 / 10 II

On 2023-05-23 01:56:46, Dmitry Baryshkov wrote:
> On Tue, 23 May 2023 at 01:32, Marijn Suijten
>  wrote:
> >
> > On 2023-05-22 04:19:45, Dmitry Baryshkov wrote:
> > > On 22/05/2023 00:23, Marijn Suijten wrote:
> > > > This SOFEF01-M Display-IC driver supports two modes with different
> > > > compatibles to differentiate between slightly different physical sizes
> > > > (panels) found on the Xperia 5 (6.1") and 10 II (6.0").
> > > >
> > > > It is currently also used to hardcode significantly higher fake porches
> > > > for the Xperia 5, which are unused in transfers due to this being a
> > > > command-mode panel but do have an effect on the clock rates set by
> > > > dsi_host.c.  Without higher clock rates this panel fails to achieve
> > > > 60fps and has significant tearing artifacts, while the same calculated
> > > > clock rate works perfectly fine on the Xperia 10 II.
> >
> > 
> >
> > > > +/* Sony Xperia 5 (kumano bahamut) */
> > > > +static const struct drm_display_mode samsung_sofef01_m_bahamut_mode = {
> > > > +   /*
> > > > +* WARNING: These massive porches are wrong/useless for CMDmode
> > > > +* (and not defined in downstream DTS) but necessary to bump dsi
> > > > +* clocks higher, so that we can achieve proper 60fps without 
> > > > tearing.
> > > > +*/
> > > > +   .clock = (1080 + 156 + 8 + 8) * (2520 + 2393 + 8 + 8) * 60 / 1000,
> > > > +   .hdisplay = 1080,
> > > > +   .hsync_start = 1080 + 156,
> > > > +   .hsync_end = 1080 + 156 + 8,
> > > > +   .htotal = 1080 + 156 + 8 + 8,
> > > > +   .vdisplay = 2520,
> > > > +   .vsync_start = 2520 + 2393,
> > > > +   .vsync_end = 2520 + 2393 + 8,
> > > > +   .vtotal = 2520 + 2393 + 8 + 8,
> > > > +   .width_mm = 61,
> > > > +   .height_mm = 142,
> > > > +};
> > > > +
> > > > +/* Sony Xperia 10 II (seine pdx201) */
> > > > +static const struct drm_display_mode samsung_sofef01_m_pdx201_mode = {
> > > > +   .clock = (1080 + 8 + 8 + 8) * (2520 + 8 + 8 + 8) * 60 / 1000,
> > > > +   .hdisplay = 1080,
> > > > +   .hsync_start = 1080 + 8,
> > > > +   .hsync_end = 1080 + 8 + 8,
> > > > +   .htotal = 1080 + 8 + 8 + 8,
> > > > +   .vdisplay = 2520,
> > > > +   .vsync_start = 2520 + 8,
> > > > +   .vsync_end = 2520 + 8 + 8,
> > > > +   .vtotal = 2520 + 8 + 8 + 8,
> > > > +   .width_mm = 60,
> > > > +   .height_mm = 139,
> > > > +};
> > > > +
> > > > +static const struct of_device_id samsung_sofef01_m_of_match[] = {
> > > > +   { .compatible = "samsung,sofef01-m-bahamut", .data = 
> > > > _sofef01_m_bahamut_mode },
> > > > +   { .compatible = "samsung,sofef01-m-pdx201", .data = 
> > > > _sofef01_m_pdx201_mode },
> > >
> > > Are there really two panels? Can we use one mode for both usecases?
> >
> > See the commit description where I explained exactly this: the panels
> > have different dimensions (6.1" vs 6.0", hence different DPI) and I also
> > abuse this to hack in higher clock rates via fake porches.
> >
> > I just ended up on a scary website that supposedly contains the panel
> > names:
> >
> > - Xperia 5 (bahamut, 6.1"): AMB609TC01
> > - Xperia 10 II (pdx201, 6.0"): AMS597UT01
> 
> Great! From the patch description it was not obvious if those are two
> different panels or a single panel with slight difference in the glass
> cover. With these names in place (well, with two distinct names in
> place) it makes sense.

For completeness: keep the current single file but embed these panel
names as suffix (eg. `samsung,sofef-01-m-am[bs]...`) to the compatible
(and document these more explicitly elsewhere)?

- Marijn

> 
> -- 
> With best wishes
> Dmitry

[Bug 217499] NVIDIA drivers fail to install on 6.4.0-rc3-1-mainline kernel

2023-05-29 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=217499

Wessel (wessel.working+ker...@gmail.com) changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|ANSWERED|MOVED

--- Comment #2 from Wessel (wessel.working+ker...@gmail.com) ---
Thank you! Will do!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH v4 13/13] drm/i915: Implement dedicated fbdev I/O helpers

Hi Thomas,

On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:
> Implement dedicated fbdev helpers for framebuffer I/O instead
> of using DRM's helpers. Use an fbdev generator macro for
> deferred I/O to create the fbdev callbacks. i915 was the only
> caller of the DRM helpers, so remove them from the helper module.
> 
> i915's fbdev emulation is still incomplete as it doesn't implement
> deferred I/O and damage handling for mmaped pages.
> 
> v4:
>   * generate deferred-I/O helpers
>   * use initializer macros for fb_ops
> v2:
>   * use FB_IO_HELPERS options
> 
> Signed-off-by: Thomas Zimmermann 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Cc: "Ville Syrjälä" 
> ---
>  drivers/gpu/drm/Kconfig|   3 -
>  drivers/gpu/drm/drm_fb_helper.c| 107 -
>  drivers/gpu/drm/i915/Kconfig   |   1 +
>  drivers/gpu/drm/i915/display/intel_fbdev.c |  14 +--
>  include/drm/drm_fb_helper.h|  39 
>  5 files changed, 9 insertions(+), 155 deletions(-)

Nice diffstat!
Assuming there is a good explanation on the dirty check:
Reviewed-by: Sam Ravnborg

Re: [PATCH v4 11/13] drm/fb-helper: Export helpers for marking damage areas

On Wed, May 24, 2023 at 11:21:48AM +0200, Thomas Zimmermann wrote:
> Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
> handle damage areas for fbdev emulation. This is a temporary export
> that allows to move the DRM I/O helpers for fbdev into drivers. Only
> fbdev-generic and i915 need them. Both will be updated to implement
> damage handling by themselves and the exported functions will be removed.
> 
> v4:
>   * update interfaces
> 
> Signed-off-by: Thomas Zimmermann 

Assuming there is a good answer why there is no dirty check:
Reviewed-by: Sam Ravnborg 

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 22 ++
>  include/drm/drm_fb_helper.h |  3 +++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f0e9549b6bd7..cb03099fd2e3 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -670,6 +670,28 @@ static void drm_fb_helper_memory_range_to_clip(struct 
> fb_info *info, off_t off,
>   drm_rect_init(clip, x1, y1, x2 - x1, y2 - y1);
>  }
>  
> +/* Don't use in new code. */
> +void drm_fb_helper_damage_range(struct fb_info *info, off_t off, size_t len)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct drm_rect damage_area;
> +
> + drm_fb_helper_memory_range_to_clip(info, off, len, _area);
> + drm_fb_helper_damage(fb_helper, damage_area.x1, damage_area.y1,
> +  drm_rect_width(_area),
> +  drm_rect_height(_area));
> +}
> +EXPORT_SYMBOL(drm_fb_helper_damage_range);
> +
> +/* Don't use in new code. */
> +void drm_fb_helper_damage_area(struct fb_info *info, u32 x, u32 y, u32 
> width, u32 height)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> +
> + drm_fb_helper_damage(fb_helper, x, y, width, height);
> +}
> +EXPORT_SYMBOL(drm_fb_helper_damage_area);
> +
>  /**
>   * drm_fb_helper_deferred_io() - fbdev deferred_io callback function
>   * @info: fb_info struct pointer
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 72032c354a30..7d5804882be7 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -253,6 +253,9 @@ void drm_fb_helper_fill_info(struct fb_info *info,
>struct drm_fb_helper *fb_helper,
>struct drm_fb_helper_surface_size *sizes);
>  
> +void drm_fb_helper_damage_range(struct fb_info *info, off_t off, size_t len);
> +void drm_fb_helper_damage_area(struct fb_info *info, u32 x, u32 y, u32 
> width, u32 height);
> +
>  void drm_fb_helper_deferred_io(struct fb_info *info, struct list_head 
> *pagereflist);
>  
>  ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
> -- 
> 2.40.1

Re: [PATCH v4 00/13] drm/fbdev: Remove DRM's helpers for fbdev I/O

Hi Thomas.

> v4:
>   * use initializer and generator macros for struct fb_ops
>   * partially support damage handling in msm (Dmitri)

I like the macros. They make it simpler and we do not spread the _cfb_
misname to more files.


> v3:
>   * fix Kconfig options (Jingfeng)
>   * minimize changes to exynos (Sam)
> v2:
>   * simplify Kconfig handling (Sam)
> 
> Thomas Zimmermann (13):
>   fbdev: Add Kconfig options to select different fb_ops helpers
>   fbdev: Add initializer macros for struct fb_ops


>   drm/armada: Use regular fbdev I/O helpers
>   drm/exynos: Use regular fbdev I/O helpers
>   drm/gma500: Use regular fbdev I/O helpers
>   drm/radeon: Use regular fbdev I/O helpers
>   drm/fbdev-dma: Use regular fbdev I/O helpers
>   drm/msm: Use regular fbdev I/O helpers
>   drm/omapdrm: Use regular fbdev I/O helpers
>   drm/tegra: Use regular fbdev I/O helpers
These are all:
Acked-by: Sam Ravnborg

Re: [PATCH v4 13/13] drm/i915: Implement dedicated fbdev I/O helpers

Hi Thomas,

On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:
> Implement dedicated fbdev helpers for framebuffer I/O instead
> of using DRM's helpers. Use an fbdev generator macro for
> deferred I/O to create the fbdev callbacks. i915 was the only
> caller of the DRM helpers, so remove them from the helper module.
> 
> i915's fbdev emulation is still incomplete as it doesn't implement
> deferred I/O and damage handling for mmaped pages.
> 
> v4:
>   * generate deferred-I/O helpers
>   * use initializer macros for fb_ops
> v2:
>   * use FB_IO_HELPERS options
> 
> Signed-off-by: Thomas Zimmermann 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Cc: "Ville Syrjälä" 
> ---
>  drivers/gpu/drm/Kconfig|   3 -
>  drivers/gpu/drm/drm_fb_helper.c| 107 -
>  drivers/gpu/drm/i915/Kconfig   |   1 +
>  drivers/gpu/drm/i915/display/intel_fbdev.c |  14 +--
>  include/drm/drm_fb_helper.h|  39 
>  5 files changed, 9 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 92a782827b7b..bb2e48cc6cd6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -133,9 +133,6 @@ config DRM_FBDEV_EMULATION
>   bool "Enable legacy fbdev support for your modesetting driver"
>   depends on DRM_KMS_HELPER
>   depends on FB=y || FB=DRM_KMS_HELPER
> - select FB_CFB_FILLRECT
> - select FB_CFB_COPYAREA
> - select FB_CFB_IMAGEBLIT
>   select FRAMEBUFFER_CONSOLE if !EXPERT
>   select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
>   default y
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index bab6b252f02a..9978147bbc8a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
> struct list_head *pagerefli
>  }
>  EXPORT_SYMBOL(drm_fb_helper_deferred_io);
>  
> -/**
> - * drm_fb_helper_cfb_read - Implements struct _ops.fb_read for I/O memory
> - * @info: fb_info struct pointer
> - * @buf: userspace buffer to read from framebuffer memory
> - * @count: number of bytes to read from framebuffer memory
> - * @ppos: read offset within framebuffer memory
> - *
> - * Returns:
> - * The number of bytes read on success, or an error code otherwise.
> - */
> -ssize_t drm_fb_helper_cfb_read(struct fb_info *info, char __user *buf,
> -size_t count, loff_t *ppos)
> -{
> - return fb_io_read(info, buf, count, ppos);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_cfb_read);
> -
> -/**
> - * drm_fb_helper_cfb_write - Implements struct _ops.fb_write for I/O 
> memory
> - * @info: fb_info struct pointer
> - * @buf: userspace buffer to write to framebuffer memory
> - * @count: number of bytes to write to framebuffer memory
> - * @ppos: write offset within framebuffer memory
> - *
> - * Returns:
> - * The number of bytes written on success, or an error code otherwise.
> - */
> -ssize_t drm_fb_helper_cfb_write(struct fb_info *info, const char __user *buf,
> - size_t count, loff_t *ppos)
> -{
> - struct drm_fb_helper *helper = info->par;
> - loff_t pos = *ppos;
> - ssize_t ret;
> - struct drm_rect damage_area;
> -
> - ret = fb_io_write(info, buf, count, ppos);
> - if (ret <= 0)
> - return ret;
> -
> - if (helper->funcs->fb_dirty) {
> - drm_fb_helper_memory_range_to_clip(info, pos, ret, 
> _area);
> - drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
> -  drm_rect_width(_area),
> -  drm_rect_height(_area));
> - }

The generated helpers do not have the if (helper->funcs->fb_dirty)
check.
Is this implemented somewhere else that I missed?

Sam


> -
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_fb_helper_cfb_write);
> -
> -/**
> - * drm_fb_helper_cfb_fillrect - wrapper around cfb_fillrect
> - * @info: fbdev registered by the helper
> - * @rect: info about rectangle to fill
> - *
> - * A wrapper around cfb_fillrect implemented by fbdev core
> - */
> -void drm_fb_helper_cfb_fillrect(struct fb_info *info,
> - const struct fb_fillrect *rect)
> -{
> - struct drm_fb_helper *helper = info->par;
> -
> - cfb_fillrect(info, rect);
> -
> - if (helper->funcs->fb_dirty)
> - drm_fb_helper_damage(helper, rect->dx, rect->dy, rect->width, 
> rect->height);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_cfb_fillrect);
> -
> -/**
> - * drm_fb_helper_cfb_copyarea - wrapper around cfb_copyarea
> - * @info: fbdev registered by the helper
> - * @area: info about area to copy
> - *
> - * A wrapper around cfb_copyarea implemented by fbdev core
> - */
> -void drm_fb_helper_cfb_copyarea(struct fb_info *info,
> - const struct

Re: [PATCH v4 03/13] drm/armada: Use regular fbdev I/O helpers

On Wed, May 24, 2023 at 11:21:40AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Armada does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
> 
> By using fbdev helpers directly within each DRM fbdev emulation,
> we can eventually remove DRM's wrapper functions entirely.
> 
> v4:
>   * use initializer macros for struct fb_ops
> v2:
>   * use FB_IO_HELPERS option
> 
> Signed-off-by: Thomas Zimmermann 
> Cc: Russell King 
Acked-by: Sam Ravnborg

Re: [PATCH v4 02/13] fbdev: Add initializer macros for struct fb_ops

On Wed, May 24, 2023 at 11:21:39AM +0200, Thomas Zimmermann wrote:
> For framebuffers in I/O and system memory, add macros that set
> struct fb_ops to the respective callback functions.
> 
> For deferred I/O, add macros that generate callback functions with
> damage handling. Add initializer macros that set struct fb_ops to
> the generated callbacks.
> 
> These macros can remove a lot boilerplate code from fbdev drivers.
> The drivers are supposed to use the macro that is required for its
> framebuffer. Each macro is split into smaller helpers, so that
> drivers with non-standard callbacks can pick and customize callbacks
> as needed. There are individual helper macros for read/write, mmap
> and drawing.
> 
> Signed-off-by: Thomas Zimmermann 
I am not a fan of public functions/macros names __something.
But I see it used in so many places, so maybe it is just me.
And everything looks consistent, so OK.

With the white space issues fixed:
Reviewed-by: Sam Ravnborg

Re: [PATCH v4 01/13] fbdev: Add Kconfig options to select different fb_ops helpers

Hi Thomas,

On Wed, May 24, 2023 at 11:21:38AM +0200, Thomas Zimmermann wrote:
> Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
> options to select them at once. This will help with making DRM's
> fbdev emulation code more modular, but can also be used to simplify
> fbdev's driver configs.
> 
> v3:
>   * fix select statement (Jingfeng)
> 
> Signed-off-by: Thomas Zimmermann 
I like these, thanks.
Reviewed-by: Sam Ravnborg

Re: [PATCH 1/7] dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible

2023-05-29 Thread Conor Dooley

On Mon, May 29, 2023 at 11:43:58AM +0200, Luca Weiss wrote:
> The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new
> compatible for it.
> 
> Signed-off-by: Luca Weiss 
> ---
>  Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 1 +
>  Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml| 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml 
> b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
> index cf4a338c4661..bd70c3873ca9 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
> @@ -18,6 +18,7 @@ properties:
>- qcom,dsi-phy-28nm-hpm
>- qcom,dsi-phy-28nm-hpm-fam-b
>- qcom,dsi-phy-28nm-lp
> +  - qcom,dsi-phy-28nm-8226

How come the order is different in both places?

Acked-by: Conor Dooley 

Thanks,
Conor.

>- qcom,dsi-phy-28nm-8960
>  
>reg:
> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml 
> b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
> index b0100105e428..db9f07c6142d 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
> @@ -125,6 +125,7 @@ patternProperties:
>- qcom,dsi-phy-14nm-660
>- qcom,dsi-phy-14nm-8953
>- qcom,dsi-phy-20nm
> +  - qcom,dsi-phy-28nm-8226
>- qcom,dsi-phy-28nm-hpm
>- qcom,dsi-phy-28nm-lp
>- qcom,hdmi-phy-8084
> 
> -- 
> 2.40.1
> 


signature.asc
Description: PGP signature

Re: [PATCH 3/7] dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible

2023-05-29 Thread Conor Dooley

On Mon, May 29, 2023 at 11:44:00AM +0200, Luca Weiss wrote:
> Add the compatible for the MDP5 found on MSM8226.
> 
> Signed-off-by: Luca Weiss 

Acked-by: Conor Dooley 

Thanks,
Conor.


signature.asc
Description: PGP signature

Re: [PATCH 2/7] dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible

2023-05-29 Thread Conor Dooley

On Mon, May 29, 2023 at 11:43:59AM +0200, Luca Weiss wrote:
> Add the compatible for the DSI found on MSM8226.
> 
> Signed-off-by: Luca Weiss 

Acked-by: Conor Dooley 

Thanks,
Conor.


signature.asc
Description: PGP signature

[PATCH v5 5/6] drm/etnaviv: expand driver support for the PCI devices

This patch adds PCI driver support on top of what already have. Take the
GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device driver.
There is only one GPU core for the GC1000 in the LS7A1000 and LS2K1000.
Therefore, component frameworks can be avoided. Because we want to bind the
DRM driver service to the PCI driver manually.
    
We avoid using the component framework because the virtual master device
will not be used without a force override. X server and Mesa will try to
find the PCI device to use by default. Creating a virtual master device
for PCI GPUs cause unnecessary troubles.
    
Using the component framework with a PCI device is still possible; it is
just that the solo PCI device should be the master. A platform with a
single GPU core could also try the non-component code path.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/Makefile  |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 62 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  3 +
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 97 ---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 12 +++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c | 88 
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h | 10 +++
 7 files changed, 232 insertions(+), 41 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h

diff --git a/drivers/gpu/drm/etnaviv/Makefile b/drivers/gpu/drm/etnaviv/Makefile
index 46e5ffad69a6..3f8b99664a58 100644
--- a/drivers/gpu/drm/etnaviv/Makefile
+++ b/drivers/gpu/drm/etnaviv/Makefile
@@ -13,6 +13,7 @@ etnaviv-y := \
etnaviv_iommu_v2.o \
etnaviv_iommu.o \
etnaviv_mmu.o \
+   etnaviv_pci_drv.o \
etnaviv_perfmon.o \
etnaviv_sched.o
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 56c98711f8e1..7ff795c5cc79 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -21,6 +22,7 @@
 #include "etnaviv_gpu.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_mmu.h"
+#include "etnaviv_pci_drv.h"
 #include "etnaviv_perfmon.h"
 
 /*
@@ -525,6 +527,16 @@ static int etnaviv_alloc_private(struct device *dev,
return ret;
}
 
+   /*
+* Loongson Mips and LoongArch CPU(ls3a5000, ls3c5000, ls2k1000la)
+* maintain cache coherency by hardware
+*/
+   if (IS_ENABLED(CONFIG_CPU_LOONGSON64) || IS_ENABLED(CONFIG_LOONGARCH))
+   priv->has_cached_coherent = true;
+
+   dev_info(dev, "Cached coherent mode is %s\n",
+priv->has_cached_coherent ? "support" : "not support");
+
*ppriv = priv;
 
return 0;
@@ -539,10 +551,9 @@ static void etnaviv_free_private(struct 
etnaviv_drm_private *priv)
kfree(priv);
 }
 
-/*
- * Platform driver:
- */
-static int etnaviv_bind(struct device *dev)
+static struct etnaviv_drm_private *etna_private_s;
+
+int etnaviv_drm_bind(struct device *dev, bool component)
 {
struct etnaviv_drm_private *priv;
struct drm_device *drm;
@@ -558,12 +569,15 @@ static int etnaviv_bind(struct device *dev)
 
priv->drm = drm;
drm->dev_private = priv;
+   etna_private_s = priv;
 
dma_set_max_seg_size(dev, SZ_2G);
 
-   dev_set_drvdata(dev, drm);
+   if (component)
+   ret = component_bind_all(dev, drm);
+   else
+   ret = etnaviv_gpu_bind(dev, NULL, drm);
 
-   ret = component_bind_all(dev, drm);
if (ret < 0)
goto out_free_priv;
 
@@ -585,14 +599,17 @@ static int etnaviv_bind(struct device *dev)
return ret;
 }
 
-static void etnaviv_unbind(struct device *dev)
+void etnaviv_drm_unbind(struct device *dev, bool component)
 {
-   struct drm_device *drm = dev_get_drvdata(dev);
-   struct etnaviv_drm_private *priv = drm->dev_private;
+   struct etnaviv_drm_private *priv = etna_private_s;
+   struct drm_device *drm = priv->drm;
 
drm_dev_unregister(drm);
 
-   component_unbind_all(dev, drm);
+   if (component)
+   component_unbind_all(dev, drm);
+   else
+   etnaviv_gpu_unbind(dev, NULL, drm);
 
etnaviv_free_private(priv);
 
@@ -601,9 +618,22 @@ static void etnaviv_unbind(struct device *dev)
drm_dev_put(drm);
 }
 
+/*
+ * Platform driver:
+ */
+static int etnaviv_master_bind(struct device *dev)
+{
+   return etnaviv_drm_bind(dev, true);
+}
+
+static void etnaviv_master_unbind(struct device *dev)
+{
+   return etnaviv_drm_unbind(dev, true);
+}
+
 static const struct component_master_ops etnaviv_master_ops = {
-   .bind = etnaviv_bind,
-   .unbind = etnaviv_unbind,
+   .bind = etnaviv_master_bind,
+   .unbind = etnaviv_master_unbind,
 };
 
 static int etnaviv_pdev_probe(struct

[PATCH v5 4/6] drm/etnaviv: add helpers for private data construction and destruction

struct etnaviv_drm_private contains a lot of common resources that are
shared by all GPUs. This patch introduces two dedicated functions, which
is for the construction and destruction of instances of this structure.
    
The idea is to avoid leaking its members outside. The error handling code
can also be simplified.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 71 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  4 ++
 2 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 0a9d90c18f2c..56c98711f8e1 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -498,28 +498,17 @@ static const struct drm_driver etnaviv_drm_driver = {
.minor  = 3,
 };
 
-/*
- * Platform driver:
- */
-static int etnaviv_bind(struct device *dev)
+static int etnaviv_alloc_private(struct device *dev,
+struct etnaviv_drm_private **ppriv)
 {
struct etnaviv_drm_private *priv;
-   struct drm_device *drm;
int ret;
 
-   drm = drm_dev_alloc(_drm_driver, dev);
-   if (IS_ERR(drm))
-   return PTR_ERR(drm);
-
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(dev, "failed to allocate private data\n");
-   ret = -ENOMEM;
-   goto out_put;
+   return -ENOMEM;
}
-   drm->dev_private = priv;
-
-   dma_set_max_seg_size(dev, SZ_2G);
 
xa_init_flags(>active_contexts, XA_FLAGS_ALLOC);
 
@@ -528,18 +517,55 @@ static int etnaviv_bind(struct device *dev)
priv->num_gpus = 0;
priv->shm_gfp_mask = GFP_HIGHUSER | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
 
-   priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(drm->dev);
+   priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(dev);
if (IS_ERR(priv->cmdbuf_suballoc)) {
-   dev_err(drm->dev, "Failed to create cmdbuf suballocator\n");
+   dev_err(dev, "Failed to create cmdbuf suballocator\n");
ret = PTR_ERR(priv->cmdbuf_suballoc);
-   goto out_free_priv;
+   kfree(priv);
+   return ret;
}
 
+   *ppriv = priv;
+
+   return 0;
+}
+
+static void etnaviv_free_private(struct etnaviv_drm_private *priv)
+{
+   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
+
+   xa_destroy(>active_contexts);
+
+   kfree(priv);
+}
+
+/*
+ * Platform driver:
+ */
+static int etnaviv_bind(struct device *dev)
+{
+   struct etnaviv_drm_private *priv;
+   struct drm_device *drm;
+   int ret;
+
+   drm = drm_dev_alloc(_drm_driver, dev);
+   if (IS_ERR(drm))
+   return PTR_ERR(drm);
+
+   ret = etnaviv_alloc_private(dev, );
+   if (ret)
+   goto out_put;
+
+   priv->drm = drm;
+   drm->dev_private = priv;
+
+   dma_set_max_seg_size(dev, SZ_2G);
+
dev_set_drvdata(dev, drm);
 
ret = component_bind_all(dev, drm);
if (ret < 0)
-   goto out_destroy_suballoc;
+   goto out_free_priv;
 
load_gpu(drm);
 
@@ -551,10 +577,8 @@ static int etnaviv_bind(struct device *dev)
 
 out_unbind:
component_unbind_all(dev, drm);
-out_destroy_suballoc:
-   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
 out_free_priv:
-   kfree(priv);
+   etnaviv_free_private(priv);
 out_put:
drm_dev_put(drm);
 
@@ -570,12 +594,9 @@ static void etnaviv_unbind(struct device *dev)
 
component_unbind_all(dev, drm);
 
-   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
-
-   xa_destroy(>active_contexts);
+   etnaviv_free_private(priv);
 
drm->dev_private = NULL;
-   kfree(priv);
 
drm_dev_put(drm);
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index b3eb1662e90c..87fb52c03c5e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -35,6 +35,7 @@ struct etnaviv_file_private {
 };
 
 struct etnaviv_drm_private {
+   struct drm_device *drm;
int num_gpus;
struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
gfp_t shm_gfp_mask;
@@ -45,6 +46,9 @@ struct etnaviv_drm_private {
struct xarray active_contexts;
u32 next_context_id;
 
+   /* hint for platform support cached coherent caching mode */
+   bool has_cached_coherent;
+
/* list of GEM objects: */
struct mutex gem_lock;
struct list_head gem_list;
-- 
2.25.1

[PATCH v5 1/6] drm/etnaviv: add a dedicated function to register an irq handler

Because getting IRQ from a device is platform-dependent, PCI devices have
different methods for getting an IRQ. This patch is a preparation patch to
extend support for the PCI device.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ---
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index de8c9894967c..636d3f39ddcb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1817,6 +1817,29 @@ static const struct of_device_id etnaviv_gpu_match[] = {
 };
 MODULE_DEVICE_TABLE(of, etnaviv_gpu_match);
 
+static int etnaviv_gpu_register_irq(struct etnaviv_gpu *gpu, int irq)
+{
+   struct device *dev = gpu->dev;
+   int err;
+
+   if (irq < 0) {
+   dev_err(dev, "failed to get irq: %d\n", irq);
+   return irq;
+   }
+
+   err = devm_request_irq(dev, irq, irq_handler, 0, dev_name(dev), gpu);
+   if (err) {
+   dev_err(dev, "failed to request IRQ %u: %d\n", irq, err);
+   return err;
+   }
+
+   gpu->irq = irq;
+
+   dev_info(dev, "IRQ handler registered, irq = %d\n", irq);
+
+   return 0;
+}
+
 static int etnaviv_gpu_platform_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1837,16 +1860,9 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
return PTR_ERR(gpu->mmio);
 
/* Get Interrupt: */
-   gpu->irq = platform_get_irq(pdev, 0);
-   if (gpu->irq < 0)
-   return gpu->irq;
-
-   err = devm_request_irq(>dev, gpu->irq, irq_handler, 0,
-  dev_name(gpu->dev), gpu);
-   if (err) {
-   dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq, err);
+   err = etnaviv_gpu_register_irq(gpu,  platform_get_irq(pdev, 0));
+   if (err)
return err;
-   }
 
/* Get Clocks: */
gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
-- 
2.25.1

[PATCH v5 0/6] drm/etnaviv: add pci device driver support

There is a Vivante GC1000 (v5037) in LS2K1000 and LS7A1000, this GPU is a
PCI device, and it has 2D and 3D cores in the same device. Thus, this patch
series is trying to add PCI device driver support to etnaviv.

Sui Jingfeng (6):
  drm/etnaviv: add a dedicated function to register an irq handler
  drm/etnaviv: add a dedicated function to get various clocks
  drm/etnaviv: add dedicated functions to create and destroy platform
devices
  drm/etnaviv: add helpers for private data construction and destruction
  drm/etnaviv: expand driver support for the PCI devices
  drm/etnaviv: allow usperspace create cached coherent bo

 drivers/gpu/drm/etnaviv/Makefile|   1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   | 183 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h   |   7 +
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   |  22 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |   9 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c   | 185 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |  13 ++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c   |  88 ++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h   |  10 ++
 include/uapi/drm/etnaviv_drm.h  |  11 +-
 10 files changed, 415 insertions(+), 114 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h

-- 
2.25.1

[PATCH v5 6/6] drm/etnaviv: allow usperspace create cached coherent bo

cached system RAM is coherent on loongson CPUs, and the GPU and DC allways
snoop the CPU's cache. write-combine caching property is not suitiable for
us.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   | 22 +++--
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |  9 -
 include/uapi/drm/etnaviv_drm.h  | 11 ++-
 4 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 7ff795c5cc79..3a86d1211ca5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -275,7 +275,7 @@ static int etnaviv_ioctl_gem_new(struct drm_device *dev, 
void *data,
struct drm_etnaviv_gem_new *args = data;
 
if (args->flags & ~(ETNA_BO_CACHED | ETNA_BO_WC | ETNA_BO_UNCACHED |
-   ETNA_BO_FORCE_MMU))
+   ETNA_BO_CACHED_COHERENT | ETNA_BO_FORCE_MMU))
return -EINVAL;
 
return etnaviv_gem_new_handle(dev, file, args->size,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index b5f73502e3dd..d8b559bd33d3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -343,6 +343,7 @@ void *etnaviv_gem_vmap(struct drm_gem_object *obj)
 static void *etnaviv_gem_vmap_impl(struct etnaviv_gem_object *obj)
 {
struct page **pages;
+   pgprot_t prot;
 
lockdep_assert_held(>lock);
 
@@ -350,8 +351,20 @@ static void *etnaviv_gem_vmap_impl(struct 
etnaviv_gem_object *obj)
if (IS_ERR(pages))
return NULL;
 
-   return vmap(pages, obj->base.size >> PAGE_SHIFT,
-   VM_MAP, pgprot_writecombine(PAGE_KERNEL));
+   switch (obj->flags) {
+   case ETNA_BO_CACHED_COHERENT:
+   case ETNA_BO_CACHED:
+   prot = PAGE_KERNEL;
+   break;
+   case ETNA_BO_UNCACHED:
+   prot = pgprot_noncached(PAGE_KERNEL);
+   break;
+   case ETNA_BO_WC:
+   default:
+   prot = pgprot_writecombine(PAGE_KERNEL);
+   }
+
+   return vmap(pages, obj->base.size >> PAGE_SHIFT, VM_MAP, prot);
 }
 
 static inline enum dma_data_direction etnaviv_op_to_dma_dir(u32 op)
@@ -545,6 +558,7 @@ static const struct drm_gem_object_funcs 
etnaviv_gem_object_funcs = {
 static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
const struct etnaviv_gem_ops *ops, struct drm_gem_object **obj)
 {
+   struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_gem_object *etnaviv_obj;
unsigned sz = sizeof(*etnaviv_obj);
bool valid = true;
@@ -555,6 +569,10 @@ static int etnaviv_gem_new_impl(struct drm_device *dev, 
u32 size, u32 flags,
case ETNA_BO_CACHED:
case ETNA_BO_WC:
break;
+   case ETNA_BO_CACHED_COHERENT:
+   if (priv->has_cached_coherent)
+   break;
+   fallthrough;
default:
valid = false;
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 3524b5811682..671d91d8f1c6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -112,11 +112,18 @@ static const struct etnaviv_gem_ops etnaviv_gem_prime_ops 
= {
 struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device 
*dev,
struct dma_buf_attachment *attach, struct sg_table *sgt)
 {
+   struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_gem_object *etnaviv_obj;
size_t size = PAGE_ALIGN(attach->dmabuf->size);
+   u32 cache_flags;
int ret, npages;
 
-   ret = etnaviv_gem_new_private(dev, size, ETNA_BO_WC,
+   if (priv->has_cached_coherent)
+   cache_flags = ETNA_BO_CACHED_COHERENT;
+   else
+   cache_flags = ETNA_BO_WC;
+
+   ret = etnaviv_gem_new_private(dev, size, cache_flags,
  _gem_prime_ops, _obj);
if (ret < 0)
return ERR_PTR(ret);
diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
index af024d90453d..474b0db286de 100644
--- a/include/uapi/drm/etnaviv_drm.h
+++ b/include/uapi/drm/etnaviv_drm.h
@@ -90,13 +90,14 @@ struct drm_etnaviv_param {
  * GEM buffers:
  */
 
-#define ETNA_BO_CACHE_MASK   0x000f
+#define ETNA_BO_CACHE_MASK  0x000f
 /* cache modes */
-#define ETNA_BO_CACHED   0x0001
-#define ETNA_BO_WC   0x0002
-#define ETNA_BO_UNCACHED 0x0004
+#define ETNA_BO_CACHED  0x0001
+#define ETNA_BO_WC  0x0002
+#define ETNA_BO_UNCACHED0x0004
+#define ETNA_BO_CACHED_COHERENT 0x0008
 /* map

[PATCH v5 3/6] drm/etnaviv: add dedicated functions to create and destroy platform devices

Also rename the virtual master platform device as etnaviv_platform_device,
for better reflection that it is a platform device, not a DRM device.

Another benefit is that we no longer need to call of_node_put() for three
different cases, Instead, we only need to call it once.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 56 +++
 1 file changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 31a7f59ccb49..0a9d90c18f2c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -656,12 +656,44 @@ static struct platform_driver etnaviv_platform_driver = {
},
 };
 
-static struct platform_device *etnaviv_drm;
+static struct platform_device *etnaviv_platform_device;
 
-static int __init etnaviv_init(void)
+static int etnaviv_create_platform_device(const char *name,
+ struct platform_device **ppdev)
 {
struct platform_device *pdev;
int ret;
+
+   pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE);
+   if (!pdev)
+   return -ENOMEM;
+
+   ret = platform_device_add(pdev);
+   if (ret) {
+   platform_device_put(pdev);
+   return ret;
+   }
+
+   *ppdev = pdev;
+
+   return 0;
+}
+
+static void etnaviv_destroy_platform_device(struct platform_device **ppdev)
+{
+   struct platform_device *pdev = *ppdev;
+
+   if (!pdev)
+   return;
+
+   *ppdev = NULL;
+
+   platform_device_unregister(pdev);
+}
+
+static int __init etnaviv_init(void)
+{
+   int ret;
struct device_node *np;
 
etnaviv_validate_init();
@@ -682,22 +714,12 @@ static int __init etnaviv_init(void)
if (!of_device_is_available(np))
continue;
 
-   pdev = platform_device_alloc("etnaviv", PLATFORM_DEVID_NONE);
-   if (!pdev) {
-   ret = -ENOMEM;
-   of_node_put(np);
-   goto unregister_platform_driver;
-   }
-
-   ret = platform_device_add(pdev);
-   if (ret) {
-   platform_device_put(pdev);
-   of_node_put(np);
+   ret = etnaviv_create_platform_device("etnaviv",
+_platform_device);
+   of_node_put(np);
+   if (ret)
goto unregister_platform_driver;
-   }
 
-   etnaviv_drm = pdev;
-   of_node_put(np);
break;
}
 
@@ -713,7 +735,7 @@ module_init(etnaviv_init);
 
 static void __exit etnaviv_exit(void)
 {
-   platform_device_unregister(etnaviv_drm);
+   etnaviv_destroy_platform_device(_platform_device);
platform_driver_unregister(_platform_driver);
platform_driver_unregister(_gpu_driver);
 }
-- 
2.25.1

[PATCH v5 2/6] drm/etnaviv: add a dedicated function to get various clocks

Because it is also platform-dependent, there are environments where don't
have CLK subsystem support, for example, discreted PCI gpu. So don't rage
quit if there is no CLK subsystem.

For the GPU in LS7a1000 and LS2k2000, the working frequency of the GPU is
tuned by configuring the PLL register directly.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 62 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  1 +
 2 files changed, 42 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 636d3f39ddcb..4937580551a5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1565,10 +1565,45 @@ static irqreturn_t irq_handler(int irq, void *data)
return ret;
 }
 
+static int etnaviv_gpu_clk_get(struct etnaviv_gpu *gpu)
+{
+   struct device *dev = gpu->dev;
+
+   if (gpu->no_clk)
+   return 0;
+
+   gpu->clk_reg = devm_clk_get_optional(dev, "reg");
+   DBG("clk_reg: %p", gpu->clk_reg);
+   if (IS_ERR(gpu->clk_reg))
+   return PTR_ERR(gpu->clk_reg);
+
+   gpu->clk_bus = devm_clk_get_optional(dev, "bus");
+   DBG("clk_bus: %p", gpu->clk_bus);
+   if (IS_ERR(gpu->clk_bus))
+   return PTR_ERR(gpu->clk_bus);
+
+   gpu->clk_core = devm_clk_get(dev, "core");
+   DBG("clk_core: %p", gpu->clk_core);
+   if (IS_ERR(gpu->clk_core))
+   return PTR_ERR(gpu->clk_core);
+   gpu->base_rate_core = clk_get_rate(gpu->clk_core);
+
+   gpu->clk_shader = devm_clk_get_optional(dev, "shader");
+   DBG("clk_shader: %p", gpu->clk_shader);
+   if (IS_ERR(gpu->clk_shader))
+   return PTR_ERR(gpu->clk_shader);
+   gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+
+   return 0;
+}
+
 static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
 {
int ret;
 
+   if (gpu->no_clk)
+   return 0;
+
ret = clk_prepare_enable(gpu->clk_reg);
if (ret)
return ret;
@@ -1599,6 +1634,9 @@ static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
 
 static int etnaviv_gpu_clk_disable(struct etnaviv_gpu *gpu)
 {
+   if (gpu->no_clk)
+   return 0;
+
clk_disable_unprepare(gpu->clk_shader);
clk_disable_unprepare(gpu->clk_core);
clk_disable_unprepare(gpu->clk_bus);
@@ -1865,27 +1903,9 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
return err;
 
/* Get Clocks: */
-   gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
-   DBG("clk_reg: %p", gpu->clk_reg);
-   if (IS_ERR(gpu->clk_reg))
-   return PTR_ERR(gpu->clk_reg);
-
-   gpu->clk_bus = devm_clk_get_optional(>dev, "bus");
-   DBG("clk_bus: %p", gpu->clk_bus);
-   if (IS_ERR(gpu->clk_bus))
-   return PTR_ERR(gpu->clk_bus);
-
-   gpu->clk_core = devm_clk_get(>dev, "core");
-   DBG("clk_core: %p", gpu->clk_core);
-   if (IS_ERR(gpu->clk_core))
-   return PTR_ERR(gpu->clk_core);
-   gpu->base_rate_core = clk_get_rate(gpu->clk_core);
-
-   gpu->clk_shader = devm_clk_get_optional(>dev, "shader");
-   DBG("clk_shader: %p", gpu->clk_shader);
-   if (IS_ERR(gpu->clk_shader))
-   return PTR_ERR(gpu->clk_shader);
-   gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+   err = etnaviv_gpu_clk_get(gpu);
+   if (err)
+   return err;
 
/* TODO: figure out max mapped size */
dev_set_drvdata(dev, gpu);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 98c6f9c320fc..6da5209a7d64 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -148,6 +148,7 @@ struct etnaviv_gpu {
struct clk *clk_reg;
struct clk *clk_core;
struct clk *clk_shader;
+   bool no_clk;
 
unsigned int freq_scale;
unsigned long base_rate_core;
-- 
2.25.1

[PATCH v4 4/6] drm/etnaviv: add helpers for private data construction and destruction

struct etnaviv_drm_private contains a lot of common resources that are
shared by all GPUs. This patch introduces two dedicated functions, which
is for the construction and destruction of instances of this structure.
    
The idea is to avoid leaking its members outside. The error handling code
can also be simplified.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 71 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  4 ++
 2 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 0a9d90c18f2c..56c98711f8e1 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -498,28 +498,17 @@ static const struct drm_driver etnaviv_drm_driver = {
.minor  = 3,
 };
 
-/*
- * Platform driver:
- */
-static int etnaviv_bind(struct device *dev)
+static int etnaviv_alloc_private(struct device *dev,
+struct etnaviv_drm_private **ppriv)
 {
struct etnaviv_drm_private *priv;
-   struct drm_device *drm;
int ret;
 
-   drm = drm_dev_alloc(_drm_driver, dev);
-   if (IS_ERR(drm))
-   return PTR_ERR(drm);
-
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(dev, "failed to allocate private data\n");
-   ret = -ENOMEM;
-   goto out_put;
+   return -ENOMEM;
}
-   drm->dev_private = priv;
-
-   dma_set_max_seg_size(dev, SZ_2G);
 
xa_init_flags(>active_contexts, XA_FLAGS_ALLOC);
 
@@ -528,18 +517,55 @@ static int etnaviv_bind(struct device *dev)
priv->num_gpus = 0;
priv->shm_gfp_mask = GFP_HIGHUSER | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
 
-   priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(drm->dev);
+   priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(dev);
if (IS_ERR(priv->cmdbuf_suballoc)) {
-   dev_err(drm->dev, "Failed to create cmdbuf suballocator\n");
+   dev_err(dev, "Failed to create cmdbuf suballocator\n");
ret = PTR_ERR(priv->cmdbuf_suballoc);
-   goto out_free_priv;
+   kfree(priv);
+   return ret;
}
 
+   *ppriv = priv;
+
+   return 0;
+}
+
+static void etnaviv_free_private(struct etnaviv_drm_private *priv)
+{
+   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
+
+   xa_destroy(>active_contexts);
+
+   kfree(priv);
+}
+
+/*
+ * Platform driver:
+ */
+static int etnaviv_bind(struct device *dev)
+{
+   struct etnaviv_drm_private *priv;
+   struct drm_device *drm;
+   int ret;
+
+   drm = drm_dev_alloc(_drm_driver, dev);
+   if (IS_ERR(drm))
+   return PTR_ERR(drm);
+
+   ret = etnaviv_alloc_private(dev, );
+   if (ret)
+   goto out_put;
+
+   priv->drm = drm;
+   drm->dev_private = priv;
+
+   dma_set_max_seg_size(dev, SZ_2G);
+
dev_set_drvdata(dev, drm);
 
ret = component_bind_all(dev, drm);
if (ret < 0)
-   goto out_destroy_suballoc;
+   goto out_free_priv;
 
load_gpu(drm);
 
@@ -551,10 +577,8 @@ static int etnaviv_bind(struct device *dev)
 
 out_unbind:
component_unbind_all(dev, drm);
-out_destroy_suballoc:
-   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
 out_free_priv:
-   kfree(priv);
+   etnaviv_free_private(priv);
 out_put:
drm_dev_put(drm);
 
@@ -570,12 +594,9 @@ static void etnaviv_unbind(struct device *dev)
 
component_unbind_all(dev, drm);
 
-   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
-
-   xa_destroy(>active_contexts);
+   etnaviv_free_private(priv);
 
drm->dev_private = NULL;
-   kfree(priv);
 
drm_dev_put(drm);
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index b3eb1662e90c..87fb52c03c5e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -35,6 +35,7 @@ struct etnaviv_file_private {
 };
 
 struct etnaviv_drm_private {
+   struct drm_device *drm;
int num_gpus;
struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
gfp_t shm_gfp_mask;
@@ -45,6 +46,9 @@ struct etnaviv_drm_private {
struct xarray active_contexts;
u32 next_context_id;
 
+   /* hint for platform support cached coherent caching mode */
+   bool has_cached_coherent;
+
/* list of GEM objects: */
struct mutex gem_lock;
struct list_head gem_list;
-- 
2.25.1

[PATCH v4 2/6] drm/etnaviv: add a dedicated function to get various clocks

Because it is also platform-dependent, there are environments where don't
have CLK subsystem support, for example, discreted PCI gpu. So don't rage
quit if there is no CLK subsystem.

For the GPU in LS7a1000 and LS2k2000, the working frequency of the GPU is
tuned by configuring the PLL register directly.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 62 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  1 +
 2 files changed, 42 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 636d3f39ddcb..4937580551a5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1565,10 +1565,45 @@ static irqreturn_t irq_handler(int irq, void *data)
return ret;
 }
 
+static int etnaviv_gpu_clk_get(struct etnaviv_gpu *gpu)
+{
+   struct device *dev = gpu->dev;
+
+   if (gpu->no_clk)
+   return 0;
+
+   gpu->clk_reg = devm_clk_get_optional(dev, "reg");
+   DBG("clk_reg: %p", gpu->clk_reg);
+   if (IS_ERR(gpu->clk_reg))
+   return PTR_ERR(gpu->clk_reg);
+
+   gpu->clk_bus = devm_clk_get_optional(dev, "bus");
+   DBG("clk_bus: %p", gpu->clk_bus);
+   if (IS_ERR(gpu->clk_bus))
+   return PTR_ERR(gpu->clk_bus);
+
+   gpu->clk_core = devm_clk_get(dev, "core");
+   DBG("clk_core: %p", gpu->clk_core);
+   if (IS_ERR(gpu->clk_core))
+   return PTR_ERR(gpu->clk_core);
+   gpu->base_rate_core = clk_get_rate(gpu->clk_core);
+
+   gpu->clk_shader = devm_clk_get_optional(dev, "shader");
+   DBG("clk_shader: %p", gpu->clk_shader);
+   if (IS_ERR(gpu->clk_shader))
+   return PTR_ERR(gpu->clk_shader);
+   gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+
+   return 0;
+}
+
 static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
 {
int ret;
 
+   if (gpu->no_clk)
+   return 0;
+
ret = clk_prepare_enable(gpu->clk_reg);
if (ret)
return ret;
@@ -1599,6 +1634,9 @@ static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
 
 static int etnaviv_gpu_clk_disable(struct etnaviv_gpu *gpu)
 {
+   if (gpu->no_clk)
+   return 0;
+
clk_disable_unprepare(gpu->clk_shader);
clk_disable_unprepare(gpu->clk_core);
clk_disable_unprepare(gpu->clk_bus);
@@ -1865,27 +1903,9 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
return err;
 
/* Get Clocks: */
-   gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
-   DBG("clk_reg: %p", gpu->clk_reg);
-   if (IS_ERR(gpu->clk_reg))
-   return PTR_ERR(gpu->clk_reg);
-
-   gpu->clk_bus = devm_clk_get_optional(>dev, "bus");
-   DBG("clk_bus: %p", gpu->clk_bus);
-   if (IS_ERR(gpu->clk_bus))
-   return PTR_ERR(gpu->clk_bus);
-
-   gpu->clk_core = devm_clk_get(>dev, "core");
-   DBG("clk_core: %p", gpu->clk_core);
-   if (IS_ERR(gpu->clk_core))
-   return PTR_ERR(gpu->clk_core);
-   gpu->base_rate_core = clk_get_rate(gpu->clk_core);
-
-   gpu->clk_shader = devm_clk_get_optional(>dev, "shader");
-   DBG("clk_shader: %p", gpu->clk_shader);
-   if (IS_ERR(gpu->clk_shader))
-   return PTR_ERR(gpu->clk_shader);
-   gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+   err = etnaviv_gpu_clk_get(gpu);
+   if (err)
+   return err;
 
/* TODO: figure out max mapped size */
dev_set_drvdata(dev, gpu);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 98c6f9c320fc..6da5209a7d64 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -148,6 +148,7 @@ struct etnaviv_gpu {
struct clk *clk_reg;
struct clk *clk_core;
struct clk *clk_shader;
+   bool no_clk;
 
unsigned int freq_scale;
unsigned long base_rate_core;
-- 
2.25.1

[PATCH v4 3/6] drm/etnaviv: add dedicated functions to create and destroy platform devices

Also rename the virtual master platform device as etnaviv_platform_device,
for better reflection that it is a platform device, not a DRM device.

Another benefit is that we no longer need to call of_node_put() for three
different cases, Instead, we only need to call it once.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 56 +++
 1 file changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 31a7f59ccb49..0a9d90c18f2c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -656,12 +656,44 @@ static struct platform_driver etnaviv_platform_driver = {
},
 };
 
-static struct platform_device *etnaviv_drm;
+static struct platform_device *etnaviv_platform_device;
 
-static int __init etnaviv_init(void)
+static int etnaviv_create_platform_device(const char *name,
+ struct platform_device **ppdev)
 {
struct platform_device *pdev;
int ret;
+
+   pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE);
+   if (!pdev)
+   return -ENOMEM;
+
+   ret = platform_device_add(pdev);
+   if (ret) {
+   platform_device_put(pdev);
+   return ret;
+   }
+
+   *ppdev = pdev;
+
+   return 0;
+}
+
+static void etnaviv_destroy_platform_device(struct platform_device **ppdev)
+{
+   struct platform_device *pdev = *ppdev;
+
+   if (!pdev)
+   return;
+
+   *ppdev = NULL;
+
+   platform_device_unregister(pdev);
+}
+
+static int __init etnaviv_init(void)
+{
+   int ret;
struct device_node *np;
 
etnaviv_validate_init();
@@ -682,22 +714,12 @@ static int __init etnaviv_init(void)
if (!of_device_is_available(np))
continue;
 
-   pdev = platform_device_alloc("etnaviv", PLATFORM_DEVID_NONE);
-   if (!pdev) {
-   ret = -ENOMEM;
-   of_node_put(np);
-   goto unregister_platform_driver;
-   }
-
-   ret = platform_device_add(pdev);
-   if (ret) {
-   platform_device_put(pdev);
-   of_node_put(np);
+   ret = etnaviv_create_platform_device("etnaviv",
+_platform_device);
+   of_node_put(np);
+   if (ret)
goto unregister_platform_driver;
-   }
 
-   etnaviv_drm = pdev;
-   of_node_put(np);
break;
}
 
@@ -713,7 +735,7 @@ module_init(etnaviv_init);
 
 static void __exit etnaviv_exit(void)
 {
-   platform_device_unregister(etnaviv_drm);
+   etnaviv_destroy_platform_device(_platform_device);
platform_driver_unregister(_platform_driver);
platform_driver_unregister(_gpu_driver);
 }
-- 
2.25.1

[PATCH v4 0/6] drm/etnaviv: add pci device driver support

There is a Vivante GC1000 (v5037) in LS2K1000 and LS7A1000, this GPU is a
PCI device, and it has 2D and 3D cores in the same device. Thus, this
series is trying to add PCI device driver support to etnaviv.

Sui Jingfeng (6):
  drm/etnaviv: add a dedicated function to register an irq handler
  drm/etnaviv: add a dedicated function to get various clocks
  drm/etnaviv: add dedicated functions to create and destroy platform
devices
  drm/etnaviv: add helpers for private data construction and destruction
  drm/etnaviv: expand driver support for the PCI devices
  drm/etnaviv: allow usperspace create cached coherent bo

 drivers/gpu/drm/etnaviv/Makefile|   1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   | 183 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h   |   7 +
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   |  22 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |   9 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c   | 185 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |  13 ++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c   |  88 ++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h   |  10 ++
 include/uapi/drm/etnaviv_drm.h  |  11 +-
 10 files changed, 415 insertions(+), 114 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h

-- 
2.25.1

[PATCH v4 5/6] drm/etnaviv: expand driver support for the PCI devices

This patch adds PCI driver support on top of what already have. Take the
GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device driver.
There is only one GPU core for the GC1000 in the LS7A1000 and LS2K1000.
Therefore, component frameworks can be avoided. Because we want to bind the
DRM driver service to the PCI driver manually.
    
We avoid using the component framework because the virtual master device
will not be used without a force override. X server and Mesa will try to
find the PCI device to use by default. Creating a virtual master device
for PCI GPUs cause unnecessary troubles.
    
Using the component framework with a PCI device is still possible; it is
just that the solo PCI device should be the master. A platform with a
single GPU core could also try the non-component code path.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/Makefile  |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 62 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  3 +
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 97 ---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 12 +++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c | 88 
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h | 10 +++
 7 files changed, 232 insertions(+), 41 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h

diff --git a/drivers/gpu/drm/etnaviv/Makefile b/drivers/gpu/drm/etnaviv/Makefile
index 46e5ffad69a6..3f8b99664a58 100644
--- a/drivers/gpu/drm/etnaviv/Makefile
+++ b/drivers/gpu/drm/etnaviv/Makefile
@@ -13,6 +13,7 @@ etnaviv-y := \
etnaviv_iommu_v2.o \
etnaviv_iommu.o \
etnaviv_mmu.o \
+   etnaviv_pci_drv.o \
etnaviv_perfmon.o \
etnaviv_sched.o
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 56c98711f8e1..7ff795c5cc79 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -21,6 +22,7 @@
 #include "etnaviv_gpu.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_mmu.h"
+#include "etnaviv_pci_drv.h"
 #include "etnaviv_perfmon.h"
 
 /*
@@ -525,6 +527,16 @@ static int etnaviv_alloc_private(struct device *dev,
return ret;
}
 
+   /*
+* Loongson Mips and LoongArch CPU(ls3a5000, ls3c5000, ls2k1000la)
+* maintain cache coherency by hardware
+*/
+   if (IS_ENABLED(CONFIG_CPU_LOONGSON64) || IS_ENABLED(CONFIG_LOONGARCH))
+   priv->has_cached_coherent = true;
+
+   dev_info(dev, "Cached coherent mode is %s\n",
+priv->has_cached_coherent ? "support" : "not support");
+
*ppriv = priv;
 
return 0;
@@ -539,10 +551,9 @@ static void etnaviv_free_private(struct 
etnaviv_drm_private *priv)
kfree(priv);
 }
 
-/*
- * Platform driver:
- */
-static int etnaviv_bind(struct device *dev)
+static struct etnaviv_drm_private *etna_private_s;
+
+int etnaviv_drm_bind(struct device *dev, bool component)
 {
struct etnaviv_drm_private *priv;
struct drm_device *drm;
@@ -558,12 +569,15 @@ static int etnaviv_bind(struct device *dev)
 
priv->drm = drm;
drm->dev_private = priv;
+   etna_private_s = priv;
 
dma_set_max_seg_size(dev, SZ_2G);
 
-   dev_set_drvdata(dev, drm);
+   if (component)
+   ret = component_bind_all(dev, drm);
+   else
+   ret = etnaviv_gpu_bind(dev, NULL, drm);
 
-   ret = component_bind_all(dev, drm);
if (ret < 0)
goto out_free_priv;
 
@@ -585,14 +599,17 @@ static int etnaviv_bind(struct device *dev)
return ret;
 }
 
-static void etnaviv_unbind(struct device *dev)
+void etnaviv_drm_unbind(struct device *dev, bool component)
 {
-   struct drm_device *drm = dev_get_drvdata(dev);
-   struct etnaviv_drm_private *priv = drm->dev_private;
+   struct etnaviv_drm_private *priv = etna_private_s;
+   struct drm_device *drm = priv->drm;
 
drm_dev_unregister(drm);
 
-   component_unbind_all(dev, drm);
+   if (component)
+   component_unbind_all(dev, drm);
+   else
+   etnaviv_gpu_unbind(dev, NULL, drm);
 
etnaviv_free_private(priv);
 
@@ -601,9 +618,22 @@ static void etnaviv_unbind(struct device *dev)
drm_dev_put(drm);
 }
 
+/*
+ * Platform driver:
+ */
+static int etnaviv_master_bind(struct device *dev)
+{
+   return etnaviv_drm_bind(dev, true);
+}
+
+static void etnaviv_master_unbind(struct device *dev)
+{
+   return etnaviv_drm_unbind(dev, true);
+}
+
 static const struct component_master_ops etnaviv_master_ops = {
-   .bind = etnaviv_bind,
-   .unbind = etnaviv_unbind,
+   .bind = etnaviv_master_bind,
+   .unbind = etnaviv_master_unbind,
 };
 
 static int etnaviv_pdev_probe(struct

[PATCH v4 1/6] drm/etnaviv: add a dedicated function to register an irq handler

Because getting IRQ from a device is platform-dependent, PCI devices have
different methods for getting an IRQ. This patch is a preparation patch to
extend support for the PCI device.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ---
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index de8c9894967c..636d3f39ddcb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1817,6 +1817,29 @@ static const struct of_device_id etnaviv_gpu_match[] = {
 };
 MODULE_DEVICE_TABLE(of, etnaviv_gpu_match);
 
+static int etnaviv_gpu_register_irq(struct etnaviv_gpu *gpu, int irq)
+{
+   struct device *dev = gpu->dev;
+   int err;
+
+   if (irq < 0) {
+   dev_err(dev, "failed to get irq: %d\n", irq);
+   return irq;
+   }
+
+   err = devm_request_irq(dev, irq, irq_handler, 0, dev_name(dev), gpu);
+   if (err) {
+   dev_err(dev, "failed to request IRQ %u: %d\n", irq, err);
+   return err;
+   }
+
+   gpu->irq = irq;
+
+   dev_info(dev, "IRQ handler registered, irq = %d\n", irq);
+
+   return 0;
+}
+
 static int etnaviv_gpu_platform_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1837,16 +1860,9 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
return PTR_ERR(gpu->mmio);
 
/* Get Interrupt: */
-   gpu->irq = platform_get_irq(pdev, 0);
-   if (gpu->irq < 0)
-   return gpu->irq;
-
-   err = devm_request_irq(>dev, gpu->irq, irq_handler, 0,
-  dev_name(gpu->dev), gpu);
-   if (err) {
-   dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq, err);
+   err = etnaviv_gpu_register_irq(gpu,  platform_get_irq(pdev, 0));
+   if (err)
return err;
-   }
 
/* Get Clocks: */
gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
-- 
2.25.1

Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT





On 29/05/2023 10:45, Icenowy Zheng wrote:

在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：

Il 26/05/23 16:24, Doug Anderson ha scritto:

Hi,

On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng 
wrote:


Currently a specific panel number is used in the Elm DTSI, which
is
corresponded to a 12" panel. However, according to the official
Chrome
OS devices document, Elm refers to Acer Chromebook R13, which, as
the
name specifies, uses a 13.3" panel, which comes with EDID
information.

As the kernel currently prioritizes the hardcoded timing
parameters
matched with the panel number compatible, a wrong timing will be
applied
to the 13.3" panel on Acer Chromebook R13, which leads to blank
display.

Because the Elm DTSI is shared with Hana board, and Hana
corresponds to
multiple devices from 11" to 14", a certain panel model number
shouldn't
be present, and driving the panel according to its EDID
information is
necessary.

Signed-off-by: Icenowy Zheng 
---
   arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)


We went through a bunch of back-and-forth here but in the end in
the
ChromeOS tree we have "edp-panel" as the "compatible" here in the
ChromeOS 5.15 tree and this makes sense.

Reviewed-by: Douglas Anderson 

...in theory one would wish for a "Fixes" tag, but I think in
previous
discussions it was decided that it was too complicated. Hardcoding
the
other compatible string has always been technically wrong, but I
guess
it worked at some point in time. The more correct way (as you're
doing
here) needs the DP AUX bus support and the generic eDP panels, both
of
which are significantly newer than the elm dts. So I guess leaving
no
"Fixes" tag is OK, or perhaps you could do the somewhat weak:

Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move
display
to ps8640 auxiliary bus")


I remember I didn't change the compatible to panel-edp because it
didn't
work at that time, but it does now... I'm not sure what actually
fixed that
and if the commit(s) was/were backported to that suggested point, so
I
would leave the Fixes tag out, as that may break older kernel.


Well at least I developed this patch on v6.3.

(In fact the same kernel config do not boot to system at all on
v6.0/v6.1 when I do make olddefconfig then build)



I applied the patch without the fixes tag. Lets stay on the secure side to not 
break older kernels.


Regards,
Matthias



Anyway, for this commit:

Reviewed-by: AngeloGioacchino Del Regno

[PATCH] pci/vgaarb: make vga_is_firmware_default() arch independent

The vga_is_firmware_default() function will work on non-x86 architectures
as long as the arch has UEFI GOP support, which passes the firmware
framebuffer base address and size.

This patch makes the vga_is_firmware_default() function arch-independent.
This could help the VGAARB subsystem make the right choice for multiple
GPU systems. Usually an integrated one and a discrete one for desktop
computers. Depending on the firmware framebuffer being put into which
GPU's VRAM, VGAARB could inherit the firmware's choice, which in turn,
is the exact choice of the user.

Signed-off-by: Sui Jingfeng 
---
 drivers/pci/vgaarb.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index 5a696078b382..f81b6c54e327 100644
--- a/drivers/pci/vgaarb.c
+++ b/drivers/pci/vgaarb.c
@@ -61,7 +61,6 @@ static bool vga_arbiter_used;
 static DEFINE_SPINLOCK(vga_lock);
 static DECLARE_WAIT_QUEUE_HEAD(vga_wait_queue);
 
-
 static const char *vga_iostate_to_str(unsigned int iostate)
 {
/* Ignore VGA_RSRC_IO and VGA_RSRC_MEM */
@@ -545,7 +544,6 @@ EXPORT_SYMBOL(vga_put);
 
 static bool vga_is_firmware_default(struct pci_dev *pdev)
 {
-#if defined(CONFIG_X86) || defined(CONFIG_IA64)
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
struct resource *r;
@@ -571,7 +569,7 @@ static bool vga_is_firmware_default(struct pci_dev *pdev)
 
return true;
}
-#endif
+
return false;
 }
 
@@ -865,8 +863,7 @@ static bool vga_arbiter_del_pci_device(struct pci_dev *pdev)
 }
 
 /* this is called with the lock */
-static inline void vga_update_device_decodes(struct vga_device *vgadev,
-int new_decodes)
+static void vga_update_device_decodes(struct vga_device *vgadev, int 
new_decodes)
 {
struct device *dev = >pdev->dev;
int old_decodes, decodes_removed, decodes_unlocked;
-- 
2.25.1

Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support

2023-05-29 Thread Laurent Pinchart

On Mon, May 29, 2023 at 02:22:06PM +, Biju Das wrote:
> HI Laurent,
> 
> Thanks for the feedback.
> 
> > Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> > Unit support
> > 
> > Hi Biju,
> > 
> > On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> > > Hi DRM maintainers,
> > >
> > > Gentle ping.
> > 
> > Sorry, I was on holidays the last two weeks.
> > 
> > > Are we happy with moving all Renesas drm drivers to Renesas specific
> > > directory or preference is for separate one??
> > 
> > This works for me.
> > 
> > > If it is later, I can send RZ/G2L drm driver separate.
> > >
> > > Otherwise, I need to rebase and resend.
> > 
> > Your series applies cleanly on top of the latest drm-next branch. Is
> > there a specific need to rebase and resend ?
> 
> Nope. After my patch series there were
> some patches from Geert for drm/shmobile merged to drm-misc-next by Thomas.
> 
> Maybe git managed this automatically??

Probably, git is nice :-)

> > I haven't had time to review patch 4/5 (the driver) yet. All the rest
> > looks good to me. Should I already include 1/5 in my next pull request ?
> 
> Yes, please.

OK, I will do so. I've reviewed 4/5 in the meantime, but changes are
needed, so I won't wait for v10 before applying 1/5.

> > > Please let me know your preference.
> > >
> > > Cheers,
> > > Biju
> > >
> > >
> > > > -Original Message-
> > > > From: Biju Das
> > > > Sent: Monday, May 15, 2023 8:58 AM
> > > > To: David Airlie ; Daniel Vetter
> > > > ; Philipp Zabel ; Geert
> > > > Uytterhoeven ; Laurent Pinchart
> > > > ; Kieran Bingham
> > > > 
> > > > Cc: dri-devel@lists.freedesktop.org;
> > > > linux-renesas-...@vger.kernel.org;
> > > > Fabrizio Castro ; Prabhakar Mahadev
> > > > Lad 
> > > > Subject: RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > Display Unit support
> > > >
> > > > Hi All,
> > > >
> > > > Gentle ping. Are we happy with this patch series?
> > > >
> > > > Cheers,
> > > > Biju
> > > >
> > > > > Subject: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > > Display Unit support
> > > > >
> > > > > RZ/G2L LCD controller composed of Frame compression
> > > > > Processor(FCPVD), Video signal processor (VSPD) and Display
> > > > > unit(DU). The output of LCDC is connected to Display parallel
> > > > > interface and MIPI link video interface.
> > > > >
> > > > > The output from DSI is connected to ADV7535.
> > > > >
> > > > > Created a vendor specific directory renesas and moved all renesas
> > > > > drm drivers to it (rcar-du and shmobile). Then added support for
> > > > > RZ/G2L DU DRM driver by creating rz_du directory.
> > > > >
> > > > > Ref:
> > > > >
> > > > >
> > > > > v8->v9:
> > > > >  * Added Rb tag from Laurent and Acked-by tag from Kieran for
> > patch#1.
> > > > >  * Added Rb tag from Laurent and Geert for patch#3.
> > > > >  * Dropped reset_control_assert() from error patch for
> > > > > rzg2l_du_crtc_get() as
> > > > >suggested by Philipp Zabel.
> > > > >  * Added Rb tag from Laurent oatch#5.
> > > > >  * Updated MAINTAINERS entries for common parts(Makefile and
> > Kconfig).
> > > > > v7->v8:
> > > > >  * Moved rcar-du and shmobile DRM drivers to renesas specific
> > > > > vendor directory.
> > > > >  * Fixed the typo vsp2->du in RZ/V2L DU bindings patch.
> > > > >  * Added Rb tag from Rob for RZ/V2L DU bindings patch.
> > > > >  * Dropped RCar du lib and created RZ/G2L DU DRM driver by
> > > > > creating rz_du folder.
> > > > >  * Updated MAINTAINERS entries.
> > > > > v6->v7:
> > > > >  * Split DU lib and  RZ/G2L du driver as separate patch series as
> > > > >DU support added to more platforms based on RZ/G2L alike SoCs.
> > > > >  * Rebased to latest drm-tip.
> > > > >  * Added patch #2 for binding support for RZ/V2L DU
> > > > >  * Added patch #4 for driver support for RZ/V2L DU
> > > > >  * Added patch #5 for SoC DTSI support for RZ/G2L DU
> > > > >  * Added patch #6 for SoC DTSI support for RZ/V2L DU
> > > > >  * Added patch #7 for Enabling DU on SMARC EVK based on
> > > > > RZ/{G2L,V2L} SoCs.
> > > > >  * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC
> > SoC.
> > > > > v5->v6:
> > > > >  * Merged DU lib and RZ/G2L du driver in same patch series
> > > > >  * Rebased to latest drm-misc.
> > > > >  * Merged patch#1 to RZ/G2L Driver patch.
> > > > >  * Updated KConfig dependency from ARCH_RENESAS->ARCH_RZG2L.
> > > > >  * Optimized rzg2l_du_output_name() by removing unsupported
> > outputs.
> > > > >
> > > > > v4->v5:
> > > > >  * Added Rb tag from Rob for binding patch.
> > > > >  * Started using RCar DU libs(kms, vsp and encoder)
> > > > >  * Started using rcar_du_device, rcar_du_write, rcar_du_crtc,
> > > > >rcar_du_format_info and rcar_du_encoder.
> > > > > v3->v4:
> > > > >  * Changed compatible name from
> > > > > renesas,du-r9a07g044->renesas,r9a07g044-
> > > > > du
> > > > >  * started using same compatible for RZ/G2{L,LC}
> > > > >  * Removed rzg2l_du_group.h and struct

Re: [PATCH v9 RESEND 4/5] drm: Add RZ/G2L DU Support

2023-05-29 Thread Laurent Pinchart

Hi Biju,

Thank you for the patch.

This is a partial review, because the driver is big, and because some
changes in v10 will (hopefully) simplify the code and make review
easier.

On Tue, May 02, 2023 at 11:09:11AM +0100, Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
> 
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to support the blending of two picture layers and
> raster operations (ROPs).
> 
> The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> alike SoCs.
> 
> Signed-off-by: Biju Das 
> ---
> Ref:
>  
> https://lore.kernel.org/linux-renesas-soc/os0pr01mb5922717e4ccfe07f3c25fbc986...@os0pr01mb5922.jpnprd01.prod.outlook.com/#t
> v8->v9:
>  * Dropped reset_control_assert() from error patch for rzg2l_du_crtc_get() as
>suggested by Philipp Zabel.
> v7->v8:
>  * Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du 
> folder.
>  * Updated KConfig and Makefile.
> v6->v7:
>  * Split DU lib and  RZ/G2L du driver as separate patch series as
>DU support added to more platforms based on RZ/G2L alike SoCs.
>  * Rebased to latest drm-tip.
>  * Added patch #2 for binding support for RZ/V2L DU
>  * Added patch #4 for driver support for RZ/V2L DU
>  * Added patch #5 for SoC DTSI support for RZ/G2L DU
>  * Added patch #6 for SoC DTSI support for RZ/V2L DU
>  * Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
>  * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
> ---
>  drivers/gpu/drm/renesas/Kconfig   |   1 +
>  drivers/gpu/drm/renesas/Makefile  |   1 +
>  drivers/gpu/drm/renesas/rz-du/Kconfig |  20 +
>  drivers/gpu/drm/renesas/rz-du/Makefile|   8 +
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 714 
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h |  99 +++
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c  | 188 +
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h  |  89 ++
>  .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c  | 112 +++
>  .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h  |  28 +
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c  | 770 ++
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h  |  43 +
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h |  67 ++
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c  | 430 ++
>  drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h  |  94 +++
>  15 files changed, 2664 insertions(+)
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/Kconfig
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/Makefile
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
>  create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h
> 
> diff --git a/drivers/gpu/drm/renesas/Kconfig b/drivers/gpu/drm/renesas/Kconfig
> index 3777dad17f81..21862a8ef710 100644
> --- a/drivers/gpu/drm/renesas/Kconfig
> +++ b/drivers/gpu/drm/renesas/Kconfig
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  
>  source "drivers/gpu/drm/renesas/rcar-du/Kconfig"
> +source "drivers/gpu/drm/renesas/rz-du/Kconfig"
>  source "drivers/gpu/drm/renesas/shmobile/Kconfig"
> diff --git a/drivers/gpu/drm/renesas/Makefile 
> b/drivers/gpu/drm/renesas/Makefile
> index ec0e89e7a592..b8d8bc53967f 100644
> --- a/drivers/gpu/drm/renesas/Makefile
> +++ b/drivers/gpu/drm/renesas/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  obj-y += rcar-du/
> +obj-y += rz-du/
>  obj-$(CONFIG_DRM_SHMOBILE) += shmobile/
> diff --git a/drivers/gpu/drm/renesas/rz-du/Kconfig 
> b/drivers/gpu/drm/renesas/rz-du/Kconfig
> new file mode 100644
> index ..90b1bf72e23b
> --- /dev/null
> +++ b/drivers/gpu/drm/renesas/rz-du/Kconfig
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config DRM_RZG2L_DU
> + tristate "DRM Support for RZ/G2L Display Unit"
> + depends on DRM && OF
> + depends on ARM64

Does the driver fail to compile on !ARM64 platforms ? If no, I'd drop
this.

> + depends on DRM_RCAR_VSP
> + depends on ARCH_RZG2L || COMPILE_TEST
> + select DRM_KMS_HELPER
> + select DRM_GEM_DMA_HELPER

Alphabetical order please.

> + select VIDEOMODE_HELPERS
> + help
> +   Choose this option if you have an RZ/G2L alike chipset.
> +   If M is selected the

[PATCH v4 8/8] drm/mediatek: dpi: Add mt8195 hdmi to DPI driver

Add the DPI1 hdmi path support in mtk dpi driver

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 121 ++--
 drivers/gpu/drm/mediatek/mtk_dpi_regs.h |   5 ++
 2 files changed, 119 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 948a53f1f4b3..b83a38e8bd60 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -9,12 +9,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -67,11 +70,14 @@ struct mtk_dpi {
struct drm_bridge *next_bridge;
struct drm_connector *connector;
void __iomem *regs;
+   struct reset_control *reset_ctl;
struct device *dev;
struct device *mmsys_dev;
struct clk *engine_clk;
+   struct clk *dpi_ck_cg;
struct clk *pixel_clk;
struct clk *tvd_clk;
+   struct clk *hdmi_cg;
int irq;
struct drm_display_mode mode;
const struct mtk_dpi_conf *conf;
@@ -138,6 +144,7 @@ struct mtk_dpi_yc_limit {
  * @csc_enable_bit: Enable bit of CSC.
  * @pixels_per_iter: Quantity of transferred pixels per iteration.
  * @edge_cfg_in_mmsys: If the edge configuration for DPI's output needs to be 
set in MMSYS.
+ * @is_internal_hdmi: True if this DPI block is directly connected to SoC 
internal HDMI block.
  */
 struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
@@ -157,6 +164,7 @@ struct mtk_dpi_conf {
u32 csc_enable_bit;
u32 pixels_per_iter;
bool edge_cfg_in_mmsys;
+   bool is_internal_hdmi;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -471,8 +479,14 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
return;
 
mtk_dpi_disable(dpi);
+
+   reset_control_rearm(dpi->reset_ctl);
+
clk_disable_unprepare(dpi->pixel_clk);
clk_disable_unprepare(dpi->engine_clk);
+   clk_disable_unprepare(dpi->dpi_ck_cg);
+   clk_disable_unprepare(dpi->hdmi_cg);
+   clk_disable_unprepare(dpi->tvd_clk);
 }
 
 static int mtk_dpi_power_on(struct mtk_dpi *dpi)
@@ -488,15 +502,44 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
goto err_refcount;
}
 
+   ret = clk_prepare_enable(dpi->tvd_clk);
+   if (ret) {
+   dev_err(dpi->dev, "Failed to enable tvd pll: %d\n", ret);
+   goto err_engine;
+   }
+
+   ret = clk_prepare_enable(dpi->hdmi_cg);
+   if (ret) {
+   dev_err(dpi->dev, "Failed to enable hdmi_cg clock: %d\n", ret);
+   goto err_tvd;
+   }
+
+   ret = clk_prepare_enable(dpi->dpi_ck_cg);
+   if (ret) {
+   dev_err(dpi->dev, "Failed to enable dpi_ck_cg clock: %d\n", 
ret);
+   goto err_hdmi_cg;
+   }
+
ret = clk_prepare_enable(dpi->pixel_clk);
if (ret) {
dev_err(dpi->dev, "Failed to enable pixel clock: %d\n", ret);
goto err_pixel;
}
 
+   reset_control_reset(dpi->reset_ctl);
+
+   if (dpi->pinctrl && dpi->pins_dpi)
+   pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
+
return 0;
 
 err_pixel:
+   clk_disable_unprepare(dpi->dpi_ck_cg);
+err_hdmi_cg:
+   clk_disable_unprepare(dpi->hdmi_cg);
+err_tvd:
+   clk_disable_unprepare(dpi->tvd_clk);
+err_engine:
clk_disable_unprepare(dpi->engine_clk);
 err_refcount:
dpi->refcount--;
@@ -541,7 +584,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
else
clk_set_rate(dpi->pixel_clk, vm.pixelclock);
 
-
vm.pixelclock = clk_get_rate(dpi->pixel_clk);
 
dev_dbg(dpi->dev, "Got  PLL %lu Hz, pixel clock %lu Hz\n",
@@ -608,7 +650,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
if (dpi->conf->support_direct_pin) {
mtk_dpi_config_yc_map(dpi, dpi->yc_map);
mtk_dpi_config_2n_h_fre(dpi);
-   mtk_dpi_dual_edge(dpi);
+   /* DPI could be connecting to external bridge
+* or internal HDMI encoder. */
+   if (dpi->conf->is_internal_hdmi) {
+   mtk_dpi_mask(dpi, DPI_CON, DPI_OUTPUT_1T1P_EN,
+DPI_OUTPUT_1T1P_EN);
+   mtk_dpi_mask(dpi, DPI_CON, DPI_INPUT_2P_EN,
+DPI_INPUT_2P_EN);
+   } else {
+   mtk_dpi_dual_edge(dpi);
+   }
mtk_dpi_config_disable_edge(dpi);
}
if (dpi->conf->input_2pixel) {
@@ -723,7 +774,10 @@ static void mtk_dpi_bridge_disable(struct drm_bridge 
*bridge)
 {
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
-   mtk_dpi_power_off(dpi);
+   if (dpi->conf->is_internal_hdmi)
+

[PATCH v4 3/8] drm/mediatek: extract common functions from the mtk hdmi driver

Create a common "framework" that can be used to add support for
different hdmi IPs within the mediatek range of products.

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/Makefile  |   3 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c| 596 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.h|  18 +
 drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 407 
 drivers/gpu/drm/mediatek/mtk_hdmi_common.h | 207 ++
 5 files changed, 666 insertions(+), 565 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index d4d193f60271..79bbaa58893e 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -22,7 +22,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
 
 mediatek-drm-hdmi-objs := mtk_cec.o \
  mtk_hdmi.o \
- mtk_hdmi_ddc.o
+ mtk_hdmi_common.o \
+ mtk_hdmi_ddc.o \
 
 obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
 
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index b526a88663e7..41a7593887fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -31,162 +31,18 @@
 #include 
 
 #include "mtk_cec.h"
-#include "mtk_hdmi.h"
+#include "mtk_hdmi_common.h"
 #include "mtk_hdmi_regs.h"
 
 #define NCTS_BYTES 7
 
-enum mtk_hdmi_clk_id {
-   MTK_HDMI_CLK_HDMI_PIXEL,
-   MTK_HDMI_CLK_HDMI_PLL,
-   MTK_HDMI_CLK_AUD_BCLK,
-   MTK_HDMI_CLK_AUD_SPDIF,
-   MTK_HDMI_CLK_COUNT
+const char * const mtk_hdmi_clk_names_v1[MTK_HDMIV1_CLK_COUNT] = {
+   [MTK_HDMIV1_CLK_HDMI_PIXEL] = "pixel",
+   [MTK_HDMIV1_CLK_HDMI_PLL] = "pll",
+   [MTK_HDMIV1_CLK_AUD_BCLK] = "bclk",
+   [MTK_HDMIV1_CLK_AUD_SPDIF] = "spdif",
 };
 
-enum hdmi_aud_input_type {
-   HDMI_AUD_INPUT_I2S = 0,
-   HDMI_AUD_INPUT_SPDIF,
-};
-
-enum hdmi_aud_i2s_fmt {
-   HDMI_I2S_MODE_RJT_24BIT = 0,
-   HDMI_I2S_MODE_RJT_16BIT,
-   HDMI_I2S_MODE_LJT_24BIT,
-   HDMI_I2S_MODE_LJT_16BIT,
-   HDMI_I2S_MODE_I2S_24BIT,
-   HDMI_I2S_MODE_I2S_16BIT
-};
-
-enum hdmi_aud_mclk {
-   HDMI_AUD_MCLK_128FS,
-   HDMI_AUD_MCLK_192FS,
-   HDMI_AUD_MCLK_256FS,
-   HDMI_AUD_MCLK_384FS,
-   HDMI_AUD_MCLK_512FS,
-   HDMI_AUD_MCLK_768FS,
-   HDMI_AUD_MCLK_1152FS,
-};
-
-enum hdmi_aud_channel_type {
-   HDMI_AUD_CHAN_TYPE_1_0 = 0,
-   HDMI_AUD_CHAN_TYPE_1_1,
-   HDMI_AUD_CHAN_TYPE_2_0,
-   HDMI_AUD_CHAN_TYPE_2_1,
-   HDMI_AUD_CHAN_TYPE_3_0,
-   HDMI_AUD_CHAN_TYPE_3_1,
-   HDMI_AUD_CHAN_TYPE_4_0,
-   HDMI_AUD_CHAN_TYPE_4_1,
-   HDMI_AUD_CHAN_TYPE_5_0,
-   HDMI_AUD_CHAN_TYPE_5_1,
-   HDMI_AUD_CHAN_TYPE_6_0,
-   HDMI_AUD_CHAN_TYPE_6_1,
-   HDMI_AUD_CHAN_TYPE_7_0,
-   HDMI_AUD_CHAN_TYPE_7_1,
-   HDMI_AUD_CHAN_TYPE_3_0_LRS,
-   HDMI_AUD_CHAN_TYPE_3_1_LRS,
-   HDMI_AUD_CHAN_TYPE_4_0_CLRS,
-   HDMI_AUD_CHAN_TYPE_4_1_CLRS,
-   HDMI_AUD_CHAN_TYPE_6_1_CS,
-   HDMI_AUD_CHAN_TYPE_6_1_CH,
-   HDMI_AUD_CHAN_TYPE_6_1_OH,
-   HDMI_AUD_CHAN_TYPE_6_1_CHR,
-   HDMI_AUD_CHAN_TYPE_7_1_LH_RH,
-   HDMI_AUD_CHAN_TYPE_7_1_LSR_RSR,
-   HDMI_AUD_CHAN_TYPE_7_1_LC_RC,
-   HDMI_AUD_CHAN_TYPE_7_1_LW_RW,
-   HDMI_AUD_CHAN_TYPE_7_1_LSD_RSD,
-   HDMI_AUD_CHAN_TYPE_7_1_LSS_RSS,
-   HDMI_AUD_CHAN_TYPE_7_1_LHS_RHS,
-   HDMI_AUD_CHAN_TYPE_7_1_CS_CH,
-   HDMI_AUD_CHAN_TYPE_7_1_CS_OH,
-   HDMI_AUD_CHAN_TYPE_7_1_CS_CHR,
-   HDMI_AUD_CHAN_TYPE_7_1_CH_OH,
-   HDMI_AUD_CHAN_TYPE_7_1_CH_CHR,
-   HDMI_AUD_CHAN_TYPE_7_1_OH_CHR,
-   HDMI_AUD_CHAN_TYPE_7_1_LSS_RSS_LSR_RSR,
-   HDMI_AUD_CHAN_TYPE_6_0_CS,
-   HDMI_AUD_CHAN_TYPE_6_0_CH,
-   HDMI_AUD_CHAN_TYPE_6_0_OH,
-   HDMI_AUD_CHAN_TYPE_6_0_CHR,
-   HDMI_AUD_CHAN_TYPE_7_0_LH_RH,
-   HDMI_AUD_CHAN_TYPE_7_0_LSR_RSR,
-   HDMI_AUD_CHAN_TYPE_7_0_LC_RC,
-   HDMI_AUD_CHAN_TYPE_7_0_LW_RW,
-   HDMI_AUD_CHAN_TYPE_7_0_LSD_RSD,
-   HDMI_AUD_CHAN_TYPE_7_0_LSS_RSS,
-   HDMI_AUD_CHAN_TYPE_7_0_LHS_RHS,
-   HDMI_AUD_CHAN_TYPE_7_0_CS_CH,
-   HDMI_AUD_CHAN_TYPE_7_0_CS_OH,
-   HDMI_AUD_CHAN_TYPE_7_0_CS_CHR,
-   HDMI_AUD_CHAN_TYPE_7_0_CH_OH,
-   HDMI_AUD_CHAN_TYPE_7_0_CH_CHR,
-   HDMI_AUD_CHAN_TYPE_7_0_OH_CHR,
-   HDMI_AUD_CHAN_TYPE_7_0_LSS_RSS_LSR_RSR,
-   HDMI_AUD_CHAN_TYPE_8_0_LH_RH_CS,
-   HDMI_AUD_CHAN_TYPE_UNKNOWN = 0xFF
-};
-
-enum hdmi_aud_channel_swap_type {
-   HDMI_AUD_SWAP_LR,
-   HDMI_AUD_SWAP_LFE_CC,
-   HDMI_AUD_SWAP_LSRS,
-   HDMI_AUD_SWAP_RLS_RRS,
-   HDMI_AUD_SWAP_LR_STATUS,
-};
-
-struct hdmi_audio_param {
-   enum hdmi_audio_coding_type aud_codec;
-   enum hdmi_audio_sample_size aud_sampe_size;
-   enum hdmi_aud_input_type aud_input_type;
-   enum hdmi_aud_i2s_fmt aud_i2s_fmt;
-   enum hdmi_aud_mclk aud_mclk;
-

[PATCH v4 7/8] dt-bindings: display: mediatek: dpi: Add compatible for MediaTek MT8195

Add dt-binding documentation of dpi for MediaTek MT8195 SoC.

Acked-by: Krzysztof Kozlowski 
Signed-off-by: Guillaume Ranquet 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index d976380801e3..cabe4031729a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -25,6 +25,7 @@ properties:
   - mediatek,mt8186-dpi
   - mediatek,mt8188-dp-intf
   - mediatek,mt8192-dpi
+  - mediatek,mt8195-dpi
   - mediatek,mt8195-dp-intf
 
   reg:

-- 
2.40.0

[PATCH v4 6/8] drm/mediatek: hdmi: v2: add audio support

Add HDMI audio support for v2

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_hdmi_common.c |   1 +
 drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 198 +
 drivers/gpu/drm/mediatek/mtk_hdmi_v2.h |   4 +-
 3 files changed, 202 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
index 97a00102a970..9ed86834ca85 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
@@ -346,6 +346,7 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_v2 = {
.mtk_hdmi_output_init = mtk_hdmi_output_init_v2,
.mtk_hdmi_clk_disable = mtk_hdmi_clk_disable_v2,
.mtk_hdmi_clk_enable = mtk_hdmi_clk_enable_v2,
+   .mtk_hdmi_set_codec_pdata = mtk_hdmi_set_codec_pdata_v2,
.mtk_hdmi_clock_names = mtk_hdmi_clk_names_v2,
.num_clocks = MTK_HDMIV2_CLK_COUNT,
 };
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
index 98b1d50ecd72..0e41dfb36db4 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
@@ -150,6 +150,24 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi, 
bool black)
regmap_update_bits(hdmi->regs, TOP_VMUTE_CFG1, REG_VMUTE_EN, val);
 }
 
+static void mtk_hdmi_hw_aud_mute(struct mtk_hdmi *hdmi)
+{
+   u32 aip, val;
+
+   regmap_read(hdmi->regs, AIP_CTRL, );
+
+   val = FIELD_PREP(AUD_MUTE_FIFO_EN, 1);
+   if (aip & DSD_EN)
+   val |= FIELD_PREP(DSD_MUTE_DATA, 1);
+
+   regmap_update_bits(hdmi->regs, AIP_TXCTRL, val, val);
+}
+
+static void mtk_hdmi_hw_aud_unmute(struct mtk_hdmi *hdmi)
+{
+   regmap_update_bits(hdmi->regs, AIP_TXCTRL, AUD_MUTE_FIFO_EN, 
AUD_MUTE_DIS);
+}
+
 static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
 {
regmap_update_bits(hdmi->regs, HDMITX_CONFIG, HDMITX_SW_RSTB, 0);
@@ -766,6 +784,7 @@ static void mtk_hdmi_audio_reset(struct mtk_hdmi *hdmi, 
bool rst)
 static void mtk_hdmi_aud_output_config(struct mtk_hdmi *hdmi,
   struct drm_display_mode *display_mode)
 {
+   mtk_hdmi_hw_aud_mute(hdmi);
mtk_hdmi_aud_enable_packet(hdmi, false);
mtk_hdmi_audio_reset(hdmi, true);
mtk_hdmi_aip_ctrl_init(hdmi);
@@ -778,6 +797,7 @@ static void mtk_hdmi_aud_output_config(struct mtk_hdmi 
*hdmi,
usleep_range(25, 50);
mtk_hdmi_aud_on_off_hw_ncts(hdmi, true);
mtk_hdmi_aud_enable_packet(hdmi, true);
+   mtk_hdmi_hw_aud_unmute(hdmi);
 }
 
 void mtk_hdmi_output_init_v2(struct mtk_hdmi *hdmi)
@@ -794,6 +814,16 @@ void mtk_hdmi_output_init_v2(struct mtk_hdmi *hdmi)
hdmi->hpd = HDMI_PLUG_OUT;
 }
 
+static void mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
+struct hdmi_audio_param *param)
+{
+   if (!hdmi->audio_enable)
+   return;
+
+   memcpy(>aud_param, param, sizeof(*param));
+   mtk_hdmi_aud_output_config(hdmi, >mode);
+}
+
 static void mtk_hdmi_change_video_resolution(struct mtk_hdmi *hdmi)
 {
mtk_hdmi_hw_reset(hdmi);
@@ -812,6 +842,7 @@ static void mtk_hdmi_change_video_resolution(struct 
mtk_hdmi *hdmi)
 
usleep_range(5, 10);
mtk_hdmi_hw_vid_black(hdmi, true);
+   mtk_hdmi_hw_aud_mute(hdmi);
mtk_hdmi_hw_send_av_unmute(hdmi);
 
regmap_update_bits(hdmi->regs, TOP_CFG01, NULL_PKT_VSYNC_HIGH_EN | 
NULL_PKT_EN, NULL_PKT_VSYNC_HIGH_EN);
@@ -1022,6 +1053,7 @@ static void mtk_hdmi_bridge_disable(struct drm_bridge 
*bridge,
mtk_hdmi_hw_send_av_mute(hdmi);
usleep_range(5, 50050);
mtk_hdmi_hw_vid_black(hdmi, true);
+   mtk_hdmi_hw_aud_mute(hdmi);
mtk_hdmi_disable_hdcp_encrypt(hdmi);
usleep_range(5, 50050);
 
@@ -1030,6 +1062,14 @@ static void mtk_hdmi_bridge_disable(struct drm_bridge 
*bridge,
hdmi->enabled = false;
 }
 
+static void mtk_hdmi_handle_plugged_change(struct mtk_hdmi *hdmi, bool plugged)
+{
+   mutex_lock(>update_plugged_status_lock);
+   if (hdmi->plugged_cb && hdmi->codec_dev)
+   hdmi->plugged_cb(hdmi->codec_dev, plugged);
+   mutex_unlock(>update_plugged_status_lock);
+}
+
 static void mtk_hdmi_bridge_post_disable(struct drm_bridge *bridge,
 struct drm_bridge_state *old_state)
 {
@@ -1041,6 +1081,9 @@ static void mtk_hdmi_bridge_post_disable(struct 
drm_bridge *bridge,
phy_power_off(hdmi->phy);
 
hdmi->powered = false;
+
+   /* signal the disconnect event to audio codec */
+   mtk_hdmi_handle_plugged_change(hdmi, false);
 }
 
 static void mtk_hdmi_bridge_pre_enable(struct drm_bridge *bridge,
@@ -1077,6 +1120,10 @@ static void mtk_hdmi_bridge_enable(struct drm_bridge 
*bridge,
mtk_hdmi_hw_avi_infoframe(hdmi, buffer_avi, sizeof(buffer_avi));
 
mtk_hdmi_hw_vid_black(hdmi, false);
+

[PATCH v4 5/8] drm/mediatek: hdmi: add v2 support

Adds hdmi and hdmi-ddc support for v2 IP.

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/Kconfig|2 +
 drivers/gpu/drm/mediatek/Makefile   |2 +
 drivers/gpu/drm/mediatek/mtk_hdmi_common.c  |   13 +
 drivers/gpu/drm/mediatek/mtk_hdmi_common.h  |1 +
 drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c  |  362 +
 drivers/gpu/drm/mediatek/mtk_hdmi_regs_v2.h |  276 +++
 drivers/gpu/drm/mediatek/mtk_hdmi_v2.c  | 1105 +++
 drivers/gpu/drm/mediatek/mtk_hdmi_v2.h  |   30 +
 8 files changed, 1791 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index b451dee64d34..242992cd1439 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -34,5 +34,7 @@ config DRM_MEDIATEK_HDMI
depends on DRM_MEDIATEK
select SND_SOC_HDMI_CODEC if SND_SOC
select PHY_MTK_HDMI
+   select DRM_DISPLAY_HDMI_HELPER
+   select DRM_DISPLAY_HELPER
help
  DRM/KMS HDMI driver for Mediatek SoCs
diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 79bbaa58893e..bb60856b629e 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -24,6 +24,8 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
  mtk_hdmi.o \
  mtk_hdmi_common.o \
  mtk_hdmi_ddc.o \
+ mtk_hdmi_ddc_v2.o \
+ mtk_hdmi_v2.o \
 
 obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
 
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
index d7f3d29138d8..97a00102a970 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
@@ -341,6 +341,15 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8173 = {
.num_clocks = MTK_HDMIV1_CLK_COUNT,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_v2 = {
+   .bridge_funcs = _v2_hdmi_bridge_funcs,
+   .mtk_hdmi_output_init = mtk_hdmi_output_init_v2,
+   .mtk_hdmi_clk_disable = mtk_hdmi_clk_disable_v2,
+   .mtk_hdmi_clk_enable = mtk_hdmi_clk_enable_v2,
+   .mtk_hdmi_clock_names = mtk_hdmi_clk_names_v2,
+   .num_clocks = MTK_HDMIV2_CLK_COUNT,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt2701-hdmi",
  .data = _hdmi_conf_mt2701,
@@ -351,6 +360,9 @@ static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt8173-hdmi",
  .data = _hdmi_conf_mt8173,
},
+   { .compatible = "mediatek,mt8195-hdmi",
+ .data = _hdmi_conf_v2,
+   },
{}
 };
 MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
@@ -399,6 +411,7 @@ static struct platform_driver mtk_hdmi_driver = {
 static struct platform_driver * const mtk_hdmi_drivers[] = {
_hdmi_ddc_driver,
_cec_driver,
+   _hdmi_ddc_v2_driver,
_hdmi_driver,
 };
 
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_common.h 
b/drivers/gpu/drm/mediatek/mtk_hdmi_common.h
index 6e4633981018..86de8942727d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_common.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_common.h
@@ -27,6 +27,7 @@
 
 #include "mtk_cec.h"
 #include "mtk_hdmi.h"
+#include "mtk_hdmi_v2.h"
 
 struct mtk_hdmi_conf {
bool tz_disabled;
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c
new file mode 100644
index ..c9e8424109f0
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Copyright (c) 2021 BayLibre, SAS
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "mtk_hdmi_regs_v2.h"
+#include "mtk_hdmi_v2.h"
+
+#define EDID_ID 0x50
+#define DDC2_CLOK 572 /* BIM=208M/(v*4) = 90Khz */
+#define DDC2_CLOK_EDID 832 /* BIM=208M/(v*4) = 62.5Khz */
+
+struct mtk_hdmi_ddc {
+   struct device *dev;
+   /* Serialize read/write operations */
+   struct mutex mtx;
+   struct i2c_adapter adap;
+   struct clk *clk;
+   void __iomem *regs;
+};
+
+enum sif_bit_t_hdmi {
+   SIF_8_BIT_HDMI, /* /< [8 bits data address.] */
+   SIF_16_BIT_HDMI, /* /< [16 bits data address.] */
+};
+
+static void hdmi_ddc_request(struct mtk_hdmi_ddc *ddc)
+{
+   regmap_update_bits(ddc->regs, HDCP2X_POL_CTRL, HDCP2X_DIS_POLL_EN,
+HDCP2X_DIS_POLL_EN);
+}
+
+static void mtk_ddc_wr_one(struct mtk_hdmi_ddc *ddc, unsigned int addr_id,
+  unsigned int offset_id, unsigned char wr_data)
+{
+   u32 val;
+
+   regmap_read(ddc->regs, HDCP2X_DDCM_STATUS, );
+
+   if

[PATCH v4 1/8] dt-bindings: display: mediatek: add MT8195 hdmi bindings

Add mt8195 SoC bindings for hdmi and hdmi-ddc

On mt8195 the ddc i2c controller is part of the hdmi IP block and thus has no
specific register range, power domain or interrupt, making it simpler
than the legacy "mediatek,hdmi-ddc" binding.

Signed-off-by: Guillaume Ranquet 
---
 .../bindings/display/mediatek/mediatek,hdmi.yaml   | 59 ++
 .../display/mediatek/mediatek,mt8195-hdmi-ddc.yaml | 45 +
 2 files changed, 93 insertions(+), 11 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
index b90b6d18a828..4f62e6b94048 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -21,6 +21,7 @@ properties:
   - mediatek,mt7623-hdmi
   - mediatek,mt8167-hdmi
   - mediatek,mt8173-hdmi
+  - mediatek,mt8195-hdmi
 
   reg:
 maxItems: 1
@@ -29,18 +30,10 @@ properties:
 maxItems: 1
 
   clocks:
-items:
-  - description: Pixel Clock
-  - description: HDMI PLL
-  - description: Bit Clock
-  - description: S/PDIF Clock
+maxItems: 4
 
   clock-names:
-items:
-  - const: pixel
-  - const: pll
-  - const: bclk
-  - const: spdif
+maxItems: 4
 
   phys:
 maxItems: 1
@@ -58,6 +51,9 @@ properties:
 description: |
   phandle link and register offset to the system configuration registers.
 
+  power-domains:
+maxItems: 1
+
   ports:
 $ref: /schemas/graph.yaml#/properties/ports
 
@@ -86,9 +82,50 @@ required:
   - clock-names
   - phys
   - phy-names
-  - mediatek,syscon-hdmi
   - ports
 
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: mediatek,mt8195-hdmi
+then:
+  properties:
+clocks:
+  items:
+- description: APB
+- description: HDCP
+- description: HDCP 24M
+- description: Split HDMI
+clock-names:
+  items:
+- const: hdmi_apb_sel
+- const: hdcp_sel
+- const: hdcp24_sel
+- const: split_hdmi
+
+  required:
+- power-domains
+else:
+  properties:
+clocks:
+  items:
+- description: Pixel Clock
+- description: HDMI PLL
+- description: Bit Clock
+- description: S/PDIF Clock
+
+clock-names:
+  items:
+- const: pixel
+- const: pll
+- const: bclk
+- const: spdif
+
+  required:
+- mediatek,syscon-hdmi
+
 additionalProperties: false
 
 examples:
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
new file mode 100644
index ..84c096835b47
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI DDC for mt8195
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt8195-hdmi-ddc
+
+  clocks:
+maxItems: 1
+
+  mediatek,hdmi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  A phandle to the mt8195 hdmi controller
+
+required:
+  - compatible
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+hdmiddc0: i2c {
+  compatible = "mediatek,mt8195-hdmi-ddc";
+  mediatek,hdmi = <>;
+  clocks = <>;
+};
+
+...

-- 
2.40.0

[PATCH v4 2/8] drm/mediatek: hdmi: use a regmap instead of iomem

To prepare support for newer chips that need to share their address
range with a dedicated ddc driver, use a regmap.

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 173 ++--
 1 file changed, 65 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0a8e0a13f516..b526a88663e7 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -171,7 +171,7 @@ struct mtk_hdmi {
u32 ibias_up;
struct regmap *sys_regmap;
unsigned int sys_offset;
-   void __iomem *regs;
+   struct regmap *regs;
enum hdmi_colorspace csp;
struct hdmi_audio_param aud_param;
bool audio_enable;
@@ -187,50 +187,10 @@ static inline struct mtk_hdmi 
*hdmi_ctx_from_bridge(struct drm_bridge *b)
return container_of(b, struct mtk_hdmi, bridge);
 }
 
-static u32 mtk_hdmi_read(struct mtk_hdmi *hdmi, u32 offset)
-{
-   return readl(hdmi->regs + offset);
-}
-
-static void mtk_hdmi_write(struct mtk_hdmi *hdmi, u32 offset, u32 val)
-{
-   writel(val, hdmi->regs + offset);
-}
-
-static void mtk_hdmi_clear_bits(struct mtk_hdmi *hdmi, u32 offset, u32 bits)
-{
-   void __iomem *reg = hdmi->regs + offset;
-   u32 tmp;
-
-   tmp = readl(reg);
-   tmp &= ~bits;
-   writel(tmp, reg);
-}
-
-static void mtk_hdmi_set_bits(struct mtk_hdmi *hdmi, u32 offset, u32 bits)
-{
-   void __iomem *reg = hdmi->regs + offset;
-   u32 tmp;
-
-   tmp = readl(reg);
-   tmp |= bits;
-   writel(tmp, reg);
-}
-
-static void mtk_hdmi_mask(struct mtk_hdmi *hdmi, u32 offset, u32 val, u32 mask)
-{
-   void __iomem *reg = hdmi->regs + offset;
-   u32 tmp;
-
-   tmp = readl(reg);
-   tmp = (tmp & ~mask) | (val & mask);
-   writel(tmp, reg);
-}
-
 static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi, bool black)
 {
-   mtk_hdmi_mask(hdmi, VIDEO_CFG_4, black ? GEN_RGB : NORMAL_PATH,
- VIDEO_SOURCE_SEL);
+   regmap_update_bits(hdmi->regs, VIDEO_SOURCE_SEL,
+  VIDEO_CFG_4, black ? GEN_RGB : NORMAL_PATH);
 }
 
 static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
@@ -265,12 +225,12 @@ static void mtk_hdmi_hw_1p4_version_enable(struct 
mtk_hdmi *hdmi, bool enable)
 
 static void mtk_hdmi_hw_aud_mute(struct mtk_hdmi *hdmi)
 {
-   mtk_hdmi_set_bits(hdmi, GRL_AUDIO_CFG, AUDIO_ZERO);
+   regmap_set_bits(hdmi->regs, GRL_AUDIO_CFG, AUDIO_ZERO);
 }
 
 static void mtk_hdmi_hw_aud_unmute(struct mtk_hdmi *hdmi)
 {
-   mtk_hdmi_clear_bits(hdmi, GRL_AUDIO_CFG, AUDIO_ZERO);
+   regmap_clear_bits(hdmi->regs, GRL_AUDIO_CFG, AUDIO_ZERO);
 }
 
 static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
@@ -279,25 +239,25 @@ static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
   HDMI_RST, HDMI_RST);
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
   HDMI_RST, 0);
-   mtk_hdmi_clear_bits(hdmi, GRL_CFG3, CFG3_CONTROL_PACKET_DELAY);
+   regmap_clear_bits(hdmi->regs, GRL_CFG3, CFG3_CONTROL_PACKET_DELAY);
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
   ANLG_ON, ANLG_ON);
 }
 
 static void mtk_hdmi_hw_enable_notice(struct mtk_hdmi *hdmi, bool 
enable_notice)
 {
-   mtk_hdmi_mask(hdmi, GRL_CFG2, enable_notice ? CFG2_NOTICE_EN : 0,
- CFG2_NOTICE_EN);
+   regmap_update_bits(hdmi->regs, GRL_CFG2, CFG2_NOTICE_EN,
+  enable_notice ? CFG2_NOTICE_EN : 0);
 }
 
 static void mtk_hdmi_hw_write_int_mask(struct mtk_hdmi *hdmi, u32 int_mask)
 {
-   mtk_hdmi_write(hdmi, GRL_INT_MASK, int_mask);
+   regmap_write(hdmi->regs, GRL_INT_MASK, int_mask);
 }
 
 static void mtk_hdmi_hw_enable_dvi_mode(struct mtk_hdmi *hdmi, bool enable)
 {
-   mtk_hdmi_mask(hdmi, GRL_CFG1, enable ? CFG1_DVI : 0, CFG1_DVI);
+   regmap_update_bits(hdmi->regs, GRL_CFG1, CFG1_DVI, enable ? CFG1_DVI : 
0);
 }
 
 static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi *hdmi, u8 *buffer,
@@ -343,22 +303,22 @@ static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi 
*hdmi, u8 *buffer,
dev_err(hdmi->dev, "Unknown infoframe type %d\n", frame_type);
return;
}
-   mtk_hdmi_clear_bits(hdmi, ctrl_reg, ctrl_frame_en);
-   mtk_hdmi_write(hdmi, GRL_INFOFRM_TYPE, frame_type);
-   mtk_hdmi_write(hdmi, GRL_INFOFRM_VER, frame_ver);
-   mtk_hdmi_write(hdmi, GRL_INFOFRM_LNG, frame_len);
+   regmap_clear_bits(hdmi->regs, ctrl_reg, ctrl_frame_en);
+   regmap_write(hdmi->regs, GRL_INFOFRM_TYPE, frame_type);
+   regmap_write(hdmi->regs, GRL_INFOFRM_VER, frame_ver);
+   regmap_write(hdmi->regs, GRL_INFOFRM_LNG, frame_len);
 
-   mtk_hdmi_write(hdmi, GRL_IFM_PORT, checksum);
+   regmap_write(hdmi->regs,

[PATCH v4 4/8] drm/mediatek: hdmi: make the cec dev optional

Make cec device optional in order to support newer versions of the
hdmi IP which doesn't require it

Signed-off-by: Guillaume Ranquet 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  8 +++--
 drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 52 +++---
 2 files changed, 39 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 41a7593887fb..4c382aeb94c9 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -925,10 +925,11 @@ void mtk_hdmi_clk_disable_audio_mt8183(struct mtk_hdmi 
*hdmi)
 static enum drm_connector_status
 mtk_hdmi_update_plugged_status(struct mtk_hdmi *hdmi)
 {
-   bool connected;
+   bool connected = true;
 
mutex_lock(>update_plugged_status_lock);
-   connected = mtk_cec_hpd_high(hdmi->cec_dev);
+   if (hdmi->cec_dev)
+   connected = mtk_cec_hpd_high(hdmi->cec_dev);
if (hdmi->plugged_cb && hdmi->codec_dev)
hdmi->plugged_cb(hdmi->codec_dev, connected);
mutex_unlock(>update_plugged_status_lock);
@@ -1024,7 +1025,8 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge 
*bridge,
return ret;
}
 
-   mtk_cec_set_hpd_event(hdmi->cec_dev, mtk_hdmi_hpd_event, hdmi->dev);
+   if (hdmi->cec_dev)
+   mtk_cec_set_hpd_event(hdmi->cec_dev, mtk_hdmi_hpd_event, 
hdmi->dev);
 
return 0;
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
index ead0c30f55b7..d7f3d29138d8 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
@@ -110,28 +110,18 @@ void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi, u8 
*buffer_spd, size_t bufsz
mtk_hdmi_setup_spd_infoframe(hdmi, buffer_spd, bufsz_spd, "mediatek", 
"On-chip HDMI");
 }
 
-int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi, struct platform_device 
*pdev,
-   const char *const *clk_names, size_t num_clocks)
+static int mtk_hdmi_get_cec_dev(struct mtk_hdmi *hdmi, struct device *dev, 
struct device_node *np)
 {
-   struct device *dev = >dev;
-   struct device_node *np = dev->of_node;
-   struct device_node *cec_np, *remote, *i2c_np;
+   int ret;
+   struct device_node *cec_np;
struct platform_device *cec_pdev;
struct regmap *regmap;
-   struct resource *mem;
-   int ret;
-
-   ret = mtk_hdmi_get_all_clk(hdmi, np, clk_names, num_clocks);
-   if (ret) {
-   dev_err(dev, "Failed to get all clks\n");
-   return ret;
-   }
 
/* The CEC module handles HDMI hotplug detection */
cec_np = of_get_compatible_child(np->parent, "mediatek,mt8173-cec");
if (!cec_np) {
dev_err(dev, "Failed to find CEC node\n");
-   return -EINVAL;
+   return -ENOTSUPP;
}
 
cec_pdev = of_find_device_by_node(cec_np);
@@ -141,7 +131,6 @@ int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi, struct 
platform_device *pdev,
return -EPROBE_DEFER;
}
of_node_put(cec_np);
-   hdmi->cec_dev = _pdev->dev;
/*
 * The mediatek,syscon-hdmi property contains a phandle link to the
 * MMSYS_CONFIG device and the register offset of the HDMI_SYS_CFG
@@ -150,12 +139,39 @@ int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi, struct 
platform_device *pdev,
regmap = syscon_regmap_lookup_by_phandle(np, "mediatek,syscon-hdmi");
ret = of_property_read_u32_index(np, "mediatek,syscon-hdmi", 1, 
>sys_offset);
if (IS_ERR(regmap))
-   ret = PTR_ERR(regmap);
+   return PTR_ERR(regmap);
if (ret) {
-   dev_err(dev, "Failed to get system configuration registers: 
%d\n", ret);
-   goto put_device;
+   dev_err(dev,
+   "Failed to get system configuration registers: 
%d\n", ret);
+   return ret;
}
+
hdmi->sys_regmap = regmap;
+   hdmi->cec_dev = _pdev->dev;
+
+   return 0;
+}
+
+int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi, struct platform_device 
*pdev,
+   const char *const *clk_names, size_t num_clocks)
+{
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *remote, *i2c_np;
+   struct resource *mem;
+   int ret;
+
+   ret = mtk_hdmi_get_all_clk(hdmi, np, clk_names, num_clocks);
+   if (ret) {
+   dev_err(dev, "Failed to get all clks\n");
+   return ret;
+   }
+
+   ret = mtk_hdmi_get_cec_dev(hdmi, dev, np);
+   if (ret == -ENOTSUPP)
+   dev_info(dev, "No CEC node found, continuing without");
+   else if(ret)
+   goto put_device;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {

--

[PATCH v4 0/8] Add MT8195 HDMI support

Add support for HDMI Tx on MT8195.

This includes a split of the current "legacy" hdmi driver into a common
library of functions and two dedicated compilation units with specific
code for mt8167 and another for the "v2" mt8195 SoC.

Support for the new mt8195 dpi/drm_drv adjustments to support hdmi.

Based on next-20230523

Still in my TODO-list for v5:

- Removal of the 'is_internal_hdmi' flag in mtk_dpi. [1]
I Couldn't find a way to get rid of it with the way things are done
in mtk_drm_drv/mtk_ddp_comp.
- Do not use a "virtual" device for the ddc v2 hw as it is embedded in
  the hdmi IP. [2]
Seems that a lot of work is done by the framework when using a
proper device-tree entry that can be linked as the ddc-i2c-bus of
the hdmi-connector.
I will keep the virtual device unless I find a way to avoid
rewriting the framework code that handles this.

[1] : 
https://lore.kernel.org/all/988b0a7a-69bb-34e4-e777-1d9516221...@collabora.com/
[2] : 
https://lore.kernel.org/all/7da1e73a0cca6867a060d5b69d45e8d4dfc89748.ca...@mediatek.com/

Signed-off-by: Guillaume Ranquet 
---

Changes in v4:
- Split phy related patches to another series (merged)
- Removed regmap wrappers in mtk_hdmi
- Removed colorimetry related changes as this initial version only
  support one color depth
- Fixed dt-bindings properties
- Removed some now useless clocks from mtk_hdmi_v2 and mtk_dpi
- Link to v3: https://lore.kernel.org/r/20220919-v3-0-a803f2660...@baylibre.com

Changes in v3:
- phy: Grouped register and bit definition together to add clarity
- dt-bindings: Addressed comments
- Link to v2: https://lore.kernel.org/r/20220919-v2-0-8419dcf4f...@baylibre.com

Changes in v2:
- Removed syscon requirement from the hdmi node
- Use as much as possible bit FIELD_PREP/FIELD_GET macros across all the
  patches
- Make cec optional dynamically instead of hardcoded with a flag
- Renamed hdmi variants to v1 (legacy) and v2 (mt8195) while waiting for
  a better name
- Rework hdmi v2 code to use a connector (same as v1)
- Remove "magic" 0x43 addr special handling in hdmi ddc code
- Link to v1: https://lore.kernel.org/r/20220919-v1-0-4844816c9...@baylibre.com

---
Guillaume Ranquet (8):
  dt-bindings: display: mediatek: add MT8195 hdmi bindings
  drm/mediatek: hdmi: use a regmap instead of iomem
  drm/mediatek: extract common functions from the mtk hdmi driver
  drm/mediatek: hdmi: make the cec dev optional
  drm/mediatek: hdmi: add v2 support
  drm/mediatek: hdmi: v2: add audio support
  dt-bindings: display: mediatek: dpi: Add compatible for MediaTek MT8195
  drm/mediatek: dpi: Add mt8195 hdmi to DPI driver

 .../bindings/display/mediatek/mediatek,dpi.yaml|1 +
 .../bindings/display/mediatek/mediatek,hdmi.yaml   |   59 +-
 .../display/mediatek/mediatek,mt8195-hdmi-ddc.yaml |   45 +
 drivers/gpu/drm/mediatek/Kconfig   |2 +
 drivers/gpu/drm/mediatek/Makefile  |5 +-
 drivers/gpu/drm/mediatek/mtk_dpi.c |  121 +-
 drivers/gpu/drm/mediatek/mtk_dpi_regs.h|5 +
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  773 ++--
 drivers/gpu/drm/mediatek/mtk_hdmi.h|   18 +
 drivers/gpu/drm/mediatek/mtk_hdmi_common.c |  437 +++
 drivers/gpu/drm/mediatek/mtk_hdmi_common.h |  208 
 drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c |  362 ++
 drivers/gpu/drm/mediatek/mtk_hdmi_regs_v2.h|  276 +
 drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 1303 
 drivers/gpu/drm/mediatek/mtk_hdmi_v2.h |   32 +
 15 files changed, 2955 insertions(+), 692 deletions(-)
---
base-commit: c8a64c6a78c54887da437098d97dc2accc689e89
change-id: 20220919-hdmi_mtk

Best regards,
-- 
Guillaume Ranquet

RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support

2023-05-29 Thread Biju Das

HI Laurent,

Thanks for the feedback.

> Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> Unit support
> 
> Hi Biju,
> 
> On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> > Hi DRM maintainers,
> >
> > Gentle ping.
> 
> Sorry, I was on holidays the last two weeks.
> 
> > Are we happy with moving all Renesas drm drivers to Renesas specific
> > directory or preference is for separate one??
> 
> This works for me.
> 
> > If it is later, I can send RZ/G2L drm driver separate.
> >
> > Otherwise, I need to rebase and resend.
> 
> Your series applies cleanly on top of the latest drm-next branch. Is
> there a specific need to rebase and resend ?

Nope. After my patch series there were
some patches from Geert for drm/shmobile merged to drm-misc-next by Thomas.

Maybe git managed this automatically??


> 
> I haven't had time to review patch 4/5 (the driver) yet. All the rest
> looks good to me. Should I already include 1/5 in my next pull request ?

Yes, please.

Cheers,
Biju

> 
> > Please let me know your preference.
> >
> > Cheers,
> > Biju
> >
> >
> > > -Original Message-
> > > From: Biju Das
> > > Sent: Monday, May 15, 2023 8:58 AM
> > > To: David Airlie ; Daniel Vetter
> > > ; Philipp Zabel ; Geert
> > > Uytterhoeven ; Laurent Pinchart
> > > ; Kieran Bingham
> > > 
> > > Cc: dri-devel@lists.freedesktop.org;
> > > linux-renesas-...@vger.kernel.org;
> > > Fabrizio Castro ; Prabhakar Mahadev
> > > Lad 
> > > Subject: RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > Display Unit support
> > >
> > > Hi All,
> > >
> > > Gentle ping. Are we happy with this patch series?
> > >
> > > Cheers,
> > > Biju
> > >
> > > > Subject: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L
> > > > Display Unit support
> > > >
> > > > RZ/G2L LCD controller composed of Frame compression
> > > > Processor(FCPVD), Video signal processor (VSPD) and Display
> > > > unit(DU). The output of LCDC is connected to Display parallel
> > > > interface and MIPI link video interface.
> > > >
> > > > The output from DSI is connected to ADV7535.
> > > >
> > > > Created a vendor specific directory renesas and moved all renesas
> > > > drm drivers to it (rcar-du and shmobile). Then added support for
> > > > RZ/G2L DU DRM driver by creating rz_du directory.
> > > >
> > > > Ref:
> > > >
> > > >
> > > > v8->v9:
> > > >  * Added Rb tag from Laurent and Acked-by tag from Kieran for
> patch#1.
> > > >  * Added Rb tag from Laurent and Geert for patch#3.
> > > >  * Dropped reset_control_assert() from error patch for
> > > > rzg2l_du_crtc_get() as
> > > >suggested by Philipp Zabel.
> > > >  * Added Rb tag from Laurent oatch#5.
> > > >  * Updated MAINTAINERS entries for common parts(Makefile and
> Kconfig).
> > > > v7->v8:
> > > >  * Moved rcar-du and shmobile DRM drivers to renesas specific
> > > > vendor directory.
> > > >  * Fixed the typo vsp2->du in RZ/V2L DU bindings patch.
> > > >  * Added Rb tag from Rob for RZ/V2L DU bindings patch.
> > > >  * Dropped RCar du lib and created RZ/G2L DU DRM driver by
> > > > creating rz_du folder.
> > > >  * Updated MAINTAINERS entries.
> > > > v6->v7:
> > > >  * Split DU lib and  RZ/G2L du driver as separate patch series as
> > > >DU support added to more platforms based on RZ/G2L alike SoCs.
> > > >  * Rebased to latest drm-tip.
> > > >  * Added patch #2 for binding support for RZ/V2L DU
> > > >  * Added patch #4 for driver support for RZ/V2L DU
> > > >  * Added patch #5 for SoC DTSI support for RZ/G2L DU
> > > >  * Added patch #6 for SoC DTSI support for RZ/V2L DU
> > > >  * Added patch #7 for Enabling DU on SMARC EVK based on
> > > > RZ/{G2L,V2L} SoCs.
> > > >  * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC
> SoC.
> > > > v5->v6:
> > > >  * Merged DU lib and RZ/G2L du driver in same patch series
> > > >  * Rebased to latest drm-misc.
> > > >  * Merged patch#1 to RZ/G2L Driver patch.
> > > >  * Updated KConfig dependency from ARCH_RENESAS->ARCH_RZG2L.
> > > >  * Optimized rzg2l_du_output_name() by removing unsupported
> outputs.
> > > >
> > > > v4->v5:
> > > >  * Added Rb tag from Rob for binding patch.
> > > >  * Started using RCar DU libs(kms, vsp and encoder)
> > > >  * Started using rcar_du_device, rcar_du_write, rcar_du_crtc,
> > > >rcar_du_format_info and rcar_du_encoder.
> > > > v3->v4:
> > > >  * Changed compatible name from
> > > > renesas,du-r9a07g044->renesas,r9a07g044-
> > > > du
> > > >  * started using same compatible for RZ/G2{L,LC}
> > > >  * Removed rzg2l_du_group.h and struct rzg2l_du_group
> > > >  * Renamed __rzg2l_du_group_start_stop->rzg2l_du_start_stop
> > > >  * Removed rzg2l_du_group_restart
> > > >  * Updated rzg2l_du_crtc_set_display_timing
> > > >  * Removed mode_valid callback.
> > > >  * Updated rzg2l_du_crtc_create() parameters
> > > >  * Updated compatible
> > > >  * Removed RZG2L_DU_MAX_GROUPS
> > > > V2->v3:
> > > >  * Added new bindings for RZ/G2L DU
> > > >  * Removed indirection and created new DRM

Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support

2023-05-29 Thread Laurent Pinchart

Hi Biju,

On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> Hi DRM maintainers,
> 
> Gentle ping.

Sorry, I was on holidays the last two weeks.

> Are we happy with moving all Renesas drm drivers to Renesas specific
> directory or preference is for separate one??

This works for me.

> If it is later, I can send RZ/G2L drm driver separate.
> 
> Otherwise, I need to rebase and resend.

Your series applies cleanly on top of the latest drm-next branch. Is
there a specific need to rebase and resend ?

I haven't had time to review patch 4/5 (the driver) yet. All the rest
looks good to me. Should I already include 1/5 in my next pull request ?

> Please let me know your preference.
> 
> Cheers,
> Biju
> 
> 
> > -Original Message-
> > From: Biju Das
> > Sent: Monday, May 15, 2023 8:58 AM
> > To: David Airlie ; Daniel Vetter ;
> > Philipp Zabel ; Geert Uytterhoeven
> > ; Laurent Pinchart
> > ; Kieran Bingham
> > 
> > Cc: dri-devel@lists.freedesktop.org; linux-renesas-...@vger.kernel.org;
> > Fabrizio Castro ; Prabhakar Mahadev Lad
> > 
> > Subject: RE: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> > Unit support
> > 
> > Hi All,
> > 
> > Gentle ping. Are we happy with this patch series?
> > 
> > Cheers,
> > Biju
> > 
> > > Subject: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> > > Unit support
> > >
> > > RZ/G2L LCD controller composed of Frame compression Processor(FCPVD),
> > > Video signal processor (VSPD) and Display unit(DU). The output of LCDC
> > > is connected to Display parallel interface and MIPI link video
> > > interface.
> > >
> > > The output from DSI is connected to ADV7535.
> > >
> > > Created a vendor specific directory renesas and moved all renesas drm
> > > drivers to it (rcar-du and shmobile). Then added support for RZ/G2L DU
> > > DRM driver by creating rz_du directory.
> > >
> > > Ref:
> > >
> > >
> > > v8->v9:
> > >  * Added Rb tag from Laurent and Acked-by tag from Kieran for patch#1.
> > >  * Added Rb tag from Laurent and Geert for patch#3.
> > >  * Dropped reset_control_assert() from error patch for
> > > rzg2l_du_crtc_get() as
> > >suggested by Philipp Zabel.
> > >  * Added Rb tag from Laurent oatch#5.
> > >  * Updated MAINTAINERS entries for common parts(Makefile and Kconfig).
> > > v7->v8:
> > >  * Moved rcar-du and shmobile DRM drivers to renesas specific vendor
> > > directory.
> > >  * Fixed the typo vsp2->du in RZ/V2L DU bindings patch.
> > >  * Added Rb tag from Rob for RZ/V2L DU bindings patch.
> > >  * Dropped RCar du lib and created RZ/G2L DU DRM driver by creating
> > > rz_du folder.
> > >  * Updated MAINTAINERS entries.
> > > v6->v7:
> > >  * Split DU lib and  RZ/G2L du driver as separate patch series as
> > >DU support added to more platforms based on RZ/G2L alike SoCs.
> > >  * Rebased to latest drm-tip.
> > >  * Added patch #2 for binding support for RZ/V2L DU
> > >  * Added patch #4 for driver support for RZ/V2L DU
> > >  * Added patch #5 for SoC DTSI support for RZ/G2L DU
> > >  * Added patch #6 for SoC DTSI support for RZ/V2L DU
> > >  * Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L}
> > > SoCs.
> > >  * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
> > > v5->v6:
> > >  * Merged DU lib and RZ/G2L du driver in same patch series
> > >  * Rebased to latest drm-misc.
> > >  * Merged patch#1 to RZ/G2L Driver patch.
> > >  * Updated KConfig dependency from ARCH_RENESAS->ARCH_RZG2L.
> > >  * Optimized rzg2l_du_output_name() by removing unsupported outputs.
> > >
> > > v4->v5:
> > >  * Added Rb tag from Rob for binding patch.
> > >  * Started using RCar DU libs(kms, vsp and encoder)
> > >  * Started using rcar_du_device, rcar_du_write, rcar_du_crtc,
> > >rcar_du_format_info and rcar_du_encoder.
> > > v3->v4:
> > >  * Changed compatible name from
> > > renesas,du-r9a07g044->renesas,r9a07g044-
> > > du
> > >  * started using same compatible for RZ/G2{L,LC}
> > >  * Removed rzg2l_du_group.h and struct rzg2l_du_group
> > >  * Renamed __rzg2l_du_group_start_stop->rzg2l_du_start_stop
> > >  * Removed rzg2l_du_group_restart
> > >  * Updated rzg2l_du_crtc_set_display_timing
> > >  * Removed mode_valid callback.
> > >  * Updated rzg2l_du_crtc_create() parameters
> > >  * Updated compatible
> > >  * Removed RZG2L_DU_MAX_GROUPS
> > > V2->v3:
> > >  * Added new bindings for RZ/G2L DU
> > >  * Removed indirection and created new DRM driver based on R-Car DU
> > > v1->v2:
> > >  * Based on [1], all references to 'rzg2l_lcdc' replaced with
> > 'rzg2l_du'
> > >  * Updated commit description for bindings
> > >  * Removed LCDC references from bindings
> > >  * Changed clock name from du.0->aclk from bindings
> > >  * Changed reset name from du.0->du from bindings
> > >  * Replaced crtc_helper_funcs->rcar_crtc_helper_funcs
> > >  * Updated macro DRM_RZG2L_LCDC->DRM_RZG2L_DU
> > >  * Replaced rzg2l-lcdc-drm->rzg2l-du-drm
> > >  * Added forward declaration for struct reset_control
> > >
> > > [1]
> >

Re: [PATCH 2/2] dt-bindings: backlight: document new property default-brightness-level

2023-05-29 Thread Alexandru Ardelean

On Fri, May 26, 2023 at 3:05 PM Philippe CORNU
 wrote:
>
>
>
> On 5/19/23 22:05, Alexandru Ardelean wrote:
> > From: Yannick Fertre 
> >
> > Add documentation for new default-brightness-level property.
> >
> > Reviewed-by: Philippe CORNU 
>
> Hi Alexandru,
> same comments as for the 1/2 patch.

Ack

Will do
Thanks
Alexandru

> Many thanks
> Philippe :-)
>
> > Signed-off-by: Yannick Fertre 
> > Signed-off-by: Alexandru Ardelean 
> > ---
> >
> > Link to original patch:
> >
> > https://github.com/STMicroelectronics/linux/commit/c4067d7bd883c6fa14ffd49892c4ce663cdafe98
> >
> >   .../bindings/leds/backlight/gpio-backlight.yaml  | 9 +
> >   1 file changed, 9 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml 
> > b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > index 584030b6b0b9..b96c08cff0f0 100644
> > --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > @@ -23,6 +23,15 @@ properties:
> >   description: enable the backlight at boot.
> >   type: boolean
> >
> > +  default-brightness-level:
> > +description:
> > +  The default brightness level (index into the array defined by the
> > +  "brightness-levels" property).
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +dependencies:
> > +  default-brightness-level: [ "brightness-levels" ]
> > +
> >   required:
> > - compatible
> > - gpios

Re: [PATCH 2/2] dt-bindings: backlight: document new property default-brightness-level

2023-05-29 Thread Alexandru Ardelean

On Fri, May 26, 2023 at 1:20 PM Daniel Thompson
 wrote:
>
> On Fri, May 19, 2023 at 11:05:20PM +0300, Alexandru Ardelean wrote:
> > From: Yannick Fertre 
> >
> > Add documentation for new default-brightness-level property.
> >
> > Reviewed-by: Philippe CORNU 
> > Signed-off-by: Yannick Fertre 
> > Signed-off-by: Alexandru Ardelean 
> > ---
> >
> > Link to original patch:
> >   
> > https://github.com/STMicroelectronics/linux/commit/c4067d7bd883c6fa14ffd49892c4ce663cdafe98
> >
> >  .../bindings/leds/backlight/gpio-backlight.yaml  | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml 
> > b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > index 584030b6b0b9..b96c08cff0f0 100644
> > --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
> > @@ -23,6 +23,15 @@ properties:
> >  description: enable the backlight at boot.
> >  type: boolean
> >
> > +  default-brightness-level:
> > +description:
> > +  The default brightness level (index into the array defined by the
> > +  "brightness-levels" property).
>
> gpio-backlight does not have a brightness-levels array property!
>
> I think it is also necessary to improve the docs of both properties to
> distinguish between the meaning of default-on and
> default-brightness-level. The result of setting default-on and
> default-brightness level to zero is that the GPIO will be off (this is
> correct behaviour but hard to figure out from the current text).
>
> default-on is a control that can "enable" the backlight at boot when it
> is not linked to a display in the DT (e.g. it is mostly for legacy
> cases). When the backlight is linked to a display then the backlight
> enable state will be automatically linked to the display enable state
> instead.
>
> default-brightness-level is useful for handling displays that
> are still readable with the backlight off (e-ink, reflective/
> transflexive LCD, etc), otherwise is should be absent or set to 1.

ack
will do in V2

thanks

>
>
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +dependencies:
> > +  default-brightness-level: [ "brightness-levels" ]
>
> As above, depending on brightness-levels doesn't make any sense here.
>
>
> Daniel.

Re: [PATCH 1/2] backlight: gpio_backlight: add new property default-brightness-level

2023-05-29 Thread Alexandru Ardelean

On Fri, May 26, 2023 at 3:04 PM Philippe CORNU
 wrote:
>
>
> On 5/19/23 22:05, Alexandru Ardelean wrote:
> > From: Yannick Fertre 
> >
> > Add new property to set a brightness by default at probe.
> >
> > Reviewed-by: Philippe CORNU 
>
> Hi Alexandru,
>
> Many thanks for your patch.
>
> You have sent a patch originally pushed on the STMicroelectronics github
> as mentioned in your commit message (no problem with that :-). But, the
> "Reviewed-by" inside this github patch is linked to our gerrit STM
> internal server so you can not use it directly for mainlining this patch.
>
> So please, re-send your this patch without my "Reviewed-by".

ack
will do

>
> Many thanks
> Philippe :-)
>
>
> > Signed-off-by: Yannick Fertre 
> > Signed-off-by: Alexandru Ardelean 
> > ---
> >
> > Link to original patch:
> >
> > https://github.com/STMicroelectronics/linux/commit/c4067d7bd883c6fa14ffd49892c4ce663cdafe98
> >
> >   drivers/video/backlight/gpio_backlight.c | 7 ++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/backlight/gpio_backlight.c 
> > b/drivers/video/backlight/gpio_backlight.c
> > index 6f78d928f054..d3fa3a8bef4d 100644
> > --- a/drivers/video/backlight/gpio_backlight.c
> > +++ b/drivers/video/backlight/gpio_backlight.c
> > @@ -53,6 +53,7 @@ static int gpio_backlight_probe(struct platform_device 
> > *pdev)
> >   struct backlight_device *bl;
> >   struct gpio_backlight *gbl;
> >   int ret, init_brightness, def_value;
> > + u32 value;
> >
> >   gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
> >   if (gbl == NULL)
> > @@ -93,7 +94,11 @@ static int gpio_backlight_probe(struct platform_device 
> > *pdev)
> >   else
> >   bl->props.power = FB_BLANK_UNBLANK;
> >
> > - bl->props.brightness = 1;
> > + ret = device_property_read_u32(dev, "default-brightness-level", 
> > );
> > + if (!ret && value <= props.max_brightness)
> > + bl->props.brightness = value;
> > + else
> > + bl->props.brightness = 1;
> >
> >   init_brightness = backlight_get_brightness(bl);
> >   ret = gpiod_direction_output(gbl->gpiod, init_brightness);

Kernel bug related to drivers/gpu/drm/ttm/ttm_bo.c

2023-05-29 Thread Christopher Klooz

Hi!

I think we have a serious kernel bug that is related to or inside in
drivers/gpu/drm/ttm/ttm_bo.c

The reason for my assumptions lies in one of my recent system freezes
with kernel 6.3.4 that go along with massive kernel error logs in
journalctl. An extract from the logs:

...
May 28 14:38:41 fedora.domain kernel: WARNING: CPU: 4 PID: 5523 at
drivers/gpu/drm/ttm/ttm_bo.c:326 ttm_bo_release+0x289/0x2e0 [ttm]
...
May 28 14:38:41 fedora.domain kernel: WARNING: CPU: 4 PID: 5523 at
drivers/gpu/drm/ttm/ttm_bo.c:327 ttm_bo_release+0x296/0x2e0 [ttm]
...
May 28 14:38:41 fedora.domain kernel: kernel BUG at
drivers/gpu/drm/ttm/ttm_bo.c:193!
...

The above information is more detailed than most of the occurrences, and
its the first occurrence that did not end up in a freeze immediately or
a few seconds after it. However, the corrupted state of the system
became again apparent when I tried to shutdown some time after the above
errors:

...

|May 28 14:51:09 fedora.domain kernel: #PF: error_code(0x) -
not-present page May 28 14:51:09 fedora.domain kernel: #PF: supervisor
read access in kernel mode May 28 14:51:09 fedora.domain kernel: BUG:
unable to handle page fault for address: 003000300010|

...

I have that issue already for a longer time, at least since 6.2.X.

You can find my bug report and many full logs (including the full logs
of the above) from root's journalctl in:
https://bugzilla.redhat.com/show_bug.cgi?id=2193110

Ignore the title and the initial comments of the bug report, it is
definitely not related to Firefox. Assuming that you want to focus on
the kernel error logs of 6.3.X, you might focus only on the last 5 comments.

Additionally to the journalctl error logs that I already added through
links in the bug report, I tested today once again 6.3.4 with
amd_pstate=active (by default I am on amd_state=passive which feels most
stable on my hardware) -> see
https://gitlab.com/py0xc31/public-tmp-storage/-/blob/main/retry6.3.4/fullSystemFreeze.kernel6.3.4.pstate-ACTIVE.log
(I have not yet put this into the bug report since I no longer assume it
is relevant)

Some other people from Fedora have experienced related issues; see the
comments on the test result pages in our update system:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-514965dd8a (6.3.3 &
6.3.4)

https://bodhi.fedoraproject.org/updates/FEDORA-2023-26325e5399 (6.2.15)
-> I am quite sure I have seen that issue already before 6.2.15.

Maybe also related (but without explicit information referring to ttm_bo.c):

https://gitlab.freedesktop.org/drm/amd/-/issues/2548

https://gitlab.freedesktop.org/drm/amd/-/issues/2447

Let me know if you need more information or if I can help with testing.

My hardware: AMD Ryzen 6850 Pro, I have no dedicated graphics but only
the AMD graphics of my Ryzen. I use Fedora 38 KDE -> cat
/proc/sys/kernel/tainted = 0.

I will try updating my BIOS in the next days when I have time to see if
that makes a difference, but I guess this is not related given the logs.

Regards,

Chris

Re: [PATCH 03/27] dt-bindings: display: mediatek: dpi: Add compatible for MediaTek MT6795


Hi Chun-Kuang Hu,

Can you help to merge the missing DT-binding patches in this series?

Thanks a lot,
Matthias

On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

Add a compatible string for the MediaTek Helio X10 MT6795 SoC, using
the same parameters as MT8183.

Signed-off-by: AngeloGioacchino Del Regno 

---
  .../display/mediatek/mediatek,dpi.yaml| 23 +++
  1 file changed, 14 insertions(+), 9 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index d976380801e3..803c00f26206 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -17,15 +17,20 @@ description: |
  
  properties:

compatible:
-enum:
-  - mediatek,mt2701-dpi
-  - mediatek,mt7623-dpi
-  - mediatek,mt8173-dpi
-  - mediatek,mt8183-dpi
-  - mediatek,mt8186-dpi
-  - mediatek,mt8188-dp-intf
-  - mediatek,mt8192-dpi
-  - mediatek,mt8195-dp-intf
+oneOf:
+  - enum:
+  - mediatek,mt2701-dpi
+  - mediatek,mt7623-dpi
+  - mediatek,mt8173-dpi
+  - mediatek,mt8183-dpi
+  - mediatek,mt8186-dpi
+  - mediatek,mt8188-dp-intf
+  - mediatek,mt8192-dpi
+  - mediatek,mt8195-dp-intf
+  - items:
+  - enum:
+  - mediatek,mt6795-dpi
+  - const: mediatek,mt8183-dpi
  
reg:

  maxItems: 1

Re: [PATCH 02/27] dt-bindings: phy: mediatek, dsi-phy: Add compatible for MT6795 Helio X10





On 14/04/2023 10:22, Krzysztof Kozlowski wrote:

On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

Add a compatible string for MediaTek Helio X10 MT6795: this SoC uses
the same DSI PHY as MT8173.

Signed-off-by: AngeloGioacchino Del Regno 

---
  Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 4 
  1 file changed, 4 insertions(+)


Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof



Applied, thanks!

RE: [PATCH v9 RESEND 2/5] dt-bindings: display: Document Renesas RZ/G2L DU bindings

2023-05-29 Thread Biju Das

Hi Laurent,

> Subject: Re: [PATCH v9 RESEND 2/5] dt-bindings: display: Document
> Renesas RZ/G2L DU bindings
> 
> Hi Biju,
> 
> Thank you for the patch.
> 
> On Tue, May 02, 2023 at 11:09:09AM +0100, Biju Das wrote:
> > The RZ/G2L LCD controller is composed of Frame Compression Processor
> > (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
> >
> > The DU module supports the following hardware features − Display
> > Parallel Interface (DPI) and MIPI LINK Video Interface − Display
> > timing master − Generates video timings − Selecting the polarity of
> > output DCLK, HSYNC, VSYNC, and DE − Supports Progressive − Input data
> > format (from VSPD): RGB888, RGB666 − Output data format: same as Input
> > data format − Supporting Full HD (1920 pixels x 1080 lines) for
> > MIPI-DSI Output − Supporting WXGA (1280 pixels x 800 lines) for
> > Parallel Output
> >
> > This patch document DU module found on RZ/G2L LCDC.
> 
> s/document/documents the/
> 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Rob Herring 
> > ---
> > v8->v9:
> >  * No change
> > v7->v8:
> >  * No change
> > v6->v7:
> >  * No change
> > v5->v6:
> >  * No change.
> > v4->v5:
> >  * Added Rb tag from Rob.
> > v3->v4:
> >  * Changed compatible name from
> > renesas,du-r9a07g044->renesas,r9a07g044-du
> >  * started using same compatible for RZ/G2{L,LC}
> > v3: New patch
> > ---
> >  .../bindings/display/renesas,rzg2l-du.yaml| 124
> ++
> >  1 file changed, 124 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > new file mode 100644
> > index ..ab99e7d57a7d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > @@ -0,0 +1,124 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fschemas%2Fdisplay%2Frenesas%2Crzg2l-du.yaml%23=05%7
> > +C01%7Cbiju.das.jz%40bp.renesas.com%7C60339e2c157d4b286c9908db604ba0b4
> > +%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638209650173950198%7CUn
> > +known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > +WwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=EpbJapOlYJybgJmDU%2FmMJZQ75vS
> > +F8v6GN5phXXl0%2FI0%3D=0
> > +$schema:
> > +https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23=05%7C01%7Cbiju.das.jz%4
> > +0bp.renesas.com%7C60339e2c157d4b286c9908db604ba0b4%7C53d82571da1947e4
> > +9cb4625a166a4a2a%7C0%7C0%7C638209650173950198%7CUnknown%7CTWFpbGZsb3d
> > +8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> > +C3000%7C%7C%7C=XRwCyvXbR274tkOBz6d3QGfmtILKEjgV5kfCk4LjrAM%3D
> > +eserved=0
> > +
> > +title: Renesas RZ/G2L Display Unit (DU)
> > +
> > +maintainers:
> > +  - Biju Das 
> > +  - Laurent Pinchart 
> > +
> > +description: |
> > +  These DT bindings describe the Display Unit embedded in the Renesas
> > +RZ/G2L
> > +  and RZ/V2L SoCs.
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +  - renesas,r9a07g044-du # RZ/G2{L,LC}
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  interrupts:
> > +maxItems: 1
> > +
> > +  clocks:
> > +items:
> > +  - description: Main clock
> > +  - description: Register access clock
> > +  - description: Video clock
> > +
> > +  clock-names:
> > +items:
> > +  - const: aclk
> > +  - const: pclk
> > +  - const: vclk
> > +
> > +  resets:
> > +maxItems: 1
> > +
> > +  power-domains:
> > +maxItems: 1
> > +
> > +  ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +description: |
> > +  The connections to the DU output video ports are modeled using
> the OF
> > +  graph bindings specified in
> Documentation/devicetree/bindings/graph.txt.
> 
> The file has moved to graph.yaml in the dt-schema repo. I'll drop the
> last part of the sentence, starting with "specified by".
> 
> > +  The number of ports and their assignment are model-dependent.
> Each port
> > +  shall have a single endpoint.
> > +
> > +patternProperties:
> > +  "^port@[0-1]$":
> > +$ref: /schemas/graph.yaml#/properties/port
> > +unevaluatedProperties: false
> > +
> > +required:
> > +  - port@0
> > +
> > +unevaluatedProperties: false
> > +
> > +  renesas,vsps:
> > +$ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +items:
> > +  items:
> > +- description: phandle to VSP instance that serves the DU
> channel
> > +- description: Channel index identifying the LIF instance in
> that VSP
> > +description:
> > +  A list of phandle and channel index tuples to the VSPs that
> handle the
> > +  memory interfaces for the DU channels.
> > +
> >

Re: [PATCH 25/27] arm64: dts: mediatek: mt6795-xperia-m5: Add eMMC, MicroSD slot, SDIO





On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

Configure and enable the MMC0/1/2 controllers, used for the eMMC chip,
MicroSD card slot and SDIO (WiFi) respectively.

Signed-off-by: AngeloGioacchino Del Regno 



Applied, thanks


---
  .../dts/mediatek/mt6795-sony-xperia-m5.dts| 91 +++
  1 file changed, 91 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts 
b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
index debe0f2553d9..155a573eac4c 100644
--- a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
+++ b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
@@ -17,6 +17,7 @@ / {
aliases {
mmc0 = 
mmc1 = 
+   mmc2 = 
serial0 = 
serial1 = 
};
@@ -121,7 +122,97 @@ proximity@48 {
};
  };
  
+ {

+   /* eMMC controller */
+   mediatek,latch-ck = <0x14>; /* hs400 */
+   mediatek,hs200-cmd-int-delay = <1>;
+   mediatek,hs400-cmd-int-delay = <1>;
+   mediatek,hs400-ds-dly3 = <0x1a>;
+   non-removable;
+   pinctrl-names = "default", "state_uhs";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_uhs>;
+   vmmc-supply = <_vemc33_reg>;
+   vqmmc-supply = <_vio18_reg>;
+   status = "okay";
+};
+
+ {
+   /* MicroSD card slot */
+   vmmc-supply = <_vmc_reg>;
+   vqmmc-supply = <_vmch_reg>;
+   status = "okay";
+};
+
+ {
+   /* SDIO WiFi on MMC2 */
+   vmmc-supply = <_vmc_reg>;
+   vqmmc-supply = <_vmch_reg>;
+   status = "okay";
+};
+
   {
+   mmc0_pins_default: emmc-sdr-pins {
+   pins-cmd-dat {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   input-enable;
+   bias-pull-up = ;
+   };
+
+   pins-clk {
+   pinmux = ;
+   bias-pull-down = ;
+   };
+
+   pins-rst {
+   pinmux = ;
+   bias-pull-up = ;
+   };
+   };
+
+   mmc0_pins_uhs: emmc-uhs-pins {
+   pins-cmd-dat {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   input-enable;
+   drive-strength = ;
+   bias-pull-up = ;
+   };
+
+   pins-clk {
+   pinmux = ;
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+
+   pins-rst {
+   pinmux = ;
+   drive-strength = ;
+   bias-pull-up = ;
+   };
+
+   pins-ds {
+   pinmux = ;
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+   };
+
nfc_pins: nfc-pins {
pins-irq {
pinmux = ;

Re: [PATCH 24/27] arm64: dts: mediatek: mt6795-xperia-m5: Add MT6331 Combo PMIC





On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

This smartphone uses the Helio X10 standard MT6331+MT6332 combo PMICs:
include the mt6331 devicetree and add the required interrupt.

Note that despite there being two interrupts, one for MT6331 and one
for MT6332, in configurations using the companion PMIC, the interrupt
of the latter fires for both events on MT6331 and for ones on MT6332,
while the interrupt for the main PMIC fires only for events of the
main PMIC.

Signed-off-by: AngeloGioacchino Del Regno 



Applied, thanks


---
  arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts 
b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
index a0e01a756f03..debe0f2553d9 100644
--- a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
+++ b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
@@ -7,6 +7,7 @@
  /dts-v1/;
  #include 
  #include "mt6795.dtsi"
+#include "mt6331.dtsi"
  
  / {

model = "Sony Xperia M5";
@@ -219,6 +220,15 @@ pins-tx {
};
  };
  
+ {

+   /*
+* Smartphones, including the Xperia M5, are equipped with a companion
+* MT6332 PMIC: when this is present, the main MT6331 PMIC will fire
+* an interrupt on the companion, so we use the MT6332 IRQ GPIO.
+*/
+   interrupts = ;
+};
+
   {
status = "okay";

Re: [PATCH 23/27] arm64: dts: mediatek: Add MT6331 PMIC devicetree





On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

MT6331 is the primary PMIC for the MediaTek Helio X10 MT6795 smartphone
platforms: add a devicetree describing its regulators, Real Time Clock
and PMIC-keys.

Signed-off-by: AngeloGioacchino Del Regno 



Applied, thanks



---
  arch/arm64/boot/dts/mediatek/mt6331.dtsi | 284 +++
  1 file changed, 289 insertions(+)
  create mode 100644 arch/arm64/boot/dts/mediatek/mt6331.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/mt6331.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6331.dtsi
new file mode 100644
index ..fcec8c07fe39
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6331.dtsi
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ * Author: AngeloGioacchino Del Regno 
+ */
+#include 
+
+ {
+   pmic: mt6331 {
+   compatible = "mediatek,mt6331";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   mt6331regulator: mt6331regulator {
+   compatible = "mediatek,mt6331-regulator";
+
+   mt6331_vdvfs11_reg: buck-vdvfs11 {
+   regulator-name = "vdvfs11";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1493750>;
+   regulator-ramp-delay = <12500>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-allowed-modes = <0 1>;
+   regulator-always-on;
+   };
+
+   mt6331_vdvfs12_reg: buck-vdvfs12 {
+   regulator-name = "vdvfs12";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1493750>;
+   regulator-ramp-delay = <12500>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-allowed-modes = <0 1>;
+   regulator-always-on;
+   };
+
+   mt6331_vdvfs13_reg: buck-vdvfs13 {
+   regulator-name = "vdvfs13";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1493750>;
+   regulator-ramp-delay = <12500>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-allowed-modes = <0 1>;
+   regulator-always-on;
+   };
+
+   mt6331_vdvfs14_reg: buck-vdvfs14 {
+   regulator-name = "vdvfs14";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1493750>;
+   regulator-ramp-delay = <12500>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-allowed-modes = <0 1>;
+   regulator-always-on;
+   };
+
+   mt6331_vcore2_reg: buck-vcore2 {
+   regulator-name = "vcore2";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1493750>;
+   regulator-ramp-delay = <12500>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-allowed-modes = <0 1>;
+   regulator-always-on;
+   };
+
+   mt6331_vio18_reg: buck-vio18 {
+   regulator-name = "vio18";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12500>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-allowed-modes = <0 1>;
+   regulator-always-on;
+   };
+
+   mt6331_vtcxo1_reg: ldo-vtcxo1 {
+   regulator-name = "vtcxo1";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-ramp-delay = <0>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   mt6331_vtcxo2_reg: ldo-vtcxo2 {
+   regulator-name = "vtcxo2";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt =

Re: [PATCH 21/27] arm64: dts: mediatek: mt6795: Add PMIC Wrapper node





On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

Add the pwrap node: this is used to communicate with the PMIC(s).

Signed-off-by: AngeloGioacchino Del Regno 



Applied thanks!


---
  arch/arm64/boot/dts/mediatek/mt6795.dtsi | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
index 50d9276d18c6..29ca9a7bf0b3 100644
--- a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
@@ -391,6 +391,17 @@ timer: timer@10008000 {
clocks = <_clk>, <>;
};
  
+		pwrap: pwrap@1000d000 {

+   compatible = "mediatek,mt6795-pwrap";
+   reg = <0 0x1000d000 0 0x1000>;
+   reg-names = "pwrap";
+   interrupts = ;
+   resets = < MT6795_INFRA_RST0_PMIC_WRAP_RST>;
+   reset-names = "pwrap";
+   clocks = < CLK_TOP_PMICSPI_SEL>, <>;
+   clock-names = "spi", "wrap";
+   };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt6795-sysirq",
 "mediatek,mt6577-sysirq";

Re: [PATCH 18/27] arm64: dts: mediatek: mt6795: Add support for IOMMU and LARBs





On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

Add nodes for the multimedia IOMMU and its LARBs: this includes all but
the MJC LARB, which cannot currently be used and will be added later.

Signed-off-by: AngeloGioacchino Del Regno 



Applied, thanks


---
  arch/arm64/boot/dts/mediatek/mt6795.dtsi | 60 
  1 file changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
index a8b2c4517e79..9cfa02085f61 100644
--- a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
@@ -8,6 +8,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -390,6 +391,17 @@ systimer: timer@10200670 {
clock-names = "clk13m";
};
  
+		iommu: iommu@10205000 {

+   compatible = "mediatek,mt6795-m4u";
+   reg = <0 0x10205000 0 0x1000>;
+   clocks = < CLK_INFRA_M4U>;
+   clock-names = "bclk";
+   interrupts = ;
+   mediatek,larbs = <   >;
+   power-domains = < MT6795_POWER_DOMAIN_MM>;
+   #iommu-cells = <1>;
+   };
+
apmixedsys: syscon@10209000 {
compatible = "mediatek,mt6795-apmixedsys", "syscon";
reg = <0 0x10209000 0 0x1000>;
@@ -648,16 +660,64 @@ mmsys: syscon@1400 {
mediatek,gce-client-reg = < SUBSYS_1400 0 
0x1000>;
};
  
+		larb0: larb@14021000 {

+   compatible = "mediatek,mt6795-smi-larb";
+   reg = <0 0x14021000 0 0x1000>;
+   clocks = < CLK_MM_SMI_COMMON>, < 
CLK_MM_SMI_LARB0>;
+   clock-names = "apb", "smi";
+   mediatek,smi = <_common>;
+   mediatek,larb-id = <0>;
+   power-domains = < MT6795_POWER_DOMAIN_MM>;
+   };
+
+   smi_common: smi@14022000 {
+   compatible = "mediatek,mt6795-smi-common";
+   reg = <0 0x14022000 0 0x1000>;
+   power-domains = < MT6795_POWER_DOMAIN_MM>;
+   clocks = < CLK_INFRA_SMI>, < 
CLK_MM_SMI_COMMON>;
+   clock-names = "apb", "smi";
+   };
+
+   larb2: larb@15001000 {
+   compatible = "mediatek,mt6795-smi-larb";
+   reg = <0 0x15001000 0 0x1000>;
+   clocks = < CLK_MM_SMI_COMMON>, < 
CLK_INFRA_SMI>;
+   clock-names = "apb", "smi";
+   mediatek,smi = <_common>;
+   mediatek,larb-id = <2>;
+   power-domains = < MT6795_POWER_DOMAIN_ISP>;
+   };
+
vdecsys: clock-controller@1600 {
compatible = "mediatek,mt6795-vdecsys";
reg = <0 0x1600 0 0x1000>;
#clock-cells = <1>;
};
  
+		larb1: larb@1601 {

+   compatible = "mediatek,mt6795-smi-larb";
+   reg = <0 0x1601 0 0x1000>;
+   mediatek,smi = <_common>;
+   mediatek,larb-id = <1>;
+   clocks = < CLK_VDEC_CKEN>, < 
CLK_VDEC_LARB_CKEN>;
+   clock-names = "apb", "smi";
+   power-domains = < MT6795_POWER_DOMAIN_VDEC>;
+   };
+
vencsys: clock-controller@1800 {
compatible = "mediatek,mt6795-vencsys";
reg = <0 0x1800 0 0x1000>;
#clock-cells = <1>;
};
+
+   larb3: larb@18001000 {
+   compatible = "mediatek,mt6795-smi-larb";
+   reg = <0 0x18001000 0 0x1000>;
+   clocks = < CLK_VENC_VENC>, < 
CLK_VENC_LARB>;
+   clock-names = "apb", "smi";
+   mediatek,smi = <_common>;
+   mediatek,larb-id = <3>;
+   power-domains = < MT6795_POWER_DOMAIN_VENC>;
+   };
};
  };

Re: [PATCH 17/27] arm64: dts: mediatek: mt6795: Add MMSYS node for multimedia clocks





On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

Add the MultiMedia System node, providing clocks for the multimedia
hardware blocks and their IOMMU/SMIs.

Signed-off-by: AngeloGioacchino Del Regno 



Applied, thanks


---
  arch/arm64/boot/dts/mediatek/mt6795.dtsi | 13 +
  1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
index 99cc4918e6ba..a8b2c4517e79 100644
--- a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
@@ -635,6 +635,19 @@ mmc3: mmc@1126 {
status = "disabled";
};
  
+		mmsys: syscon@1400 {

+   compatible = "mediatek,mt6795-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   power-domains = < MT6795_POWER_DOMAIN_MM>;
+   assigned-clocks = < CLK_TOP_MM_SEL>;
+   assigned-clock-rates = <4>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   mboxes = < 0 CMDQ_THR_PRIO_HIGHEST>,
+< 1 CMDQ_THR_PRIO_HIGHEST>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0 
0x1000>;
+   };
+
vdecsys: clock-controller@1600 {
compatible = "mediatek,mt6795-vdecsys";
reg = <0 0x1600 0 0x1000>;

Re: [PATCH 16/27] arm64: dts: mediatek: mt6795: Add support for the CMDQ/GCE mailbox





On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:

In preparation for adding multimedia blocks, add the CMDQ/GCE mailbox.

Signed-off-by: AngeloGioacchino Del Regno 



Applied, thanks


---
  arch/arm64/boot/dts/mediatek/mt6795.dtsi | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
index 090400d7fd61..99cc4918e6ba 100644
--- a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -401,6 +402,15 @@ fhctl: clock-controller@10209f00 {
status = "disabled";
};
  
+		gce: mailbox@10212000 {

+   compatible = "mediatek,mt6795-gce", 
"mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+   #mbox-cells = <2>;
+   };
+
gic: interrupt-controller@10221000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;

[PATCH v8 13/18] drm/msm/a6xx: Add A610 support

A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It
features no GMU, as it's implemented solely on SoCs with SMD_RPM.
What's more interesting is that it does not feature a VDDGX line
either, being powered solely by VDDCX and has an unfortunate hardware
quirk that makes its reset line broken - after a couple of assert/
deassert cycles, it will hang for good and will not wake up again.

This GPU requires mesa changes for proper rendering, and lots of them
at that. The command streams are quite far away from any other A6XX
GPU and hence it needs special care. This patch was validated both
by running an (incomplete) downstream mesa with some hacks (frames
rendered correctly, though some instructions made the GPU hangcheck
which is expected - garbage in, garbage out) and by replaying RD
traces captured with the downstream KGSL driver - no crashes there,
ever.

Add support for this GPU on the kernel side, which comes down to
pretty simply adding A612 HWCG tables, altering a few values and
adding a special case for handling the reset line.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  | 101 +
 drivers/gpu/drm/msm/adreno/adreno_device.c |  12 
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|   8 ++-
 3 files changed, 108 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index bb04f65e6f68..c0d5973320d9 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -252,6 +252,56 @@ static void a6xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit)
a6xx_flush(gpu, ring);
 }
 
+const struct adreno_reglist a612_hwcg[] = {
+   {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220},
+   {REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0081},
+   {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xf3cf},
+   {REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002},
+   {REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_DELAY3_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_DELAY4_TP0, 0x0001},
+   {REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x},
+   {REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007},
+   {REG_A6XX_RBBM_CLOCK_CNTL_RB0, 0x},
+   {REG_A6XX_RBBM_CLOCK_CNTL2_RB0, 0x0120},
+   {REG_A6XX_RBBM_CLOCK_CNTL_CCU0, 0x2220},
+   {REG_A6XX_RBBM_CLOCK_HYST_RB_CCU0, 0x00040f00},
+   {REG_A6XX_RBBM_CLOCK_CNTL_RAC, 0x05522022},
+   {REG_A6XX_RBBM_CLOCK_CNTL2_RAC, 0x},
+   {REG_A6XX_RBBM_CLOCK_DELAY_RAC, 0x0011},
+   {REG_A6XX_RBBM_CLOCK_HYST_RAC, 0x00445044},
+   {REG_A6XX_RBBM_CLOCK_CNTL_TSE_RAS_RBBM, 0x0422},
+   {REG_A6XX_RBBM_CLOCK_MODE_VFD, 0x},
+   {REG_A6XX_RBBM_CLOCK_MODE_GPC, 0x0222},
+   {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ_2, 0x0002},
+   {REG_A6XX_RBBM_CLOCK_MODE_HLSQ, 0x},
+   {REG_A6XX_RBBM_CLOCK_DELAY_TSE_RAS_RBBM, 0x4000},
+   {REG_A6XX_RBBM_CLOCK_DELAY_VFD, 0x},
+   {REG_A6XX_RBBM_CLOCK_DELAY_GPC, 0x0200},
+   {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ, 0x},
+   {REG_A6XX_RBBM_CLOCK_HYST_TSE_RAS_RBBM, 0x},
+   {REG_A6XX_RBBM_CLOCK_HYST_VFD, 0x},
+   {REG_A6XX_RBBM_CLOCK_HYST_GPC, 0x04104004},
+   {REG_A6XX_RBBM_CLOCK_HYST_HLSQ, 0x},
+   {REG_A6XX_RBBM_CLOCK_CNTL_UCHE, 0x},
+   {REG_A6XX_RBBM_CLOCK_HYST_UCHE, 0x0004},
+   {REG_A6XX_RBBM_CLOCK_DELAY_UCHE, 0x0002},
+   {REG_A6XX_RBBM_ISDB_CNT, 0x0182},
+   {REG_A6XX_RBBM_RAC_THRESHOLD_CNT, 0x},
+   {REG_A6XX_RBBM_SP_HYST_CNT, 0x},
+   {REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x0222},
+   {REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x0111},
+   {REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x0555},
+   {},
+};
+
 /* For a615 family (a615, a616, a618 and a619) */
 const struct adreno_reglist a615_hwcg[] = {
{REG_A6XX_RBBM_CLOCK_CNTL_SP0,  0x0222},
@@ -602,6 +652,8 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
 
if (adreno_is_a630(adreno_gpu))
clock_cntl_on = 0x8aa8aa02;
+   else if (adreno_is_a610(adreno_gpu))
+   clock_cntl_on = 0xaaa8aa82;
else
clock_cntl_on = 0x8aa8aa82;
 
@@ -612,13 +664,15 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
return;
 
/* Disable SP clock before programming HWCG registers */
-   gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 1, 0);
+   if (!adreno_is_a610(adreno_gpu))

[PATCH v8 11/18] drm/msm/adreno: Disable has_cached_coherent in GMU wrapper configurations

A610 and A619_holi don't support the feature. Disable it to make the GPU stop
crashing after almost each and every submission - the received data on
the GPU end was simply incomplete in garbled, resulting in almost nothing
being executed properly. Extend the disablement to adreno_has_gmu_wrapper,
as none of the GMU wrapper Adrenos that don't support yet seem to feature it.

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 8cff86e9d35c..b133755a56c4 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -551,7 +551,6 @@ static int adreno_bind(struct device *dev, struct device 
*master, void *data)
config.rev.minor, config.rev.patchid);
 
priv->is_a2xx = config.rev.core == 2;
-   priv->has_cached_coherent = config.rev.core >= 6;
 
gpu = info->init(drm);
if (IS_ERR(gpu)) {
@@ -563,6 +562,10 @@ static int adreno_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
+   if (config.rev.core >= 6)
+   if (!adreno_has_gmu_wrapper(to_adreno_gpu(gpu)))
+   priv->has_cached_coherent = true;
+
return 0;
 }
 

-- 
2.40.1

[PATCH v8 06/18] drm/msm/a6xx: Improve a6xx_bus_clear_pending_transactions()