RE: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu
[AMD Official Use Only - General] Hi Christian, I will check this issue. Regards, Arun -Original Message- From: Koenig, Christian Sent: Tuesday, April 26, 2022 10:06 PM To: Mike Lothian ; Paneer Selvam, Arunpravin Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Deucher, Alexander ; matthew.a...@intel.com Subject: Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu Hi Mike, sounds like somehow stitching together the SG table for PRIME doesn't work any more with this patch. Can you try with P2P DMA disabled? Apart from that can you take a look Arun? Thanks, Christian. Am 26.04.22 um 17:29 schrieb Mike Lothian: > Hi > > I'm having issues with this patch on my PRIME system and vulkan > workloads > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl > ab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1992data=05%7C01%7C > christian.koenig%40amd.com%7Ce18d158769fc47b08ee708da27998e7e%7C3dd896 > 1fe4884e608e11a82d994e183d%7C0%7C0%7C637865838441574170%7CUnknown%7CTW > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > Mn0%3D%7C1000%7C%7C%7Csdata=hQu67WrdUwZn6%2BdXziGz84nMGepI6%2FnlB > 8XFCFKCnpA%3Dreserved=0 > > Is there any chance you could take a look? > > Cheers > > Mike
Re: [PATCH 1/2] drm/vmwgfx: Remove unused hugepage support
On 4/25/22 22:31, Zack Rusin wrote:
From: Zack Rusin
There's no point in explicitly trying to align virtual memory to
facilitate huge page table entries or huge page memory in buffer objects
given that they're not being used.
Transparent hugepages support for vram allocations has been gradually
retired over the last two years making alignment of unmapped areas
unneeded and pointless.
Signed-off-by: Zack Rusin
For the series:
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 5dc02fd806db..45028e25d490 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1423,18 +1423,6 @@ static void vmw_debugfs_resource_managers_init(struct
vmw_private *vmw)
root, "system_mob_ttm");
}
-static unsigned long
-vmw_get_unmapped_area(struct file *file, unsigned long uaddr,
- unsigned long len, unsigned long pgoff,
- unsigned long flags)
-{
- struct drm_file *file_priv = file->private_data;
- struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
-
- return drm_get_unmapped_area(file, uaddr, len, pgoff, flags,
-dev_priv->drm.vma_offset_manager);
-}
-
static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
void *ptr)
{
@@ -1601,7 +1589,6 @@ static const struct file_operations vmwgfx_driver_fops = {
.compat_ioctl = vmw_compat_ioctl,
#endif
.llseek = noop_llseek,
- .get_unmapped_area = vmw_get_unmapped_area,
};
static const struct drm_driver driver = {
[Bug 215892] 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30!
https://bugzilla.kernel.org/show_bug.cgi?id=215892 --- Comment #4 from Mark Johnston (ula...@gmail.com) --- Created attachment 300815 --> https://bugzilla.kernel.org/attachment.cgi?id=300815=edit acpidump summary -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215892] 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30!
https://bugzilla.kernel.org/show_bug.cgi?id=215892 --- Comment #3 from Mark Johnston (ula...@gmail.com) --- Created attachment 300814 --> https://bugzilla.kernel.org/attachment.cgi?id=300814=edit lspci The hardware configuration that was most recently tested. -- 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] gpu: drm: remove redundant dma_fence_put() when drm_sched_job_add_dependency() fails
On 2022/4/26 22:55, Andrey Grodzovsky wrote:
On 2022-04-25 22:54, Hangyu Hua wrote:
On 2022/4/25 23:42, Andrey Grodzovsky wrote:
On 2022-04-25 04:36, Hangyu Hua wrote:
When drm_sched_job_add_dependency() fails, dma_fence_put() will be
called
internally. Calling it again after drm_sched_job_add_dependency()
finishes
may result in a dangling pointer.
Fix this by removing redundant dma_fence_put().
Signed-off-by: Hangyu Hua
---
drivers/gpu/drm/lima/lima_gem.c | 1 -
drivers/gpu/drm/scheduler/sched_main.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_gem.c
b/drivers/gpu/drm/lima/lima_gem.c
index 55bb1ec3c4f7..99c8e7f6bb1c 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -291,7 +291,6 @@ static int lima_gem_add_deps(struct drm_file
*file, struct lima_submit *submit)
err = drm_sched_job_add_dependency(>task->base,
fence);
if (err) {
- dma_fence_put(fence);
return err;
Makes sense here
}
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index b81fceb0b8a2..ebab9eca37a8 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -708,7 +708,6 @@ int
drm_sched_job_add_implicit_dependencies(struct drm_sched_job *job,
dma_fence_get(fence);
ret = drm_sched_job_add_dependency(job, fence);
if (ret) {
- dma_fence_put(fence);
Not sure about this one since if you look at the relevant commits -
'drm/scheduler: fix drm_sched_job_add_implicit_dependencies' and
'drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder'
You will see that the dma_fence_put here balances the extra
dma_fence_get
above
Andrey
I don't think so. I checked the call chain and found no additional
dma_fence_get(). But dma_fence_get() needs to be called before
drm_sched_job_add_dependency() to keep the counter balanced.
I don't say there is an additional get, I just say that
drm_sched_job_add_dependency doesn't grab an extra reference to the
fences it stores so this needs to be done outside and for that
drm_sched_job_add_implicit_dependencies->dma_fence_get is called and, if
this addition fails you just call dma_fence_put to keep the counter
balanced.
drm_sched_job_add_implicit_dependencies() will call
drm_sched_job_add_dependency(). And drm_sched_job_add_dependency()
already call dma_fence_put() when it fails. Calling dma_fence_put()
twice doesn't make sense.
dma_fence_get() is in [2]. But dma_fence_put() will be called in [1] and
[3] when xa_alloc() fails.
int drm_sched_job_add_dependency(struct drm_sched_job *job,
struct dma_fence *fence)
{
...
ret = xa_alloc(>dependencies, , fence, xa_limit_32b,
GFP_KERNEL);
if (ret != 0)
dma_fence_put(fence); <--- [1]
return ret;
}
EXPORT_SYMBOL(drm_sched_job_add_dependency);
int drm_sched_job_add_implicit_dependencies(struct drm_sched_job *job,
struct drm_gem_object *obj,
bool write)
{
struct dma_resv_iter cursor;
struct dma_fence *fence;
int ret;
dma_resv_for_each_fence(, obj->resv, write, fence) {
/* Make sure to grab an additional ref on the added fence */
dma_fence_get(fence); <--- [2]
ret = drm_sched_job_add_dependency(job, fence);
if (ret) {
dma_fence_put(fence); <--- [3]
return ret;
}
}
return 0;
}
On the other hand, dma_fence_get() and dma_fence_put() are meaningless
here if threre is an extra dma_fence_get() beacause counter will not
decrease to 0 during drm_sched_job_add_dependency().
I check the call chain as follows:
msm_ioctl_gem_submit()
-> submit_fence_sync()
-> drm_sched_job_add_implicit_dependencies()
Can you maybe trace or print one such example of problematic refcount
that you are trying to fix ? I still don't see where is the problem.
Andrey
I also wish I could. System logs can make this easy. But i don't have a
corresponding GPU physical device.
drm_sched_job_add_implicit_dependencies is only used in a few devices.
Thanks.
Thanks,
Hangyu
return ret;
}
}
[Bug 215892] 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30!
https://bugzilla.kernel.org/show_bug.cgi?id=215892 --- Comment #2 from Mark Johnston (ula...@gmail.com) --- Created attachment 300813 --> https://bugzilla.kernel.org/attachment.cgi?id=300813=edit Prior PowerColor (6500XT) board with chip that does not produce error -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215892] 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30!
https://bugzilla.kernel.org/show_bug.cgi?id=215892 --- Comment #1 from Mark Johnston (ula...@gmail.com) --- Created attachment 300812 --> https://bugzilla.kernel.org/attachment.cgi?id=300812=edit full dmesg -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215892] New: 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30!
https://bugzilla.kernel.org/show_bug.cgi?id=215892 Bug ID: 215892 Summary: 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30! Product: Drivers Version: 2.5 Kernel Version: 5.18-rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ula...@gmail.com Regression: No Created attachment 300811 --> https://bugzilla.kernel.org/attachment.cgi?id=300811=edit New PowerColor board with chip that produces kernel errors Hello! This is my first time submitted a bug here. I apologize if I make any mistakes here, but I am going to do my best to describe the efforts that I have gone through to attempt to resolve this issue on my own. As well, I hope not to overload with information, but just wish to help with skipping over the basic questions. I have numerous PowerColor RX 6500XT graphics cards, and all of them with a specific chip package (picture attached) have the same issue. Any PowerColor RX 6500XT with 2152 printed at the top of the package, and "TFTB43.00" at the bottom of the package suffers the same kernel errors. Previously (up until a few weeks ago) PowerColor was shipping 6500XT boards with chips that were stamped with 2146 and "TFAW62.T5" at the top and bottom of the package respectively. Boards with those chips have zero kernel errors and work flawlessly. As well, I have tested various 6500XT and 6400 boards from different AIB partners of AMD and have not had any issues other than this specific variant from PowerColor. To be honest, I am not sure if the root of the problem is in pcieport or in amdgpu, but the amdgpu error throws first. I have attached the full dmesg output but to save some time here are some highlighted lines of issue: [5.506718] [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30! [ 14.368915] pcieport :01:00.0: can't change power state from D0 to D3hot (config space inaccessible) [ 15.270778] pcieport :01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 15.270799] pcieport :02:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 25.478689] pcieport :01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 25.478696] pcieport :02:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 25.722619] amdgpu :03:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 35.833714] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 0! [ 35.941450] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for sem acquire in VM flush! [ 36.048999] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 1! [ 36.156835] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for sem acquire in VM flush! [ 36.264770] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 1! [ 36.372616] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 0! What I have attempted so far: Results were the same for the following kernels: 5.4.190, 5.10.111, 5.15.34, 5.17.4 and now 5.18-rc4. Many different motherboards with varying chipsets (B250, H510, X370, B550). Same result. Enabling/Disabling clock gating, ASPM, extended synch control for PCIE. Same result. The problematic cards from PowerColor indeed do work in Windows without issue. This leads me to believe that something may have changed with TUL's implementation of the 6500XT from one production run to another. Hopefully someone from the amdgpu team can help here. To summarize, PowerColor's prior 6500XT production worked flawlessly with the drivers in the mainline kernel. New production for some reason is no longer usable. New cards work in Windows, but now throw the errors above. Not an isolated issue of one card, as I have tested 12 identical ones with the same chip and all have the same result regardless of motherboard, cpu, power, kernel, OS, etc. Cards (6500XT and 6400s) from other partners have not had any issues. -- 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 03/25] drm/msm/dpu: add support for SSPP allocation to RM
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
Add support for handling and allocting SSPP blocks through the resource
manager. Handling code is not converted to use it though.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 10 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 81 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 6 ++
5 files changed, 104 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 1b18de957500..f805c30643b1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -388,6 +388,16 @@ struct dpu_hw_pipe {
};
struct dpu_kms;
+/**
+ * to_dpu_hw_pipe - convert base object dpu_hw_base to container
+ * @hw: Pointer to base hardware block
+ * return: Pointer to hardware block container
+ */
+static inline struct dpu_hw_pipe *to_dpu_hw_pipe(struct dpu_hw_blk *hw)
+{
+ return container_of(hw, struct dpu_hw_pipe, base);
+}
+
/**
* dpu_hw_sspp_init - initializes the sspp hw driver object.
* Should be called once before accessing every pipe.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 2d385b4b7f5e..824495ad2392 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -146,6 +146,7 @@ struct dpu_global_state {
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
uint32_t intf_to_enc_id[INTF_MAX - INTF_0];
uint32_t dspp_to_enc_id[DSPP_MAX - DSPP_0];
+ uint32_t pipe_to_plane_id[SSPP_MAX - SSPP_NONE];
};
struct dpu_global_state
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c04c3be16d85..146dbccd79cd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1235,8 +1235,6 @@ static void dpu_plane_destroy(struct drm_plane *plane)
/* this will destroy the states as well */
drm_plane_cleanup(plane);
- dpu_hw_sspp_destroy(pdpu->pipe_hw);
-
kfree(pdpu);
}
}
@@ -1445,14 +1443,13 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
pdpu->pipe = pipe;
/* initialize underlying h/w driver */
- pdpu->pipe_hw = dpu_hw_sspp_init(pipe, kms->mmio, kms->catalog);
- if (IS_ERR(pdpu->pipe_hw)) {
- DPU_ERROR("[%u]SSPP init failed\n", pipe);
- ret = PTR_ERR(pdpu->pipe_hw);
+ if (!kms->rm.sspp_blks[pipe - SSPP_NONE])
goto clean_plane;
- } else if (!pdpu->pipe_hw->cap || !pdpu->pipe_hw->cap->sblk) {
+ pdpu->pipe_hw = to_dpu_hw_pipe(kms->rm.sspp_blks[pipe - SSPP_NONE]);
+
+ if (!pdpu->pipe_hw->cap || !pdpu->pipe_hw->cap->sblk) {
DPU_ERROR("[%u]SSPP init returned invalid cfg\n", pipe);
- goto clean_sspp;
+ goto clean_plane;
}
format_list = pdpu->pipe_hw->cap->sblk->format_list;
@@ -1462,7 +1459,7 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
format_list, num_formats,
supported_format_modifiers, type, NULL);
if (ret)
- goto clean_sspp;
+ goto clean_plane;
pdpu->catalog = kms->catalog;
@@ -1494,9 +1491,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
pipe, plane->base.id);
return plane;
-clean_sspp:
- if (pdpu && pdpu->pipe_hw)
- dpu_hw_sspp_destroy(pdpu->pipe_hw);
clean_plane:
kfree(pdpu);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f9c83d6e427a..21c9e513f1f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -8,6 +8,7 @@
#include "dpu_hw_lm.h"
#include "dpu_hw_ctl.h"
#include "dpu_hw_pingpong.h"
+#include "dpu_hw_sspp.h"
#include "dpu_hw_intf.h"
#include "dpu_hw_dspp.h"
#include "dpu_hw_merge3d.h"
@@ -35,6 +36,14 @@ int dpu_rm_destroy(struct dpu_rm *rm)
{
int i;
+ for (i = 0; i < ARRAY_SIZE(rm->sspp_blks); i++) {
+ struct dpu_hw_pipe *hw;
+
+ if (rm->sspp_blks[i]) {
+ hw = to_dpu_hw_pipe(rm->sspp_blks[i]);
+ dpu_hw_sspp_destroy(hw);
+ }
+ }
for (i = 0; i < ARRAY_SIZE(rm->pingpong_blks); i++) {
struct dpu_hw_pingpong *hw;
@@ -166,6 +175,24 @@ int dpu_rm_init(struct dpu_rm *rm,
rm->pingpong_blks[pp->id - PINGPONG_0] = >base;
}
+ for (i = 0; i < cat->sspp_count; i++) {
+ struct dpu_hw_pipe *hw;
+
[PATCH v3] drm/amdgpu: Disable ABM when AC mode
Disable ABM feature when the system is running on AC mode to get the more
perfect contrast of the display.
v2: remove "UPSTREAM" from the subject.
v3: adv->pm.ac_power updating by amd gpu_acpi_event_handler.
Signed-off-by: Ryan Lin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 1 +
drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c | 61 +++
drivers/gpu/drm/amd/include/amd_acpi.h| 1 +
4 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 4811b0faafd9a..6ac331ee4255d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -822,7 +822,8 @@ static int amdgpu_acpi_event(struct notifier_block *nb,
struct amdgpu_device *adev = container_of(nb, struct amdgpu_device,
acpi_nb);
struct acpi_bus_event *entry = (struct acpi_bus_event *)data;
- if (strcmp(entry->device_class, ACPI_AC_CLASS) == 0) {
+ if (strcmp(entry->device_class, ACPI_AC_CLASS) == 0 ||
+ strcmp(entry->device_class, ACPI_BATTERY_CLASS) == 0) {
if (power_supply_is_system_supplied() > 0)
DRM_DEBUG_DRIVER("pm: AC\n");
else
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index abfcc1304ba0c..3a0afe7602727 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3454,6 +3454,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
adev->gfx.gfx_off_req_count = 1;
adev->pm.ac_power = power_supply_is_system_supplied() > 0;
+ adev->pm.old_ac_power = true;
atomic_set(>throttling_logging_enabled, 1);
/*
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
index 54a1408c8015c..090bd23410b45 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
@@ -22,7 +22,8 @@
* Authors: AMD
*
*/
-
+#include
+#include "amdgpu.h"
#include "dmub_abm.h"
#include "dce_abm.h"
#include "dc.h"
@@ -50,7 +51,7 @@
#define DISABLE_ABM_IMMEDIATELY 255
-
+extern uint amdgpu_dm_abm_level;
static void dmub_abm_enable_fractional_pwm(struct dc_context *dc)
{
@@ -117,28 +118,6 @@ static void dmub_abm_init(struct abm *abm, uint32_t
backlight)
dmub_abm_enable_fractional_pwm(abm->ctx);
}
-static unsigned int dmub_abm_get_current_backlight(struct abm *abm)
-{
- struct dce_abm *dce_abm = TO_DMUB_ABM(abm);
- unsigned int backlight = REG_READ(BL1_PWM_CURRENT_ABM_LEVEL);
-
- /* return backlight in hardware format which is unsigned 17 bits, with
-* 1 bit integer and 16 bit fractional
-*/
- return backlight;
-}
-
-static unsigned int dmub_abm_get_target_backlight(struct abm *abm)
-{
- struct dce_abm *dce_abm = TO_DMUB_ABM(abm);
- unsigned int backlight = REG_READ(BL1_PWM_TARGET_ABM_LEVEL);
-
- /* return backlight in hardware format which is unsigned 17 bits, with
-* 1 bit integer and 16 bit fractional
-*/
- return backlight;
-}
-
static bool dmub_abm_set_level(struct abm *abm, uint32_t level)
{
union dmub_rb_cmd cmd;
@@ -147,6 +126,10 @@ static bool dmub_abm_set_level(struct abm *abm, uint32_t
level)
int i;
int edp_num;
uint8_t panel_mask = 0;
+ struct amdgpu_device *dev = dc->driver_context;
+
+ if (dev->pm.ac_power)
+ level = 0;
get_edp_links(dc->dc, edp_links, _num);
@@ -170,6 +153,36 @@ static bool dmub_abm_set_level(struct abm *abm, uint32_t
level)
return true;
}
+static unsigned int dmub_abm_get_current_backlight(struct abm *abm)
+{
+ struct dce_abm *dce_abm = TO_DMUB_ABM(abm);
+ unsigned int backlight = REG_READ(BL1_PWM_CURRENT_ABM_LEVEL);
+ struct dc_context *dc = abm->ctx;
+ struct amdgpu_device *adev = dc->driver_context;
+
+ if (adev->pm.ac_power != adev->pm.old_ac_power) {
+ dmub_abm_set_level(abm, amdgpu_dm_abm_level);
+ adev->pm.ac_power = power_supply_is_system_supplied() > 0;
+ adev->pm.old_ac_power = adev->pm.ac_power;
+ }
+
+ /* return backlight in hardware format which is unsigned 17 bits, with
+* 1 bit integer and 16 bit fractional
+*/
+ return backlight;
+}
+
+static unsigned int dmub_abm_get_target_backlight(struct abm *abm)
+{
+ struct dce_abm *dce_abm = TO_DMUB_ABM(abm);
+ unsigned int backlight = REG_READ(BL1_PWM_TARGET_ABM_LEVEL);
+
+ /* return backlight in hardware format which is unsigned 17 bits, with
+* 1 bit integer and 16 bit fractional
+*/
+ return backlight;
+}
+
static bool dmub_abm_init_config(struct abm *abm,
const char *src,
Re: [PATCH 2/2] drm/amdgpu: debugfs: fix NULL dereference in ta_if_invoke_debugfs_write()
Alex-- On 4/26/22 07:47, Alex Deucher wrote: > Applied the series. Thanks! > > Alex > I just saw a build warning here when CONFIG_DEBUG_FS is not enabled: ../drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c:281:23: warning: 'amdgpu_ta_if_debugfs_create' defined but not used [-Wunused-function] 281 | static struct dentry *amdgpu_ta_if_debugfs_create(struct amdgpu_device *adev) | ^~~ -- ~Randy
Re: [PATCH 02/25] drm/msm/dpu: do not limit the zpos property
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
Stop limiting zpos property values, we use normalized_zpos anyway. And
nothing stops userspace from assigning several planes to a single zpos
(it is a userspace bug, but the kernel is forgiving about it).
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 3fcc964dec0a..c04c3be16d85 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1429,7 +1429,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
struct dpu_plane *pdpu;
struct msm_drm_private *priv = dev->dev_private;
struct dpu_kms *kms = to_dpu_kms(priv->kms);
- int zpos_max = DPU_ZPOS_MAX;
uint32_t num_formats;
int ret = -EINVAL;
@@ -1467,14 +1466,7 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
pdpu->catalog = kms->catalog;
- if (kms->catalog->mixer_count &&
- kms->catalog->mixer[0].sblk->maxblendstages) {
- zpos_max = kms->catalog->mixer[0].sblk->maxblendstages - 1;
- if (zpos_max > DPU_STAGE_MAX - DPU_STAGE_0 - 1)
- zpos_max = DPU_STAGE_MAX - DPU_STAGE_0 - 1;
- }
-
- ret = drm_plane_create_zpos_property(plane, 0, 0, zpos_max);
+ ret = drm_plane_create_zpos_property(plane, 0, 0, DPU_ZPOS_MAX);
if (ret)
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
Re: [PATCH 01/25] drm/msm/dpu: rip out master planes support
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
Master/virtual planes were used for multirect support. In preparation to
reworking DPU planes, drop support for master planes (which was not used
anyway).
Signed-off-by: Dmitry Baryshkov
Agreed, master planes were unused today anyway.
hence,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 11 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 72 -
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 13 +---
6 files changed, 18 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e7c9fe1a250f..7318bd45637a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1138,17 +1138,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
}
for (i = 1; i < SSPP_MAX; i++) {
- if (pipe_staged[i]) {
+ if (pipe_staged[i])
dpu_plane_clear_multirect(pipe_staged[i]);
-
- if (is_dpu_plane_virtual(pipe_staged[i]->plane)) {
- DPU_ERROR(
- "r1 only virt plane:%d not supported\n",
- pipe_staged[i]->plane->base.id);
- rc = -EINVAL;
- goto end;
- }
- }
}
z_pos = -1;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 09cdc3576653..8714ee767346 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -783,8 +783,7 @@ static const struct dpu_sspp_cfg *_sspp_offset(enum
dpu_sspp sspp,
}
struct dpu_hw_pipe *dpu_hw_sspp_init(enum dpu_sspp idx,
- void __iomem *addr, struct dpu_mdss_cfg *catalog,
- bool is_virtual_pipe)
+ void __iomem *addr, struct dpu_mdss_cfg *catalog)
{
struct dpu_hw_pipe *hw_pipe;
const struct dpu_sspp_cfg *cfg;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 92b071b78fdb..1b18de957500 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -394,11 +394,9 @@ struct dpu_kms;
* @idx: Pipe index for which driver object is required
* @addr: Mapped register io address of MDP
* @catalog : Pointer to mdss catalog data
- * @is_virtual_pipe: is this pipe virtual pipe
*/
struct dpu_hw_pipe *dpu_hw_sspp_init(enum dpu_sspp idx,
- void __iomem *addr, struct dpu_mdss_cfg *catalog,
- bool is_virtual_pipe);
+ void __iomem *addr, struct dpu_mdss_cfg *catalog);
/**
* dpu_hw_sspp_destroy(): Destroys SSPP driver context
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 47fe11a84a77..4d2b75f3bc89 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -738,7 +738,7 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
catalog->sspp[i].features & BIT(DPU_SSPP_CURSOR));
plane = dpu_plane_init(dev, catalog->sspp[i].id, type,
- (1UL << max_crtc_count) - 1, 0);
+ (1UL << max_crtc_count) - 1);
if (IS_ERR(plane)) {
DPU_ERROR("dpu_plane_init failed\n");
ret = PTR_ERR(plane);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index ca75089c9d61..3fcc964dec0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -89,7 +89,7 @@ enum dpu_plane_qos {
/*
* struct dpu_plane - local dpu plane structure
* @aspace: address space pointer
- * @mplane_list: List of multirect planes of the same pipe
+ * @csc_ptr: Points to dpu_csc_cfg structure to use for current
* @catalog: Points to dpu catalog structure
* @revalidate: force revalidation of all the plane properties
*/
@@ -104,8 +104,6 @@ struct dpu_plane {
uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
- bool is_virtual;
- struct list_head mplane_list;
struct dpu_mdss_cfg *catalog;
};
@@ -223,7 +221,7 @@ static void _dpu_plane_calc_clk(struct drm_plane *plane, struct dpu_hw_pipe_cfg
static int _dpu_plane_calc_fill_level(struct drm_plane *plane,
const struct dpu_format *fmt, u32 src_width)
{
- struct dpu_plane *pdpu, *tmp;
+ struct dpu_plane *pdpu;
struct dpu_plane_state
Re: [PATCH v5 6/9] drm: vkms: Refactor the plane composer to accept new formats
On April 26, 2022 10:03:09 PM GMT-03:00, Igor Torrente
wrote:
>
>
>On 4/25/22 22:54, Igor Torrente wrote:
>> Hi Pekka,
>>
>> On 4/25/22 05:10, Pekka Paalanen wrote:
>>> On Sat, 23 Apr 2022 15:53:20 -0300
>>> Igor Torrente wrote:
>>>
I forgot to respond some points from your review.
On 4/23/22 13:04, Igor Torrente wrote:
> Hi Pekka,
>
> On 4/20/22 09:36, Pekka Paalanen wrote:
>> On Mon, 4 Apr 2022 17:45:12 -0300
>> Igor Torrente wrote:
>>
>>> Currently the blend function only accepts XRGB_ and ARGB_
>>> as a color input.
>>>
>>> This patch refactors all the functions related to the plane composition
>>> to overcome this limitation.
>>>
>>> A new internal format(`struct pixel`) is introduced to deal with all
>>
>> Hi,
>>
>> struct pixel_argb_u16 was added in the previous patch.
>
> I will fix it. Thanks!
>>>
>>> ...
>>>
>>> +static int compose_active_planes(struct vkms_writeback_job *active_wb,
>>> +struct vkms_crtc_state *crtc_state,
>>> +u32 *crc32)
>>> {
>>> + int line_width, ret = 0, pixel_size = sizeof(struct
>>> pixel_argb_u16);
>>> + struct vkms_frame_info *primary_plane_info = NULL;
>>> + struct line_buffer output_buffer, stage_buffer;
>>> + struct vkms_plane_state *act_plane = NULL;
>>> + u32 wb_format;
>>> + if (WARN_ON(pixel_size != 8))
>>
>> Isn't there a compile-time assert macro for this? Having to actually
>> run VKMS to check for this reduces the chances of finding it early.
>> What's the reason for this check anyway?
Yes, it exists.
include/linux/build_bug.h:1:#define static_assert(expr, ...)
__static_assert(expr, ##__VA_ARGS__, #expr)
I didn't add it because I can imagine some people very mad if the kernel
did not compile because of vkms.
>>>
>>> But that would mean that VKMS is broken on those platforms. You'd
>>> better know which platforms VKMS is broken, so the Kconfig can stop
>>> VKMS from being built there at all. Or better, fix it before anyone
>>> needs VKMS there.
>>
>> Right. Makes sense. I will add it then.
>>
>>>
This check exists so we can call `crc32_le` for the entire line instead
doing it for each channel of each pixel in case `struct `pixel_argb_u16`
had any gap added by the compiler between the struct fields.
>>>
>>> Oh the CRC computation. Good point.
>>>
>>> Can you add a comment about that with the check?
>>
>> Yeah, np.
>>
>> I will copy the explanation above :)
>>
>>>
>>
>>> + return -EINVAL;
>>> +
>>> + if (crtc_state->num_active_planes >= 1) {
>>> + act_plane = crtc_state->active_planes[0];
>>> + if (act_plane->base.base.plane->type ==
>>> DRM_PLANE_TYPE_PRIMARY)
>>> + primary_plane_info = act_plane->frame_info;
>>
>> After the next patch, do you even need the primary plane for anything
>> specifically?
Yeah, I will not need it anymore.
>> There is the map_is_null check below, but that should be
>> done on all planes in the array, right?
Yes, I guess so. And I don't know why it only checks for the
primary_plane TBH.
>>>
>>> Maybe a left-over from times when it didn't have anything but a primary
>>> plane?
>>
>> Maybe.
>>
>> Anyway, I have added this verification to all active planes in the next
>> version.
>>
>>>
>>
>> I suspect the next patch, or another patch in this series, should just
>> delete this chunk.
I should, and I will in the V6 of next patch.
>
>
>
>>
>>> }
>>> + if (!primary_plane_info)
>>> + return -EINVAL;
>>> +
>>> if (WARN_ON(dma_buf_map_is_null(_plane_info->map[0])))
>>> return -EINVAL;
>>> + if (WARN_ON(check_format_funcs(crtc_state, active_wb)))
>>> + return -EINVAL;
>>> + line_width = drm_rect_width(_plane_info->dst);
>>> + stage_buffer.n_pixels = line_width;
>>> + output_buffer.n_pixels = line_width;
>>> + stage_buffer.pixels = kvmalloc(line_width * pixel_size,
>>> GFP_KERNEL);
>>> + if (!stage_buffer.pixels) {
>>> + DRM_ERROR("Cannot allocate memory for the output line
>>> buffer");
>>> + return -ENOMEM;
>>> + }
>>> + output_buffer.pixels = kvmalloc(line_width * pixel_size,
>>> GFP_KERNEL);
>>> + if (!output_buffer.pixels) {
>>> + DRM_ERROR("Cannot allocate memory for intermediate line
>>> buffer");
>>> + ret = -ENOMEM;
>>> + goto free_stage_buffer;
>>> + }
>>> +
>>> +
Re: [PATCH v5 6/9] drm: vkms: Refactor the plane composer to accept new formats
On 4/25/22 22:54, Igor Torrente wrote:
Hi Pekka,
On 4/25/22 05:10, Pekka Paalanen wrote:
On Sat, 23 Apr 2022 15:53:20 -0300
Igor Torrente wrote:
I forgot to respond some points from your review.
On 4/23/22 13:04, Igor Torrente wrote:
Hi Pekka,
On 4/20/22 09:36, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:12 -0300
Igor Torrente wrote:
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal format(`struct pixel`) is introduced to deal with all
Hi,
struct pixel_argb_u16 was added in the previous patch.
I will fix it. Thanks!
...
+static int compose_active_planes(struct vkms_writeback_job *active_wb,
+struct vkms_crtc_state *crtc_state,
+u32 *crc32)
{
+ int line_width, ret = 0, pixel_size = sizeof(struct pixel_argb_u16);
+ struct vkms_frame_info *primary_plane_info = NULL;
+ struct line_buffer output_buffer, stage_buffer;
+ struct vkms_plane_state *act_plane = NULL;
+ u32 wb_format;
+ if (WARN_ON(pixel_size != 8))
Isn't there a compile-time assert macro for this? Having to actually
run VKMS to check for this reduces the chances of finding it early.
What's the reason for this check anyway?
Yes, it exists.
include/linux/build_bug.h:1:#define static_assert(expr, ...)
__static_assert(expr, ##__VA_ARGS__, #expr)
I didn't add it because I can imagine some people very mad if the kernel
did not compile because of vkms.
But that would mean that VKMS is broken on those platforms. You'd
better know which platforms VKMS is broken, so the Kconfig can stop
VKMS from being built there at all. Or better, fix it before anyone
needs VKMS there.
Right. Makes sense. I will add it then.
This check exists so we can call `crc32_le` for the entire line instead
doing it for each channel of each pixel in case `struct `pixel_argb_u16`
had any gap added by the compiler between the struct fields.
Oh the CRC computation. Good point.
Can you add a comment about that with the check?
Yeah, np.
I will copy the explanation above :)
+ return -EINVAL;
+
+ if (crtc_state->num_active_planes >= 1) {
+ act_plane = crtc_state->active_planes[0];
+ if (act_plane->base.base.plane->type == DRM_PLANE_TYPE_PRIMARY)
+ primary_plane_info = act_plane->frame_info;
After the next patch, do you even need the primary plane for anything
specifically?
Yeah, I will not need it anymore.
There is the map_is_null check below, but that should be
done on all planes in the array, right?
Yes, I guess so. And I don't know why it only checks for the
primary_plane TBH.
Maybe a left-over from times when it didn't have anything but a primary
plane?
Maybe.
Anyway, I have added this verification to all active planes in the next
version.
I suspect the next patch, or another patch in this series, should just
delete this chunk.
I should, and I will in the V6 of next patch.
}
+ if (!primary_plane_info)
+ return -EINVAL;
+
if (WARN_ON(dma_buf_map_is_null(_plane_info->map[0])))
return -EINVAL;
+ if (WARN_ON(check_format_funcs(crtc_state, active_wb)))
+ return -EINVAL;
+ line_width = drm_rect_width(_plane_info->dst);
+ stage_buffer.n_pixels = line_width;
+ output_buffer.n_pixels = line_width;
+ stage_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);
+ if (!stage_buffer.pixels) {
+ DRM_ERROR("Cannot allocate memory for the output line buffer");
+ return -ENOMEM;
+ }
+ output_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);
+ if (!output_buffer.pixels) {
+ DRM_ERROR("Cannot allocate memory for intermediate line
buffer");
+ ret = -ENOMEM;
+ goto free_stage_buffer;
+ }
+
+ if (active_wb) {
+ struct vkms_frame_info *wb_frame_info = _wb->frame_info;
+
+ wb_format = wb_frame_info->fb->format->format;
I don't see wb_format being used, is it?
This is probably a leftover from the last versions. Thanks for catching
it.
+ wb_frame_info->src = primary_plane_info->src;
+ wb_frame_info->dst = primary_plane_info->dst;
+ }
+
+ blend(active_wb, crtc_state, crc32, _buffer,
+ _buffer, (s64)line_width * pixel_size);
What's the (s64) doing here?
Are byte sizes not usually expressed with size_t or ssize_t types, or
is the kernel convention to use u64 and s64?
This makes me suspect that pixel_offset() and friends in vkms_format.c
are going to need fixing as well. int type overflows at 2G.
Yeah, I should be using size_t in all these places.
+
+
Re: [PATCH v5 9/9] drm: vkms: Add support to the RGB565 format
Hi Pekka,
On 4/21/22 07:58, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:15 -0300
Igor Torrente wrote:
Adds this common format to vkms.
This commit also adds new helper macros to deal with fixed-point
arithmetic.
It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.
V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_formats.c | 70 +++
drivers/gpu/drm/vkms/vkms_plane.c | 6 ++-
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +-
3 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 8d913fa7dbde..4af8b295f31e 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -5,6 +5,23 @@
#include "vkms_formats.h"
+/* The following macros help doing fixed point arithmetic. */
+/*
+ * With Fixed-Point scale 15 we have 17 and 15 bits of integer and fractional
+ * parts respectively.
+ * | 0.000 |
+ * 31 0
+ */
+#define FIXED_SCALE 15
I think this would usually be called a "shift" since it's used in
bit-shifts.
Ok, I will rename this.
+
+#define INT_TO_FIXED(a) ((a) << FIXED_SCALE)
+#define FIXED_MUL(a, b) ((s32)(((s64)(a) * (b)) >> FIXED_SCALE))
+#define FIXED_DIV(a, b) ((s32)(((s64)(a) << FIXED_SCALE) / (b)))
A truncating div, ok.
+/* This macro converts a fixed point number to int, and round half up it */
+#define FIXED_TO_INT_ROUND(a) (((a) + (1 << (FIXED_SCALE - 1))) >> FIXED_SCALE)
Yes.
+/* Convert divisor and dividend to Fixed-Point and performs the division */
+#define INT_TO_FIXED_DIV(a, b) (FIXED_DIV(INT_TO_FIXED(a), INT_TO_FIXED(b)))
Ok, this is obvious to read, even though it's the same as FIXED_DIV()
alone. Not sure the compiler would optimize that extra bit-shift away...
If one wanted to, it would be possible to write type-safe functions for
these so that fixed and integer could not be mixed up.
Ok, I will move to a function.
+
static int pixel_offset(const struct vkms_frame_info *frame_info, int x, int
y)
{
return frame_info->offset + (y * frame_info->pitch)
@@ -112,6 +129,30 @@ static void XRGB16161616_to_argb_u16(struct line_buffer
*stage_buffer,
}
}
+static void RGB565_to_argb_u16(struct line_buffer *stage_buffer,
+ const struct vkms_frame_info *frame_info, int y)
+{
+ struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x, x_limit = min_t(size_t, drm_rect_width(_info->dst),
+ stage_buffer->n_pixels);
+
+ for (x = 0; x < x_limit; x++, src_pixels++) {
+ u16 rgb_565 = le16_to_cpu(*src_pixels);
+ int fp_r = INT_TO_FIXED((rgb_565 >> 11) & 0x1f);
+ int fp_g = INT_TO_FIXED((rgb_565 >> 5) & 0x3f);
+ int fp_b = INT_TO_FIXED(rgb_565 & 0x1f);
+
+ int fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+ int fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
These two should be outside of the loop since they are constants.
Likely no difference for performance because the compiler is probably
doing that already, but I think it would read better.
I will move it.
+
+ out_pixels[x].a = (u16)0x;
+ out_pixels[x].r = FIXED_TO_INT_ROUND(FIXED_MUL(fp_r,
fp_rb_ratio));
+ out_pixels[x].g = FIXED_TO_INT_ROUND(FIXED_MUL(fp_g,
fp_g_ratio));
+ out_pixels[x].b = FIXED_TO_INT_ROUND(FIXED_MUL(fp_b,
fp_rb_ratio));
Looks good.
+ }
+}
+
/*
* The following functions take an line of argb_u16 pixels from the
@@ -199,6 +240,31 @@ static void argb_u16_to_XRGB16161616(struct
vkms_frame_info *frame_info,
}
}
+static void argb_u16_to_RGB565(struct vkms_frame_info *frame_info,
+ const struct line_buffer *src_buffer, int y)
+{
+ int x, x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
+ int x_limit = min_t(size_t, drm_rect_width(_info->dst),
+ src_buffer->n_pixels);
+
+ for (x = 0; x < x_limit; x++, dst_pixels++) {
+ int fp_r = INT_TO_FIXED(in_pixels[x].r);
+ int fp_g = INT_TO_FIXED(in_pixels[x].g);
+ int fp_b = INT_TO_FIXED(in_pixels[x].b);
+
+ int fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+ int fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
Move these out of the loop.
+
+ u16 r = FIXED_TO_INT_ROUND(FIXED_DIV(fp_r, fp_rb_ratio));
+ u16 g = FIXED_TO_INT_ROUND(FIXED_DIV(fp_g,
Re: [PATCH v5 5/9] drm: vkms: Add fb information to `vkms_writeback_job`
On 4/26/22 04:09, Pekka Paalanen wrote:
On Mon, 25 Apr 2022 21:56:12 -0300
Igor Torrente wrote:
Hi Pekka,
On 4/25/22 04:56, Pekka Paalanen wrote:
On Sat, 23 Apr 2022 12:12:51 -0300
Igor Torrente wrote:
Hi Pekka,
On 4/20/22 08:23, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:11 -0300
Igor Torrente wrote:
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_composer`
struct.
Hi,
should this be talking about vkms_frame_info struct instead?
Yes it should. I will fix this. Thanks.
Also adds two new function pointers (`{wb,plane}_format_transform_func`)
are defined to handle format conversion to/from internal format.
These things will allow us, in the future, to have different compositing
and wb format types.
V2: Change the code to get the drm_framebuffer reference and not copy its
contents(Thomas Zimmermann).
V3: Drop the refcount in the wb code(Thomas Zimmermann).
V5: Add {wb,plane}_format_transform_func to vkms_writeback_job
and vkms_plane_state (Pekka Paalanen)
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 31 +--
drivers/gpu/drm/vkms/vkms_plane.c | 10 -
drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++---
4 files changed, 49 insertions(+), 16 deletions(-)
...
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 2e6342164bef..2704cfb6904b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
...
+
+struct vkms_writeback_job {
+ struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
+ struct vkms_frame_info frame_info;
Which frame_info is this? Should the field be called wb_frame_info?
Considering it's already in the writeback_job struct do you think this
necessary?
This struct has 'data' too, and that is not the wb buffer, right?
AFAIU, no. Each plane has its own `iosys_map map[]`.
Hmm, if it's not the wb buffer, then using DRM_FORMAT_MAX_PLANES is
odd...
Yeah. I honestly don't have any clue why we have an array of `iosys_map`
for each plane, why we only use the map[0] and why we only call
`iosys_map_is_null` only to the `primary_composer`.
Maybe @tzimmermann or @rodrigosiqueiramelo can shed some light on these
questions.
Yeah, those questions would be really good to figure out.
FWIW, I can tell you this: "plane" has two different meanings in the
context of KMS:
https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/glossary.md#plane
DRM_FORMAT_MAX_PLANES refers to the number of planes (or the number of
memory buffers) for a single image (single framebuffer). Most often
with RGB there is just one plane in one memory buffer. RGB buffer could
be accompanied with e.g. a compression data buffer, so two planes,
one buffer each. Different YUV formats have different numbers of planes
from N=1 to 3, and those plane may be stored in 1 to N memory buffers
(with dmabuf handles pointing to them).
The number of planes and the number of memory buffers are often
conflated in APIs by just passing the same memory buffer multiple times
when multiple planes are stored in the same buffer (with different
offset).
The number of planes is determined by the pixel format and the format
modifier. The number of memory buffers is more... vaguely defined and
may vary sometimes.
Right. So probably this answers the first two questions. And also
probably my initial implementation of YUV420 and NV12 is wrong.
In other words, what kind of misudertanding do you think can happen if
this variable stay without the `wb_` prefix?
I spent a few minutes trying to find a case, but nothing came to my
mind.
My question above is the confusion.
If all these members are about the wb destination buffer only, then
where do the inputs come from and how are they reference-counted to
make sure they are available when needed?
Ok. Got it.
Thanks,
pq
[PATCH 3/4] drm/i915/huc: Prepare for GSC-loaded HuC
HuC loading via GSC is performed via a PXP command sent through the mei
modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
the GSC will do both the transfer and the authentication, the legacy HuC
loading paths can be safely skipped.
Also note that the GSC-loaded HuC survives GT reset.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 76 +++---
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 6 ++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 11 +++-
5 files changed, 88 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
index 66027a42cda9e..2516705b9f365 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
@@ -96,6 +96,7 @@
#define GUC_SHIM_CONTROL2 _MMIO(0xc068)
#define GUC_IS_PRIVILEGED(1<<29)
+#define GSC_LOADS_HUC(1<<30)
#define GUC_SEND_INTERRUPT _MMIO(0xc4c8)
#define GUC_SEND_TRIGGER (1<<0)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 773020e69589a..76a7df7f136fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,6 +6,7 @@
#include
#include "gt/intel_gt.h"
+#include "intel_guc_reg.h"
#include "intel_huc.h"
#include "i915_drv.h"
@@ -17,11 +18,15 @@
* capabilities by adding HuC specific commands to batch buffers.
*
* The kernel driver is only responsible for loading the HuC firmware and
- * triggering its security authentication, which is performed by the GuC. For
- * The GuC to correctly perform the authentication, the HuC binary must be
- * loaded before the GuC one. Loading the HuC is optional; however, not using
- * the HuC might negatively impact power usage and/or performance of media
- * workloads, depending on the use-cases.
+ * triggering its security authentication, which is performed by the GuC on
+ * older platforms and by the GSC on newer ones. For the GuC to correctly
+ * perform the authentication, the HuC binary must be loaded before the GuC
one.
+ * Loading the HuC is optional; however, not using the HuC might negatively
+ * impact power usage and/or performance of media workloads, depending on the
+ * use-cases.
+ * HuC must be reloaded on events that cause the WOPCM to lose its contents
+ * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on GuC/GT reset,
+ * while GSC-managed HuC will survive that.
*
* See https://github.com/intel/media-driver for the latest details on HuC
* functionality.
@@ -54,11 +59,51 @@ void intel_huc_init_early(struct intel_huc *huc)
}
}
+#define HUC_LOAD_MODE_STRING(x) (x ? "GSC" : "legacy")
+static int check_huc_loading_mode(struct intel_huc *huc)
+{
+ struct intel_gt *gt = huc_to_gt(huc);
+ bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
+ bool hw_uses_gsc = false;
+
+ /*
+* The fuse for HuC load via GSC is only valid on platforms that have
+* GuC deprivilege.
+*/
+ if (HAS_GUC_DEPRIVILEGE(gt->i915))
+ hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
+
+ if (fw_needs_gsc != hw_uses_gsc) {
+ drm_err(>i915->drm,
+ "mismatch between HuC FW (%s) and HW (%s) load modes\n",
+ HUC_LOAD_MODE_STRING(fw_needs_gsc),
+ HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ return -ENOEXEC;
+ }
+
+ /* make sure we can access the GSC via the mei driver if we need it */
+ if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
+ fw_needs_gsc) {
+ drm_info(>i915->drm,
+"Can't load HuC due to missing MEI modules\n");
+ return -EIO;
+ }
+
+ drm_dbg(>i915->drm, "GSC loads huc=%s\n", str_yes_no(fw_needs_gsc));
+
+ return 0;
+}
+
int intel_huc_init(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
int err;
+ err = check_huc_loading_mode(huc);
+ if (err)
+ goto out;
+
err = intel_uc_fw_init(>fw);
if (err)
goto out;
@@ -108,17 +153,20 @@ int intel_huc_auth(struct intel_huc *huc)
struct intel_guc *guc = >uc.guc;
int ret;
- GEM_BUG_ON(huc_is_authenticated(huc));
-
if (!intel_uc_fw_is_loaded(>fw))
return -ENOEXEC;
+ /* GSC will do the auth */
+ if (intel_huc_is_loaded_by_gsc(huc))
+ return -ENODEV;
+
ret = i915_inject_probe_error(gt->i915, -ENXIO);
if (ret)
goto fail;
- ret =
[PATCH 4/4] drm/i915/huc: Don't fail the probe if HuC init fails
The previous patch introduced new failure cases in the HuC init flow
that can be hit by simply changing the config, so we want to avoid
failing the probe in those scenarios. HuC load failure is already
considered a non-fatal error and we have a way to report to userspace
if the HuC is not available via a dedicated getparam, so no changes
in expectation there.
The error message in the HuC init code has also been lowered to info to
avoid throwing error message for an expected behavior.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 11 ++-
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 76a7df7f136fc..3d2e7a6d7c1b7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -113,7 +113,7 @@ int intel_huc_init(struct intel_huc *huc)
return 0;
out:
- i915_probe_error(i915, "failed with %d\n", err);
+ drm_info(>drm, "HuC init failed with %d\n", err);
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dce94f896a8c..ecf149c5fdb02 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -323,17 +323,10 @@ static int __uc_init(struct intel_uc *uc)
if (ret)
return ret;
- if (intel_uc_uses_huc(uc)) {
- ret = intel_huc_init(huc);
- if (ret)
- goto out_guc;
- }
+ if (intel_uc_uses_huc(uc))
+ intel_huc_init(huc);
return 0;
-
-out_guc:
- intel_guc_fini(guc);
- return ret;
}
static void __uc_fini(struct intel_uc *uc)
--
2.25.1
[PATCH 1/4] drm/i915/huc: check HW directly for HuC auth status
The huc_is_authenticated function return is based on our SW tracking of
the HuC auth status. However, around suspend/resume and reset this can
go out of sync with the actual HW state, which is why we use
huc_check_state() to look at the actual HW state. Instead of having this
duality, just make huc_is_authenticated() return the HW state and use it
everywhere we need to know if HuC is running.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 23 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 5 -
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 556829de9c172..773020e69589a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -80,6 +80,18 @@ void intel_huc_fini(struct intel_huc *huc)
intel_uc_fw_fini(>fw);
}
+static bool huc_is_authenticated(struct intel_huc *huc)
+{
+ struct intel_gt *gt = huc_to_gt(huc);
+ intel_wakeref_t wakeref;
+ u32 status = 0;
+
+ with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+ status = intel_uncore_read(gt->uncore, huc->status.reg);
+
+ return (status & huc->status.mask) == huc->status.value;
+}
+
/**
* intel_huc_auth() - Authenticate HuC uCode
* @huc: intel_huc structure
@@ -96,7 +108,7 @@ int intel_huc_auth(struct intel_huc *huc)
struct intel_guc *guc = >uc.guc;
int ret;
- GEM_BUG_ON(intel_huc_is_authenticated(huc));
+ GEM_BUG_ON(huc_is_authenticated(huc));
if (!intel_uc_fw_is_loaded(>fw))
return -ENOEXEC;
@@ -150,10 +162,6 @@ int intel_huc_auth(struct intel_huc *huc)
*/
int intel_huc_check_status(struct intel_huc *huc)
{
- struct intel_gt *gt = huc_to_gt(huc);
- intel_wakeref_t wakeref;
- u32 status = 0;
-
switch (__intel_uc_fw_status(>fw)) {
case INTEL_UC_FIRMWARE_NOT_SUPPORTED:
return -ENODEV;
@@ -167,10 +175,7 @@ int intel_huc_check_status(struct intel_huc *huc)
break;
}
- with_intel_runtime_pm(gt->uncore->rpm, wakeref)
- status = intel_uncore_read(gt->uncore, huc->status.reg);
-
- return (status & huc->status.mask) == huc->status.value;
+ return huc_is_authenticated(huc);
}
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 73ec670800f2b..77d813840d76c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -50,11 +50,6 @@ static inline bool intel_huc_is_used(struct intel_huc *huc)
return intel_uc_fw_is_available(>fw);
}
-static inline bool intel_huc_is_authenticated(struct intel_huc *huc)
-{
- return intel_uc_fw_is_running(>fw);
-}
-
void intel_huc_load_status(struct intel_huc *huc, struct drm_printer *p);
#endif
--
2.25.1
[PATCH 2/4] drm/i915/huc: Add fetch support for gsc-loaded HuC binary
On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
HuC loading has been moved from the GuC to the GSC. As part of the
change, the header format of the HuC binary has been updated and does not
match the GuC anymore. The GSC will perform all the required checks on
the binary size, so we only need to check that the version matches.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 99
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 9 ++
3 files changed, 72 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index cb5dd16421d0d..8d602d87a7295 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -301,45 +301,31 @@ static void __force_fw_fetch_failures(struct intel_uc_fw
*uc_fw, int e)
}
}
-/**
- * intel_uc_fw_fetch - fetch uC firmware
- * @uc_fw: uC firmware
- *
- * Fetch uC firmware into GEM obj.
- *
- * Return: 0 on success, a negative errno code on failure.
- */
-int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
+static int check_gsc_manifest(const struct firmware *fw,
+ struct intel_uc_fw *uc_fw)
{
- struct drm_i915_private *i915 = __uc_fw_to_gt(uc_fw)->i915;
- struct device *dev = i915->drm.dev;
- struct drm_i915_gem_object *obj;
- const struct firmware *fw = NULL;
- struct uc_css_header *css;
- size_t size;
- int err;
+ u32 *dw = (u32 *)fw->data;
+ u32 version = dw[HUC_GSC_VERSION_DW];
- GEM_BUG_ON(!i915->wopcm.size);
- GEM_BUG_ON(!intel_uc_fw_is_enabled(uc_fw));
-
- err = i915_inject_probe_error(i915, -ENXIO);
- if (err)
- goto fail;
+ uc_fw->major_ver_found = FIELD_GET(HUC_GSC_MAJOR_VER_MASK, version);
+ uc_fw->minor_ver_found = FIELD_GET(HUC_GSC_MINOR_VER_MASK, version);
- __force_fw_fetch_failures(uc_fw, -EINVAL);
- __force_fw_fetch_failures(uc_fw, -ESTALE);
+ return 0;
+}
- err = request_firmware(, uc_fw->path, dev);
- if (err)
- goto fail;
+static int check_ccs_header(struct drm_i915_private *i915,
+ const struct firmware *fw,
+ struct intel_uc_fw *uc_fw)
+{
+ struct uc_css_header *css;
+ size_t size;
/* Check the size of the blob before examining buffer contents */
if (unlikely(fw->size < sizeof(struct uc_css_header))) {
drm_warn(>drm, "%s firmware %s: invalid size: %zu <
%zu\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
fw->size, sizeof(struct uc_css_header));
- err = -ENODATA;
- goto fail;
+ return -ENODATA;
}
css = (struct uc_css_header *)fw->data;
@@ -352,8 +338,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
"%s firmware %s: unexpected header size: %zu != %zu\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
fw->size, sizeof(struct uc_css_header));
- err = -EPROTO;
- goto fail;
+ return -EPROTO;
}
/* uCode size must calculated from other sizes */
@@ -368,8 +353,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
drm_warn(>drm, "%s firmware %s: invalid size: %zu <
%zu\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
fw->size, size);
- err = -ENOEXEC;
- goto fail;
+ return -ENOEXEC;
}
/* Sanity check whether this fw is not larger than whole WOPCM memory */
@@ -378,8 +362,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
drm_warn(>drm, "%s firmware %s: invalid size: %zu >
%zu\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
size, (size_t)i915->wopcm.size);
- err = -E2BIG;
- goto fail;
+ return -E2BIG;
}
/* Get version numbers from the CSS header */
@@ -388,6 +371,49 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
uc_fw->minor_ver_found = FIELD_GET(CSS_SW_VERSION_UC_MINOR,
css->sw_version);
+ if (uc_fw->type == INTEL_UC_FW_TYPE_GUC)
+ uc_fw->private_data_size = css->private_data_size;
+
+ return 0;
+}
+
+/**
+ * intel_uc_fw_fetch - fetch uC firmware
+ * @uc_fw: uC firmware
+ *
+ * Fetch uC firmware into GEM obj.
+ *
+ * Return: 0 on success, a negative errno code on failure.
+ */
+int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
+{
+ struct drm_i915_private *i915 = __uc_fw_to_gt(uc_fw)->i915;
+ struct device *dev = i915->drm.dev;
+
[PATCH 0/4] drm/i915: Prepare for GSC-loaded HuC
On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of HuC loading and authentication has been moved from the GuC to the GSC, with both actions being performed via a single PXP command. Given that the mei code has not fully landed yet (see [1]), we can't implement the new load mechanism, but we can start getting ready for it by taking care of the changes required for the existing code: - The HuC header is now different from the GuC one. This also means that if the FW is for GSC-loading and the HW fuse is set to legacy load (or vice-versa) we can't load the HuC. - To send a PXP message to the GSC we need both MEI_GSC and MEI_PXP. - All legacy HuC loading paths can be skipped. Note that the HuC fw version for DG2 is still not defined, so the HuC code will be skipped until the define is added. [1] https://patchwork.freedesktop.org/series/102339/ Cc: Alan Previn Cc: John Harrison Daniele Ceraolo Spurio (4): drm/i915/huc: check HW directly for HuC auth status drm/i915/huc: Add fetch support for gsc-loaded HuC binary drm/i915/huc: Prepare for GSC-loaded HuC drm/i915/huc: Don't fail the probe if HuC init fails drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_huc.c | 97 +++ drivers/gpu/drm/i915/gt/uc/intel_huc.h | 5 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c| 5 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c| 22 +++-- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 99 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 9 ++ 8 files changed, 172 insertions(+), 68 deletions(-) -- 2.25.1
Re: [PATCH] gpu: drm: remove redundant dma_fence_put() when drm_sched_job_add_dependency() fails
On 2022-04-25 22:54, Hangyu Hua wrote:
On 2022/4/25 23:42, Andrey Grodzovsky wrote:
On 2022-04-25 04:36, Hangyu Hua wrote:
When drm_sched_job_add_dependency() fails, dma_fence_put() will be
called
internally. Calling it again after drm_sched_job_add_dependency()
finishes
may result in a dangling pointer.
Fix this by removing redundant dma_fence_put().
Signed-off-by: Hangyu Hua
---
drivers/gpu/drm/lima/lima_gem.c | 1 -
drivers/gpu/drm/scheduler/sched_main.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_gem.c
b/drivers/gpu/drm/lima/lima_gem.c
index 55bb1ec3c4f7..99c8e7f6bb1c 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -291,7 +291,6 @@ static int lima_gem_add_deps(struct drm_file
*file, struct lima_submit *submit)
err = drm_sched_job_add_dependency(>task->base,
fence);
if (err) {
- dma_fence_put(fence);
return err;
Makes sense here
}
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index b81fceb0b8a2..ebab9eca37a8 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -708,7 +708,6 @@ int
drm_sched_job_add_implicit_dependencies(struct drm_sched_job *job,
dma_fence_get(fence);
ret = drm_sched_job_add_dependency(job, fence);
if (ret) {
- dma_fence_put(fence);
Not sure about this one since if you look at the relevant commits -
'drm/scheduler: fix drm_sched_job_add_implicit_dependencies' and
'drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder'
You will see that the dma_fence_put here balances the extra
dma_fence_get
above
Andrey
I don't think so. I checked the call chain and found no additional
dma_fence_get(). But dma_fence_get() needs to be called before
drm_sched_job_add_dependency() to keep the counter balanced.
I didn't say there is an additional dma_fence_get , from what I
understand here drm_sched_job_add_implicit_dependencies->dma_fence_get
is not balancing any counter but rather grabs an extra reference to
account for adding the fence to the job's dependency array, and so when
adding fails then you call dma_fence_put to decrement the count back.
This makes sense because drm_sched_job_add_dependency doesn't increment
himself refcount for the fences
On the other hand, dma_fence_get() and dma_fence_put() are meaningless
here if threre is an extra dma_fence_get() beacause counter will not
decrease to 0 during drm_sched_job_add_dependency().
Where is the extra dma_fence_get() ?
I check the call chain as follows:
msm_ioctl_gem_submit()
-> submit_fence_sync()
-> drm_sched_job_add_implicit_dependencies()
Could you maybe print the buggy refcount sequence you say you discovered
as an example ? Because I fail to follow where is the problem.
Andrey
Thanks,
Hangyu
return ret;
}
}
Re: [PATCH 1/2] drm/probe-helper: Add helper for drm_helper_probe_single_connector_modes()
On 4/26/2022 11:46 AM, Douglas Anderson wrote:
The drm_helper_probe_single_connector_modes() is a bit long. Let's
break a chunk off to update and validate modes. This helps avoid one
goto and also will allow us to more easily call the helper a second
time in a future patch without adding looping or another goto.
This change is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson
I think this cleanup looks reasonable to me.
Hence,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/drm_probe_helper.c | 105 -
1 file changed, 59 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 682359512996..819225629010 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -354,6 +354,61 @@ drm_helper_probe_detect(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_helper_probe_detect);
+static bool _drm_helper_update_and_validate(struct drm_connector *connector,
+ uint32_t maxX, uint32_t maxY,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_display_mode *mode;
+ int mode_flags = 0;
+ int ret;
+
+ drm_connector_list_update(connector);
+
+ if (connector->interlace_allowed)
+ mode_flags |= DRM_MODE_FLAG_INTERLACE;
+ if (connector->doublescan_allowed)
+ mode_flags |= DRM_MODE_FLAG_DBLSCAN;
+ if (connector->stereo_allowed)
+ mode_flags |= DRM_MODE_FLAG_3D_MASK;
+
+ list_for_each_entry(mode, >modes, head) {
+ if (mode->status != MODE_OK)
+ continue;
+
+ mode->status = drm_mode_validate_driver(dev, mode);
+ if (mode->status != MODE_OK)
+ continue;
+
+ mode->status = drm_mode_validate_size(mode, maxX, maxY);
+ if (mode->status != MODE_OK)
+ continue;
+
+ mode->status = drm_mode_validate_flag(mode, mode_flags);
+ if (mode->status != MODE_OK)
+ continue;
+
+ ret = drm_mode_validate_pipeline(mode, connector, ctx,
+>status);
+ if (ret) {
+ drm_dbg_kms(dev,
+ "drm_mode_validate_pipeline failed: %d\n",
+ ret);
+
+ if (drm_WARN_ON_ONCE(dev, ret != -EDEADLK))
+ mode->status = MODE_ERROR;
+ else
+ return true;
+ }
+
+ if (mode->status != MODE_OK)
+ continue;
+ mode->status = drm_mode_validate_ycbcr420(mode, connector);
+ }
+
+ return false;
+}
+
/**
* drm_helper_probe_single_connector_modes - get complete set of display modes
* @connector: connector to probe
@@ -421,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int count = 0, ret;
- int mode_flags = 0;
bool verbose_prune = true;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
@@ -519,52 +573,11 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
connector->status == connector_status_unknown))
count = drm_add_modes_noedid(connector, 1024, 768);
count += drm_helper_probe_add_cmdline_mode(connector);
- if (count == 0)
- goto prune;
-
- drm_connector_list_update(connector);
-
- if (connector->interlace_allowed)
- mode_flags |= DRM_MODE_FLAG_INTERLACE;
- if (connector->doublescan_allowed)
- mode_flags |= DRM_MODE_FLAG_DBLSCAN;
- if (connector->stereo_allowed)
- mode_flags |= DRM_MODE_FLAG_3D_MASK;
-
- list_for_each_entry(mode, >modes, head) {
- if (mode->status != MODE_OK)
- continue;
-
- mode->status = drm_mode_validate_driver(dev, mode);
- if (mode->status != MODE_OK)
- continue;
-
- mode->status = drm_mode_validate_size(mode, maxX, maxY);
- if (mode->status != MODE_OK)
- continue;
-
- mode->status = drm_mode_validate_flag(mode, mode_flags);
- if (mode->status != MODE_OK)
- continue;
-
- ret = drm_mode_validate_pipeline(mode, connector, ,
->status);
- if (ret) {
- drm_dbg_kms(dev,
-
Re: [RFC v2 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc
On Mon, Apr 25, 2022 at 12:16:11PM +0530, Bhanuprakash Modem wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces helpers to attach and set "vrr_enabled" property
> on the crtc to allow userspace to query VRR enabled status on that crtc.
>
> Atomic drivers should attach this property to crtcs those are capable of
> driving variable refresh rates using
> drm_mode_crtc_attach_vrr_enabled_property().
>
> The value should be updated based on driver and hardware capability
> by using drm_mode_crtc_set_vrr_enabled_property().
>
> V2: Use property flag as atomic
We already have userspace making us of the CRTC vrr_enabled property to
enable VRR for the CRTC like in case of full screen gaming.
This can already be done through:
drm_atomic_crtc_set_property call. Why do we need additonal helpers
for setting the same per CRTC property?
This is a default CRTC property so it will be created annd attached for
CRTC as per the DRM doc:
"VRR_ENABLED":
* Default _crtc boolean property that notifies the driver that the
* content on the CRTC is suitable for variable refresh rate presentation.
* The driver will take this property as a hint to enable variable
* refresh rate support if the receiver supports it, ie. if the
* "vrr_capable" property is true on the _connector object. The
* vertical front porch duration will be extended until page-flip or
* timeout when enabled.
Then we can use the atomic_crtc_set/get_property helpers to set it
Am I missing some other use case here?
Manasi
>
> Cc: Ville Syrjälä
> Cc: Nicholas Kazlauskas
> Cc: Manasi Navare
> Cc: Harry Wentland
> Signed-off-by: Bhanuprakash Modem
> ---
> drivers/gpu/drm/drm_crtc.c| 44 +++
> drivers/gpu/drm/drm_mode_config.c | 2 +-
> include/drm/drm_crtc.h| 4 +++
> 3 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 26a77a735905..95b4a0c7ecb3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -883,3 +883,47 @@ int drm_crtc_create_scaling_filter_property(struct
> drm_crtc *crtc,
> return 0;
> }
> EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
> +
> +/**
> + * drm_mode_crtc_attach_vrr_enabled_property - attaches the vrr_enabled
> property
> + * @crtc: drm CRTC to attach the vrr_enabled property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * VRR enabled status for a crtc.
> + */
> +void drm_mode_crtc_attach_vrr_enabled_property(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (!config->prop_vrr_enabled)
> + return;
> +
> + drm_object_attach_property(>base,
> +config->prop_vrr_enabled,
> +0);
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_attach_vrr_enabled_property);
> +
> +/**
> + * drm_mode_crtc_set_vrr_enabled_property - sets the vrr enabled property for
> + * a crtc.
> + * @crtc: drm CRTC
> + * @vrr_enabled: True to enable the VRR on CRTC
> + *
> + * Should be used by atomic drivers to update the VRR enabled status on a
> CRTC
> + */
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
> + bool vrr_enabled)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (!config->prop_vrr_enabled)
> + return;
> +
> + drm_object_property_set_value(>base,
> + config->prop_vrr_enabled,
> + vrr_enabled);
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_set_vrr_enabled_property);
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index 37b4b9f0e468..b7cde73d5586 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -323,7 +323,7 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_mode_id = prop;
>
> - prop = drm_property_create_bool(dev, 0,
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> "VRR_ENABLED");
> if (!prop)
> return -ENOMEM;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a70baea0636c..bde657cb0f9e 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1333,4 +1333,8 @@ static inline struct drm_crtc *drm_crtc_find(struct
> drm_device *dev,
> int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
> unsigned int supported_filters);
>
> +void drm_mode_crtc_attach_vrr_enabled_property(struct drm_crtc *crtc);
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
Re: [PATCH] drm/msm/disp/dpu1: avoid clearing hw interrupts if hw_intr is null during drm uninit
Quoting Vinod Polimera (2022-04-25 23:02:11)
> Avoid clearing irqs and derefernce hw_intr when hw_intr is null.
Presumably this is only the case when the display driver doesn't fully
probe and something probe defers? Can you clarify how this situation
happens?
>
> BUG: Unable to handle kernel NULL pointer dereference at virtual address
>
>
> Call trace:
> dpu_core_irq_uninstall+0x50/0xb0
> dpu_irq_uninstall+0x18/0x24
> msm_drm_uninit+0xd8/0x16c
> msm_drm_bind+0x580/0x5fc
> try_to_bring_up_master+0x168/0x1c0
> __component_add+0xb4/0x178
> component_add+0x1c/0x28
> dp_display_probe+0x38c/0x400
> platform_probe+0xb0/0xd0
> really_probe+0xcc/0x2c8
> __driver_probe_device+0xbc/0xe8
> driver_probe_device+0x48/0xf0
> __device_attach_driver+0xa0/0xc8
> bus_for_each_drv+0x8c/0xd8
> __device_attach+0xc4/0x150
> device_initial_probe+0x1c/0x28
>
> Fixes: a73033619ea ("drm/msm/dpu: squash dpu_core_irq into dpu_hw_interrupts")
The fixes tag looks odd. In dpu_core_irq_uninstall() at that commit it
is dealing with 'irq_obj' which isn't a pointer. After commit
f25f656608e3 ("drm/msm/dpu: merge struct dpu_irq into struct
dpu_hw_intr") dpu_core_irq_uninstall() starts using 'hw_intr' which is
allocated on the heap. If we backported this patch to a place that had
a73033619ea without f25f656608e3 it wouldn't make any sense.
> Signed-off-by: Vinod Polimera
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> index c515b7c..ab28577 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> @@ -599,6 +599,9 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
> {
> int i;
>
> + if (!dpu_kms->hw_intr)
> + return;
> +
> pm_runtime_get_sync(_kms->pdev->dev);
> for (i = 0; i < dpu_kms->hw_intr->total_irqs; i++)
Re: [PATCH v2] drm: rcar-du: Fix Alpha blending issue on Gen3
Hi Biju, Thank you for the patch. On Tue, Apr 26, 2022 at 09:41:57AM +0100, Biju Das wrote: > From: LUU HOAI > > As per R-Car-Gen3_Common_OPC_Customer_Notifications_V30.1.pdf, > unexpected image output(such as incorrect colors or planes being > invisible) can happen on the below conditions, as PnALPHAR register > is not initialized by reset. > > When alpha blending (PpMRm.PpSPIM=0b101) is performed and: > •two Planes are enabled on any DUn (n=0,1,2,3) > oDSPRn= 0x 0031 or 0x 0013 > •or DU0 and DU1 is used for display at the same time > oDSPR0= 0x 0001 and DSPR1= 0x 0003 > oDSPR0= 0x 0003 and DSPR1= 0x 0001 > •or DU2 and DU3(H3 Only) is used for display at the same time > oDSPR2= 0x 0001 and DSPR3= 0x 0003 > oDSPR2= 0x 0003 and DSPR3= 0x 0001 > > This patch set PnALPHAR register to 0 to avoid this issue. > > Signed-off-by: LUU HOAI > Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart > --- > v1->v2: > * Updated commit description > * Updated the code comments > --- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > index f214a8b6cfd3..aa80c44dd8d7 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > @@ -510,6 +510,18 @@ static void rcar_du_plane_setup_format_gen3(struct > rcar_du_group *rgrp, > > rcar_du_plane_write(rgrp, index, PnDDCR4, > state->format->edf | PnDDCR4_CODE); > + > + /* > + * On Gen3, some DU channels have two planes, each being wired to a > + * separate VSPD instance. The DU can then blend two planes. While > + * this feature isn't used by the driver, issues related to alpha > + * blending (such as incorrect colors or planes being invisible) may > + * still occur if the PnALPHAR register has a stale value. Set the > + * register to 0 to avoid this. > + */ > + > + /* TODO: Check if alpha-blending should be disabled in PnMR. */ > + rcar_du_plane_write(rgrp, index, PnALPHAR, 0); > } > > static void rcar_du_plane_setup_format(struct rcar_du_group *rgrp, -- Regards, Laurent Pinchart
Re: [PATCH v6] drm/msm/dp: remove fail safe mode related code
Hi,
On Tue, Apr 26, 2022 at 2:12 PM Kuogee Hsieh wrote:
>
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
> is executed under drm_thread context.
>
> After review all possibilities methods and as discussed on
> https://patchwork.freedesktop.org/patch/483155/, supporting EDID
> compliance tests in the driver is quite hacky. As seen with other
> vendor drivers, supporting these will be much easier with IGT. Hence
> removing all the related fail safe code for it so that no possibility
> of circular lock will happen.
>
> ==
> WARNING: possible circular locking dependency detected
> 5.15.35-lockdep #6 Tainted: GW
> --
> frecon/429 is trying to acquire lock:
> ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
> dp_panel_add_fail_safe_mode+0x4c/0xa0
>
> but task is already holding lock:
> ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at:
> lock_crtcs+0xb4/0x124
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (>commit_lock[i]){+.+.}-{3:3}:
> __mutex_lock_common+0x174/0x1a64
> mutex_lock_nested+0x98/0xac
> lock_crtcs+0xb4/0x124
> msm_atomic_commit_tail+0x330/0x748
> commit_tail+0x19c/0x278
> drm_atomic_helper_commit+0x1dc/0x1f0
> drm_atomic_commit+0xc0/0xd8
> drm_atomic_helper_set_config+0xb4/0x134
> drm_mode_setcrtc+0x688/0x1248
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> -> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
> __mutex_lock_common+0x174/0x1a64
> ww_mutex_lock+0xb8/0x278
> modeset_lock+0x304/0x4ac
> drm_modeset_lock+0x4c/0x7c
> drmm_mode_config_init+0x4a8/0xc50
> msm_drm_init+0x274/0xac0
> msm_drm_bind+0x20/0x2c
> try_to_bring_up_master+0x3dc/0x470
> __component_add+0x18c/0x3c0
> component_add+0x1c/0x28
> dp_display_probe+0x954/0xa98
> platform_probe+0x124/0x15c
> really_probe+0x1b0/0x5f8
> __driver_probe_device+0x174/0x20c
> driver_probe_device+0x70/0x134
> __device_attach_driver+0x130/0x1d0
> bus_for_each_drv+0xfc/0x14c
> __device_attach+0x1bc/0x2bc
> device_initial_probe+0x1c/0x28
> bus_probe_device+0x94/0x178
> deferred_probe_work_func+0x1a4/0x1f0
> process_one_work+0x5d4/0x9dc
> worker_thread+0x898/0xccc
> kthread+0x2d4/0x3d4
> ret_from_fork+0x10/0x20
>
> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> ww_acquire_init+0x1c4/0x2c8
> drm_modeset_acquire_init+0x44/0xc8
> drm_helper_probe_single_connector_modes+0xb0/0x12dc
> drm_mode_getconnector+0x5dc/0xfe8
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> -> #0 (>mode_config.mutex){+.+.}-{3:3}:
> __lock_acquire+0x2650/0x672c
> lock_acquire+0x1b4/0x4ac
> __mutex_lock_common+0x174/0x1a64
> mutex_lock_nested+0x98/0xac
> dp_panel_add_fail_safe_mode+0x4c/0xa0
> dp_hpd_plug_handle+0x1f0/0x280
> dp_bridge_enable+0x94/0x2b8
> drm_atomic_bridge_chain_enable+0x11c/0x168
> drm_atomic_helper_commit_modeset_enables+0x500/0x740
> msm_atomic_commit_tail+0x3e4/0x748
> commit_tail+0x19c/0x278
> drm_atomic_helper_commit+0x1dc/0x1f0
> drm_atomic_commit+0xc0/0xd8
> drm_atomic_helper_set_config+0xb4/0x134
> drm_mode_setcrtc+0x688/0x1248
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> Changes in v2:
> -- re text commit title
> -- remove all fail safe mode
>
> Changes in v3:
> -- remove dp_panel_add_fail_safe_mode() from dp_panel.h
> -- add Fixes
>
> Changes in v5:
> -- to=diand...@chromium.org
>
> Changes in v6:
> -- fix Fixes commit ID
>
> Fixes: 8b2c181e3dcf ("drm/msm/dp: add fail safe mode outside
Re: [RFC PATCH] drm/edid: drm_add_modes_noedid() should set lowest resolution as preferred
On 4/26/2022 1:52 PM, Doug Anderson wrote: Hi, On Tue, Apr 26, 2022 at 1:46 PM Abhinav Kumar wrote: On 4/26/2022 1:21 PM, Douglas Anderson wrote: If we're unable to read the EDID for a display because it's corrupt / bogus / invalid then we'll add a set of standard modes for the display. When userspace looks at these modes it doesn't really have a good concept for which mode to pick and it'll likely pick the highest resolution one by default. That's probably not ideal because the modes were purely guesses on the part of the Linux kernel. Let's instead set 640x480 as the "preferred" mode when we have no EDID. Signed-off-by: Douglas Anderson drm_dmt_modes array is sorted but you are also relying on this check to eliminate the non-60fps modes 5611if (drm_mode_vrefresh(ptr) > 61) 5612continue; I am not sure why we filter out the modes > 61 vrefresh. If that check will remain this is okay. If its not, its not reliable that the first mode will be 640x480@60 I suspect that the check will remain. I guess I could try to do something fancier if people want, but I'd be interested in _what_ fancier thing I should do if so. Do we want the rule to remain that we always prefer 640x480, or do we want to prefer the lowest resolution? ...do we want to prefer 60 Hz or the lowest refresh rate? Do we do this only for DP (which explicitly calls out 640x480 @60Hz as the best failsafe) or for everything? For now, the way it's coded up seems reasonable (to me). It's the lowest resolution _and_ it's 640x480 just because of the current values of the table. I suspect that extra lower resolution failsafe modes won't be added, but we can always change the rules here if/when they are. -Doug Alright, agreed. The way the API is today, I dont see anything getting broken with this. So typically, as per spec, when a preferred mode is not set by the sink, the first entry becomes the preferred mode. This also aligns with that expectation. So FWIW, Reviewed-by: Abhinav Kumar We will test this one also out with our equipment, then give tested-by tags. Thanks Abhinav
Re: [PATCH v6] drm/msm/dp: remove fail safe mode related code
Quoting Kuogee Hsieh (2022-04-26 14:12:14)
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
[...]
>
> Changes in v6:
> -- fix Fixes commit ID
>
> Fixes: 8b2c181e3dcf ("drm/msm/dp: add fail safe mode outside of event_mutex
> context")
> Reported-by: Douglas Anderson
> Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Re: [PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
Hi,
On Tue, Apr 26, 2022 at 2:11 PM Abhinav Kumar wrote:
>
>
>
> On 4/26/2022 1:26 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Apr 26, 2022 at 12:20 PM Abhinav Kumar
> > wrote:
> >>
> >> Missed one more comment.
> >>
> >> On 4/26/2022 12:16 PM, Abhinav Kumar wrote:
> >>> Hi Doug
> >>>
> >>> One minor comment below.
> >>>
> >>> But otherwise, looking at this change this should work for us acc to me.
> >>>
> >>> We will test this out with our equipment and then provide R-b.
> >>>
> >>> Thanks
> >>>
> >>> Abhinav
> >>> On 4/26/2022 11:46 AM, Douglas Anderson wrote:
> As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
> that all detachable sinks shall support 640x480 @60Hz as a fail safe
> mode.
>
> A DP compliance test expected us to utilize the above fact when all
> modes it presented to the DP source were not achievable. It presented
> only modes that would be achievable with more lanes and/or higher
> speeds than we had available and expected that when we couldn't do
> that then we'd fall back to 640x480 even though it didn't advertise
> this size.
>
> In order to pass the compliance test (and also support any users who
> might fall into a similar situation with their display), we need to
> add 640x480 into the list of modes. However, we don't want to add
> 640x480 all the time. Despite the fact that the DP spec says all sinks
> _shall support_ 640x480, they're not guaranteed to support it
> _well_. Continuing to read the spec you can see that the display is
> not required to really treat 640x480 equal to all the other modes. It
> doesn't need to scale or anything--just display the pixels somehow for
> failsafe purposes. It should also be noted that it's not hard to find
> a display hooked up via DisplayPort that _doesn't_ support 640x480 at
> all. The HP ZR30w screen I'm sitting in front of has a native DP port
> and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
> display via a DP to HDMI adapter and that screen definitely doesn't
> support 640x480.
>
> As a compromise solution, let's only add the 640x480 mode if:
> * We're on DP.
> * All other modes have been pruned.
>
> This acknowledges that 640x480 might not be the best mode to use but,
> since sinks are _supposed_ to support it, we will at least fall back
> to it if there's nothing else.
>
> Note that we _don't_ add higher resolution modes like 1024x768 in this
> case. We only add those modes for a failed EDID read where we have no
> idea what's going on. In the case where we've pruned all modes then
> instead we only want 640x480 which is the only defined "Fail Safe"
> resolution.
>
> This patch originated in response to Kuogee Hsieh's patch [1].
>
> [1]
> https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
>
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/drm_probe_helper.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 819225629010..90cd46cbfec1 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> const struct drm_connector_helper_funcs *connector_funcs =
> connector->helper_private;
> int count = 0, ret;
> -bool verbose_prune = true;
> enum drm_connector_status old_status;
> struct drm_modeset_acquire_ctx ctx;
> @@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> connector->base.id, connector->name);
> drm_connector_update_edid_property(connector, NULL);
> -verbose_prune = false;
> -goto prune;
> +drm_mode_prune_invalid(dev, >modes, false);
> +goto exit;
> }
> count = (*connector_funcs->get_modes)(connector);
> @@ -580,9 +579,26 @@ int
> drm_helper_probe_single_connector_modes(struct drm_connector *connector,
> }
> }
> -prune:
> -drm_mode_prune_invalid(dev, >modes, verbose_prune);
> +drm_mode_prune_invalid(dev, >modes, true);
> +/*
> + * Displayport spec section 5.2.1.2 ("Video Timing Format") says
> that
> + * all detachable sinks shall support 640x480 @60Hz as a fail safe
> + * mode. If all modes were pruned, perhaps because they need more
> + * lanes or a higher pixel
[PATCH v6] drm/msm/dp: remove fail safe mode related code
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is executed under drm_thread context.
After review all possibilities methods and as discussed on
https://patchwork.freedesktop.org/patch/483155/, supporting EDID
compliance tests in the driver is quite hacky. As seen with other
vendor drivers, supporting these will be much easier with IGT. Hence
removing all the related fail safe code for it so that no possibility
of circular lock will happen.
==
WARNING: possible circular locking dependency detected
5.15.35-lockdep #6 Tainted: GW
--
frecon/429 is trying to acquire lock:
ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
dp_panel_add_fail_safe_mode+0x4c/0xa0
but task is already holding lock:
ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at: lock_crtcs+0xb4/0x124
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (>commit_lock[i]){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
lock_crtcs+0xb4/0x124
msm_atomic_commit_tail+0x330/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
ww_mutex_lock+0xb8/0x278
modeset_lock+0x304/0x4ac
drm_modeset_lock+0x4c/0x7c
drmm_mode_config_init+0x4a8/0xc50
msm_drm_init+0x274/0xac0
msm_drm_bind+0x20/0x2c
try_to_bring_up_master+0x3dc/0x470
__component_add+0x18c/0x3c0
component_add+0x1c/0x28
dp_display_probe+0x954/0xa98
platform_probe+0x124/0x15c
really_probe+0x1b0/0x5f8
__driver_probe_device+0x174/0x20c
driver_probe_device+0x70/0x134
__device_attach_driver+0x130/0x1d0
bus_for_each_drv+0xfc/0x14c
__device_attach+0x1bc/0x2bc
device_initial_probe+0x1c/0x28
bus_probe_device+0x94/0x178
deferred_probe_work_func+0x1a4/0x1f0
process_one_work+0x5d4/0x9dc
worker_thread+0x898/0xccc
kthread+0x2d4/0x3d4
ret_from_fork+0x10/0x20
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
ww_acquire_init+0x1c4/0x2c8
drm_modeset_acquire_init+0x44/0xc8
drm_helper_probe_single_connector_modes+0xb0/0x12dc
drm_mode_getconnector+0x5dc/0xfe8
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #0 (>mode_config.mutex){+.+.}-{3:3}:
__lock_acquire+0x2650/0x672c
lock_acquire+0x1b4/0x4ac
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
dp_panel_add_fail_safe_mode+0x4c/0xa0
dp_hpd_plug_handle+0x1f0/0x280
dp_bridge_enable+0x94/0x2b8
drm_atomic_bridge_chain_enable+0x11c/0x168
drm_atomic_helper_commit_modeset_enables+0x500/0x740
msm_atomic_commit_tail+0x3e4/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
Changes in v2:
-- re text commit title
-- remove all fail safe mode
Changes in v3:
-- remove dp_panel_add_fail_safe_mode() from dp_panel.h
-- add Fixes
Changes in v5:
-- to=diand...@chromium.org
Changes in v6:
-- fix Fixes commit ID
Fixes: 8b2c181e3dcf ("drm/msm/dp: add fail safe mode outside of event_mutex
context")
Reported-by: Douglas Anderson
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 --
drivers/gpu/drm/msm/dp/dp_panel.c | 11 ---
drivers/gpu/drm/msm/dp/dp_panel.h | 1 -
3 files changed, 18 deletions(-)
diff --git
Re: [PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
On 4/26/2022 1:26 PM, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 12:20 PM Abhinav Kumar
wrote:
Missed one more comment.
On 4/26/2022 12:16 PM, Abhinav Kumar wrote:
Hi Doug
One minor comment below.
But otherwise, looking at this change this should work for us acc to me.
We will test this out with our equipment and then provide R-b.
Thanks
Abhinav
On 4/26/2022 11:46 AM, Douglas Anderson wrote:
As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a fail safe
mode.
A DP compliance test expected us to utilize the above fact when all
modes it presented to the DP source were not achievable. It presented
only modes that would be achievable with more lanes and/or higher
speeds than we had available and expected that when we couldn't do
that then we'd fall back to 640x480 even though it didn't advertise
this size.
In order to pass the compliance test (and also support any users who
might fall into a similar situation with their display), we need to
add 640x480 into the list of modes. However, we don't want to add
640x480 all the time. Despite the fact that the DP spec says all sinks
_shall support_ 640x480, they're not guaranteed to support it
_well_. Continuing to read the spec you can see that the display is
not required to really treat 640x480 equal to all the other modes. It
doesn't need to scale or anything--just display the pixels somehow for
failsafe purposes. It should also be noted that it's not hard to find
a display hooked up via DisplayPort that _doesn't_ support 640x480 at
all. The HP ZR30w screen I'm sitting in front of has a native DP port
and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
display via a DP to HDMI adapter and that screen definitely doesn't
support 640x480.
As a compromise solution, let's only add the 640x480 mode if:
* We're on DP.
* All other modes have been pruned.
This acknowledges that 640x480 might not be the best mode to use but,
since sinks are _supposed_ to support it, we will at least fall back
to it if there's nothing else.
Note that we _don't_ add higher resolution modes like 1024x768 in this
case. We only add those modes for a failed EDID read where we have no
idea what's going on. In the case where we've pruned all modes then
instead we only want 640x480 which is the only defined "Fail Safe"
resolution.
This patch originated in response to Kuogee Hsieh's patch [1].
[1]
https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_probe_helper.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 819225629010..90cd46cbfec1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int count = 0, ret;
-bool verbose_prune = true;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
@@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_connector_update_edid_property(connector, NULL);
-verbose_prune = false;
-goto prune;
+drm_mode_prune_invalid(dev, >modes, false);
+goto exit;
}
count = (*connector_funcs->get_modes)(connector);
@@ -580,9 +579,26 @@ int
drm_helper_probe_single_connector_modes(struct drm_connector *connector,
}
}
-prune:
-drm_mode_prune_invalid(dev, >modes, verbose_prune);
+drm_mode_prune_invalid(dev, >modes, true);
+/*
+ * Displayport spec section 5.2.1.2 ("Video Timing Format") says
that
+ * all detachable sinks shall support 640x480 @60Hz as a fail safe
+ * mode. If all modes were pruned, perhaps because they need more
+ * lanes or a higher pixel clock than available, at least try to add
+ * in 640x480.
+ */
+if (list_empty(>modes) &&
+connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+count = drm_add_modes_noedid(connector, 640, 480);
+if (_drm_helper_update_and_validate(connector, maxX, maxY,
)) {
+drm_modeset_backoff();
+goto retry;
Do we need another retry here? This will again repeat everything from
get_modes().
The fact that we are hitting this code is because we have already tried
that and this is already a second-pass. So I think another retry isnt
needed?
This will help cover the case of 4.2.2.6 but not fix 4.2.2.1.
For 4.2.2.1, we will have 0 modes and so the original DRM fwk code of
adding all modes <= 1024x768 will
Re: [PATCH 0/4] mgag200: Improve damage handling
Nice work! For the whole series: Reviewed-by: Lyude Paul Will probably let it sit on the ML for a little bit just to make sure that Thomas gets a chance to look at this On Tue, 2022-04-26 at 18:41 +0200, Jocelyn Falempe wrote: > This series improves the damage handling on Matrox gpu, and allows > Gnome/Wayland to run much better. > Also include some driver cleanup. > > Tested on a Dell T310 with Matrox MGA G200eW WPCM450 (rev 0a) > > Thanks, > > Jocelyn Falempe (4): > mgag200: Add FB_DAMAGE_CLIPS support > mgag200: Optimize damage clips > mgag200: remove unused flag > mgag200: remove mgag200_probe_vram() > > drivers/gpu/drm/mgag200/mgag200_drv.c | 3 +- > drivers/gpu/drm/mgag200/mgag200_drv.h | 3 -- > drivers/gpu/drm/mgag200/mgag200_mm.c | 50 -- > drivers/gpu/drm/mgag200/mgag200_mode.c | 17 ++--- > 4 files changed, 20 insertions(+), 53 deletions(-) > > -- > 2.35.1 > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH 2/2] Revert "drm: of: Lookup if child node has panel or bridge"
On Tue 26 Apr 06:50 PDT 2022, Paul Kocialkowski wrote:
> On Tue 26 Apr 22, 15:19, Maxime Ripard wrote:
> > On Tue, Apr 26, 2022 at 03:04:17PM +0200, Paul Kocialkowski wrote:
> > > On Tue 26 Apr 22, 14:55, Maxime Ripard wrote:
> > > > On Tue, Apr 26, 2022 at 02:54:01PM +0200, Maxime Ripard wrote:
> > > > > On Tue, Apr 26, 2022 at 02:41:44PM +0200, Paul Kocialkowski wrote:
> > > > > > On Tue 26 Apr 22, 14:33, Laurent Pinchart wrote:
> > > > > > > On Tue, Apr 26, 2022 at 09:54:36AM +0200, Paul Kocialkowski wrote:
> > > > > > > > On Thu 21 Apr 22, 10:59, Paul Kocialkowski wrote:
> > > > > > > > > On Thu 21 Apr 22, 10:23, Maxime Ripard wrote:
> > > > > > > > > > On Thu, Apr 21, 2022 at 01:15:54PM +0530, Jagan Teki wrote:
> > > > > > > > > > > + Linus
> > > > > > > > > > > + Marek
> > > > > > > > > > > + Laurent
> > > > > > > > > > > + Robert
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Apr 21, 2022 at 4:40 AM Bjorn Andersson wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Commit '80253168dbfd ("drm: of: Lookup if child node
> > > > > > > > > > > > has panel or
> > > > > > > > > > > > bridge")' attempted to simplify the case of expressing
> > > > > > > > > > > > a simple panel
> > > > > > > > > > > > under a DSI controller, by assuming that the first
> > > > > > > > > > > > non-graph child node
> > > > > > > > > > > > was a panel or bridge.
> > > > > > > > > > > >
> > > > > > > > > > > > Unfortunately for non-trivial cases the first child
> > > > > > > > > > > > node might not be a
> > > > > > > > > > > > panel or bridge. Examples of this can be a aux-bus in
> > > > > > > > > > > > the case of
> > > > > > > > > > > > DisplayPort, or an opp-table represented before the
> > > > > > > > > > > > panel node.
> > > > > > > > > > > >
> > > > > > > > > > > > In these cases the reverted commit prevents the caller
> > > > > > > > > > > > from ever finding
> > > > > > > > > > > > a reference to the panel.
> > > > > > > > > > > >
> > > > > > > > > > > > This reverts commit '80253168dbfd ("drm: of: Lookup if
> > > > > > > > > > > > child node has
> > > > > > > > > > > > panel or bridge")', in favor of using an explicit graph
> > > > > > > > > > > > reference to the
> > > > > > > > > > > > panel in the trivial case as well.
> > > > > > > > > > >
> > > > > > > > > > > This eventually breaks many child-based
> > > > > > > > > > > devm_drm_of_get_bridge
> > > > > > > > > > > switched drivers. Do you have any suggestions on how to
> > > > > > > > > > > proceed to
> > > > > > > > > > > succeed in those use cases as well?
> > > > > > > > > >
> > > > > > > > > > I guess we could create a new helper for those, like
> > > > > > > > > > devm_drm_of_get_bridge_with_panel, or something.
> > > > > > > > >
> > > > > > > > > Oh wow I feel stupid for not thinking about that.
> > > > > > > > >
> > > > > > > > > Yeah I agree that it seems like the best option.
> > > > > > > >
> > > > > > > > Should I prepare a patch with such a new helper?
> > > > > > > >
> > > > > > > > The idea would be to keep drm_of_find_panel_or_bridge only for
> > > > > > > > the of graph
> > > > > > > > case and add one for the child node case, maybe:
> > > > > > > > drm_of_find_child_panel_or_bridge.
> > > > > > > >
> > > > > > > > I really don't have a clear idea of which driver would need to
> > > > > > > > be switched
> > > > > > > > over though. Could someone (Jagan?) let me know where it would
> > > > > > > > be needed?
> > > > > > > >
> > > > > > > > Are there cases where we could both expect of graph and child
> > > > > > > > node?
> > > > > > > > (i.e. does the new helper also need to try via of graph?)
> > > > > > >
> > > > > > > I still think we should use OF graph uncondtionally, even in the
> > > > > > > DSI
> > > > > > > case. We need to ensure backward-compatibility, but I'd like new
> > > > > > > bindings (and thus new drivers) to always use OF graph.
> > > > > >
> > > > > > I just went over the thread on "drm: of: Improve error handling in
> > > > > > bridge/panel
> > > > > > detection" again and I'm no longer sure there's actually still an
> > > > > > issue that
> > > > > > stands, with the fix that allows returning -ENODEV when possible.
> > > > > >
> > > > > > The remaining issue that was brought up was with a connector node,
> > > > > > but it should
> > > > > > be up to the driver to detect that and avoid calling
> > > > > > drm_of_find_panel_or_bridge
> > > > > > in such situations.
> > > > > >
> > > > > > So with that in mind it feels like the child node approach can be
> > > > > > viable
> > > > > > (and integrated in the same helper).
> > > > > >
> > > > > > We might still want to favor an explicit OF graph approach, but
> > > > > > note that
> > > > > > dsi-controller.yaml also specifies extra properties that are
> > > > > > specific to
> > > > > > MIPI DSI and I'm not sure there are equivalent definitions for the
> > > > > > OF graph
> > > > > > approach.
> > > > > >
> > > > > > What do
Re: [PATCH 1/2] drm/amdkfd: Use bitmap_zalloc() when applicable
Am 2022-04-26 um 14:47 schrieb Christophe JAILLET:
Le 26/04/2022 à 20:01, Felix Kuehling a écrit :
Hi Christophe,
I just stumbled over this patch series while cleaning up my inbox.
Sorry for dropping it back in November. I'm about to apply it but I
noticed that patch 1 is missing a Signed-off-by. Is it OK to add that
in your name?
Hi,
No problem for me if you can add it. Thanks.
But if you prefer a v2, it is also fine for me.
No need. I submitted the patches to amd-staging-drm-next.
Regards,
Felix
BTW sorry for missing the SoB tag. This definitively means that I
forgot the checkpatch.pl step for this patch, which is bad.
CJ
Thanks,
Felix
Am 2021-11-28 um 11:45 schrieb Christophe JAILLET:
'kfd->gtt_sa_bitmap' is a bitmap. So use 'bitmap_zalloc()' to simplify
code, improve the semantic and avoid some open-coded arithmetic in
allocator arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index e1294fba0c26..c5a0ce44a295 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1252,8 +1252,6 @@ int
kgd2kfd_schedule_evict_and_restore_process(struct mm_struct *mm,
static int kfd_gtt_sa_init(struct kfd_dev *kfd, unsigned int
buf_size,
unsigned int chunk_size)
{
- unsigned int num_of_longs;
-
if (WARN_ON(buf_size < chunk_size))
return -EINVAL;
if (WARN_ON(buf_size == 0))
@@ -1264,11 +1262,8 @@ static int kfd_gtt_sa_init(struct kfd_dev
*kfd, unsigned int buf_size,
kfd->gtt_sa_chunk_size = chunk_size;
kfd->gtt_sa_num_of_chunks = buf_size / chunk_size;
- num_of_longs = (kfd->gtt_sa_num_of_chunks + BITS_PER_LONG - 1) /
- BITS_PER_LONG;
-
- kfd->gtt_sa_bitmap = kcalloc(num_of_longs, sizeof(long),
GFP_KERNEL);
-
+ kfd->gtt_sa_bitmap = bitmap_zalloc(kfd->gtt_sa_num_of_chunks,
+ GFP_KERNEL);
if (!kfd->gtt_sa_bitmap)
return -ENOMEM;
@@ -1278,13 +1273,12 @@ static int kfd_gtt_sa_init(struct kfd_dev
*kfd, unsigned int buf_size,
mutex_init(>gtt_sa_lock);
return 0;
-
}
static void kfd_gtt_sa_fini(struct kfd_dev *kfd)
{
mutex_destroy(>gtt_sa_lock);
- kfree(kfd->gtt_sa_bitmap);
+ bitmap_free(kfd->gtt_sa_bitmap);
}
static inline uint64_t kfd_gtt_sa_calc_gpu_addr(uint64_t start_addr,
Re: [RFC PATCH] drm/edid: drm_add_modes_noedid() should set lowest resolution as preferred
Hi, On Tue, Apr 26, 2022 at 1:46 PM Abhinav Kumar wrote: > > On 4/26/2022 1:21 PM, Douglas Anderson wrote: > > If we're unable to read the EDID for a display because it's corrupt / > > bogus / invalid then we'll add a set of standard modes for the > > display. When userspace looks at these modes it doesn't really have a > > good concept for which mode to pick and it'll likely pick the highest > > resolution one by default. That's probably not ideal because the modes > > were purely guesses on the part of the Linux kernel. > > > > Let's instead set 640x480 as the "preferred" mode when we have no EDID. > > > > Signed-off-by: Douglas Anderson > > drm_dmt_modes array is sorted but you are also relying on this check to > eliminate the non-60fps modes > > 5611if (drm_mode_vrefresh(ptr) > 61) > 5612continue; > > I am not sure why we filter out the modes > 61 vrefresh. > > If that check will remain this is okay. > > If its not, its not reliable that the first mode will be 640x480@60 I suspect that the check will remain. I guess I could try to do something fancier if people want, but I'd be interested in _what_ fancier thing I should do if so. Do we want the rule to remain that we always prefer 640x480, or do we want to prefer the lowest resolution? ...do we want to prefer 60 Hz or the lowest refresh rate? Do we do this only for DP (which explicitly calls out 640x480 @60Hz as the best failsafe) or for everything? For now, the way it's coded up seems reasonable (to me). It's the lowest resolution _and_ it's 640x480 just because of the current values of the table. I suspect that extra lower resolution failsafe modes won't be added, but we can always change the rules here if/when they are. -Doug
Re: [RFC PATCH] drm/edid: drm_add_modes_noedid() should set lowest resolution as preferred
On 4/26/2022 1:21 PM, Douglas Anderson wrote:
If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. When userspace looks at these modes it doesn't really have a
good concept for which mode to pick and it'll likely pick the highest
resolution one by default. That's probably not ideal because the modes
were purely guesses on the part of the Linux kernel.
Let's instead set 640x480 as the "preferred" mode when we have no EDID.
Signed-off-by: Douglas Anderson
drm_dmt_modes array is sorted but you are also relying on this check to
eliminate the non-60fps modes
5611if (drm_mode_vrefresh(ptr) > 61)
5612continue;
I am not sure why we filter out the modes > 61 vrefresh.
If that check will remain this is okay.
If its not, its not reliable that the first mode will be 640x480@60
---
drivers/gpu/drm/drm_edid.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7a8482b75071..64ccfff4167e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5839,6 +5839,15 @@ int drm_add_modes_noedid(struct drm_connector *connector,
continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
+ /*
+* The drm_dmt_modes array is sorted so that lower
+* resolutions come first. We'll set the lowest
+* resolution mode as preferred. We have no EDID so
+* we should prefer the lowest resolution mode as
+* the safest one.
+*/
+ if (num_modes == 0)
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
num_modes++;
}
Re: [PATCH v5] drm/msm/dp: remove fail safe mode related code
Hi,
On Tue, Apr 26, 2022 at 1:30 PM Kuogee Hsieh wrote:
>
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
> is executed under drm_thread context.
>
> After review all possibilities methods and as discussed on
> https://patchwork.freedesktop.org/patch/483155/, supporting EDID
> compliance tests in the driver is quite hacky. As seen with other
> vendor drivers, supporting these will be much easier with IGT. Hence
> removing all the related fail safe code for it so that no possibility
> of circular lock will happen.
>
> ==
> WARNING: possible circular locking dependency detected
> 5.15.35-lockdep #6 Tainted: GW
> --
> frecon/429 is trying to acquire lock:
> ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
> dp_panel_add_fail_safe_mode+0x4c/0xa0
>
> but task is already holding lock:
> ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at:
> lock_crtcs+0xb4/0x124
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (>commit_lock[i]){+.+.}-{3:3}:
> __mutex_lock_common+0x174/0x1a64
> mutex_lock_nested+0x98/0xac
> lock_crtcs+0xb4/0x124
> msm_atomic_commit_tail+0x330/0x748
> commit_tail+0x19c/0x278
> drm_atomic_helper_commit+0x1dc/0x1f0
> drm_atomic_commit+0xc0/0xd8
> drm_atomic_helper_set_config+0xb4/0x134
> drm_mode_setcrtc+0x688/0x1248
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> -> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
> __mutex_lock_common+0x174/0x1a64
> ww_mutex_lock+0xb8/0x278
> modeset_lock+0x304/0x4ac
> drm_modeset_lock+0x4c/0x7c
> drmm_mode_config_init+0x4a8/0xc50
> msm_drm_init+0x274/0xac0
> msm_drm_bind+0x20/0x2c
> try_to_bring_up_master+0x3dc/0x470
> __component_add+0x18c/0x3c0
> component_add+0x1c/0x28
> dp_display_probe+0x954/0xa98
> platform_probe+0x124/0x15c
> really_probe+0x1b0/0x5f8
> __driver_probe_device+0x174/0x20c
> driver_probe_device+0x70/0x134
> __device_attach_driver+0x130/0x1d0
> bus_for_each_drv+0xfc/0x14c
> __device_attach+0x1bc/0x2bc
> device_initial_probe+0x1c/0x28
> bus_probe_device+0x94/0x178
> deferred_probe_work_func+0x1a4/0x1f0
> process_one_work+0x5d4/0x9dc
> worker_thread+0x898/0xccc
> kthread+0x2d4/0x3d4
> ret_from_fork+0x10/0x20
>
> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> ww_acquire_init+0x1c4/0x2c8
> drm_modeset_acquire_init+0x44/0xc8
> drm_helper_probe_single_connector_modes+0xb0/0x12dc
> drm_mode_getconnector+0x5dc/0xfe8
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> -> #0 (>mode_config.mutex){+.+.}-{3:3}:
> __lock_acquire+0x2650/0x672c
> lock_acquire+0x1b4/0x4ac
> __mutex_lock_common+0x174/0x1a64
> mutex_lock_nested+0x98/0xac
> dp_panel_add_fail_safe_mode+0x4c/0xa0
> dp_hpd_plug_handle+0x1f0/0x280
> dp_bridge_enable+0x94/0x2b8
> drm_atomic_bridge_chain_enable+0x11c/0x168
> drm_atomic_helper_commit_modeset_enables+0x500/0x740
> msm_atomic_commit_tail+0x3e4/0x748
> commit_tail+0x19c/0x278
> drm_atomic_helper_commit+0x1dc/0x1f0
> drm_atomic_commit+0xc0/0xd8
> drm_atomic_helper_set_config+0xb4/0x134
> drm_mode_setcrtc+0x688/0x1248
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> Changes in v2:
> -- re text commit title
> -- remove all fail safe mode
>
> Changes in v3:
> -- remove dp_panel_add_fail_safe_mode() from dp_panel.h
I don't see this part. I think you lost a bunch of chunks of your
change between v2 and v3. Can you double-check?
> -- add Fixes
>
> Changes in v4:
> --
[PATCH v5] drm/msm/dp: remove fail safe mode related code
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is executed under drm_thread context.
After review all possibilities methods and as discussed on
https://patchwork.freedesktop.org/patch/483155/, supporting EDID
compliance tests in the driver is quite hacky. As seen with other
vendor drivers, supporting these will be much easier with IGT. Hence
removing all the related fail safe code for it so that no possibility
of circular lock will happen.
==
WARNING: possible circular locking dependency detected
5.15.35-lockdep #6 Tainted: GW
--
frecon/429 is trying to acquire lock:
ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
dp_panel_add_fail_safe_mode+0x4c/0xa0
but task is already holding lock:
ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at: lock_crtcs+0xb4/0x124
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (>commit_lock[i]){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
lock_crtcs+0xb4/0x124
msm_atomic_commit_tail+0x330/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
ww_mutex_lock+0xb8/0x278
modeset_lock+0x304/0x4ac
drm_modeset_lock+0x4c/0x7c
drmm_mode_config_init+0x4a8/0xc50
msm_drm_init+0x274/0xac0
msm_drm_bind+0x20/0x2c
try_to_bring_up_master+0x3dc/0x470
__component_add+0x18c/0x3c0
component_add+0x1c/0x28
dp_display_probe+0x954/0xa98
platform_probe+0x124/0x15c
really_probe+0x1b0/0x5f8
__driver_probe_device+0x174/0x20c
driver_probe_device+0x70/0x134
__device_attach_driver+0x130/0x1d0
bus_for_each_drv+0xfc/0x14c
__device_attach+0x1bc/0x2bc
device_initial_probe+0x1c/0x28
bus_probe_device+0x94/0x178
deferred_probe_work_func+0x1a4/0x1f0
process_one_work+0x5d4/0x9dc
worker_thread+0x898/0xccc
kthread+0x2d4/0x3d4
ret_from_fork+0x10/0x20
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
ww_acquire_init+0x1c4/0x2c8
drm_modeset_acquire_init+0x44/0xc8
drm_helper_probe_single_connector_modes+0xb0/0x12dc
drm_mode_getconnector+0x5dc/0xfe8
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #0 (>mode_config.mutex){+.+.}-{3:3}:
__lock_acquire+0x2650/0x672c
lock_acquire+0x1b4/0x4ac
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
dp_panel_add_fail_safe_mode+0x4c/0xa0
dp_hpd_plug_handle+0x1f0/0x280
dp_bridge_enable+0x94/0x2b8
drm_atomic_bridge_chain_enable+0x11c/0x168
drm_atomic_helper_commit_modeset_enables+0x500/0x740
msm_atomic_commit_tail+0x3e4/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
Changes in v2:
-- re text commit title
-- remove all fail safe mode
Changes in v3:
-- remove dp_panel_add_fail_safe_mode() from dp_panel.h
-- add Fixes
Changes in v4:
-- to=diand...@chromium.org
Fixes: 8b2c181 ("drm/msm/dp: add fail safe mode outside of event_mutex context")
Reported-by: Douglas Anderson
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_panel.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index f141872..26f4b695 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++
Re: [PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
Hi,
On Tue, Apr 26, 2022 at 12:20 PM Abhinav Kumar
wrote:
>
> Missed one more comment.
>
> On 4/26/2022 12:16 PM, Abhinav Kumar wrote:
> > Hi Doug
> >
> > One minor comment below.
> >
> > But otherwise, looking at this change this should work for us acc to me.
> >
> > We will test this out with our equipment and then provide R-b.
> >
> > Thanks
> >
> > Abhinav
> > On 4/26/2022 11:46 AM, Douglas Anderson wrote:
> >> As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
> >> that all detachable sinks shall support 640x480 @60Hz as a fail safe
> >> mode.
> >>
> >> A DP compliance test expected us to utilize the above fact when all
> >> modes it presented to the DP source were not achievable. It presented
> >> only modes that would be achievable with more lanes and/or higher
> >> speeds than we had available and expected that when we couldn't do
> >> that then we'd fall back to 640x480 even though it didn't advertise
> >> this size.
> >>
> >> In order to pass the compliance test (and also support any users who
> >> might fall into a similar situation with their display), we need to
> >> add 640x480 into the list of modes. However, we don't want to add
> >> 640x480 all the time. Despite the fact that the DP spec says all sinks
> >> _shall support_ 640x480, they're not guaranteed to support it
> >> _well_. Continuing to read the spec you can see that the display is
> >> not required to really treat 640x480 equal to all the other modes. It
> >> doesn't need to scale or anything--just display the pixels somehow for
> >> failsafe purposes. It should also be noted that it's not hard to find
> >> a display hooked up via DisplayPort that _doesn't_ support 640x480 at
> >> all. The HP ZR30w screen I'm sitting in front of has a native DP port
> >> and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
> >> display via a DP to HDMI adapter and that screen definitely doesn't
> >> support 640x480.
> >>
> >> As a compromise solution, let's only add the 640x480 mode if:
> >> * We're on DP.
> >> * All other modes have been pruned.
> >>
> >> This acknowledges that 640x480 might not be the best mode to use but,
> >> since sinks are _supposed_ to support it, we will at least fall back
> >> to it if there's nothing else.
> >>
> >> Note that we _don't_ add higher resolution modes like 1024x768 in this
> >> case. We only add those modes for a failed EDID read where we have no
> >> idea what's going on. In the case where we've pruned all modes then
> >> instead we only want 640x480 which is the only defined "Fail Safe"
> >> resolution.
> >>
> >> This patch originated in response to Kuogee Hsieh's patch [1].
> >>
> >> [1]
> >> https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
> >>
> >>
> >> Signed-off-by: Douglas Anderson
> >> ---
> >>
> >> drivers/gpu/drm/drm_probe_helper.c | 26 +-
> >> 1 file changed, 21 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> index 819225629010..90cd46cbfec1 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> @@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
> >> drm_connector *connector,
> >> const struct drm_connector_helper_funcs *connector_funcs =
> >> connector->helper_private;
> >> int count = 0, ret;
> >> -bool verbose_prune = true;
> >> enum drm_connector_status old_status;
> >> struct drm_modeset_acquire_ctx ctx;
> >> @@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct
> >> drm_connector *connector,
> >> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> >> connector->base.id, connector->name);
> >> drm_connector_update_edid_property(connector, NULL);
> >> -verbose_prune = false;
> >> -goto prune;
> >> +drm_mode_prune_invalid(dev, >modes, false);
> >> +goto exit;
> >> }
> >> count = (*connector_funcs->get_modes)(connector);
> >> @@ -580,9 +579,26 @@ int
> >> drm_helper_probe_single_connector_modes(struct drm_connector *connector,
> >> }
> >> }
> >> -prune:
> >> -drm_mode_prune_invalid(dev, >modes, verbose_prune);
> >> +drm_mode_prune_invalid(dev, >modes, true);
> >> +/*
> >> + * Displayport spec section 5.2.1.2 ("Video Timing Format") says
> >> that
> >> + * all detachable sinks shall support 640x480 @60Hz as a fail safe
> >> + * mode. If all modes were pruned, perhaps because they need more
> >> + * lanes or a higher pixel clock than available, at least try to add
> >> + * in 640x480.
> >> + */
> >> +if (list_empty(>modes) &&
> >> +connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> >> +count = drm_add_modes_noedid(connector, 640, 480);
> >> +if (_drm_helper_update_and_validate(connector, maxX, maxY,
> >> )) {
> >> +
Re: [PATCH 3/5] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195
On Tue, Apr 19, 2022 at 11:32:35AM +0800, Rex-BC Chen wrote:
> From: "Nancy.Lin"
>
> Add vdosys1 RDMA definition.
How does this compare to the mediatek,mt8183-mdp3-rdma or
mediatek,mt8195-disp-rdma?
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
> ---
> .../display/mediatek/mediatek,mdp-rdma.yaml | 86 +++
> 1 file changed, 86 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> new file mode 100644
> index ..6ab773569462
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mdp-rdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MDP RDMA
> +
> +maintainers:
> + - Matthias Brugger
> +
> +description: |
> + The mediatek MDP RDMA stands for Read Direct Memory Access.
> + It provides real time data to the back-end panel driver, such as DSI,
> + DPI and DP_INTF.
> + It contains one line buffer to store the sufficient pixel data.
> + RDMA device node must be siblings to the central MMSYS_CONFIG node.
> + For a description of the MMSYS_CONFIG binding, see
> + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for
> details.
> +
> +properties:
> + compatible:
> +oneOf:
> + - items:
> + - const: mediatek,mt8195-vdo1-rdma
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + power-domains:
> +description: A phandle and PM domain specifier as defined by bindings of
> + the power controller specified by phandle. See
> + Documentation/devicetree/bindings/power/power-domain.yaml for details.
> +
> + clocks:
> +items:
> + - description: RDMA Clock
> +
> + iommus:
> +description:
> + This property should point to the respective IOMMU block with master
> port as argument,
> + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for
> details.
> +
> + mediatek,gce-client-reg:
> +description:
> + The register of display function block to be set by gce. There are 4
> arguments,
> + such as gce node, subsys id, offset and register size. The subsys id
> that is
> + mapping to the register of display function blocks is defined in the
> gce header
> + include/include/dt-bindings/gce/-gce.h of each chips.
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - power-domains
> + - clocks
> + - iommus
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +soc {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +vdo1_rdma0: mdp-rdma@1c104000 {
> +compatible = "mediatek,mt8195-vdo1-rdma";
> +reg = <0 0x1c104000 0 0x1000>;
> +interrupts = ;
> +clocks = < CLK_VDO1_MDP_RDMA0>;
> +power-domains = < MT8195_POWER_DOMAIN_VDOSYS1>;
> +iommus = <_vdo M4U_PORT_L2_MDP_RDMA0>;
> +mediatek,gce-client-reg = < SUBSYS_1c10 0x4000 0x1000>;
> +};
> +};
> --
> 2.18.0
>
>
[RFC PATCH] drm/edid: drm_add_modes_noedid() should set lowest resolution as preferred
If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. When userspace looks at these modes it doesn't really have a
good concept for which mode to pick and it'll likely pick the highest
resolution one by default. That's probably not ideal because the modes
were purely guesses on the part of the Linux kernel.
Let's instead set 640x480 as the "preferred" mode when we have no EDID.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_edid.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7a8482b75071..64ccfff4167e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5839,6 +5839,15 @@ int drm_add_modes_noedid(struct drm_connector *connector,
continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
+ /*
+* The drm_dmt_modes array is sorted so that lower
+* resolutions come first. We'll set the lowest
+* resolution mode as preferred. We have no EDID so
+* we should prefer the lowest resolution mode as
+* the safest one.
+*/
+ if (num_modes == 0)
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
num_modes++;
}
--
2.36.0.rc2.479.g8af0fa9b8e-goog
Re: [PATCH v4] drm/msm/dp: remove fail safe mode related code
On 26/04/2022 23:04, Kuogee Hsieh wrote:
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is executed under drm_thread context.
After review all possibilities methods and as discussed on
https://patchwork.freedesktop.org/patch/483155/, supporting EDID
compliance tests in the driver is quite hacky. As seen with other
vendor drivers, supporting these will be much easier with IGT. Hence
removing all the related fail safe code for it so that no possibility
of circular lock will happen.
==
WARNING: possible circular locking dependency detected
5.15.35-lockdep #6 Tainted: GW
--
frecon/429 is trying to acquire lock:
ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
dp_panel_add_fail_safe_mode+0x4c/0xa0
but task is already holding lock:
ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at: lock_crtcs+0xb4/0x124
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (>commit_lock[i]){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
lock_crtcs+0xb4/0x124
msm_atomic_commit_tail+0x330/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
ww_mutex_lock+0xb8/0x278
modeset_lock+0x304/0x4ac
drm_modeset_lock+0x4c/0x7c
drmm_mode_config_init+0x4a8/0xc50
msm_drm_init+0x274/0xac0
msm_drm_bind+0x20/0x2c
try_to_bring_up_master+0x3dc/0x470
__component_add+0x18c/0x3c0
component_add+0x1c/0x28
dp_display_probe+0x954/0xa98
platform_probe+0x124/0x15c
really_probe+0x1b0/0x5f8
__driver_probe_device+0x174/0x20c
driver_probe_device+0x70/0x134
__device_attach_driver+0x130/0x1d0
bus_for_each_drv+0xfc/0x14c
__device_attach+0x1bc/0x2bc
device_initial_probe+0x1c/0x28
bus_probe_device+0x94/0x178
deferred_probe_work_func+0x1a4/0x1f0
process_one_work+0x5d4/0x9dc
worker_thread+0x898/0xccc
kthread+0x2d4/0x3d4
ret_from_fork+0x10/0x20
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
ww_acquire_init+0x1c4/0x2c8
drm_modeset_acquire_init+0x44/0xc8
drm_helper_probe_single_connector_modes+0xb0/0x12dc
drm_mode_getconnector+0x5dc/0xfe8
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #0 (>mode_config.mutex){+.+.}-{3:3}:
__lock_acquire+0x2650/0x672c
lock_acquire+0x1b4/0x4ac
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
dp_panel_add_fail_safe_mode+0x4c/0xa0
dp_hpd_plug_handle+0x1f0/0x280
dp_bridge_enable+0x94/0x2b8
drm_atomic_bridge_chain_enable+0x11c/0x168
drm_atomic_helper_commit_modeset_enables+0x500/0x740
msm_atomic_commit_tail+0x3e4/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
Changes in v2:
-- re text commit title
-- remove all fail safe mode
Changes in v3:
-- remove dp_panel_add_fail_safe_mode() from dp_panel.h
-- add Fixes
Changes in v4:
-- to=diand...@chromium.org
Fixes: 8b2c181 ("drm/msm/dp: add fail safe mode outside of event_mutex context")
Signed-off-by: Kuogee Hsieh
Fixes: f1b47e6a8df8 ("drm/msm/dp: remove fail safe mode related code")
Reported-by: Douglas Anderson
This does not look correct. Your sign-off should be the latest
[PATCH v4] drm/msm/dp: remove fail safe mode related code
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is executed under drm_thread context.
After review all possibilities methods and as discussed on
https://patchwork.freedesktop.org/patch/483155/, supporting EDID
compliance tests in the driver is quite hacky. As seen with other
vendor drivers, supporting these will be much easier with IGT. Hence
removing all the related fail safe code for it so that no possibility
of circular lock will happen.
==
WARNING: possible circular locking dependency detected
5.15.35-lockdep #6 Tainted: GW
--
frecon/429 is trying to acquire lock:
ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
dp_panel_add_fail_safe_mode+0x4c/0xa0
but task is already holding lock:
ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at: lock_crtcs+0xb4/0x124
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (>commit_lock[i]){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
lock_crtcs+0xb4/0x124
msm_atomic_commit_tail+0x330/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
ww_mutex_lock+0xb8/0x278
modeset_lock+0x304/0x4ac
drm_modeset_lock+0x4c/0x7c
drmm_mode_config_init+0x4a8/0xc50
msm_drm_init+0x274/0xac0
msm_drm_bind+0x20/0x2c
try_to_bring_up_master+0x3dc/0x470
__component_add+0x18c/0x3c0
component_add+0x1c/0x28
dp_display_probe+0x954/0xa98
platform_probe+0x124/0x15c
really_probe+0x1b0/0x5f8
__driver_probe_device+0x174/0x20c
driver_probe_device+0x70/0x134
__device_attach_driver+0x130/0x1d0
bus_for_each_drv+0xfc/0x14c
__device_attach+0x1bc/0x2bc
device_initial_probe+0x1c/0x28
bus_probe_device+0x94/0x178
deferred_probe_work_func+0x1a4/0x1f0
process_one_work+0x5d4/0x9dc
worker_thread+0x898/0xccc
kthread+0x2d4/0x3d4
ret_from_fork+0x10/0x20
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
ww_acquire_init+0x1c4/0x2c8
drm_modeset_acquire_init+0x44/0xc8
drm_helper_probe_single_connector_modes+0xb0/0x12dc
drm_mode_getconnector+0x5dc/0xfe8
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #0 (>mode_config.mutex){+.+.}-{3:3}:
__lock_acquire+0x2650/0x672c
lock_acquire+0x1b4/0x4ac
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
dp_panel_add_fail_safe_mode+0x4c/0xa0
dp_hpd_plug_handle+0x1f0/0x280
dp_bridge_enable+0x94/0x2b8
drm_atomic_bridge_chain_enable+0x11c/0x168
drm_atomic_helper_commit_modeset_enables+0x500/0x740
msm_atomic_commit_tail+0x3e4/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
Changes in v2:
-- re text commit title
-- remove all fail safe mode
Changes in v3:
-- remove dp_panel_add_fail_safe_mode() from dp_panel.h
-- add Fixes
Changes in v4:
-- to=diand...@chromium.org
Fixes: 8b2c181 ("drm/msm/dp: add fail safe mode outside of event_mutex context")
Signed-off-by: Kuogee Hsieh
Fixes: f1b47e6a8df8 ("drm/msm/dp: remove fail safe mode related code")
Reported-by: Douglas Anderson
---
drivers/gpu/drm/msm/dp/dp_panel.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index f141872..26f4b695
Re: How should "max bpc" KMS property work?
On Tue, Apr 26, 2022 at 03:38:25PM -0400, Alex Deucher wrote: > On Tue, Apr 26, 2022 at 4:35 AM Pekka Paalanen wrote: > > > > Hi all, > > > > I'm working on setting HDR & WCG video modes in Weston, and I thought > > setting "max bpc" KMS property on the connector would be a good idea. > > I'm confused about how it works though. > > > > I did some digging in > > https://gitlab.freedesktop.org/wayland/weston/-/issues/612 > > > > Summary: > > > > - Apparently the property was originally added as a manual workaround > > for sink hardware behaving badly with high depth. A simple end user > > setting for "max bpc" would suffice for this use. > > > > - Drivers will sometimes automatically choose a lower bpc than the "max > > bpc" value, but never bigger. > > > > - amdgpu seems to (did?) default "max bpc" to 8, meaning that I > > definitely want to raise it. > > > > If I always slam "max bpc" to the highest supported value for that > > property, do I lose more than workarounds for bad sink hardware? > > > > Do I lose the ability to set video modes that take too much bandwidth > > at uncapped driver-selected bpc while capping the bpc lower would allow > > me to use those video modes? > > You wouldn't lose workarounds for amdgpu, you'd just lose potential > modes. The reason we added this feature in the first place was > because users bought new 4K monitors and the driver capped them at > 30Hz because we always defaulted to the highest supported bpc. We got > tons of bug reports about 4k@60 not being available and that was due > to the fact that the bpc was set to something greater than 8. I'm not > sure what the right answer is. It really depends on whether the user > wants higher bpc or faster refresh rates and possibly additional > higher res modes. IMO the right answer is to do mode filtering based on the min bpc. -- Ville Syrjälä Intel
[PATCH v3] drm/msm/dp: remove fail safe mode related code
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is executed under drm_thread context.
After review all possibilities methods and as discussed on
https://patchwork.freedesktop.org/patch/483155/, supporting EDID
compliance tests in the driver is quite hacky. As seen with other
vendor drivers, supporting these will be much easier with IGT. Hence
removing all the related fail safe code for it so that no possibility
of circular lock will happen.
==
WARNING: possible circular locking dependency detected
5.15.35-lockdep #6 Tainted: GW
--
frecon/429 is trying to acquire lock:
ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
dp_panel_add_fail_safe_mode+0x4c/0xa0
but task is already holding lock:
ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at: lock_crtcs+0xb4/0x124
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (>commit_lock[i]){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
lock_crtcs+0xb4/0x124
msm_atomic_commit_tail+0x330/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
ww_mutex_lock+0xb8/0x278
modeset_lock+0x304/0x4ac
drm_modeset_lock+0x4c/0x7c
drmm_mode_config_init+0x4a8/0xc50
msm_drm_init+0x274/0xac0
msm_drm_bind+0x20/0x2c
try_to_bring_up_master+0x3dc/0x470
__component_add+0x18c/0x3c0
component_add+0x1c/0x28
dp_display_probe+0x954/0xa98
platform_probe+0x124/0x15c
really_probe+0x1b0/0x5f8
__driver_probe_device+0x174/0x20c
driver_probe_device+0x70/0x134
__device_attach_driver+0x130/0x1d0
bus_for_each_drv+0xfc/0x14c
__device_attach+0x1bc/0x2bc
device_initial_probe+0x1c/0x28
bus_probe_device+0x94/0x178
deferred_probe_work_func+0x1a4/0x1f0
process_one_work+0x5d4/0x9dc
worker_thread+0x898/0xccc
kthread+0x2d4/0x3d4
ret_from_fork+0x10/0x20
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
ww_acquire_init+0x1c4/0x2c8
drm_modeset_acquire_init+0x44/0xc8
drm_helper_probe_single_connector_modes+0xb0/0x12dc
drm_mode_getconnector+0x5dc/0xfe8
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #0 (>mode_config.mutex){+.+.}-{3:3}:
__lock_acquire+0x2650/0x672c
lock_acquire+0x1b4/0x4ac
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
dp_panel_add_fail_safe_mode+0x4c/0xa0
dp_hpd_plug_handle+0x1f0/0x280
dp_bridge_enable+0x94/0x2b8
drm_atomic_bridge_chain_enable+0x11c/0x168
drm_atomic_helper_commit_modeset_enables+0x500/0x740
msm_atomic_commit_tail+0x3e4/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
Changes in v2:
-- re text commit title
-- remove all fail safe mode
Changes in v3:
-- remove dp_panel_add_fail_safe_mode() from dp_panel.h
-- add Fixes
Fixes: 8b2c181 ("drm/msm/dp: add fail safe mode outside of event_mutex context")
Signed-off-by: Kuogee Hsieh
Fixes: f1b47e6a8df8 ("drm/msm/dp: remove fail safe mode related code")
Reported-by: Douglas Anderson
---
drivers/gpu/drm/msm/dp/dp_panel.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index f141872..26f4b695 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
Re: [PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
Hi,
On Tue, Apr 26, 2022 at 12:16 PM Abhinav Kumar
wrote:
>
> Hi Doug
>
> One minor comment below.
>
> But otherwise, looking at this change this should work for us acc to me.
>
> We will test this out with our equipment and then provide R-b.
>
> Thanks
>
> Abhinav
> On 4/26/2022 11:46 AM, Douglas Anderson wrote:
> > As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
> > that all detachable sinks shall support 640x480 @60Hz as a fail safe
> > mode.
> >
> > A DP compliance test expected us to utilize the above fact when all
> > modes it presented to the DP source were not achievable. It presented
> > only modes that would be achievable with more lanes and/or higher
> > speeds than we had available and expected that when we couldn't do
> > that then we'd fall back to 640x480 even though it didn't advertise
> > this size.
> >
> > In order to pass the compliance test (and also support any users who
> > might fall into a similar situation with their display), we need to
> > add 640x480 into the list of modes. However, we don't want to add
> > 640x480 all the time. Despite the fact that the DP spec says all sinks
> > _shall support_ 640x480, they're not guaranteed to support it
> > _well_. Continuing to read the spec you can see that the display is
> > not required to really treat 640x480 equal to all the other modes. It
> > doesn't need to scale or anything--just display the pixels somehow for
> > failsafe purposes. It should also be noted that it's not hard to find
> > a display hooked up via DisplayPort that _doesn't_ support 640x480 at
> > all. The HP ZR30w screen I'm sitting in front of has a native DP port
> > and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
> > display via a DP to HDMI adapter and that screen definitely doesn't
> > support 640x480.
> >
> > As a compromise solution, let's only add the 640x480 mode if:
> > * We're on DP.
> > * All other modes have been pruned.
> >
> > This acknowledges that 640x480 might not be the best mode to use but,
> > since sinks are _supposed_ to support it, we will at least fall back
> > to it if there's nothing else.
> >
> > Note that we _don't_ add higher resolution modes like 1024x768 in this
> > case. We only add those modes for a failed EDID read where we have no
> > idea what's going on. In the case where we've pruned all modes then
> > instead we only want 640x480 which is the only defined "Fail Safe"
> > resolution.
> >
> > This patch originated in response to Kuogee Hsieh's patch [1].
> >
> > [1]
> > https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
> >
> > Signed-off-by: Douglas Anderson
> > ---
> >
> > drivers/gpu/drm/drm_probe_helper.c | 26 +-
> > 1 file changed, 21 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 819225629010..90cd46cbfec1 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> > const struct drm_connector_helper_funcs *connector_funcs =
> > connector->helper_private;
> > int count = 0, ret;
> > - bool verbose_prune = true;
> > enum drm_connector_status old_status;
> > struct drm_modeset_acquire_ctx ctx;
> >
> > @@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> > connector->base.id, connector->name);
> > drm_connector_update_edid_property(connector, NULL);
> > - verbose_prune = false;
> > - goto prune;
> > + drm_mode_prune_invalid(dev, >modes, false);
> > + goto exit;
> > }
> >
> > count = (*connector_funcs->get_modes)(connector);
> > @@ -580,9 +579,26 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> > }
> > }
> >
> > -prune:
> > - drm_mode_prune_invalid(dev, >modes, verbose_prune);
> > + drm_mode_prune_invalid(dev, >modes, true);
> >
> > + /*
> > + * Displayport spec section 5.2.1.2 ("Video Timing Format") says that
> > + * all detachable sinks shall support 640x480 @60Hz as a fail safe
> > + * mode. If all modes were pruned, perhaps because they need more
> > + * lanes or a higher pixel clock than available, at least try to add
> > + * in 640x480.
> > + */
> > + if (list_empty(>modes) &&
> > + connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> > + count = drm_add_modes_noedid(connector, 640, 480);
> > + if (_drm_helper_update_and_validate(connector, maxX, maxY,
> > )) {
> > + drm_modeset_backoff();
> > + goto retry;
>
> Do we need another retry here? This
Re: How should "max bpc" KMS property work?
On Tue, Apr 26, 2022 at 4:35 AM Pekka Paalanen wrote: > > Hi all, > > I'm working on setting HDR & WCG video modes in Weston, and I thought > setting "max bpc" KMS property on the connector would be a good idea. > I'm confused about how it works though. > > I did some digging in > https://gitlab.freedesktop.org/wayland/weston/-/issues/612 > > Summary: > > - Apparently the property was originally added as a manual workaround > for sink hardware behaving badly with high depth. A simple end user > setting for "max bpc" would suffice for this use. > > - Drivers will sometimes automatically choose a lower bpc than the "max > bpc" value, but never bigger. > > - amdgpu seems to (did?) default "max bpc" to 8, meaning that I > definitely want to raise it. > > If I always slam "max bpc" to the highest supported value for that > property, do I lose more than workarounds for bad sink hardware? > > Do I lose the ability to set video modes that take too much bandwidth > at uncapped driver-selected bpc while capping the bpc lower would allow > me to use those video modes? You wouldn't lose workarounds for amdgpu, you'd just lose potential modes. The reason we added this feature in the first place was because users bought new 4K monitors and the driver capped them at 30Hz because we always defaulted to the highest supported bpc. We got tons of bug reports about 4k@60 not being available and that was due to the fact that the bpc was set to something greater than 8. I'm not sure what the right answer is. It really depends on whether the user wants higher bpc or faster refresh rates and possibly additional higher res modes. Alex > > Or, are drivers required to choose a lower-than-usual but highest > usable bpc to make the requested video mode squeeze through the > connector and link? > > Do I need to implement a fallback strategy in a display server, > starting from the highest possible "max bpc" value, and if my modeset > is rejected, repeatedly try with lower "max bpc" setting until it works > or I'm out of bpc options? > > > Thanks, > pq
[PATCH v4 1/2] dt-bindings: display: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge
The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
which represents this serializer as a bridge.
Acked-by: Sam Ravnborg
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Peng Fan
Cc: Rob Herring
Cc: Robby Cai
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: - Consistently use fsl,imx8mp-ldb as compatible
- Drop items: from compatible:
- Replace minItems with maxItems in clocks:
- Drop quotes from clock-names const: ldb
- Rename syscon to fsl,syscon
- Use generic name of ldb-lvds in example
V3: - Add AB from Sam
- Consistently use MX8MP
V4: - Rename to fsl-ldb all over the place
- Put the LDB node under media block controller in the example
---
.../bindings/display/bridge/fsl,ldb.yaml | 92 +++
1 file changed, 92 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
new file mode 100644
index ..77f174eee424
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP DPI to LVDS bridge chip
+
+maintainers:
+ - Marek Vasut
+
+description: |
+ The i.MX8MP mediamix contains two registers which are responsible
+ for configuring the on-SoC DPI-to-LVDS serializer. This describes
+ those registers as bridge within the DT.
+
+properties:
+ compatible:
+const: fsl,imx8mp-ldb
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: ldb
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for DPI input.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-A output (panel or bridge).
+
+ port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-B output (panel or bridge).
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - clocks
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+blk-ctrl {
+bridge {
+compatible = "fsl,imx8mp-ldb";
+clocks = < IMX8MP_CLK_MEDIA_LDB>;
+clock-names = "ldb";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+
+ldb_from_lcdif2: endpoint {
+remote-endpoint = <_to_ldb>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+ldb_lvds_ch0: endpoint {
+remote-endpoint = <_to_lvdsx4panel>;
+};
+};
+
+port@2 {
+reg = <2>;
+
+ldb_lvds_ch1: endpoint {
+};
+};
+};
+};
+};
--
2.35.1
[PATCH v4 2/2] drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge
The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Implement a
simple bridge driver for this serializer.
Reviewed-by: Sam Ravnborg
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Peng Fan
Cc: Robby Cai
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
To: dri-devel@lists.freedesktop.org
--
V2: - Rename syscon to fsl,syscon
V3: - Consistently use MX8MP
- Add sentinel of_device_table
- Add RB from Sam
V4: - Fix MODULE_DESCRIPTION to also use MX8MP
- Rename to fsl-ldb altogether
---
drivers/gpu/drm/bridge/Kconfig | 8 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/fsl-ldb.c | 342 +++
3 files changed, 351 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/fsl-ldb.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index edba12dde250..acccd97335b3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -75,6 +75,14 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_FSL_LDB
+ tristate "Freescale i.MX8MP LDB bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ help
+ Support for i.MX8MP DPI-to-LVDS on-SoC encoder.
+
config DRM_ITE_IT6505
tristate "ITE IT6505 DisplayPort bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index bdffad2a7ed3..313f4a09bbe0 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o
obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o
obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
new file mode 100644
index ..c24c488fb208
--- /dev/null
+++ b/drivers/gpu/drm/bridge/fsl-ldb.c
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2022 Marek Vasut
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define LDB_CTRL 0x5c
+#define LDB_CTRL_CH0_ENABLEBIT(0)
+#define LDB_CTRL_CH0_DI_SELECT BIT(1)
+#define LDB_CTRL_CH1_ENABLEBIT(2)
+#define LDB_CTRL_CH1_DI_SELECT BIT(3)
+#define LDB_CTRL_SPLIT_MODEBIT(4)
+#define LDB_CTRL_CH0_DATA_WIDTHBIT(5)
+#define LDB_CTRL_CH0_BIT_MAPPING BIT(6)
+#define LDB_CTRL_CH1_DATA_WIDTHBIT(7)
+#define LDB_CTRL_CH1_BIT_MAPPING BIT(8)
+#define LDB_CTRL_DI0_VSYNC_POLARITYBIT(9)
+#define LDB_CTRL_DI1_VSYNC_POLARITYBIT(10)
+#define LDB_CTRL_REG_CH0_FIFO_RESETBIT(11)
+#define LDB_CTRL_REG_CH1_FIFO_RESETBIT(12)
+#define LDB_CTRL_ASYNC_FIFO_ENABLE BIT(24)
+#define LDB_CTRL_ASYNC_FIFO_THRESHOLD_MASK GENMASK(27, 25)
+
+#define LVDS_CTRL 0x128
+#define LVDS_CTRL_CH0_EN BIT(0)
+#define LVDS_CTRL_CH1_EN BIT(1)
+#define LVDS_CTRL_VBG_EN BIT(2)
+#define LVDS_CTRL_HS_ENBIT(3)
+#define LVDS_CTRL_PRE_EMPH_EN BIT(4)
+#define LVDS_CTRL_PRE_EMPH_ADJ(n) (((n) & 0x7) << 5)
+#define LVDS_CTRL_PRE_EMPH_ADJ_MASKGENMASK(7, 5)
+#define LVDS_CTRL_CM_ADJ(n)(((n) & 0x7) << 8)
+#define LVDS_CTRL_CM_ADJ_MASK GENMASK(10, 8)
+#define LVDS_CTRL_CC_ADJ(n)(((n) & 0x7) << 11)
+#define LVDS_CTRL_CC_ADJ_MASK GENMASK(13, 11)
+#define LVDS_CTRL_SLEW_ADJ(n) (((n) & 0x7) << 14)
+#define LVDS_CTRL_SLEW_ADJ_MASKGENMASK(16, 14)
+#define LVDS_CTRL_VBG_ADJ(n) (((n) & 0x7) << 17)
+#define LVDS_CTRL_VBG_ADJ_MASK GENMASK(19, 17)
+
+struct fsl_ldb {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+ struct clk *clk;
+ struct regmap *regmap;
+ bool lvds_dual_link;
+};
+
+static inline struct fsl_ldb *to_fsl_ldb(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct fsl_ldb, bridge);
+}
+
+static int fsl_ldb_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+
[PATCH v3 17/18] drm/edid: Extract drm_edid_decode_mfg_id()
From: Ville Syrjälä
Make the PNPID decoding available for other users.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
include/drm/drm_edid.h | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3204a58fb09..e92385a13d2a 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -496,6 +496,22 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
}
+/**
+ * drm_edid_decode_mfg_id - Decode the manufacturer ID
+ * @mfg_id: The manufacturer ID
+ * @vend: A 4-byte buffer to store the 3-letter vendor string plus a '\0'
+ * termination
+ */
+static inline const char *drm_edid_decode_mfg_id(u16 mfg_id, char vend[4])
+{
+ vend[0] = '@' + ((mfg_id >> 10) & 0x1f);
+ vend[1] = '@' + ((mfg_id >> 5) & 0x1f);
+ vend[2] = '@' + ((mfg_id >> 0) & 0x1f);
+ vend[3] = '\0';
+
+ return vend;
+}
+
/**
* drm_edid_encode_panel_id - Encode an ID for matching against
drm_edid_get_panel_id()
* @vend_chr_0: First character of the vendor string.
@@ -536,10 +552,7 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
static inline void drm_edid_decode_panel_id(u32 panel_id, char vend[4], u16
*product_id)
{
*product_id = (u16)(panel_id & 0x);
- vend[0] = '@' + ((panel_id >> 26) & 0x1f);
- vend[1] = '@' + ((panel_id >> 21) & 0x1f);
- vend[2] = '@' + ((panel_id >> 16) & 0x1f);
- vend[3] = '\0';
+ drm_edid_decode_mfg_id(panel_id >> 16, vend);
}
bool drm_probe_ddc(struct i2c_adapter *adapter);
--
2.35.1
Re: [PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
Missed one more comment.
On 4/26/2022 12:16 PM, Abhinav Kumar wrote:
Hi Doug
One minor comment below.
But otherwise, looking at this change this should work for us acc to me.
We will test this out with our equipment and then provide R-b.
Thanks
Abhinav
On 4/26/2022 11:46 AM, Douglas Anderson wrote:
As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a fail safe
mode.
A DP compliance test expected us to utilize the above fact when all
modes it presented to the DP source were not achievable. It presented
only modes that would be achievable with more lanes and/or higher
speeds than we had available and expected that when we couldn't do
that then we'd fall back to 640x480 even though it didn't advertise
this size.
In order to pass the compliance test (and also support any users who
might fall into a similar situation with their display), we need to
add 640x480 into the list of modes. However, we don't want to add
640x480 all the time. Despite the fact that the DP spec says all sinks
_shall support_ 640x480, they're not guaranteed to support it
_well_. Continuing to read the spec you can see that the display is
not required to really treat 640x480 equal to all the other modes. It
doesn't need to scale or anything--just display the pixels somehow for
failsafe purposes. It should also be noted that it's not hard to find
a display hooked up via DisplayPort that _doesn't_ support 640x480 at
all. The HP ZR30w screen I'm sitting in front of has a native DP port
and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
display via a DP to HDMI adapter and that screen definitely doesn't
support 640x480.
As a compromise solution, let's only add the 640x480 mode if:
* We're on DP.
* All other modes have been pruned.
This acknowledges that 640x480 might not be the best mode to use but,
since sinks are _supposed_ to support it, we will at least fall back
to it if there's nothing else.
Note that we _don't_ add higher resolution modes like 1024x768 in this
case. We only add those modes for a failed EDID read where we have no
idea what's going on. In the case where we've pruned all modes then
instead we only want 640x480 which is the only defined "Fail Safe"
resolution.
This patch originated in response to Kuogee Hsieh's patch [1].
[1]
https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_probe_helper.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 819225629010..90cd46cbfec1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int count = 0, ret;
- bool verbose_prune = true;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
@@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_connector_update_edid_property(connector, NULL);
- verbose_prune = false;
- goto prune;
+ drm_mode_prune_invalid(dev, >modes, false);
+ goto exit;
}
count = (*connector_funcs->get_modes)(connector);
@@ -580,9 +579,26 @@ int
drm_helper_probe_single_connector_modes(struct drm_connector *connector,
}
}
-prune:
- drm_mode_prune_invalid(dev, >modes, verbose_prune);
+ drm_mode_prune_invalid(dev, >modes, true);
+ /*
+ * Displayport spec section 5.2.1.2 ("Video Timing Format") says
that
+ * all detachable sinks shall support 640x480 @60Hz as a fail safe
+ * mode. If all modes were pruned, perhaps because they need more
+ * lanes or a higher pixel clock than available, at least try to add
+ * in 640x480.
+ */
+ if (list_empty(>modes) &&
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ count = drm_add_modes_noedid(connector, 640, 480);
+ if (_drm_helper_update_and_validate(connector, maxX, maxY,
)) {
+ drm_modeset_backoff();
+ goto retry;
Do we need another retry here? This will again repeat everything from
get_modes().
The fact that we are hitting this code is because we have already tried
that and this is already a second-pass. So I think another retry isnt
needed?
This will help cover the case of 4.2.2.6 but not fix 4.2.2.1.
For 4.2.2.1, we will have 0 modes and so the original DRM fwk code of
adding all modes <= 1024x768 will kick in.
Now, in that list, we will still need to pick/mark 640x480 as the
preferred mode.
We still
Re: [Intel-gfx] [PULL] gvt-next
On 26/04/2022 17:58, Wang, Zhi A wrote:
On 4/26/22 3:53 PM, Jason Gunthorpe wrote:
On Tue, Apr 26, 2022 at 07:58:59AM +, Wang, Zhi A wrote:
Hi folks:
Here is the pull of gvt-next which fixs the compilation error when i915 debug
is open after the GVT-g refactor patches.
Thanks so much for the efforts.
Thanks,
Zhi.
The following changes since commit 2917f53113be3b7a0f374e02cebe6d6b749366b5:
vfio/mdev: Remove mdev drvdata (2022-04-21 07:36:56 -0400)
are available in the Git repository at:
https://github.com/intel/gvt-linux tags/gvt-next-2022-04-26
for you to fetch changes up to 2da299cee780ea797b3f72558687868072cf5eb5:
drm/i915/gvt: Add missing export of symbols. (2022-04-25 18:03:04 -0400)
gvt-next-2022-04-26
- Add two missing exports of symbols when i915 debug is enabled.
Zhi Wang (1):
drm/i915/gvt: Add missing export of symbols.
drivers/gpu/drm/i915/intel_gvt.c | 2 ++
1 file changed, 2 insertions(+)
This still has another compile problem:
ERROR: modpost: "intel_runtime_pm_put" [vmlinux] is a static EXPORT_SYMBOL_GPL
Because:
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
void intel_runtime_pm_put(struct intel_runtime_pm *rpm, intel_wakeref_t wref);
#else
static inline void
intel_runtime_pm_put(struct intel_runtime_pm *rpm, intel_wakeref_t wref)
{
intel_runtime_pm_put_unchecked(rpm);
}
#endif
Looks like it happens if CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
I think you probably want to #ifdef the export in the same way:
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -309,7 +309,9 @@ EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT);
EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT);
EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT);
EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put, I915_GVT);
+#endif
Sigh. That's tricky. Let me prepare another one.
Also the following compile error:
drivers/gpu/drm/i915/gvt/handlers.c:75:6: error: no previous prototype
for ‘intel_gvt_match_device’ [-Werror=missing-prototypes]
75 | bool intel_gvt_match_device(struct intel_gvt *gvt,
| ^~
it was removed from a header. The implementation should now be made static
EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT);
EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT);
EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT);
Jason
Re: [PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
Hi Doug
One minor comment below.
But otherwise, looking at this change this should work for us acc to me.
We will test this out with our equipment and then provide R-b.
Thanks
Abhinav
On 4/26/2022 11:46 AM, Douglas Anderson wrote:
As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a fail safe
mode.
A DP compliance test expected us to utilize the above fact when all
modes it presented to the DP source were not achievable. It presented
only modes that would be achievable with more lanes and/or higher
speeds than we had available and expected that when we couldn't do
that then we'd fall back to 640x480 even though it didn't advertise
this size.
In order to pass the compliance test (and also support any users who
might fall into a similar situation with their display), we need to
add 640x480 into the list of modes. However, we don't want to add
640x480 all the time. Despite the fact that the DP spec says all sinks
_shall support_ 640x480, they're not guaranteed to support it
_well_. Continuing to read the spec you can see that the display is
not required to really treat 640x480 equal to all the other modes. It
doesn't need to scale or anything--just display the pixels somehow for
failsafe purposes. It should also be noted that it's not hard to find
a display hooked up via DisplayPort that _doesn't_ support 640x480 at
all. The HP ZR30w screen I'm sitting in front of has a native DP port
and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
display via a DP to HDMI adapter and that screen definitely doesn't
support 640x480.
As a compromise solution, let's only add the 640x480 mode if:
* We're on DP.
* All other modes have been pruned.
This acknowledges that 640x480 might not be the best mode to use but,
since sinks are _supposed_ to support it, we will at least fall back
to it if there's nothing else.
Note that we _don't_ add higher resolution modes like 1024x768 in this
case. We only add those modes for a failed EDID read where we have no
idea what's going on. In the case where we've pruned all modes then
instead we only want 640x480 which is the only defined "Fail Safe"
resolution.
This patch originated in response to Kuogee Hsieh's patch [1].
[1]
https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_probe_helper.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 819225629010..90cd46cbfec1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int count = 0, ret;
- bool verbose_prune = true;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
@@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_connector_update_edid_property(connector, NULL);
- verbose_prune = false;
- goto prune;
+ drm_mode_prune_invalid(dev, >modes, false);
+ goto exit;
}
count = (*connector_funcs->get_modes)(connector);
@@ -580,9 +579,26 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
}
}
-prune:
- drm_mode_prune_invalid(dev, >modes, verbose_prune);
+ drm_mode_prune_invalid(dev, >modes, true);
+ /*
+* Displayport spec section 5.2.1.2 ("Video Timing Format") says that
+* all detachable sinks shall support 640x480 @60Hz as a fail safe
+* mode. If all modes were pruned, perhaps because they need more
+* lanes or a higher pixel clock than available, at least try to add
+* in 640x480.
+*/
+ if (list_empty(>modes) &&
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ count = drm_add_modes_noedid(connector, 640, 480);
+ if (_drm_helper_update_and_validate(connector, maxX, maxY,
)) {
+ drm_modeset_backoff();
+ goto retry;
Do we need another retry here? This will again repeat everything from
get_modes().
The fact that we are hitting this code is because we have already tried
that and this is already a second-pass. So I think another retry isnt
needed?
+ }
+ drm_mode_prune_invalid(dev, >modes, true);
+ }
+
+exit:
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
Re: [PATCH v2 1/2] drm/sched: use DECLARE_EVENT_CLASS
Done Andrey On 2022-04-26 14:52, Chia-I Wu wrote: That would be great. I don't have push permission. On Tue, Apr 26, 2022 at 11:25 AM Andrey Grodzovsky wrote: It's ok to land but it wasn't, do you have push permissions to drm-misc-next ? If not, I will do it for you. Andrey On 2022-04-26 12:29, Chia-I Wu wrote: On Tue, Apr 12, 2022 at 1:48 PM Chia-I Wu wrote: drm_sched_job and drm_run_job have the same prototype. v2: rename the class from drm_sched_job_entity to drm_sched_job (Andrey) Signed-off-by: Chia-I Wu Cc: Rob Clark Reviewed-by: Andrey Grodzovsky This series has been reviewed. Is it ok to land (if it hasn't)?
Re: [PATCH 06/19] drm/edid: clean up cea_db_is_*() functions
On Thu, Apr 14, 2022 at 06:06:49PM +0300, Jani Nikula wrote:
> Abstract helpers for matching vendor data blocks and extended tags, and
> use them to simplify all the cea_db_is_*() functions.
>
> Take void pointer as parameter to allow transitional use for both u8 *
> and struct cea_db *.
>
> v2: Remove superfluous parens (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 127 -
> 1 file changed, 40 insertions(+), 87 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 43d9e04f8fb9..34897b1417a5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4360,12 +4360,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
> const u8 *db, u8 len,
> return modes;
> }
>
> -static int
> -cea_db_extended_tag(const u8 *db)
> -{
> - return db[1];
> -}
> -
> static int
> cea_revision(const u8 *cea)
> {
> @@ -4477,6 +4471,22 @@ static const void *cea_db_data(const struct cea_db *db)
> return db->data;
> }
>
> +static bool cea_db_is_extended_tag(const struct cea_db *db, int tag)
> +{
> + return cea_db_tag(db) == CTA_DB_EXTENDED_TAG &&
> + cea_db_payload_len(db) >= 1 &&
> + db->data[0] == tag;
> +}
> +
> +static bool cea_db_is_vendor(const struct cea_db *db, int vendor_oui)
> +{
> + const u8 *data = cea_db_data(db);
> +
> + return cea_db_tag(db) == CTA_DB_VENDOR &&
> + cea_db_payload_len(db) >= 3 &&
> + oui(data[2], data[1], data[0]) == vendor_oui;
> +}
> +
> static void cea_db_iter_edid_begin(const struct edid *edid, struct
> cea_db_iter *iter)
> {
> memset(iter, 0, sizeof(*iter));
> @@ -4611,93 +4621,50 @@ static void cea_db_iter_end(struct cea_db_iter *iter)
> memset(iter, 0, sizeof(*iter));
> }
>
> -static bool cea_db_is_hdmi_vsdb(const u8 *db)
> +static bool cea_db_is_hdmi_vsdb(const void *db)
> {
> - if (cea_db_tag(db) != CTA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) < 5)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI;
> + return cea_db_is_vendor(db, HDMI_IEEE_OUI) &&
> + cea_db_payload_len(db) >= 5;
> }
>
> -static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
> +static bool cea_db_is_hdmi_forum_vsdb(const void *db)
> {
> - if (cea_db_tag(db) != CTA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) < 7)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
> + return cea_db_is_vendor(db, HDMI_FORUM_IEEE_OUI) &&
> + cea_db_payload_len(db) >= 7;
> }
>
> -static bool cea_db_is_microsoft_vsdb(const u8 *db)
> +static bool cea_db_is_microsoft_vsdb(const void *db)
> {
> - if (cea_db_tag(db) != CTA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) != 21)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == MICROSOFT_IEEE_OUI;
> + return cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
> + cea_db_payload_len(db) == 21;
> }
>
> -static bool cea_db_is_vcdb(const u8 *db)
> +static bool cea_db_is_vcdb(const void *db)
> {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (cea_db_payload_len(db) != 2)
> - return false;
> -
> - if (cea_db_extended_tag(db) != CTA_EXT_DB_VIDEO_CAP)
> - return false;
> -
> - return true;
> + return cea_db_is_extended_tag(db, CTA_EXT_DB_VIDEO_CAP) &&
> + cea_db_payload_len(db) == 2;
> }
>
> -static bool cea_db_is_hdmi_forum_scdb(const u8 *db)
> +static bool cea_db_is_hdmi_forum_scdb(const void *db)
> {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (cea_db_payload_len(db) < 7)
> - return false;
> -
> - if (cea_db_extended_tag(db) != CTA_EXT_DB_HF_SCDB)
> - return false;
> -
> - return true;
> + return cea_db_is_extended_tag(db, CTA_EXT_DB_HF_SCDB) &&
> + cea_db_payload_len(db) >= 7;
> }
>
> -static bool cea_db_is_y420cmdb(const u8 *db)
> +static bool cea_db_is_y420cmdb(const void *db)
> {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (!cea_db_payload_len(db))
> - return false;
> -
> - if (cea_db_extended_tag(db) != CTA_EXT_DB_420_VIDEO_CAP_MAP)
> - return false;
> -
> - return true;
> + return cea_db_is_extended_tag(db, CTA_EXT_DB_420_VIDEO_CAP_MAP);
> }
>
> -static bool cea_db_is_y420vdb(const u8 *db)
> +static bool cea_db_is_y420vdb(const void *db)
> {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (!cea_db_payload_len(db))
> - return false;
> -
> - if (cea_db_extended_tag(db) !=
Re: [PATCH 02/19] drm/edid: check for HF-SCDB block
On Thu, Apr 14, 2022 at 06:06:45PM +0300, Jani Nikula wrote:
> From: Lee Shawn C
>
> Find HF-SCDB information in CEA extensions block. And retrieve
> Max_TMDS_Character_Rate that support by sink device.
>
> v2: HF-SCDB and HF-VSDBS carry the same SCDS data. Reuse
> drm_parse_hdmi_forum_vsdb() to parse this packet.
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Ankit Nautiyal
> Cc: intel-gfx
> Signed-off-by: Lee Shawn C
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 4758e78fad82..32ece9607b94 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3495,6 +3495,7 @@ add_detailed_modes(struct drm_connector *connector,
> const struct edid *edid,
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> #define EXT_VIDEO_DATA_BLOCK_420 0x0E
> #define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> +#define EXT_VIDEO_HF_SCDB_DATA_BLOCK 0x79
> #define EDID_BASIC_AUDIO (1 << 6)
> #define EDID_CEA_YCRCB444(1 << 5)
> #define EDID_CEA_YCRCB422(1 << 4)
> @@ -4426,6 +4427,20 @@ static bool cea_db_is_vcdb(const u8 *db)
> return true;
> }
>
> +static bool cea_db_is_hdmi_forum_scdb(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (cea_db_payload_len(db) < 7)
> + return false;
> +
> + if (cea_db_extended_tag(db) != EXT_VIDEO_HF_SCDB_DATA_BLOCK)
> + return false;
> +
> + return true;
> +}
> +
> static bool cea_db_is_y420cmdb(const u8 *db)
> {
> if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -5387,7 +5402,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
>
> if (cea_db_is_hdmi_vsdb(db))
> drm_parse_hdmi_vsdb_video(connector, db);
> - if (cea_db_is_hdmi_forum_vsdb(db))
> + if (cea_db_is_hdmi_forum_vsdb(db) ||
> + cea_db_is_hdmi_forum_scdb(db))
> drm_parse_hdmi_forum_vsdb(connector, db);
I'd do a s/parse_hdmi_forum_vsdb/parse_scds/ to keep up
with the spec terminology.
Reviewed-by: Ville Syrjälä
> if (cea_db_is_microsoft_vsdb(db))
> drm_parse_microsoft_vsdb(connector, db);
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: [GIT PULL] fbdev updates & fixes for v5.18-rc5
The pull request you sent on Tue, 26 Apr 2022 17:18:42 +0200: > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/for-5.18/fbdev-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cf424ef014ac30b0da27125dd1fbdf10b0d3a520 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v2 1/2] drm/sched: use DECLARE_EVENT_CLASS
That would be great. I don't have push permission. On Tue, Apr 26, 2022 at 11:25 AM Andrey Grodzovsky wrote: > > It's ok to land but it wasn't, do you have push permissions to > drm-misc-next ? If not, I will do it for you. > > Andrey > > On 2022-04-26 12:29, Chia-I Wu wrote: > > On Tue, Apr 12, 2022 at 1:48 PM Chia-I Wu wrote: > >> drm_sched_job and drm_run_job have the same prototype. > >> > >> v2: rename the class from drm_sched_job_entity to drm_sched_job (Andrey) > >> > >> Signed-off-by: Chia-I Wu > >> Cc: Rob Clark > >> Reviewed-by: Andrey Grodzovsky > > This series has been reviewed. Is it ok to land (if it hasn't)?
Re: [PATCH 01/19] drm/edid: reset display info in drm_add_edid_modes() for NULL edid
On Thu, Apr 14, 2022 at 06:06:44PM +0300, Jani Nikula wrote:
> If a NULL edid gets passed to drm_add_edid_modes(), we should probably
> also reset the display info.
One concern I had with this is resetting of eg. {width,height}_mm
which might have been populated by intel_panel_add_fixed_mode().
But I think that might already happen anyway through one of the
other codepaths that call drm_reset_display_info() so probably not
something that is made any worse by this patch.
IIRC at one point I tried to startd cleaning up the display_info
mess a bit but the patches got stuck in some silly bikeshed
so I gave up.
Reviewed-by: Ville Syrjälä
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 324ce8467915..4758e78fad82 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5721,6 +5721,7 @@ static int drm_edid_connector_update(struct
> drm_connector *connector,
> u32 quirks;
>
> if (edid == NULL) {
> + drm_reset_display_info(connector);
> clear_eld(connector);
> return 0;
> }
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
On Tue, Apr 26, 2022 at 11:02 AM Christian König wrote: > > Am 26.04.22 um 19:40 schrieb Chia-I Wu: > > [SNIP] > Well I just send a patch to completely remove the trace point. > > As I said it absolutely doesn't make sense to use this for > visualization, that's what the trace_dma_fence_init trace point is good > for. > > I am a bit confused by this. _emit and _signaled are a great way to > > see how many fences are pending from cpu's point of view. How does > > _emit make no sense and _init is good instead? > > We had exactly that confusion now multiple times and it's one of the > main reasons why I want to remove the _emit trace point. > > See the when you want to know how many fences are pending you need to > watch out for init/destroy and *NOT* emit. > > The reason is that in the special case where emit makes sense (e.g. the > GPU scheduler fences) emit comes later than init, but pending on the CPU > and taking up resources are all fences and not just the one emitted to > the hardware. I am more interested in pending on the GPU. > > On the other hand when you want to measure how much time each operation > took on the hardware you need to take a look at the differences of the > signal events on each timeline. _signaled alone is not enough when the GPU is not always busy. After the last pending fence signals but before the following _init/_emit, nothing is pending. For all drivers except virtio-gpu, _init and "ring head update" always happen close enough that I can see why _emit is redundant. But I like having _emit as a generic tracepoint for timelines where _init and _emit can be apart, instead of requiring a special case tracepoint for each special case timeline. > > So there isn't really any use case for the emit trace point, except when > you want to figure out how much latency the scheduler introduce. Then > you want to take a look at init and emit, but that isn't really that > interesting for performance analyses. > > Regards, > Christian. >
Re: [PATCH v2] drm/msm/dp: remove fail safe mode related code
Hi,
On Mon, Apr 25, 2022 at 10:56 PM Kuogee Hsieh wrote:
>
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
> is executed under drm_thread context.
>
> After review all possibilities methods and as discussed on
> https://patchwork.freedesktop.org/patch/483155/, supporting EDID
> compliance tests in the driver is quite hacky. As seen with other
> vendor drivers, supporting these will be much easier with IGT. Hence
> removing all the related fail safe code for it so that no possibility
> of circular lock will happen.
>
> ==
> WARNING: possible circular locking dependency detected
> 5.15.35-lockdep #6 Tainted: GW
> --
> frecon/429 is trying to acquire lock:
> ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
> dp_panel_add_fail_safe_mode+0x4c/0xa0
>
> but task is already holding lock:
> ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at:
> lock_crtcs+0xb4/0x124
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (>commit_lock[i]){+.+.}-{3:3}:
> __mutex_lock_common+0x174/0x1a64
> mutex_lock_nested+0x98/0xac
> lock_crtcs+0xb4/0x124
> msm_atomic_commit_tail+0x330/0x748
> commit_tail+0x19c/0x278
> drm_atomic_helper_commit+0x1dc/0x1f0
> drm_atomic_commit+0xc0/0xd8
> drm_atomic_helper_set_config+0xb4/0x134
> drm_mode_setcrtc+0x688/0x1248
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> -> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
> __mutex_lock_common+0x174/0x1a64
> ww_mutex_lock+0xb8/0x278
> modeset_lock+0x304/0x4ac
> drm_modeset_lock+0x4c/0x7c
> drmm_mode_config_init+0x4a8/0xc50
> msm_drm_init+0x274/0xac0
> msm_drm_bind+0x20/0x2c
> try_to_bring_up_master+0x3dc/0x470
> __component_add+0x18c/0x3c0
> component_add+0x1c/0x28
> dp_display_probe+0x954/0xa98
> platform_probe+0x124/0x15c
> really_probe+0x1b0/0x5f8
> __driver_probe_device+0x174/0x20c
> driver_probe_device+0x70/0x134
> __device_attach_driver+0x130/0x1d0
> bus_for_each_drv+0xfc/0x14c
> __device_attach+0x1bc/0x2bc
> device_initial_probe+0x1c/0x28
> bus_probe_device+0x94/0x178
> deferred_probe_work_func+0x1a4/0x1f0
> process_one_work+0x5d4/0x9dc
> worker_thread+0x898/0xccc
> kthread+0x2d4/0x3d4
> ret_from_fork+0x10/0x20
>
> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> ww_acquire_init+0x1c4/0x2c8
> drm_modeset_acquire_init+0x44/0xc8
> drm_helper_probe_single_connector_modes+0xb0/0x12dc
> drm_mode_getconnector+0x5dc/0xfe8
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> -> #0 (>mode_config.mutex){+.+.}-{3:3}:
> __lock_acquire+0x2650/0x672c
> lock_acquire+0x1b4/0x4ac
> __mutex_lock_common+0x174/0x1a64
> mutex_lock_nested+0x98/0xac
> dp_panel_add_fail_safe_mode+0x4c/0xa0
> dp_hpd_plug_handle+0x1f0/0x280
> dp_bridge_enable+0x94/0x2b8
> drm_atomic_bridge_chain_enable+0x11c/0x168
> drm_atomic_helper_commit_modeset_enables+0x500/0x740
> msm_atomic_commit_tail+0x3e4/0x748
> commit_tail+0x19c/0x278
> drm_atomic_helper_commit+0x1dc/0x1f0
> drm_atomic_commit+0xc0/0xd8
> drm_atomic_helper_set_config+0xb4/0x134
> drm_mode_setcrtc+0x688/0x1248
> drm_ioctl_kernel+0x1e4/0x338
> drm_ioctl+0x3a4/0x684
> __arm64_sys_ioctl+0x118/0x154
> invoke_syscall+0x78/0x224
> el0_svc_common+0x178/0x200
> do_el0_svc+0x94/0x13c
> el0_svc+0x5c/0xec
> el0t_64_sync_handler+0x78/0x108
> el0t_64_sync+0x1a4/0x1a8
>
> Changes in v2:
> -- re text commit title
> -- remove all fail safe mode
>
> Signed-off-by: Kuogee Hsieh
Reported-by: Douglas Anderson
Fixes: f1b47e6a8df8 ("drm/msm/dp: remove fail safe mode related code")
> @@ -151,15 +151,6 @@ static int dp_panel_update_modes(struct drm_connector
> *connector,
> return rc;
Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
Hi, On Tue, Apr 26, 2022 at 8:37 AM Abhinav Kumar wrote: > > > Can you provide the exact EDID from the failing test case? Maybe that > > will help shed some light on what's going on. I looked at the original > > commit and it just referred to 4.2.2.1, which I assume is "EDID Read > > upon HPD Plug Event", but that doesn't give details that seem relevant > > to the discussion here. > > Yes so it is 4.2.2.1 and 4.2.2.6. > > That alone wont give the full picture. > > So its a combination of things. > > While running the test, the test equipment published only one mode. > But we could not support that mode because of 2 lanes. > Equipment did not add 640x480 to the list of modes. > DRM fwk will also not add it because count_modes is not 0 ( there was > one mode ). > So we ended up making these changes. Ah! This is useful context and makes tons of sense. This really feels like something that could be handled in the core. OK, See: https://lore.kernel.org/r/20220426114627.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid > > I guess maybe what's happening is that the test case is giving an EDID > > where all the modes are not supportable by the current clock rate / > > lanes? ...and then somehow we're not falling back to 640x480. It's > > always possible that this is a userspace problem. > > > > In any case, would you object to a revert of the patches in the short term? > > Not sure, if you saw this change kuogee posted last night. > https://patchwork.freedesktop.org/patch/483415/ > We did decided to remove all the code related to these test cases and > handle them in IGT. I hadn't seen it yet and I wasn't CCed. :( I'll take a look now.
Re: [PATCH 1/2] drm/amdkfd: Use bitmap_zalloc() when applicable
Le 26/04/2022 à 20:01, Felix Kuehling a écrit :
Hi Christophe,
I just stumbled over this patch series while cleaning up my inbox. Sorry
for dropping it back in November. I'm about to apply it but I noticed
that patch 1 is missing a Signed-off-by. Is it OK to add that in your name?
Hi,
No problem for me if you can add it. Thanks.
But if you prefer a v2, it is also fine for me.
BTW sorry for missing the SoB tag. This definitively means that I forgot
the checkpatch.pl step for this patch, which is bad.
CJ
Thanks,
Felix
Am 2021-11-28 um 11:45 schrieb Christophe JAILLET:
'kfd->gtt_sa_bitmap' is a bitmap. So use 'bitmap_zalloc()' to simplify
code, improve the semantic and avoid some open-coded arithmetic in
allocator arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index e1294fba0c26..c5a0ce44a295 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1252,8 +1252,6 @@ int
kgd2kfd_schedule_evict_and_restore_process(struct mm_struct *mm,
static int kfd_gtt_sa_init(struct kfd_dev *kfd, unsigned int buf_size,
unsigned int chunk_size)
{
- unsigned int num_of_longs;
-
if (WARN_ON(buf_size < chunk_size))
return -EINVAL;
if (WARN_ON(buf_size == 0))
@@ -1264,11 +1262,8 @@ static int kfd_gtt_sa_init(struct kfd_dev *kfd,
unsigned int buf_size,
kfd->gtt_sa_chunk_size = chunk_size;
kfd->gtt_sa_num_of_chunks = buf_size / chunk_size;
- num_of_longs = (kfd->gtt_sa_num_of_chunks + BITS_PER_LONG - 1) /
- BITS_PER_LONG;
-
- kfd->gtt_sa_bitmap = kcalloc(num_of_longs, sizeof(long),
GFP_KERNEL);
-
+ kfd->gtt_sa_bitmap = bitmap_zalloc(kfd->gtt_sa_num_of_chunks,
+ GFP_KERNEL);
if (!kfd->gtt_sa_bitmap)
return -ENOMEM;
@@ -1278,13 +1273,12 @@ static int kfd_gtt_sa_init(struct kfd_dev
*kfd, unsigned int buf_size,
mutex_init(>gtt_sa_lock);
return 0;
-
}
static void kfd_gtt_sa_fini(struct kfd_dev *kfd)
{
mutex_destroy(>gtt_sa_lock);
- kfree(kfd->gtt_sa_bitmap);
+ bitmap_free(kfd->gtt_sa_bitmap);
}
static inline uint64_t kfd_gtt_sa_calc_gpu_addr(uint64_t start_addr,
[PATCH 2/2] drm/probe-helper: For DP, add 640x480 if all other modes are bad
As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a fail safe
mode.
A DP compliance test expected us to utilize the above fact when all
modes it presented to the DP source were not achievable. It presented
only modes that would be achievable with more lanes and/or higher
speeds than we had available and expected that when we couldn't do
that then we'd fall back to 640x480 even though it didn't advertise
this size.
In order to pass the compliance test (and also support any users who
might fall into a similar situation with their display), we need to
add 640x480 into the list of modes. However, we don't want to add
640x480 all the time. Despite the fact that the DP spec says all sinks
_shall support_ 640x480, they're not guaranteed to support it
_well_. Continuing to read the spec you can see that the display is
not required to really treat 640x480 equal to all the other modes. It
doesn't need to scale or anything--just display the pixels somehow for
failsafe purposes. It should also be noted that it's not hard to find
a display hooked up via DisplayPort that _doesn't_ support 640x480 at
all. The HP ZR30w screen I'm sitting in front of has a native DP port
and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
display via a DP to HDMI adapter and that screen definitely doesn't
support 640x480.
As a compromise solution, let's only add the 640x480 mode if:
* We're on DP.
* All other modes have been pruned.
This acknowledges that 640x480 might not be the best mode to use but,
since sinks are _supposed_ to support it, we will at least fall back
to it if there's nothing else.
Note that we _don't_ add higher resolution modes like 1024x768 in this
case. We only add those modes for a failed EDID read where we have no
idea what's going on. In the case where we've pruned all modes then
instead we only want 640x480 which is the only defined "Fail Safe"
resolution.
This patch originated in response to Kuogee Hsieh's patch [1].
[1]
https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khs...@quicinc.com
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_probe_helper.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 819225629010..90cd46cbfec1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -476,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int count = 0, ret;
- bool verbose_prune = true;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
@@ -556,8 +555,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_connector_update_edid_property(connector, NULL);
- verbose_prune = false;
- goto prune;
+ drm_mode_prune_invalid(dev, >modes, false);
+ goto exit;
}
count = (*connector_funcs->get_modes)(connector);
@@ -580,9 +579,26 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
}
}
-prune:
- drm_mode_prune_invalid(dev, >modes, verbose_prune);
+ drm_mode_prune_invalid(dev, >modes, true);
+ /*
+* Displayport spec section 5.2.1.2 ("Video Timing Format") says that
+* all detachable sinks shall support 640x480 @60Hz as a fail safe
+* mode. If all modes were pruned, perhaps because they need more
+* lanes or a higher pixel clock than available, at least try to add
+* in 640x480.
+*/
+ if (list_empty(>modes) &&
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ count = drm_add_modes_noedid(connector, 640, 480);
+ if (_drm_helper_update_and_validate(connector, maxX, maxY,
)) {
+ drm_modeset_backoff();
+ goto retry;
+ }
+ drm_mode_prune_invalid(dev, >modes, true);
+ }
+
+exit:
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
--
2.36.0.rc2.479.g8af0fa9b8e-goog
[PATCH 1/2] drm/probe-helper: Add helper for drm_helper_probe_single_connector_modes()
The drm_helper_probe_single_connector_modes() is a bit long. Let's
break a chunk off to update and validate modes. This helps avoid one
goto and also will allow us to more easily call the helper a second
time in a future patch without adding looping or another goto.
This change is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_probe_helper.c | 105 -
1 file changed, 59 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 682359512996..819225629010 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -354,6 +354,61 @@ drm_helper_probe_detect(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_helper_probe_detect);
+static bool _drm_helper_update_and_validate(struct drm_connector *connector,
+ uint32_t maxX, uint32_t maxY,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_display_mode *mode;
+ int mode_flags = 0;
+ int ret;
+
+ drm_connector_list_update(connector);
+
+ if (connector->interlace_allowed)
+ mode_flags |= DRM_MODE_FLAG_INTERLACE;
+ if (connector->doublescan_allowed)
+ mode_flags |= DRM_MODE_FLAG_DBLSCAN;
+ if (connector->stereo_allowed)
+ mode_flags |= DRM_MODE_FLAG_3D_MASK;
+
+ list_for_each_entry(mode, >modes, head) {
+ if (mode->status != MODE_OK)
+ continue;
+
+ mode->status = drm_mode_validate_driver(dev, mode);
+ if (mode->status != MODE_OK)
+ continue;
+
+ mode->status = drm_mode_validate_size(mode, maxX, maxY);
+ if (mode->status != MODE_OK)
+ continue;
+
+ mode->status = drm_mode_validate_flag(mode, mode_flags);
+ if (mode->status != MODE_OK)
+ continue;
+
+ ret = drm_mode_validate_pipeline(mode, connector, ctx,
+>status);
+ if (ret) {
+ drm_dbg_kms(dev,
+ "drm_mode_validate_pipeline failed: %d\n",
+ ret);
+
+ if (drm_WARN_ON_ONCE(dev, ret != -EDEADLK))
+ mode->status = MODE_ERROR;
+ else
+ return true;
+ }
+
+ if (mode->status != MODE_OK)
+ continue;
+ mode->status = drm_mode_validate_ycbcr420(mode, connector);
+ }
+
+ return false;
+}
+
/**
* drm_helper_probe_single_connector_modes - get complete set of display modes
* @connector: connector to probe
@@ -421,7 +476,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int count = 0, ret;
- int mode_flags = 0;
bool verbose_prune = true;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
@@ -519,52 +573,11 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
connector->status == connector_status_unknown))
count = drm_add_modes_noedid(connector, 1024, 768);
count += drm_helper_probe_add_cmdline_mode(connector);
- if (count == 0)
- goto prune;
-
- drm_connector_list_update(connector);
-
- if (connector->interlace_allowed)
- mode_flags |= DRM_MODE_FLAG_INTERLACE;
- if (connector->doublescan_allowed)
- mode_flags |= DRM_MODE_FLAG_DBLSCAN;
- if (connector->stereo_allowed)
- mode_flags |= DRM_MODE_FLAG_3D_MASK;
-
- list_for_each_entry(mode, >modes, head) {
- if (mode->status != MODE_OK)
- continue;
-
- mode->status = drm_mode_validate_driver(dev, mode);
- if (mode->status != MODE_OK)
- continue;
-
- mode->status = drm_mode_validate_size(mode, maxX, maxY);
- if (mode->status != MODE_OK)
- continue;
-
- mode->status = drm_mode_validate_flag(mode, mode_flags);
- if (mode->status != MODE_OK)
- continue;
-
- ret = drm_mode_validate_pipeline(mode, connector, ,
->status);
- if (ret) {
- drm_dbg_kms(dev,
- "drm_mode_validate_pipeline failed: %d\n",
- ret);
-
- if
Re: [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches
On Tue, Apr 26, 2022 at 06:32:01PM +, Souza, Jose wrote:
> On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> > On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > > Intel hardware supports change between modes with different refresh
> > > rates without any glitches or visual artifacts, that feature is called
> > > seamless DRRS.
> > >
> > > So far i915 driver was automatically changing between preferred panel
> > > mode and lower refresh rate mode based on idleness but ChromeOS
> > > compositor team is requesting to be in control of the mode switch.
> > > So for a certain types of content it can switch to mode with a lower
> > > refresh rate without user noticing a thing and saving power.
> > >
> > > This seamless mode switch will be triggered when user-space dispatch
> > > a atomic commit with the new mode and clears the
> > > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> > >
> > > A driver that don't implement atomic_seamless_mode_switch_check
> > > function will continue to fail in the atomic check phase with
> > > "[CRTC:%d:%s] requires full modeset" debug message.
> > > While a driver that implements it and support the seamless change
> > > between old and new mode will return 0 otherwise it should return the
> > > appropried errno.
> > >
> > > So here adding basic drm infrastructure to that be supported by i915
> > > and other drivers.
> >
> > I don't see the need for any extra infrastructure for this.
> >
> > I think we just need:
> > - fix the fastset code to not suck
>
> How would it know that only mode changed and not all other things that causes
> mode_changed to be set?
> For example: intel_digital_connector_atomic_check()
That's what the fastset stuff does. It checks if anything changes
that needs a full modeset or not.
>
> > - reprogram M/N during fastset
> > - calculate eDP link params using panel's highest refresh rate mode
> > to make sure we get the same link params for all refresh rates
> >
> > >
> > > Cc: Vidya Srinivas
> > > Cc: Sean Paul
> > > Cc: Ville Syrjälä
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 1 +
> > > drivers/gpu/drm/drm_atomic_helper.c | 16 +++
> > > drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> > > include/drm/drm_crtc.h| 25 +++
> > > 4 files changed, 43 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 58c0283fb6b0c..21525f9f4b4c1 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct
> > > drm_printer *p,
> > > drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
> > > drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
> > > drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> > > + drm_printf(p, "\tseamless_mode_changed=%d\n",
> > > state->seamless_mode_changed);
> > > drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
> > > drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
> > > drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 9603193d2fa13..e6f3a966f7b86 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device
> > > *dev,
> > > drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> > > crtc->base.id, crtc->name);
> > > new_crtc_state->mode_changed = true;
> > > +
> > > + if (!state->allow_modeset &&
> > > + crtc->funcs->atomic_seamless_mode_switch_check) {
> > > + ret =
> > > crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
> > > + if (ret == -EOPNOTSUPP) {
> > > + drm_dbg_atomic(dev, "[CRTC:%d:%s]
> > > Seamless mode switch not supported\n",
> > > +crtc->base.id,
> > > crtc->name);
> > > + return ret;
> > > + }
> > > +
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + new_crtc_state->seamless_mode_changed = true;
> > > + new_crtc_state->mode_changed = false;
> > > + }
> > > }
> > >
> > > if (old_crtc_state->enable != new_crtc_state->enable) {
> > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > index 3b6d3bdbd0996..c093073ea6e11 100644
> > > ---
Requests For Proposals for hosting XDC 2023 are now open
Hello everyone! The X.org board is soliciting proposals to host XDC in 2023. Since XDC 2022 is being held in North America this year, XDC 2023 is expected to be in Europe. However, the board is open to other locations, especially if there's an interesting co-location with another conference. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of *September 1st, 2022*. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. Best regards, Lyude Paul On behalf of X.org
XDC 2022: Registration & Call for Proposals now open!
Hello! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org
Re: [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches
On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > Intel hardware supports change between modes with different refresh
> > rates without any glitches or visual artifacts, that feature is called
> > seamless DRRS.
> >
> > So far i915 driver was automatically changing between preferred panel
> > mode and lower refresh rate mode based on idleness but ChromeOS
> > compositor team is requesting to be in control of the mode switch.
> > So for a certain types of content it can switch to mode with a lower
> > refresh rate without user noticing a thing and saving power.
> >
> > This seamless mode switch will be triggered when user-space dispatch
> > a atomic commit with the new mode and clears the
> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> >
> > A driver that don't implement atomic_seamless_mode_switch_check
> > function will continue to fail in the atomic check phase with
> > "[CRTC:%d:%s] requires full modeset" debug message.
> > While a driver that implements it and support the seamless change
> > between old and new mode will return 0 otherwise it should return the
> > appropried errno.
> >
> > So here adding basic drm infrastructure to that be supported by i915
> > and other drivers.
>
> I don't see the need for any extra infrastructure for this.
>
> I think we just need:
> - fix the fastset code to not suck
How would it know that only mode changed and not all other things that causes
mode_changed to be set?
For example: intel_digital_connector_atomic_check()
> - reprogram M/N during fastset
> - calculate eDP link params using panel's highest refresh rate mode
> to make sure we get the same link params for all refresh rates
>
> >
> > Cc: Vidya Srinivas
> > Cc: Sean Paul
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_helper.c | 16 +++
> > drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> > include/drm/drm_crtc.h| 25 +++
> > 4 files changed, 43 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58c0283fb6b0c..21525f9f4b4c1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct
> > drm_printer *p,
> > drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
> > drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
> > drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> > + drm_printf(p, "\tseamless_mode_changed=%d\n",
> > state->seamless_mode_changed);
> > drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
> > drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
> > drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 9603193d2fa13..e6f3a966f7b86 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> >crtc->base.id, crtc->name);
> > new_crtc_state->mode_changed = true;
> > +
> > + if (!state->allow_modeset &&
> > + crtc->funcs->atomic_seamless_mode_switch_check) {
> > + ret =
> > crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
> > + if (ret == -EOPNOTSUPP) {
> > + drm_dbg_atomic(dev, "[CRTC:%d:%s]
> > Seamless mode switch not supported\n",
> > + crtc->base.id,
> > crtc->name);
> > + return ret;
> > + }
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + new_crtc_state->seamless_mode_changed = true;
> > + new_crtc_state->mode_changed = false;
> > + }
> > }
> >
> > if (old_crtc_state->enable != new_crtc_state->enable) {
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 3b6d3bdbd0996..c093073ea6e11 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -142,6 +142,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> > drm_crtc *crtc,
> > if (state->gamma_lut)
> > drm_property_blob_get(state->gamma_lut);
> > state->mode_changed = false;
> > + state->seamless_mode_changed =
Re: [PATCH 1/5] dt-bindings: arm: mediatek: mmsys: add power and gce properties
On Tue, Apr 19, 2022 at 11:32:33AM +0800, Rex-BC Chen wrote:
> From: "jason-jh.lin"
>
> Power:
> 1. Add description for power-domains property.
>
> GCE:
> 1. Add description for mboxes property.
> 2. Add description for mediatek,gce-client-reg property.
>
> Signed-off-by: jason-jh.lin
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: CK Hu
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> index b31d90dc9eb4..6c2c3edcd443 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> @@ -41,6 +41,30 @@ properties:
>reg:
> maxItems: 1
>
> + power-domains:
How many and what are they.
> +description:
> + A phandle and PM domain specifier as defined by bindings
> + of the power controller specified by phandle. See
> + Documentation/devicetree/bindings/power/power-domain.yaml for details.
Drop. Don't need generic descriptions of common properties.
> +
> + mboxes:
How many?
> +description:
> + Using mailbox to communicate with GCE, it should have this
If using?
> + property and list of phandle, mailbox specifiers. See
> + Documentation/devicetree/bindings/mailbox/mtk-gce.txt for details.
Drop
> +$ref: /schemas/types.yaml#/definitions/phandle-array
Already has a type.
> +
> + mediatek,gce-client-reg:
> +description:
> + The register of client driver can be configured by gce with 4 arguments
> + defined in this property, such as phandle of gce, subsys id,
> + register offset and size.
> + Each subsys id is mapping to a base address of display function blocks
> + register which is defined in the gce header
> + include/dt-bindings/gce/-gce.h.
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +maxItems: 1
This needs to define exact sizes.
items:
- items:
- description: phandle to GCE
- description: subsy id
- description: register offset
- description: register size
> +
>"#clock-cells":
> const: 1
>
> @@ -56,9 +80,16 @@ additionalProperties: false
>
> examples:
>- |
> +#include
> +#include
> +
> mmsys: syscon@1400 {
> compatible = "mediatek,mt8173-mmsys", "syscon";
> reg = <0x1400 0x1000>;
> +power-domains = < MT8173_POWER_DOMAIN_MM>;
> #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>;
> };
> --
> 2.18.0
>
>
RE: [PATCH 1/3] drm: New function to get luminance range based on static hdr metadata
Yes I agree that this data parsed from EDID/Display ID should be stored in
structs defined in drm_display_info.
Like for the VRR range that we parse from EDID, we store that in a struct
monitor_range in drm_display_info.
Manasi
-Original Message-
From: dri-devel On Behalf Of Jani
Nikula
Sent: Tuesday, April 26, 2022 6:38 AM
To: Hogander, Jouni ; dri-devel@lists.freedesktop.org
Cc: Hogander, Jouni ; Rodrigo Siqueira
; Kahola, Mika
Subject: Re: [PATCH 1/3] drm: New function to get luminance range based on
static hdr metadata
On Tue, 26 Apr 2022, Jouni Högander wrote:
> Split luminance min/max calculation using static hdr metadata from
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:update_connector_ext
> _caps
> into drm/drm_edid.c.
IMO all of this should be computed at EDID parsing time once and stored in the
metadata. Maybe in drm_parse_hdr_metadata_block().
Over time we've added a bunch of functions to do this type of stuff, and all
drivers call them at slightly different times and different ways, and it just
grows complicated.
(Also, I think basically everything that comes out of the EDID or DisplayID
should be stored in connector->display_info instead of being spread around like
we currently do. But that's for another patch series, another time.)
BR,
Jani.
>
> Cc: Rodrigo Siqueira
> Cc: Harry Wentland
> Cc: Lyude Paul
> Cc: Mika Kahola
> Cc: Jani Nikula
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/drm_edid.c | 55 ++
> include/drm/drm_edid.h | 4 +++
> 2 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7a8482b75071..1cb886debbbe 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4005,6 +4005,61 @@ drm_display_mode_from_cea_vic(struct drm_device
> *dev, } EXPORT_SYMBOL(drm_display_mode_from_cea_vic);
>
> +/**
> + * drm_luminance_range_from_static_hdr_metadata() - luminance range
> +from static hdr
> + * metadata
> + * @connector: connector we're calculating for
> + * @min: Calculated min value
> + * @max: Calculated max value
> + *
> + * Calculates backlight min and max as described in CTA-861-G
> + *
> + * Returns: True when calculation succeeds.
> + */
> +bool
> +drm_luminance_range_from_static_hdr_metadata(struct drm_connector *connector,
> + u32 *min, u32 *max)
> +{
> + struct hdr_sink_metadata *hdr_metadata = >hdr_sink_metadata;
> + static const u8 pre_computed_values[] = {
> + 50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
> + 71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
> + u32 min_cll, max_cll, q, r;
> +
> + if (!(hdr_metadata->hdmi_type1.metadata_type &
> + BIT(HDMI_STATIC_METADATA_TYPE1)))
> + return false;
> +
> + max_cll = hdr_metadata->hdmi_type1.max_cll;
> + min_cll = hdr_metadata->hdmi_type1.min_cll;
> +
> + /* From the specification (CTA-861-G), for calculating the maximum
> + * luminance we need to use:
> + * Luminance = 50*2**(CV/32)
> + * Where CV is a one-byte value.
> + * For calculating this expression we may need float point precision;
> + * to avoid this complexity level, we take advantage that CV is divided
> + * by a constant. From the Euclids division algorithm, we know that CV
> + * can be written as: CV = 32*q + r. Next, we replace CV in the
> + * Luminance expression and get 50*(2**q)*(2**(r/32)), hence we just
> + * need to pre-compute the value of r/32. For pre-computing the values
> + * We just used the following Ruby line:
> + * (0...32).each {|cv| puts (50*2**(cv/32.0)).round}
> + * The results of the above expressions can be verified at
> + * pre_computed_values.
> + */
> + q = max_cll >> 5;
> + r = max_cll % 32;
> + *max = (1 << q) * pre_computed_values[r];
> +
> + /* min luminance: maxLum * (CV/255)^2 / 100 */
> + q = DIV_ROUND_CLOSEST(min_cll, 255);
> + *min = *max * DIV_ROUND_CLOSEST((q * q), 100);
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_luminance_range_from_static_hdr_metadata);
> +
> static int
> do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
> { diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index
> c3204a58fb09..63e441c84d72 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -406,6 +406,10 @@ drm_hdmi_avi_infoframe_quant_range(struct
> hdmi_avi_infoframe *frame,
> const struct drm_display_mode *mode,
> enum hdmi_quantization_range
> rgb_quant_range);
>
> +bool
> +drm_luminance_range_from_static_hdr_metadata(struct drm_connector *connector,
> + u32 *min, u32 *max);
> +
> /**
> * drm_eld_mnl - Get ELD monitor name length in bytes.
>
Re: [PATCH v2 1/2] drm/sched: use DECLARE_EVENT_CLASS
It's ok to land but it wasn't, do you have push permissions to drm-misc-next ? If not, I will do it for you. Andrey On 2022-04-26 12:29, Chia-I Wu wrote: On Tue, Apr 12, 2022 at 1:48 PM Chia-I Wu wrote: drm_sched_job and drm_run_job have the same prototype. v2: rename the class from drm_sched_job_entity to drm_sched_job (Andrey) Signed-off-by: Chia-I Wu Cc: Rob Clark Reviewed-by: Andrey Grodzovsky This series has been reviewed. Is it ok to land (if it hasn't)?
Re: [PATCH] drm/nouveau: fix returnvar.cocci warning
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Mon, 2022-04-25 at 19:47 +0800, Guo Zhengkui wrote:
> Fix the following coccicheck warning:
> drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c:71:5-12:
> Unneeded variable: "disable". Return "0ULL" on line 85.
>
> Signed-off-by: Guo Zhengkui
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c
> index dc026ac1b595..3d0ab86c3115 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c
> @@ -68,7 +68,6 @@ gt215_devinit_disable(struct nvkm_devinit *init)
> struct nvkm_device *device = init->subdev.device;
> u32 r001540 = nvkm_rd32(device, 0x001540);
> u32 r00154c = nvkm_rd32(device, 0x00154c);
> - u64 disable = 0ULL;
>
> if (!(r001540 & 0x4000)) {
> nvkm_subdev_disable(device, NVKM_ENGINE_MSPDEC, 0);
> @@ -82,7 +81,7 @@ gt215_devinit_disable(struct nvkm_devinit *init)
> if (!(r00154c & 0x0200))
> nvkm_subdev_disable(device, NVKM_ENGINE_CE, 0);
>
> - return disable;
> + return 0ULL;
> }
>
> static u32
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Replace crtc_state's has_drrs by drrs_downclock_mode
On Mon, 2022-04-25 at 14:55 +0300, Jani Nikula wrote:
> On Thu, 21 Apr 2022, José Roberto de Souza wrote:
> > Will be adding some additional control options to DRRS that will
> > require to have the DRRS downclock mode stored in the crtc_state.
> >
> > So to optimize memory usage a bit here using it to replace has_drrs
> > as we can check if the drrs_downclock_mode pointer is different than
> > null to have the same behavior has has_drrs.
> >
> > Cc: Vidya Srinivas
> > Cc: Sean Paul
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> > drivers/gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
> > drivers/gpu/drm/i915/display/intel_display_types.h | 4 +++-
> > drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_drrs.c| 4 ++--
> > 5 files changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 0ddfce21a828d..a5f5caeced9a0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5360,7 +5360,7 @@ static void intel_dump_pipe_config(const struct
> > intel_crtc_state *pipe_config,
> >
> > drm_dbg_kms(_priv->drm, "ips: %i, double wide: %i, drrs: %i\n",
> > pipe_config->ips_enabled, pipe_config->double_wide,
> > - pipe_config->has_drrs);
> > + CRTC_STATE_HAS_DRRS(pipe_config));
>
> I'll mostly let Ville comment on the series, but that macro is an
> eyesore and also just out of place in intel_display_types.h. Please make
> it a proper function intel_drrs_something_something() in
> intel_drrs.[ch].
Okay in making this a function but I don't have a good name for it neither.
intel_crtc_state_has_drrs() is worst than current name of the macro.
>
> BR,
> Jani.
>
> >
> > intel_dpll_dump_hw_state(dev_priv, _config->dpll_hw_state);
> >
> > @@ -7088,7 +7088,7 @@ static void intel_crtc_copy_fastset(const struct
> > intel_crtc_state *old_crtc_stat
> > new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
> > new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> > new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
> > - new_crtc_state->has_drrs = old_crtc_state->has_drrs;
> > + new_crtc_state->drrs_downclock_mode =
> > old_crtc_state->drrs_downclock_mode;
> > }
> >
> > static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 452d773fd4e34..f9720562336da 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1096,7 +1096,7 @@ static int i915_drrs_status(struct seq_file *m, void
> > *unused)
> >
> > /* DRRS Supported */
> > seq_printf(m, "\tDRRS Enabled: %s\n",
> > - str_yes_no(crtc_state->has_drrs));
> > + str_yes_no(CRTC_STATE_HAS_DRRS(crtc_state)));
> >
> > seq_printf(m, "\tDRRS Active: %s\n",
> >str_yes_no(intel_drrs_is_active(crtc)));
> > @@ -1786,7 +1786,7 @@ static int i915_drrs_ctl_set(void *data, u64 val)
> > crtc_state = to_intel_crtc_state(crtc->base.state);
> >
> > if (!crtc_state->hw.active ||
> > - !crtc_state->has_drrs)
> > + !CRTC_STATE_HAS_DRRS(crtc_state))
> > goto out;
> >
> > commit = crtc_state->uapi.commit;
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index cfd042117b109..f0b3cfd3138ce 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1056,7 +1056,7 @@ struct intel_crtc_state {
> >
> > /* m2_n2 for eDP downclock */
> > struct intel_link_m_n dp_m2_n2;
> > - bool has_drrs;
> > + const struct drm_display_mode *drrs_downclock_mode;
> >
> > /* PSR is supported but might not be enabled due the lack of enabled
> > planes */
> > bool has_psr;
> > @@ -1264,6 +1264,8 @@ enum drrs_refresh_rate {
> > DRRS_REFRESH_RATE_LOW,
> > };
> >
> > +#define CRTC_STATE_HAS_DRRS(crtc_state)
> > (!!((crtc_state)->drrs_downclock_mode))
> > +
> > #define INTEL_PIPE_CRC_ENTRIES_NR 128
> > struct intel_pipe_crc {
> > spinlock_t lock;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d55acc4a028a8..feea172dd2753 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1881,7 +1881,7 @@ intel_dp_drrs_compute_config(struct intel_connector
> > *connector,
>
Re: [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches
On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> Intel hardware supports change between modes with different refresh
> rates without any glitches or visual artifacts, that feature is called
> seamless DRRS.
>
> So far i915 driver was automatically changing between preferred panel
> mode and lower refresh rate mode based on idleness but ChromeOS
> compositor team is requesting to be in control of the mode switch.
> So for a certain types of content it can switch to mode with a lower
> refresh rate without user noticing a thing and saving power.
>
> This seamless mode switch will be triggered when user-space dispatch
> a atomic commit with the new mode and clears the
> DRM_MODE_ATOMIC_ALLOW_MODESET flag.
>
> A driver that don't implement atomic_seamless_mode_switch_check
> function will continue to fail in the atomic check phase with
> "[CRTC:%d:%s] requires full modeset" debug message.
> While a driver that implements it and support the seamless change
> between old and new mode will return 0 otherwise it should return the
> appropried errno.
>
> So here adding basic drm infrastructure to that be supported by i915
> and other drivers.
I don't see the need for any extra infrastructure for this.
I think we just need:
- fix the fastset code to not suck
- reprogram M/N during fastset
- calculate eDP link params using panel's highest refresh rate mode
to make sure we get the same link params for all refresh rates
>
> Cc: Vidya Srinivas
> Cc: Sean Paul
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_helper.c | 16 +++
> drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> include/drm/drm_crtc.h| 25 +++
> 4 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58c0283fb6b0c..21525f9f4b4c1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct
> drm_printer *p,
> drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
> drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
> drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> + drm_printf(p, "\tseamless_mode_changed=%d\n",
> state->seamless_mode_changed);
> drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
> drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
> drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9603193d2fa13..e6f3a966f7b86 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> crtc->base.id, crtc->name);
> new_crtc_state->mode_changed = true;
> +
> + if (!state->allow_modeset &&
> + crtc->funcs->atomic_seamless_mode_switch_check) {
> + ret =
> crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
> + if (ret == -EOPNOTSUPP) {
> + drm_dbg_atomic(dev, "[CRTC:%d:%s]
> Seamless mode switch not supported\n",
> +crtc->base.id,
> crtc->name);
> + return ret;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + new_crtc_state->seamless_mode_changed = true;
> + new_crtc_state->mode_changed = false;
> + }
> }
>
> if (old_crtc_state->enable != new_crtc_state->enable) {
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 3b6d3bdbd0996..c093073ea6e11 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -142,6 +142,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> drm_crtc *crtc,
> if (state->gamma_lut)
> drm_property_blob_get(state->gamma_lut);
> state->mode_changed = false;
> + state->seamless_mode_changed = false;
> state->active_changed = false;
> state->planes_changed = false;
> state->connectors_changed = false;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a70baea0636ca..b7ce378d679d3 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -140,6 +140,16 @@ struct drm_crtc_state {
>*/
>
Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
On 26/04/2022 20:56, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:44 AM Dmitry Baryshkov
wrote:
On 26/04/2022 20:11, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
wrote:
On 4/25/2022 7:18 PM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
wrote:
2) When there was a valid EDID but no 640x480 mode
This is the equipment specific case and the one even I was a bit
surprised. There is a DP compliance equipment we have in-house
and while
validation, it was found that in its list of modes , it did not
have any
modes which chromebook supported ( due to 2 lanes ). But my
understanding was that, all sinks should have atleast 640x480 but
apparently this one did not have that. So to handle this DP
compliance
equipment behavior, we had to do this.
That doesn't seem right. If there's a valid EDID and the valid EDID
doesn't contain 640x480, are you _sure_ you're supposed to be adding
640x480? That doesn't sound right to me. I've got a tiny display in
front of me for testing that only has one mode:
#0 800x480 65.68 800 840 888 928 480 493 496 525 32000
As I had wrote, DRM core kicks in only when the count of modes is 0.
Here what is happening is the count was not 0 but 640x480 was not
present in the EDID. So we had to add it explicitly.
Your tiny display is a display port display?
I am referring to only display port monitors. If your tiny display is
DP, it should have had 640x480 in its list of modes.
My tiny display is actually a HDMI display hooked up to a HDMI to DP
(active) adapter.
...but this is a legal and common thing to have. I suppose possibly my
HDMI display is "illegal"?
OK, so reading through the spec more carefully, I do see that the DP
spec makes numerous mentions of the fact that DP sinks _must_ support
640x480. Even going back to DP 1.4, I see section "5.2.1.2 Video
Timing Format" says that we must support 640x480. It seems like that's
_intended_ to be used only if the EDID read fails, though or if we
somehow have to output video without knowledge of the EDID. It seems
hard to believe that there's a great reason to assume a display will
support 640x480 if we have more accurate knowledge.
In any case, I guess I would still say that adding this mode belongs
in the DRM core. The core should notice that it's a DP connection
(bridge->type == DRM_MODE_CONNECTOR_DisplayPort) and that 640x480 was
left out and it should add it. We should also make sure it's not
"preferred" and is last in the list so we never accidentally pick it.
If DP truly says that we should always give the user 640x480 then
that's true for everyone, not just Qualcomm. We should add it in the
core. If, later, someone wants to hide this from the UI it would be
much easier if they only needed to modify one place.
So I debugged with kuogee just now using the DP compliance equipment.
It turns out, the issue is not that 640x480 mode is not present.
The issue is that it is not marked as preferred.
Hence we missed this part during debugging this equipment failure.
We still have to figure out the best way to either mark 640x480 as
preferred or eliminate other modes during the test-case so that 640x480
is actually picked by usermode.
Now that being said, the fix still doesn't belong in the framework. It
has to be in the msm/dp code.
Different vendors handle this failure case differently looks like.
Lets take below snippet from i915 as example.
3361if (intel_connector->detect_edid == NULL ||
3362connector->edid_corrupt ||
3363intel_dp->aux.i2c_defer_count > 6) {
3364/* Check EDID read for NACKs, DEFERs and corruption
3365 * (DP CTS 1.2 Core r1.1)
3366 *4.2.2.4 : Failed EDID read, I2C_NAK
3367 *4.2.2.5 : Failed EDID read, I2C_DEFER
3368 *4.2.2.6 : EDID corruption detected
3369 * Use failsafe mode for all cases
3370 */
3371if (intel_dp->aux.i2c_nack_count > 0 ||
3372intel_dp->aux.i2c_defer_count > 0)
3373drm_dbg_kms(>drm,
3374"EDID read had %d NACKs, %d
DEFERs\n",
3375intel_dp->aux.i2c_nack_count,
3376intel_dp->aux.i2c_defer_count);
3377intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
The reason I pointed to this code is to give an example of how other
drivers handle this test-case.
We added this patch for 4.2.2.1 and 4.2.2.6 EDID test cases.
The challenge here as found out from our discussion here was to mark a
particular mode as preferred so that the Chrome usermode can pick it.
Now whats happening with that there was always a possibility of two
modes being marked as preferred due to this and
Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
On 4/26/2022 10:56 AM, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:44 AM Dmitry Baryshkov
wrote:
On 26/04/2022 20:11, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
wrote:
On 4/25/2022 7:18 PM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
wrote:
2) When there was a valid EDID but no 640x480 mode
This is the equipment specific case and the one even I was a bit
surprised. There is a DP compliance equipment we have in-house
and while
validation, it was found that in its list of modes , it did not
have any
modes which chromebook supported ( due to 2 lanes ). But my
understanding was that, all sinks should have atleast 640x480 but
apparently this one did not have that. So to handle this DP
compliance
equipment behavior, we had to do this.
That doesn't seem right. If there's a valid EDID and the valid EDID
doesn't contain 640x480, are you _sure_ you're supposed to be adding
640x480? That doesn't sound right to me. I've got a tiny display in
front of me for testing that only has one mode:
#0 800x480 65.68 800 840 888 928 480 493 496 525 32000
As I had wrote, DRM core kicks in only when the count of modes is 0.
Here what is happening is the count was not 0 but 640x480 was not
present in the EDID. So we had to add it explicitly.
Your tiny display is a display port display?
I am referring to only display port monitors. If your tiny display is
DP, it should have had 640x480 in its list of modes.
My tiny display is actually a HDMI display hooked up to a HDMI to DP
(active) adapter.
...but this is a legal and common thing to have. I suppose possibly my
HDMI display is "illegal"?
OK, so reading through the spec more carefully, I do see that the DP
spec makes numerous mentions of the fact that DP sinks _must_ support
640x480. Even going back to DP 1.4, I see section "5.2.1.2 Video
Timing Format" says that we must support 640x480. It seems like that's
_intended_ to be used only if the EDID read fails, though or if we
somehow have to output video without knowledge of the EDID. It seems
hard to believe that there's a great reason to assume a display will
support 640x480 if we have more accurate knowledge.
In any case, I guess I would still say that adding this mode belongs
in the DRM core. The core should notice that it's a DP connection
(bridge->type == DRM_MODE_CONNECTOR_DisplayPort) and that 640x480 was
left out and it should add it. We should also make sure it's not
"preferred" and is last in the list so we never accidentally pick it.
If DP truly says that we should always give the user 640x480 then
that's true for everyone, not just Qualcomm. We should add it in the
core. If, later, someone wants to hide this from the UI it would be
much easier if they only needed to modify one place.
So I debugged with kuogee just now using the DP compliance equipment.
It turns out, the issue is not that 640x480 mode is not present.
The issue is that it is not marked as preferred.
Hence we missed this part during debugging this equipment failure.
We still have to figure out the best way to either mark 640x480 as
preferred or eliminate other modes during the test-case so that 640x480
is actually picked by usermode.
Now that being said, the fix still doesn't belong in the framework. It
has to be in the msm/dp code.
Different vendors handle this failure case differently looks like.
Lets take below snippet from i915 as example.
3361if (intel_connector->detect_edid == NULL ||
3362connector->edid_corrupt ||
3363intel_dp->aux.i2c_defer_count > 6) {
3364/* Check EDID read for NACKs, DEFERs and corruption
3365 * (DP CTS 1.2 Core r1.1)
3366 *4.2.2.4 : Failed EDID read, I2C_NAK
3367 *4.2.2.5 : Failed EDID read, I2C_DEFER
3368 *4.2.2.6 : EDID corruption detected
3369 * Use failsafe mode for all cases
3370 */
3371if (intel_dp->aux.i2c_nack_count > 0 ||
3372intel_dp->aux.i2c_defer_count > 0)
3373drm_dbg_kms(>drm,
3374"EDID read had %d NACKs, %d
DEFERs\n",
3375intel_dp->aux.i2c_nack_count,
3376intel_dp->aux.i2c_defer_count);
3377intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
The reason I pointed to this code is to give an example of how other
drivers handle this test-case.
We added this patch for 4.2.2.1 and 4.2.2.6 EDID test cases.
The challenge here as found out from our discussion here was to mark a
particular mode as preferred so that the Chrome usermode can pick it.
Now whats happening with that there was always a possibility of two
modes being marked as preferred due to this and
Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
Am 26.04.22 um 19:40 schrieb Chia-I Wu: [SNIP] Well I just send a patch to completely remove the trace point. As I said it absolutely doesn't make sense to use this for visualization, that's what the trace_dma_fence_init trace point is good for. I am a bit confused by this. _emit and _signaled are a great way to see how many fences are pending from cpu's point of view. How does _emit make no sense and _init is good instead? We had exactly that confusion now multiple times and it's one of the main reasons why I want to remove the _emit trace point. See the when you want to know how many fences are pending you need to watch out for init/destroy and *NOT* emit. The reason is that in the special case where emit makes sense (e.g. the GPU scheduler fences) emit comes later than init, but pending on the CPU and taking up resources are all fences and not just the one emitted to the hardware. On the other hand when you want to measure how much time each operation took on the hardware you need to take a look at the differences of the signal events on each timeline. So there isn't really any use case for the emit trace point, except when you want to figure out how much latency the scheduler introduce. Then you want to take a look at init and emit, but that isn't really that interesting for performance analyses. Regards, Christian.
Re: [PATCH 1/2] drm/amdkfd: Use bitmap_zalloc() when applicable
Hi Christophe,
I just stumbled over this patch series while cleaning up my inbox. Sorry
for dropping it back in November. I'm about to apply it but I noticed
that patch 1 is missing a Signed-off-by. Is it OK to add that in your name?
Thanks,
Felix
Am 2021-11-28 um 11:45 schrieb Christophe JAILLET:
'kfd->gtt_sa_bitmap' is a bitmap. So use 'bitmap_zalloc()' to simplify
code, improve the semantic and avoid some open-coded arithmetic in
allocator arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index e1294fba0c26..c5a0ce44a295 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1252,8 +1252,6 @@ int kgd2kfd_schedule_evict_and_restore_process(struct
mm_struct *mm,
static int kfd_gtt_sa_init(struct kfd_dev *kfd, unsigned int buf_size,
unsigned int chunk_size)
{
- unsigned int num_of_longs;
-
if (WARN_ON(buf_size < chunk_size))
return -EINVAL;
if (WARN_ON(buf_size == 0))
@@ -1264,11 +1262,8 @@ static int kfd_gtt_sa_init(struct kfd_dev *kfd, unsigned
int buf_size,
kfd->gtt_sa_chunk_size = chunk_size;
kfd->gtt_sa_num_of_chunks = buf_size / chunk_size;
- num_of_longs = (kfd->gtt_sa_num_of_chunks + BITS_PER_LONG - 1) /
- BITS_PER_LONG;
-
- kfd->gtt_sa_bitmap = kcalloc(num_of_longs, sizeof(long), GFP_KERNEL);
-
+ kfd->gtt_sa_bitmap = bitmap_zalloc(kfd->gtt_sa_num_of_chunks,
+ GFP_KERNEL);
if (!kfd->gtt_sa_bitmap)
return -ENOMEM;
@@ -1278,13 +1273,12 @@ static int kfd_gtt_sa_init(struct kfd_dev *kfd, unsigned int buf_size,
mutex_init(>gtt_sa_lock);
return 0;
-
}
static void kfd_gtt_sa_fini(struct kfd_dev *kfd)
{
mutex_destroy(>gtt_sa_lock);
- kfree(kfd->gtt_sa_bitmap);
+ bitmap_free(kfd->gtt_sa_bitmap);
}
static inline uint64_t kfd_gtt_sa_calc_gpu_addr(uint64_t start_addr,
[PATCH v3 1/2] drm/msm/dp: reset DP controller before transmit phy test pattern
DP controller state can not switch from video ready state to
transmit phy pattern state at run time. DP mainlink has to be
teared down followed by reset controller to default state to have
DP controller switch to transmit phy test pattern state and start
generate specified phy test pattern to sinker once main link setup
again.
Changes in v2:
-- correct Fixes's commit id
Fixes: 52352fe2f866 ("drm/msm/dp: use dp_ctrl_off_link_stream during PHY
compliance test run")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 5356856..193cc1a 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1532,7 +1532,7 @@ static int dp_ctrl_process_phy_test_request(struct
dp_ctrl_private *ctrl)
* running. Add the global reset just before disabling the
* link clocks and core clocks.
*/
- ret = dp_ctrl_off_link_stream(>dp_ctrl);
+ ret = dp_ctrl_off(>dp_ctrl);
if (ret) {
DRM_ERROR("failed to disable DP controller\n");
return ret;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 2/2] drm/msm/dp: do not stop transmitting phy test pattern during DP phy compliance test
At normal operation, transmit phy test pattern has to be terminated before
DP controller switch to video ready state. However during phy compliance
testing, transmit phy test pattern should not be terminated until end of
compliance test which usually indicated by unplugged interrupt.
Only stop sending the train pattern in dp_ctrl_on_stream() if we're not
doing compliance testing. We also no longer reset 'p_level' and
'v_level' within dp_ctrl_on_link() due to both 'p_level' and 'v_level'
are acquired from link status at previous dpcd read and we like to use
those level to start link training.
Changes in v2:
-- add more details commit text
-- correct Fixes
Changes in v3:
-- drop unnecessary braces
Fixes: 2e0adc765d88 ("drm/msm/dp: do not end dp link training until video is
ready")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 193cc1a..08cc48a 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1699,8 +1699,6 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
ctrl->link->link_params.rate,
ctrl->link->link_params.num_lanes, ctrl->dp_ctrl.pixel_rate);
- ctrl->link->phy_params.p_level = 0;
- ctrl->link->phy_params.v_level = 0;
rc = dp_ctrl_enable_mainlink_clocks(ctrl);
if (rc)
@@ -1822,12 +1820,6 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl)
}
}
- if (!dp_ctrl_channel_eq_ok(ctrl))
- dp_ctrl_link_retrain(ctrl);
-
- /* stop txing train pattern to end link training */
- dp_ctrl_clear_training_pattern(ctrl);
-
ret = dp_ctrl_enable_stream_clocks(ctrl);
if (ret) {
DRM_ERROR("Failed to start pixel clocks. ret=%d\n", ret);
@@ -1839,6 +1831,12 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl)
return 0;
}
+ if (!dp_ctrl_channel_eq_ok(ctrl))
+ dp_ctrl_link_retrain(ctrl);
+
+ /* stop txing train pattern to end link training */
+ dp_ctrl_clear_training_pattern(ctrl);
+
/*
* Set up transfer unit values and set controller state to send
* video.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 0/2] fix DP phy compliance test
Current DP phy compliance test failed due to test pattern generation was terminated premature. Kuogee Hsieh (2): drm/msm/dp: reset DP controller before transmit phy test pattern drm/msm/dp: do not stop transmitting phy test pattern during DP phy compliance test drivers/gpu/drm/msm/dp/dp_ctrl.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
Hi,
On Tue, Apr 26, 2022 at 10:44 AM Dmitry Baryshkov
wrote:
>
> On 26/04/2022 20:11, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
> > wrote:
> >>
> >> On 26/04/2022 18:37, Abhinav Kumar wrote:
> >>> Hi Doug
> >>>
> >>> On 4/26/2022 8:20 AM, Doug Anderson wrote:
> Hi,
>
> On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
> wrote:
> >
> > On 4/25/2022 7:18 PM, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
> >> wrote:
> >>>
> > 2) When there was a valid EDID but no 640x480 mode
> >
> > This is the equipment specific case and the one even I was a bit
> > surprised. There is a DP compliance equipment we have in-house
> > and while
> > validation, it was found that in its list of modes , it did not
> > have any
> > modes which chromebook supported ( due to 2 lanes ). But my
> > understanding was that, all sinks should have atleast 640x480 but
> > apparently this one did not have that. So to handle this DP
> > compliance
> > equipment behavior, we had to do this.
>
> That doesn't seem right. If there's a valid EDID and the valid EDID
> doesn't contain 640x480, are you _sure_ you're supposed to be adding
> 640x480? That doesn't sound right to me. I've got a tiny display in
> front of me for testing that only has one mode:
>
> #0 800x480 65.68 800 840 888 928 480 493 496 525 32000
>
> >>>
> >>> As I had wrote, DRM core kicks in only when the count of modes is 0.
> >>> Here what is happening is the count was not 0 but 640x480 was not
> >>> present in the EDID. So we had to add it explicitly.
> >>>
> >>> Your tiny display is a display port display?
> >>>
> >>> I am referring to only display port monitors. If your tiny display is
> >>> DP, it should have had 640x480 in its list of modes.
> >>
> >> My tiny display is actually a HDMI display hooked up to a HDMI to DP
> >> (active) adapter.
> >>
> >> ...but this is a legal and common thing to have. I suppose possibly my
> >> HDMI display is "illegal"?
> >>
> >> OK, so reading through the spec more carefully, I do see that the DP
> >> spec makes numerous mentions of the fact that DP sinks _must_ support
> >> 640x480. Even going back to DP 1.4, I see section "5.2.1.2 Video
> >> Timing Format" says that we must support 640x480. It seems like that's
> >> _intended_ to be used only if the EDID read fails, though or if we
> >> somehow have to output video without knowledge of the EDID. It seems
> >> hard to believe that there's a great reason to assume a display will
> >> support 640x480 if we have more accurate knowledge.
> >>
> >> In any case, I guess I would still say that adding this mode belongs
> >> in the DRM core. The core should notice that it's a DP connection
> >> (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) and that 640x480 was
> >> left out and it should add it. We should also make sure it's not
> >> "preferred" and is last in the list so we never accidentally pick it.
> >> If DP truly says that we should always give the user 640x480 then
> >> that's true for everyone, not just Qualcomm. We should add it in the
> >> core. If, later, someone wants to hide this from the UI it would be
> >> much easier if they only needed to modify one place.
> >>
> >
> > So I debugged with kuogee just now using the DP compliance equipment.
> > It turns out, the issue is not that 640x480 mode is not present.
> >
> > The issue is that it is not marked as preferred.
> >
> > Hence we missed this part during debugging this equipment failure.
> >
> > We still have to figure out the best way to either mark 640x480 as
> > preferred or eliminate other modes during the test-case so that 640x480
> > is actually picked by usermode.
> >
> > Now that being said, the fix still doesn't belong in the framework. It
> > has to be in the msm/dp code.
> >
> > Different vendors handle this failure case differently looks like.
> >
> > Lets take below snippet from i915 as example.
> >
> > 3361if (intel_connector->detect_edid == NULL ||
> > 3362connector->edid_corrupt ||
> > 3363intel_dp->aux.i2c_defer_count > 6) {
> > 3364/* Check EDID read for NACKs, DEFERs and corruption
> > 3365 * (DP CTS 1.2 Core r1.1)
> > 3366 *4.2.2.4 : Failed EDID read, I2C_NAK
> > 3367 *4.2.2.5 : Failed EDID read, I2C_DEFER
> > 3368 *4.2.2.6 : EDID corruption detected
> > 3369 * Use failsafe mode for all cases
> > 3370 */
> > 3371if
Re: How should "max bpc" KMS property work?
On Tue, Apr 26, 2022 at 11:35:02AM +0300, Pekka Paalanen wrote: > Hi all, > > I'm working on setting HDR & WCG video modes in Weston, and I thought > setting "max bpc" KMS property on the connector would be a good idea. > I'm confused about how it works though. > > I did some digging in > https://gitlab.freedesktop.org/wayland/weston/-/issues/612 > > Summary: > > - Apparently the property was originally added as a manual workaround > for sink hardware behaving badly with high depth. A simple end user > setting for "max bpc" would suffice for this use. > > - Drivers will sometimes automatically choose a lower bpc than the "max > bpc" value, but never bigger. > > - amdgpu seems to (did?) default "max bpc" to 8, meaning that I > definitely want to raise it. I've occasionally pondered about doing the same for i915, just to have the safest default possible. But I'd hate to lose the deep color testing coverage knowing very few people would in practice raise the limit. Also the number of systems where deep color doesn't work reliably (or can't be made to work by not using a crap cable) seems to be quite low. > > If I always slam "max bpc" to the highest supported value for that > property, do I lose more than workarounds for bad sink hardware? We don't have any workarounds implemented like this in the kernel. Or should not have at least. "max bpc" exists purely for the user to have a say in the matter in addition to whatever the EDID/quirks say. Ie. if the kernel knows for sure that deep color won't work on a particular setup then it should just not allow deep color at all despite what the prop value says. So the only danger is fighting with the user's wishes which I guess you can overcome with some kind of user visible knob. > > Do I lose the ability to set video modes that take too much bandwidth > at uncapped driver-selected bpc while capping the bpc lower would allow > me to use those video modes? > > Or, are drivers required to choose a lower-than-usual but highest > usable bpc to make the requested video mode squeeze through the > connector and link? IMO drivers should implement the "reduce bpc until it fits" fallback. We have that in i915, except for MST where we'd need to potentially involve multiple streams in the fallback. That is something we intend to remedy eventually but it's not an entirely trivial thing to implement so will take some actual work. ATM we just cap MST to <=8bpc to avoid users getting into this situation so often. > > Do I need to implement a fallback strategy in a display server, > starting from the highest possible "max bpc" value, and if my modeset > is rejected, repeatedly try with lower "max bpc" setting until it works > or I'm out of bpc options? IMO the bpc part should be handled by the kernel since we already had this behaviour even before the "max bpc" prop was introduced and we didn't add an explicit "use this bpc or fail" prop. But of course you should have some kind of sensible fallback strategy for things that just fail for other reasons. The one problem we have in the kernel is that we have no way to ask the user if the display we tried to light up is actually working. So our policy decisions can't really involve user input. Userspace should not generally have that problem. -- Ville Syrjälä Intel
Re: [PATCH] drm/nouveau/disp/gv100: make gv100_disp_wndw and gv100_disp_wndw_mthd static
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Mon, 2022-04-25 at 09:13 -0400, Tom Rix wrote:
> Sparse reports these issues
> wndwgv100.c:120:1: warning: symbol 'gv100_disp_wndw_mthd' was not declared.
> Should it be static?
> wndwgv100.c:140:1: warning: symbol 'gv100_disp_wndw' was not declared.
> Should it be static?
>
> These variable are only used in wndwgv100.c. Single file variables should
> be static.
> So use static as their storage-class specifiers.
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c
> index 5d3b641dbb14..e635247d794f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c
> @@ -116,7 +116,7 @@ gv100_disp_wndw_mthd_base = {
> }
> };
>
> -const struct nv50_disp_chan_mthd
> +static const struct nv50_disp_chan_mthd
> gv100_disp_wndw_mthd = {
> .name = "Window",
> .addr = 0x001000,
> @@ -136,7 +136,7 @@ gv100_disp_wndw_intr(struct nv50_disp_chan *chan, bool
> en)
> nvkm_mask(device, 0x611da4, mask, data);
> }
>
> -const struct nv50_disp_chan_func
> +static const struct nv50_disp_chan_func
> gv100_disp_wndw = {
> .init = gv100_disp_dmac_init,
> .fini = gv100_disp_dmac_fini,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/nouveau/disp/gv100: make gv100_disp_wimm static
Reviewed-by: Lyude Paul
Will push upstream in a moment
On Mon, 2022-04-25 at 09:00 -0400, Tom Rix wrote:
> Sparse reports this issue
> wimmgv100.c:39:1: warning: symbol 'gv100_disp_wimm' was not declared. Should
> it be static?
>
> This variable is only used in wimmgv100.c. Single file variables should be
> static.
> So use static as its storage-class specifier.
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c
> index 89d783368b4f..bb4db6351ddf 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c
> @@ -35,7 +35,7 @@ gv100_disp_wimm_intr(struct nv50_disp_chan *chan, bool en)
> nvkm_mask(device, 0x611da8, mask, data);
> }
>
> -const struct nv50_disp_chan_func
> +static const struct nv50_disp_chan_func
> gv100_disp_wimm = {
> .init = gv100_disp_dmac_init,
> .fini = gv100_disp_dmac_fini,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
On 26/04/2022 20:11, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
wrote:
On 4/25/2022 7:18 PM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
wrote:
2) When there was a valid EDID but no 640x480 mode
This is the equipment specific case and the one even I was a bit
surprised. There is a DP compliance equipment we have in-house
and while
validation, it was found that in its list of modes , it did not
have any
modes which chromebook supported ( due to 2 lanes ). But my
understanding was that, all sinks should have atleast 640x480 but
apparently this one did not have that. So to handle this DP
compliance
equipment behavior, we had to do this.
That doesn't seem right. If there's a valid EDID and the valid EDID
doesn't contain 640x480, are you _sure_ you're supposed to be adding
640x480? That doesn't sound right to me. I've got a tiny display in
front of me for testing that only has one mode:
#0 800x480 65.68 800 840 888 928 480 493 496 525 32000
As I had wrote, DRM core kicks in only when the count of modes is 0.
Here what is happening is the count was not 0 but 640x480 was not
present in the EDID. So we had to add it explicitly.
Your tiny display is a display port display?
I am referring to only display port monitors. If your tiny display is
DP, it should have had 640x480 in its list of modes.
My tiny display is actually a HDMI display hooked up to a HDMI to DP
(active) adapter.
...but this is a legal and common thing to have. I suppose possibly my
HDMI display is "illegal"?
OK, so reading through the spec more carefully, I do see that the DP
spec makes numerous mentions of the fact that DP sinks _must_ support
640x480. Even going back to DP 1.4, I see section "5.2.1.2 Video
Timing Format" says that we must support 640x480. It seems like that's
_intended_ to be used only if the EDID read fails, though or if we
somehow have to output video without knowledge of the EDID. It seems
hard to believe that there's a great reason to assume a display will
support 640x480 if we have more accurate knowledge.
In any case, I guess I would still say that adding this mode belongs
in the DRM core. The core should notice that it's a DP connection
(bridge->type == DRM_MODE_CONNECTOR_DisplayPort) and that 640x480 was
left out and it should add it. We should also make sure it's not
"preferred" and is last in the list so we never accidentally pick it.
If DP truly says that we should always give the user 640x480 then
that's true for everyone, not just Qualcomm. We should add it in the
core. If, later, someone wants to hide this from the UI it would be
much easier if they only needed to modify one place.
So I debugged with kuogee just now using the DP compliance equipment.
It turns out, the issue is not that 640x480 mode is not present.
The issue is that it is not marked as preferred.
Hence we missed this part during debugging this equipment failure.
We still have to figure out the best way to either mark 640x480 as
preferred or eliminate other modes during the test-case so that 640x480
is actually picked by usermode.
Now that being said, the fix still doesn't belong in the framework. It
has to be in the msm/dp code.
Different vendors handle this failure case differently looks like.
Lets take below snippet from i915 as example.
3361if (intel_connector->detect_edid == NULL ||
3362connector->edid_corrupt ||
3363intel_dp->aux.i2c_defer_count > 6) {
3364/* Check EDID read for NACKs, DEFERs and corruption
3365 * (DP CTS 1.2 Core r1.1)
3366 *4.2.2.4 : Failed EDID read, I2C_NAK
3367 *4.2.2.5 : Failed EDID read, I2C_DEFER
3368 *4.2.2.6 : EDID corruption detected
3369 * Use failsafe mode for all cases
3370 */
3371if (intel_dp->aux.i2c_nack_count > 0 ||
3372intel_dp->aux.i2c_defer_count > 0)
3373drm_dbg_kms(>drm,
3374"EDID read had %d NACKs, %d
DEFERs\n",
3375intel_dp->aux.i2c_nack_count,
3376intel_dp->aux.i2c_defer_count);
3377intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
The reason I pointed to this code is to give an example of how other
drivers handle this test-case.
We added this patch for 4.2.2.1 and 4.2.2.6 EDID test cases.
The challenge here as found out from our discussion here was to mark a
particular mode as preferred so that the Chrome usermode can pick it.
Now whats happening with that there was always a possibility of two
modes being marked as preferred due to this and so-on.
We had a pretty long discussion last night and thought of all possible
solutions but all of them look like
Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
On Tue, Apr 26, 2022 at 10:20 AM Christian König wrote: > > Am 26.04.22 um 19:16 schrieb Rob Clark: > > On Tue, Apr 26, 2022 at 10:08 AM Christian König > > wrote: > >> Am 26.04.22 um 19:05 schrieb Rob Clark: > >>> On Tue, Apr 26, 2022 at 9:42 AM Christian König > >>> wrote: > Am 26.04.22 um 18:32 schrieb Chia-I Wu: > > On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote: > >> In practice, trace_dma_fence_init called from dma_fence_init is good > >> enough and almost no driver calls trace_dma_fence_emit. But drm_sched > >> and virtio both have cases where trace_dma_fence_init and > >> trace_dma_fence_emit can be apart. It is easier for visualization > >> tools > >> to always use the more correct trace_dma_fence_emit when visualizing > >> fence timelines. > >> > >> v2: improve commit message (Dmitry) > >> > >> Signed-off-by: Chia-I Wu > >> Cc: Rob Clark > >> Reviewed-by: Dmitry Baryshkov > > This has been reviewed. Should we land it? > No, there are still open discussions about it. > >>> I think if it is needed for trace visualization, that is justification > >>> enough for me > >>> > >>> I don't really see otherwise how a generic trace visualization tool > >>> like perfetto would handle the case that some fence timelines have > >>> separate events but others do not. > >> Well I just send a patch to completely remove the trace point. > >> > >> As I said it absolutely doesn't make sense to use this for > >> visualization, that's what the trace_dma_fence_init trace point is good > >> for. I am a bit confused by this. _emit and _signaled are a great way to see how many fences are pending from cpu's point of view. How does _emit make no sense and _init is good instead? Or is this just that _init is good enough most of the time? (More below) > >> > >> The only use case is for debugging the GPU scheduler and we should > >> probably introduce a separate GPU scheduler specific trace point for > >> this instead if we should ever need it. > > Hmm, AFAIU from Chia-I, virtgpu has a separation of init and emit.. > > OTOH if using separate events in these special cases is better, then > > I'm ok with that and can revert this patch. Chia-I is more familiar > > with the visualization end of it, so I'll let him comment on whether > > that is a workable approach. > > Interesting, I wasn't aware of the virtgpu separation of init and emit. > > But yes if there is really an use case for tracing this time stamp as > well then we should probably have that use case specific. > > I just looked into the scheduler case a bit and found that even there we > already have a different trace point for it, which is probably the > reason why we never used trace_dma_fence_emit there. Yeah, I am using drm_sched tracepoints in that case. > > So yes, there really isn't much reason I can see two have two separate > trace points for every driver. That sounds fair. In any tool, it should be easy to see if a fence timeline has _emit in addition to _init, and adapt accordingly. We can drop this patch. A clarification that _emit is optional/redundant for most fence timelines should be nicer than removing it though. > > Christian. > > > > > BR, > > -R > > > >> Regards, > >> Christian. > >> > >>> BR, > >>> -R > >>> > Regards, > Christian. > > > (Or, how do I check if it has landed?) >
Re: [PATCH v2] drm/msm/dp: remove fail safe mode related code
On 4/25/2022 11:00 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-04-25 22:56:35)
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is executed under drm_thread context.
After review all possibilities methods and as discussed on
https://patchwork.freedesktop.org/patch/483155/, supporting EDID
compliance tests in the driver is quite hacky. As seen with other
vendor drivers, supporting these will be much easier with IGT. Hence
removing all the related fail safe code for it so that no possibility
of circular lock will happen.
[...]
Changes in v2:
-- re text commit title
-- remove all fail safe mode
Signed-off-by: Kuogee Hsieh
Should add some Fixes tags here, probably for the first introduction of
this logic and the one that moved stuff around to try to avoid the
lockdep warning.
Fixes: 8b2c181 ("drm/msm/dp: add fail safe mode outside of event_mutex
context")
Re: [PATCH] drm/nouveau/kms/gv100: use static for gv100_disp_core_mthd_[base|sor]
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a bit
On Fri, 2022-04-22 at 14:51 -0400, Tom Rix wrote:
> Sparse reports these issues
> coregv100.c:27:1: warning: symbol 'gv100_disp_core_mthd_base' was not
> declared. Should it be static?
> coregv100.c:43:1: warning: symbol 'gv100_disp_core_mthd_sor' was not
> declared. Should it be static?
>
> These variables are only used in coregv100.c. Single file use
> variables should be static, so add static to their storage-class specifier.
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c
> index 448a515057c7..1d333c484a49 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c
> @@ -23,7 +23,7 @@
>
> #include
>
> -const struct nv50_disp_mthd_list
> +static const struct nv50_disp_mthd_list
> gv100_disp_core_mthd_base = {
> .mthd = 0x,
> .addr = 0x00,
> @@ -39,7 +39,7 @@ gv100_disp_core_mthd_base = {
> }
> };
>
> -const struct nv50_disp_mthd_list
> +static const struct nv50_disp_mthd_list
> gv100_disp_core_mthd_sor = {
> .mthd = 0x0020,
> .addr = 0x20,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
On 4/26/2022 10:11 AM, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
wrote:
On 4/25/2022 7:18 PM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
wrote:
2) When there was a valid EDID but no 640x480 mode
This is the equipment specific case and the one even I was a bit
surprised. There is a DP compliance equipment we have in-house
and while
validation, it was found that in its list of modes , it did not
have any
modes which chromebook supported ( due to 2 lanes ). But my
understanding was that, all sinks should have atleast 640x480 but
apparently this one did not have that. So to handle this DP
compliance
equipment behavior, we had to do this.
That doesn't seem right. If there's a valid EDID and the valid EDID
doesn't contain 640x480, are you _sure_ you're supposed to be adding
640x480? That doesn't sound right to me. I've got a tiny display in
front of me for testing that only has one mode:
#0 800x480 65.68 800 840 888 928 480 493 496 525 32000
As I had wrote, DRM core kicks in only when the count of modes is 0.
Here what is happening is the count was not 0 but 640x480 was not
present in the EDID. So we had to add it explicitly.
Your tiny display is a display port display?
I am referring to only display port monitors. If your tiny display is
DP, it should have had 640x480 in its list of modes.
My tiny display is actually a HDMI display hooked up to a HDMI to DP
(active) adapter.
...but this is a legal and common thing to have. I suppose possibly my
HDMI display is "illegal"?
OK, so reading through the spec more carefully, I do see that the DP
spec makes numerous mentions of the fact that DP sinks _must_ support
640x480. Even going back to DP 1.4, I see section "5.2.1.2 Video
Timing Format" says that we must support 640x480. It seems like that's
_intended_ to be used only if the EDID read fails, though or if we
somehow have to output video without knowledge of the EDID. It seems
hard to believe that there's a great reason to assume a display will
support 640x480 if we have more accurate knowledge.
In any case, I guess I would still say that adding this mode belongs
in the DRM core. The core should notice that it's a DP connection
(bridge->type == DRM_MODE_CONNECTOR_DisplayPort) and that 640x480 was
left out and it should add it. We should also make sure it's not
"preferred" and is last in the list so we never accidentally pick it.
If DP truly says that we should always give the user 640x480 then
that's true for everyone, not just Qualcomm. We should add it in the
core. If, later, someone wants to hide this from the UI it would be
much easier if they only needed to modify one place.
So I debugged with kuogee just now using the DP compliance equipment.
It turns out, the issue is not that 640x480 mode is not present.
The issue is that it is not marked as preferred.
Hence we missed this part during debugging this equipment failure.
We still have to figure out the best way to either mark 640x480 as
preferred or eliminate other modes during the test-case so that 640x480
is actually picked by usermode.
Now that being said, the fix still doesn't belong in the framework. It
has to be in the msm/dp code.
Different vendors handle this failure case differently looks like.
Lets take below snippet from i915 as example.
3361if (intel_connector->detect_edid == NULL ||
3362connector->edid_corrupt ||
3363intel_dp->aux.i2c_defer_count > 6) {
3364/* Check EDID read for NACKs, DEFERs and corruption
3365 * (DP CTS 1.2 Core r1.1)
3366 *4.2.2.4 : Failed EDID read, I2C_NAK
3367 *4.2.2.5 : Failed EDID read, I2C_DEFER
3368 *4.2.2.6 : EDID corruption detected
3369 * Use failsafe mode for all cases
3370 */
3371if (intel_dp->aux.i2c_nack_count > 0 ||
3372intel_dp->aux.i2c_defer_count > 0)
3373drm_dbg_kms(>drm,
3374"EDID read had %d NACKs, %d
DEFERs\n",
3375intel_dp->aux.i2c_nack_count,
3376intel_dp->aux.i2c_defer_count);
3377intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
The reason I pointed to this code is to give an example of how other
drivers handle this test-case.
We added this patch for 4.2.2.1 and 4.2.2.6 EDID test cases.
The challenge here as found out from our discussion here was to mark a
particular mode as preferred so that the Chrome usermode can pick it.
Now whats happening with that there was always a possibility of two
modes being marked as preferred due to this and so-on.
We had a pretty long discussion last night and thought of all possible
solutions but all of them look
Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
Am 26.04.22 um 19:16 schrieb Rob Clark: On Tue, Apr 26, 2022 at 10:08 AM Christian König wrote: Am 26.04.22 um 19:05 schrieb Rob Clark: On Tue, Apr 26, 2022 at 9:42 AM Christian König wrote: Am 26.04.22 um 18:32 schrieb Chia-I Wu: On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote: In practice, trace_dma_fence_init called from dma_fence_init is good enough and almost no driver calls trace_dma_fence_emit. But drm_sched and virtio both have cases where trace_dma_fence_init and trace_dma_fence_emit can be apart. It is easier for visualization tools to always use the more correct trace_dma_fence_emit when visualizing fence timelines. v2: improve commit message (Dmitry) Signed-off-by: Chia-I Wu Cc: Rob Clark Reviewed-by: Dmitry Baryshkov This has been reviewed. Should we land it? No, there are still open discussions about it. I think if it is needed for trace visualization, that is justification enough for me I don't really see otherwise how a generic trace visualization tool like perfetto would handle the case that some fence timelines have separate events but others do not. Well I just send a patch to completely remove the trace point. As I said it absolutely doesn't make sense to use this for visualization, that's what the trace_dma_fence_init trace point is good for. The only use case is for debugging the GPU scheduler and we should probably introduce a separate GPU scheduler specific trace point for this instead if we should ever need it. Hmm, AFAIU from Chia-I, virtgpu has a separation of init and emit.. OTOH if using separate events in these special cases is better, then I'm ok with that and can revert this patch. Chia-I is more familiar with the visualization end of it, so I'll let him comment on whether that is a workable approach. Interesting, I wasn't aware of the virtgpu separation of init and emit. But yes if there is really an use case for tracing this time stamp as well then we should probably have that use case specific. I just looked into the scheduler case a bit and found that even there we already have a different trace point for it, which is probably the reason why we never used trace_dma_fence_emit there. So yes, there really isn't much reason I can see two have two separate trace points for every driver. Christian. BR, -R Regards, Christian. BR, -R Regards, Christian. (Or, how do I check if it has landed?)
Re: [Freedreno] [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
>
> On 26/04/2022 18:37, Abhinav Kumar wrote:
> > Hi Doug
> >
> > On 4/26/2022 8:20 AM, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
> >> wrote:
> >>>
> >>> On 4/25/2022 7:18 PM, Doug Anderson wrote:
> Hi,
>
> On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
> wrote:
> >
> >>> 2) When there was a valid EDID but no 640x480 mode
> >>>
> >>> This is the equipment specific case and the one even I was a bit
> >>> surprised. There is a DP compliance equipment we have in-house
> >>> and while
> >>> validation, it was found that in its list of modes , it did not
> >>> have any
> >>> modes which chromebook supported ( due to 2 lanes ). But my
> >>> understanding was that, all sinks should have atleast 640x480 but
> >>> apparently this one did not have that. So to handle this DP
> >>> compliance
> >>> equipment behavior, we had to do this.
> >>
> >> That doesn't seem right. If there's a valid EDID and the valid EDID
> >> doesn't contain 640x480, are you _sure_ you're supposed to be adding
> >> 640x480? That doesn't sound right to me. I've got a tiny display in
> >> front of me for testing that only has one mode:
> >>
> >> #0 800x480 65.68 800 840 888 928 480 493 496 525 32000
> >>
> >
> > As I had wrote, DRM core kicks in only when the count of modes is 0.
> > Here what is happening is the count was not 0 but 640x480 was not
> > present in the EDID. So we had to add it explicitly.
> >
> > Your tiny display is a display port display?
> >
> > I am referring to only display port monitors. If your tiny display is
> > DP, it should have had 640x480 in its list of modes.
>
> My tiny display is actually a HDMI display hooked up to a HDMI to DP
> (active) adapter.
>
> ...but this is a legal and common thing to have. I suppose possibly my
> HDMI display is "illegal"?
>
> OK, so reading through the spec more carefully, I do see that the DP
> spec makes numerous mentions of the fact that DP sinks _must_ support
> 640x480. Even going back to DP 1.4, I see section "5.2.1.2 Video
> Timing Format" says that we must support 640x480. It seems like that's
> _intended_ to be used only if the EDID read fails, though or if we
> somehow have to output video without knowledge of the EDID. It seems
> hard to believe that there's a great reason to assume a display will
> support 640x480 if we have more accurate knowledge.
>
> In any case, I guess I would still say that adding this mode belongs
> in the DRM core. The core should notice that it's a DP connection
> (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) and that 640x480 was
> left out and it should add it. We should also make sure it's not
> "preferred" and is last in the list so we never accidentally pick it.
> If DP truly says that we should always give the user 640x480 then
> that's true for everyone, not just Qualcomm. We should add it in the
> core. If, later, someone wants to hide this from the UI it would be
> much easier if they only needed to modify one place.
>
> >>>
> >>> So I debugged with kuogee just now using the DP compliance equipment.
> >>> It turns out, the issue is not that 640x480 mode is not present.
> >>>
> >>> The issue is that it is not marked as preferred.
> >>>
> >>> Hence we missed this part during debugging this equipment failure.
> >>>
> >>> We still have to figure out the best way to either mark 640x480 as
> >>> preferred or eliminate other modes during the test-case so that 640x480
> >>> is actually picked by usermode.
> >>>
> >>> Now that being said, the fix still doesn't belong in the framework. It
> >>> has to be in the msm/dp code.
> >>>
> >>> Different vendors handle this failure case differently looks like.
> >>>
> >>> Lets take below snippet from i915 as example.
> >>>
> >>> 3361if (intel_connector->detect_edid == NULL ||
> >>> 3362connector->edid_corrupt ||
> >>> 3363intel_dp->aux.i2c_defer_count > 6) {
> >>> 3364/* Check EDID read for NACKs, DEFERs and corruption
> >>> 3365 * (DP CTS 1.2 Core r1.1)
> >>> 3366 *4.2.2.4 : Failed EDID read, I2C_NAK
> >>> 3367 *4.2.2.5 : Failed EDID read, I2C_DEFER
> >>> 3368 *4.2.2.6 : EDID corruption detected
> >>> 3369 * Use failsafe mode for all cases
> >>> 3370 */
> >>> 3371if (intel_dp->aux.i2c_nack_count > 0 ||
> >>> 3372intel_dp->aux.i2c_defer_count > 0)
> >>> 3373drm_dbg_kms(>drm,
> >>> 3374"EDID read had %d NACKs, %d
> >>> DEFERs\n",
> >>> 3375intel_dp->aux.i2c_nack_count,
> >>> 3376
Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
On Tue, Apr 26, 2022 at 10:08 AM Christian König wrote: > > Am 26.04.22 um 19:05 schrieb Rob Clark: > > On Tue, Apr 26, 2022 at 9:42 AM Christian König > > wrote: > >> Am 26.04.22 um 18:32 schrieb Chia-I Wu: > >>> On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote: > In practice, trace_dma_fence_init called from dma_fence_init is good > enough and almost no driver calls trace_dma_fence_emit. But drm_sched > and virtio both have cases where trace_dma_fence_init and > trace_dma_fence_emit can be apart. It is easier for visualization tools > to always use the more correct trace_dma_fence_emit when visualizing > fence timelines. > > v2: improve commit message (Dmitry) > > Signed-off-by: Chia-I Wu > Cc: Rob Clark > Reviewed-by: Dmitry Baryshkov > >>> This has been reviewed. Should we land it? > >> No, there are still open discussions about it. > > I think if it is needed for trace visualization, that is justification > > enough for me > > > > I don't really see otherwise how a generic trace visualization tool > > like perfetto would handle the case that some fence timelines have > > separate events but others do not. > > Well I just send a patch to completely remove the trace point. > > As I said it absolutely doesn't make sense to use this for > visualization, that's what the trace_dma_fence_init trace point is good for. > > The only use case is for debugging the GPU scheduler and we should > probably introduce a separate GPU scheduler specific trace point for > this instead if we should ever need it. Hmm, AFAIU from Chia-I, virtgpu has a separation of init and emit.. OTOH if using separate events in these special cases is better, then I'm ok with that and can revert this patch. Chia-I is more familiar with the visualization end of it, so I'll let him comment on whether that is a workable approach. BR, -R > Regards, > Christian. > > > > > BR, > > -R > > > >> Regards, > >> Christian. > >> > >>> (Or, how do I check if it has landed?) >
Re: [PATCH v6 10/19] drm/msm/dpu: make changes to dpu_encoder to support virtual encoder
On 26/04/2022 17:41, Abhinav Kumar wrote:
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v4:
- squash dpu_encoder pieces from [1]
changes in v5:
- none
changes in v6:
- fix the comment about intf_idx and wb_idx
- add the condition for valid phys_enc with intf_idx
and wb_idx
[1] https://patchwork.freedesktop.org/patch/483099/?series=102964=2
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Minor nits below,
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 98 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 7 ++
2 files changed, 87 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 25c7eda..e9d8859 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1013,9 +1013,18 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
if (phys->intf_idx >= INTF_0 && phys->intf_idx < INTF_MAX)
phys->hw_intf = dpu_rm_get_intf(_kms->rm,
phys->intf_idx);
- if (!phys->hw_intf) {
+ if (phys->wb_idx >= WB_0 && phys->wb_idx < WB_MAX)
+ phys->hw_wb = dpu_rm_get_wb(_kms->rm, phys->wb_idx);
+
+ if (!phys->hw_intf && !phys->hw_wb) {
+ DPU_ERROR_ENC(dpu_enc,
+ "no intf or wb block assigned at idx:
%d\n", i);
+ return;
+ }
+
+ if (phys->hw_intf && phys->hw_wb) {
DPU_ERROR_ENC(dpu_enc,
- "no intf block assigned at idx: %d\n", i);
+ "invalid phys both intf and wb block at idx:
%d\n", i);
return;
}
@@ -1163,16 +1172,35 @@ static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog,
{
int i = 0;
- for (i = 0; i < catalog->intf_count; i++) {
- if (catalog->intf[i].type == type
- && catalog->intf[i].controller_id == controller_id) {
- return catalog->intf[i].id;
+ if (type != INTF_WB) {
This might be easier (like you did in the dpu_encoder_get_wb()):
if (type == INTF_WB)
goto end;
+ for (i = 0; i < catalog->intf_count; i++) {
+ if (catalog->intf[i].type == type
+ && catalog->intf[i].controller_id ==
controller_id) {
+ return catalog->intf[i].id;
+ }
}
}
return INTF_MAX;
}
+static enum dpu_wb dpu_encoder_get_wb(struct dpu_mdss_cfg *catalog,
+ enum dpu_intf_type type, u32 controller_id)
+{
+ int i = 0;
+
+ if (type != INTF_WB)
+ goto end;
+
+ for (i = 0; i < catalog->wb_count; i++) {
+ if (catalog->wb[i].id == controller_id)
+ return catalog->wb[i].id;
+ }
+
+end:
+ return WB_MAX;
+}
+
static void dpu_encoder_vblank_callback(struct drm_encoder *drm_enc,
struct dpu_encoder_phys *phy_enc)
{
@@ -1887,16 +1915,32 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
dpu_encoder_helper_reset_mixers(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);
-
- /* mark INTF flush as pending */
- if (phys_enc->hw_ctl->ops.update_pending_flush_intf)
-
phys_enc->hw_ctl->ops.update_pending_flush_intf(phys_enc->hw_ctl,
- dpu_enc->phys_encs[i]->hw_intf->idx);
+ /*
+* TODO: move the once-only operation like CTL flush/trigger
+* into dpu_encoder_virt_disable() and all operations which need
+* to be done per phys encoder into the phys_disable() op.
+*/
+ if (phys_enc->hw_wb) {
+ /* disable the PP block */
+ if (phys_enc->hw_wb->ops.bind_pingpong_blk)
+ phys_enc->hw_wb->ops.bind_pingpong_blk(phys_enc->hw_wb,
false,
+ phys_enc->hw_pp->idx);
+
+ /* mark WB flush as pending */
+ if (phys_enc->hw_ctl->ops.update_pending_flush_wb)
+ phys_enc->hw_ctl->ops.update_pending_flush_wb(ctl,
phys_enc->hw_wb->idx);
+ } else {
+ for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+ if (dpu_enc->phys_encs[i] &&
Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
Am 26.04.22 um 19:05 schrieb Rob Clark: On Tue, Apr 26, 2022 at 9:42 AM Christian König wrote: Am 26.04.22 um 18:32 schrieb Chia-I Wu: On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote: In practice, trace_dma_fence_init called from dma_fence_init is good enough and almost no driver calls trace_dma_fence_emit. But drm_sched and virtio both have cases where trace_dma_fence_init and trace_dma_fence_emit can be apart. It is easier for visualization tools to always use the more correct trace_dma_fence_emit when visualizing fence timelines. v2: improve commit message (Dmitry) Signed-off-by: Chia-I Wu Cc: Rob Clark Reviewed-by: Dmitry Baryshkov This has been reviewed. Should we land it? No, there are still open discussions about it. I think if it is needed for trace visualization, that is justification enough for me I don't really see otherwise how a generic trace visualization tool like perfetto would handle the case that some fence timelines have separate events but others do not. Well I just send a patch to completely remove the trace point. As I said it absolutely doesn't make sense to use this for visualization, that's what the trace_dma_fence_init trace point is good for. The only use case is for debugging the GPU scheduler and we should probably introduce a separate GPU scheduler specific trace point for this instead if we should ever need it. Regards, Christian. BR, -R Regards, Christian. (Or, how do I check if it has landed?)
Re: [PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
On Tue, Apr 26, 2022 at 9:42 AM Christian König wrote: > > Am 26.04.22 um 18:32 schrieb Chia-I Wu: > > On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote: > >> In practice, trace_dma_fence_init called from dma_fence_init is good > >> enough and almost no driver calls trace_dma_fence_emit. But drm_sched > >> and virtio both have cases where trace_dma_fence_init and > >> trace_dma_fence_emit can be apart. It is easier for visualization tools > >> to always use the more correct trace_dma_fence_emit when visualizing > >> fence timelines. > >> > >> v2: improve commit message (Dmitry) > >> > >> Signed-off-by: Chia-I Wu > >> Cc: Rob Clark > >> Reviewed-by: Dmitry Baryshkov > > This has been reviewed. Should we land it? > > No, there are still open discussions about it. I think if it is needed for trace visualization, that is justification enough for me I don't really see otherwise how a generic trace visualization tool like perfetto would handle the case that some fence timelines have separate events but others do not. BR, -R > Regards, > Christian. > > > > > (Or, how do I check if it has landed?) >
Re: [PATCH] dma-buf: remove trace_dma_fence_emit
Add a few more people on CC.
Am 26.04.22 um 19:00 schrieb Christian König:
There was never any significant difference between trace_dma_fence_emit()
and trace_dma_fence_init() and the only place where it would made a
significant difference was never implemented.
So remove trace_dma_fence_emit() since we have an repeating issue that
people are trying to use it for visualization and are surprised that
it actually doesn't work for most drivers.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence.c | 1 -
drivers/gpu/drm/nouveau/nouveau_fence.c | 1 -
drivers/gpu/drm/qxl/qxl_release.c | 1 -
drivers/gpu/drm/virtio/virtgpu_fence.c | 2 --
include/trace/events/dma_fence.h| 7 ---
5 files changed, 12 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 066400ed8841..d0d704f3edae 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -20,7 +20,6 @@
#define CREATE_TRACE_POINTS
#include
-EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 7f01dcf81fab..abcac7db4347 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -224,7 +224,6 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct
nouveau_channel *chan)
>lock, fctx->context, ++fctx->sequence);
kref_get(>fence_ref);
- trace_dma_fence_emit(>base);
ret = fctx->emit(fence);
if (!ret) {
dma_fence_get(>base);
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 368d26da0d6a..cb9f27771f32 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -424,7 +424,6 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
*/
dma_fence_init(>base, _fence_ops, >release_lock,
release->id | 0xf000, release->base.seqno);
- trace_dma_fence_emit(>base);
list_for_each_entry(entry, >bos, head) {
bo = entry->bo;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index f28357dbde35..e8b6dec37977 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -111,8 +111,6 @@ void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
list_add_tail(>node, >fences);
spin_unlock_irqrestore(>lock, irq_flags);
- trace_dma_fence_emit(>f);
-
cmd_hdr->flags |= cpu_to_le32(VIRTIO_GPU_FLAG_FENCE);
cmd_hdr->fence_id = cpu_to_le64(fence->fence_id);
diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h
index 3963e79ca7b4..eb744a6aca49 100644
--- a/include/trace/events/dma_fence.h
+++ b/include/trace/events/dma_fence.h
@@ -34,13 +34,6 @@ DECLARE_EVENT_CLASS(dma_fence,
__entry->seqno)
);
-DEFINE_EVENT(dma_fence, dma_fence_emit,
-
- TP_PROTO(struct dma_fence *fence),
-
- TP_ARGS(fence)
-);
-
DEFINE_EVENT(dma_fence, dma_fence_init,
TP_PROTO(struct dma_fence *fence),
